Vulnerabilities / Threats
6/28/2013
11:52 AM
Mike Rothman
Mike Rothman
Commentary
50%
50%

The (Attack) Path To Prioritization

Since you can't fix every vulnerability, you need to prioritize what needs to get done now and what doesn't. Using attack path data can help

When I want to troll during a speaking gig, I'll usually ask how many folks in the crowd get through their to-do lists every day. I get some uncomfortable laughter, but almost no one raises a hand (except the one numbnut in the crowd who's usually between jobs). Suffice it to say that no one doing security can get everything done. Not consistently, anyway. There are too many users clicking on too many links -- too many applications to protect and too many adversaries with too many attack vectors to think you can protect everything.

So your key to security success is to prioritize fiercely. You have to choose wisely about what really needs to get done now and what can wait for the next Ice Age since you'll never get to it. Our security management tools aren't helping, either. Your vulnerability scanner is happy to tell you that you have thousands of things to fix. As shown in Krebs' great post on the FIS breach, those folks had more than 18,000 network vulnerabilities and 291 application vulnerability past due.

Yeah, no one is getting through 18,000 vulns. Ever. You may as well turn the data center into a parking lot. But we know that not all of those 18,000 vulnerabilities represent real risks to the organization. And your job is to figure out which 100 or 200 you can fix in a reasonable time frame. An interesting way to evaluate the real "risk" is to figure out what can be accessed by an adversary, since any vulnerabilities on those devices are in play.

That brings us to the concept of attack paths. You start by spending a little bit of time determining what would be attractive targets for the attacker. I'm talking about your private customer data, your organization's intellectual property, or the photos you have of the CEO. (I think I'm kidding about that last one). Once you know what's important, you need to figure out whether an adversary can get to it and how. Even if a device is vulnerable to some kind of attack, if the adversary can't get to it, then it's not really a risk, right? So attack path becomes another attribute to determine the criticality of each vulnerability.

The problem is that you can't determine attack paths on the back of an envelope. In any network of scale, you are talking about millions of ways to get from point A to point B. To fully understand your security posture, you need to evaluate each of those paths to determine whether proper controls are in place to protect the data on those devices. This requires highly optimized algorithms (yay for math!) to factor all of this data, and it's not like you network is static. So with every new connection and every changed route, your attack paths change. The good news is that we're starting to see new offerings -- kind of like network topology tools on steroids -- that can do this math and give you an idea about which devices are exposed at any given time.

Of course, we all know that attackers tend to take an indirect path to your sensitive stuff. They compromise an interim device to gain a foothold and then move laterally through your environment until they get what they are looking for. Yeah, that complicates the math further. If it were easy, everyone would be doing it.

But of all the means to help understand your priorities, evaluating every vulnerability and/or configuration problem through the prism of an attack path is a good means to figure out what needs to get done right now and what doesn't. Mike's bold perspectives and irreverent style are invaluable as companies determine effective strategies to grapple with the dynamic security threatscape. Mike specializes in the sexy aspects of security, like protecting networks and endpoints, security management, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6501
Published: 2015-03-30
The default soap.wsdl_cache_dir setting in (1) php.ini-production and (2) php.ini-development in PHP through 5.6.7 specifies the /tmp directory, which makes it easier for local users to conduct WSDL injection attacks by creating a file under /tmp with a predictable filename that is used by the get_s...

CVE-2014-9652
Published: 2015-03-30
The mconvert function in softmagic.c in file before 5.21, as used in the Fileinfo component in PHP before 5.4.37, 5.5.x before 5.5.21, and 5.6.x before 5.6.5, does not properly handle a certain string-length field during a copy of a truncated version of a Pascal string, which might allow remote atta...

CVE-2014-9653
Published: 2015-03-30
readelf.c in file before 5.22, as used in the Fileinfo component in PHP before 5.4.37, 5.5.x before 5.5.21, and 5.6.x before 5.6.5, does not consider that pread calls sometimes read only a subset of the available data, which allows remote attackers to cause a denial of service (uninitialized memory ...

CVE-2014-9705
Published: 2015-03-30
Heap-based buffer overflow in the enchant_broker_request_dict function in ext/enchant/enchant.c in PHP before 5.4.38, 5.5.x before 5.5.22, and 5.6.x before 5.6.6 allows remote attackers to execute arbitrary code via vectors that trigger creation of multiple dictionaries.

CVE-2014-9709
Published: 2015-03-30
The GetCode_ function in gd_gif_in.c in GD 2.1.1 and earlier, as used in PHP before 5.5.21 and 5.6.x before 5.6.5, allows remote attackers to cause a denial of service (buffer over-read and application crash) via a crafted GIF image that is improperly handled by the gdImageCreateFromGif function.

Dark Reading Radio
Archived Dark Reading Radio
Good hackers--aka security researchers--are worried about the possible legal and professional ramifications of President Obama's new proposed crackdown on cyber criminals.