Security Analytics – Does your security operations need it?

DIERA, UAE - July 27, 2016 - PRLog -- I frequently get asked by clients whether they should invest in security analytics projects. Over a period of time, I have built up a conceptual framework to put security analytics in the context of overall security operations. Although there are many areas for applying analytics, including risk and compliance or vulnerability management, I will concentrate on threat management where I feel it has maximum applications.

At the broadest level, I try to picture it as a left brain/right brain metaphor. While there may not be strong scientific evidence, the popular notion is that the right brain is involved in identifying patterns, connecting dots and getting the bigger picture while the left half is used for logical, analytical, and deductive thinking. In security parlance, right brain analytics would be used for discovering new things such as abnormal patterns, outlying behaviors, unknown attacks or trying to complete the jigsaw puzzle of an attack campaign when parts of the attacks may be missing from alerts. Meanwhile, left brain analytics would be used to dig deeper once an alert is found to deduce how and when the attack happened, who attacked, and what damage was done.

You can break security analytics in threat management into discovery analytics –right brain and investigative analytics –left brain. These are the fundamental pillars in an active cyber security framework.

When it comes to discovery analytics, there are a plethora of products today which have established the capabilities to detect attacks. Every AV, Firewall, IDS/ IPS, SIEM, and anti-APT have security analytics for this. In addition, there are a variety of threat intelligence products and separate big data analytics, user behavior, and entity behavior analytics. Again, I have tried to create a conceptual framework for this concept.

One can break up the threat into 2 parameters- attack vector and threat actor (attackers) – and plot the four quadrants as known and unknown for actors and vector. Known actors would mean we know something about the attacker, for example, the typical TTPs in a known attack has obvious meaning.

The right half of the graph is all about rules- attacks are known and hence a rule can be created for security devices like IPS, WAF, DLP, SIEM or anti-malware products. Because the attacks are getting more complex and because there are stages to attacks, these rules can be more than just one signature. While purists may not deem such rule writing as analytics, nevertheless, modelling the correct rules is an important part of threat detection. Many of the existing products in this segment are building more and more complex rules when they say security analytics.

The segment quadrant is where the attacks are not known a-priori, but we have some knowledge of the attacker. There is an entire industry that has grown around external threat intelligence. In addition, large enterprises are building up threat intel from their own internal SOC data. Such threat intel can be applied to a variety of data sources including logs, flows, packets, URL access, machine configuration files, etc to generate alerts. Tactical threat intel gets applied directly while strategic threat intel gets modeled into attack trees.

The most classical application of analytics however is in the unknown-unknown quadrant. This is where the statistical and probabilistic models are used for finding outliers, patterns, abnormalities, and attack sequencing. Machine learning is getting widely used for this quadrant and the concept of big data is most relevant here since the underlying data is beyond logs, ingesting a wider variety of machines, networks, packets, and unstructured data.

However, the last quadrant is also the area where you could end up chasing the tools rather than the output. There are so many models, algorithms, and software packages that do machine learning, statistics, and probability calculation that often the discussion is more about the tools and platform capabilities rather than the use cases. Even if you are trying to find unknown-unknowns, it's still important to pin down the use cases for them.

The Cyber Kill Chain – Determining when rules are needed

That brings us to my third conceptual model – using cyber kill chain to understand why we are building what we are building in security analytics. As the diagram shows, there are some areas of kill chain like exploit and recon and some parts of execute where rules are available in current products. These are represented by red dots. Several other areas like the deliver phase or the install phase are difficult to have rules and hence need analytical models, which are shown as black dots.

These detect waterhole attacks, unknown forms of beaconing, unknown malware installation, lateral spread in networks, data exfiltration without the data being labeled, etc, and are the areas that need analytics as well as rules to solve them. For other places where rules can solve, it is overkill to build analytics. (The red and black dots are only for illustrating the idea and not the exact measurement of what rules are available). So, one way to approach use cases would be to determine what threats you want to detect and whether any rules exist in any of the deployed products before taking up a security analytics project.

I am trying to build a framework regarding left brain analytics, security investigative analytics, what analytics are needed following an alert or incident, or as Gartner says, "hypothesis driven analytics." I will address this concept in a future post.

http://paladion.net/

Authored by Rajat Mohanty, Co-founder, Chairman and Chief Executive Officer at Paladion Networks