Multi-Cloud Security: Security Hub, SCC, and Defender Setup

Note: when infrastructure is distributed across AWS, GCP, and Azure, fragmented security logs turn three clouds into three black boxes. On one project with 200 AWS accounts, 50 GCP projects, and 100 Azure subscriptions, each team manually reviewed thousands of findings per week, and the mean time to respond (MTTR) was 8 hours. Setting up centralized security services—AWS Security Hub, GCP Security Command Center (SCC), and Azure Defender for Cloud—reduced MTTR to 30 minutes and cut security costs by 25%. AWS documentation confirms that Security Hub automatically includes three compliance standards: CIS, PCI-DSS, and AWS Foundational Benchmarks. But out of the box, these services don't work effectively—manual configuration of integrations, compliance frameworks, and automated responses is required. Below are specific configurations and a pipeline from 50+ projects we have already implemented.

What problems do Security Hub, SCC, and Defender solve?

Each service addresses three key tasks:

• Aggregation of findings from built-in tools: GuardDuty, Inspector, Config on AWS; Security Health Analytics, Web Scanner on GCP; Defender for Servers, Containers, SQL on Azure.
• Compliance monitoring against CIS, PCI-DSS, SOC 2, and vendor best practices.
• Automated response to critical incidents—from notifications to automatic remediation.

A typical mistake during initial setup is not enabling all sources. Security Hub won't see GuardDuty findings until the integration is explicitly enabled. On GCP, the Standard tier does not provide real-time container control. Azure Defender without a full set of plans leaves bare-metal servers unprotected.

How we configure each service: detailed example on AWS

For AWS, we use the CLI with --enable-default-standards flags and explicit enabling of all sources:

# Enable Security Hub
aws securityhub enable-security-hub \
  --enable-default-standards \
  --region us-east-1

# Enable GuardDuty as a finding source
aws guardduty create-detector \
  --enable \
  --finding-publishing-frequency FIFTEEN_MINUTES

# Enable AWS Inspector v2
aws inspector2 enable \
  --resource-types EC2 ECR LAMBDA

After enabling, Security Hub maps findings to the ASFF (Amazon Security Finding Format). For automated response to Critical and High findings, we subscribe to events via EventBridge:

{ "source": ["aws.securityhub"], "detail-type": ["Security Hub Findings - Imported"], "detail": { "findings": { "Severity": {"Label": ["CRITICAL", "HIGH"]}, "Workflow": {"Status": ["NEW"]} } } } 

A Lambda function triggered by this rule processes the finding—for example, closes a public S3 bucket. For GCP, we use gcloud to query findings with a severity filter, and for automatic sending of Critical findings to PubSub, we use a Terraform configuration:

resource "google_scc_notification_config" "critical_findings" {
  config_id = "critical-findings-pubsub"
  organization = var.org_id
  description = "Critical and High findings to PubSub"
  pubsub_topic = google_pubsub_topic.security_findings.id
  streaming_config {
    filter = "severity = \"CRITICAL\" OR severity = \"HIGH\""
  }
}

On Azure—enabling protection plans and configuring continuous export:

az security pricing create --name Containers --tier Standard
az security pricing create --name VirtualMachines --tier Standard --subplan P2
az security pricing create --name AppServices --tier Standard
# Continuous export configured via UI or ARM

Feature comparison of the services

Why configure all three services?

A single security window for three clouds reduces MTTR by an average of 40% compared to manually switching between consoles. Security Hub processes findings 3 times faster than manual log collection from 10 regions. Incident cost savings: for example, replacing manual response with automated saved a client about $1.8k–2.6k monthly. We have implemented a centralized pipeline for 50+ projects: AWS Security Hub → EventBridge → Kinesis Firehose, GCP SCC → PubSub → Dataflow, Azure Defender → Event Hub. All streams converge into Elastic, Splunk, or Microsoft Sentinel, providing a unified incident feed while preserving ticketing and runbooks.

Setup process and what's included

1. Audit current configuration — identify missing sources and insecure settings.
2. Enable services and compliance frameworks — CIS, PCI-DSS, plus custom policies.
3. Configure aggregation — select master account (Security Hub) or external SIEM.
4. Automatic notifications — Critical findings → Slack/PagerDuty, High → email.
5. Remediation actions — Lambda functions for common violations (open ports, public buckets).
6. E2E test — from simulated event to alert and automatic fix.

The work includes full incident response documentation and runbooks, team training on consoles and dashboards, and post-project support for one month.

Common mistakes we often fix

• Not enabling all finding sources — GuardDuty, Inspector, Macie on AWS.
• Using Standard tier SCC for Kubernetes clusters — without Premium, you won't see container attacks.
• Missing continuous export from Azure Defender — findings are lost if Continuous Export is not configured.
• Forgotten remediations — Critical incidents remain unhandled if no EventBridge rules exist.

We guarantee a centralized security overview across three clouds with minimal MTTR. For a consultation on your project, contact us. Request an initial audit to get a snapshot of current vulnerabilities and configuration recommendations.