To Automate or Not to Automate (Incident Response): That Is the Question

The recently published Senate report on the Target breach exposed a dicey situation that is all too familiar to enterprise security professionals.  As it turns out, Target implemented malware detection technology from FireEye which happened to detect the now infamous POS memory scrapping code but the IT team was running FireEye in detection rather than prevention mode.  This meant that Target had to take some manual action to remove the malware and remediate the incident.  Alas, Target did not take this faithful act and the rest is cybercrime history.

To the uninitiated, Target’s behavior seems misguided at best, or even completely incompetent if you take a harder line.  Why wouldn’t Target let FireEye do what it was designed to do and avoid this whole disaster? 

Those of us who live and breathe cybersecurity know that it isn’t so easy  Technologies like anti-malware gateways, IDS/IPS, and SIEM are the software equivalent of the Robot on the 1960s television show, Lost In Space, that constantly warned the exceedingly anxious Dr. Smith about imminent danger.  This is because security technology alerts are often based on a limited or specialized view of the whole IT enchilada.  For example, FireEye looks at packets, sessions, and content flowing across the network, but in its network-based form factor, FireEye can’t tell you about endpoint behavior or historical patterns (Note:  This is one reason why FireEye acquired Mandiant and partners with numerous security technology vendors.  It is also why Cisco, IBM, McAfee, Palo Alto Networks, RSA Security, and Trend Micro have adopted similar strategies). 

Given the limited scope of these alerts, security professionals have been conditioned to take one of two actions:  1) Use the alert as a catalyst that drives a much more thorough investigation, or 2) Note the warning but do nothing.  The former case demands security analytics skills and resources are available as security investigations can be complex and require a lot of manual processes.  In the latter case, security professionals may be waiting for additional alerts, correlation, or threat intelligence before taking action, or they may simply be dismissing the alert as a “false positive.” 

It should be noted that false positives are the bane of security professionals’ existence to be avoided at all cost.  Why?  Imagine an incident where the security team reacts to an alert by blocking systems or cutting off network access for users.  This activity disrupts business operations and may even have an impact on revenue (i.e. when an eCommerce server is taken off the network).  If it is later learned that there actually wasn’t an actual cyber-attack but rather a false positive alert, it’s likely that security professional heads will roll – a worst-case scenario for every security pro. 

CISO false positive phobia is understandable, but the Target event demonstrates that we can’t simply eschew security alerts or even adopt a wait-and-see attitude.  In fact, ESG research indicates that 56% of enterprise organizations (i.e. more than 1,000 employees) already do some type of basic for of automated incident response, like blocking a URL, IP address, or generating an IDS signature based upon a security alert or threat intelligence feed.  A good start but not enough. 

I believe that the state of cybersecurity is at a tipping point.  Cyber threats continue to grow more sophisticated and voluminous, and security professionals simply can’t scale to investigate or even triage the tsunami of current security alerts.  The only way out of this conundrum is the use of more automated incident response technologies.  To achieve this goal, we need help from the supply and demand side:

1.  Cybersecurity vendors must improve the intelligence and data analysis capabilities in their products so that they have a contextual understanding of an organization’s networks, IT assets, users, and what constitutes “normal” behavior.  Armed with this intelligence and critical contextual knowledge, they can then make accurate decisions on when to pull the plug.

2.  Security professionals must begin proof-of-concept projects ASAP so they gain experience with automated response technologies, fine-tune them, and roll them out into production networks over the next few years.  Finally, CISOs need to reassess how they measure risk.  For example, what’s worse:  Pissing off a few customers or taking POS systems of the network and preventing a major data breach? 

Several vendors such as Cybereason, Hexis Cyber Solutions, and NetCitadel are focused on automating incident response but the vast part of the market hasn’t come around.  In my humble opinion, we have no choice here.  Either automate incident response (in a thoughtful way of course), or suffer the consequences.