Lesson 3 — Cloud Workload Protection

Learning objectives

After completing this lesson, you should be able to explain how Defender for Cloud protects running workloads and how different Defender plans contribute to detection and response.

• Define Cloud Workload Protection.
• Differentiate CSPM from CWPP.
• Explain the purpose of Microsoft Defender plans.
• Recognise workload-specific protection capabilities.
• Understand runtime monitoring and threat detection.
• Describe how alerts are generated and investigated.
• Explain Defender XDR and Sentinel integration.
• Build a repeatable cloud workload investigation workflow.

What is Cloud Workload Protection?

Cloud Workload Protection protects resources after deployment by monitoring for suspicious behaviour, vulnerabilities, malicious access and runtime threats.

It is the active protection layer within Microsoft Defender for Cloud.

CSPM and CWPP work together

CSPM identifies security weaknesses that could be exploited. CWPP detects suspicious activity affecting running workloads.

A public management port is a posture issue. Repeated password attacks against that port are a workload protection issue.

Prevention and detection

Strong posture reduces the opportunity for attackers, but no environment can rely on prevention alone.

CWPP provides the monitoring and detection layer needed when attackers probe, exploit or abuse cloud workloads.

What is a cloud workload?

A cloud workload is a deployed resource or service performing business or technical functions.

Examples include virtual machines, storage accounts, databases, containers, APIs, application services and secrets platforms.

Why workload-specific protection matters

Different workloads expose different telemetry and attack surfaces.

A suspicious database query, malicious file upload and container escape attempt require different detection logic and investigation evidence.

What are Microsoft Defender plans?

Microsoft Defender plans enable additional protection for selected workload categories and deployment scopes.

Each plan adds capabilities designed for the workload it protects, such as vulnerability assessment, malware scanning, behavioural analytics and threat detection.

Plan scope matters

A Defender plan must be enabled at the correct subscription, account, project or supported resource scope.

Security teams should never assume that every workload is protected simply because Defender for Cloud is enabled.

Defender for Servers

Defender for Servers protects Windows and Linux machines across Azure, hybrid and supported multicloud environments.

Capabilities can include endpoint detection, vulnerability assessment, file integrity monitoring, agentless scanning and workload alerts, depending on the selected plan and configuration.

Endpoint integration

Server protection can integrate with Microsoft Defender for Endpoint to provide endpoint telemetry, detections and response capabilities.

This connects cloud workload context with process, file, network and identity evidence from the protected machine.

Defender for Storage

Defender for Storage monitors supported storage accounts for suspicious access, malicious uploads and unusual data activity.

On-upload malware scanning can help identify harmful files before downstream systems process them.

Storage threat examples

• Malware uploaded to a blob container
• Suspicious access from unusual locations
• Abnormal data extraction
• Credential misuse
• Unexpected access patterns

Defender for Databases

Database protection monitors supported platforms for suspicious queries, unusual authentication and potential exploitation.

Database alerts must be interpreted with application behaviour, account context and expected operational patterns.

Database threat examples

• SQL injection activity
• Unusual privileged access
• Abnormal query behaviour
• Credential abuse
• Suspicious data extraction

Defender for Containers

Container protection covers supported Kubernetes and container environments across build, deployment and runtime stages.

Protection can include image vulnerability findings, control-plane detections and suspicious container activity.

Container threat examples

• Privileged container deployment
• Suspicious shell activity
• Cryptocurrency mining
• Container escape behaviour
• Unexpected control-plane operations

Defender for Key Vault

Key Vault protection monitors access to keys, secrets and certificates for suspicious or unusual operations.

Because secrets often unlock other systems, unusual Key Vault activity can represent the beginning of a much wider compromise.

Key Vault investigation context

• Which identity requested the secret?
• Was the location expected?
• Was the volume unusual?
• Did the identity recently gain permissions?
• What resources could the secret unlock?

Defender for APIs

Defender for APIs helps identify security weaknesses and runtime threats affecting supported APIs.

API protection is important because APIs often expose sensitive business functions directly to applications, partners and the internet.

API threat examples

• Abnormal request patterns
• Suspicious endpoint access
• Authentication abuse
• Unusual data access
• Reconnaissance and probing

Defender for App Service

App Service protection monitors supported Azure web applications and hosting environments.

Alerts can help identify suspicious requests, exploitation attempts and unusual application behaviour.

Control-plane protection

Cloud attacks do not always target an operating system or application.

Suspicious changes made through Azure management operations can create new credentials, alter networking, disable controls or deploy malicious resources.

Runtime monitoring

Runtime monitoring observes activity while a workload is operating.

It can reveal behaviour that static configuration assessment cannot see, such as a malicious process, abnormal query or suspicious secret request.

Security telemetry

Workload detections can use platform logs, endpoint signals, network activity, authentication events, control-plane operations and service-specific telemetry.

The available evidence depends on the workload, enabled plan and deployment configuration.

Threat intelligence

Threat intelligence helps identify known malicious infrastructure, attacker techniques and suspicious indicators.

It adds external context to workload behaviour, but analysts must still confirm whether the activity is truly harmful in their environment.

Behavioural analytics

Behavioural analytics compares current activity with expected patterns to identify anomalies.

An unusual event is not automatically malicious, but it can provide a valuable starting point for investigation.

Vulnerability assessment

Vulnerability assessment identifies known weaknesses in supported machines, images and database environments.

Vulnerability findings provide prevention context, while CWPP alerts indicate suspicious or active behaviour.

Malware scanning

Malware scanning can inspect supported files, machines or storage uploads depending on the plan.

Detection should trigger an investigation into the source, destination, execution status and any related activity.

What an alert can contain

• Alert title and severity
• Affected resource
• Source and destination entities
• Accounts and identities
• Processes, files or network indicators
• MITRE ATT&CK techniques
• Investigation steps
• Recommended response actions

Alert severity is not enough

A high-severity alert on a test resource may have less business impact than a medium-severity alert affecting a critical production service.

Always combine alert severity with resource criticality, exposure, identity context and related incidents.

MITRE ATT&CK mapping

Many alerts map detected behaviour to MITRE ATT&CK tactics and techniques.

This helps analysts understand the attacker objective and connect cloud activity with a broader incident timeline.

Alerts versus incidents

An alert describes a detected security event. An incident groups related alerts and evidence into a larger investigation.

Correlation reduces fragmentation and helps analysts follow an attack across workloads, identities and cloud services.

Microsoft Defender XDR integration

Cloud alerts can appear within the Microsoft Defender portal and contribute to cross-domain incidents.

This allows cloud workload evidence to be correlated with endpoints, identities, email and applications.

Microsoft Sentinel integration

Defender for Cloud alerts can be integrated with Microsoft Sentinel for incident management, hunting, automation and long-term analytics.

A Sentinel investigation can connect cloud detections with wider organisational telemetry.

Investigation questions

• Which workload generated the alert?
• Is the resource internet-facing?
• Which identity performed the activity?
• Was the activity successful?
• What happened immediately before and after?
• Are related alerts present?
• Does the workload contain sensitive data?
• What containment action is safe?

Containment choices

• Restrict network access
• Disable or rotate credentials
• Isolate a server
• Block a malicious indicator
• Stop a compromised container
• Disable exposed API access
• Preserve evidence before destructive action

Do not destroy the evidence

Stopping or deleting a resource too early can remove volatile evidence and make root-cause analysis difficult.

Containment must balance business impact, attacker access and evidence preservation.

Validate plan coverage

An alert investigation should confirm which Defender plan protected the workload and whether every required component was deployed correctly.

Partial onboarding can leave gaps in telemetry and response capability.

What Agent Foskett checked

• Alert evidence and timeline
• Authentication success and failure
• Public network exposure
• Source IP addresses
• Endpoint process and file activity
• Related Defender XDR incidents
• Vulnerabilities and missing patches
• Safe containment options

Operational lesson

A detection is not the same as a confirmed breach.

Analysts must determine what was attempted, whether it succeeded, what control detected it and what weakness allowed the attack to reach the workload.

Common mistakes

• Assuming every alert means compromise.
• Enabling plans without validating coverage.
• Ignoring workload-specific evidence.
• Investigating alerts without identity context.
• Deleting resources before preserving evidence.
• Failing to remediate the exposure that enabled the attack.
• Treating Defender for Cloud as server antivirus only.

Best practices

• Enable the correct Defender plan for each workload.
• Validate onboarding and telemetry coverage.
• Integrate alerts with Defender XDR and Sentinel.
• Prioritise critical and exposed workloads.
• Combine runtime alerts with posture recommendations.
• Preserve evidence before destructive containment.
• Review plan features and licensing regularly.