One of the official Microsoft offerings I deliver to customers includes a Day 1 setup of Azure Sentinel – which then leads into a 3-day workshop. But, that Day 1 setup is important so we have the customer’s real data to work with the rest of the week and the customer has data to continue their learning and business integration after the workshop is complete.
One of the things that customers notice right away after setup and enabling a few Data Connectors is the number of Incidents created based on “rare” occurrences. An example is shown in the following image…
Think about it. The customer has setup Azure Sentinel for the very first time and enabled Data Connectors. It makes sense that there would be “rare” operations identified because it’s the first time ever these have been detected.
It’s critical to keep these specific Analytics Rules enabled because they represent important threats to keep track of and be alerted about – however, after setting up Azure Sentinel the first time, you may want to make some temporary adjustments as these will flatten out over time.
First off…make sure to identify the accounts and hostnames associated as Entities to the Incident to confirm the hosts and users are part of your organization. Once these have been confirmed, manage the Incident lifecycle by making a note, assigning the Incident to yourself (or whoever is applicable), and set the Status to “Closed – Benign Positive – suspicious but expected“.
You may also want to adjust the Analytics Rules associated with these Incidents for the time being to help eliminate some noise.
The specific Analytics Rules are:
| Rule | Connector |
| Rare subscription-level operations in Azure | Azure Activity |
| Rare application consent | Azure Active Directory |
| Rare RDP Connections | Security Events |
| SharePointFileOperation via previously unseen IPs | Office 365 |
| SharePointFileOperation via devices with previously unseen user agents | Office 365 |
Consider adjusting the alert grouping for each to make them less noisy.
