There are lots of buzzwords floating around cybersecurity: machine learning, artificial intelligence, supervised and unsupervised learning … In many cases these advanced technologies are based on anomaly detection. This makes a lot of sense since it’s hard - even impossible - to anticipate an attacker’s behavior. Also, in many cases there is not enough classified data to distinguish between benign and malicious events.
How Is Anomaly Detection Used in Cybersecurity?
Various behavioral anomaly detection techniques are used in almost every aspect of cybersecurity. For example, anomaly detection is extensively used in UEBA (User and Entity Behavioral Analytics), NTA (Network Traffic Anomaly), Endpoint operational anomalies etc. An anomaly can mean things like : “Too many failed logins” in UEBA, “A lot of traffic sent from A to B” (where typically it sends much less) in NTA, a process that executes another process that looks like a statistical anomaly in endpoint protection etc.
Anomalies can be strong indicators of malicious activity but, in many cases, anomalies can be triggered by unexpected but legitimate actions. While anomalies are a powerfully tool for threat-hunting they might be a burden on SOC analysts who are focused on addressing threats as part of their incident response.
Since there is a significant cost associated with false positive alerts, due to the time needed to investigate them, we should be very careful when flagging anomalies as security alerts in SOC. While some security devices do a great job of filtering out false positives, many simply dump all or many anomalies in the laps of security analysts for further investigation.
How Can SIEM Platforms Help Separate Valuable Anomalies From Noise?
When combining multiple sources of anomalies and other security signals such as alerts from IDS, EDR, mail security or any other product, the challenge is to automatically find the connections and merge those events into actionable information. Such information must separate the high-risk incidents from the noise. SIEMs that attempt to do so need to also show the evidence and provide analysts with the root-cause and the potential flow of an attack. This saves valuable time in the deeper investigation that will require the forensics data typically stored in the SIEM.
For example, consider an indication of network anomaly where host A sent a lot of data to host B, when typically they do not communicate. This may be an indication of data exfiltration, but it can also be the result of various legitimate scenarios (e.g. unexpected but legitimate file sharing). If following this event there is an indication that node B scanned the network, or there is indication that files were encrypted at an unusual rate, this should raise the severity of the security incident. If other indications are available for the entities involved, such as IDS alerts, of node A or B, this would strengthen the case that all these singular events together tell a truly high-risk attack “story.”
This automatic fusion of anomalies and other events must be a key feature in the next generation of SIEMs that will direct SOC teams to deal with high severity alerts, rather than investigate loads of anomalies.
