How many of us have seen the ‘Threat Intelligence’ section of Microsoft Sentinel, and wondered what it was all about? There’s some obvious immediate questions – how does it work? Why should we use it? And arguably the most important question – how much is it going to cost?
Read on to find the answers to some of these questions below!
How does it work?
To work this out, we have to dissect the different components of Threat Intelligence from a Sentinel perspective.
Intelligence Feeds
A threat intelligence data feed is a collection of Indicators of Compromise (IoC’s) brought together by an organisation, typically containing information of Bad Actors motivations, known infrastructure that has been used for malicious purposes, the latest techniques used by Bad Actors, specific IP addresses associated with known malicious activities, and many other data. Your first step before ingesting this information is to determine which feed you wish to consume, and set up the relevant subscription to this service. Some are free, and some require a paid for subscription, but all will provide you with a unique reference to use when connecting to the service to obtain security data. You should make a note of these details, as it will be required at later stages of the setup.
Azure AD Enterprise Application Registration
Before feeds are ingested from your provider, a mechanism needs to be created for the data captured to be ingested to the right place in Azure – such as the appropriate Azure tenant, and the relevant resources in Azure. To do this an Enterprise Application needs to be registered in Azure, with permissions to write data to the Microsoft Graph Api. Microsoft Graph is designed to be a single endpoint in to the Azure platform insights, all related to the individuals consuming applications and services within your M365 and Azure Tenant. Bringing in a Threat Intelligence data feed adds another perspective to the data already available within the Graph ecosystem, and as such requires permissions to write to the Graph Api as the data is copied in to your tenant.
The Enterprise Application will provide you with an Application ID, a Client Secret and should be used in conjunction with your tenant ID to match the data import to your tenant. The Enterprise Application must be granted ‘ThreatIndicators.ReadWrite.OwnedBy’ permission level and granted Authorisation by an Azure AD Administrator user before this will function as desired.
Feed Ingestion
Microsoft provide you with a list of suggested threat intelligence data feeds that can be used in Sentinel. Azure connects to the third party provider, typically using an Api key, downloads the data and pushes this into Sentinel via the Enterprise App created above. Some of you will have heard of the TAXII Threat Intelligence feed, which is widely recognised as a respected name in this area, but others I have worked with include the AlienVault_OTX_V2 feed, and MISP. All of these have a data ingestion approach as described here.
The most common and indeed simplest way to capture this data is via a LogicApp. The example below shows some of the workflow for the AlienVault_OTX_V2 provider:
Threat Intelligence Data Connector
Once data has been ingested from the provider, a Data Connector in the Sentinel portal can be used to bring this in to the GUI. At the time of writing this there are dedicated data connectors for the TAXII feed, but for any of the other providers in the list above you can use the generic ‘Threat Intelligence’ Data Connector.
Once this detects data being ingested in by the LogicApp above, these will be visible in the ‘Threat Intelligence’ section of the Microsoft Sentinel portal:
Threat Intelligence Analytics Rules
Following on from successful Threat Intelligence data, you then need to enable Analytics rules to actually interrogate your log data to determine if, in accordance with the Threat Intelligence data, there are any Indicators of Compromise. To help with this Microsoft do provide you with a list of predefined Analytics rules:
These are designed to periodically analyse log data in your underlying Log Analytics workspace in the context of the Threat Intelligence feed. It is also worth noting that the provider you use for your Threat Intelligence feed may well provide you with some custom threat intelligence analytics rules to go deeper into the data – always worth checking with the provider when you take out the subscription to determine their recommendations.
Why use Threat Intelligence Feeds in Sentinel?
Understanding the ‘why?’ is the key question really. It might seem like a considerable effort to get this up and running, but what is the gain from this? Really simple to be honest: confidence. If you are running Sentinel, happily churning through log data with Microsoft providing all the machine learning and threat intelligence/IoC analysis to determine whether there are any issues in your environment, you are relying on a single source for that security analytics. If Microsoft say there’s an issue, then there is an issue, and if they don’t then there isn’t. That is not necessarily a bad thing given the amount of money Microsoft invest in security intelligence these days, but if you can add a second source of IoC data however, then the worst you are doing is complimenting your existing data and increasing the confidence that your information is secure. That can’t be a bad thing, surely?!
How much is it going to cost?
Not a lot, ultimately. There are several angles to the costs to consider however:
- The costs from your Threat Intelligence provider. As mentioned earlier, some have a subscription fee and some are free, but you should be able to explore a proof of concept with a provider before you make your final decision to determine the business value.
- Initial setup costs. This might just be the time it takes for your internal teams to set up the Threat Intelligence aspects of Sentinel, but if you are using a third party provider for this then there could be additional setup costs to consider.
- LogicApp runtime. In the example above, the LogicApp is set to run once a day, and each time this runs it incurs some Compute costs. These are minimal however, and are based on the time it takes for the ingest process to complete. The first time you run this it can take ~40 minutes, but following on from that its around 1 minute. The Consumption model tends to work best for these types of low-complexity, low frequency tasks and should be relatively low cost as a result, but can differ from provider to provider. The Price Calculator can be used to determine what this looks like for your specific environment, but would expect this to be below £10 per month.
As a result of the above, the on-going costs of adding this to Sentinel are negligible.
Summary
Threat Intelligence feeds in Sentinel is an area that in a lot of cases go above and beyond what is required for the particular deployment. If you’re looking to automate a second pair of eyes into the data within Sentinel however, then this is likely to be the simplest and most cost effective way to achieve this. A little bit of additional setup effort and cost can go a long way to guaranteeing your environment security is at the best possible level.
