Complete Microsoft Sentinel Tutorial - GUI Version

1. What is Microsoft Sentinel?

Microsoft Sentinel is a scalable, cloud-native **Security Information and Event Management (SIEM)** and **Security Orchestration, Automation, and Response (SOAR)** solution. It provides intelligent security analytics and threat intelligence across an enterprise, offering a single solution for alert detection, threat visibility, proactive hunting, and automated threat response.

Built on top of **Azure Log Analytics**, Sentinel leverages Microsoft's vast threat intelligence, AI, and machine learning capabilities to help security operations teams efficiently protect their digital assets in both cloud and on-premises environments.

2. Key Features and Benefits

• Collect Data at Cloud Scale: Ingests data from various sources (Microsoft 365, Azure services, on-premises, other clouds, third-party security solutions).
• Detect Threats with Smart Analytics: Uses built-in rules, machine learning, and behavioral analytics to identify known and unknown threats.
• Investigate Threats with AI: Leverages AI to reduce alert fatigue by correlating raw alerts into actionable incidents, and provides powerful investigation graphs.
• Automate Response with SOAR: Built-in playbooks (Azure Logic Apps) enable automated responses to threats, accelerating remediation.
• Proactive Threat Hunting: Allows security analysts to proactively search for undiscovered threats using powerful Kusto Query Language (KQL).
• Cloud-Native & Scalable: Pay-as-you-go model, scales infinitely with your data ingestion needs.
• Unified Visibility: Centralizes security data from diverse sources into a single pane of glass.

3. Architecture & Components

Microsoft Sentinel's architecture is built on Azure services, primarily Azure Log Analytics.

• Azure Log Analytics Workspace:
  • The central **data repository** for Sentinel. All data ingested into Sentinel is stored here.
  • Uses **Kusto Query Language (KQL)** for querying and analyzing log data.
• Data Connectors: Mechanisms to ingest data from various sources into the Log Analytics Workspace.
• Analytics Rules: Define logic to detect threats by analyzing incoming data. These generate alerts and incidents.
• Incidents: Correlated groups of alerts representing potential security threats.
• Workbooks: Interactive dashboards for data visualization and custom reporting.
• Hunting Queries: Pre-built or custom KQL queries to proactively search for threats.
• Playbooks (Azure Logic Apps): Automated workflows triggered by Sentinel incidents or alerts.
• Threat Intelligence: Integrates with various threat intelligence feeds.
• User and Entity Behavior Analytics (UEBA): Identifies anomalous behavior by users and entities.

4. Initial Setup & Onboarding

Setting up Microsoft Sentinel involves deploying it to an Azure subscription and configuring a Log Analytics Workspace.

Prerequisites:

• An Azure subscription. If you don't have one, create a free account.
• Contributor permissions on the Azure subscription where Sentinel will be deployed.
• A Log Analytics Workspace.

Steps to Onboard Microsoft Sentinel (Azure Portal):

1. Log in to the Azure Portal: portal.azure.com
2. Create/Select a Log Analytics Workspace:
   • In the Azure Portal search bar, type `Log Analytics workspaces` and select it.
   • Click **+ Create** or select an existing one.
   • If creating, provide **Subscription**, **Resource Group**, **Name**, **Region**. Set a suitable pricing tier (e.g., Pay-as-you-go). Click **Review + create** > **Create**.
3. Enable Microsoft Sentinel:
   • In the Azure Portal search bar, type `Microsoft Sentinel` and select it.
   • Click **+ Create Microsoft Sentinel**.
   • Select the Log Analytics workspace you created or chose.
   • Click **Add**.
4. Grant Permissions: After onboarding, assign appropriate roles for your security team members in the Azure portal for the Log Analytics Workspace (e.g., `Microsoft Sentinel Contributor`, `Microsoft Sentinel Responder`).
   • Go to your Log Analytics Workspace > **Access control (IAM)** > **+ Add** > **Add role assignment**.
   • Select the role (e.g., `Microsoft Sentinel Contributor`), assign to a user or group, and click **Save**.

5. Data Connectors

Data connectors are the pipelines that ingest data from various sources into your Log Analytics Workspace for Sentinel to analyze.

A. Types of Data Connectors:

• Microsoft Services: Azure Active Directory, Microsoft 365 logs (Audit, SharePoint), Microsoft Defender XDR, Azure Firewall. (Often direct, service-to-service integration).
• External Solutions (APIs): AWS CloudTrail, Google Workspace, CrowdStrike. (May involve Azure Logic Apps or Functions).
• Industry Standard Protocols: Syslog, Common Event Format (CEF) from firewalls, proxies, EDRs, etc. (Requires a Linux-based Log Analytics agent/forwarder).
• Custom Logs: For any application or system not covered by built-in connectors.

B. Connecting Data Sources (GUI - Defender Portal):

1. Navigate to Data connectors:

   Microsoft Defender portal > Microsoft Sentinel > Content management > Data connectors

2. Connecting an Azure Service (e.g., Azure Active Directory):
   • Search for `Azure Active Directory` connector.
   • Click on the connector and then click **Open connector page**.
   • Review the prerequisites and instructions. Typically, you'll just click **Connect** for Azure AD logs (e.g., `Audit logs`, `Sign-in logs`).
   • Verify the "Status" shows as `Connected`.
3. Connecting Microsoft 365 (Audit logs):
   • Search for `Microsoft 365` connector.
   • Click **Open connector page**.
   • Check the boxes for the logs you want to collect (e.g., `Exchange`, `SharePoint`, `Teams`, `Audit logs (all activities)`).
   • Click **Connect**.
4. Connecting Syslog/CEF (e.g., from a Linux server/firewall):
   • Search for `Syslog` or `Common Event Format (CEF)` connector.
   • Click **Open connector page**.
   • Follow the step-by-step instructions provided to deploy a Linux-based Log Analytics agent (often referred to as a "Log Forwarder") on a dedicated VM, and configure it to send Syslog/CEF data to that agent.
   • Verify data ingestion by checking the "Status" and by navigating to **Logs** and running a basic query (e.g., `Syslog | take 10` or `CommonSecurityLog | take 10`).

Microsoft Defender portal > Microsoft Sentinel > Content management > Content hub

6. Logs (Log Analytics Workspace) & KQL

All your Sentinel data resides in your Azure Log Analytics workspace. **Kusto Query Language (KQL)** is the powerful query language used to interact with this data.

A. Accessing Logs (Defender Portal):

Microsoft Defender portal > Microsoft Sentinel > General > Logs

This opens the Log Analytics query interface where you can write and execute KQL queries.

B. Basic KQL Syntax (GUI Examples):

1. Basic Query & Run:
   • In the query editor, type `SigninLogs` (if you connected AAD logs).
   • Click **Run**. You'll see the latest sign-in logs.

   SigninLogs

2. Filtering Data:
   • Add a `| where` clause.
   • Example: To see only failed sign-ins.

     SigninLogs
     | where ResultType == 50126 // 50126 is a common code for failed sign-ins

3. Projecting Columns:
   • Use `| project` to select specific columns.

     SigninLogs
     | where ResultType == 50126
     | project TimeGenerated, Identity, IPAddress, Location, ResultDescription

4. Summarizing Data:
   • Use `| summarize` for aggregation.

     SigninLogs
     | where TimeGenerated > ago(7d)
     | summarize FailedAttempts = count() by IPAddress, Identity
     | where FailedAttempts > 5
     | order by FailedAttempts desc

7. Analytics Rules (Detections)

Analytics rules define logic to detect specific threats or suspicious activities in your ingested data, generating alerts and incidents.

A. Types of Analytics Rules:

• Scheduled query: Runs a KQL query on a set schedule, generating an alert if conditions are met. (Most common and what we'll demonstrate).
• Microsoft incident creation rule: Automatically creates incidents from alerts generated by Microsoft security products (e.g., Defender for Endpoint).
• Fusion: Uses Microsoft's AI to correlate multiple low-fidelity alerts into high-fidelity incidents.
• Machine learning (ML) behavior analytics: Pre-built ML models that detect anomalous behavior (e.g., impossible travel).
• Microsoft security: Connects alerts from Microsoft services (e.g., Microsoft Defender for Cloud Apps).

B. Creating a Scheduled Query Rule (GUI - Defender Portal):

Let's create a rule to detect multiple failed sign-in attempts from a single IP.

1. Navigate to Analytics rules:

   Microsoft Defender portal > Microsoft Sentinel > Configuration > Analytics rules

2. Create Rule:
   • Click **+ Create** > **Scheduled query rule**.
   • General tab:
     • Name: `Brute Force Attempt from Single IP`.
     • Description: `Detects multiple failed sign-in attempts from a unique IP address to different user accounts within a short period.`
     • Tactics: Select relevant MITRE ATT&CK tactics (e.g., `Credential Access`, `Initial Access`).
     • Severity: `High`.
     • Status: `Enabled`.
   • Click **Next: Set rule logic**.
   • Set rule logic tab:
     • Rule query: Paste your KQL query here.

       SigninLogs
       | where ResultType == 50126 // Common failed login result code
       | summarize FailedLogons = count(), AccountList = make_set(Identity) by IPAddress, bin(TimeGenerated, 5m)
       | where FailedLogons > 10 // Threshold for failed attempts
       | extend StartTime = min(TimeGenerated), EndTime = max(TimeGenerated)
       | project IPAddress, FailedLogons, AccountList, StartTime, EndTime
       | order by FailedLogons desc

     • Entity mapping: Click **+ Add new entity**. Map relevant entities from your query results (e.g., `IPAddress` to `IP address`, `Identity` (from `AccountList`) to `Account`). This is crucial for the investigation graph.
     • Custom details: Click **+ Add new custom detail**. Map query fields to alert details (e.g., `FailedLogons` to "Failed Logons Count").
     • Query scheduling:
       • Run query every: `5 minutes`.
       • Lookup data from the last: `5 minutes`.
     • Alert threshold: `Generate alert when number of query results is greater than 0`.
     • Event grouping: `Group all events into a single alert` (default).
   • Click **Next: Incident settings**.
   • Incident settings tab:
     • **Automated incident creation:** Ensure `Create incidents from alerts triggered by this analytics rule` is set to `Enabled`.
     • **Alert grouping:** (Optional) Configure how alerts are grouped into incidents (e.g., by IP address within 1 hour).
   • Click **Next: Automated response**.
   • Automated response tab: (Optional, see Automation section).
   • Click **Next: Review and create**.
   • Click **Create**.

8. Incidents & Investigation

When analytics rules trigger alerts, and related alerts are automatically correlated into **incidents**. Incidents are the primary focus for security analysts.

A. Managing Incidents (GUI - Defender Portal):

1. Navigate to Incidents:

   Microsoft Defender portal > Microsoft Sentinel > Threat management > Incidents

2. View Incident Queue:
   • You'll see a table listing all incidents, their severity, status (New, Active, Closed), owner, and entities involved.
   • Use filters at the top to narrow down the incidents (e.g., filter by severity, status, owner).
3. Assign & Status: Select an incident, and use the options at the top to **Assign** it to yourself or another team member, and change its **Status** (e.g., from `New` to `Active`).

B. Incident Investigation (GUI - Defender Portal):

Click on an incident to open the full investigation details.

1. Overview Tab: Provides a summary, related alerts, entities involved, and MITRE ATT&CK tactics.
2. Alerts Tab: Lists all individual alerts associated with this incident. Click on an alert to see its raw data.
3. Entities Tab: Shows all users, hosts, IP addresses, processes, etc., that Sentinel has identified as relevant to the incident. These are crucial for the investigation graph.
4. Timeline Tab: Displays a chronological sequence of events and alerts related to the entities in the incident.
5. Investigation Graph:
   • Click the **Investigate** button from the incident overview page. This opens a visual representation of the incident.
   • Nodes represent entities (users, devices, IPs) and alerts. Lines show relationships.
   • Click on an entity node (e.g., an IP address) to view its details in the side pane.
   • Hover over an entity to reveal "Exploration Queries" – pre-defined queries to expand your investigation (e.g., "Related alerts," "Logon events"). Click to run them and add results to the graph.
   • You can expand nodes, drag entities around, and use the timeline at the bottom to focus on specific timeframes.
6. Audit Log & Comments: Add notes and observations to the incident's "Audit log" for collaboration and record-keeping.
7. Actions: From the incident page, you can take various actions like running playbooks manually, creating a new hunting query from an entity, or closing the incident.

9. Hunting

Threat hunting is the proactive search for threats that are currently undetected by existing security controls. Sentinel's Hunting capabilities empower security analysts to do this.

1. Navigate to Hunting:

   Microsoft Defender portal > Microsoft Sentinel > Threat management > Hunting

2. Explore Hunting Queries (Queries tab):
   • You'll see a library of pre-built hunting queries, often based on known TTPs (e.g., "PowerShell Empire Usage," "Unusual Azure AD Signins").
   • Filter queries by Tactics, Data sources, or Tags.
   • Click the **Run query** button next to a query to execute it.
   • The results will appear at the bottom. You can then refine the query in the Logs interface or take action.
3. Create Custom Hunting Queries:
   • From the Hunting page, click **+ New query**.
   • This opens the Logs interface where you can write your own KQL queries.
   • Once satisfied with your query, you can **Save** it as a new hunting query, or promote it to an analytics rule.
4. Bookmarks:
   • When running a hunting query in the Logs interface, if you find interesting events, you can "bookmark" them.
   • Select the relevant rows from the results, then click **Add bookmark** from the top bar.
   • Provide a name, notes, and map entities. This creates a record of your findings in the **Bookmarks** tab of the Hunting page.
   • From a bookmark, you can create a new incident or add it to an existing incident.

10. Automation (Playbooks & Automation Rules)

Automation in Sentinel consists of **Playbooks** (Azure Logic Apps for automated workflows) and **Automation Rules** (to automatically triage incidents and trigger playbooks).

A. Playbooks (Azure Logic Apps) - GUI Usage:

Automated, scalable, and customizable workflows triggered by Sentinel alerts or incidents.

1. Navigate to Automation:

   Microsoft Defender portal > Microsoft Sentinel > Configuration > Automation

2. Create Playbook:
   • Go to the **Playbooks** tab.
   • Click **+ Create** > **Blank playbook**. (This opens the Azure Logic App designer in a new browser tab).
   • Basics: Select **Subscription**, **Resource Group**, **Playbook name** (e.g., `BlockIPandNotify`). **Region**. Select **Plan type** (`Consumption` is typical).
   • Click **Review + create** > **Create**.
   • Once deployed, click **Go to resource** to open the Logic App designer.
   • Choose a trigger: Search for `Microsoft Sentinel` and select "When a Microsoft Sentinel incident is created".
   • Add actions:
     • Click **+ New step**. Search for an action (e.g., `Azure Firewall - Block IP address list`). Configure the action (firewall details, IP address from dynamic content of the incident entity).
     • Add another action (e.g., `Office 365 Outlook - Send an email (V2)`). Configure sender, recipient, subject (`Incident: @{triggerBody()?['properties']?['AlertDisplayName']}`), and body using dynamic content from the incident.
   • **Save** the Logic App.
   • Grant Permissions: Back in the Azure Portal (not Defender portal), navigate to your **Log Analytics Workspace** > **Access control (IAM)** > **+ Add** > **Add role assignment**. Grant the Logic App's Managed Identity (you'll find its name under "System assigned managed identity" in the Logic App's Identity blade) necessary permissions (e.g., `Azure Firewall Contributor` if blocking IPs, `Microsoft Sentinel Responder` if updating incident).

B. Automation Rules - GUI Usage:

Define rules to automatically triage incidents or trigger playbooks.

1. Navigate to Automation rules:

   Microsoft Defender portal > Microsoft Sentinel > Configuration > Automation

2. Create Automation Rule:
   • Go to the **Automation rules** tab.
   • Click **+ Create** > **Automation rule**.
   • **Rule name:** (e.g., `Trigger Block IP Playbook for Brute Force`).
   • **Trigger:** `When incident is created`.
   • **Conditions:** Add conditions to specify which incidents this rule applies to (e.g., `Analytics rule name` `Contains` `Brute Force Attempt from Single IP`).
   • **Actions:**
     • Select `Run playbook`.
     • Choose your `BlockIPandNotify` playbook.
   • Configure **Rule expiration** and **Order**.
   • Click **Apply**.

Now, when your "Brute Force Attempt from Single IP" analytics rule creates an incident, this automation rule will automatically trigger your "BlockIPandNotify" playbook.

11. Workbooks & Dashboards

Workbooks provide flexible and interactive canvases for data analysis and rich visualizations within Sentinel.

1. Navigate to Workbooks:

   Microsoft Defender portal > Microsoft Sentinel > Threat management > Workbooks

2. Explore Templates:
   • Go to the **Templates** tab.
   • Browse pre-built workbook templates for various data sources (e.g., Azure AD Sign-ins, Firewall logs).
   • Click on a template, then click **Save** to create a saved instance of the workbook in your workspace.
3. Create Custom Workbook:
   • Go to the **My workbooks** (or **Shared reports**) tab.
   • Click **+ Add workbook**.
   • This opens an empty workbook. Click **Edit**.
   • Click **Add** > **Add query**.
     • Data source: `Logs`.
     • Resource type: `Log Analytics`.
     • Workspace: Select your Sentinel workspace.
     • **KQL Query:** (e.g., `SigninLogs | summarize count() by ResultType | render piechart with (title="Sign-in Result Types")`).
     • Click **Run Query**.
     • Choose a **Visualization** type (e.g., `Pie chart`, `Bar chart`, `Grid`).
     • Click **Done editing**.
   • Add other elements like **Text**, **Parameters** (for interactive filters), **Links**.
   • Click **Save** (top toolbar). Provide a **Workbook name**, **Subscription**, **Resource group**, and **Location**. Click **Save**.

12. Threat Intelligence

Sentinel can ingest threat intelligence feeds to enrich your data and enhance detections, hunting, and investigations.

1. Navigate to Threat intelligence:

   Microsoft Defender portal > Microsoft Sentinel > Threat management > Threat intelligence

2. Manage Indicators:
   • You'll see a list of ingested threat indicators.
   • Click **+ Add new** to manually add indicators (e.g., a known malicious IP, domain, or file hash).
3. Data Connectors for TI:
   • Go to **Data connectors** and search for `Threat Intelligence - TAXII` (for STIX/TAXII feeds) or `Microsoft Defender Threat Intelligence`.
   • Follow the instructions on the connector page to configure ingestion from external TI platforms.
4. Using TI in Analytics Rules/Hunting: Indicators ingested into Sentinel populate the `ThreatIntelligenceIndicator` table, which you can use in your KQL queries.

   # Example: Find events matching ingested malicious IPs
   CommonSecurityLog
   | where TimeGenerated > ago(1d)
   | where DestinationIP in (ThreatIntelligenceIndicator | where Description contains "Malicious_IP_Feed" | project NetworkIP)

13. User & Entity Behavior Analytics (UEBA)

UEBA in Sentinel helps detect subtle, complex, and insider threats by identifying anomalous behavior from users and other entities (hosts, applications).

1. How it Works: Sentinel builds a baseline of normal behavior for each user/entity. Deviations from this baseline trigger alerts and are surfaced in entity pages.
2. Access Entity Pages:
   • From an incident, click on an **entity** (e.g., a user's name or a device name). This will open the Entity page in the Defender portal (or Azure AD for users).
   • The **Timeline** tab on the entity page will show a consolidated view of activities and alerts associated with that entity, including UEBA-driven anomalies.
   • Insights based on UEBA data are also visible on the **Overview** dashboard and within certain workbooks.
3. Configuration: UEBA functionality is largely enabled by connecting relevant data sources (e.g., Azure Active Directory Sign-in and Audit Logs, Windows Security Events, Syslog). Ensure your analytics rules map entities correctly.

14. Cost Management

Understanding and managing Sentinel costs is important as it's a pay-as-you-go service based primarily on data ingestion and data retention.

1. Primary Cost Driver: Data Ingestion (per GB).
2. Monitoring Costs (Azure Portal):

   Azure Portal > Subscription > Cost analysis

   • Filter by `Resource type` to see costs for `Log Analytics workspace` and `Microsoft Sentinel`.

   Azure Portal > Log Analytics workspace > Usage and estimated costs

   • Provides detailed breakdown of ingested data by solution (e.g., `SecurityInsights` for Sentinel, `Security` for Defender for Cloud).
3. Cost Optimization Strategies:
   • Filter data at source: Use data connector configurations or Log Analytics agent settings to only ingest necessary logs.
   • Daily Cap: Set a daily ingestion cap on your Log Analytics Workspace (Azure Portal > Log Analytics workspace > Usage and estimated costs > Daily cap). This prevents unexpected spikes but can impact security visibility if reached.
   • Retention Period: Adjust log retention to balance cost and compliance needs (Azure Portal > Log Analytics workspace > Usage and estimated costs > Data retention).
   • Pricing Tiers: Consider commitment tiers for predictable, high-volume ingestion.
   • Tune Analytics Rules: Reduce false positives that generate unnecessary alerts and data.

15. Best Practices & Troubleshooting

A. Best Practices:

• Phased Deployment: Deploy Sentinel in phases, starting with essential data connectors and a pilot group.
• KQL Mastery: Continuously learn and practice KQL for effective hunting, investigation, and rule creation.
• Tune Analytics Rules: Regularly review and fine-tune rules to minimize false positives and maximize true positives. Use the "Play with current query in Log Analytics" option to refine rules.
• Leverage Built-in Content: Explore the vast library of out-of-the-box data connectors, analytics rules, workbooks, and hunting queries in the **Content Hub**.
• Implement Automation: Use **Automation Rules** and **Playbooks** to automate repetitive tasks for faster response and reduced analyst workload.
• Integrate Threat Intelligence: Enrich your detections with relevant IOCs from various sources.
• Use Incidents Effectively: Triage, investigate, assign, and close incidents systematically. Leverage the Investigation Graph.
• Regular Hunting: Proactively search for threats that evade automated detections.
• Monitor Costs: Keep a close eye on data ingestion and retention costs.
• Security Hygiene: Sentinel is powerful, but good foundational security practices (patching, MFA, least privilege) are still critical.

B. Troubleshooting:

• Data Ingestion:
  • Check the **Data Connectors** page for "Last Data Received" status.
  • Run simple `<TableName> | take 10` queries in **Logs** to verify data flow.
  • For agent-based connectors, verify the Log Analytics agent status on the source machine and check relevant system logs.
  • Check network connectivity and firewall rules between data sources and the Log Analytics workspace.
• Alerts Not Firing:
  • Check the **Analytics rules** page for the rule's status (Enabled/Disabled).
  • Go to the rule's **Edit** page > **Set rule logic** tab > **Play with current query in Log Analytics** to manually run the KQL query. Does it return results?
  • Verify "Query scheduling" and "Alert threshold" in the rule configuration.
  • Ensure data relevant to the rule is actually being ingested into the correct tables.
• Incident Not Created/Playbook Not Running:
  • Check the **Analytics rule**'s "Automated response" tab to ensure a playbook is attached.
  • Go to **Automation rules** and verify the rule is configured correctly to trigger for your incident type and that its conditions are met.
  • For Playbooks, go to the specific Logic App in the Azure Portal (search for "Logic apps") and check its **Run history** for failures and details.
  • Verify permissions of the Playbook's Managed Identity (IAM roles).
• Permissions: Double-check that your user account or service principal has the necessary Azure RBAC roles for the operations you're trying to perform.
• Resource Health: Monitor the health and performance of your Log Analytics Workspace in Azure Monitor (Azure Portal > Log Analytics workspaces).
• Microsoft Learn & Community: The official Microsoft Sentinel documentation and the Microsoft Tech Community are excellent resources for troubleshooting.