Cyber Security Automation; Where to Start
The short and quick answer is; you start with the most impactful tasks. These are the tasks that will bring the highest value and return on your investment in the shortest period of time.
When automating your Security Operations Center (SOC), tasks in an effort to deal with high volumes of appliance events and alerts, you'll likely find that analysts will have tightened the criteria on what triggers an alert to be sent to them. This action will provide the analyst with the highest priority alerts.
We’ve seen this practice in many places because there are simply far too many false positives and too many alerts to respond to each and every one. We call these high priority alerts the “SmokingGun” alerts. When you receive one of these alerts, you can trust its urgency and know your day just took a turn to the worst, someone somewhere is holding a smoking gun.
Smoking Gun Alerts are definitively reactionary. Something bad has happened, and you need to react to it as quickly as possible. We need to become proactive and act before the bad something continues to cause problems. However, the best place to start automating is with these reactionary alerts. Make a list of the alerts you have in place now that are in the “smoking gun alerts” category.
What is Next?
Here is a high level strategy for cyber security automation and automating tasks in an SOC that quickly shows management a ROI from your efforts.
- Smoking Gun Alerts
- False Positive Reductions
- Example: Exploit/Vulnerability Corroboration.
- Cross Correlation of Indications of Compromise (IOC)
- Example: Using multiple appliance's data points
- Internal Threat Intelligence (based on your knowledge of your enterprise)
- Zero Day Exploits (behavior analysis in your enterprise)
- External Threat Intelligence (based on community knowledge of the general threat landscape)
- Internal Threat Intelligence (based on your knowledge of your enterprise)
This is just a suggested path forward, and not intended to be rigid. For example, some “hunting” tasks are of high value, and can easily be automated. So, apply a healthy dose of common sense to your implementation order and strategy.
In this post, we’ll introduce a few examples that may illustrate the types of tasks we’ve found value in automating. In subsequent posts we’ll actually show you how to automate these tasks with DarkLight.
Oh, and one last thing to share before getting into talking about these tasks. If you don’t know how to do these things manually, you are likely going to have a bad time trying to automate them! But, as I mentioned above, actual implementation will come in subsequent posts, and we’ll talk about it more.
Smoking Gun Alerts
A couple of thoughts about Smoking Guns; first, the gun is smoking because the shot has been fired already, and second, the criminal is only going to be holding the gun for so long, so get there fast to identify him.
Usually, because we respond manually, our response to these kinds of alerts is done in forensics mode. It’s after the fact, and in some cases, well after the fact. But if we use cyber security automation, we can collect more timely information on this particular event, and perhaps do some proactive risk reduction for others not yet effected by the threat.
For example, consider an appliance indicating that a box on your network is beaconing a Command and Control (CnC) domain. There may be several actions we want to take, but for the sake of keeping this example simple let’s just constrain it to two:
- Notify a security analyst
- Add the CnC domain to your firewall’s blacklist
This is what we refer to as a Pass-Through alert. The appliance has done the detection work, likely labeled it as being severe or critical and now, just needs to let the analyst know that the event has occurred. But how about enhancing the alert information with contextual information about your enterprise so the analyst has a more complete picture? Information such as the custodian of the box, the user’s real name, his/her phone number, their job title, the department they work in, the physical location of the computer, and any other information that if not provided, will require the responding analyst to look it up.
Figure 1: Raw Event with Enhanced Data
Secondly, an automated mitigation task can help limit the enterprise risk. Since the appliance has indicated that there is an IP or domain that could be a CnC, why not notify your firewall to block all communication with it? If done quickly enough this might prevent the compromised box from receiving additional malware, or prevent other boxes from starting a conversation with it.
False Positive Reductions
Let’s face it, some appliances are noisy. That is not to say that the information is not extremely valuable, but it is to say there is a lot of it!
Here is an example that is really straightforward in concept. Honestly, it is straightforward in implementation too… a good thing.
Consider alerts from Intrusion Protection Systems (IPS). They can throw thousands of alerts a day for a modestly sized company. This is because there are so many kiddie scripters out there trying to make a dishonest buck.
Most IPS alerts include the Common Vulnerability and Exposure (CVE) identification number of the exploit that is being attempted. If the box being attacked is not vulnerable to that CVE, then the alert is a false positive. There is no need to chase it down further, there is no mole to whack.
By running a regular vulnerability scan on your network you can get each device’s list of vulnerabilities, and you’ll know what their vulnerabilities are by CVE.
Although a human can’t manually compare thousands of attempted exploits against the scanned vulnerabilities, a computer has no problem doing so. The false positive reduction based on this automation alone can bring joyful tears to an analyst’s eyes.
Cross Correlations of IOC
Today, most SOCs have security appliances with redundant capabilities. For example you may have two appliances that both issue Intrusion Prevention alerts. If one or the other appliance throws an alert, it may well be worth looking into. If both appliances throw an alert, then there may be more concern that something is really going on. This is particularly true if the appliances are using different algorithms to detect the potential intruder.
Automated hunting is incredibly valuable and easy… really. Here is a simple example. Bad guys don’t do the same kinds of things that normal users do, and that can work to our advantage.
A variation from norm that has yielded some fruit is hunting for odd uses of PING.EXE. The default number of “pings” is 3. So when an IT technician uses the utility you commonly see the three pings when the command is used. However, in order to avoid being detected when scanning your network at the command line a hacker may use the –n argument to reduce the default number of pings.
Constantly watching command line usage for this type of thing just isn’t humanly possible, not to mention it would be boring. By combining the computational staring and reading of command line usage and cross-correlating that with user role (some employees hardly ever open a command prompt let alone use ping.exe) you can flag this odd behavior.
There are lots of these kinds of behaviors to hunt for, just ask one of your sharp cyber guys for a few examples, and then automate them!
Different Strokes for Different Folks
The CISO loves automation because it transforms a reactive team into a proactive team; a team that can keep up with defending the enterprise, and limit the risks. The cyber analyst loves automation because it removes the mundane tasks from his/her workload, and frees them up to track the really hard and interesting challenges.
I have not heard from anyone that thinks at least some form of cyber security automation is a bad idea. At least not to reduce false positives or to alert the human cyber analyst that something may need attention.
What do YOU think?