Skip to content ↓ | Skip to navigation ↓

Last week Dwayne crafted a post about automatic security response, and it got me to thinking about where I believe automation will work in our process, and how much automation is appropriate  and/or possible.  Specifically, where can automation help us the most right now, especially in the domain of incident detection and response.

Dwayne’s post explained that a discussion they had at a security summit found everyone in agreement that cyber attacks typically begin without warning.  Another way to view this is that incidents happen without warning (attacks are a type of incident).  Consequently, we have a need to quickly recognize we’re being attacked and respond appropriately.

Dwayne covered some of the facets of automation that make it difficult to trust in the context of incident response, and I agree – automated is not the same as automatic, and automatic should be used only after the automated has been demonstrated as effective.  What I’d like to cover today is a little different – what about the automation of pre-incident activities – everything you do right up to, and including, the point of detection?

In other words, what would it take for us to trust automated operational processes (IT and security processes included) in everyday, routine activities?  Is trust the same in this context or is it somehow different?

Dwayne mentioned fragmented technology environments, lack of standards, and lack of testing and structured R&D as challenges to automation in incident response.  For incident response, these things are very true.  For all the routine activities that help us detect incidents, the situation is much different.

I’d like to cite the Security Automation community and Security Automation and Continuous Monitoring efforts specifically.  The entire goal of these efforts are to take us from control to configuration/event sensor to monitoring and back again, doing so in an automated manner.  As an aside, this effort will only grow stronger with more participation.  If all you can do is sign up to the SACM mailing list and voice an opinion, you are helping all of us do better.

Let’s recognize that all of this work – the day-to-day IT activities – are exactly what lead to effective incident detection.  Put another way, the more we can automate the routine of managing assets, configuration, and change, the better our incident detection capabilities become.

What do we want to automate to make incident detection better?  In no particular order:

  • Configuration activities:  We want to automate hardening our systems and continuously monitoring those systems for changes from accepted configuration state.
  • Audit Logging: Once configuration activities are underway, we can assume that audit settings are configured appropriately, but we need a way to automate the collection and analysis of those logs.
  • Asset Management: We want to ensure that we are discovering new assets, determining which assets are authorized to be part of our ecosystem, and to maintain an ongoing collection of up-to-date associations with respect to our assets.  Who owns the asset?  Who administers the asset?  To which subnet is the asset connected?  What is the asset’s criticality to the business?
  • Continuously Monitoring: When we have basic activities in place and automated, then we can continuously monitor these systems for deviations from what we expect to see.

That last part is important.  When we detect a deviation from the norm, we have, in effect, started the incident detection and response cycle, because we have detected an incident.  The deviation may be expected, but it may not be, and either way it’s an incident.  I’m not sure how many people would agree with me on this one, but I view most problems outside the routine first as an incident.  Most are benign, some are not.  So, when someone’s account is locked out, that is first an incident, then a PEBCAK issue.  Or, when someone files a help ticket complaining that Outlook is changing focus from the e-mail being drafted to the menu every time they type an apostrophe, that is first an incident, then an oddity of Outlook.

I would argue that it will take much less for us to trust automation up to and including incident detection than it will to trust automation for the response.  Why?  Because the response to an incident requires analysis, and we’re not yet mature enough as an industry to automate the analysis that a human would perform in the heat of the moment, but we are mature enough to automate the routine of managing assets, configuration, and change.

I believe we are mature enough to represent configurations in a machine readable manner.  I believe we are mature enough to collect and manage asset data.  I believe we are mature enough to create appropriate data formats, transports, and interfaces for all of the machine readable information required to continuously monitor our enterprise.

And, because the name of the game today is, as Dwayne mentioned and others believe, quick detection and response, continuous monitoring is a critical piece of that solution.  In fact, to answer the title of this post, I believe continuous monitoring is the embodiment of effective incident detection.

Do you believe otherwise?  I’d like to know.