CH07-04: Posture Management and Threat Detection

Goal

The previous sections focused on preventive controls: identity, access, secrets, edge protection, network inspection, and private access. Prevention matters, but it is never the whole security story. Cloud environments change constantly. People deploy resources, permissions drift, dependencies change, and attackers look for weak paths.

This section introduces the operational controls that help teams find risk, detect suspicious signals, investigate incidents, and respond.

The durable idea for this section is:

Posture tools help find and reduce risk; detection and response tools help investigate and act when signals appear.

The Short Version

Microsoft Defender for Cloud and Microsoft Sentinel are often mentioned together, but they have different jobs.

Defender for Cloud helps teams understand and improve cloud security posture. In plain language, it looks at cloud resources and workloads, identifies security recommendations, helps show protection coverage, and can provide workload protection alerts through Defender plans.

Microsoft Sentinel is a SIEM and SOAR service. SIEM means security information and event management: collecting security signals, correlating them, detecting threats, investigating incidents, and hunting. SOAR means security orchestration, automation, and response: using automation and playbooks to help act on incidents.

The simplest distinction is:

Need	Better-Fit Direction
Find misconfiguration and improve cloud security posture.	Defender for Cloud.
Protect specific workload types and surface workload alerts.	Defender for Cloud plans.
Collect signals from many sources and correlate incidents.	Sentinel.
Investigate, hunt, automate, and orchestrate response.	Sentinel.
Produce useful security evidence.	Both, plus logging, policy, access records, and operating process.

Neither service removes the need for security operations. They create signals and workflows. People and processes still decide what matters, who responds, and how improvement happens.

Posture, Detection, Investigation, Response, and Evidence

Security operations becomes clearer when you separate the lifecycle:

flowchart LR
    A["Posture<br/><small>What is weak or misconfigured?</small>"]
    B["Detection<br/><small>What signal suggests risk or attack?</small>"]
    C["Investigation<br/><small>What happened and what is affected?</small>"]
    D["Response<br/><small>What action limits impact?</small>"]
    E["Evidence<br/><small>What records prove control and improvement?</small>"]

    A --> B --> C --> D --> E --> A

Posture management asks whether the environment is configured in a secure and governed way. Detection asks whether something suspicious is happening. Investigation asks what the signal means. Response asks what action should be taken. Evidence asks what records show that controls existed, alerts were handled, and improvements were made.

Microsoft Defender for Cloud

Microsoft Defender for Cloud is useful when the control objective is security posture and workload protection.

At a high level, it helps teams answer questions such as:

Which resources are exposed or misconfigured?
Which recommendations should resource owners remediate?
Which workloads have protection enabled?
Which subscriptions, workloads, or resource types need attention?
Which alerts indicate possible workload threat activity?
How can security teams assign remediation work and track progress?

For a reader new to Azure, it may help to think of Defender for Cloud as the service that looks across cloud resources and says, "Here is where your environment is weak, here is what should be improved, and here are workload protection signals if you enabled the relevant plans."

That does not mean every recommendation has equal urgency. A recommendation on a public, regulated production workload may matter more than a recommendation on a temporary lab environment. Architecture judgment still matters.

Microsoft Sentinel

Microsoft Sentinel is useful when the control objective is security analytics, incident correlation, investigation, automation, and response.

Sentinel can collect data from Microsoft services, Azure resources, identity logs, network logs, application logs, on-premises systems, and other clouds or security tools through connectors and custom ingestion paths. Once data is collected, analytics rules and detections can group signals into incidents. Analysts can investigate incidents, hunt across data, use workbooks for visibility, and automate response with playbooks.

In plain language, Sentinel is where many security signals can become an investigation and response workflow.

That workflow needs design. Sending logs to Sentinel is not enough. Teams must decide:

Design Question	Why It Matters
Which logs are worth ingesting?	Ingestion creates cost and operational noise.
What should be detected?	A SIEM without detection logic becomes expensive storage.
Who owns each incident type?	Alerts without owners become ignored background noise.
Which alerts should be automated?	Automation can help, but only when actions are trusted.
How long should data be retained?	Retention affects cost, investigation depth, and audit needs.
How are false positives tuned?	Noisy detections train teams to ignore the system.

How They Work Together

Defender for Cloud and Sentinel can reinforce each other:

flowchart TB
    A["Azure resources and workloads"]
    B["Defender for Cloud<br/><small>Posture recommendations and workload alerts</small>"]
    C["Platform, identity, network, and application logs"]
    D["Microsoft Sentinel<br/><small>Analytics, incidents, hunting, automation, response</small>"]
    E["Owners and responders<br/><small>Remediate, investigate, document, improve</small>"]

    A --> B
    A --> C
    B --> D
    C --> D
    D --> E
    B --> E
    E --> A

Defender for Cloud might identify that storage accounts, databases, virtual machines, containers, or APIs have posture gaps or protection alerts. Sentinel might correlate those signals with identity activity, firewall logs, WAF logs, application logs, and endpoint signals to create a richer incident view.

The design goal is not more dashboards. The design goal is action.

Example: Regulated Workload Signals

Consider a regulated API platform.

Defender for Cloud might highlight that a storage account allows public access, a VM is missing a security update, a container image has vulnerabilities, or a Key Vault has suspicious access attempts through a Defender plan.

Sentinel might correlate several signals: an unusual sign-in, a new role assignment, WAF blocks from the same source range, firewall denies, and application errors. Individually, each signal may be easy to miss. Together, they may deserve investigation.

The team still needs a response path:

Signal	Possible Owner	Example Action
Posture recommendation on a workload resource.	Workload team with security oversight.	Remediate configuration or document an approved exception.
Suspicious identity activity.	Identity or security operations team.	Investigate sign-in, enforce conditional controls, review account.
WAF and firewall activity spike.	Network/security operations team.	Review traffic, tune rules, escalate if attack is suspected.
Application error pattern during suspicious activity.	Application team.	Check deployment, logs, and possible abuse path.
Correlated incident in Sentinel.	Security operations team.	Triage, assign severity, run playbook, preserve evidence.

The value appears when signals lead to owned decisions.

Common Mistakes

Enabling alerts without owners.
Treating a posture score as proof of security.
Sending logs to a SIEM without deciding what to detect.
Creating too many noisy alerts and training teams to ignore them.
Missing the response workflow after detection.
Keeping security evidence in dashboards but not connecting it to remediation or incident records.

If Someone Asks You

What is the difference between Defender for Cloud and Sentinel?

A good answer is:

Defender for Cloud helps assess and improve cloud security posture and can provide workload protection alerts through Defender plans. Sentinel is a SIEM and SOAR service that collects security signals, correlates incidents, supports investigation and hunting, and automates response. Defender for Cloud helps find and reduce cloud risk; Sentinel helps turn signals from many sources into detection, investigation, and response workflows.

What You Should Remember

Security value comes from finding risk, detecting signals, and acting through an owned response process.

Questions to Check Your Understanding

How is posture management different from incident response?
Why does alert ownership matter?
What kinds of signals might Sentinel correlate?