One of the biggest challenges within cybersecurity is how to handle the sheer amount of data. Everyone in the field is familiar with the stories of failed SIEM implementations, because the number of false positives is simply too big for the available IT staff to have enough time and manpower to separate the useful from the useless. Outside of that it seems unlikely there’s going to be an end to the amount of data and it’ll be (already is) near impossible for security teams to process all the data manually. In short: automation is indispensable and there are more than enough vendors offering their products.
Content vs Context
Properly assessing this data isn’t a challenge that’s solved by throwing a set of general rules at it, which is what virtually all these products do. The complexity is in the relevance of the data in relation to your environment. It’s important to make the clear distinction between content and context here.
Content can be seen as the what. These are often the hard facts, like “10 dollars”, or a security event “blocked brute force attack from IP address”. It’s hard to determine whether or not “10 dollars” is a lot if you don’t know in what context the “10 dollars” is brought up. The same goes for the security event “blocked brute force attack from IP address”; is this a good thing or a bad thing?
The challenging part of context is that it can vary per environment and person; everyone has their own perspective and interpretation.
It’s dangerous to simply apply general rules to this data. Generally speaking, it might be a good thing that a brute force attack has been blocked, but that doesn’t mean that we can just ignore that it happened, when the fact that it’s happening can be very relevant for the security team and organization.
Context differs per environment
In order to properly judge content, we need context. What is the content about and in what scenario is it happening; by adding context to the content we can determine how to handle the content. The challenging part of context is that this can differ per environment and person, because everyone has their own perspective on things, and their own way of interpreting content.
A clear example: 10 dollars
Let’s use the example of “10 dollars”: if it’s 10 dollars for a beer, then (most) people are inclined to say that’s expensive. However, if it’s 10 dollars for a beer at Coachella, people will likely be less surprised. To help clarify that perspective a little more, we can tell you that beer prices at Coachella range from 12 to 15 dollars.
This extra context will make the interpretation of the content simpler and this is important when we’re talking about automation. There needs to be a high rate of certainty to properly assess data.
Zero Trust and context: segmentation
Zero Trust as a security strategy offers a clear handle when we want to work with context. Zero Trust is built on the fact that the environment and segmentation is taken into consideration, and the term crown jewels is often used to explain the concept.
In short: the idea is to separate the environment in segments and that these segments are shaped around the Data, Assets, Applications and Services (DAAS) that you want to protect. Because we know what is located in each segment, it is useful to properly describe this, including relevant information. A few examples are:
- What kind of data is located in this segment?;
- What rules and regulations apply?;
- Who is responsible for this data?;
- Where is this data located?
The purpose of this information is that it gives context to events (content) that are related to this segment.
Security events and context
Here we’ve reached the final piece of the puzzle. Security solutions generate events. These events are naturally generic and need to be able to work in nearly every environment: the solution itself has no notion of the environment (context) in which it operates. In short, after receiving these events we have to link them to the right context.
When we look at the earlier example of a blocked brute force attack from IP address, we can use the IP address to determine where the attack came from. If this is this an attack that came from the Internet on a service that’s being offered on the Internet, then we can automatically handle this. After all, online services are constantly ‘knocking on the door’. Though it is interesting to see how often this happens and if there’s an increase over time.
However, when it turns out that the internal server, for example the CRM (customer relationship management) system is causing this brute force attack, then we’ll need to do more research. Is it an expired service account or is there an attacker present, laterally working their way through the network?
Despite the fact that the security device blocked the attack, it’s clear that in the context of the CRM environment, this event can’t just be ignored!
Conclusion
To make sure the security team doesn’t get flooded with data from security solutions and is unable to separate useful alerts from useless ones, it’s important to apply automation as much as possible. To do this properly and to prevent useful information being missed, it’s important to provide the content with context.
This way, the useful alerts can be handled in the right framework and even if this doesn’t happen automatically, the context will provide the security employee with much more information.
By implementing Zero Trust and the accompanying defining of segments, it’s a small task to add context to the content.
For more information, see also: There’s no such thing as an all-encompassing Zero Trust product (PDF).
What can ON2IT do for you
ON2IT offers her clients a portal, that allows them to set up their Zero Trust segments, including relevant meta-data, like ownership, BIV/CIA score, etc. Every security event will be processed by the Zero Trust Contextualization Engine and automatically linked to the relevant context. This context can (and will) differ per client.
Offering context is a way of enriching an event. By enriching the events we’re able to properly handle them and there will be clear communication, the active directory, which is much clearer than IP-address 10.1.2.3. An event can, depending on the context, have several ways of being handled (this can also depend on the client).
These ways of being handled aren’t always automatic and/or administrative, but can also consist of so-called Rules of Engagement. For example: automatically placing a device in quarantine.
In contrast to many other products, ON2IT uses an Indicator of Good (IOG) instead of an Indicator of Compromise (IOC). The focus for the (automatic) evaluation of events is on whether or not the event was positive, like for example the blocked brute force attack which went from the Internet to a public service.
The moment we’ve established the certainty of the IOG we can automatically process the event for reporting. Other events will be correlated and a ticket will be created for our managed SOC (mSOC) team.
Rob Maas
Thought Leader
