AWS Security Hub Expands: AI Workload Protection and Azure Integration

A unified security posture across Microsoft Azure and Amazon Web Services (AWS) requires bridging distinct native security models. AWS Security Hub aggregates findings using the AWS Security Finding Format (ASFF), a normalized JSON schema. Azure offers its own security graph via Microsoft Defender for Cloud, which exposes alerts and recommendations through the Azure Resource Graph and REST API. Direct native integration between the two platforms does not exist; instead, enterprise engineers must build a custom ingestion pipeline.

The core concept involves extracting Azure security findings, transforming them into ASFF, and forwarding them to AWS Security Hub via the BatchImportFindings API. For example, an engineer can deploy an Azure Logic App scheduled to query Defender for Cloud’s vulnerability assessments and compliance checks (e.g., against NIST SP 800-53 controls). The Logic App serializes each result into an ASFF-compliant JSON object—mapping fields such as ProductArn (set to a custom product), Types, and Severity—then calls the AWS Security Hub API through an Azure API Management instance or a dedicated HTTP action with AWS Signature V4 authentication.

Key architectural considerations include:

• Normalizing Severity Levels: Azure uses a four-point scale (Low, Medium, High, Critical); ASFF uses numeric values (0–100). Map High (60–80) and Critical (90–100) appropriately to avoid alert fatigue.
• Handling Deduplication: Use a deterministic Id field—for example, a concatenation of Azure resource ID and finding title—so Security Hub does not create duplicate findings.
• Continuous Sync: Schedule the Logic App every 15–30 minutes or use Azure Monitor alerts as triggers to achieve near-real-time updates.
• Compliance Frameworks: AWS Security Hub supports automated compliance checks for standards such as SOC 2 (controls for security, availability, processing integrity), ISO 27001 (information security management), and NIST 800-53 (security and privacy controls). Ingested Azure findings can contribute to these consolidated checks, provided they map to the same control IDs (e.g., AC-2 for account management).

This approach enables a single pane of glass for security posture, though it demands rigorous mapping of Azure resource properties to ASFF and ongoing maintenance as both cloud providers update their APIs. No third-party connector is assumed; the method described uses only native services and standard API calls.

Operating in a multi-cloud environment introduces distinct security visibility gaps. AWS generates alerts through GuardDuty, Security Hub, and CloudTrail, while Azure produces findings via Defender for Cloud, Sentinel, and Activity Logs. Without consolidation, security teams must context-switch between consoles, correlate events manually, and maintain duplicate alert triage workflows. This fragmentation increases mean time to detect (MTTD) and invites missed threats that span cloud boundaries.

Centralizing these alerts into a single hub—typically a SIEM or SOAR platform that ingests data from both AWS and Azure—solves these inefficiencies. The hub ingests native findings from each provider’s security services and normalizes them into a common data model. This allows analysts to define cross-cloud correlation rules. For instance, a suspicious API call from a compromised AWS IAM key that later appears in an Azure sign-in log can be linked as a single incident, rather than treated as two unrelated alerts. Incident response (IR) workflows then trigger automatically in a single playbook, reducing manual steps and eliminating platform-specific tooling.

Practical integration steps include:

• Ingesting AWS Security Hub findings via EventBridge or a CloudWatch Logs subscription into the central SIEM.
• Forwarding Azure Defender for Cloud alerts and Sentinel logs to the same SIEM using the Azure Event Hub or Log Analytics workspace export.
• Enriching normalized alerts with asset inventory and identity data from both clouds to speed up context gathering.
• Implementing a single SOAR playbook that can execute containment actions in either cloud—e.g., revoking a compromised key in AWS while disabling a user in Azure Active Directory.

Compliance alignment is also simplified. A centralized view supports the continuous monitoring required by SOC 2 (criterion CC7.2) and the incident management requirements of ISO 27001 (control A.16). For NIST CSF, the RS function (Analysis) benefits from aggregated, correlated telemetry across both cloud providers. While OWASP does not prescribe infrastructure monitoring directly, its API Security Top 10 stresses the importance of logging and monitoring for API abuse—a threat that often spans multiple cloud environments.

Consolidation does not require replacing existing cloud-native tools. Instead, it layers a unified detection and response capability on top, preserving investment in AWS and Azure security services while eliminating operational friction. The outcome is faster, more reliable incident response with lower staff overhead and reduced risk of human error during cross-cloud events.

To maintain consistent security policies and compliance standards across hybrid cloud infrastructures, organizations must enforce a unified governance layer that abstracts the heterogeneity of on-premises, private cloud, and public cloud environments. Without centralized control, policy drift occurs: a misconfigured storage bucket in one public cloud might expose regulated data, while an identical resource on-premises remains compliant. Modern compliance frameworks explicitly require continuous monitoring and automated enforcement, not point-in-time audits.

Concepts before recommendations

Hybrid cloud compliance relies on three interlocking capabilities:

• Policy-as-code – Declarative rules (e.g., Rego, Sentinel) that are version-controlled, tested, and applied uniformly across all environments. This eliminates manual configuration and reduces human error.
• Centralized audit logging – Aggregating logs from all infrastructure components into a single, immutable data store. These logs must capture identity, resource changes, and data access events to satisfy forensic requirements.
• Automated compliance checks – Scheduled or event-driven scans that evaluate infrastructure state against defined policies, producing evidence for auditors without manual collection.

Practical example: an organization subject to SOC 2 Type II must demonstrate effective access controls and monitoring across all systems that process customer data. Using policy-as-code, they can enforce that any virtual machine launched in AWS, Azure, or on-premises vSphere must have encryption-at-rest enabled and must belong to a network segment with restricted inbound rules. A centralized compliance engine runs continuous scans, and any violation triggers an automated remediation workflow—such as shutting down the non-compliant VM or alerting the security team. This same logic applies to ISO 27001’s A.9 (access control) and A.12 (operations security) requirements.

Standards described accurately

• SOC 2 – Trust Services Criteria covering security, availability, processing integrity, confidentiality, and privacy. Requires evidence of controls over time, not just snapshots.
• ISO 27001 – Information Security Management System (ISMS) standard requiring risk-based selection of controls from Annex A. Hybrid cloud deployments must map each control to the responsible cloud provider and the organization’s own systems.
• NIST Cybersecurity Framework – Risk-based framework with five functions (Identify, Protect, Detect, Respond, Recover). In hybrid cloud, Detect relies on centralized logging and anomaly detection; Protect requires consistent identity and encryption policies.
• OWASP – Primarily focused on application security (Top 10 Web Application Security Risks). For compliance, organizations should integrate OWASP guidance into CI/CD pipelines, ensuring that code deployed to any cloud environment undergoes static and dynamic analysis.

By unifying policy enforcement and automated evidence collection, organizations reduce audit fatigue and prevent configuration drift. The key architectural decision is to treat policy as a separate, infrastructure-agnostic layer rather than embedding it into each cloud provider’s native tooling.

Integrating Azure account onboarding and AI workload monitoring into an existing AWS Security Hub deployment requires bridging two distinct cloud-native security ecosystems without duplicating effort. The goal is to unify visibility across Azure and AWS while applying consistent detection and compliance frameworks—such as the NIST Cybersecurity Framework, ISO 27001, or CIS Benchmarks—to protect AI services.

First, establish a central identity and governance baseline. In AWS Security Hub, enable cross-region aggregation and define custom insight rules that map to Azure security events. For Azure, use Azure Policy to enforce guardrails on AI resources (e.g., Azure OpenAI endpoints, Azure Machine Learning workspaces) and export diagnostic logs to a central Azure Log Analytics workspace. These logs must be forwarded to AWS Security Hub via a secure, low-latency pipeline.

A practical approach involves:

• Deploying an AWS Lambda function that consumes Azure Event Hubs messages containing AzureActivityLogs and AzureDiagnosticLogs. The Lambda transforms the Azure schema into the AWS Security Finding Format (ASFF) and sends findings to Security Hub using the BatchImportFindings API.
• Using an AWS Systems Manager Parameter Store to manage cross-account credentials and Azure service principal secrets.
• Configuring Security Hub custom actions to trigger automated remediations in Azure (e.g., via Azure DevOps or REST APIs) when critical AI workload anomalies are detected.

For AI workload monitoring specifically, apply the OWASP Top 10 for Large Language Model Applications to define threat models. Map findings from Azure AI content safety filters or model monitoring logs (e.g., data drift, inference latency) into Security Hub as custom findings with severity levels aligned to your existing SOC 2 or PCI DSS controls.

Recommended next steps in order:

• Enable Azure Security Center’s continuous export and stream to an Event Hubs namespace.
• Deploy a proof-of-concept pipeline for a single Azure subscription and one AI workload (e.g., an Azure OpenAI chat deployment).
• Validate that findings appear in AWS Security Hub under the correct product ARN and match severity thresholds.
• Extend the pipeline to support multiple Azure subscriptions using Terraform or Bicep templates that automatically onboard new subscriptions.

By treating the integration as a data fusion problem rather than a migration, security teams can retain existing playbooks and reporting in Security Hub while gaining visibility into Azure AI assets—without requiring a full SIEM replacement.