Azure Sentinel for SIEM - Mini Project: Build & Apply

Azure Sentinel for SIEM

📖 Scenario: You are a security analyst setting up Azure Sentinel to monitor security events in your cloud environment. Azure Sentinel helps collect, detect, and respond to threats using data from various sources.

🎯 Goal: Build a simple Azure Sentinel workspace, connect a data source, create a detection rule, and enable alerting to monitor security events effectively.

📋 What You'll Learn

Create an Azure Sentinel workspace resource

Connect a data source (e.g., Azure Active Directory logs)

Create a detection rule using Kusto Query Language (KQL)

Enable alerting on the detection rule

💡 Why This Matters

🌍 Real World

Azure Sentinel is used by security teams to monitor cloud and on-premises environments for threats and respond quickly.

💼 Career

Skills in setting up and managing Azure Sentinel are valuable for cloud security engineers and analysts.

1

Create an Azure Sentinel workspace

Create an Azure Sentinel workspace resource named sentinelWorkspace in the resource group SecurityRG with location eastus.

Azure

# Your code here to create sentinelWorkspace resource

Hint

Use Azure Resource Manager (ARM) template or Bicep syntax to create the workspace and enable Sentinel.

2

Connect Azure Active Directory logs as data source

Add a data connector resource named aadConnector to connect Azure Active Directory logs to the sentinelWorkspace.

Azure

resource sentinelWorkspace 'Microsoft.OperationalInsights/workspaces@2021-06-01' = {
  name: 'sentinelWorkspace'
  location: 'eastus'
  properties: {
    sku: {
      name: 'PerGB2018'
    }
  }
}

resource sentinel 'Microsoft.SecurityInsights/sentinelOnboarding@2021-03-01-preview' = {
  name: '${sentinelWorkspace.name}/default'
  dependsOn: [sentinelWorkspace]
  properties: {}
}

# Your code here to add aadConnector resource

Hint

Use the dataConnectors resource type and enable signInLogs and auditLogs.

3

Create a detection rule with KQL query

Create a scheduled analytics rule resource named failedSignInRule in sentinelWorkspace that detects failed sign-in attempts using this KQL query: SigninLogs | where ResultType != 0. Set the rule to run every 5 minutes.

Azure

resource sentinelWorkspace 'Microsoft.OperationalInsights/workspaces@2021-06-01' = {
  name: 'sentinelWorkspace'
  location: 'eastus'
  properties: {
    sku: {
      name: 'PerGB2018'
    }
  }
}

resource sentinel 'Microsoft.SecurityInsights/sentinelOnboarding@2021-03-01-preview' = {
  name: '${sentinelWorkspace.name}/default'
  dependsOn: [sentinelWorkspace]
  properties: {}
}

resource aadConnector 'Microsoft.SecurityInsights/dataConnectors@2021-03-01-preview' = {
  name: '${sentinelWorkspace.name}/AzureActiveDirectory'
  dependsOn: [sentinel]
  properties: {
    dataTypes: {
      signInLogs: {
        state: 'Enabled'
      }
      auditLogs: {
        state: 'Enabled'
      }
    }
  }
}

# Your code here to add failedSignInRule resource

Hint

Use the alertRules resource type and set queryFrequency and queryPeriod to 5 minutes (PT5M).

4

Enable alerting on the detection rule

Add an alert rule action group named emailActionGroup to failedSignInRule that sends email notifications to [e-mail] when the rule triggers.

Azure

resource sentinelWorkspace 'Microsoft.OperationalInsights/workspaces@2021-06-01' = {
  name: 'sentinelWorkspace'
  location: 'eastus'
  properties: {
    sku: {
      name: 'PerGB2018'
    }
  }
}

resource sentinel 'Microsoft.SecurityInsights/sentinelOnboarding@2021-03-01-preview' = {
  name: '${sentinelWorkspace.name}/default'
  dependsOn: [sentinelWorkspace]
  properties: {}
}

resource aadConnector 'Microsoft.SecurityInsights/dataConnectors@2021-03-01-preview' = {
  name: '${sentinelWorkspace.name}/AzureActiveDirectory'
  dependsOn: [sentinel]
  properties: {
    dataTypes: {
      signInLogs: {
        state: 'Enabled'
      }
      auditLogs: {
        state: 'Enabled'
      }
    }
  }
}

resource failedSignInRule 'Microsoft.SecurityInsights/alertRules@2021-03-01-preview' = {
  name: '${sentinelWorkspace.name}/FailedSignInAttempts'
  dependsOn: [aadConnector]
  properties: {
    displayName: 'Detect Failed Sign-In Attempts'
    description: 'Detects failed sign-in attempts from Azure AD logs'
    severity: 'Medium'
    enabled: true
    queryFrequency: 'PT5M'
    queryPeriod: 'PT5M'
    query: 'SigninLogs | where ResultType != 0'
    triggerOperator: 'GreaterThan'
    triggerThreshold: 0
    tactics: [ 'InitialAccess' ]
    alertDetailsOverride: {
      alertDisplayNameFormat: 'Failed sign-in detected for {{Account}}'
    }
  }
}

# Your code here to add emailActionGroup to failedSignInRule

Hint

Create an actionGroups resource with the email receiver and link it in the actions array of the alert rule.

Practice

1. What is the main purpose of Azure Sentinel in security management?

easy

A. To provide cloud storage for application data

B. To collect and analyze security data for threat detection

C. To manage user passwords and authentication

D. To store backups of all user files

Solution

1. Step 1: Understand Azure Sentinel's role

   Azure Sentinel is designed to collect security data from various sources to detect threats.

2. Step 2: Compare options with Sentinel's function

   Only To collect and analyze security data for threat detection describes collecting and analyzing security data for threat detection, which matches Sentinel's purpose.

3. Final Answer:

   To collect and analyze security data for threat detection -> Option B

4. Quick Check:

   Azure Sentinel = threat detection [OK]

Hint: Remember: Sentinel = security data + threat detection [OK]

Common Mistakes:

• Confusing Sentinel with backup or storage services
• Thinking Sentinel manages passwords directly
• Assuming Sentinel is just cloud storage

2. Which of the following is the correct way to create an alert rule query in Azure Sentinel using Kusto Query Language (KQL)?

easy

A. GET SecurityEvent WHERE EventID = 4625

B. SELECT * FROM SecurityEvent WHERE EventID = 4625

C. FIND SecurityEvent WITH EventID 4625

D. SecurityEvent | where EventID == 4625

Solution

1. Step 1: Identify the query language used in Azure Sentinel

   Azure Sentinel uses Kusto Query Language (KQL), which uses pipe operators and 'where' clauses.

2. Step 2: Match the syntax to KQL

   SecurityEvent | where EventID == 4625 uses KQL syntax correctly: table name, pipe, and 'where' condition. Other options use SQL or invalid syntax.

3. Final Answer:

   SecurityEvent | where EventID == 4625 -> Option D

4. Quick Check:

   KQL uses pipes and 'where' [OK]

Hint: KQL uses pipes (|) and 'where' for filters [OK]

Common Mistakes:

• Using SQL syntax instead of KQL
• Missing pipe operator in query
• Using incorrect keywords like GET or FIND

3. Given the following KQL query in Azure Sentinel alert rule:
SecurityEvent | where EventID == 4625 | summarize count() by Account
What does this query output?

medium

A. A count of all events without grouping

B. A list of all successful login events

C. A count of failed login attempts grouped by user account

D. A list of accounts with no login attempts

Solution

1. Step 1: Analyze the query filters and aggregation

   The query filters SecurityEvent for EventID 4625, which means failed login attempts, then counts them grouped by Account.

2. Step 2: Understand the summarize clause

   'summarize count() by Account' groups results by Account and counts events per account.

3. Final Answer:

   A count of failed login attempts grouped by user account -> Option C

4. Quick Check:

   EventID 4625 = failed logins, grouped count = A count of failed login attempts grouped by user account [OK]

Hint: EventID 4625 means failed login; summarize groups counts [OK]

Common Mistakes:

• Confusing EventID 4625 with successful logins
• Ignoring the grouping by Account
• Thinking it lists accounts without attempts

4. You wrote this KQL alert rule query in Azure Sentinel:
SecurityEvent | where EventID = 4625 | summarize count() by Account
Why does this query fail to run correctly?

medium

A. Because the equality operator should be '==' not '=' in KQL

B. Because 'summarize' cannot be used with 'count()'

C. Because 'Account' is not a valid field in SecurityEvent

D. Because 'where' clause must come after 'summarize'

Solution

1. Step 1: Check the operator syntax in the 'where' clause

   KQL requires '==' for equality comparison, not a single '=' which is assignment in some languages.

2. Step 2: Validate other parts of the query

   'summarize count() by Account' is valid, and 'Account' is a common field. 'where' must come before 'summarize'.

3. Final Answer:

   Because the equality operator should be '==' not '=' in KQL -> Option A

4. Quick Check:

   KQL equality uses '==' not '=' [OK]

Hint: Use '==' for equality in KQL, not '=' [OK]

Common Mistakes:

• Using single '=' instead of '==' in KQL
• Misplacing 'where' after 'summarize'
• Assuming 'count()' is invalid with 'summarize'

5. You want to create an Azure Sentinel alert that triggers when there are more than 5 failed login attempts from the same account within 10 minutes. Which KQL query correctly implements this logic?

hard

A. SecurityEvent | where EventID == 4625 | where TimeGenerated > ago(10m) | summarize FailedAttempts = count() by Account | where FailedAttempts > 5

B. SecurityEvent | where EventID == 4625 | summarize count() by Account | where count_ > 5

C. SecurityEvent | where EventID == 4625 and TimeGenerated < ago(10m) | summarize count() by Account | where count_ > 5

D. SecurityEvent | where EventID == 4625 | summarize count() by Account, TimeGenerated | where count_ > 5

Solution

1. Step 1: Filter failed login events within last 10 minutes

   SecurityEvent | where EventID == 4625 | where TimeGenerated > ago(10m) | summarize FailedAttempts = count() by Account | where FailedAttempts > 5 uses 'where TimeGenerated > ago(10m)' to filter recent events correctly.

2. Step 2: Group by Account and count attempts, then filter counts over 5

   SecurityEvent | where EventID == 4625 | where TimeGenerated > ago(10m) | summarize FailedAttempts = count() by Account | where FailedAttempts > 5 summarizes counts by Account and filters where count > 5, matching the requirement.

3. Final Answer:

   SecurityEvent | where EventID == 4625 | where TimeGenerated > ago(10m) | summarize FailedAttempts = count() by Account | where FailedAttempts > 5 -> Option A

4. Quick Check:

   Filter by time + count > 5 per account = SecurityEvent | where EventID == 4625 | where TimeGenerated > ago(10m) | summarize FailedAttempts = count() by Account | where FailedAttempts > 5 [OK]

Hint: Filter time first, then count and filter by count > 5 [OK]

Common Mistakes:

• Not filtering events by time range
• Using incorrect logical operators in filters
• Grouping by TimeGenerated causing wrong counts