If We Know How Breaches Happen, Then Why Aren’t We Doing Something?

In his August 26 blog post on the Securosis Blog called “We Know How Breaches Happen”, Rich Mogull made some very good observations about the cause of data breaches. According to Mogull:

“If we look across all our sources, we see a consistent picture emerging. The vast majority of cybercrime still seems to take advantage of known vulnerabilities that are can be addressed using common practices. The Verizon report certainly calls out unpatched systems, configuration errors, and default passwords as the most common breach sources.”

When I was with Cybertrust, Peter Tippett, one of the early pioneers in antivirus software now with Verizon Business, would make the impassioned case (he still is) that following a relatively small number of essential practices would lower an organization’s risk significantly.  Tippett’s researchers from Cybertrust are at the core of the Verizon team that publish the Verizon Data Breach Investigations Report which notes that “2008 continued a downward trend in attacks that exploit patchable vulnerabilities versus those that exploit configuration weaknesses or functionality.”

In other words, a little discipline in security configuration management would go a long way toward making organizations more secure and eliminating the low hanging fruit used by hackers.  Hackers are people too, and like the rest of us they will take the path of least resistance.  They could choose the difficult path of engineering a new zero day attack. Or they could take the far more simple approach of using an exploit that leverages a common misconfiguration known to exist in a significant number of endpoint machines and build an attack with enough variation to evade the signatures in place for earlier versions of that attack. 

You can almost picture a Glengarry Glen Ross hacker’s boiler room full of hackers under quota and a boss telling the crew that “Coffee is for hackers that Hack!”  It is just too simple to spin up an exploit that picks off the multitude of unpatched and misconfigured endpoints.

In a separate post, Mogull talks about the Data Breach Triangle in the context of fire triangle (oxygen, heat, fuel – take away any one of the three and the fire goes out): the sides of the triangle are the three components needed for a breach to occur, so removing any one side prevents the breach.  Good security configuration management should help eliminate the triangle side Mogull calls the exploit, which is the vulnerability or flaw that provides the hacker the path to the data.

Given the obvious linkage between breaches and configuration problems, why hasn’t security configuration management become an essential component of endpoint security strategies?  The answer is steeped in irony given that configuration management has replaced patchable vulnerabilities as the exploit of choice.  Many of the companies that offer security configuration management use what are essentially patch management tools as the technical implementation.  Think of the number of patch management vendors that now offer security configuration management. These solutions essentially push out configurations and remediations the same way that they would push out a patch. 

Why is his ironic? While this is a proven and technically sound approach, patching is somewhat universally recognized as problematic.  It is therefore sensible and logical to ask why we would expect that using the same type of tool and underlying processes would prove to be successful in addressing configuration management.  Patching tends to be a brute force process, while configuration management requires much more flexibility and finesse.  And creating a patch (call it any name the vendor gives it – it is still a patch) is a human resource intensive process that requires someone to write, test and deploy a script.  

It would be fair of the patch management vendors to note that a lack of institutional commitment and sound process are also contributing factors and I would agree.  But the parallel between patch management and configuration management is too obvious to ignore.  Mogull’s observations are backed by numerous studies and analysis that cite unpatched systems and security configurations errors as a problem, so the evidence would indicate that these tools are not getting the job done. 

Clearly a different and more automated approach is appropriate, and in my next post I will tell you how Triumfant addresses this problem.  Specifically, I will detail how Triumfant continuously enforces security configurations by detecting machines that are out of compliance with desired configurations and automatically build a remediation to return the machine to compliance.

What is clear is that we need to address these foundational problems to become more secure and reduce organizational risk.  Perhaps now the tools have caught up with the problem and we can make the road of that hacker a bit more difficult.