15 Jan Top 3 Indicators You’re Ready for Security Automation
By Tom Young, Executive Vice President of Worldwide Sales
Winston Churchill famously spoke of readiness in his “finest hour” speech, “To each there comes in their lifetime a special moment when they are figuratively tapped on the shoulder and offered the chance to do a very special thing, unique to them and fitted to their talents. What a tragedy if that moment finds them unprepared or unqualified for that which could have been their finest hour.”
There’s rightfully a groundswell of chatter about Security Automation across industries in this early new year. Everyone acknowledges that Security teams cannot keep pace with the alert overload, staff shortages, threat landscape complexity, and attack surface expansion (IoT, Cloud, etc.). However, few fully understand what it takes to be ready to step into this exciting new world of security automation. Doing so without properly readying the process, people and technology will never yield the intended results. In fact, I’d argue doing so when not ready threatens to take the bloom of the budding Security Automation rose.
Thankfully, there’s plenty of help. A great place to start is Stacey Collett’s CSO Online article, ‘Keeping pace with security automation,” https://www.csoonline.com/article/3245171/security/keeping-pace-with-security-automation.html
One section of the article in particular, comments from Jon Oltsik, senior principal analyst at ESG, rings true to my experience with customers. Out of those comments, I’m highlighting what I consider the three key indicators you’re ready for Security Automation:
- Identified priority use cases (which ones pose the most risk)?
- Detailed triage and IR processes (including systems/data source used).
- Found your appetite for automation (what will you IT team let your do)?
1) Priority Use Cases
When looking to alleviate the SecOps pain created by the factors mentioned earlier, there’s a temptation to boil the ocean when taking on automation. Remember, just because you can, doesn’t mean you should. As Olstik suggests, “Talk to your people and figure out where your biggest pain point is. Where does it take two hours to resolve issues? Where is it difficult to get people to work together or get the data that you need for investigations or forensics?”
However, I’d suggest that understanding your priority uses cases is not simply listing the most time-consuming and painful types of events/alerts. What’s equally important is which ones pose the most risk. Although responding to a subpoena is a time-consuming and coordination challenged task, it may not represent significant cyber risk (the fact it might represent legal risk is a different issue). Botnet callbacks from database server hosting sensitive customer information does. Prioritizing use cases on the basis of both operational pain and cyber risk is imperative. If you’re not sure which events/alerts pose the most risk, that in and of itself speaks volumes about your readiness for automaton.
2) Defining the corresponding triage and IR processes
When I ask potential customers about their processes for triaging, and if escalated to Incidents, the different types of User-submitted Phishing, SIEM or MSSP alerts they receive, I’m always surprised by the variations. Sometimes I find four analysts who each describe a different process for the same event/alert type, while others point to a Wiki or Intranet page they’ve created to guide the analysts. I’ve seen MS OneNote documents that serve as poor man’s audit trail of what every person has done, and still others point to out-of-date spreadsheets or documents that outline their preferred approaches. The one constant among all these approaches is that they’re not defined as they need to be for automation. They are often out of date, don’t reflect how analysts are actually doing the work, and they lack specifics about which systems are used to complete a given step, how the information captured instructs the next step in the process. Perhaps most challenging to capture is what criteria does an analyst use to make a determination about escalating to an incident. All of these specifics should be fleshed out before attempting to encapsulate these processes into what Gartner calls a Security Orchestration, Automation and Response (SOAR) technology platform.
3) Finding your appetite for automation
As Joseph Blankenship, senior analyst serving security and risk professionals at Forrester Research, says in Collett’s article, “In the past, [automation] has caused us problems. We’ve stopped legitimate traffic, caused outages. There’s a lot of issues with taking automated action without necessarily having somebody look at the action and verify it.” For good reason, many organizations are hesitant to turn on Security automation. Think back to the early days of IPS, when “blocking fear” prevented inline, active prevention of malicious network traffic. However, there are two things to consider when looking to implement automation; a) times have changed, and b) not all automation is created equal.
With respect to the, “times have changed,” point, Blankenship also says in Collett’s piece, “Not until recently have we opened up APIs where we’ve got the ability to not only pull data out beyond just plain and simple log data, or to push an action back. There’s more sharing between platforms, and we’ve created this automation and orchestration layer thanks to APIs that allow a little more free-exchange of data.” Firms like Syncurity now provide purpose-built, enterprise-class platforms to address this layer, where there was no clear solution before.
More importantly, though, is recognizing where in the process automation adds high value with minimal risk. As Syncurity Founder & CSO, JP Bourget, explained in his Dark Reading article, “Finding Your Appetite for Automation (And Why it Matters),” automation introduces disruption risk at different levels at depending on the stage of the triage and IR lifecycle. For example, using automation to look up a suspicious IP address across multiple threat intel sources, both public and private, and presenting back their malicious score and confidence ratings can dramatically reduce the time it takes an analyst to triage an alert, and poses very little risk of disrupting any business processes. However, deciding to automatically block an IP address across the network based on the intel source feedback could. Recognizing where automation can quickly expedite and actually reduce risk vs. where it might introduce disruption risk is critical to early success. Once people begin to have confidence in the triage and IR processes, and the accuracy of recommendations for action, the ability to automate more of these steps becomes more feasible.
Security Automation has Great Promise; Proceed with Caution
One caveat – I’m always telling customers, be careful. Automatically updating your firewall rules 400 times in a day, means 100,000 new rules/year. That’s a lot of strain on the appliances themselves, not to mention the migration nightmare should the enterprise decide to switch platforms/vendors. If automation isn’t applied thoughtfully, and doesn’t include human oversight informed by supervised learning technology, the technical debt generated by this effort will be crippling.
Security Automation holds great promise in dealing with system issues plaguing the good guys in the cyber wars. However, if you’re not ready, having identified top use cases, defined the associated processes in sufficient detail, nor established what your IT team will/won’t allow you to automate, you’ll fall short of your “finest hour.”
What did we miss as far as top security automation readiness indicators? Join the discussion on Twitter, LinkedIn, Facebook, and Peerlyst.