How and Why to Use the Closed Classification Properly for Azure Sentinel Incidents

There’s been discussion recently over the classifications available when you close an Incident in Azure Sentinel. Specifically, those questions are around what each classification means and how applying the correct classification will make the system more intelligent.

Importance of Classifications

Before digging into the definitions and recommendations for each classification, its important to understand the reasoning behind each classification. The first thing to understand is that when you assign the appropriate classification, the data is used by the product team to improve the out of the box (OOTB) detections. The classification is used to limit false positives as much possible. In the future, there may also be additional functionality for Incident confidence and rule tuning suggestions, among other things.

With this in mind, selecting classifications and the definitions behind each classification makes more sense – particularly the false positive selections. By selecting the appropriate classification, you are helping the product team which, in turn, helps you because it makes Azure Sentinel better.

And, can I take a brief moment here? THIS IS IMPORTANT. By using the Closed classifications, selecting the correct ones, and providing proper commenting feedback, you are not just helping yourself, but you’re helping all Azure Sentinel customers. Just the simple act of doing this and doing it correctly, you are massively improving the accuracy and intelligence of the product. Don’t underestimate your value and your place in this process!

Definitions

True Positive – suspicious activity = Choose this classification when you’ve performed a complete investigation that resulted in an actual security issue and the culprit was identified and the situation was truly remediated.

Benign Positive – suspicious but expected = Choose this classification if the event is something you still want to be notified about in the future, but the individual (user account) who did it, or the hostname or IP address used, was expected. A good example of this is when someone adds a device to an NSG with elevated access. As a security team, its something you want to know about. But, as part of the investigation you determine it was a valid change management operation and accomplished by a trusted individual. This gives you the opportunity to add that trusted individual to a Watchlist so that this specific person is not captured in any future dragnet. Next time, you’ll only be alerted to non-trusted accounts.

False Positive – incorrect alert logic = Choose this classification when you believe the logic behind the Analytics Rule is wrong. If it’s an Analytics Rule you created, make sure to adjust the rule to fix it. If its one of ours, you can adjust it, but know that the original rule template will be vetted and potentially adjusted. Make sure to be precise in the commenting. Thanks for your help!

False Positive – inaccurate data = Choose this classification when you believe any of the data contained in the Incident is wrong. Did it collect the wrong user account? Did it not capture ALL user accounts? Is the IP address wrong? , et al. If its a rule you created, you’ll want to modify the rule. If its ours, we’ll take it under advisement for tuning. Make sure to comment effectively. Again, thanks for the help!

Undetermined = OK…I hate this one. As an analyst, I believe we should avoid closing out an investigation without proper context. Using the law enforcement approach, this is essentially turning an investigation into a “cold case.” I’ve experienced a few cases where it was unavoidable – particularly when no Entities were captured in the Incident – but also realize that if you close out an investigation without context or entities, there’s a good chance a similar occurrence with more data will be exposed shortly. So, close it out and expect to reopen it later.

Author