SOCs: why they struggle with context?

Most SOC finds it challenging to go through the vast amount of (false positive) alerts. The good thing those alerts are indeed indications that something is happening that needs their attention. The bad thing is that even SOC teams are under understaffing pressure and challenging budgets and that it is not easy to pick the most important alerts to focus on. One of the reasons for the latter is that all those alerts are seen without context and/or relationships. We need to know for instance which network location those alerts coming from, what is it for location, what is the reason for that location, and what is the impact if that location is impacted. And we need to know what other devices are related to the one given the alert to understand the impact and spreading. This context and/or relationships become even more important with Zero Trust as a security strategy.

What about context and/or relationships

A lot of SIEM (Security Information and Event Management) solutions are good in finding events/alerts that are falling inside a certain category (access, network, etc). But what they often are not that good at is to know them in the context of the environment and/or segment. So context refers to give more details to abstract or to group the results. But before we can bring data into context we first need to know the relationships where a thing (IP-address, server, etc) is belonging to. We need to know if the IP-address is from in- or external, and if internal we need to know from which subnet. If we know the subnet we need to know the segment or environment this subnet belongs to. We also want to know what that segment and/or environment is about, etc.

Some of those relationships do come from the in-house CMDB. But especially things like IP-addresses, MAC-addresses, logons, (IoT) devices, can change a lot in time. The current CMDB solutions are more to serve the IT Service Management processes and not to support the SOC people and their SIEM solution.

How is the SOC handling the needed context and/or relationships today?

Most SOCs do know that the organization’s CMDB is not up-to-par or at least not sufficient for their daily work. But they know that those CMDBs do have valuable information, mostly at the services and business level, but often difficult to link to the data that they are working with. That is the reason why a lot of SOCs do have their own spreadsheets and/or “asset lists” containing the information they need. That approach is very time-consuming and error-prone and difficult to oversee the bigger picture.

With most SOCs do use their own spreadsheets and/or “asset lists” they all have to raise security incidents and assign them to the right team to further solve or at least make contact with a team. But before they can do they must find out which device (laptop, phone, printer, server,..) is related to the SIEM event. With all of the (multi) cloud and now with all of the devices that a user can use from more than only the office it is difficult to know who to contact.

With all I mentioned above the SOC is really losing time in getting context in their events and they are already under great unstaffed and budgetary pressure. And with the increasing prominence of IoT devices context becomes more and more important. So there is a need

But for that, a new solution is needed

Current CMDBs lack the flexibility to link data as is needed by the SOC. They also lack the flexibility to analyze the data once it is in there. The reason behind this is that often those tools are rigid in making changes and are also based on relational tables with complex and time-consuming “joins”.
Splunk Enterprise Security is used a lot within large enterprises but that solution is good in generating the SIEM events.

What the SOC need is something that can be used from within Splunk, is flexible in the type of data they need to store and relationships they need, and which is fast by nature.
For that, I developed the Common/Corporate Metadata Data Model (CMDM) that is exactly doing that. It of course takes the data out of existing CMDB but it is also easy to upload files or even to get data out of Splunk and feed that directly into CMDM.
And then the CMDM can query directly from a browser or directly out of Splunk to enrich the security-related data that is there. To know more about the CMDM go: Common Metadata Data Model (CMDM)

If you’re interested please leave your details below and I will be in contact to have a free half-hour discussing the context issue you want to address: