Better together with Azure WAF + Microsoft Defender for Storage + Defender for Azure SQL Databases
Authored by: Fernanda_Vela , saikishor, Yura_Lee Reviewed by: YuriDiogenes, Mohit_Kumar, Amir_Dahan, eitanbremler , Kitt_Weatherman Introduction Often, customers ask why additional workload protection is needed when a web application firewall is already in place. Azure Web Application Firewall (WAF) serves as a critical control at the application edge, inspecting inbound HTTP/S traffic and blocking common web-based exploits before they reach backend services. However, modern attack paths are no longer limited to the web entry point. Attackers increasingly target components that bypass HTTP/S inspection altogether such as direct access to storage and SQL through SDKs, native integration tools, private endpoints, or compromised identities and third-party integrations. This is where Microsoft Defender for Cloud complements WAF. While WAF focuses on securing the application boundary, Defender for Cloud extends protection into the resource layer by providing Cloud-Native Application Protection Platform (CNAPP) capabilities, including security posture management and workload protection. Using resource-native signals, it helps identify misconfigurations and detect suspicious control-plane and data-plane activity that would otherwise remain invisible to perimeter controls. The Azure Networking Security blog post “Zero Trust with Azure Firewall, Azure DDoS Protection, and Azure WAF: A practical approach” highlights WAF’s role in inspecting inbound HTTP/S traffic, detecting malicious request patterns (such as OWASP Top 10 vulnerabilities), and reducing direct exposure of backend endpoints by enforcing a controlled application entry point. Building on that foundation, this blog focuses on a “better together” approach that combines WAF with Microsoft Defender for Cloud protecting storage and database. Through practical scenarios and posture insights, we will underline how these controls together: Reduces attack surface at the application entry point Continuously improves security posture through configuration and exposure analysis Detects and responds to threats targeting storage accounts and SQL databases beyond the web perimeter By the end of this post, you will understand how Defender for Cloud’s Storage and SQL protections extend the visibility provided by WAF, enabling protection not only at the edge, but also across the underlying data services. Together, these controls form a cohesive model that addresses both external attack vectors and internal or indirect access paths. Note: This is not a deep configuration guide for rule tuning, nor a replacement for official product documentation. It is intended to help architects and security teams align responsibilities and understand how these services reinforce each other. Architecture: The architecture below shows the traffic flow and where each service fits in the lab used in this blog to simulate the attacks. Azure Application Gateway with WAF is the internet-facing entry point, inspecting inbound HTTP/S traffic before it reaches the backend. Behind it, Azure Firewall provides both network- and application-layer inspection for inbound and outbound flows. In the backend subnet, multiple VMs host the workload. For our demonstration, we focus on a single host running: OWASP Juice Shop (port 3000), An upload API that writes to Azure Storage (port 8080) An API that connects to Azure SQL Database (port 5000). This setup allows us to simulate realistic attack paths originating both from the internet and from within the network. Figure 1: Architecture that shows resources with Application Gateway with WAF, Azure Firewall Premium and inbound traffic Note: The patterns in this blog apply to both Azure WAF platforms: Application Gateway WAF and Azure Front Door WAF. The lab uses Application Gateway WAF for the demonstration. Now, let’s head to the next section where we dive deep into these services to understand their capabilities with some attacks, alerts and insights. Azure Web Application Firewall at the Edge As we may have understood by now, Azure WAF is the first layer of protection, inspecting external web traffic for malicious patterns. Each incoming request is evaluated against its rulesets to either allow, block or log this traffic by using its managed and custom rulesets. Now, what are these rulesets? Azure WAF uses managed rule sets like the Default Rule Set (DRS) (version 2.2 as of this writing), which incorporate OWASP Top 10 protections and Microsoft threat intelligence to block common attacks (SQL injection, XSS, remote file inclusion, etc.) in real time. Additional managed sets include a Bot Protection rule set (to guard against malicious bots scraping content) and HTTP DDoS rule set (to detect Layer 7 DDoS patterns). Beyond the built-ins, you can define custom WAF rules for application-specific needs—blocking or allowing traffic based on attributes like geolocation, IP ranges, or specific URL paths. Now let’s talk about an example scenario. In our lab, Azure WAF is protecting multiple backend services on different paths and ports. When an external attacker tries to exploit the Juice Shop app with a crafted XSSattack, Azure WAF immediately detects the malicious pattern and blocks the request at the gateway as seen below. Figure 2: An XSS attack on the juiceshop website, immediately results in a 403 Forbidden as WAF catches this attack in the application layer. However, WAF’s inspection is inherently limited to traffic it can see, primarily, the HTTP/S flows it fronts. Let’s say our attacker changes tactics: instead of trying to force malicious code through the web interface, they obtain a stolen storage key or credentials through phishing and attempt to access the Azure Storage account directly via APIs. This request never goes through WAF, so WAF cannot assess or block it. In such a case, Microsoft Defender for Storage’s threat detection monitors for such suspicious activity, for example by raising an alert about the unusual direct access or flagging a malware file uploaded to a blob container. Likewise, if our attacker exploited a weakness in application code to run malicious SQL commands on the database (whether through potentially harmful application or a suspicious service account), Defender for SQL monitors for and alerts anomalous query patterns or suspicious logins. This illustrates why WAF and Defender for Cloud are complementary: WAF stops web attacks at the door, while Defender for Cloud watches for threats that get inside or come through alternate doors. Figure 3: Single-host lab architecture with Azure Application Gateway (WAF) and resource‑level protection Figure 3 illustrates the key distinction: WAF inspects and protects the application entry point, while Defender for Cloud provides visibility into the resources themselves. Together, they cover both the path into the application and the behavior within the environment—forming a complete protection model across layers. Because not all access to storage and databases may flow through the application gateway, you also need resource-level posture and threat detection to see and stop activity that never appears in WAF logs. Cloud Security Posture Management with Defender for Cloud With the edge covered, the next challenge is reducing risk that originates from misconfiguration and resource exposure. Most successful attacks originate from exposed services and misconfigurations rather than direct application-layer exploits. Microsoft Defender for Cloud’s storage and database protection provide security posture insights that help identify and prioritize these security gaps at the resource level. Defender for Cloud has visibility insights that capture the resources’ misconfigurations on the control and data plane via the Recommendations view in the Azure portal, as shown in the example below: Figure 4: Juice Shop’s storage account and SQL server recommendations Figure 4 is a list of recommendations organized by risk level for this particular environment. The security team should harden the “defendertestsai” storage asset by preventing shared access keys, and the “juiceshop” SQL database by provisioning an Entra administrator. Each recommendation will also provide guidance to remediate these findings. The “Data & AI Dashboard” in Defender for Cloud, with Defender CSPM, will also provide security posture insight into storage, database and AI resources by surfacing their risks, alerts and sensitive data discovery all in one dashboard. Figure 5: Juice Shop’s Sensitive data discovery and Data threat detection dashboard in Defender for Cloud’s “Data&AI section”. Under Data closer look, in Figure 5, you can see in this example, starting from the left, sensitive information found in scanned resources, level alerts for databases and storage resources based on severity, templatized queries from the Cloud Security Explorer, and a graph displaying all internet exposed data resources below. These powerful insights on data resources all come from Defender for Cloud, designed to help customers harden their environment by priority through visibility across their entire data ecosystem based on risk level. Figure 6: Juice Shop’s attack path “Internet exposed Azure VM with high severity vulnerabilities allows lateral movement to Critical Storage used by Azure AI Foundry”. Attack paths are potential avenues in which an attacker can infiltrate and compromise data. In Figure 6 above, we see insight into not only the storage account itself, but the context around it: an internet exposed storage account is connected to other assets like a virtual machine and a managed identity that has permissions to manipulate data. These Defender for Cloud security posture insights complement WAF and complete the defense-in-depth security approach: harden the data services so that even if an attacker reaches them the blast radius is smaller, and the likelihood of compromise is reduced. Defender for Cloud’s advanced threat protection Even in well-secured environments, attackers often interact directly with storage accounts or databases through identities, APIs, or trusted internal paths. Reducing exposure is critical but not sufficient. Detection is required once an attacker begins interacting with data Defender for Cloud’s advanced threat protection for Storage and SQL surfaces resource-level security alerts such as suspicious access patterns, anomalous queries, and malware detections—often with richer context than perimeter telemetry alone. Let’s use a malware alert for a storage account in the Defender portal as an example: Figure 7: Juice Shop’s storage account security alert “Malicious blob uploaded to storage account”. Malware scanning is a common requirement for teams that process user uploads or must meet security benchmarks. In this lab, Juice Shop allows users to upload files (for example, feedback attachments), and the upload API writes those files to Azure Blob Storage. Azure WAF inspects the HTTP request that delivers the upload headers, parameters, payload patterns and blocks web-layer attacks like XSS or SQLi. Scanning blob contents after they land is a different job, performed at the resource layer by Defender for Storage. With Defender for Storage malware scanning enabled, each uploaded blob is scanned; if the verdict is malware, Defender for Cloud raises an alert such as “Malicious blob uploaded to storage account” as shown in figure 7. Then, with Defender for Storage’s automated malware remediation, the malicious blog is set to soft-delete for quarantine and further analysis. SQL databases are high-value targets for data access, privilege escalation, and exploitation of vulnerable applications. Database protection in Defender for Cloud has the visibility to provide customers with control plane and data plane level insight to alert on suspicious activity such as anomalous logons, unusual client applications, and injection-like query patterns. For example, here’s a potential SQL injection alert for a database in the Defender portal: Figure 8: Juice Shop’s database security alert on a potential SQL injection. These alerts typically include investigation context such as the client application, client principal name, and the statement or pattern in question, along with severity to help you prioritize, as shown in Figure 8. From there, analysts can use recommended response actions (for example, to contain risky access paths or harden the database) to reduce the chance of repeat activity. In practice, Defender for Cloud threat detection gives SOC teams prioritized, resource-specific alerts with the context needed to investigate quickly and take action at the storage and database layers. Conclusion Azure Application Gateway with WAF is a necessary control to reduce application-layer risk at the edge. But defense in depth requires the assumption that some threats will reach or target data services directly. By layering Microsoft Defender for Storage and Microsoft Defender for SQL on top of Azure WAF, you add continuous posture insights to reduce preventable exposure, plus threat protection that detects suspicious activity at the resource layer. Operated together, these services provide stronger prevention, better detection coverage, and clearer response paths than single control alone.Become a Microsoft Defender for Cloud Ninja
[Last update: 03/30/2026] This blog post has a curation of many Microsoft Defender for Cloud (formerly known as Azure Security Center and Azure Defender) resources, organized in a format that can help you to go from absolutely no knowledge in Microsoft Defender for Cloud, to design and implement different scenarios. You can use this blog post as a training roadmap to learn more about Microsoft Defender for Cloud. On November 2nd, at Microsoft Ignite 2021, Microsoft announced the rebrand of Azure Security Center and Azure Defender for Microsoft Defender for Cloud. To learn more about this change, read this article. Every month we are adding new updates to this article, and you can track it by checking the red date besides the topic. If you already study all the modules and you are ready for the knowledge check, follow the procedures below: To obtain the Defender for Cloud Ninja Certificate 1. Take this knowledge check here, where you will find questions about different areas and plans available in Defender for Cloud. 2. If you score 80% or more in the knowledge check, request your participation certificate here. If you achieved less than 80%, please review the questions that you got it wrong, study more and take the assessment again. Note: it can take up to 24 hours for you to receive your certificate via email. To obtain the Defender for Servers Ninja Certificate (Introduced in 08/2023) 1. Take this knowledge check here, where you will find only questions related to Defender for Servers. 2. If you score 80% or more in the knowledge check, request your participation certificate here. If you achieved less than 80%, please review the questions that you got it wrong, study more and take the assessment again. Note: it can take up to 24 hours for you to receive your certificate via email. Modules To become an Microsoft Defender for Cloud Ninja, you will need to complete each module. The content of each module will vary, refer to the legend to understand the type of content before clicking in the topic’s hyperlink. The table below summarizes the content of each module: Module Description 0 - CNAPP In this module you will familiarize yourself with the concepts of CNAPP and how to plan Defender for Cloud deployment as a CNAPP solution. 1 – Introducing Microsoft Defender for Cloud and Microsoft Defender Cloud plans In this module you will familiarize yourself with Microsoft Defender for Cloud and understand the use case scenarios. You will also learn about Microsoft Defender for Cloud and Microsoft Defender Cloud plans pricing and overall architecture data flow. 2 – Planning Microsoft Defender for Cloud In this module you will learn the main considerations to correctly plan Microsoft Defender for Cloud deployment. From supported platforms to best practices implementation. 3 – Enhance your Cloud Security Posture In this module you will learn how to leverage Cloud Security Posture management capabilities, such as Secure Score and Attack Path to continuous improvement of your cloud security posture. This module includes automation samples that can be used to facilitate secure score adoption and operations. 4 – Cloud Security Posture Management Capabilities in Microsoft Defender for Cloud In this module you will learn how to use the cloud security posture management capabilities available in Microsoft Defender for Cloud, which includes vulnerability assessment, inventory, workflow automation and custom dashboards with workbooks. 5 – Regulatory Compliance Capabilities in Microsoft Defender for Cloud In this module you will learn about the regulatory compliance dashboard in Microsoft Defender for Cloud and give you insights on how to include additional standards. In this module you will also familiarize yourself with Azure Blueprints for regulatory standards. 6 – Cloud Workload Protection Platform Capabilities in Azure Defender In this module you will learn how the advanced cloud capabilities in Microsoft Defender for Cloud work, which includes JIT, File Integrity Monitoring and Adaptive Application Control. This module also covers how threat protection works in Microsoft Defender for Cloud, the different categories of detections, and how to simulate alerts. 7 – Streaming Alerts and Recommendations to a SIEM Solution In this module you will learn how to use native Microsoft Defender for Cloud capabilities to stream recommendations and alerts to different platforms. You will also learn more about Azure Sentinel native connectivity with Microsoft Defender for Cloud. Lastly, you will learn how to leverage Graph Security API to stream alerts from Microsoft Defender for Cloud to Splunk. 8 – Integrations and APIs In this module you will learn about the different integration capabilities in Microsoft Defender for Cloud, how to connect Tenable to Microsoft Defender for Cloud, and how other supported solutions can be integrated with Microsoft Defender for Cloud. 9 - DevOps Security In this module you will learn more about DevOps Security capabilities in Defender for Cloud. You will be able to follow the interactive guide to understand the core capabilities and how to navigate through the product. 10 - Defender for APIs In this module you will learn more about the new plan announced at RSA 2023. You will be able to follow the steps to onboard the plan and validate the threat detection capability. 11 - AI Posture Management and Workload Protection In this module you will learn more about the risks of Gen AI and how Defender for Cloud can help improve your AI posture management and detect threats against your Gen AI apps. Module 0 - Cloud Native Application Protection Platform (CNAPP) Improving Your Multi-Cloud Security with a CNAPP - a vendor agnostic approach Microsoft CNAPP Solution Planning and Operationalizing Microsoft CNAPP Understanding Cloud Native Application Protection Platforms (CNAPP) Cloud Native Applications Protection Platform (CNAPP) Microsoft CNAPP eBook Understanding CNAPP Why Microsoft Leads the IDC CNAPP MarketScape: Key Insights for Security Decision-Makers Module 1 - Introducing Microsoft Defender for Cloud What is Microsoft Defender for Cloud? A New Approach to Get Your Cloud Risks Under Control Getting Started with Microsoft Defender for Cloud Implementing a CNAPP Strategy to Embed Security From Code to Cloud Boost multicloud security with a comprehensive code to cloud strategy A new name for multi-cloud security: Microsoft Defender for Cloud Common questions about Defender for Cloud MDC Cost Calculator Breaking down security silos: Microsoft Defender for Cloud Expands into the Defender Portal Microsoft Defender for Cloud Customer Newsletter (03/2026) New innovations in Microsoft Defender to strengthen multi-cloud, containers, and AI model security (03/2026) Module 2 – Planning Microsoft Defender for Cloud Features for IaaS workloads Features for PaaS workloads Built-in RBAC Roles in Microsoft Defender for Cloud Enterprise Onboarding Guide Design Considerations for Log Analytics Workspace Onboarding on-premises machines using Windows Admin Center Understanding Security Policies in Microsoft Defender for Cloud Creating Custom Policies Centralized Policy Management in Microsoft Defender for Cloud using Management Groups Planning Data Collection for IaaS VMs Microsoft Defender for Cloud PoC Series – Microsoft Defender for Storage How to Effectively Perform an Microsoft Defender for Cloud PoC Microsoft Defender for Cloud PoC Series – Microsoft Defender CSPM Microsoft Defender for DevOps GitHub Connector - Microsoft Defender for Cloud PoC Series Grant tenant-wide permissions to yourself Simplifying Onboarding to Microsoft Defender for Cloud with Terraform Module 3 – Enhance your Cloud Security Posture How Secure Score affects your governance Cloud secure score in Microsoft Defender for Cloud - Microsoft Defender for Cloud Enhance your Secure Score in Microsoft Defender for Cloud Security recommendations Active User (Public Preview) Resource exemption Create custom security standards and recommendations - Microsoft Defender for Cloud Deliver a Security Score weekly briefing Send Microsoft Defender for Cloud Recommendations to Azure Resource Stakeholders User roles and permissions - Microsoft Defender for Cloud Secure Score Reduction Alert Improved experience for managing the default Azure security policies Security Policy Enhancements in Defender for Cloud Create custom recommendations and security standards Secure Score Overtime Workbook Automation Artifacts for Secure Score Recommendations Connecting Defender for Cloud with Jira Remediation Scripts Module 4 – Cloud Security Posture Management Capabilities in Microsoft Defender for Cloud CSPM in Defender for Cloud Take a Proactive Risk-Based Approach to Securing your Cloud Native Applications Predict future security incidents! Cloud Security Posture Management with Microsoft Defender Software inventory filters added to asset inventory Drive your organization to security actions using Governance experience Managing Asset Inventory in Microsoft Defender for Cloud Vulnerability Assessment Workbook Template Vulnerability Assessment for Containers Implementing Workflow Automation Workflow Automation Artifacts Using Microsoft Defender for Cloud API for Workflow Automation What you need to know when deleting and re-creating the security connector(s) in Defender for Cloud Connect AWS Account with Microsoft Defender for Cloud Video Demo - Connecting AWS accounts Microsoft Defender for Cloud PoC Series - Multi-cloud with AWS Onboarding your AWS/GCP environment to Microsoft Defender for Cloud with Terraform How to better manage cost of API calls that Defender for Cloud makes to AWS Cloud posture management adds serverless protection for Azure and AWS Integrate AWS CloudTrail logs with Microsoft Defender for Cloud Connect GCP Account with Microsoft Defender for Cloud Protecting Containers in GCP with Defender for Containers Video Demo - Connecting GCP Accounts Microsoft Defender for Cloud PoC Series - Multicloud with GCP All You Need to Know About Microsoft Defender for Cloud Multicloud Protection Custom recommendations for AWS and GCP 31 new and enhanced multicloud regulatory standards coverage Azure Monitor Workbooks integrated into Microsoft Defender for Cloud and three templates provided How to Generate a Microsoft Defender for Cloud exemption and disable policy report Exempt resources at scale - Microsoft Defender for Cloud Cloud security posture and contextualization across cloud boundaries from a single dashboard Best Practices to Manage and Mitigate Security Recommendations Defender CSPM Defender CSPM Plan Options Go Beyond Checkboxes: Proactive Cloud Security with Microsoft Defender CSPM What’s New in Microsoft Defender CSPM Cloud Security Explorer Identify and remediate attack paths Agentless scanning for machines Cloud security explorer and Attack path analysis Governance Rules at Scale Governance Improvements Data Security Aware Posture Management Fast-Start Checklist for Microsoft Defender CSPM: From Enablement to Best Practices Unlocking API visibility: Defender for Cloud Expands API security to Function Apps and Logic Apps A Proactive Approach to Cloud Security Posture Management with Microsoft Defender for Cloud Prioritize Risk remediation with Microsoft Defender for Cloud Attack Path Analysis Understanding data aware security posture capability Agentless Container Posture Agentless Container Posture Management Microsoft Defender for Cloud - Automate Notifications when new Attack Paths are created Proactively secure your Google Cloud Resources with Microsoft Defender for Cloud Demystifying Defender CSPM Discover and Protect Sensitive Data with Defender for Cloud Defender for cloud's Agentless secret scanning for virtual machines is now generally available! Defender CSPM Support for GCP Data Security Dashboard Agentless Container Posture Management in Multicloud Agentless malware scanning for servers Recommendation Prioritization Unified insights from Microsoft Entra Permissions Management Defender CSPM Internet Exposure Analysis Future-Proofing Cloud Security with Defender CSPM ServiceNow's integration now includes Configuration Compliance module Agentless code scanning for GitHub and Azure DevOps (preview) 🚀 Suggested Labs: Improving your Secure Posture Connecting a GCP project Connecting an AWS project Defender CSPM Agentless container posture through Defender CSPM Contextual Security capabilities for AWS using Defender CSPM Module 5 – Regulatory Compliance Capabilities in Microsoft Defender for Cloud Understanding Regulatory Compliance Capabilities in Microsoft Defender for Cloud Adding new regulatory compliance standards Regulatory Compliance workbook Regulatory compliance dashboard now includes Azure Audit reports Microsoft cloud security benchmark: Azure compute benchmark is now aligned with CIS! Updated naming format of Center for Internet Security (CIS) standards in regulatory compliance CIS Azure Foundations Benchmark v2.0.0 in regulatory compliance dashboard Spanish National Security Framework (Esquema Nacional de Seguridad (ENS)) added to regulatory compliance dashboard for Azure Microsoft Defender for Cloud Adds Four New Regulatory Frameworks | Microsoft Community Hub 🚀 Suggested Lab: Regulatory Compliance Module 6 – Cloud Workload Protection Platform Capabilities in Microsoft Defender for Clouds Understanding Just-in-Time VM Access Implementing JIT VM Access File Integrity Monitoring in Microsoft Defender Understanding Threat Protection in Microsoft Defender Performing Advanced Risk Hunting in Defender for Cloud Microsoft Defender for Servers Demystifying Defender for Servers Onboarding directly (without Azure Arc) to Defender for Servers Agentless secret scanning for virtual machines in Defender for servers P2 & DCSPM Vulnerability Management in Defender for Cloud File Integrity Monitoring using Microsoft Defender for Endpoint File Integrity Monitoring requires MDE agent version 10.8799+ for legacy Windows machines (03/2026) Microsoft Defender for Containers Basics of Defender for Containers Secure your Containers from Build to Runtime Guarding Kubernetes Deployments: Runtime Gating for Vulnerable Images Now Generally Available AWS ECR Coverage in Defender for Containers Upgrade to Microsoft Defender Vulnerability Management End to end container security with unified SOC experience Binary drift detection episode Binary drift detection Cloud Detection Response experience Exploring the Latest Container Security Updates from Microsoft Ignite 2024 Unveiling Kubernetes lateral movement and attack paths with Microsoft Defender for Cloud Onboarding Docker Hub and JFrog Artifactory Improvements in Container’s Posture Management New AKS Security Dashboard in Defender for Cloud The Risk of Default Configuration: How Out-of-the-Box Helm Charts Can Breach Your Cluster Your cluster, your rules: Helm support for container security with Microsoft Defender for Cloud Defending Container Runtime from Malware with Microsoft Defender for Containers (03/2026) Microsoft Defender for Storage Protect your storage resources against blob-hunting Malware Scanning in Defender for Storage What's New in Defender for Storage Defender for Storage: Malware Scan Error Message Update Protecting Cloud Storage in the Age of AI Key findings from product telemetry: top storage security alerts across industries Malware scan results now in blob tags (ADLS Gen2 HNS | Public Preview) (03/2026) Microsoft Defender for SQL New Defender for SQL VA Defender for SQL on Machines Enhanced Agent Update Microsoft Defender for SQL Anywhere New autoprovisioning process for SQL Server on machines plan Enhancements for protecting hosted SQL servers across clouds and hybrid environments Defender for Open-Source Relational Databases Multicloud Modern Database Protection: From Visibility to Threat Detection with Microsoft Defender for Cloud (03/2026) Microsoft Defender for KeyVault Microsoft Defender for AppService Microsoft Defender for Resource Manager Understanding Security Incident Security Alert Correlation Alert Reference Guide 'Copy alert JSON' button added to security alert details pane Alert Suppression Simulating Alerts in Microsoft Defender for Cloud Alert validation Simulating alerts for Windows Simulating alerts for Containers Simulating alerts for Storage Simulating alerts for Microsoft Key Vault Simulating alerts for Microsoft Defender for Resource Manager Integration with Microsoft Defender for Endpoint Auto-provisioning of Microsoft Defender for Endpoint unified solution Resolve security threats with Microsoft Defender for Cloud Protect your servers and VMs from brute-force and malware attacks with Microsoft Defender for Cloud Filter security alerts by IP address Alerts by resource group Defender for Servers Security Alerts Improvements From visibility to action: The power of cloud detection and response 🚀 Suggested Labs: Workload Protections Agentless container vulnerability assessment scanning Microsoft Defender for Cloud database protection Protecting On-Prem Servers in Defender for Cloud Defender for Storage Module 7 – Streaming Alerts and Recommendations to a SIEM Solution Continuous Export capability in Microsoft Defender for Cloud Deploying Continuous Export using Azure Policy Connecting Microsoft Sentinel with Microsoft Defender for Cloud Stream alerts to monitoring solutions - Microsoft Defender for Cloud | Microsoft Learn Microsoft Sentinel bi-directional alert synchronization 🚀 Suggested Lab: Exporting Microsoft Defender for Cloud information to a SIEM Module 8 – Integrations and APIs Integration with Tenable Integrate security solutions in Microsoft Defender for Cloud Defender for Cloud integration with Defender EASM Defender for Cloud integration with Defender TI REST APIs for Microsoft Defender for Cloud Using Graph Security API to Query Alerts in Microsoft Defender for Cloud Automate(d) Security with Microsoft Defender for Cloud and Logic Apps Automating Cloud Security Posture and Cloud Workload Protection Responses Module 9 – DevOps Security Overview of Microsoft Defender for Cloud DevOps Security DevOps Security Interactive Guide Configure the Microsoft Security DevOps Azure DevOps extension Configure the Microsoft Security DevOps GitHub action Automate SecOps to Developer Communication with Defender for DevOps Compliance for Exposed Secrets Discovered by DevOps Security Automate DevOps Security Recommendation Remediation DevOps Security Workbook Remediating Security Issues in Code with Pull Request Annotations Code to Cloud Security using Microsoft Defender for DevOps GitHub Advanced Security for Azure DevOps alerts in Defender for Cloud Securing your GitLab Environment with Microsoft Defender for Cloud Bridging the Gap Between Code and Cloud with Defender for Cloud Integrate Defender for Cloud CLI with CI/CD pipelines Code Reachability Analysis 🚀 Suggested Labs: Onboarding Azure DevOps to Defender for Cloud Onboarding GitHub to Defender for Cloud Module 10 – Defender for APIs What is Microsoft Defender for APIs? Onboard Defender for APIs Validating Microsoft Defender for APIs Alerts API Security with Defender for APIs Microsoft Defender for API Security Dashboard Exempt functionality now available for Defender for APIs recommendations Create sample alerts for Defender for APIs detections Defender for APIs reach GA Increasing API Security Testing Visibility Boost Security with API Security Posture Management 🚀 Suggested Lab: Defender for APIs Module 11 – AI Posture Management and Threat Protection Secure your AI applications from code to runtime with Microsoft Defender for Cloud AI security posture management AI threat protection Extending Defender’s AI Threat Protection to Microsoft Foundry Agents Secure your AI applications from code to runtime Data and AI security dashboard Protecting Azure AI Workloads using Threat Protection for AI in Defender for Cloud Plug, Play, and Prey: The security risks of the Model Context Protocol Learn Live: Enable advanced threat protection for AI workloads with Microsoft Defender for Cloud Microsoft AI Security Story: Protection Across the Platform Microsoft Defender for AI Alerts Demystifying AI Security Posture Management Part 3: Unified Security Intelligence - Orchestrating GenAI Threat Detection with Microsoft Sentinel A new era of agents, a new era of posture Defending the AI Era: New Microsoft Capabilities to Protect AI (03/2026) 🚀 Suggested Lab: Security for AI workloads Are you ready to take your knowledge check? If so, click here. If you score 80% or more in the knowledge check, request your participation certificate here. If you achieved less than 80%, please review the questions that you got it wrong, study more and take the assessment again. Note: it can take up to 24 hours for you to receive your certificate via email. Other Resources Microsoft Defender for Cloud Labs Become an Microsoft Sentinel Ninja Become an MDE Ninja Cross-product lab (Defend the Flag) Release notes (updated every month) Important upcoming changes Have a great time ramping up in Microsoft Defender for Cloud and becoming a Microsoft Defender for Cloud Ninja!! Reviewer: Tom Janetscheck, Senior PMModern Database Protection: From Visibility to Threat Detection with Microsoft Defender for Cloud
Databases sit at the heart of modern businesses. They support everyday apps, reports and AI tools. For example, any time you engage a site that requires a username and password, there is a database at the back end that stores your login information. As organizations adopt multi-cloud and hybrid architectures, databases are generated all the time, creating database sprawl. As a result, tracking and managing every database, catching misconfigurations and vulnerabilities, knowing where sensitive information lives, all becomes increasingly difficult leaving a huge security gap. And because companies store their most valuable data, like your login information, credit card and social security numbers, in databases, databases are the main target for threat actors. Securing databases is no longer optional, yet getting started can feel daunting. Database security needs to address the gaps mentioned above – help organizations see their databases to help them monitor for misconfigurations and vulnerabilities, sensitive information and any suspicious activities that occur within the database that are indicative of an attack. Further, database security must meet customers where they are – in multi-cloud and hybrid environments. This five part blog series will introduce and explore database-specific security needs and how Defender for Cloud addresses the gaps through its deep visibility into your database estate, detection of misconfiguration, vulnerabilities and sensitive information, threat protection with alerts and Integrated security platform to manage it all. This blog, part one, will begin with an overview of today’s database infrastructure security needs. Then we will introduce Microsoft Defender for Cloud’s unique database protection capabilities to help address this gap. Modern Database Architectures and Their Security Implications Modern databases can be deployed in two main ways: on your own infrastructure or as a cloud service. In an on-premises or IaaS (Infrastructure as a Service) setup, you manage the underlying server or virtual machine. For example, running a SQL Server on a self-managed Windows server—whether in your data center or on a cloud VM in Azure or AWS—is an IaaS deployment (Microsoft Defender for Cloud refers to these as “SQL servers on machines”) that require server maintenance. The other approach is PaaS (Platform as a Service), where a cloud provider manages the host server for you. In a PaaS scenario, you simply use a hosted database service (such as Azure SQL Database, Azure SQL Managed Instance, Azure Database for PostgreSQL, or Amazon RDS) without worrying about the operating system or server maintenance. In either case, you need to secure both the database host (the server or VM) and the database itself (the data and database engine). It’s also important to distinguish between a database’s control plane and data plane. The control plane includes the external settings that govern your database environment—like network firewall rules or who can access the system. The data plane involves information and queries inside the database. An attacker might exploit a weak firewall setting on the control plane or use stolen credentials to run malicious queries on the data plane. To fully protect a database, you need visibility into both planes to catch suspicious behavior. Effective database protection must span both IaaS and PaaS environments and monitor both the control plane and data plane because they are common targets for threat actors. Security teams can then detect suspicious activity such as SQL injections, brute-force attempts, and lateral movement through your environment. A Unified Approach to Database Protection Built for Multicloud Modern database environments are fragmented across deployment models, database ownership, and teams. Databases run across IaaS and PaaS, span control and data planes, and in multiple clouds, yet protection is often pieced together from disconnected point solutions Microsoft Defender for Cloud is a cloud native application protection platform (CNAPP) solution that provides a unified, cloud-native approach to database protection—bringing together discovery, posture management, and threat detection across SQL (Iaas and Paas), open-source relational databases (OSS), and Cosmos DB databases. Defender for Cloud’s database protection uses both agent-based and agentless solutions to protect database resources on-premises, hybrid, multi-cloud and Azure. A lightweight agent-based solution is used for SQL servers on Azure virtual machines or virtual machines hosted outside Azure and allows for deeper inspection, while an agentless approach for managed databases stored in Azure or AWS RDS resources provide protection with seamless integration. Additionally, Defender for Cloud brings in other signals from the cloud environment, surfacing a secure score for security posture, an asset inventory, regulatory compliance, governance capabilities, and a cloud security graph that allows for proactive risk exploration. The value of database security in Defender for Cloud starts with pre and post breach visibility. Vulnerability assessment and data security posture management helps security admins understand their database security posture and, by following Defender for Cloud’s recommendations, security admins can harden their environment proactively. Vulnerability assessments scans surface remediation steps for configurations that do not follow industry’s best practices. These recommendations may include enabling encryption when data is at rest where applicable or database server should restrict public access ranges. Data security posture management in Defender for Cloud automatically helps security admins prioritize the riskiest databases by discovering sensitive data and surfacing related exposure and risk. When databases are associated with certain risks, Defender for Cloud will provide its findings in three ways: risk-based security recommendations, attack path analysis with Defender CSPM and the data and AI dashboard. The risk level is determined by other context related to the resource like, internet exposure or sensitive information. This way, Security admins will have a solid understanding of their database environment pre-breach and will have a prioritized list of resources to remediate based on risk or posture level. While we can do our best to harden the environment, breaches can still happen. Timely post-breach response is just as important. Threat detection capabilities within Defender for Cloud will identify anomalous activity in near real time so SOC analytes can take action to contain the attack immediately. Defender for Cloud monitors both the control and the data plane for any anomalous activity that indicates a threat, from brute force attack detections to access and query anomalies. To provide a unified security experience, Defender for Cloud natively integrates with the Microsoft Defender Portal. The Defender portal brings signals from Defender for Cloud to provide a single cloud-agnostic security experience, equipping security teams with tools like secure score for security posture, attack paths, and incidents and alerts. When anomalous activities occur in the environment, time is of the essence. Security teams must have context and tools to investigate a database resource, both in the control plan and the data plane, to remediate and mitigate future attacks quickly. Defender for Cloud and the Defender portal brings together a security ecosystem that allows SOC analysts to investigate, correlate activities and incidents with alerts, contain and respond accordingly. Take Action: Close the Database Blind Spot Today Modern database environments demand more than isolated controls or point solutions. As databases span hybrid and multiple clouds, security teams need a unified approach that delivers visibility, context, and actionable protection where the data lives. Microsoft Defender for Cloud provides organizations the visibility into all of your databases in a centralized Defender portal using its unique control and data plane findings so that security teams can identify misconfigurations. prioritize them based on cloud-context risk-based recommendations or proactively identify other attack scenarios using the attack path analysis while SOC analysts can investigate alerts and act quickly. Follow this story for part two. We’ll go into Defender for Cloud’s unique visibility into database resources to find misconfiguration gaps, sensitive information exposure, and contextual risks that may exist in your environment. Resources: Get started with Defender for Databases. Learn more about SQL vulnerability assessment. Learn more about Data Security Posture Management Learn more about Advanced Threat Protection Reviewers: YuriDiogenes, lisetteranga, talberdah
Defending Container Runtime from Malware with Microsoft Defender for Containers
In cloud-native environments, malware protection is no longer traditional antivirus — it is runtime workload security, ensuring containerized applications remain safe throughout their lifecycle. Many organizations focus on scanning container images before deployment. While image scanning is important, this does not stop runtime attacks. Image scanning protects before deployment, but malware detection protects during execution. Malware can enter cloud environments through container images, compromised CI/CD pipelines, exposed services, or misuse of legitimate administrative tools, making runtime malware detection an essential security control rather than an optional enhancement. Runtime Malware detection and Prevention acts as the last line of defence when preventive controls fail. If malware executes successfully inside a container, it may attempt Privilege escalation, Container escape and Host compromise. Antimalware in Defender for Containers Defender for Containers antimalware, powered by Microsoft Defender Antivirus cloud protection, near-real-time malware detection directly into container environments. The antimalware feature is available via Helm with sensor version 0.10.2 for AKS, GKE, and EKS. Defender for Containers Sensor Defender for Containers Antimalware provides: Runtime monitoring of container activity Malware detection on Container Workloads Malware detection for Kubernetes nodes Alerts integrated into Defender XDR Anti-malware detection and blocking - Microsoft Defender for Cloud | Microsoft Learn Container antimalware protection in Defender for Containers is powered by three main components: 1) Defender Sensor - version 0.10.2 installed via Helm or arc-extension The Defender sensor runs inside the Kubernetes cluster and monitors workload activity in real time. It provides: Runtime visibility into container processes Binary execution monitoring Behavioral inspection Alert and Block Malware execution Multicloud Support (Azure Kubernetes Service, AWS EKS, GCP GKE) Prerequisites: Ensure the following components of the Defender for containers plan are enabled: Defender sensor Security findings Registry access Kubernetes API access To Install Defender Sensor for Antimalware, ensure there are sufficient resources on your Kubernetes Cluster and outbound connectivity. In addition to the core sensor memory and CPU requirements, you need: Component Request Limit CPU 50m 300m Memory 128Mi 500Mi All sensor components use outbound-only connectivity (no inbound access required). To install Defender for Containers sensor follow the guidance here To Verify the sensor deployed successfully on all nodes, use the commands as screenshot below: You should see the collectors pods in Running state with 3/3 containers. 2) Antimalware Policy Engine Policies define what happens when malware is detected: Alert only Block execution Ignore (allowlisted cases) Policies can be scoped to Azure subscriptions, AWS Accounts and GCP Projects and also to Specific clusters, Namespaces, Pods, Images, Labels or workloads. This allows organizations to reduce false positives while enforcing strict security where needed. Host vs Workload Protection — How Sensor Covers Both Antimalware Rules can be applied to Resource scopes: Scope What Is Protected Workload (Container) Processes inside containers Host (Node) Kubernetes node OS and runtime Default rules include: Default antimalware workload rule Default antimalware host rule This matters because attackers often escape containers and target kubelet, container runtime, and node filesystem. Blocking malware at both workload and host layers prevents cluster takeover. To configure the Antimalware policy follow the guidance here To verify the antimalware policy is deployed to the cluster, login to your K8s cluster and use the commands as screenshot below: 3) Cloud Protection (Microsoft Defender Antivirus Cloud) Defender for Containers Sensor integrates with Microsoft Defender Antivirus cloud protection, which provides Global threat intelligence, Machine learning classification, Reputation scoring, Zero-day detection. When suspicious binaries appear, cloud analysis determines whether they should be allowed or blocked. To test Malware detection and blocking, upload an EICAR file to a running Container on your cluster. If policy action = Block Malware, the sensor performs enforcement. Blocking actions include, Killing malicious process and Generates Defender for Cloud alert as below: The malware is detected and execution is blocked. Defender for Cloud Alerts are also available in Defender XDR portal. Security Operations teams can further investigate the infected file by navigating to the Incidents and Alerts section in the Defender portal. When a container or pod is determined to be compromised, Defender XDR enables Security Operations Team to take response actions. For more details : Investigate and respond to container threats in the Microsoft Defender portal Binary Drift Detection and Prevention : Containers are expected to be immutable. Running containers should only execute binaries that came from the original container image. This is extremely important because most container attacks involve Curl/wget downloading malware, Crypto miners dropped post-compromise, Attack tools installed dynamically. For more details refer Binary drift detection and blocking Defender detects runtime drift, such as New binaries downloaded after deployment Files written into container filesystem Tools installed via reverse shell Payloads dropped by attackers To Configure drift detection and prevention policy follow the guidance here . When a drift is detected on a container workload, Defender for Container sensor detects drift and prevents it from being drifted. To test drift prevention, deploy a container and introduce a drift in the running container. The drift will be detected by the sensor and prevents drift, and alert is generated as shown in the screenshot below: References: Anti-malware detection and blocking Install Defender for Containers sensor using Helm Binary drift detection and blocking Investigate and respond to container threats in the Microsoft Defender portal Reviewed by: Eyal Gur, Principal Product Manager, Microsoft Defender for CloudMicrosoft Defender for Cloud Customer Newsletter
Check out monthly news for the rest of the MTP suite here! What's new in Defender for Cloud? Now in public preview, Defender for Cloud provides threat protection for AI agents built with Foundry, as part of the Defender for AI Services plan. Learn more about this in our documentation. Defender for Cloud’s Defender for SQL on machines plan provides a simulated alert feature to help validate deployment and test prepared security team for detection, response and automation workflows. For more details, please refer to this documentation. Check out other updates from last month here. Blogs of the month In February, our team published the following blog post we would like to share: Extending Defender's AI Threat Protection to Microsoft Foundry Agents Defender for Cloud in the field Revisit the announcement on the new Secure Score model and the enhancements available in the Defender Portal. New Secure Score model and Defender portal enhancements GitHub Community Module 12 in Defender for Cloud’s lab has been updated to include alert simulation! Database protection lab - module 12 Customer journey Discover how other organizations successfully use Microsoft Defender for Cloud to protect their cloud workloads. This month we are featuring ContraForce. ContraForce, a cybersecurity startup, built its platform on Microsoft’s robust security and AI ecosystem. Contraforce, while participating in Microsoft for Startup Pegasus program, addressed the issue of traditional, complex, and siloed security stacks by leveraging Microsoft Sentinel, Defender XDR, Entra ID and Microsoft Foundry. ContraForce was able to deliver enterprise-grade protection at scale, without the enterprise-level overhead. As a result, measured key outcomes like 90%+ incident automation, 93% reduced cost per incident, and 60x faster incident response. Join our community! We offer several customer connection programs within our private communities. By signing up, you can help us shape our products through activities such as reviewing product roadmaps, participating in co-design, previewing features, and staying up-to-date with announcements. Sign up at aka.ms/JoinCCP. We greatly value your input on the types of content that enhance your understanding of our security products. Your insights are crucial in guiding the development of our future public content. We aim to deliver material that not only educates but also resonates with your daily security challenges. Whether it’s through in-depth live webinars, real-world case studies, comprehensive best practice guides through blogs, or the latest product updates, we want to ensure our content meets your needs. Please submit your feedback on which of these formats do you find most beneficial and are there any specific topics you’re interested in https://aka.ms/PublicContentFeedback. Note: If you want to stay current with Defender for Cloud and receive updates in your inbox, please consider subscribing to our monthly newsletter: https://aka.ms/MDCNewsSubscribeExtending Defender’s AI Threat Protection to Microsoft Foundry Agents
Today’s blog post introduces new capabilities to strengthen the security and governance of AI agents using Microsoft Foundry Agent Service and explores how Microsoft Defender helps organizations secure Foundry agents as they move from experimentation to production.Microsoft Defender for Cloud Customer Newsletter
What's new in Defender for Cloud? Now in public preview, Microsoft Security Private Link allows for private connectivity between Defender for Cloud and your workloads. For more information, see our public documentation. Blogs of the month In January, our team published the following blog posts we would like to share: Guarding Kubernetes Deployments: Runtime gating for vulnerable images now GA Architecting Trust: A NIST-Based Security Governance Framework for AI Agents Defender for Cloud in the field Revisit the announcement on the CloudStorageAggregatedEvents table in XDR’s Advanced Hunting experience. Storage aggregated logs in XDR’s advanced hunting Visit our YouTube page GitHub Community Update your Defender for SQL on machines extension at scale Update Defender for SQL extension at scale Visit our GitHub page Customer journey Discover how other organizations successfully use Microsoft Defender for Cloud to protect their cloud workloads. This month we are featuring Toyota Leasing Thailand. Toyota Leasing Thailand, a financial services subsidiary of Toyota, provides financing, insurance and mobility services and is entrusted with sensitive personal data. Integrating with Defender, Entra and Purview, Security Copilot provided the SOC and the IT team a unified view, streamlined operations and reporting to reduce response times on phishing attacks from hours to minutes. Join our community! We offer several customer connection programs within our private communities. By signing up, you can help us shape our products through activities such as reviewing product roadmaps, participating in co-design, previewing features, and staying up-to-date with announcements. Sign up at aka.ms/JoinCCP. We greatly value your input on the types of content that enhance your understanding of our security products. Your insights are crucial in guiding the development of our future public content. We aim to deliver material that not only educates but also resonates with your daily security challenges. Whether it’s through in-depth live webinars, real-world case studies, comprehensive best practice guides through blogs, or the latest product updates, we want to ensure our content meets your needs. Please submit your feedback on which of these formats do you find most beneficial and are there any specific topics you’re interested in https://aka.ms/PublicContentFeedback. Note: If you want to stay current with Defender for Cloud and receive updates in your inbox, please consider subscribing to our monthly newsletter: https://aka.ms/MDCNewsSubscribe
Part 3: Unified Security Intelligence - Orchestrating GenAI Threat Detection with Microsoft Sentinel
Why Sentinel for GenAI Security Observability? Before diving into detection rules, let's address why Microsoft Sentinel is uniquely positioned for GenAI security operations—especially compared to traditional or non-native SIEMs. Native Azure Integration: Zero ETL Overhead The problem with external SIEMs: To monitor your GenAI workloads with a third-party SIEM, you need to: Configure log forwarding from Log Analytics to external systems Set up data connectors or agents for Azure OpenAI audit logs Create custom parsers for Azure-specific log schemas Maintain authentication and network connectivity between Azure and your SIEM Pay data egress costs for logs leaving Azure The Sentinel advantage: Your logs are already in Azure. Sentinel connects directly to: Log Analytics workspace - Where your Container Insights logs already flow Azure OpenAI audit logs - Native access without configuration Azure AD sign-in logs - Instant correlation with identity events Defender for Cloud alerts - Platform-level AI threat detection included Threat intelligence feeds - Microsoft's global threat data built-in Microsoft Defender XDR - AI-driven cybersecurity that unifies threat detection and response across endpoints, email, identities, cloud apps and Sentinel There's no data movement, no ETL pipelines, and no latency from log shipping. Your GenAI security data is queryable in real-time. KQL: Built for Complex Correlation at Scale Why this matters for GenAI: Detecting sophisticated AI attacks requires correlating: Application logs (your code from Part 2) Azure OpenAI service logs (API calls, token usage, throttling) Identity signals (who authenticated, from where) Threat intelligence (known malicious IPs) Defender for Cloud alerts (platform-level anomalies) KQL's advantage: Kusto Query Language is designed for this. You can: Join across multiple data sources in a single query Parse nested JSON (like your structured logs) natively Use time-series analysis functions for anomaly detection and behavior patterns Aggregate millions of events in seconds Extract entities (users, IPs, sessions) automatically for investigation graphs Example: Correlating your app logs with Azure AD sign-ins and Defender alerts takes 10 lines of KQL. In a traditional SIEM, this might require custom scripts, data normalization, and significantly slower performance. User Security Context Flows Natively Remember the user_security_context you pass in extra_body from Part 2? That context: Automatically appears in Azure OpenAI's audit logs Flows into Defender for Cloud AI alerts Is queryable in Sentinel without custom parsing Maps to the same identity schema as Azure AD logs With external SIEMs: You'd need to: Extract user context from your application logs Separately ingest Azure OpenAI logs Write correlation logic to match them Maintain entity resolution across different data sources With Sentinel: It just works. The end_user_id, source_ip, and application_name are already normalized across Azure services. Built-In AI Threat Detection Sentinel includes pre-built detections for cloud and AI workloads: Azure OpenAI anomalous access patterns (out of the box) Unusual token consumption (built-in analytics templates) Geographic anomalies (using Azure's global IP intelligence) Impossible travel detection (cross-referencing sign-ins with AI API calls) Microsoft Defender XDR (correlation with endpoint, email, cloud app signals) These aren't generic "high volume" alerts—they're tuned for Azure AI services by Microsoft's security research team. You can use them as-is or customize them with your application-specific context. Entity Behavior Analytics (UEBA) Sentinel's UEBA automatically builds baselines for: Normal request volumes per user Typical request patterns per application Expected geographic access locations Standard model usage patterns Then it surfaces anomalies: "User_12345 normally makes 10 requests/day, suddenly made 500 in an hour" "Application_A typically uses GPT-3.5, suddenly switched to GPT-4 exclusively" "User authenticated from Seattle, made AI requests from Moscow 10 minutes later" This behavior modeling happens automatically—no custom ML model training required. Traditional SIEMs would require you to build this logic yourself. The Bottom Line For GenAI security on Azure: Sentinel reduces time-to-detection because data is already there Correlation is simpler because everything speaks the same language Investigation is faster because entities are automatically linked Cost is lower because you're not paying data egress fees Maintenance is minimal because connectors are native If your GenAI workloads are on Azure, using anything other than Sentinel means fighting against the platform instead of leveraging it. From Logs to Intelligence: The Complete Picture Your structured logs from Part 2 are flowing into Log Analytics. Here's what they look like: { "timestamp": "2025-10-21T14:32:17.234Z", "level": "INFO", "message": "LLM Request Received", "request_id": "a7c3e9f1-4b2d-4a8e-9c1f-3e5d7a9b2c4f", "session_id": "550e8400-e29b-41d4-a716-446655440000", "prompt_hash": "d3b07384d113edec49eaa6238ad5ff00", "security_check_passed": "PASS", "source_ip": "203.0.113.42", "end_user_id": "user_550e8400", "application_name": "AOAI-Customer-Support-Bot", "model_deployment": "gpt-4-turbo" } These logs are in the ContainerLogv2 table since our application “AOAI-Customer-Support-Bot” is running on Azure Kubernetes Services (AKS). Steps to Setup AKS to stream logs to Sentinel/Log Analytics From Azure portal, navigate to your AKS, then to Monitoring -> Insights Select Monitor Settings Under Container Logs Select the Sentinel-enabled Log Analytics workspace Select Logs and events Check the ‘Enable ContainerLogV2’ and ‘Enable Syslog collection’ options More details can be found at this link Kubernetes monitoring in Azure Monitor - Azure Monitor | Microsoft Learn Critical Analytics Rules: What to Detect and Why Rule 1: Prompt Injection Attack Detection Why it matters: Prompt injection is the GenAI equivalent of SQL injection. Attackers try to manipulate the model by overriding system instructions. Multiple attempts indicate intentional malicious behavior. What to detect: 3+ prompt injection attempts within 10 minutes from similar IP let timeframe = 1d; let threshold = 3; AlertEvidence | where TimeGenerated >= ago(timeframe) and EntityType == "Ip" | where DetectionSource == "Microsoft Defender for AI Services" | where Title contains "jailbreak" or Title contains "prompt injection" | summarize count() by bin (TimeGenerated, 1d), RemoteIP | where count_ >= threshold What the SOC sees: User identity attempting injection Source IP and geographic location Sample prompts for investigation Frequency indicating automation vs. manual attempts Severity: High (these are actual attempts to bypass security) Rule 2: Content Safety Filter Violations Why it matters: When Azure AI Content Safety blocks a request, it means harmful content (violence, hate speech, etc.) was detected. Multiple violations indicate intentional abuse or a compromised account. What to detect: Users with 3+ content safety violations in a 1 hour block during a 24 hour time period. let timeframe = 1d; let threshold = 3; ContainerLogV2 | where TimeGenerated >= ago(timeframe) | where isnotempty(LogMessage.end_user_id) | where LogMessage.security_check_passed == "FAIL" | extend source_ip=tostring(LogMessage.source_ip) | extend end_user_id=tostring(LogMessage.end_user_id) | extend session_id=tostring(LogMessage.session_id) | extend application_name = tostring(LogMessage.application_name) | extend security_check_passed = tostring (LogMessage.security_check_passed) | summarize count() by bin(TimeGenerated, 1h),source_ip,end_user_id,session_id,Computer,application_name,security_check_passed | where count_ >= threshold What the SOC sees: Severity based on violation count Time span showing if it's persistent vs. isolated Prompt samples (first 80 chars) for context Session ID for conversation history review Severity: High (these are actual harmful content attempts) Rule 3: Rate Limit Abuse Why it matters: Persistent rate limit violations indicate automated attacks, credential stuffing, or attempts to overwhelm the system. Legitimate users who hit rate limits don't retry 10+ times in minutes. What to detect: Users blocked by rate limiter 5+ times in 10 minutes let timeframe = 1h; let threshold = 5; AzureDiagnostics | where ResourceProvider == "MICROSOFT.COGNITIVESERVICES" | where OperationName == "Completions" or OperationName contains "ChatCompletions" | extend tokensUsed = todouble(parse_json(properties_s).usage.total_tokens) | summarize totalTokens = sum(tokensUsed), requests = count(), rateLimitErrors = countif(httpstatuscode_s == "429") by bin(TimeGenerated, 1h) | where count_ >= threshold What the SOC sees: Whether it's a bot (immediate retries) or human (gradual retries) Duration of attack Which application is targeted Correlation with other security events from same user/IP Severity: Medium (nuisance attack, possible reconnaissance) Rule 4: Anomalous Source IP for User Why it matters: A user suddenly accessing from a new country or VPN could indicate account compromise. This is especially critical for privileged accounts or after-hours access. What to detect: User accessing from an IP never seen in the last 7 days let lookback = 7d; let recent = 1h; let baseline = IdentityLogonEvents | where Timestamp between (ago(lookback + recent) .. ago(recent)) | where isnotempty(IPAddress) | summarize knownIPs = make_set(IPAddress) by AccountUpn; ContainerLogV2 | where TimeGenerated >= ago(recent) | where isnotempty(LogMessage.source_ip) | extend source_ip=tostring(LogMessage.source_ip) | extend end_user_id=tostring(LogMessage.end_user_id) | extend session_id=tostring(LogMessage.session_id) | extend application_name = tostring(LogMessage.application_name) | extend security_check_passed = tostring (LogMessage.security_check_passed) | extend full_prompt_sample = tostring (LogMessage.full_prompt_sample) | lookup baseline on $left.AccountUpn == $right.end_user_id | where isnull(knownIPs) or IPAddress !in (knownIPs) | project TimeGenerated, source_ip, end_user_id, session_id, Computer, application_name, security_check_passed, full_prompt_sample What the SOC sees: User identity and new IP address Geographic location change Whether suspicious prompts accompanied the new IP Timing (after-hours access is higher risk) Severity: Medium (environment compromise, reconnaissance) Rule 5: Coordinated Attack - Same Prompt from Multiple Users Why it matters: When 5+ users send identical prompts, it indicates a bot network, credential stuffing, or organized attack campaign. This is not normal user behavior. What to detect: Same prompt hash from 5+ different users within 1 hour let timeframe = 1h; let threshold = 5; ContainerLogV2 | where TimeGenerated >= ago(timeframe) | where isnotempty(LogMessage.prompt_hash) | where isnotempty(LogMessage.end_user_id) | extend source_ip=tostring(LogMessage.source_ip) | extend end_user_id=tostring(LogMessage.end_user_id) | extend prompt_hash=tostring(LogMessage.prompt_hash) | extend application_name = tostring(LogMessage.application_name) | extend security_check_passed = tostring (LogMessage.security_check_passed) | project TimeGenerated, prompt_hash, source_ip, end_user_id, application_name, security_check_passed | summarize DistinctUsers = dcount(end_user_id), Attempts = count(), Users = make_set(end_user_id, 100), IpAddress = make_set(source_ip, 100) by prompt_hash, bin(TimeGenerated, 1h) | where DistinctUsers >= threshold What the SOC sees: Attack pattern (single attacker with stolen accounts vs. botnet) List of compromised user accounts Source IPs for blocking Prompt sample to understand attack goal Severity: High (indicates organized attack) Rule 6: Malicious model detected Why it matters: Model serialization attacks can lead to serious compromise. When Defender for Cloud Model Scanning identifies issues with a custom or opensource model that is part of Azure ML Workspace, Registry, or hosted in Foundry, that may be or may not be a user oversight. What to detect: Model scan results from Defender for Cloud and if it is being actively used. What the SOC sees: Malicious model Applications leveraging the model Source IPs and users accessed the model Severity: Medium (can be user oversight) Advanced Correlation: Connecting the Dots The power of Sentinel is correlating your application logs with other security signals. Here are the most valuable correlations: Correlation 1: Failed GenAI Requests + Failed Sign-Ins = Compromised Account Why: Account showing both authentication failures and malicious AI prompts is likely compromised within a 1 hour timeframe l let timeframe = 1h; ContainerLogV2 | where TimeGenerated >= ago(timeframe) | where isnotempty(LogMessage.source_ip) | extend source_ip=tostring(LogMessage.source_ip) | extend end_user_id=tostring(LogMessage.end_user_id) | extend session_id=tostring(LogMessage.session_id) | extend application_name = tostring(LogMessage.application_name) | extend security_check_passed = tostring (LogMessage.security_check_passed) | extend full_prompt_sample = tostring (LogMessage.full_prompt_sample) | extend message = tostring (LogMessage.message) | where security_check_passed == "FAIL" or message contains "WARNING" | join kind=inner ( SigninLogs | where ResultType != 0 // 0 means success, non-zero indicates failure | project TimeGenerated, UserPrincipalName, ResultType, ResultDescription, IPAddress, Location, AppDisplayName ) on $left.end_user_id == $right.UserPrincipalName | project TimeGenerated, source_ip, end_user_id, application_name, full_prompt_sample, prompt_hash, message, security_check_passed Severity: High (High probability of compromise) Correlation 2: Application Logs + Defender for Cloud AI Alerts Why: Defender for Cloud AI Threat Protection detects platform-level threats (unusual API patterns, data exfiltration attempts). When both your code and the platform flag the same user, confidence is very high. let timeframe = 1h; ContainerLogV2 | where TimeGenerated >= ago(timeframe) | where isnotempty(LogMessage.source_ip) | extend source_ip=tostring(LogMessage.source_ip) | extend end_user_id=tostring(LogMessage.end_user_id) | extend session_id=tostring(LogMessage.session_id) | extend application_name = tostring(LogMessage.application_name) | extend security_check_passed = tostring (LogMessage.security_check_passed) | extend full_prompt_sample = tostring (LogMessage.full_prompt_sample) | extend message = tostring (LogMessage.message) | where security_check_passed == "FAIL" or message contains "WARNING" | join kind=inner ( AlertEvidence | where TimeGenerated >= ago(timeframe) and AdditionalFields.Asset == "true" | where DetectionSource == "Microsoft Defender for AI Services" | project TimeGenerated, Title, CloudResource ) on $left.application_name == $right.CloudResource | project TimeGenerated, application_name, end_user_id, source_ip, Title Severity: Critical (Multi-layer detection) Correlation 3: Source IP + Threat Intelligence Feeds Why: If requests come from known malicious IPs (C2 servers, VPN exit nodes used in attacks), treat them as high priority even if behavior seems normal. //This rule correlates GenAI app activity with Microsoft Threat Intelligence feed available in Sentinel and Microsoft XDR for malicious IP IOCs let timeframe = 10m; ContainerLogV2 | where TimeGenerated >= ago(timeframe) | where isnotempty(LogMessage.source_ip) | extend source_ip=tostring(LogMessage.source_ip) | extend end_user_id=tostring(LogMessage.end_user_id) | extend session_id=tostring(LogMessage.session_id) | extend application_name = tostring(LogMessage.application_name) | extend security_check_passed = tostring (LogMessage.security_check_passed) | extend full_prompt_sample = tostring (LogMessage.full_prompt_sample) | join kind=inner ( ThreatIntelIndicators | where IsActive == "true" | where ObservableKey startswith "ipv4-addr" or ObservableKey startswith "network-traffic" | project IndicatorIP = ObservableValue ) on $left.source_ip == $right.IndicatorIP | project TimeGenerated, source_ip, end_user_id, application_name, full_prompt_sample, security_check_passed Severity: High (Known bad actor) Workbooks: What Your SOC Needs to See Executive Dashboard: GenAI Security Health Purpose: Leadership wants to know: "Are we secure?" Answer with metrics. Key visualizations: Security Status Tiles (24 hours) Total Requests Success Rate Blocked Threats (Self detected + Content Safety + Threat Protection for AI) Rate Limit Violations Model Security Score (Red Team evaluation status of currently deployed model) ContainerLogV2 | where TimeGenerated > ago (1d) | extend security_check_passed = tostring (LogMessage.security_check_passed) | summarize SuccessCount=countif(security_check_passed == "PASS"), FailedCount=countif(security_check_passed == "FAIL") by bin(TimeGenerated, 1h) | extend TotalRequests = SuccessCount + FailedCount | extend SuccessRate = todouble(SuccessCount)/todouble(TotalRequests) * 100 | order by SuccessRate 1. Trend Chart: Pass vs. Fail Over Time Shows if attack volume is increasing Identifies attack time windows Validates that defenses are working ContainerLogV2 | where TimeGenerated > ago (14d) | extend security_check_passed = tostring (LogMessage.security_check_passed) | summarize SuccessCount=countif(security_check_passed == "PASS"), FailedCount=countif(security_check_passed == "FAIL") by bin(TimeGenerated, 1d) | render timechart 2. Top 10 Users by Security Events Bar chart of users with most failures ContainerLogV2 | where TimeGenerated > ago (1d) | where isnotempty(LogMessage.end_user_id) | extend end_user_id=tostring(LogMessage.end_user_id) | extend security_check_passed = tostring (LogMessage.security_check_passed) | where security_check_passed == "FAIL" | summarize FailureCount = count() by end_user_id | top 20 by FailureCount | render barchart Applications with most failures ContainerLogV2 | where TimeGenerated > ago (1d) | where isnotempty(LogMessage.application_name) | extend application_name=tostring(LogMessage.application_name) | extend security_check_passed = tostring (LogMessage.security_check_passed) | where security_check_passed == "FAIL" | summarize FailureCount = count() by application_name | top 20 by FailureCount | render barchart 3. Geographic Threat Map Where are attacks originating? Useful for geo-blocking decisions ContainerLogV2 | where TimeGenerated > ago (1d) | where isnotempty(LogMessage.application_name) | extend application_name=tostring(LogMessage.application_name) | extend source_ip=tostring(LogMessage.source_ip) | extend security_check_passed = tostring (LogMessage.security_check_passed) | where security_check_passed == "FAIL" | extend GeoInfo = geo_info_from_ip_address(source_ip) | project sourceip, GeoInfo.counrty, GeoInfo.city Analyst Deep-Dive: User Behavior Analysis Purpose: SOC analyst investigating a specific user or session Key components: 1. User Activity Timeline Every request from the user in time order ContainerLogV2 | where isnotempty(LogMessage.end_user_id) | project TimeGenerated, LogMessage.source_ip, LogMessage.end_user_id, LogMessage. session_id, Computer, LogMessage.application_name, LogMessage.request_id, LogMessage.message, LogMessage.full_prompt_sample | order by tostring(LogMessage_end_user_id), TimeGenerated Color-coded by security status AlertInfo | where DetectionSource == "Microsoft Defender for AI Services" | project TimeGenerated, AlertId, Title, Category, Severity, SeverityColor = case( Severity == "High", "🔴 High", Severity == "Medium", "🟠 Medium", Severity == "Low", "🟢 Low", "⚪ Unknown" ) 2. Session Analysis Table All sessions for the user ContainerLogV2 | where TimeGenerated > ago (1d) | where isnotempty(LogMessage.end_user_id) | extend end_user_id=tostring(LogMessage.end_user_id) | where end_user_id == "<username>" // Replace with actual username | extend application_name=tostring(LogMessage.application_name) | extend source_ip=tostring(LogMessage.source_ip) | extend session_id=tostri1ng(LogMessage.session_id) | extend security_check_passed = tostring (LogMessage.security_check_passed) | project TimeGenerated, session_id, end_user_id, application_name, security_check_passed Failed requests per session ContainerLogV2 | where TimeGenerated > ago (1d) | extend security_check_passed = tostring (LogMessage.security_check_passed) | where security_check_passed == "FAIL" | extend end_user_id=tostring(LogMessage.end_user_id) | extend session_id=tostring(LogMessage.session_id) | extend security_check_passed = tostring (LogMessage.security_check_passed) | summarize Failed_Sessions = count() by end_user_id, session_id | order by Failed_Sessions Session duration ContainerLogV2 | where TimeGenerated > ago (1d) | where isnotempty(LogMessage.session_id) | extend security_check_passed = tostring (LogMessage.security_check_passed) | where security_check_passed == "PASS" | extend end_user_id=tostring(LogMessage.end_user_id) | extend session_id=tostring(LogMessage.session_id) | extend application_name=tostring(LogMessage.application_name) | extend source_ip=tostring(LogMessage.source_ip) | summarize Start=min(TimeGenerated), End=max(TimeGenerated), count() by end_user_id, session_id, source_ip, application_name | extend DurationSeconds = datetime_diff("second", End, Start) 3. Prompt Pattern Detection Unique prompts by hash Frequency of each pattern Detect if user is fuzzing/testing boundaries Sample query for user investigation: ContainerLogV2 | where TimeGenerated > ago (14d) | where isnotempty(LogMessage.prompt_hash) | where isnotempty(LogMessage.full_prompt_sample) | extend prompt_hash=tostring(LogMessage.prompt_hash) | extend full_prompt_sample=tostring(LogMessage.full_prompt_sample) | extend application_name=tostring(LogMessage.application_name) | summarize count() by prompt_hash, full_prompt_sample | order by count_ Threat Hunting Dashboard: Proactive Detection Purpose: Find threats before they trigger alerts Key queries: 1. Suspicious Keywords in Prompts (e.g. Ignore, Disregard, system prompt, instructions, DAN, jailbreak, pretend, roleplay) let suspicious_prompts = externaldata (content_policy:int, content_policy_name:string, q_id:int, question:string) [ @"https://raw.githubusercontent.com/verazuo/jailbreak_llms/refs/heads/main/data/forbidden_question/forbidden_question_set.csv"] with (format="csv", has_header_row=true, ignoreFirstRecord=true); ContainerLogV2 | where TimeGenerated > ago (14d) | where isnotempty(LogMessage.full_prompt_sample) | extend full_prompt_sample=tostring(LogMessage.full_prompt_sample) | where full_prompt_sample in (suspicious_prompts) | extend end_user_id=tostring(LogMessage.end_user_id) | extend session_id=tostring(LogMessage.session_id) | extend application_name=tostring(LogMessage.application_name) | extend source_ip=tostring(LogMessage.source_ip) | project TimeGenerated, session_id, end_user_id, source_ip, application_name, full_prompt_sample 2. High-Volume Anomalies User sending too many requests by a IP or User. Assuming that Foundry Projects are configured to use Azure AD and not API Keys. //50+ requests in 1 hour let timeframe = 1h; let threshold = 50; AzureDiagnostics | where ResourceProvider == "MICROSOFT.COGNITIVESERVICES" | where OperationName == "Completions" or OperationName contains "ChatCompletions" | extend tokensUsed = todouble(parse_json(properties_s).usage.total_tokens) | summarize totalTokens = sum(tokensUsed), requests = count() by bin(TimeGenerated, 1h),CallerIPAddress | where count_ >= threshold 3. Rare Failures (Novel Attack Detection) Rare failures might indicate zero-day prompts or new attack techniques //10 or more failures in 24 hours ContainerLogV2 | where TimeGenerated >= ago (24h) | where isnotempty(LogMessage.security_check_passed) | extend security_check_passed=tostring(LogMessage.security_check_passed) | where security_check_passed == "FAIL" | extend application_name=tostring(LogMessage.application_name) | extend end_user_id=tostring(LogMessage.end_user_id) | extend source_ip=tostring(LogMessage.source_ip) | summarize FailedAttempts = count(), FirstAttempt=min(TimeGenerated), LastAttempt=max(TimeGenerated) by application_name | extend DurationHours = datetime_diff('hour', LastAttempt, FirstAttempt) | where DurationHours >= 24 and FailedAttempts >=10 | project application_name, FirstAttempt, LastAttempt, DurationHours, FailedAttempts Measuring Success: Security Operations Metrics Key Performance Indicators Mean Time to Detect (MTTD): let AppLog = ContainerLogV2 | extend application_name=tostring(LogMessage.application_name) | extend security_check_passed=tostring (LogMessage.security_check_passed) | extend session_id=tostring(LogMessage.session_id) | extend end_user_id=tostring(LogMessage.end_user_id) | extend source_ip=tostring(LogMessage.source_ip) | where security_check_passed=="FAIL" | summarize FirstLogTime=min(TimeGenerated) by application_name, session_id, end_user_id, source_ip; let Alert = AlertEvidence | where DetectionSource == "Microsoft Defender for AI Services" | extend end_user_id = tostring(AdditionalFields.AadUserId) | extend source_ip=RemoteIP | extend application_name=CloudResource | summarize FirstAlertTime=min(TimeGenerated) by AlertId, Title, application_name, end_user_id, source_ip; AppLog | join kind=inner (Alert) on application_name, end_user_id, source_ip | extend DetectionDelayMinutes=datetime_diff('minute', FirstAlertTime, FirstLogTime) | summarize MTTD_Minutes=round(avg (DetectionDelayMinutes),2) by AlertId, Title Target: <= 15 minutes from first malicious activity to alert Mean Time to Respond (MTTR): SecurityIncident | where Status in ("New", "Active") | where CreatedTime >= ago(14d) | extend ResponseDelay = datetime_diff('minute', LastActivityTime, FirstActivityTime) | summarize MTTR_Minutes = round (avg (ResponseDelay),2) by CreatedTime, IncidentNumber | order by CreatedTime, IncidentNumber asc Target: < 4 hours from alert to remediation Threat Detection Rate: ContainerLogV2 | where TimeGenerated > ago (1d) | extend security_check_passed = tostring (LogMessage.security_check_passed) | summarize SuccessCount=countif(security_check_passed == "PASS"), FailedCount=countif(security_check_passed == "FAIL") by bin(TimeGenerated, 1h) | extend TotalRequests = SuccessCount + FailedCount | extend SuccessRate = todouble(SuccessCount)/todouble(TotalRequests) * 100 | order by SuccessRate Context: 1-3% is typical for production systems (most traffic is legitimate) What You've Built By implementing the logging from Part 2 and the analytics rules in this post, your SOC now has: ✅ Real-time threat detection - Alerts fire within minutes of malicious activity ✅ User attribution - Every incident has identity, IP, and application context ✅ Pattern recognition - Detect both volume-based and behavior-based attacks ✅ Correlation across layers - Application logs + platform alerts + identity signals ✅ Proactive hunting - Dashboards for finding threats before they trigger rules ✅ Executive visibility - Metrics showing program effectiveness Key Takeaways GenAI threats need GenAI-specific analytics - Generic rules miss context like prompt injection, content safety violations, and session-based attacks Correlation is critical - The most sophisticated attacks span multiple signals. Correlating app logs with identity and platform alerts catches what individual rules miss. User context from Part 2 pays off - end_user_id, source_ip, and session_id enable investigation and response at scale Prompt hashing enables pattern detection - Detect repeated attacks without storing sensitive prompt content Workbooks serve different audiences - Executives want metrics; analysts want investigation tools; hunters want anomaly detection Start with high-fidelity rules - Content Safety violations and rate limit abuse have very low false positive rates. Add behavioral rules after establishing baselines. What's Next: Closing the Loop You've now built detection and visibility. In Part 4, we'll close the security operations loop with: Part 4: Platform Integration and Automated Response Building SOAR playbooks for automated incident response Implementing automated key rotation with Azure Key Vault Blocking identities in Entra Creating feedback loops from incidents to code improvements The journey from blind spot to full security operations capability is almost complete. Previous: Part 1: Securing GenAI Workloads in Azure: A Complete Guide to Monitoring and Threat Protection - AIO11Y | Microsoft Community Hub Part 2: Part 2: Building Security Observability Into Your Code - Defensive Programming for Azure OpenAI | Microsoft Community Hub Next: Part 4: Platform Integration and Automated Response (Coming soon)Demystifying AI Security Posture Management
Introduction In the ever-evolving paradigm shift that is Generative AI, adoption is accelerating at an unprecedented level. Organizations find it increasingly challenging to keep up with the multiple security branches of defence and attack that are complementing the adoption. With agentic and autonomous agents being the new security frontier we will be concentrating on for the next 10 years, the need to understand, secure and govern what Generative AI applications are running within an organisation becomes critical. Organizations that have a strong “security first” principle have been able to integrate AI by following appropriate methodologies such as Microsoft’s Prepare, Discover, Protect and Govern approach, and are now accelerating the adoption with strong posture management. Link: Build a strong security posture for AI | Microsoft Learn However, due to the nature of this rapid adoption, many organizations have found themselves in a “chicken and egg” situation whereby they are racing to allow employees and developers to adopt and embrace both Low Code and Pro Code solutions such as Microsoft Copilot Studio and Microsoft Foundry, but due to governance and control policies not being implemented in time, now find themselves in a Shadow AI situation, and require the ability to retroactively assess already deployed solutions. Why AI Security Posture Management? Generative AI Workloads, like any other, can only be secured and governed if the organization is aware of their existence and usage. With the advent of Generative AI we now not only have Shadow IT but also Shadow AI, so the need to be able to discover, assess, understand, and govern the Generative AI tooling that is being used in an organisation is now more important than ever. Consider the risks mentioned in the recent Microsoft Digital Defence Report and how they align to AI Usage, AI Applications and AI Platform Security. As Generative AI becomes more ingrained in the day-to-day operations of organizations, so does the potential for increased attack vectors, misuse and the need for appropriate security oversight and mitigation. Link: Microsoft Digital Defense Report 2025 – Safeguarding Trust in the AI Era A recent study by KMPG discussing Shadow AI listed the following statistics: 44% of employees have used AI in ways that contravene policies and guidelines, indicating a significant prevalence of shadow AI in organizations. 57% of employees have made mistakes due to AI, and 58 percent have relied on AI output without evaluating its accuracy. 41% of employees report that their organization has a policy guiding the use of GenAI, highlighting a huge gap in guardrails. A very informed comment by Sawmi Chandrasekaran, Principal, US and Global AI and Data Labs leader at KPMG states: “Shadow AI isn’t a fringe issue—it’s a signal that employees are moving faster than the systems designed to support them. Without trusted oversight and a coordinated architectural strategy, even a single shortcut can expose the organization to serious risk. But with the right guardrails in place, shadow AI can become a powerful force for innovation, agility, and long-term competitive advantage. The time to act is now—with clarity, trust, and bold forward-looking leadership.” Link: Shadow AI is already here: Take control, reduce risk, and unleash innovation It’s abundantly clear that organizations require integrated solutions to deal with the escalating risks and potential flashpoints. The “Best of Breed” approach is no longer sustainable considering the integration challenges both in cross-platform support and data ingestion charges that can arise, this is where the requirements for a modern CNAPP start to come to the forefront. The Next Era of Cloud Security report created by the IDC highlights Cloud Native Application Protection Platforms (CNAPPs) as a key investment area for organizations: “The IDC CNAPP Survey affirmed that 71% of respondents believe that over the next two years, it would be beneficial for their organization to invest in an integrated SecOps platform that includes technologies such as XDR/EDR, SIEM, CNAPP/cloud security, GenAI, and threat intelligence.” Link: The Next Era of Cloud Security: Cloud-Native Application Protection Platform and Beyond AI Security Posture Management vs Data Security Posture Management Data Security Posture Management (DSPM) is often discussed, having evolved prior to the conceptualization of Generative AI. However, DSPM is its own solution that is covered in the Blog Post Data Security Posture Management for AI. AI Security Posture Management (AI-SPM) focuses solely on the ability to monitor, assess and improve the security of AI systems, models, data and infrastructure in the environment. Microsoft’s Approach – Defender for Cloud Defender for Cloud is Microsoft’s modern Cloud Native Application Protection Platform (CNAPP), encompassing multiple cloud security solution services across both Proactive Security and Runtime Protection. However, for the purposes of this article, we will just be delving into AI Security Posture Management (AI-SPM) which is a sub feature of Cloud Security Posture Management (CSPM), both of which sit under Proactive Security solutions. Link: Microsoft Defender for Cloud Overview - Microsoft Defender for Cloud | Microsoft Learn Understanding AI Security Posture Management The following is going to attempt to “cut to the chase” on each of the four areas and cover an overview of the solution and the requirements. For detailed information on feature enablement and usage, each section includes a link to the full documentation on Microsoft Learn for further reading AI Security Posture Management AI Security Posture Management is a key component of the all-up Cloud Security Posture Management (CSPM) solution, and focuses on 4 key areas: o Generative AI Workload Discover o Vulnerability Assessment o Attack Path Analysis o Security Recommendations Generative AI Workload Discovery Overview Arguably, the principal role of AI Security Posture Management is to discover and identify Generative AI Workloads in the organization. Understanding what AI resources exist in the environment being the key to understanding their defence. Microsoft refers to this as the AI Bill-Of-Materials or AI-BOM. Bill-Of-Materials is a manufacturing term used to describe the components that go together to create a product (think door, handle, latch, hinges and screws). In the AI World this becomes application components such as data and artifacts. AI-SPM can discover Generative AI Applications across multiple supported services including: Azure OpenAI Service Microsoft foundry Azure Machine Learning Amazon Bedrock Google Vertex AI (Preview) Why no Microsoft Copilot Studio Integration? Microsoft Copilot Studio is not an external or custom AI agent service and is deeply integrated into Microsoft 365. Security posture for Microsoft Copilot Studio is handed over to Microsoft Defender for Cloud Apps and Microsoft Purview, with applications being marked as Sanctioned or Unsanctioned via the Defender for Cloud portal. For more information on Microsoft Defender for Cloud Apps see the link below. Link: App governance in Microsoft Defender for Cloud Apps and Microsoft Defender XDR - Microsoft Defender for Cloud Apps | Microsoft Learn Requirements An active Azure Subscription with Microsoft Defender for Cloud. Cloud Security Posture Management (CSPM) Enabled Have at least one environment with an AI supported workload. Link: Discover generative AI workloads - Microsoft Defender for Cloud | Microsoft Learn Vulnerability Assessment Once you have a clear overview of which AI resources exist in your environment, Vulnerability Assessment in AI-SPM allows you to cover two main areas of consideration. The first allows for the organization to discover vulnerabilities within containers that are running generative AI images with known vulnerabilities. The second allows vulnerability discovery within Generative AI Library Dependences such as TensorFlow, PyTorch, and LangChain. Both options will align any vulnerabilities detected to known Common Vulnerabilities and Exposures (CVE) IDs via Microsoft Threat Detection. Requirements An active Azure Subscription with Microsoft Defender for Cloud. Cloud Security Posture Management (CSPM) Enabled Have at least one Azure OpenAI resource, with at least one model deployment connected to it via Azure AI Foundry portal. Link: Explore risks to pre-deployment generative AI artifacts - Microsoft Defender for Cloud | Microsoft Learn Attack Path Analysis AI-SPM hunts for potential attack paths in a multi-cloud environment, by concentrating on real, externally driven and exploitable threats rather than generic scenarios. Using a proprietary algorithm, the attack path is mapped from outside the organization, through to critical assets. The attack path analysis is used to highlight immediately, exploitable threats to the business, which attackers would be able to exploit and breach the environment. Recommendations are given to be able to resolve the detected security issues. Discovered Attack Paths are organized by risk levels, which are determined using a context-aware risk-prioritization engine that considers the risk factors of each resource. Requirements An active Azure Subscription with Microsoft Defender for Cloud. Cloud Security Posture Management (CSPM) with Agentless Scanning Enabled. Required roles and permissions: Security Reader, Security Admin, Reader, Contributor, or Owner. To view attack paths that are related to containers: You must enable agentless container posture extension in Defender CSPM or You can enable Defender for Containers, and install the relevant agents in order to view attack paths that are related to containers. This also gives you the ability to query containers data plane workloads in security explorer. Required roles and permissions: Security Reader, Security Admin, Reader, Contributor, or Owner. Link: Identify and remediate attack paths - Microsoft Defender for Cloud | Microsoft Learn Security Recommendations Microsoft Defender for Cloud evaluates all resources discovered, including AI resources, and all workloads based on both built-in and custom security standards, which are implemented across Azure subscriptions, Amazon Web Services (AWS) accounts, and Google Cloud Platform (GCP) projects. Following these assessments, security recommendations offer actionable guidance to address issues and enhance the overall security posture. Defender for Cloud utilizes an advanced dynamic engine to systematically assess risks within your environment by considering exploitation potential and possible business impacts. This engine prioritizes security recommendations according to the risk factors associated with each resource, determined by the context of the environment, including resource configuration, network connections, and existing security measures. Requirements No specific requirements are required for Security Recommendations if you have Defender for Cloud enabled in the tenant as the feature is included by default. However, you will not be able to see Risk Prioritization unless you have the Defender for CSPM plan enabled. Link: Review Security Recommendations - Microsoft Defender for Cloud | Microsoft Learn CSPM Pricing CSPM has two billing models, Foundational CSPM (Free) Defender CSPM, which has its own additional billing model. AI-SPM is only included as part of the Defender CSPM plan. Foundational CSPM Defender CSPM Cloud Availability AI Security Posture Management - Azure, AWS, GCP (Preview) Price Free $5.11/Billable resource/month Information regarding licensing in this article is provided for guidance purposes only and doesn’t provide any contractual commitment. This list and license requirements are subject to change without any prior notice. Full details can be found on the official Microsoft documentation found here, Link: Pricing - Microsoft Defender for Cloud | Microsoft Azure. Final Thoughts AI Security Posture Management can no longer be considered an optional component to security, but rather a cornerstone to any organization’s operations. The integration of Microsoft Defender for Cloud across all areas of an organization shows the true potential of a modern a CNAPP, where AI is no longer a business objective, but rather a functional business component.Defender for AI services: Threat Protection and AI red team workshop
Authors: Thor Draper & Nathan Swift Generative AI is reshaping how enterprises operate, introducing new efficiencies—and new risks. Imagine launching a helpful chatbot, only to learn a cleverly crafted prompt can bypass safety controls and exfiltrate sensitive data. This is today’s reality: every system prompt, plugin/tool, dataset, fine‑tune, or orchestration step can change the attack surface. This is due to the non deterministic nature in how LLM models craft responses in output. The slightest change in the input of a prompt in verbiage or tone can change the outcome of a output in subtle but non predictable ways especially when your data is involved. This post shows how to operationalize AI red teaming with Microsoft Defender for AI services so security teams gain evidence‑backed visibility into adversarial behavior and turn that visibility into daily defense. By aligning with Microsoft’s Responsible AI principles of transparency, accountability, and continuous improvement, we demonstrate a pragmatic, repeatable loop that makes AI safer week after week. Crucially, security needs to have a seat at the table across the AI app lifecycle from model selection and pilot to production and ongoing updates. Who Should Read This (and What You’ll See) SOC analysts & incident responders - See how AI signals materialize as high‑fidelity alerts (prompt evidence, URL intel, identity context) in Defender for Cloud and Defender XDR for fast triage and correlation. AI/ML engineers - Validate model safety with controlled simulations (PyRIT‑informed strategies) and understand which filters/guardrails move the needle. Security architects - Integrate Microsoft Defender for AI services into your cloud security program; codify improvements as policy, IaC, and identity hygiene. Red teamers/researchers - Run structured, repeatable adversarial tests that produce measurable outcomes the org can act on. Why now? Data leakage, prompt injection, jailbreaks, and endpoint abuse are among the fastest‑growing threats to AI systems. With AI red teaming and Microsoft Defender for AI services, you catch intent before impact and translate insight into durable controls. What’s Different About the AI Attack Surface New risks sit alongside the traditional ones: Prompts & responses — Susceptible to prompt injection and jailbreak attempts (rule change, role‑play, encoding/obfuscation). User & application context — Missing context slows investigations and blurs accountability. Model endpoints & identities — Static keys and weak identity practices increase credential theft and scripted probing risk. Attached data (RAG/fine‑tuning) — Indirect prompt injection via documents or data sources. Orchestration layers/agents — Tool invocation abuse, unintended actions, or “over‑permissive” chains. Content & safety filters — Configuration drift or silent loosening erodes protection. A key theme across these risks is context propagation. The way user identity, application parameters, and environmental signals travel with each prompt and response. When context is preserved and surfaced in security alerts, SOC teams can quickly correlate incidents, trace attack paths, and remediate threats with precision. Effective context propagation transforms raw signals into actionable intelligence, making investigations faster and more accurate. Microsoft Defender for AI services adds a real‑time protection layer across this surface by combining Prompt Shields, activity monitoring, and Microsoft threat intelligence to produce high‑fidelity alerts you can operationalize. The Improvement Loop (Responsible AI in Practice) Responsible AI comes to life when teams Observe → Correlate → Remediate → Retest → Codify: Observe controlled jailbreak/phishing/automation patterns and collect prompt evidence. Correlate with identity, network, and prior incidents in Defender XDR. Remediate with the smallest effective control (filters, identities, rate limits, data scoping). Retest the same scenario to verify risk reduction. Codify as baseline (policy, IaC template, guardrail profile, rotation notes). Repeat this rhythm on a schedule and you’ll build durable posture faster than a one‑time “big‑bang” control set. Prerequisites: To take advantage of this workshop you’ll need: Sandbox subscription (ideally inside a Sandbox Mgmt Group with lighter policies), you may also leverage a Free trial of Azure Subscription as well. Microsoft Defender for AI services plan enabled (see Participant Guide ) Contributor access (you can deploy + view alerts) Region capacity confirmed (Azure AI Foundry in East US 2) Workshop flow and testing: Prep: Enable the Microsoft Defender for AI services plan with prompt evidence, deploy the Azure Template (one hub + single endpoint), and open the AIRT-Eval.ipynb notebook; you now have a controlled space to generate signals(see Participant Guide). Controlled Signals: Trigger against a jailbreak attempt, a phishing URL simulation, and a suspicious user agent simulation to produce three distinct alert types. Triage & Correlate: For each alert, review anatomy (evidence, severity, IDs) and capture prompt/URL evidence. Harden & Retest: Apply improvements or security controls, then validate fixes. After you harden controls and retest, the next step is validating that your defenses trigger the right alerts on demand. There is a list of Microsoft Defender for AI services alerts here. To evaluate alerts, open DfAI‑Eval.ipynb - a streamlined notebook that safely simulates adversarial activity (current alerts: jailbreak, phishing URL, suspicious user agent) to exercise Microsoft Defender for AI services detections. Think of it as the EICAR test for AI workloads: consistent, repeatable, and safe. Next, we will review and break down each of the alerts you’ll generate in the workshop and how to read them effectively. Anatomy of Jailbreak from AI Red team Agent: A jailbreak is a user prompt designed to sidestep system or safety instructions—rule‑change (“ignore previous rules”), fake embedded conversation, role‑play as an unrestricted persona, or encoding tricks. Microsoft Defender for AI services (via Prompt Shields + threat intelligence) flags it before unsafe output (“left‑of‑boom”) and publishes a correlated high‑fidelity alert into Defender XDR for cross‑signal investigation. Anatomy of a Phishing involved in an attack: Phishing prompt URL alerts fire when a prompt or draft response embeds domains linked to impersonation, homoglyph tricks, newly registered infrastructure, encoded redirects, or reputation‑flagged hosting. Microsoft Defender for AI services enriches the URL (normalization, age, reputation, brand similarity) and—if prompt evidence is enabled—includes the exact snippet, then streams the alert into Defender XDR where end‑user/application context fields (e.g. `EndUserId`, `SourceIP`) let analysts correlate repeated lure attempts and pivot to related credential or jailbreak activity. Anatomy of a User Agent involved in an attack: Suspicious user agent alerts highlight enumeration or automation patterns (generic library signatures, headless runners, scanner strings, cadence anomalies) tied to AI endpoint usage and identity context. Microsoft Defender for AI services scores the anomaly and forwards it to Defender XDR enriched with optional `UserSecurityContext` (IP, user ID, application name) so analysts can correlate rapid probing with concurrent jailbreak or phishing alerts and enforce mitigations like managed identity, rate limits, or user agent filtering. Conclusion The goal of this Red teaming and AI Threat workshop amongst the different attendees is to catch intent before impact, prompt manipulation before unsafe output, phishing infrastructure before credential loss, and scripted probing before exfiltration. Microsoft Defender for AI services feeding Defender XDR enables a compact improvement loop that converts red team findings into operational guardrails. Within weeks, this cadence transforms AI from experimental liability into a governed, monitored asset aligned with your cloud security program. Incrementally closing gaps within context propagation, identity hygiene, Prompt Shields & filter tuning—builds durable posture. Small, focused cycles win ship one improvement, measure its impact, promote to baseline, and repeat.
