Supercharge Microsoft Sentinel SIEM with SenseOn 

Security information and event management (SIEM) solutions like Microsoft Sentinel SIEM are at the heart of most security operations teams.

But like any SIEM, while Microsoft Sentinel can be an incredible tool for centralising security data, it also risks being expensive and ineffective. In a recent webinar, SenseOn’s Director of Technology Brad Freeman discusses these problems and how SenseOn can help supercharge Azure Sentinel. You can now watch this webinar anytime online.

To give you a taste of what I covered in the webinar, here’s a short rundown of two core challenges Sentinel creates. Plus, how SenseOn solves them. 

Microsoft Sentinel SIEM Challenge 1: Cost

When you ingest data into a Microsoft SIEM from sources other than Microsoft apps like Office 365 audits and Defender, you have to pay for it. 

Using a typical log count generated by a 1,000-person organisation, and a simple sizing calculator, an organisation of this size will likely need to ingest 188 GB of data into their SIEM daily. If that organisation were to use Sentinel, that volume of log data would equate to roughly £200k per year on log costs.

Organisations may be aware of this cost in theory (and sign up to a particular Sentinel pricing tier). Still, the actual toll of getting actionable insight can be far greater than many account for.

This is partly because the “raw” logs generated by an application are not what gets stored on a SIEM like Sentinel. Log sizes can vary greatly and be larger than security teams expect. The actual volume of data that goes into a Microsoft Sentinel SIEM is not just the sum of all the logs collected but the result of normalised events. These happen when raw logs are converted to a readable and consistent format in the SIEM.

Normalisation involves mapping key parameters, such as source IP addresses, usernames, and system origin. The problem is that normalised logs often double or even triple in size due to the enrichment process.

It’s also crucial to remember that technology costs aren’t the only ones SIEMs like Sentinel create. To develop useful analytics and make use of the logs, an organisation will need to invest in competent security engineers, skilled security analysts, and a robust IT operations team. 

SIEMs also present a cultural challenge. IT needs to work closely with security teams to provide the logs required and have to account for the internal business processes necessary for managing detections, tuning, and integrating your SIEM into new projects. 

Read more: Why there’s no such thing as a low-cost SIEM

Where SenseOn comes in

To reduce these costs, SenseOn first identifies the most voluminous and expensive logs and assesses their value. The goal is to recognise valuable logs and determine whether they can be replaced or filtered through SenseOn’s capabilities, ultimately reducing costs.

For instance, a real customer case study shows that SenseOn decreased volumetric logs by 61% and reduced Microsoft Sentinel SIEM costs by 57%, saving the customer £10k per month. 

Microsoft Sentinel SIEM Challenge 2: Visibility 

If you use a SIEM like Sentinel, you are probably going to be sending it telemetry from a range of sources like Endpoint Detection and Response (EDR) systems, Intrusion Detection and Prevention Systems (IDS/IPS), and Network Detection and Response (NDR). 

These tools can input rich information into Microsoft Sentinel SIEM, but they also come with a downside. Even the most advanced security tools are disparate and disconnected. This creates serious visibility problems.

With information coming from various channels, the root cause of an event often remains obscured despite an avalanche of encrypted data and unusual network activity. The struggle then is not just in collecting data but also deciphering the complex, multilayered story that this data tells. 

For instance, if a SOC detects a connection to a command and control (CNC) server from their NDR, they typically won’t be able to know the originating process on the endpoint. There is usually no link between the network event and its source on the endpoint, i.e., whether it was triggered by Powershell or Chrome visiting a webpage. 

As a result, SOCs can fail to complete security investigations and become overwhelmed by tickets. 

Read more: 4 SIEM augmentation tools and why you need them

Where SenseOn comes in

SenseOn solves this visibility problem by collecting unified data from endpoints, networks and servers in a single format. Our solution links information from endpoints (via deep packet inspection or DPI) with user behaviour and network activity. 

SenseOn pulls together data to present security teams with a sequence of information about individual incidents that we call “Cases.” These cases allow teams to see not only that an event (like a connection to a CNC server) happened but also the entire context surrounding it, i.e., its full DPI, parent process, command line algorithms, etc. 

Pushing SenseOn’s telemetry and telemetry from Microsoft solutions into a Sentinel SIEM can give SOCs proper consolidation and insight. The level of understanding SenseOn creates has been proven to dramatically reduce the mean time to respond (MTTR) for any individual incident. 

Supercharge Microsoft Sentinel with SenseOn

Organisations need a strategic, cost-effective, and efficient cybersecurity solution. 

Leveraging platforms like Microsoft Sentinel SIEM and SenseOn can provide a comprehensive security operations ecosystem that optimises costs, reduces workload, and enhances detections.

Try a demo of SenseOn today.