📌 Project Overview

In this project, I built an end-to-end Security Information and Event Management (SIEM) and Security Orchestration Automated Response (SOAR) system using Microsoft Sentinel.

I designed the environment with this mindset:

Every configuration must prevent a real security risk, and every automation must reduce response time.

This project simulates real enterprise SOC operations by implementing:

• Log Analytics Workspace for centralized security logs
• Microsoft Sentinel for threat detection
• Data connectors for identity, cloud activity, and workload security
• Analytics rules (built-in + custom KQL detections)
• Playbooks (Logic Apps) for automated response
• Automated disabling of compromised accounts
• Real-time alerting
• A custom security dashboard (workbook)

Architecture Overview

Resource Group (security-lab-rg)
│
├─ Log Analytics Workspace (sentinel-workspace)
│
├─ Microsoft Sentinel
│   ├─ Data Connectors
│   ├─ Analytics Rules
│   ├─ Automation Rules
│   └─ Workbooks
│
└─ Logic Apps (sentinel-auto-disable-user)
      ├─ Trigger: When Sentinel Incident is Created
      ├─ Action: Send Email Notification
      └─ Action: Disable Compromised User

1️⃣ Created the Log Analytics Workspace

What I Did

• Created a new workspace named sentinel-workspace

• Placed it in security-lab-rg
• Ensured all other resources use the same region

Why I Did It

• Sentinel relies on a workspace to store and query logs
• A dedicated workspace ensures clean log boundaries
• Keeps costs predictable and centralized

What Risk It Prevents

• Prevents log fragmentation and missing telemetry
• Avoids misconfigured Sentinel deployments that cannot ingest logs
• Ensures compliance-ready logging

2️⃣ Deployed Microsoft Sentinel

What I Did

• Enabled Microsoft Sentinel on sentinel-workspace

• Confirmed onboarding through the Sentinel overview dashboard

Why I Did It

• Sentinel provides threat detection, investigation, hunting, and incident management

What Risk It Prevents

• Prevents blind spots in cloud security
• Ensures unified visibility across identity, cloud workloads, and endpoints

3️⃣ Connected Critical Security Data Sources

A. Azure Activity Logs

What I Did

• Connected Azure subscription activity logs

Why

Tracks:

• Resource creation
• Privilege escalation
• Policy changes

What Risk It Prevents

• Detects rogue admins
• Prevents unnoticed infrastructure changes

B. Entra ID (Azure AD) Sign-In + Audit Logs

What I Did

Enabled:

• Sign-in logs
• Audit logs

Why

These logs are the backbone of identity threat detection.

What Risk It Prevents

• Detects brute-force attacks
• Impossible travel activities
• Unauthorized MFA bypass attempts

C. Defender for Cloud Alerts

What I Did

Enabled Defender for:

• Servers
• App services
• Cloud security posture management

Why

To ingest advanced workload-level alerts directly into Sentinel.

What Risk It Prevents

• Malware infections
• VM vulnerabilities
• SQL injection attempts
• Misconfigurations

4️⃣ Enabled Built-In Analytics Rules

What I Did

Turned on rules such as:

• Suspicious authentication patterns
• Impossible travel
• Lateral movement detection

Why

Built-in Microsoft rules provide enterprise-grade threat intelligence out-of-the-box.

What Risk It Prevents

• Prevents identity-based breaches
• Stops attackers early in the kill chain
• Detects anomalous access attempts

5️⃣ Built a Custom Detection Rule (KQL)

What I Did

Created a scheduled analytic rule using this KQL:

SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType == 0
| where IPAddress has "192.168." or IPAddress has "10."
| summarize by UserPrincipalName, IPAddress
| extend Alert = "Potential use of internal IP after external login"

Why

This rule detects unusual behavior where:

• A user logs in successfully
• From an internal IP
• Right after external access

This is a strong sign of token theft or session hijacking.

What Risk It Prevents

• Prevents lateral movement
• Detects compromised user accounts
• Identifies suspicious hybrid-network login patterns

6️⃣ Built a SOAR Playbook — Automated Response

What I Did

Created a Logic App named sentinel-auto-disable-user.

Steps included:

Trigger

• When Microsoft Sentinel Incident is created

Action 1 — Send Security Email

Email content included:

• User UPN from the incident
• Incident ID
• Severity level

Action 2 — Disable Compromised User

Used Azure AD connector → Disable User

Dynamic input:

• Account UPN from Sentinel incident

Why I Did It

Automating response:

• Reduces Mean Time To Respond (MTTR)
• Prevents attackers using compromised accounts
• Ensures high-severity threats trigger immediate action

What Risk It Prevents

• Stops active lateral movement
• Prevents further access after detected compromise
• Eliminates delayed human response

7️⃣ Created an Automation Rule in Sentinel

What I Did

Connected:

• IF severity is High
• THEN run playbook sentinel-auto-disable-user

Why

This ties detection → response into a single automated workflow.

What Risk It Prevents

• No dependency on manual SOC review
• Prevents delayed response to critical threats
• Stops attackers the moment high-risk activity is detected

8️⃣ Built a Sentinel Security Dashboard (Workbook)

What I Did

Created a visual workbook with:

• Line chart: incidents over time
• Bar chart: severity distribution
• Table: last 10 incidents
• Custom KPIs

Why

SOC analysts need instant visibility and correlation.

What Risk It Prevents

• Prevents slow investigation
• Reduces overlooked incidents
• Gives leadership security insights at a glance

⚠️ Challenges I Faced & How I Solved Them

❗ 1. Sentinel Logic App Trigger Failing

Cause: "Incident not defined" errors due to missing dynamic content.

Fix: Used the correct trigger → Microsoft Sentinel Incident Trigger

Lesson: Not all connectors support Sentinel incidents.

❗ 2. Missing User Entity in Incident Body

Cause: Some incidents didn’t include UPN entities.

Fix: Adjusted rule mappings & selected "User Account" entity

Lesson: Incidents vary based on rule configuration.

❗ 3. Logic App Validation Errors

Cause: Incorrect parameter name referencing a non-existing action block.

Fix: Rebuilt the playbook cleanly using correct dynamic entities

Lesson: SOAR automation must be designed cleanly from scratch if corrupted.

❗ 4. Confusion with Data Connectors

Cause: Unsure which logs were necessary or paid.

Fix: Used only free-tier identity logs + defender trial

Lesson: Cost optimization matters in SIEM deployments.

❗ 5. Stuck on how to extract UPN from incident JSON

Solution:

Used expression:

@{triggerBody()?['Entities'][0]['UPN']}

Lesson: Understanding Sentinel incident structure is crucial for automation.

✅ What I Achieved

By completing this project, I successfully deployed:

✔ A fully operational SIEM (Sentinel)

✔ A real-world SOAR pipeline

✔ Automated high-severity responses

✔ Prevented compromised accounts from accessing systems

✔ Custom detections using KQL

✔ Security dashboard for monitoring

✔ Full visibility into identity, cloud activity, and workloads

This mirrors what real SOC/Cloud Security Engineers do in enterprise environments.