Microsoft Sentinel: SOAR thực chiến – tự động block user, gửi alert Teams, và tạo ticket khi có incident

Chào các bạn!

Ở bài 7, mình đã deploy Sentinel, kết nối dữ liệu, và tạo analytics rules để phát hiện threat. Nhưng phát hiện chỉ là nửa câu chuyện – response mới là thứ quyết định thiệt hại.

Thực tế mình hay thấy: một incident được phát hiện lúc 2 giờ sáng, nhưng analyst đầu tiên nhìn thấy nó là 8 giờ sáng hôm sau. Trong 6 tiếng đó, attacker có thể đã làm rất nhiều thứ.

SOAR (Security Orchestration, Automation, and Response) giải quyết vấn đề này: tự động thực hiện các bước response đầu tiên ngay khi incident được tạo – không cần chờ người.

Bài này mình sẽ xây 4 playbooks thực chiến:

  1. Gửi notification vào Teams khi có High/Critical incident
  2. Tự động block user bị compromise trong Entra ID
  3. Tự động tạo ticket qua email (hoặc ServiceNow nếu có)
  4. Thu thập thêm context về user và device trước khi analyst vào điều tra

Hai tầng automation trong Sentinel

Sentinel có 2 tầng automation với mức độ phức tạp khác nhau:

Tầng 1: Automation Rules (không cần code)
├── Trigger: khi incident được tạo hoặc update
├── Condition: severity = High, rule name contains "...", v.v.
└── Action: assign analyst, change status, add tag, chạy playbook

Tầng 2: Playbooks (Logic Apps — low-code)
├── Trigger: từ Automation Rule, hoặc thủ công
├── Steps: gọi API, gửi email/Teams, update Entra ID, tạo ticket...
└── Có thể làm bất cứ thứ gì có API

Automation Rules là nơi bắt đầu – nhanh, không cần code, xử lý triage cơ bản. Playbooks là nơi làm những thứ phức tạp hơn – gọi API ngoài, thực hiện response actions, thu thập thông tin.

Điều kiện cần

Yêu cầuChi tiết
SentinelĐã deploy và có incidents — xem bài 7
Azure Logic AppsCó sẵn trong cùng subscription
Quyền SentinelMicrosoft Sentinel Contributor để tạo automation rules
Quyền Logic AppsLogic App Contributor để tạo và sửa playbooks
Quyền Entra IDUser Administrator để block user từ playbook

Bước 1: Cấp quyền cho Sentinel để chạy playbooks

Sentinel cần quyền để trigger Logic Apps. Đây là bước hay bị quên.

  1. Vào Azure portal → tìm resource group chứa Sentinel → Access control (IAM)
  2. + Add → Add role assignment
  3. Role: Microsoft Sentinel Automation Contributor
  4. Assign to: Microsoft Sentinel (managed identity của workspace)
  5. Save

Nếu bỏ qua bước này, playbook sẽ không trigger được từ automation rule và báo lỗi permission denied.

Bước 2: Automation Rules – triage tự động không cần code

Automation rules xử lý được nhiều việc tẻ nhạt mà analyst hay phải làm thủ công.

Rule 1: tự động assign incident theo severity

  1. Sentinel → Automation → + Create → Automation rule
  2. Đặt tên: Auto-assign High and Critical incidents
  3. Trigger: When incident is created
  4. Conditions:
    • Incident severity → Contains → High, Critical
  5. Actions:
    • Assign owner: chọn analyst hoặc nhóm SOC
    • Change status: Active
    • Add tags: auto-assigned
  6. Order: 1 (chạy trước)
  7. Save

Rule 2: tự động đóng false positive từ nguồn tin cậy

Một số alert thường xuyên là false positive (ví dụ: vulnerability scanner nội bộ trigger network detection rule). Thay vì analyst phải đóng thủ công mỗi ngày:

  1. Tạo rule mới: Auto-close - Internal vulnerability scanner
  2. Trigger: When incident is created
  3. Conditions:
    • Analytics rule name → Contains → [tên rule hay false positive]
    • Incident title → Contains → [IP của scanner nội bộ]
  4. Actions:
    • Change status: Closed
    • Change classification: False positive – incorrect alert logic
    • Add comment: Auto-closed: known false positive from internal scanner
  5. Save

Rule 3: tự động add tag để phân loại

  1. Tạo rule: Tag — Identity related incidents
  2. Conditions: Analytics rule name → Contains → IdentityEntraAADUser
  3. Actions: Add tags → identity-threat
  4. Save

Sau khi có tags, analyst có thể filter incident queue theo tag để xử lý theo nhóm.

Bước 3: Playbook 1 – gửi notification vào Microsoft Teams

Playbook này tự động gửi adaptive card vào Teams channel khi có High/Critical incident, bao gồm link trực tiếp đến incident.

3a. Tạo playbook từ template

  1. Sentinel → Automation → Playbook templates (tab)
  2. Tìm Notify-Teams-On-Incident hoặc tương tự → Create playbook

Nếu không có template phù hợp, tạo từ đầu:

  1. Sentinel → Automation → + Create → Playbook with incident trigger
  2. Đặt tên: Notify-Teams-High-Incident
  3. Region: Southeast Asia
  4. Create

[screenshot: tạo playbook, chọn incident trigger, điền tên]

3b. Thiết kế Logic App flow

Sau khi tạo, Logic App Designer mở ra. Đã có sẵn trigger Microsoft Sentinel incident.

Thêm step: Parse incident entities

  1. + New step → tìm Microsoft Sentinel → Entities – Get Accounts
  2. Input: Entities từ trigger (dynamic content)

Thêm step: Post message to Teams

  1. + New step → tìm Microsoft Teams → Post adaptive card and wait for a response (hoặc Post message in a chat or channel)
  2. Post as: Flow bot
  3. Post in: Channel
  4. Team: chọn team SOC của bạn
  5. Channel: #security-incidents
  6. Message:
⚠️ NEW SECURITY INCIDENT

Severity: @{triggerBody()?['object']?['properties']?['severity']}
Title: @{triggerBody()?['object']?['properties']?['title']}
Status: @{triggerBody()?['object']?['properties']?['status']}
Time: @{triggerBody()?['object']?['properties']?['createdTimeUtc']}

Incident URL: @{triggerBody()?['object']?['properties']?['incidentUrl']}

Affected entities: @{body('Entities_-_Get_Accounts')?['Accounts']}
  1. Save playbook

3c. Test playbook

  1. Mở một incident trong Sentinel
  2. Run playbook (button trong incident page)
  3. Chọn playbook vừa tạo → Run
  4. Kiểm tra Teams channel – message có xuất hiện không

Bước 4: Playbook 2 – tự động block user bị compromise

Đây là playbook quan trọng nhất – khi có alert “user confirmed compromised” hoặc user risk = High, tự động revoke sessions và disable account ngay lập tức.

4a. Tạo playbook

  1. Sentinel → Automation → + Create → Playbook with incident trigger
  2. Đặt tên: Respond-Block-Compromised-User
  3. Create

4b. Thiết kế flow

Step 1: Get account entities

  • Action: Entities – Get Accounts (Microsoft Sentinel)
  • Input: Entities từ trigger

Step 2: Loop qua từng account

  • Action: For each (Control)
  • Input: Accounts từ step 1

Bên trong For each loop:

Step 3: Revoke user sessions

  • Action: HTTP (gọi Microsoft Graph API)
  • Method: POST
  • URI: https://graph.microsoft.com/v1.0/users/@{items('For_each')?['Name']}/revokeSignInSessions
  • Authentication: Managed Identity
  • Audience: https://graph.microsoft.com

Step 4: Disable user account

  • Action: HTTP
  • Method: PATCH
  • URI: https://graph.microsoft.com/v1.0/users/@{items('For_each')?['AadUserId']}
  • Body:
{
  "accountEnabled": false
}
  • Authentication: Managed Identity

Step 5: Add comment vào incident

  • Action: Add comment to incident (V3) (Microsoft Sentinel)
  • Incident ARM ID: từ trigger
  • Comment:
🔒 AUTOMATED RESPONSE EXECUTED

User @{items('For_each')?['Name']} has been automatically:
1. All sign-in sessions revoked
2. Account disabled

Reason: High-risk incident - @{triggerBody()?['object']?['properties']?['title']}
Time: @{utcNow()}

ACTION REQUIRED: Investigate incident and re-enable account after verification.

4c. Cấp quyền Graph API cho Managed Identity

Playbook dùng Managed Identity để gọi Graph API – cần cấp quyền trước.

  1. Lấy Object ID của Logic App managed identity:
    • Vào Logic App → Identity → tab System assigned → copy Object ID
  2. Chạy PowerShell để cấp quyền:
# Cài module nếu chưa có
Install-Module Microsoft.Graph -Scope CurrentUser

Connect-MgGraph -Scopes "Application.Read.All", "AppRoleAssignment.ReadWrite.All", "Directory.Read.All"

$ManagedIdentityId = "[Object ID của Logic App]"

# Tìm Microsoft Graph service principal
$GraphSP = Get-MgServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'"

# Cấp quyền User.ReadWrite.All
$AppRole = $GraphSP.AppRoles | Where-Object {$_.Value -eq "User.ReadWrite.All"}
New-MgServicePrincipalAppRoleAssignment `
    -ServicePrincipalId $ManagedIdentityId `
    -PrincipalId $ManagedIdentityId `
    -ResourceId $GraphSP.Id `
    -AppRoleId $AppRole.Id

4d. Test với user test

Tạo một user test, chạy playbook thủ công từ incident có user đó, kiểm tra account có bị disable không.

Bước 5: Playbook 3 – thu thập context trước khi analyst vào

Playbook này tự động thu thập thêm thông tin về user và device bị ảnh hưởng, rồi ghi vào comment của incident. Khi analyst vào thì context đã sẵn sàng – tiết kiệm 10-15 phút điều tra ban đầu.

5a. Tạo playbook

Tên: Enrich-Incident-With-Context

5b. Thiết kế flow

Step 1: Get accounts và devices

  • Entities – Get Accounts
  • Entities – Get Hosts

Step 2: Loop qua từng account, lấy sign-in history

HTTP GET https://graph.microsoft.com/v1.0/auditLogs/signIns
    ?$filter=userPrincipalName eq '@{items('For_each')?['Name']}'
    &$top=5
    &$orderby=createdDateTime desc
Authentication: Managed Identity

Step 3: Loop qua device, lấy MDE risk level

HTTP GET https://api.securitycenter.microsoft.com/api/machines
    ?$filter=computerDnsName eq '@{items('For_each_device')?['HostName']}'
Authentication: Managed Identity
Audience: https://api.securitycenter.microsoft.com

Step 4: Compose comment tổng hợp

📊 AUTOMATED CONTEXT ENRICHMENT

=== USER INFORMATION ===
User: @{items('For_each')?['Name']}
Last 5 sign-ins:
@{body('Parse_JSON_signins')?['value']}

=== DEVICE INFORMATION ===
Device: @{items('For_each_device')?['HostName']}
MDE Risk Level: @{body('Parse_JSON_mde')?['value']?[0]?['riskScore']}
Last seen: @{body('Parse_JSON_mde')?['value']?[0]?['lastSeen']}
Health state: @{body('Parse_JSON_mde')?['value']?[0]?['healthStatus']}

=== RECOMMENDED NEXT STEPS ===
1. Review sign-in locations in Azure AD
2. Check device timeline in Defender portal
3. Verify with user's manager if activity is expected

Step 5: Add comment vào incident

Bước 6: Kết nối playbooks vào Automation Rules

Sau khi có playbooks, kết nối chúng vào automation rules để chạy tự động.

  1. Sentinel → Automation → + Create → Automation rule
  2. Đặt tên: SOAR — High incident full response
  3. Trigger: When incident is created
  4. Conditions: Severity → Equals → High, Critical
  5. Actions (theo thứ tự):
    • Order 1: Run playbook → Enrich-Incident-With-Context
    • Order 2: Run playbook → Notify-Teams-High-Incident
    • Order 3: Assign owner → [SOC lead]
    • Order 4: Add tags → soar-processed
  6. Save

Automation rule riêng cho compromise

  1. Tạo rule mới: SOAR — Block compromised user
  2. Conditions:
    • Analytics rule name → Contains → compromisedcredentialrisky user
    • Severity → Equals → High, Critical
  3. Actions:
    • Run playbook → Respond-Block-Compromised-User
    • Add tags → user-blocked
  4. Save

Bước 7: Monitor và debug playbook runs

Sau khi deploy, phải theo dõi playbook có chạy đúng không.

Xem run history trong Logic Apps

  1. Vào Azure portal → Logic Apps → chọn playbook
  2. Runs history – danh sách tất cả lần chạy, trạng thái Succeeded/Failed

[screenshot: Logic App runs history, danh sách runs với timestamp, duration, và status]

  1. Click vào một run để xem chi tiết từng step:
    • Step màu xanh: thành công
    • Step màu đỏ: thất bại — click để xem error message

Lỗi thường gặp

LỗiNguyên nhânCách sửa
401 UnauthorizedManaged Identity chưa có quyềnChạy lại PowerShell cấp quyền
403 ForbiddenKhông đủ quyền APIKiểm tra app role được cấp
404 Not FoundUser/device ID saiKiểm tra dynamic content expression
Connection timeoutLogic App không kết nối được APIKiểm tra network/firewall
Playbook không triggerSentinel không có quyền chạy Logic AppKiểm tra lại bước 1

Xem playbook runs từ Sentinel

  1. Sentinel → Automation → tab Active playbooks
  2. Chọn playbook → View run logs

[screenshot: Sentinel Active playbooks, playbook với số lần run và success rate]

Bước 8: Tổng hợp – luồng response hoàn chỉnh

Sau khi setup xong, đây là luồng tự động khi có High incident:

Incident được tạo (từ analytics rule)
        │
        ▼
Automation Rule trigger
        │
        ├─► Playbook: Enrich-Incident-With-Context
        │       └─► Comment thêm: sign-in history, MDE risk level
        │
        ├─► Playbook: Notify-Teams-High-Incident
        │       └─► Teams message với link incident
        │
        ├─► Assign to SOC lead
        │
        └─► Tag: soar-processed

        [Nếu có "compromised user" signal]
        │
        ▼
Automation Rule: Block compromised user
        │
        └─► Playbook: Respond-Block-Compromised-User
                ├─► Revoke all sessions
                ├─► Disable account
                └─► Comment: ghi lại hành động

Kết quả: Khi SOC analyst vào làm việc buổi sáng, incident đã có đầy đủ context, user đã bị block nếu cần, và Teams channel đã có notification từ đêm qua. Thời gian analyst cần để bắt đầu điều tra thực sự giảm từ 30-45 phút xuống còn 5-10 phút.

[screenshot: incident trong Sentinel sau khi tất cả playbooks chạy xong - comments tự động, tags, owner được assign]

Tổng kết những gì đã làm

Sau bài này, bạn đã có:

  • 3 Automation Rules xử lý triage tự động: assign, close false positive, tag
  • Playbook 1: notify Teams khi có High/Critical incident
  • Playbook 2: tự động block user bị compromise – revoke sessions + disable account
  • Playbook 3: enrich incident với sign-in history và MDE risk level
  • Luồng SOAR hoàn chỉnh: từ incident creation đến context enrichment, notification, và response

Tài liệu tham khảo


Bài viết có gì chưa rõ hoặc bạn gặp lỗi ở bước nào, cứ để lại comment bên dưới – mình sẽ cập nhật bài.

Long Trần | khongkho.com