Following my previous column, Taking Back the Reigns, about the need to empower network security managers and allowing them to proactively program security solution per need rather than manage reactive administration of security devices, I would like to shed some light on what the market calls “context-based security decisions and processes” and how to get there through programmability.
Now more than ever, context-based decisions have become a necessity. This is because the identification process of an advanced persistent attack campaign is all about putting events in the right context. The evolution of these attacks spans over longer time periods (days and weeks) and each attack campaign contains different types of security events and anomalies across different network entities.
Some of these events are generated by legitimate network tools used for malicious purposes (e.g., VNC, SSH, PuTTy); some by attack tools, some are manually performed by compromised machines that are controlled by attackers, some are generated automatically, and some are generated by insiders. Advanced attack campaigns include the whole wide spectrum of security events and anomalies – all together.
Today’s security systems are struggling in identifying a single event with acceptable low false positive rates, because their decision-making process is not implemented in the right context. So, what will happen when such systems will need to identify a full attack campaign that requires more holistic context-based security mechanisms? This will probably not work.
To illustrate how the holistic context comes into play, let’s take another look at an illustration of the target breach I used in one of my previous posts (Transforming Cyber Defense Planning Model Actions):
When looking at each step by of the attack (from one to five) by itself in the above Figure, it doesn’t really imply that data is about to be stolen. Exploitation of web service (step one), which is separated from the critical network area doesn’t look like a real problem yet, neither do the manual probes (step 2) of the Active Directory, DNS servers etc. Even the remote command channel tools used (stage 4) for malware propagation do not yet give an indication about what is going to happen.
However, when looking at the whole “picture” holistically through the human security expert’s eyes, it becomes pretty obvious that something big and bad is about to happen.
Transforming these human expert insights into machine processes cannot yet be done by any artificial intelligence technology (at least not a commercial one). Therefore, and probably more than ever, protection systems should be designed in a way that allows interaction by the human security expert for providing advanced holistic context scenarios.
This level of interaction requires certain levels of programmability that can be represented through the following abstract security model:
Each layer (surface) in the above figure represents a logical abstract stage that a protection system should implement.
Following is a description, from the bottom up:
Traffic statistics, security logs and security reputation feeds are collected by a profiler, which aggregates and learns behavioral parameters with no real context in mind.
A security engine is an entity that selects certain types of parameters and correlates them in order to make a security decision. This is where a “local” context based security decision is made, as multiple parameters are taken into account in the decision making.
The reason for defining it as a “local” context lies in that fact that an engine doesn’t “know” about decisions of other security engines in the same level. The separation between decision engines that “live” in the same level is required for scale and extendibility purposes of the protection system, i.e., agility that allows the creation of more security engines.
The holistic context-based engine(s) collects feeds from the different decision engines and is responsible for identifying the “big picture”. The Big Picture is generated by engine(s) that can process a wide spectrum of feeds of different types and “glue” them together based on parameters such as time, topology, the asset type, security event type and so on.
Security language – in order to create a system which is extendible in a way that more context-based scenarios can be added, two levels of security language are introduced. One is for creating new security engines that identify a new type of threats with a “local” context, and another language (the highest one in the Figure), for creating the holistic context-based decision process – a language that provides the “glue” between the aforementioned parameters.
Although some of the processes can be automated, full automation results in limited protection or as I described that in my previous column “a limited protection space.”
Therefore, the interaction of the human security expert is key! Protection systems that aim to fight against Advanced Persistent Attack Campaigns and are expected to end up with the upper hand, need to provide the security managers with real tools to fight back. The proposed security model I’ve illustrated is needed in order to start designing products that provide these tools.