Vulnerabilities / Threats
6/28/2013
11:52 AM
Mike Rothman
Mike Rothman
Commentary
Connect Directly
RSS
E-Mail
50%
50%
Repost This

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
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-3946
Published: 2014-04-24
Cisco IOS before 15.3(2)S allows remote attackers to bypass interface ACL restrictions in opportunistic circumstances by sending IPv6 packets in an unspecified scenario in which expected packet drops do not occur for "a small percentage" of the packets, aka Bug ID CSCty73682.

CVE-2012-5723
Published: 2014-04-24
Cisco ASR 1000 devices with software before 3.8S, when BDI routing is enabled, allow remote attackers to cause a denial of service (device reload) via crafted (1) broadcast or (2) multicast ICMP packets with fragmentation, aka Bug ID CSCub55948.

CVE-2013-6738
Published: 2014-04-24
Cross-site scripting (XSS) vulnerability in IBM SmartCloud Analytics Log Analysis 1.1 and 1.2 before 1.2.0.0-CSI-SCALA-IF0003 allows remote attackers to inject arbitrary web script or HTML via an invalid query parameter in a response from an OAuth authorization endpoint.

CVE-2014-0188
Published: 2014-04-24
The openshift-origin-broker in Red Hat OpenShift Enterprise 2.0.5, 1.2.7, and earlier does not properly handle authentication requests from the remote-user auth plugin, which allows remote attackers to bypass authentication and impersonate arbitrary users via the X-Remote-User header in a request to...

CVE-2014-2391
Published: 2014-04-24
The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

Best of the Web