A new vulnerability in Internet Explorer already in use for targeted attacks leads this week’s Risk intelligence summary.  Exploit code has been published and a Metasploit module makes weaponization trivial. Verizon Business customers should pull out their “MS out-of-cycle patch” response plans as this seems ripe for their twelfth incident.  February’s Adobe Reader vulnerability is also being used in targeted attacks.  Patching vulnerabilities in Brightmail, OpenView and OpenSSL, all infrastructure, should be planned.  March’s Microsoft Tuesday came in the form of security bulletins for Excel and Windows Movie Maker, but only enterprises at risk to targeted attacks via Excel need to deploy these patches. The good guys made inroads against the Zeus gang, but a broad Koobface attack on Facebook users Thursday evening to Friday may have been the gang’s answer, if one accepts our assessment that they are closely related. After all the bluster of RSA two weeks ago, we were back to confronting real problems over the last week.

In Outliers, Malcom Gladwell analyses how plane crashes are the result of a combination of errors. I found this analysis very interesting because of the similarity with most security breaches. A brief excerpt of his book:

“Plane crashes rarely happen in real life the same way they happen in the movies. Some engine part does not explode in a fiery bang. The rudder doesn’t suddenly snap under the force of takeoff. The captain doesn’t gasp, “Dear God,” as he’s thrown back against his seat. The typical commercial jetliner – at this point in its stage of development – is about as dependable as a toaster. Plane crashes are much more likely to be the result of an accumulation of minor difficulties and seemingly trivial malfunctions.

The typical accident involves seven consecutive human errors. One of the pilots does something wrong that by itself is not a problem. Then one of them makes another error on top of that, which combined with the first error still does not amount to catastrophe. But then they make a third error on top of that, and then another and another and another and another, and it is the combination of all those errors that leads to disaster.”

Security breaches happen exactly like that. They are the result of a combination of minor or seemingly insignificant errors. Let me illustrate this. A few years ago, a merchant suffered a breach, and its case is one of the best examples for this topic. Their e-commerce website was developed in-house but some of the components had been developed by a third party. The application had been thoroughly reviewed for security vulnerabilities and none had been identified as risky. However, one of the components was not reviewed, it was added a few days after the application review had been completed, and since it was not related in any way with payment transactions, it was deemed as non-critical.

The merchant had a network IDS which was maintained and monitored by a MSS (managed security services) vendor. The device had signatures that were able to recognize SQL injection attempts and they were supposedly enabled. One of the vendor’s security analysts disabled rules monitoring attacks on port 80 and 443 for the e-commerce servers. This was probably because they generated many false-positive alerts, and was most likely intended as a temporary action. As a result, none of the attacks and unusual traffic on those ports was detected by the IDS.

The e-commerce site was using a trusted relationship to connect to the database. Credit card numbers had been encrypted in the database a few months ago. During the process as a contingency plan, the DBA exported the tables containing sensitive data before encrypting some of the columns. The backup files had been left on the database server since then.

Hackers found the security vulnerability in the e-commerce website; the third-party component was vulnerable to SQL injection. By exploiting the vulnerability, they were able to create local administrator accounts on the database server and run OS commands with local administrator privileges. Unfortunately, since the IDS was not monitoring traffic on ports 90 and 443, none of the SQL probes was detected by the IDS, nor was any other unusual traffic on those ports. Remote management tools were installed and password hashes were cracked off-line. The hackers reviewed every folder on the web server looking for scripts, source code, and data files. They found the backup files left behind by the DBA.

The merchant was only aware of the intrusion several months after the fact, when they were notified by law enforcement agents that their data was on sale on one of the carders websites.

This case clearly illustrates that even when proper security controls are in place, a breach could happen at any moment. Relying on single controls or single layers of security is never sufficient.

The case also illustrates the need to assess security controls independently of any other surrounding security or other layers of security. QSAs and internal staff in charge of PCI DSS compliance should not consider risk-based discussions until all the security controls have been independently assessed.

Focus on the human subject – the beneficiary of technology

We’re pretty good at dealing with everything from the digital perimeter through to the protected resources the person wants to access. But the big problem, the very old problem, that we’ve made little progress in solving, is reliably and confidently authenticating the person to the digital perimeter. Let’s keep in mind the kind of attacks on information systems that we see everyday, the vast majority of them are attacking the human being through some form of impersonation.

My thesis would be that we have extraordinary existing technology for securing everything within the digital workflow, but we are unbelievably immature in our current approaches to securely connecting the human being (the physical world) to the digital world.

99% of protected resources still rely on Username/Password as the means for authentication of a human being. Let’s be clear about this,  Username/Password does not authenticate a human being, it authenticates a directory entry.

We can talk about End-to-End trust forever, but until we can effectively manage the identity risk of human beings using Information Systems, the weakest link will continue to be end-user authentication and it will continue to be the primary focus of attacks.

The problem with traditional electronic identity credentials

Symmetric key cryptography, or shared secrets, is not an inherently weak form of authentication. It just happens that as its currently implemented though Username/Password across heterogeneous, monolithic systems it is wholly inadequate. Human beings are actually outrageously capable cryptographic processors. In fact, when it comes to communication, language, collaboration and knowledge almost everything we do is rooted in our ability to perform millions of symmetric key cryptographic operations in real-time and, for the most part, sub-consciously.

Two quick examples should cement the point. The citrus fruit called orange, when ripe is also the color orange. At a very young age we’re taught to associate specific labels – red, orange, blue, etc with specific frequencies of light. So the only reason 2 speakers refer to the color of an orange as orange is because we have a socially agreed upon set of key pairs. Language, alphabets, etc all work the same way. The only reason I don’t know Chinese is because I’ve not learned those specific encryption/decryption algorithms.

Another example should cement the cryptographic nature of these relationships. Prior to going to a potentially boring party, I agree with my friend that if one of us says “how about those Red Sox”, we should both immediately initiate an exit strategy. Since we exclusively know the “code”, for all other participants in the conversation it is effectively “cyphertext.

Now, if you think about how many of these operations we constantly perform, for instance, as you’re reading this blog, you will get my point. Bottom-line, human beings are naturally really good at cryptography.

So why are Username/Passwords so bad? 3 reasons:

• They are not easy to use. We don’t intuitively think of or recall 8+ character words with 1 upper-case alpha, 1 lower case alpha, one number and one non-alpha numeric. It’s get even harder when we have to change them every 90 days, and they must be different than the last 10 we used, and we’ve got 30 pairs of them to remember.
• Compromise is hard to detect. They are typically static for long periods of time – like 90 days — and it’s not obvious to the end-user when someone else has compromised them.
• They are not unique to the subject. Many people could have the same password, so there is nothing that inherently connects a password to an individual user.

Now contrast that with our ability to remember and recognize faces. Even though facial recognition is vastly more complicated then remembering an 8 character complex password, it is orders of magnitude easier and more intuitive for us to recognize faces, and this is just one example of many. Any of these things can be used as key material for symmetric crypto systems.

For electronic credentials to be effective and efficient there are a few properties they should exhibit:

• Ease of use. They should be intuitive, leverage capabilities that we already possess and fit in with our lifestyles and work habits. That implies we need more then one. What may be an appropriate electronic credential when we’re authenticating to an ATM in a private vestibule, may not be appropriate when we’re attending a wedding or sitting in a lecture hall.
• Easy to detect compromise. It should be obvious, in a short amount of time (minutes or hours vs. days or months) when a credential has been compromised. While it’s almost impossible to know someone’s stolen your password, it’s obvious, pretty quickly, when someone’s stolen your Blackberry.
• They should be unique to you. At least one, and ideally, multiple components of a credential should be unique, ie., only 1 exists and it’s associated with you. That means when compromised it either no longer exists or is no longer associated with you.

Now, I’m not suggesting PIV cards and biometric readers for everyone. Quite the opposite, because they are terrible at 1 and only reasonably good at 2 and 3. What I’m suggesting is approaching the whole concept of electronic credentials from a totally different perspective.

People should be able to use whatever credential best suits the particular transaction, the physical and social environment in which they find themselves, and the capabilities they have at their immediate disposal. Part II of the post will be coming soon.

Issues with ASLR, DEP and RSA authentication are irrelevant to risk for the foreseeable future, but fueled the Sirens into competition with the banshees. Activists mounted DoS attacks between Korea and Japan.  A faint bright spot near the Conception catastrophe was that it occurred more than 1,000 miles (1600km) from the Pan-American submarine cable’s landfall in Arica, Chile. Last week we prompted for stilts and hip waders, but earplugs are now also part of the uniform of the week.

The week began with this announcement via The Register, “Most businesses are defenseless against the types of attacks that recently hit Google and at least 33 other companies….” “Defenseless!”  Goodness gracious, ABANDON SHIP!  But then I thought, “maybe the reporter just misinterpreted the primary source.”  So I downloaded the report from iSec, and their disturbing conclusion has the same ring of finality, “even most Fortune-500 companies will not be able to assemble security teams with the diversity of skills necessary to respond to this type of incident.  It is extremely unlikely that SMBs will be able to properly prepare for these threats.” Then I checked to make sure Verizon is in the Fortune-500, and then I started to look for some hemlock.

Don’t you see?  It’s hopeless.  Time to give up.  Richard Bejtlich says, “get the divers out of the water,” and there are only two companies up to the task of fighting an APT.  Hey, I don’t work for either of those, therefore, I’m just not capable of helping my customers secure their information.

But wait!  Maybe it’s not TEOTWAWKI .  On Wednesday, Computerworld told me, “Attacks on Google may have been work of amateurs.”  Phew!  Maybe I have a career after all.  Maybe the last 26 years haven’t been a complete waste of time. But what if this reporter got it wrong though? I better check the original source. Wonderful news: “criminal operators behind the attack are relatively unsophisticated….”  This from the same people who told us six weeks ago, “regardless of the perimeter or host security technology you deploy, and how “preemptive” it is, it isn’t going to stop an APT.”  So, if they can flip-flop perhaps there’s hope for the rest of us after all.

Do you know what really convinced me it’s time to go?  It was yesterday’s headline, “Researchers seek balance in security hype.”

My job is done.  More than four years ago, my colleagues and I on the Risk Team began providing “Hype or Hot” alerts to our customers.  The very first one called “hype” on FUD being spread about CVE-2005-1790, one of those times Microsoft patched a vulnerability on the next month’s patch Tuesday.  This was a year before the Storm worm.  This was back in the days when we still worried about global worm outbreaks using the latest Windows vulnerability.  Yet we called “hype” on that one.  Anyone know of anybody who was compromised by that old bug (rhetorical)?  It certainly doesn’t conjure up nightmares like “LSASS” does it (also rhetorical)?

Since that time, we’ve used “hype” more often than our other grades which include To-Do (do in 90 days), Important (do in 30 days), Hot (do in 7 days), Red Hot (do something ASAP), Hoax (false claims) and Fact (true, but good security practices protect).  We’ve spent altogether too many hours not doing security but, instead, reacting to some nonsensical headline.

No longer are we the only voices calling “hype.”  <insert joyous chorus here>

And just when I thought I could move on, yet another reason the world is about to end broke yesterday: “Severe’ OpenSSL vuln busts public key crypto.” Busted! <insert Macaulay Culkin graphic here>

EJECT, EJECT, EJECT!

Don’t you see now?  It’s all so hopeless!  There’s no reason to get out of bed in the morning.

It’s not like I was in a profession filled with tens of thousands of dedicated and ethical individuals and teams. It’s not as if every good security company on the planet has a vested interest in providing security for their customers.  (Here I define “good security company” as any company that actually does have a vested interest in the security of their customers.)

The anti-virus companies really don’t care if their customers are “defenseless,” do they? They aren’t working 24×7 to solve not only the easy rogue AV, and they are not trying “to stop an APT,” and they not already working on whatever is going to come after that.  No, they’re all just sitting around collecting subscription fees and ignoring the ringing phones. They don’t care about their customers. They don’t care about their shareholders. There’s no cooperation among them to share samples, and no one is making presentations at conferences like Virus Bulletin to share information among themselves.  Right?

It must be “extremely unlikely” for my peers and I to learn anything or create anything useful, and most of us are not in one of those places where “the” solution exists.  It’s not as if most of us don’t scorn the Henny-penny’s who try to tell us we’re “defenseless,” or “extremely unlikely” (to do our job), or that we’re incapable of transforming “busted” into “secured.”

It’s not like I was in a profession full of problem solvers who come to work every day to provide security for the people, places, things and information that make society go.  If some scurrilous idiot, or criminal, or spy, or even nation state, attacks, people in this profession won’t work tirelessly to ensure those attacks fail. No, we’ll just throw up our hands and the Internet will stop working, and then we’ll all just curl up in our cubicles and die.

So I’m done.  I’m done with the hype.  I’m done with the headlines that exaggerate every problem. I’m done with the defeatism. I’m done with elitism. I’m done with the researchers who spend my tax money on problems instead of solutions.  I’m done with the narcissistic vulnerability pimps.  I’m done with the collateral that implies the competition is incompetent and irrelevant.

The production of the DBIR has been driven by our desire to help solve what we see as two of the most significant problems facing our industry:

1. Uncertainty due to the lack of data
2. Equivocality due to the lack of a common framework

Basically, we believe that until we can all be on the same page regarding what terms mean and why those terms are useful, we’re going to have a problem creating meaning from any data we *do* get.

One of the reasons we feel that the DBIR is so useful is because it translates the incident narrative (the attacker did this, then that, then the other thing) into a data set.  To accomplish this translation, we used a set of metrics developed internally. Think of it as a framework of incident elements we believe will, when gathered consistently, help people better interpret data and manage risk.

Today we’re making a version of that framework, the Verizon Incident Sharing Framework (VerIS), available for you to use.

In the document that  you can download here, you’ll find the first release of the VerIS framework.  You can also find a shorter executive summary here.  Our goal for our customers, friends, and anyone responsible for incident response, is to be able to create data sets that can be used and compared because of their commonality.  Together, we can work to eliminate both equivocality and uncertainty, and help defend the organizations we serve.

We hope that you’ll use and even take an active interest in the VerIS Framework.  To that extent, we’ve set up an online forum for questions and answers, and have put in place an advisory board of independent security experts to work with the community for the better growth and evolution of the framework as it’s used outside of Verizon.

We truly believe that together, we can begin to make a real difference, and it is our hope that this “common language” will be the first step towards creating an era of shared knowledge and collaboration for our industry.

Wade Baker, Alex Hutton and Chris Porter will present at Mini-Metricon 4.5  on 2010-03-01.

At the RSA Conference, in chronological order:

On Tuesday 2010-03-02:

Alex Hutton will be on a panel: Meet the Wizards: Behind the Industry Threat Reports, Session SIP-106  (Orange 307 @ 1:00 PM)

Wade Baker will present Evidence-Based Security: An Alternative To Hunches And Hype, Session GRC-108 (Green 133 @ 3:40 PM)

On Wednesday 2010-03-03:

Charles Spallitta will be on a panel: SaaS-Based Security Solutions, Session BUS-202 (Orange 302 @ 9:10 AM)

Marcus Sachs will be on the next panel: Proving the Worth of Security Metrics with Real-World Data Session BUS-203 (also in Orange 302 @ 10:40 AM)

On Thursday 2010-03-04:

Marcus Sachs will be on a panel: Social Networking — Your Personal and Business Information in the Wild Session EXP-303 (Blue 103 @ 10:40 AM)

A team of professionals from Verizon Business Security Solutions will be staffing Booth 2217 on the Expo floor. We welcome you to attend.

• Increased incidents of reputation attacks (Human Factors)
• Increased JavaScript Exploits
• Increased IPv6 vulnerability chatter
• Vulnerability disclosure and exploits in MS Office documents
• Increased exploitation of web sites/web apps that offer up 3rd party content that can be scripted or include code that executes on the visitor’s system
• Fourth age worm attack
• (New) Exploitation of Barnacleware: Bundled and Helper software and utilities. Software that is installed by the OEM or is picked up through routine usage but is not supported. Examples: quick launch buttons, acceleration, quicktime, adobe, realplayer, webex, zip etc…

Our concern was based not only on vulnerabilities in these products appearing more frequently, but more in the following beliefs:

• These applications are everywhere, on virtually all systems
• These applications are often installed for the user, so the user may not even know they’re there or that they need to be maintained/patched/updated
• Most, if not all, have no automatic (no user interaction) update mechanism

We felt this was forming a perfect storm. Largely unknown applications sitting on peoples’ machines, vulnerable for extended periods of time. As it turned out, we weren’t wrong. Throughout 2008 and 2009 we saw a distinct shift from attacks against the operating system to attacks against the applications, particularly barnacleware.

As the vulnerabilities in Adobe Acrobat Reader were announced, or attacked before being announced, we noticed a recurring trend that we felt was disturbing. The trend was, and still is, that Adobe isn’t the one discovering the majority of the vulnerabilities in Acrobat Reader. Third party security researchers, or criminals, have been the source for all but a couple of security vulnerabilities Adobe has patched in Acrobat Reader from what we can see. Couple this with the announcement from Scansafe that their analysis shows that criminally-crafted PDF exploits accounted for 80% of all exploits via the web in the fourth quarter of 2009.

What we didn’t expect in 2007 when we first made our prediction was that any one piece of barnacleware would be so abused without the product’s vendor taking distinct action to resolve the problems. You may remember that Microsoft shut down development of Windows Vista in order to take a serious stab at addressing the vulnerabilities in Windows XP, resulting in Windows XP SP2 which did make a big difference in the security of the operating system. In Adobe’s case, however, we have seen continual bloating of Acrobat Reader with new features and a significant increase in code base. What we haven’t seen is a new updating mechanism, one which ensures Acrobat Reader stays up-to-date without significant user interaction. Also, advice from Adobe on how to turn off Javascript completely was lacking until late 2009. When it did arrive it was via third party supporters who offered registry hacks that would achieve the goal. Even today, Adobe’s own link for “Managing JavaScript Execution in the Acrobat Family of Products ” is broken. In May 2009 Adobe introduced new functionality to restrict Javascript, allowing for the blacklisting of specific Javascript APIs. While extremely granular, it remains to be seen whether it is effective since the vulnerable APIs are not blacklisted until Adobe finds out they are vulnerable, unless the user is in an enterprise environment where Enterprise Administrators could establish their own blacklist. This certainly seems to be in line with Adobe not discovering vulnerabilities themselves, giving users the ability to disable functionality without relying on an update from Adobe.

There are numerous alternatives for reading PDF documents and we believe that you should consider whether you can deploy an alternative in your environment. We believe that the vast majority of PDF viewers do not need all of the functionality that Acrobat Reader offers, and so could be productive with an alternative. If you can find a way to get some or all of your users using an alternative, it will significantly reduce the attack surface of your enterprise. While appreciating that replacing Acrobat Reader is no small task, we do recommend you consider the risk reduction possibilities.

Finally, here is our current list of predictions:

• Increased incidents of health record compromise resulting from implementation of HITECH Act in the ARRA
• Increased targeting of EHR due to activism opposed to the health care reform debate
• A new and improved security infrastructure purposed for defending the enterprise from social networking risks
• Adoption of Business Intelligence platforms for security intelligence extraction
• High-profile financial services firm attacked through their web site
• The tipping point is imminent or has been reached for risk to mobile devices and enterprise policy will be compelled to mitigate it with controls and products, for example: anti-virus, secure “wallets,” device and application controls, etc

Benefits of Mapping and Measuring Cybercrime

There are numerous personal, organizational, national, and societal benefits to be gained from mapping and measuring cybercrime. In the broadest sense, these benefits can be summed up through the simple axiom “measurement enables management.” However, the last few decades suggest that the security community is prone to jump to management while bypassing measurement. Many checklists, standards, policies, and regulations have been created to manage cybercrime while there have been relatively few attempts to justify or validate their effectiveness. In fact, many do not even reference the need or means to do so. If we cannot reliably measure cybercrime, our efforts to manage it will be inefficient at best and ineffective (or perhaps even counterproductive) at worst.

Challenges of Mapping and Measuring Cybercrime

As is the case with most worthy endeavors, the challenges involved with mapping and measuring cybercrime are commensurate with the benefits. The question of which challenges are most fundamental or critical largely depends upon one’s area of experience. To my mind, the primary challenge plaguing efforts to manage cybercrime is a lack of data. We (whether we be nations, organizations, or individuals) do not have data of sufficient quality or quantity to make informed decisions or take justified action to manage cybercrime.  This state of being is well described by Galbraith’s definition of uncertainty  as “the difference between the amount of information required to perform the task and the amount of information already possessed by the organization.”

Removing uncertainty involves shrinking the gap between what we know and what we need to know. This is accomplished through the collection and analysis of data – a.k.a., measurement. There are many challenges inherent to this process as it relates to cybercrime. Key among them are:

1. Reducing equivocality

2. Ensuring reliability

3. Increasing accessibility

Equivocality refers to the existence of ambiguity, conflicting interpretations, and lack of understanding. While on the surface it may seem strange to apply this term to cybercrime, it is perhaps more appropriate than one might initially suspect. For instance, I have on several occasions conducted a test in which I ask the audience to name the top 5 cyber threats to their organization. The answers I receive range from “insiders” to “targeted malware” to “application vulnerabilities” to “loss of intellectual property” to “brand damage.” As one may or may not recognize, these responses are not all threats. This example may seem pedantic but the point is that it is difficult to measure things if we do not know (or cannot agree upon) what those things are. As it relates to measuring cybercrime, equivocality is manifested most noticeably in the lack of a commonly accepted taxonomy. We are either paralyzed because we are not sure what to measure or we cannot use measurements that do exist because they are based upon an incompatible or inadequate system of classification.

Reliability is a key challenge to mapping and measuring cybercrime on many levels. While equivocality stems from confusion about what to measure, reliability concerns how to measure. If cybercrime data are unreliable, any policies, plans, and procedures based upon them will be unreliable as well. Measurements must be accurate. They should be taken using sound methods. They need to be representative of and applicable to entities that will utilize them. Historically, the security community has not consistently provided measurements with these (and other) important characteristics. As a result, we know far less than we should and believe far more than we ought. I like to say we have more dogma than data.

Accessibility requires that data be shared, aggregated, suitably formatted, usable, and readily available to interested parties. There are many roadblocks to this, evidenced by the long-standing dearth of public repositories of cybercrime data. In addition to the technical challenges that exist, legal and privacy concerns keep many from reporting and sharing data. Those that do tend to do so under compulsion and provide only the minimum required. Similar issues dissuade others from collecting and distributing data. The pervasive mentality promotes secrecy and shame rather than constructive and cooperative learning from our mistakes. This current of ignorance is extremely detrimental. Few incentives exist to overcome these obstacles.

Recommendations for Mapping and Measuring Cybercrime

There are many ways the security community (or any given entity) can begin addressing these challenges. The following recommendations are based upon my experience analyzing cybercrime cases over the last several years with Verizon. Though I draw repeatedly from this well in the paragraphs below, I believe the recommendations have broad application to the topic at hand.

Define scope. “Mapping and measuring cybercrime” is a large, complex, and lengthy task that could easily become overwhelming. Identifying what to measure and focusing on the essential will help ensure that related efforts produce useful and timely results. For instance, my team at Verizon has the responsibility of collecting data “relevant to better understanding and managing information risk” (no small task). To aid these activities, we created a list of intelligence types pertinent to that goal.

Develop a taxonomy. Once the scope of mapping and measuring cybercrime is indentified, the next logical step is to create (or adopt) a method of organizing and classifying what is to be measured. Creating good taxonomies is difficult; getting them widely accepted (especially in the security community) is perhaps more so. Regardless of the difficulty, it is crucial to reducing equivocality and obtaining useful cybercrime data. Having identified ‘threat frequency’ as relevant to our goals, the RISK Intelligence team spent years developing a classification framework. Our Data Breach Investigations Report is based upon portions of this taxonomy. In hopes that others will find it helpful (and to allow comparison to our published findings), we will release it for free public use in early 2010.

Select methodology. With a sound framework in place, one should consider how measurements are to be reliably taken. In general, the security community does not have a good track record here. We take lots of measurements, waive around numbers, and assume we’re learning something from them. This is often not the case and carefully evaluating methodologies should have higher priority. To be clear, there is no such thing as “one measurement to rule them all.” There are many potential and valid methods depending on what is being measured and how it will be used. Continuing with the example discussed above, there are quite a few options for measuring ‘threat frequency’. Recording internal incidents is a good start as is utilizing reports of external incidents. Sensors can provide useful attack data. “After Action Reports” based on penetration tests, security audits, etc. are a valuable source of threat trends. Surveys can capture the experiences and insights of others. We use all these and more (with varying degrees of success) in our research at Verizon. As a further example, one may wish to read the methodology section in the 2008 Data Breach Investigations Report.

Collect data. This recommendation is fairly obvious but it must be mentioned. Effort spent on the previous steps will reap benefits here. If possible, measurements should be collected from a wide variety of sources, aggregated, analyzed, correlated, and checked for reliability. My personal opinion is that the actual process of measurement has not been as much of a roadblock to useful cybercrime data as have some of the challenges discussed elsewhere in this document.

Distribute findings. This is critical. Historically, the tendency has been to hold back data (or restrict it) rather than give it to others who might benefit from it. This is understandable and there is nothing inherently wrong with this strategy; data are a valuable commodity and can be a differentiator. However, when information is not distributed, ignorance reigns. I would like to submit that private organizations could freely share cybercrime data while still retaining competitive advantage and incurring financial benefits. Public entities that encourage responsible sharing of cybercrime data (in various ways) will do a good service to their constituents.

Encourage participation. The recommendations outlined above will achieve greater benefit with wider implementation. Governments, consortia, organizations, and institutions can encourage the collection and sharing of cybercrime data among their respective communities. Here I am specifically referring to a communally beneficial and cooperative effort to share experiences, data, and lessons learned rather than mandatory reporting of events (the latter is another matter entirely and has positively contributed to what we know of cybercrime in recent years). Incentive structures for such collaboration need not be elaborate; access to data can be its own reward.  Lessening the risk of participation (i.e., removing legal action) will help greatly as well.

The production of the DBIR has been driven by our desire to help solve what we see as two of the most significant problems facing our industry:

1. Uncertainty due to the lack of data
2. Equivocality due to the lack of a common framework

Basically, we believe that until we can all be on the same page regarding what terms mean and why those terms are useful, we’re going to have a problem creating meaning from any data we *do* get.

One of the reasons we feel that the DBIR is so useful is because it translates the incident narrative (the attacker did this, then that, then the other thing) into a data set.  To accomplish this translation, we used a set of metrics developed internally. Think of it as a framework of incident elements we believe will, when gathered consistently, help people better interpret data and manage risk.

Today we’re making a version of that framework, the Verizon Incident Sharing Framework (VerIS), available for you to use.

In the document that  you can download here, you’ll find the first release of the VerIS framework.  You can also find a shorter executive summary here.  Our goal for our customers, friends, and anyone responsible for incident response, is to be able to create data sets that can be used and compared because of their commonality.  Together, we can work to eliminate both equivocality and uncertainty, and help defend the organizations we serve.

We hope that you’ll use and even take an active interest in the VerIS Framework.  To that extent, we’ve set up an online forum for questions and answers, and have put in place an advisory board of independent security experts to work with the community for the better growth and evolution of the framework as it’s used outside of Verizon.

We truly believe that together, we can begin to make a real difference, and it is our hope that this “common language” will be the first step towards creating an era of shared knowledge and collaboration for our industry.

A week or so ago, we posted a quick heads up about the UK Security Breach Investigations Report. Although several others have been released since then (Mandiant and Trustwave), this one is particularly interesting for comparison to our DBIR because it focuses on breaches in the UK (Note – the DBIR caseload has a US-based majority but a sizeable (growing) number of European (and other global) breaches). Although we often hear comments that suggest that breaches in the US are radically different and thus not comparable to those elsewhere, this report seems to suggest otherwise. The following is a high-level comparison of DBIR findings to the 7Safe report from the UK.

As an FYI, the scope of the 7Safe report is 62 cases over a time period of the last 18 months.

It would appear that their sample skews more toward smaller businesses than does the DBIR.

The top 2 industries breached in the 7Safe report were Retail (69%) and Finance (7%). The 2009 DBIR shows the same order with different percentages (31% retail and 30% financial services).

The 7Safe report uses classifications for breach source that are very similar to the DBIR.  It also shows remarkably similar results. Both reports rank external attacks as most common (7Safe 80%, DBIR 74%), followed by partner (7Safe 18%, DBIR 32%), and internal attacks being last (7Safe 2%, DBIR 20%).  It’s worth noting that this is not the first non-DBIR dataset that shows similar findings (see the comparison to DatalossDB in the appendix of our 2009 Supplemental DBIR).

The comparison of the origin of attack is a bit difficult since the DBIR lists regions and they provide specific countries. The reports show both similarities and differences. As might be expected, 7Safe showed a larger percentage of attacks from Western Europe. Both report a sizeable proportion of attacks from North America (USA was #1 in the UK report). The most noteworthy differences are that the 7Safe report lists a much larger percentage of attacks from Southeast Asia (Vietnam + Singapore + Indonesia) than the DBIR (3/90 breaches) and total absence of attacks originating from East Asia (ie, China).

The most common methods of intrusion look familiar. We’ve heard changing default passwords is key.

The 7Safe report has a slightly different scale of measuring attack difficulty but it seems clear that like the US, the majority of attacks are not complicated. 27% rated as “sophisticated” compared to the 17% of attacks rated “highly difficult” in the DBIR.

It’s rather amazing that the top 5 non-compliant PCI DSS requirements from 7Safe are the exact same as the top five in our caseload. Given the odds of that happening (pick the same 5 from a sample of 12), there’s probably a lesson to pay attention to here.

Both sets have the majority of data breached at less than 100K.  There are fewer cases in the 7Safe findings that are greater than 100K (14%), but there are some.

We like that 7Safe includes what environment the data resided or where it was stored or processed. 46% of breached assets were in a shared hosting environment, 43% in a dedicated hosting environment and 11% in an internal office environment. As of last year, we started tracking the same metric and it will be included in the 2010 DBIR.

To wrap up, it is interesting how similar most of the findings are across the pond to what we see in our own back yard. Modern business does not really respect national boundaries and it seems that modern criminals don’t either. Our report, along with 7Safe’s and others, are important to remind organizations that we all face a common enemy who often uses similar weapons against us. This sharing of what we learn is critical to our collective ability to protect the interests and assets of our organizations.

These reports, which were published by Trustwave and Mandiant, both appear to be well done and are certainly worth a read. We have heard about similar reports being published in the past by Trustwave, and have actually requested copies. We are glad to finally get our hands on one. Let’s hope that this trend will lead to greater information sharing in the Security field in the future.