How to Save on Sentinel's Recurring Costs - eGroup Enabling Technologies

How to Save on Sentinel’s Recurring Costs

While Microsoft Sentinel is a powerful tool to identify and resolve sophisticated cyber attacks, organizations who pilot without taking preliminary steps to minimize costs might experience some sticker shock. This blog outlines some of the more obvious and subtle optimizations that are often missed.

Don’t Go with Pay-As-You-Go

Organizations who plan on ingesting a significant amount of data from third party sources like firewalls, servers, and third party services will pay nearly twice as much on a pay–as–you–go plan than when selecting a “commitment tier.” This is a committed payment whether it’s used or not, so it’s rare that pilots are set up with a commitment, especially since ingesting logs from (most) Microsoft 365 services are free. But when you get started on pay-as-you-go and extrapolate the first costs to the potential worst case, remember it’s not a linear equation. As you approach the bare minimum for a commitment tier (100GB/day), remember to change it. The more logs ingested/committed, the cheaper the per GB.

Pay-as-you-go costs ~$4.76/GB, making the minimum savings of a commitment tier ~38%.

Create a Separate Log Analytics Workspace

Sentinel is Microsoft’s AI-enabled Security Information and Event Management (SIEM) service, while Log Analytics is the repository storing the logs that Sentinel analyzes. Isolating the security logs in their own Log Analytics workspace keeps Sentinel analyzing only relevant data and keeps costs down. Store any other log in its own workspace.

Ingestion Costs Don’t Have to Cause Indegestion

Whether on pay-as-you-go or a commitment tier, ingesting pointless data to Sentinel is wasteful. You can filter incoming data before it’s stored in the Log Analytics workspace where it would start costing money.

There are two types of logs that you can opt to ingest. To get the full value of Sentinel as an early warning system, Analytics Logs are the standard.

The easy yet debatable way to reduce ingestion is by using Basic Logs. Basic logs are best for data with low detection value, but good for forensics. Netflow, TLS certificate monitoring, and cloud storage access logs are good examples. They aren’t going to be the first triggers of an incident but could identify breadcrumbs as you do forensics on a suspected breach. There’s an extra fee to search/analyze basic logs.

In a nutshell, Basic Logs are an option appropriate for budget-conscious organizations who don’t plan to actively use the SIEM for proactive detection and resolution– but who may need to check a box to have a SIEM for a compliance requirement. SIEM expert Rod Trent wrote a good blog about When to Use and When NOT to Use Basic Logs with Microsoft Sentinel

Now, back to the standard Analytics Logs. What can be done to manage their costs? A somewhat sophisticated way to streamline ingested data is to ‘transform’ the logs before they hit the Log Analytics workspace. Log Analytics’ custom data ingestion process gives you a high level of control over the data that gets ingested. Transforming could mean removing redundancies (i.e. two firewalls in an HA pair sending similar logs) or truncating logs from the device. For instance, there Syslog has eight levels of severity, ranging from Emergency to Debug. Customers rarely need all eight. You can configure the device itself to send a specific level of logs, and you can use Log Analytics’ Data Collection Rules to filter unwanted logs.

On Windows Servers running the Azure Monitor Agent, use data collection rules to define the data to collect from each agent. Besides for the predefined sets of events that you can select to ingest, such as All events, Minimal, or Common, data collection rules enable you to build custom filters and select specific events to ingest. The Azure Monitor Agent uses these rules to filter the data at the source, and then ingest only the events you’ve selected, while leaving everything else behind.

Retention Rules Help Retain Budget

After their eight days of normal life, basic logs can be archived to store the data for longer. Standard logs can also be archived, after their 90 days of free storage. Instead of leaving logs in standard storage at full cost, organizations can archive data for up to seven years at a lower cost, shown below. When needed for an audit or review, extracting the data again comes with a fee/GB.

Other Means to Get Lean and Mean

There are several other techniques that can Reduce costs for Microsoft Sentinel beyond the major savers above.

Organizations ingesting at least 500 GB / day into your Microsoft Sentinel workspace or workspaces in the same region should consider moving to a Log Analytics dedicated cluster.
Use Azure Data Explorer as an alternative to Archiving logs for long-term data retention. With Azure Data Explorer, you can store data at a lower price, but still explore the data using the same Kusto Query Language (KQL) queries as in Microsoft Sentinel.

Summary

While Sentinel is generally cheaper than Splunk and other SIEMs, it can seem expensive if left with its defaults. These techniques will be helpful in reducing costs, but should be carefully set up so as to not miss an important incident.