Embracing the “Presumption of Breach” Doctrine With Rapid Detection and Response

I came across a term last week in a very good article about the virus attack on the USAF Drone command systems (“Dronegate: the First Casualty is our CyberSecurity Paradigm” by CTOVision.com).  The term was simply “Presumption of Breach”, and for me it really summarized the doctrine that organizations and government agencies must adopt in the face of todays IT security environment.  The doctrine is simple: You must assume you have been breached, have tools in place to detect those breaches that evade your shields, and have a plan to respond when such breaches are detected.  I call that Rapid Detection and Response.

The first step in the process – assuming you have been breached – sounds simple, but for many organizations it is the hardest party of adopting the “Presumption of Breach” doctrine.  It is far more comforting to have 100% faith that your shields will protect your systems without fail and without regard to the attack or attacker.  The emotional component of admitting that you cannot fully protect your IT systems is an interesting topic and one that I plan to expand in a later post.

In spite of the emotional resistance to assuming that you have been breached, all evidence points to it being the cold hard truth.  Many believe organizations now fall into two categories: those who know they have been breached and those who don’t.  Even if you have not been breached, every statistic and simple reason says you will be.

Once you give yourself over to the “presumption of breach” you will need a tool to help you quickly identify when you are breached.  Here is where I must make the disclaimer that Triumfant is such a tool, so I will have a bias toward the Triumfant approach and capabilities.  Now that my bias is fully exposed I can also say that I have not yet encountered another tool better equipped for rapid detection and response.

Why a separate tool and not some extension of your shield solutions? First, if your shields could have detected the attack they would have prevented the attack. Put another way, the attack happened because it evaded your defenses, so your defenses are obviously not able to perform the detection.  Second, it is always good to have checks and balances by not relying completely on one tool or vendor.  Think about it – how motivated is a shield vendor to provide you a tool that tells you when those shields did not do their job.

The detection tool must work rapidly and be comprehensive in its discovery and analysis of the attack.  Rapid detection enables the organization to contain the damage caused by a long-term infiltration.  The Verizon Business 2011 Data Breach Investigations Report (published May 2011) noted that 60% of the breaches studied in the report went undiscovered for over a month or more.

Comprehensive analysis is necessary to provide the breadth of actionable data needed to respond to the attack.  The recent virus attack on the systems associated with the USAF drone fleet illustrated the problem when attempts to kill the virus were unsuccessful for two weeks or more.  Today’s malware is designed to persist – to survive.  If you just kill the malicious executable, chances are there is a persistence mechanism that will simply resurrect the malware in another place in the machine.  Detection software that does not detect the attack and all of the associated change/damage to the machine will hamper your response and leave the organization at risk.  The same is true for solutions that used pre-written, generic remediations – a one-size-fits-all approach will undoubtedly leave dangerous artifacts.

(Triumfant uses change detection coupled to patented analytics to identify attacks and correlate all of the changes to the victim machine associated with the attack.  This provides a complete picture of the primary and associated collateral damage, and allows Triumfant to build a remediation specific to the attack that repairs all of the damage to the machine.  This includes persistence mechanisms)

Lastly you have to have a plan to respond to these breaches.  Your rapid detection and response tool should have the ability to learn about the attack and use that knowledge to look for other infiltrations throughout your network.  You should have processes in place to correlate the attack data to firewall logs and other security data (perhaps via a SIEM tool) to help identify the source of the attack and ways to block it at the shield level.  You also need to establish reporting channels to make the appropriate people aware of the breach in the event that it becomes public or cause an interruption in services to stakeholders or customers.  In other words, do the opposite of how Sony handled their PS3 breaches.

Putting the “Presumption of Breach” doctrine into practice is not an admission of failure or some IT security nihilism.  It is a sound and pragmatic recognition of the environment in which we operate.  It also means that your organization faces the inevitable prepared with a plan to minimize the impact of any attacks that gets past your shields.