How to assess security automation tools

Understanding the differences between the tools that promise to ease your security workload

This column is available in a weekly newsletter called IT Best Practices.  Click here to subscribe.  

During my recent trip to Tel Aviv to attend CyberTech 2017, I had a one-on-one conversation with Barak Klinghofer, co-founder and chief product officer of Hexadite. He gave me a preview of an educational presentation he was to give two weeks later at the RSA Conference. His insight is worth repeating for anyone looking to add automation tools to their security toolset.

As I saw at CyberTech, and I’m sure was the case at RSA, the hottest topics were security automation, automated incident response and security orchestration. These can be confusing terms, as every vendor describes them a little bit differently.

In this article, Klinghofer gives his definition of security automation and an overview of several hot market trends today. Klinghofer and the other Hexadite co-founders all worked as security analysts before they started their company, so they have walked in the shoes of the people who are most likely to use security automation tools.

Klinghofer defines security automation as an active process of the following:

1.     Mimicking the ideal steps a human would take to investigate a cyber threat. The tool should not just assist or provide more insight or more data about a threat, but really mimic the same steps and the logic an analyst should take when doing a cyber investigation. If you can train people to do an investigation, you can probably codify the logic in a system.

2.     Determining whether the threat requires action. This goes beyond running something in a sandbox or comparing it to a threat intelligence list, to include using the results of those kinds of tests and really questioning the evidence. A SOC analyst would do this, so it’s reasonable to expect a security automation tool to do this as well.

3.     Performing the necessary remediation actions. This isn’t as easy as it sounds because there are so many configuration permutations and ramifications for possible actions taken. You want to know that your automation solution is aware of as many use cases as possible because you are expecting the same result as you would get from a human analyst.

4.     Deciding what additional investigations should be next. Many security automation tools stop after the first three steps, but a SOC analyst would go a step further and try to verify or validate that the threat was removed and is no longer a risk to the organization. For example, if there is an alert about a phishing instance, who else in the organization might have that same phish sitting in his inbox?

The big trend in the cybersecurity market is security orchestration. Most of these types of tools are API-driven as opposed to logic-driven, and the basic premise is to get different types of security tools to work together to drive a process. To get value from orchestration, you really need to define the outcome you are expecting.

Orchestration is the means to an end; it’s not the goal itself. If you can find use cases where connecting two devices or solutions gives you extra value that you couldn’t get from either of the devices or solutions alone, then orchestration is worthwhile. That said, there are several types of tools that say they are doing orchestration or automation.

One example is workflow tools. Vendors say these tools will enhance alert data and automate the information sent to your SOC analyst to streamline your incident response (IR) communications. What they actually mean is they will provide you with a framework to better organize your team’s IR flow with built-in ticketing, playbooks and user rules. What you get is something that will tell your IR staff what they should do and in what order, if they have the time to do it. Plus, everything will be documented.

Suppose one of your end-users received a phish. The workflow tool receives the phishing alert from the detection system and starts the process. First the tool will collect the data on the different entities within the email to get more context.The tool will scan and analyze the URLs within the email, and if there is an attachment, it will run it in a sandbox and try to find all of the threat intel. Next the tool will open and assign a ticket which includes the enriched data to assist in the manual investigation.  The analyst will take over with a manual process to deep dive into the alert, but there might be additional steps the workflow tool can help facilitate. The main objective of the tool is to speed up the process and keep it moving along, especially if multiple people are involved.

Another type of security automation tool does threat prioritization. Vendors say they will enhance the alert data and prioritize the information sent to your security analysts to streamline your incident response process. This way you won’t need to analyze everything. What they actually mean is they will ignore everything that is under a specified threshold.

Prioritization is essentially a conscious decision about what you are willing to let go without investigation—but you are never 100% sure that you can ignore something. It’s hard to determine if something is a legitimate risk or not without investigating it. Many breaches have occurred when alerts were not investigated. The advantage of prioritization is that your SOC analysts aren’t overwhelmed with too much to do.

Scripting tools are another type of security automation tool. Vendors say they will provide a way to enhance your IR by integrating your SecOps solutions in order to get a good result. What you really get is an open development framework with some of the APIs already pre-built, but eventually you need to build the playbooks you want. It will take you longer to do this and you need to have experts who know exactly what they are doing. Defining, building and testing the use cases can be very complicated. While the scenarios might sound easy, the fact is that there are many complications and the scripts won’t work in all situations. Basically you end up trading security analysts for programmers.

Klinghofer says Hexadite’s security orchestration and automation tool, Automated Incident Response Solution (AIRS), investigates every alert. AIRS receives alerts from multiple detection and endpoint security systems, adds contextual intelligence and then automatically launches an investigation.

He says the system analyzes data from the network and endpoint devices using algorithms and tools to determine whether the alert is a false alarm, low-level threat, or security breach. Based on pre-defined policies and best practices codified in the logic of the solution, AIRS applies targeted mitigation efforts to stop the full extent of the breach. It follows the same processes and logic that SOC analysts would follow, but without human intervention. (See Hexadite's Automated Incident Response Solution narrows the gap between detection and response.)

With an increasing number of security threats being detected, and the growing shortage of security analysts, most enterprises will be looking for some sort of security automation tool to improve their IR capabilities. If your company is in the market for such a tool, be sure you understand just what it will do for you.


Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Must read: 10 new UI features coming to Windows 10