How does the cloud-native Microsoft Sentinel SIEM work?
As cloud services become more commonplace, there’s an increasing need for data security in the cloud. Complex hybrid environments often provide organisations with more adaptable solutions, yet they also pose a challenge with regard to data security and its maintenance in a complex environment.
When servers are running both locally and in the cloud in multiple machine rooms, it can be difficult to obtain a centralised overview. And if you include all of the firewalls and alert tools, you’re already looking at quite a laborious list of things to monitor. This is why Microsoft has introduced its own SIEM – a cloud-native solution that can be easily integrated into both local and cloud environments. Microsoft Sentinel (previously Azure Sentinel) monitors disturbances in both Microsoft’s own tools and third-party software, and also allows for centralised monitoring when necessary.
Sentinel is a response to the huge demand for a cloud-native SIEM. As a public cloud platform, Azure brings substantial advantages to Sentinel’s functionality that provide unprecedented agility and scalability. Notably, the service is quick to set up thanks to pre-built data connectors and Log Analytics, which is the driving force behind Sentinel. Technical deployment is extremely rapid, as the required resources can be created in Azure and Sentinel provides user-friendly interfaces. With only a few clicks, you can obtain logs of anything from users’ login credentials to server security events.
The power of queries
After Sentinel has been deployed, you can set up KQL analytics rules to automatically seek out anomalies in logged data. Sentinel provides a considerable number of predefined rules, but it is possible – and even recommended – to create your own query rules. This will not only enable you to respond effectively to new threats on the fly, but also to adapt Sentinel to suit your needs. Query rules can, for example, detect anomalies in users’ login credentials or alert you to suspicious email forwarding rules.
In addition to automatic analytics, Sentinel also includes a “threat hunting” feature that enables you to perform the same query rules in real time at the press of a button. This enables effective troubleshooting and reactive investigation whenever it is required. Active threat hunting plays a major role in modern data security. It is therefore one of Sentinel’s core functionalities and has been made as easily accessible as possible.
What are cloud-native SIEMs made of?
On a technical level, Sentinel is based on two Azure resources: Sentinel itself and the background service Log Analytics. The Log Analytics Workspace acts as a storage space and management platform for logged data. Sentinel is provisioned on top of it, and is responsible for receiving and analysing data and saving it in Log Analytics. These two resources make Sentinel transparent and cost-effective to manage.
When deploying Sentinel, it’s a good idea to carefully plan what log data you intend to collect and how you want to process it. Do you need to store data for legal reasons or do you need to analyse and investigate certain events? How long do you need to store each type of log data and how will it be stored?
As a SIEM, Sentinel is able to collect data, detect disturbances, and investigate the cause of a disturbance. From the outset, Sentinel has always sought to provide an automatic option that will make maintenance and threat response as easy as possible.
It’s easy to send an automatic message to a Teams channel whenever a new incident is detected, but other measures are also available, such as closing a compromised user account or shutting down a virtual machine. Naturally, it’s not compulsory to take advantage of every phase. However, when drawing up your deployment specifications, it’s recommended that you analyse the needs you are trying to address with the SIEM and identify the opportunities afforded by its logged data.
“But how much will it cost?”
So how much does it cost to use Sentinel? This is naturally a question that occurs to everyone who’s interested in the service, and is also one of the most common questions I encounter. The cost of using Sentinel is not that straightforward to determine, so I’ll open things up a little for you. In principle, the costs are billed using a “Pay-As-You-Go” model, that is, entirely based on actual usage.
Costs are calculated per gigabyte of incoming data and per gigabyte of data stored. As the service consists of two resources – Sentinel itself and the background function Log Analytics – you will have to calculate the cost for using both of them to get the total price. This may sound complicated, but the final price can be calculated very quickly and accurately as long as you can estimate the volume of data that needs to be logged.
In order to optimise costs, it’s important to accurately specify which data sources are to be used with the SIEM rather than simply including all possible data right away. Logs from firewalls or servers typically generate large volumes of data. However, if you’re monitoring users’ login credentials or data generated by Office, this will typically result in very low bit volumes and therefore low costs. For SMEs, it’s not at all unusual for the costs of using Sentinel to be in the range of only a couple of dozen euros per month. It’s also worth noting that all of the data fed into Sentinel can always be stored free for a period of ninety days.
If you want to estimate the cost of using Sentinel for yourself, you can easily find the per-gigabyte price on the Microsoft website: https://azure.microsoft.com/en-us/pricing/details/azure-sentinel/.
If you like the sound of Sentinel, I heartily recommend getting better acquainted with this solution. As the technical environment is quick and easy to set up, it’s easy to organise a several-month demo at little cost. Likewise, Sentinel can also be deactivated as quickly as it can be deployed.
At Sulava, we’ve already implemented several Sentinel deployments and we’re happy to help you with any questions you may have about the solution itself or setting up the technical environment.
So don’t hesitate to contact us and start harnessing cloud security in your environment!
Oliver Lahti
I’m particularly interested in implementing cloud-native infrastructure solutions in Microsoft Azure. Cloud-native services provide a practical way of scaling and administering solutions, making things easier for both customers and service providers.