Deploy Microsoft Sentinel Analytic Rules from 3rd Party Sources
Deploy analytic rules from sources all over the web.
The cybersecurity community is constantly developing and sharing analytics that can be used to detect potentially malicious activity. Cybersecurity analysts working with Microsoft Sentinel can take these shared analytics and turn them into analytic rules. The only issue is that there is not a clear set of instructions available for deploying analytic rules from 3rd party sources as analytic rules.
In this blog, we show how you can take analytics that you found in a shared online community and turn them into effective Microsoft Sentinel analytic rules. We will also discuss the additional steps that you can go through to improve the quality of the new analytic rule.
Analytic Rule ARM Templates
Some 3rd party sources have analytic rules available in the form of an ARM template. Once you have an ARM template, you can make changes to it before you upload the file to your Sentinel instance. ARM templates can be uploaded using Microsoft Sentinel PowerShell commands or using a tool that deploys ARM templates like Microsoft Sentinel DevOps.
Updating Analytic Rule ARM Templates
Analytic rule ARM templates often need to be updated because there may not be enough information in the existing template or the analyst creating the analytic rule would like to add more features. By using a text editor, the JSON value pairs can be edited to change the analytic rule features before it is deployed.
Analytic Rules in Other Query Languages
If a useful analytic rule is found but it is in a different querying language than KQL, it can still be used in Sentinel. The query used for the analytic rule would need to be translated from its current querying language into KQL using the free “uncoder.io” query translating app.
Once the analytic rule query is translated into KQL it can be plugged into the analytic rule creation menu or the query value pair in an analytic rule ARM template.
Post-Deployment Entity Mapping
Microsoft recently removed the option to programmatically add entity mapping for custom analytic rules. This means that entity mapping must be done manually with any custom analytic rules that are uploaded to a Sentinel instance.
Be sure to map entities for the analytic rule otherwise no nodes will appear in the investigation graph when the analytic rule generates an incident. Up to 5 entities can be mapped and it is recommended that the most important information is mapped otherwise analysts will have to do advanced hunting to finish their investigations.
Consider Adding More Details
Some analytic rules shared with the community have little to no description or comments, which makes it hard to understand how it is detecting what it claims to detect. By updating the description and comments in the query, other analysts will be able to tell what the analytic rule does and potentially how the detection works without having to dive into it.
Analysts that get incidents from the custom analytic rule will have to rely on the description left by the person that deployed the analytic rule to understand what the detection is looking for. A clear description will help analyst be more effective with their investigation of the incident.
We will continue to share best practices and lessons learned in future posts on deploying Microsoft Sentinel analytic rules. CyberMSI is integrating new analytic rules from the community regularly, so we will constantly be searching for the most efficient way to update analytic rules.
In closing, consider these three questions when using 3rd party analytic rules in your organization:
- Is the analytic rule already in the form of an ARM template, and if not is it worth the time to convert it into an ARM template?
- Have we vetted our 3rd party analytic rule sources to ensure that they are reliable?
- Will writing a description for the analytic rule help analysts while they are investigating incidents based on this analytic rule?