Você está na página 1de 3

Security Analytics Does your security operations need

it?
How does the left and right brain theory apply to cyber security
monitoring
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 parametersattack 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 unknownunknowns, its 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.
Authored by Rajat Mohanty, Co-founder, Chairman and Chief Executive Officer at
Paladion Networks