Hey all – Mike Reavey here. I’ve been with the Microsoft Security Response Center (MSRC) for over five years now, and working in security for over a decade. One of the reasons I’m truly passionate about this type of work is that it’s always changing, and very exciting.
However, in some ways the security ecosystem is a very predictable place.
For example, I can almost guarantee we’ll see a lot of charts at Black Hat with arrows going “up” showing that things are still rough in the security space. And in fact, if you read George’s thoughts in a ZDNet guest editorial you’ll see things are going “up” in a lot of areas.
One other predictable activity is that following every 2nd Tuesday, after we’ve released our security updates, there’s a community of folks reverse engineering our updates and creating exploit code. Consequently, another very predictable activity is that customers always ask us which of the vulnerabilities we’ve fixed have had exploit code released each month. That’s a key factor in their risk assessment.
When we reviewed why they asked that question, one thing we realized is that not every vulnerability we release updates for has functional exploit code created. And that’s in the face of very competent people like those behind tools like Metasploit, Immunity CANVAS and Core’s IMPACT – who have systems and people geared up to produce exploit code every time we release updates.
When doing the math, roughly 30 percent of the vulnerabilities we fix each year have exploit code released. You can see more details on this analysis in the SIR (www.microsoft.com/sir). There’s a lot of reasons it’s not at 100 percent – some just aren’t interesting from an attacker’s or a pen tester’s perspective, and others only affect products that have low penetration, but some are more challenging to exploit given the way the vulnerability manifests itself. For example, a defense in depth approach may make a particular vulnerability especially hard to exploit consistently, maybe /GS causes the process to crash without any data aside from the /GS cookie being overwritten, or maybe it’s just an area of code where the system memory isn’t structured in a reliable way to gain execution.
This morning, we’ve announced an “Exploitability Index.” The Microsoft Exploitability Index is designed to provide additional information to help customers better prioritize the deployment of Microsoft security updates. This Index will provide customers with guidance on the likelihood of functional exploit being developed for vulnerabilities addressed by Microsoft security updates.
This index will attempt to predict if a vulnerability is likely to have functioning exploit code released, or have inconsistent exploit code released that wouldn’t work every time an attacker attempted to used it. We’ll even highlight vulnerabilities where we think it’s unlikely that functioning exploit code will ever be released.
The first question I get when I talk about this is, “How are you going to make this assessment? “
Well, first we’ll review our understanding of the vulnerability and what it would take to exploit it with folks like our Security Vulnerability Research & Defense (SVRD) team as part of our standard MSRC process. Second, we’re also incorporating the same methodologies we’ve seen used in the community for years – some of these we’ve even had presented at our own conference, BlueHat, by folks like Halvar Flake and Lurene Greenier. And third, since, as Steve says, “it takes a village” to raise a healthy security ecosystem, we’re asking members of the Microsoft Active Protections Program to also review the vulnerabilities to check our work before we release the index each month.
Bottom line… we are giving customers more information to help their risk assessment, and that, we think, is a good thing. And a very reasonable request, given the security ecosystem’s emerging shift towards more collaboration.
I’ll be talking more about this and other Black Hat happenings at my Twitter feed: www.twitter.com\mreavey
– Mike Reavey
*Postings are provided “AS IS” with no warranties, and confers no rights.*