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-0360
Published: 2014-04-23
Memory leak in Cisco IOS before 15.1(1)SY, when IKEv2 debugging is enabled, allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCtn22376.

CVE-2012-1317
Published: 2014-04-23
The multicast implementation in Cisco IOS before 15.1(1)SY allows remote attackers to cause a denial of service (Route Processor crash) by sending packets at a high rate, aka Bug ID CSCts37717.

CVE-2012-1366
Published: 2014-04-23
Cisco IOS before 15.1(1)SY on ASR 1000 devices, when Multicast Listener Discovery (MLD) tracking is enabled for IPv6, allows remote attackers to cause a denial of service (device reload) via crafted MLD packets, aka Bug ID CSCtz28544.

CVE-2012-3062
Published: 2014-04-23
Cisco IOS before 15.1(1)SY, when Multicast Listener Discovery (MLD) snooping is enabled, allows remote attackers to cause a denial of service (CPU consumption or device crash) via MLD packets on a network that contains many IPv6 hosts, aka Bug ID CSCtr88193.

CVE-2012-3918
Published: 2014-04-23
Cisco IOS before 15.3(1)T on Cisco 2900 devices, when a VWIC2-2MFT-T1/E1 card is configured for TDM/HDLC mode, allows remote attackers to cause a denial of service (serial-interface outage) via certain Frame Relay traffic, aka Bug ID CSCub13317.

Best of the Web