05 Microsoft Sentinel

A SIEM is valuable only when it helps you turn security telemetry into detection, investigation, and response.

Welcome to the Microsoft Sentinel Lab.

In the previous Azure security labs, you worked with:

• Azure RBAC

• Microsoft Entra ID Security

• Azure Network Security

• Microsoft Defender for Cloud

Now you will bring these telemetry sources together and focus on:

How do we detect suspicious activity, investigate incidents, hunt for threats, and decide what happens next?

This lab moves you from:

I know what Microsoft Sentinel is.

to:

I can use security telemetry and KQL to investigate Azure and Microsoft security activity systematically.

This lab is especially relevant for:

• SOC Analysts

• Security Operations Analysts

• Microsoft Sentinel Analysts

• Cloud Security Analysts

• Detection Engineers

• Incident Responders

• Azure Security Engineers

🎯 Mission Information

Item	Details
Lab	Microsoft Sentinel
Difficulty	Beginner → Intermediate
Estimated Time	2–4 hours
Primary Focus	SIEM, Detection, Investigation & Threat Hunting
Target Roles	SOC Analyst, Security Operations Analyst, Cloud Security Analyst
Certification Alignment	SC-200, AZ-500, SC-100
Career Skill	Security Monitoring & Incident Investigation
Environment	Azure / Microsoft Sentinel lab workspace
Cost Awareness	Log ingestion, retention, and some integrated services can generate charges

⚠️ Cost Awareness

Microsoft Sentinel and Log Analytics can generate charges based on:

• data ingestion

• retention

• connected data sources

• query/storage design

For this lab:

• use a small workspace

• connect only required data

• avoid unnecessary high-volume sources

• keep retention appropriate for learning

• review Azure Cost Management afterward

If your environment does not include every Defender or Entra feature, use the data and sample scenarios available to you.

🏢 Mission Scenario

You have joined the Security Operations Center as a junior Security Operations Analyst.

The organization uses Azure and Microsoft security services.

The SOC receives security signals from:

• Microsoft Entra ID

• Azure resources

• Microsoft Defender

• cloud workloads

• other connected systems

The team is concerned that:

• alerts are reviewed inconsistently

• analysts rely too heavily on dashboards

• KQL skills are weak

• incidents are not properly correlated

• threat hunting is mostly reactive

• investigation notes are inconsistent

• high-noise detections create alert fatigue

Your mission is to establish a basic Microsoft Sentinel investigation workflow.

🎯 Mission Objectives

By the end of this lab, you should be able to:

• explain Microsoft Sentinel

• understand Log Analytics workspaces

• review data connectors

• identify useful security telemetry

• write basic KQL

• investigate security events

• understand analytics rules

• distinguish alerts from incidents

• review incident entities

• build investigation timelines

• perform basic threat hunting

• identify false positives

• understand automation concepts

• document SOC findings

• answer Sentinel interview questions

📚 Prerequisites

You should understand:

• basic cybersecurity

• authentication

• logs

• incidents

• Microsoft Entra ID

• Azure Activity Log

• Defender for Cloud

• basic incident response

Recommended previous learning:

• SC-900

• SC-200

• AZ-500

• Microsoft Entra ID Security Lab

• Microsoft Defender for Cloud Lab

🧠 Microsoft Sentinel Mental Model

Think:

Security Telemetry
      ↓
Log Analytics
      ↓
Detection Logic
      ↓
Alert
      ↓
Incident
      ↓
Investigation
      ↓
Threat Hunting
      ↓
Response

🧠 SOC Mental Model

For every incident ask:

What happened?

What activity triggered the detection?

Who?

Which identity is involved?

What asset?

Which host, resource, application, or service?

When?

When did the activity begin?

Context?

What happened before and after?

Scope?

What else may be affected?

Decision?

Benign, false positive, suspicious, or confirmed malicious?

Action?

What should happen next?

🧪 Task 1 — Open Microsoft Sentinel

Navigate to:

Azure Portal → Microsoft Sentinel

Select or create your lab workspace.

Review:

• overview

• incidents

• logs

• analytics

• hunting

• data connectors

• automation

Do not memorize interface placement.

The interface changes.

Focus on the workflow.

🧪 Task 2 — Review the Log Analytics Workspace

Microsoft Sentinel operates with a Log Analytics workspace.

Review:

• workspace name

• resource group

• Region

• retention

• connected data

🧠 Why the Workspace Matters

Think:

Security Sources
      ↓
Log Analytics Workspace
      ↓
Queries / Detection
      ↓
Sentinel

🧪 Task 3 — Review Data Connectors

Navigate to:

Microsoft Sentinel → Data connectors

Review available connectors.

Possible sources may include:

• Microsoft Entra ID

• Azure Activity

• Microsoft Defender

• Windows security events

• network devices

• third-party services

📋 Connector Inventory

Data Source	Connected?	Security Value	Volume	Priority

🧠 Connector Question

Ask:

What security question does this data source help us answer?

Do not connect sources simply because they are available.

🧪 Task 4 — Identify Core Azure Security Telemetry

For this lab, identify useful telemetry such as:

Microsoft Entra Sign-In Activity

Helps answer:

Who authenticated, from where, and under what conditions?

Entra Audit Activity

Helps answer:

Which identity or application configuration changed?

Azure Activity

Helps answer:

Who changed Azure resources?

Defender Findings

Helps answer:

What suspicious activity or workload risk was detected?

🧪 Task 5 — Open Logs

Navigate:

Microsoft Sentinel / Log Analytics → Logs

Inspect available tables.

Your exact tables depend on connected sources.

🧠 Important Principle

Before writing a query ask:

Which table contains the evidence I need?

🧪 Task 6 — Learn Basic KQL Structure

Start with the simplest pattern:

TableName
| where TimeGenerated > ago(24h)

Understand:

Table
 ↓
Filter
 ↓
Transform
 ↓
Summarize
 ↓
Present

🧪 Task 7 — Practise where

Use a suitable available table.

Concept:

SigninLogs
| where TimeGenerated > ago(24h)

Then add another condition.

Example:

SigninLogs
| where TimeGenerated > ago(24h)
| where UserPrincipalName contains "test"

Use the fields available in your workspace.

🧠 Plain-English Translation

Always translate the query:

Show sign-in events from the last 24 hours for this test user.

If you cannot explain the query, simplify it.

🧪 Task 8 — Practise project

Reduce output to useful fields.

Example concept:

SigninLogs
| where TimeGenerated > ago(24h)
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName

🧠 SOC Tip

Do not pull 50 columns if you only need five.

Investigation queries should make evidence easier to understand.

🧪 Task 9 — Practise Sorting

Example:

SigninLogs
| where TimeGenerated > ago(24h)
| project TimeGenerated, UserPrincipalName, IPAddress
| order by TimeGenerated desc

This helps build timelines.

🧪 Task 10 — Practise summarize

Use aggregation to answer questions.

Example concept:

SigninLogs
| where TimeGenerated > ago(24h)
| summarize Count=count() by UserPrincipalName
| order by Count desc

🧠 Security Question

This query may help answer:

Which users generated the most sign-in activity?

The count itself is not proof of malicious activity.

It is context.

🧪 Task 11 — Investigate Failed Sign-Ins

Use your available sign-in data.

Build a query that identifies failed authentication.

Your exact field syntax may vary depending on the schema.

Record:

• user

• source IP

• application

• time

• failure reason

📋 Failed Sign-In Worksheet

User	IP	Attempts	Application	Time Window

🧠 Investigation Question

Ask:

Is this a user mistake, automation issue, password spray, or brute-force-like pattern?

🧪 Task 12 — Investigate a Successful Sign-In After Failures

Scenario:

A user has repeated failed sign-ins followed by a successful authentication.

Build a timeline.

Failed Login
      ↓
Failed Login
      ↓
Failed Login
      ↓
Successful Login

🔍 Ask

• same IP?

• different IP?

• same device?

• same application?

• what happened after success?

🧠 Important

The successful login may be more important than the failed attempts.

🧪 Task 13 — Review Azure Activity Logs

Use the appropriate Azure activity table where available.

Search for resource changes.

Examples may include:

• NSG changes

• VM changes

• resource creation

• role-related changes

🧠 Cloud Investigation Question

Ask:

Did suspicious identity activity lead to Azure resource modification?

🧪 Task 14 — Build a User Activity Timeline

Select one test or sample user.

Build a timeline combining available identity and Azure activity.

Example:

09:10
Sign-In

09:14
Resource Group Viewed

09:20
NSG Changed

09:27
New Resource Created

🧠 Investigation Goal

You should be able to explain:

What did the user do after authentication?

🧪 Task 15 — Review Analytics Rules

Navigate:

Microsoft Sentinel → Analytics

Review:

• active rules

• templates

• scheduling concepts

• severity

• entity mapping

🧠 Analytics Rule Mental Model

Telemetry
   ↓
KQL / Detection Logic
   ↓
Threshold / Conditions
   ↓
Alert

🧪 Task 16 — Analyze an Existing Rule

Choose one rule or template.

Document:

Rule Name:

Threat Being Detected:

Data Source:

Logic:

Frequency:

Severity:

Potential False Positives:

Response:

🧠 Detection Engineering Question

Ask:

Why would this activity be suspicious?

If you cannot answer that, you do not fully understand the rule.

🧪 Task 17 — Design a Failed-Login Detection

Conceptual scenario:

Detect a high number of authentication failures for one identity in a short period.

Document:

• source data

• threshold

• time window

• severity

• false positives

• investigation steps

⚠️ Do Not Choose Thresholds Arbitrarily

Ask:

• what is normal?

• how many failures are expected?

• which users are service accounts?

• what applications create noise?

🧪 Task 18 — Design a Privileged-Activity Detection

Scenario:

Detect unexpected privileged role changes.

Consider telemetry around:

• role assignment

• privileged access changes

• high-impact administrators

🧠 High-Value Detection Principle

Privileged changes should generally receive greater monitoring because the potential impact is higher.

🧪 Task 19 — Understand Alerts

An alert represents a security signal generated by detection logic or connected security products.

For an available alert review:

• name

• severity

• time

• entity

• evidence

• source product

🧪 Task 20 — Understand Incidents

Incidents can group related alerts into one investigation.

Think:

Suspicious Sign-In Alert
        +
Privilege Change Alert
        +
Defender Endpoint Alert
        ↓
Single Incident

🧠 Alert vs Incident

Alert

One security signal.

Incident

The investigation case.

This distinction matters operationally.

🧪 Task 21 — Open an Incident

Review an available or sample incident.

Record:

• incident title

• severity

• status

• owner

• alerts

• entities

• timeline

📋 Incident Worksheet

Item	Details
Incident
Severity
Identity
Host / Resource
IP
Detection Source
Initial Assessment

🧪 Task 22 — Review Entities

Entities may include:

• accounts

• hosts

• IP addresses

• URLs

• files

• cloud resources

🧠 Why Entities Matter

They connect evidence.

Example:

User A
 ↓
Signed in from IP X
 ↓
Changed VM Y
 ↓
VM Y contacted IP Z

This is much more useful than isolated alerts.

🧪 Task 23 — Build an Investigation Timeline

Use incident evidence and logs.

Create:

Time	Event	Entity	Evidence	Significance

🧠 Timeline Principle

A strong SOC investigation tells a chronological story.

🧪 Task 24 — Classify the Incident

Choose:

False Positive

Benign Positive

Suspicious

Confirmed Malicious

Needs Escalation

🧠 False Positive vs Benign Positive

False Positive

The detection was technically incorrect.

Benign Positive

The detection correctly identified the activity, but the activity was legitimate.

Example:

A privileged administrator legitimately performs a rare action.

The rule may correctly detect it.

The activity is still benign.

🧪 Task 25 — Write Investigation Notes

Use a standard format.

Incident:

Summary:

Affected Entities:

Evidence Reviewed:

Timeline:

Assessment:

Scope:

Actions Taken:

Recommended Next Steps:

🧠 Professional Tip

Do not write:

Checked logs. Looks okay.

Write evidence-based conclusions.

🧪 Task 26 — Perform a Basic Threat Hunt

Threat hunting starts with a hypothesis.

Example:

Privileged accounts may be active outside expected working hours.

🧠 Hunt Workflow

Hypothesis
   ↓
Relevant Data
   ↓
Query
   ↓
Analyze Results
   ↓
Validate
   ↓
Expand Scope

🧪 Task 27 — Create a Privileged-Activity Hunt

Identify:

• privileged identities

• sign-in/activity time

• unusual access windows

• unusual locations

Document your hypothesis and result.

🧪 Task 28 — Hunt for Rare IP Activity

Concept:

Identify users authenticating from IPs rarely observed in the environment.

You may need to:

• summarize by IP

• identify low-frequency values

• correlate with users

🧠 Rare Does Not Mean Malicious

Rare activity is:

worth investigation.

Not:

automatically malicious.

🧪 Task 29 — Hunt for Suspicious Azure Changes

Search Azure activity for high-impact changes such as:

• network exposure

• privilege changes

• security configuration changes

Then ask:

Which identity performed the change?

🧪 Task 30 — Hunt for Activity After Suspicious Authentication

Scenario:

A suspicious sign-in occurs.

Query the next 30–60 minutes of activity.

Look for:

• role changes

• network changes

• resource creation

• security changes

🧠 SOC Thinking

An alert should lead to:

What happened next?

🧪 Task 31 — Convert a Hunt Into a Detection Concept

Suppose your hunt identifies a useful suspicious pattern.

Document:

Threat:

Telemetry:

Query Logic:

Threshold:

False Positives:

Severity:

Incident Response:

🧠 Hunt-to-Detection

Threat Hunt
    ↓
Repeatable Pattern
    ↓
Analytics Rule
    ↓
Continuous Detection

This is an important SOC maturity concept.

🧪 Task 32 — Review Workbooks

Explore Sentinel workbooks available in your environment.

Understand their purpose for:

• visualization

• operational monitoring

• security trends

• investigations

🧠 Dashboard Warning

Dashboards are useful for visibility.

They do not replace:

• querying

• investigation

• context

🧪 Task 33 — Review Automation Rules

Navigate to Sentinel automation capabilities.

Understand automation use cases such as:

• assignment

• incident tagging

• incident status changes

• notification

• workflow triggering

🧠 Automation Principle

Start with low-risk repetitive activities.

Examples:

New High Incident
      ↓
Assign SOC Queue
      ↓
Add Tag
      ↓
Notify Analyst

🧪 Task 34 — Understand Playbooks

Security-response playbooks may orchestrate actions through supported automation workflows.

Possible examples:

• notify analyst

• create ticket

• enrich IP information

• disable account

• block indicator

⚠️ Automation Safety

Do not automatically disable accounts just because:

an alert fired.

Consider:

• detection confidence

• business impact

• reversibility

• approval requirements

🧪 Task 35 — Design an Identity-Response Workflow

Scenario:

High-confidence compromised administrator account.

Design:

Detection
   ↓
Sentinel Incident
   ↓
Validate
   ↓
Disable / Restrict Identity
   ↓
Revoke Access
   ↓
Notify SOC
   ↓
Investigate Scope

🧠 Response Principle

Containment should reduce threat activity without preventing investigation.

🧪 Task 36 — Design a Cloud Resource Investigation

Scenario:

Suspicious Azure NSG modification.

Investigate:

Sentinel Alert
      ↓
Identity
      ↓
Azure Activity
      ↓
Affected NSG
      ↓
Affected Workload
      ↓
Network Exposure
      ↓
Subsequent Activity

🧪 Task 37 — Correlate Sentinel With Defender for Cloud

Scenario:

Defender reports suspicious VM activity and Sentinel contains related identity events.

Create:

Defender Alert
      ↓
Affected VM
      ↓
User / Identity
      ↓
Sentinel Investigation
      ↓
Azure Activity
      ↓
Scope

🧠 Why Correlation Matters

Real incidents often cross:

• identity

• endpoint

• cloud

• network

🧪 Task 38 — Build a Detection Coverage Matrix

Threat Scenario	Telemetry	Detection	Investigation Source
Failed logins	Entra sign-in	Analytics rule	Sentinel
Privilege change	Entra audit	Analytics rule	Sentinel
Azure resource change	Azure Activity	Analytics rule	Sentinel
VM threat	Defender	Defender alert	Sentinel/Defender

🧠 Security Operations Question

Ask:

Which important threat scenarios currently have no detection?

🧪 Task 39 — Review Alert Noise

Select a noisy rule or conceptual example.

Ask:

• how many alerts?

• how many are real?

• what common benign behavior exists?

• can logic improve?

🧠 Alert Fatigue

Too many low-value alerts lead analysts to:

• miss important incidents

• rush investigations

• close alerts mechanically

Detection quality matters.

🧪 Task 40 — Tune a Detection Concept

Possible improvements:

• narrow target population

• adjust threshold

• add exclusions

• include asset criticality

• add enrichment

⚠️ Tuning Principle

Do not create exclusions simply to:

make alerts disappear.

Understand why behavior is legitimate.

🧪 Task 41 — Create a SOC Finding

Example:

Finding ID:
SENT-001

Title:
Privileged Identity Activity Lacks Dedicated Detection

Severity:
High

Observation:
High-impact administrator role changes are logged but no dedicated Sentinel detection monitors unexpected changes.

Risk:
Unauthorized privilege changes may remain unnoticed.

Recommendation:
Create and tune detection logic for privileged-role activity with clear SOC ownership and investigation procedures.

🧪 Task 42 — Create a Logging Gap Finding

Finding ID:
SENT-002

Title:
Critical Azure Security Telemetry Not Connected to Sentinel

Severity:
Medium / High

Observation:
Security operations does not receive required telemetry from an in-scope Azure environment.

Risk:
SOC analysts may be unable to detect or investigate suspicious activity.

Recommendation:
Validate logging requirements and onboard the necessary telemetry with appropriate retention and monitoring.

🧪 Task 43 — Create an Alert Quality Finding

Finding ID:
SENT-003

Title:
High-Noise Detection Generates Excessive False/Benign Alerts

Severity:
Medium

Risk:
Excessive alert volume may create analyst fatigue and reduce the likelihood of timely response to genuine incidents.

Recommendation:
Review detection logic, baseline expected behavior, tune thresholds and exclusions, and measure detection quality after changes.

🧪 Task 44 — Build a SOC Assessment Checklist

Control	Status	Risk	Recommendation
Required data connectors
Identity telemetry
Azure activity telemetry
Defender integrations
Analytics rules
High-value detections
Alert tuning
Incident ownership
Threat hunting
Automation
Incident documentation

🚨 Incident Scenario — Suspicious Administrator

Scenario:

A privileged Entra account signs in from an unusual location. Shortly afterward, a production NSG is modified.

Use:

Sign-In
   ↓
Identity Context
   ↓
Azure Activity
   ↓
NSG Change
   ↓
Affected Workloads
   ↓
Scope
   ↓
Response

Investigate:

• authentication result

• MFA

• source IP

• resource modification

• later activity

🚨 Incident Scenario — Password Spray

Scenario:

Multiple users show authentication failures from the same source IP.

Then one user successfully authenticates.

Investigate:

• affected users

• source IP

• time window

• failure reasons

• successful account

• post-login activity

🚨 Incident Scenario — Compromised Workload

Scenario:

Defender reports suspicious VM activity.

Sentinel also contains unusual authentication from the VM’s associated user.

Correlate:

Defender
 +
Identity
 +
Azure Activity
 +
Network
 =
Incident Context

🎤 Microsoft Sentinel Interview Questions

Practise without notes.

Fundamentals

1. What is Microsoft Sentinel?

2. What is a SIEM?

3. What is Log Analytics?

4. Why are data connectors required?

5. What makes a security log valuable?

KQL

6. What is KQL?

7. What does where do?

8. What does project do?

9. What does summarize do?

10. How would you search a user’s activity over 24 hours?

Analytics

11. What is an analytics rule?

12. How would you design a good detection?

13. Why do detections create false positives?

14. How do you reduce alert fatigue?

Alerts & Incidents

15. Alert vs incident?

16. What is an entity?

17. How do you investigate a Sentinel incident?

18. How do you determine scope?

Threat Hunting

19. What is threat hunting?

20. How is hunting different from incident investigation?

21. What is a hunting hypothesis?

22. What should happen when a hunt reveals a repeatable pattern?

Automation

23. What are automation rules?

24. What is a playbook conceptually?

25. What are the risks of automatic containment?

🚨 Scenario Interview Question 1

A user generates 50 failed logins followed by a successful sign-in.

A strong answer should include:

Review User
   ↓
Source IP
   ↓
Authentication Details
   ↓
Time Pattern
   ↓
Successful Login
   ↓
Post-Login Activity
   ↓
Decision

🚨 Scenario Interview Question 2

Sentinel shows a privileged role assignment that occurred at 2 AM.

Do not automatically label it malicious.

Investigate:

• identity performing the assignment

• business change window

• PIM activation

• target user

• later actions

🚨 Scenario Interview Question 3

A detection generates hundreds of incidents every day.

A strong response should discuss:

• detection intent

• true positive rate

• baseline

• thresholds

• exclusions

• data quality

🚨 Scenario Interview Question 4

An analyst sees a Defender alert in Sentinel for a compromised VM.

Discuss:

• affected resource

• user/identity

• timeline

• Azure Activity

• network context

• scope

• containment

🚨 Scenario Interview Question 5

A security manager asks you to connect every possible data source to Sentinel.

Do not answer:

yes.

Discuss:

• detection requirements

• value of telemetry

• data volume

• cost

• retention

• ownership

🧠 SOC Interview Answer Framework

Use:

Alert
 ↓
Validate
 ↓
Entities
 ↓
Evidence
 ↓
Timeline
 ↓
Scope
 ↓
Severity
 ↓
Action
 ↓
Documentation

💬 Interview Tip

Avoid:

“I would run a KQL query.”

A stronger answer is:

“I would first identify the affected entities and investigation question, select the relevant telemetry, use KQL to build a timeline and correlate activity, determine whether the event is legitimate or malicious, assess scope, and then recommend containment or escalation.”

That sounds like a Security Operations Analyst.

📁 Portfolio Evidence

After completing the lab, create a sanitized SOC portfolio package.

Include:

Sentinel Architecture

Show:

Entra Logs
Azure Activity
Defender Alerts
Other Security Data
      ↓
Log Analytics
      ↓
Microsoft Sentinel
      ↓
Detection
      ↓
Incident
      ↓
SOC

KQL Investigation Queries

Include 5–10 queries and explain:

What security question does each query answer?

Incident Report

Document:

• alert

• evidence

• entities

• timeline

• conclusion

• response

Threat Hunt

Document:

• hypothesis

• query

• findings

• recommendation

Detection Design

Document:

• threat

• telemetry

• detection logic

• false positives

• response

📝 Resume Examples

Instead of:

Knowledge of Microsoft Sentinel.

Use:

Investigated simulated Microsoft Sentinel incidents using KQL and correlated Microsoft Entra, Azure Activity, and Defender telemetry to determine incident scope and recommended response.

Or:

Developed KQL-based threat-hunting and detection exercises for suspicious authentication, privileged activity, and Azure resource changes, including alert tuning and incident documentation.

⭐ Job-Readiness Check

After this lab, you should be able to:

• explain Sentinel

• explain Log Analytics

• identify useful data connectors

• write basic KQL

• search identity activity

• analyze Azure resource activity

• understand analytics rules

• distinguish alerts and incidents

• analyze entities

• build investigation timelines

• classify incidents

• perform basic threat hunting

• explain automation concepts

• tune noisy detections

• document investigations professionally

If your Sentinel workflow is still:

open incident → read alert → close incident,

repeat the lab.

The goal is:

Use telemetry to establish what happened, determine whether it matters, understand the scope, and recommend the right action.

🧹 Lab Clean-Up

After completing the lab:

• remove temporary analytics rules

• remove test automation

• remove unnecessary data connectors

• review workspace retention

• remove temporary test resources

• confirm no intentionally insecure lab configuration remains

• review Sentinel and Log Analytics costs

🏆 Mission Complete

You have now practised:

Telemetry Collection
      ↓
KQL Investigation
      ↓
Detection
      ↓
Alerts
      ↓
Incidents
      ↓
Entity Correlation
      ↓
Threat Hunting
      ↓
Response
      ↓
Documentation

These are core capabilities for:

• SOC Analysts

• Security Operations Analysts

• Microsoft Sentinel Analysts

• Detection Engineers

• Cloud Security Analysts

• Incident Responders

🚀 What’s Next?

You have now completed the core Azure hands-on security labs:

Azure RBAC
      ↓
Microsoft Entra ID Security
      ↓
Azure Network Security
      ↓
Microsoft Defender for Cloud
      ↓
Microsoft Sentinel

The next step is to move from individual technical exercises into professional repeatable assessment methodology, just as we did in the AWS path.

➡️ Next: Azure Security Assessment Runbook

In the next runbook, you will systematically assess:

• tenant and subscription structure

• Microsoft Entra identity security

• Azure RBAC

• privileged access

• network exposure

• VNets and NSGs

• Defender for Cloud

• logging and Sentinel

• storage and Key Vault

• Azure Policy

• security findings

• risk rating

• remediation

• executive reporting