The Blog Inspired By The Book
The Telegraph reports:
More than half of all Britons have been injured by biscuits ranging from scalding from hot tea or coffee while dunking or breaking a tooth eating during a morning tea break, a survey has revealed.
Who knew that cookies could be so dangerous? So forget worrying about AV or even seat belts, skip the carbs….
[Image from the original article]
Todays New York Times has an interesting article “A Lawsuit Tries to Get at Hackers Through the Banks They Attack” about the folks over at Unspam who are suing under the Can-Spam Act in an attempt to get the names of miscreants who have been attacking banks. More interestingly, they are hoping to force the several banks they suing to cough up information about the nature of the attacks and who was attacked. They hope to use this data to get a better idea of how this attacks are occurring and who is perpetrating them. While I have some concerns about this approach, it is without a doubt an interesting way to go about getting the data. Now we get to sit back and see how hard the banks fight back. Time to get out the popcorn, this will definitely be interesting.
There’s been lots of discussion here and elsewhere about what’s wrong with GRC as a market and that discussion is pretty spot on. However, last week, I was chatting with Alex and it suddenly hit me that while GRC doesn’t work, the very concept is even more broken then we had previously thought. I briefly mentioned this last week on twitter, and promised a more complete breakdown this week so here we go:
First off, it’s not about governance, risk and compliance, but rather about compliance, governance and audit with risk being both an informer and product of the Compliance, Governance, Audit (CGA) process. So once again we have one of Andy Jaquith’s Hamster Wheels of Pain, with risk as an externality.
[Pretend I put a fancy graph with arrows here]
First off, you have a perceived risk, that risk might be the fear of government legislation in your space (hence the creation of pci), it might be something bad happening to a competitor (lead paint on children’s toys) or anything else really. The result of that perceived risk is some sort of compliance demand, which may be formal like PCI, SOX, HIPAA or informal, the CEO declares iPods verboten and every employee must carry a zune for instance. In other words, compliance is just a declared requirement to do (or not do) something. To totally abuse a metaphor, this kind of sounds like the legislative branch of the government.
Secondly, the compliance requirements drive governance requirements. Governance is just a sexy word for enforcement of compliance. In other words, governance is the series of controls and processes you will use to ensure that the compliance need is being met. To continue the metaphor abuse, this more or less maps to the executive branch.
Finally, we have audit. Audit is in the simplest terms, the group that interprets the compliance requirements and then takes those interpretations and applies them to what the governance group did. Sounds a lot like what the courts do (minus the ability to declare certain compliance requirements as null and void).
As the cycle rotates, we have a new state of being which changes both the real and perceived risk states. This new perception drives changes to compliance. Which drives changes to governance which drives changes to audit. Lather, rinse, repeat.
The net result of this that (once again), it’s really about risk, even when you don’t think it is.
Following up on my previous post, here’s Part 2, “The Factors that Drive Probable Use”. This is the meat of our model. Follow up posts will dig deeper into Parts 1 and 2. At Black Hat we’ll be applying this model to the vulnerabilities that are going to be released at the show.
But before we do our digging, two quick things about this model and post. First, the model is a “knowledge” model (that’s a term Alex just made up, btw to describe the difference between Bayesian and Frequentist approaches to statistical analytics). It actually measures state of knowledge rather than state of nature. That means that this is not a probabilistic model that attempts to try to fill in a number count for some amount of population (how many people expect traditional statistical analysis to work), rather this model measures a degree of belief. Second, the reason we did this was twofold – 1.) establishing accurate information around rate of adoption for what we want to study is difficult, 2.) If we get to the point where we *can* measure rate of adoption in the wild, there’s a proof that a strong knowledge model actually can never be worse than a frequentist model, and that sort of data will only increase the accuracy of the knowledge model results.
Finally, we’re using this model with “exploit code” in this post to describe how much we believe a specific exploit will be used by the aggregate threat community. If you recall the gartner hype cycle graph, it is an attempt to identify and “measure” the factors that drive the curve of “adoption”. It should be noted that this model might work well for not just describing a belief that exploit code will be well adopted, but also that a given weakness (what is commonly referred to as a vulnerability) will have exploit code developed for it. The authors intend to play with this model for both purposes.
On To The Model: The Mortman/Hutton Model for Expectation of Exploit Use
So here it is:
In this model, essentially, two significant factors begin to determine the fate of the exploit code. First, to understate the simplicity of the real world factors that drive exploit adoption, the exploit must be useful. And in order to be useful, the exploit would need to have valuable systems to penetrate, and people to use it. We break these two factors of usefulness down into two concepts: Saturation of Vulnerable Technology and Exploit Utility.
Saturation of Vulnerable Technology (SVT)
If an exploit is going to be developed or used, there actually need to be systems to attack. Saturation of Vulnerable Technology (SVT) reflects that requirement. SVT itself represents the aggregate amount of vulnerable systems, and is driven by two main factors. The number of vulnerable systems is determined by how significant the market penetration is for the technology (Windows = a lot, BeOS = a little), and the ability to compensate for the vulnerability. This ability to compensate is broken down into two sub-elements, the ability to repair (patch the system, for example) and/or the ability to apply compensating controls.
The outcome in SVT is “measured” in a number of probable systems without the ability to compensate. It is a combination of the number of systems with the initial vulnerability, and the probable % of the population that is currently vulnerable.
Exploit Utility
If SVT attempts to measure the aggregate attack surface available to the exploit code, then Exploit Utility is an attempt to measure how useful the exploit code is to the aggregate threat community. Exploit Utility is dependent on two factors, if the systems that the exploit will be used on can be expected to return value to the threat community, and how pervasive the exploit code is in the threat community. We call these The Expected Value of Vulnerable Systems (EVoVS) and Probability of Code Dissemination, respectively.
The premise behind the Expected Value of Vulnerable Systems is simply an attempt to suggest that exploit code will only be used if the attacker can expect to gain something from the attack. This value can be expressed in the Information it Offers (in volume and expected market return), the Resources it Offers (in power/space/bandwidth), or the Access it Allows (notably, to other systems). The EVoVS can be measured as a range of value compared to the broader distribution of computing assets available as targets to the broader threat community.
The premise behind the Probability of Code Dissemination is simply an attempt to suggest that the expected amount an exploit is to be used (in aggregate) is a function of how “available” it is. This could simply be stated as a proportion of exploit code inclusion in commonly available toolkit packages. An expected Rate of Exploit Adoption could be said to be dependent on two factors; the ease of use (skills, resources required to use it) and the nature of the exploit author (secretive, non-secretive).
In Conclusion
So there it is. Developed at several different Columbus area coffee shops and lots of chicken wings and beer after work. Now many of us have been privy (or hostage) to discussions around the what and why’s of “some sort of vulnerability/exploit was just announced by research team/vendor”. If anything, hopefully this model will provide a rational basis for coming to a joint conclusion about why we should or shouldn’t care. This model is released under a creative commons attribute-share alike-non-commercial license. That means you have to tell people where you found it, if you mess with it – please give back to the community, and please don’t go charging anyone for the use of it.
I wanted to throw it out here as an example of how you would the model from my earlier post in real life. So let’s take the recently released Internet Explorer security vulnerability and see how it fits. Now this is a pretty brain-dead example and hardly requires a special tool, but I think it illustrates the use quite nicely. As a refresher, the black line indicates the general path of vulnerabilities for a particular technology (in this case it could be browsers, or IE specifically) and the red line indicates the deployment of that technology within an organization. I’ve added arrows to indicate approximately where on the curve this vulnerability fits and where, for just about every organization on the planet, the deployment of IE is.
Looking at the two curves and the placement of the arrows, we can see that, barring other issues, addressing this particular issue should be high priority. In our next post, you’ll see some other issues you may want to take into consideration in order to find the priority of this vulnerability relative to other vulnerabilities you may be facing.
Not much to add, but a good article in Business Week on Lessons from the Data Breach at Heartland. Well worth reading…
Alex and I will be on a panel, A Black Hat Vulnerability Risk Assessment, at this year’s Black Hat. We’ll be discussing the need to perform a risk assessment of vulnerabilities as you become aware of them in a deeper context then just looking at the CVSS scores. Things to consider are what compensating controls may be in place, the value of the data being protected and how likely is it that an? attack will happen and how often it will be successful.
Alex and I have developed a model, The Mortman/Hutton Probabilistic Model of Exploit Use, that we hope will assist with this risk assessment. We’ll be posting portions of the white paper we wrote for Black Hat over the next couple of weeks, as well as updates to the model as it evolves in response to our own research and your feedback. We’d love to hear what you think.
Part 1, ” Background: On Technology Adoption” is below:
Tipping Point v2
Using the pre-supposition that the classic Gartner Hype Cycle curve (above) represents a real model for rate of technology adoption and is applicable to the use of an exploit, the Mortman/Hutton model is an attempt to understand the factors that will “drive the curve”. So if we can say that the Gartner Hype Cycle represents the evolution of vulnerabilities with regards to a particular technology or a portion of that technology, then the first peak is what we see when researchers and/or miscreants first start examining that technology. This represents the low hanging fruit, that was either missed or deemed acceptable risk by the producers. After the initial burst of research, activity generally tapers off for a while based on a number of factors (that can be represented in part by the model). Once the research community gets more comfortable with the technology and has enough time to really start digging into its guts, more exploits start to appear and often they are more damaging or harder to fix. Additionally as you move along the curve, exploits start appearing in Metsploit and similar toolsets and eventually into tools that script kiddies and analysts can use.
If the black line represents activity around a vulnerability/exploit, then the red line represents the deployment of that same technology within organizations. Where the two lines overlap is when things start to get interesting, In the example above, the organization already has a heavy deployment of that technology when the second upswing of vulnerability research has started. As such the shaded area represents the tipping point where the CSO should seriously start worrying about the risk of vulnerabilities within there technology. Similarly, if the overlap is in a different place then a different rsik assessmment will result.
The Mortman/Hutton model attempts to help security professionals understand what will make exploit code “move” from 2 to 3 on the X axis. It is an examination of the factors that drive the probable creation and use of exploit tools.
There was an interesting segement on NPR this morning, “Economy Got You Down? Many Blame Rating Firms” that covered amongst other things the risk model that Standard and Poors used to rate bonds and in specific mortgage backed ones. There are a few choice quotes in the story about how the organizations approached the models in the face of branching out to new classes of customers with whom they had little to no experience:
The new bonds were based on pools of thousands of mortgages. If you bought one of these bonds, you were basically loaning money to people for their houses. What the equation tried to predict was how likely the homeowners were to keep making payments.
The system made sense, Raiter says, until loan issuers started offering mortgages to people who didn’t have great credit and in some cases didn’t have a job.
Raiter says there wasn’t a lot of data on these new homebuyers. He says he told his bosses they needed better data and a better model for assessing the riskiness of the loans.
He remembers them telling him, “You’ve got 94 percent market share. You’re not going to get any more if you build a new model.” He adds, “To them it was just a tool. And we were making a lot of money with it. So why change it?”
This is a common theme throughout the story and while S&P claims they changed their models it also appears that they weren’t willing to discuss this in detail with NPR. Assuming this is in fact accurate what we have here is not failure of models, but rather an unwillingness to pay attention to what the models were telling them. What do you think?
The folks over at Voltage have released a really cool interactive map of breaches from around the world. Tools like this show how important having data is, just imagine how much more impressive and useful something like this could be if more people were willing to share data about breaches or other information security issues they are facing.
(via Branden Williams)
Last night, the fine folks at Verizon posted the 2009 version of the DBIR. I haven’t had time to do a full deep dive yet, but I thought I’d share my initial notes in the meantime. Stuff in italics is from the DBIR, regular text is me:
81 percent of organizations subject to PCI DSS had not been found
compliant prior to the breach.
81%? Wow, PCI really is hard. My initial questions was is this an implication that none were actually compliant at the time of the breach? This gets answered later in the report. The short version is “no not really.”
The value associated with selling stolen credit card data have dropped from between $10 and $16 per record in mid-2007 to less than $0.50 per record today.
Is this based on internal data or on some public study?
Results from 600 incidents over five years make a strong case against the long-abiding and deeply held belief that insiders are behind most breaches.
and
The distribution of breach sources in 2008 is presented in Figure 4. (74% external, 20% internal, 32% partner) The results are quite similar to that of the 2004 to 2007 data set and continue to challenge some of the prevailing wisdom in the security community with regard to the origins of data breaches
Real data! This is awesome. Finally something other then the old FBI/CSI survey, may I never see it again on a vendor slide deck. Also I love Figure 5.
Figure 7 is fascinating in that we do see the truth that on average Internal breaches are far more devastating by nearly a factor of 3. However, they are 4 times LESS likely to happen. Really highlights the fact that although the really high profile cases like Hannaford and TJX were public, they are in fact edge cases.
Of all insider cases in 2008, investigators determined about two-thirds were the result of deliberate action and the rest were unintentional.
1/3 of the time don’t attribute to malice that which can be attributed
to human stupidity.
While it’s tempting to infer that administrators acted more deliberately and maliciously than end-users and other employees, the evidence does not support this conclusion. The ratio was roughly equal between them
I haven’t found it yet, but there was apparently a recent NSA/Carnegie Mellon study on insiders that found similar results. Anyone know what this is?
With respect to breaches caused by recently terminated employees, the following two scenarios were observed:
– Employee was terminated and his/her account was not disabled in a timely manner.
– Employee was notified of termination but was allowed to “finish the day” unmonitored and with normal access/privileges.
This encompass all areas of access (decommissioning accounts, disabling privileges, escorting terminated employees, etc.).
This is why those auditors are right to be checking IAM process!
In the large majority of cases, it was the lax security practices of the third party that allowed the attack. It should not come as a surprise that organizations frequently lack measures to provide visibility and accountability for partner-facing systems
Yet more justification to have security provisions in the contracts with cash penalties for failure.
We investigated an entire series of cases in which multiple organizations within the same industry all suffered breaches within a very short timeframe. It didn’t take long to figure out that each used the same third-party vendor to remotely manage their systems. Unfortunately, that vendor neglected to change the default username and password and used the same credentials across multiple clients
It’s the little things that bite you the hardest.
Figure 15: Shared/Default credentials just as likely as SQL injection, both which were an order of magnitude more then buffer overflows and XSS attacks.
More proof that attacks are shifting to where the data is known to be.
Only six confirmed breaches resulted from an attack exploiting a patchable vulnerability.
Were any from 0-days? Also, why bother with things that can be patched when you can use things like SQL-injection and default passwords? Path of least resistance and all.
“Figure 22: Over half the attacks could have been performed by script kiddies or people with even less skill.”
At first glance, this is one of the best justifications for something like PCI. By even raising the bar a little we can reduce the number of incidents. Interestingly, it would not necessarily reduce the overall number of records lost due to the high number of records (95%) falling into the the “high skill” category. I still think it’s worthwhile though. If we an with minimal effort reduce the number of incidents that means more time to focus on the high impact issues in the long run.
The final recommendations from the report:
- Changing default credentials is key
- Avoid shared credentials
- User account review
- Application testing and code review
- Smarter patch management strategies
- Human resources termination procedures
- Enable application logs and monitor them
- Define “suspicious” and “anomalous” (then look for whatever “it” is)
Looks like the basics of a good information security program . However, I do have a couple of nitpicks.
Rec #5. There are other reasons to patch quickly and comprehensively then stopping data loss oriented breaches. So saying that patches can be lower priority is ing somewhat overly focused on one aspect of security. It’d be very interesting to see the numbers of other types of incidents and what the impact of patching is on them.
Recs #7 and #8. I’m a big fan of logging however unless you have the right tools then these are effectively impossible to do. And at this point I think effective log monitoring and traffic analysis is definitely in the realm of
capability of only a select few enterprises. Side thought are orgs that use MSSPs for log monitoring having fewer incidents or at least lower impact incidents versus those that are doing it themselves?
Rec #4. Given the prevelance of SQL injection, it would have been really nice to see a breakdown of whether they SQL injection was in a COTS package or an internally developed one.
What You’ve Said