Building a Microsoft Sentinel Data Use Case

Data retention is not just a regulatory box to tick; it’s the backbone of a robust security posture.  In the realm of Microsoft Sentinel, understanding how to manage your data retention is key to leveraging the full potential of your SIEM system.  From cost management to compliance, the way you handle data can make or break your security operations.

In the last article about Data Retention in Sentinel, we discussed the importance of building a use case for data requirements and retention.  At its core, Microsoft Sentinel offers flexible retention options tailored to your organization’s needs.  Interactive retention allows for swift, on-the-fly queries, making real-time threat detection and analysis a breeze.

Once this interactive period lapses, data seamlessly transitions to archive retention, offering a cost-effective solution for long-term storage—perfect for compliance and historical analysis.

It’s not just about storing data.  The distinction between analytics and basic logs is pivotal.

Analytics logs provide enriched, contextual information ideal for deep dives and comprehensive investigations.  On the flip side, basic logs offer a more economical way to store high volumes of operational data without compromising on essential monitoring capabilities.  Striking the right balance between these log types ensures you’re not just compliant, but also efficient and effective.

Let’s dive into the intricacies of managing your Microsoft Sentinel data retention strategy, ensuring you’re prepared for today’s threats and tomorrow’s challenges.  Buckle up as we explore the essentials of interactive vs. archive retention and the strategic use of analytics vs. basic logs.

Welcome to one of the biggest, and most impactful, steps in mastering your Microsoft Sentinel deployment!

Creating a use case for Microsoft Sentinel involves a few key steps:

• Define the objective by clearly defining what you aim to achieve.  For example, detecting anomalous login activities to prevent potential breaches.
• Identify data sources that you need.  This might include login logs from Active Directory, Microsoft Entra, Google Cloud, AWS, VPN logs, etc.
• Develop analytics rules by writing KQL queries to detect the specific behavior you’re targeting.  These rules will form the backbone of your use case, identifying patterns that signal potential threats.
  • In many cases, Microsoft Sentinel Content Hub has packages or analytics rules already packaged up & ready to use as-is, or as a starting point.
• Set up alerts and actions to notify your security team when the analytics rules are triggered.  Decide on automated responses, such as notifying admins or blocking IP addresses.
  • We have talked a lot about automation of actions here on AzureTracks!
• Test and refine your use case and monitor its effectiveness.  Regularly review and refine your rules and alerts to reduce false positives and improve accuracy.
• Use your use case as an opportunity to document your Microsoft Sentinel configuration for your Standard Operating Procedure (SOP).  It will make the next people to inherit your systems much faster & they will thank you!

Follow these steps & you can build repeatable use cases that help detail and document your security posture.

Let’s explore a sample use case together….

Use Case: Anomalous Login Detection

Objective

To detect and respond to unusual login activities that may indicate potential security breaches, such as brute force attacks or compromised accounts.

Description

This use case involves monitoring login attempts across the organization’s network to identify patterns that deviate from normal behavior.  By focusing on login activities, we can detect suspicious events, such as multiple failed login attempts from a single IP address or logins from unusual geographic locations.

Data Requirements

Signin logs collected from all authentication systems, including Active Directory, Microsoft Entra ID, VPN, edge protection devices, and any custom authentication solutions.

User profile information on user roles, usual login times, and typical geographic locations. Typically Microsoft Entra ID is used for this information in combination with ADDS and enhanced with Microsoft Defender for Identity risk data.

IP addresses –> Ensure that source IP addresses for each login or signin attempt are included.

Time stamps for all ingested identity logs should be included.

Data Retention Requirements

Signin and login data should be retained in a searchable format for 90 days and kept as archive for 3 years. Remember to list any relevant frameworks, legal requirements such as SOC, HIPPA, ePHI, etc.

Analytics Rules

Create an analytics rule in Microsoft Sentinel to identify patterns of anomalous login activity:

SigninLogs
| where ResultType != 0 // Failed logins
| summarize FailedAttempts = count() by UserPrincipalName, IPAddress, bin(TimeGenerated, 1h)
| where FailedAttempts > 10
| join kind=leftanti (SigninLogs | where ResultType == 0 // Successful logins) on UserPrincipalName, IPAddress, bin(TimeGenerated, 1d)
| project UserPrincipalName, IPAddress, FailedAttempts, TimeGenerated
| extend AccountCustomEntity = UserPrincipalName, IPCustomEntity = IPAddress

You can add more details to define the settings of your analytics rules, or specify adding specific packaged content from Content Hub within Sentinel.

Response Actions

Alerting –> Generate an alert in Microsoft Sentinel when the analytics rule triggers.

Automated Response –> Use a playbook to automatically send a notification to the security team.

• Temporarily disable the affected account.
• Block the suspicious IP address.

Pro Tip:
Consider using a Teams channel for the Security team to collaborate and receive these priority notifications.

Metrics for Success

Reduction in Successful Breaches –> Measure the decrease in successful breaches originating from compromised accounts.

Response Time –> Track the time taken from detection to remediation.

• (MTTR = Mean time to remediation)

False Positives –> Monitor the number of false positives and refine the rule as needed. This can often be optimized to your own environment over time and made to be very accurate when creating a Sentinel incident.

Benefits

Proactive Threat Detection –> Quickly identify and respond to potential account compromises.

Enhanced Security Posture –> Improve the overall security of the organization by addressing login-related threats and reducing MTTR.

Operational Efficiency –> Automate responses to reduce the workload on the security team.

Summary

Using the sample information shown in the above use case, you can replicate the headings and sections to create your own. Implementing a use case ensures your organization is better prepared to detect and mitigate anomalous login activities, enhancing your security measures and protecting sensitive data. This also helps to define what data we need, what we will use in that data, and how long we should retain it overall.

Remember to add any relevant details for your own industry requirements and to ensure that data retention requirements are driven by the business.

Keep your head in the clouds!