12.1 Cloud SOC Foundations and Shared Responsibility

The Cloud Shared Responsibility Model: Security Monitoring and Telemetry Boundaries

Transitioning security operations from on-premises data centers to public cloud environments fundamentally alters the Security Operations Center (SOC) operational charter. In a traditional enterprise data center, the internal SOC maintains uninhibited, full-stack visibility—from physical facility surveillance, hypervisor access, and raw network packet inspection via physical Test Access Points (TAPs) or Switched Port Analyzer (SPAN) ports, up to the application and data layers. In contrast, cloud environments operate under the Cloud Shared Responsibility Model, which delineates security obligations between the Cloud Service Provider (CSP) (such as Amazon Web Services, Microsoft Azure, or Google Cloud Platform) and the Customer Organization.

A common failure mode in Tier 1 and Tier 2 cloud incident triage is misunderstanding where the CSP's defensive boundary terminates and where the customer's analytical mandate begins. The division of responsibility changes dramatically across the three primary cloud service models:

• Infrastructure as a Service (IaaS): The CSP assumes responsibility for the security of the cloud, encompassing physical data centers, core hardware infrastructure, host virtualization/hypervisor layers (e.g., AWS Nitro System, Azure Hyper-V), and physical network fabric. The customer SOC retains full responsibility for security in the cloud. This includes deploying and maintaining host-based endpoint detection and response (EDR) agents, operating system security patch management, guest firewall rules, virtual network routing, identity and access management (IAM), data encryption at rest and in transit, and ingesting/analyzing guest OS audit logs.
• Platform as a Service (PaaS): The CSP manages the physical infrastructure, hypervisor, operating system lifecycle, middleware runtimes, and platform database engines (e.g., Azure SQL Database, AWS RDS, GCP BigQuery). Customers normally cannot access the provider’s underlying host kernel or hypervisor logs for a managed PaaS service. Their monitoring therefore emphasizes provider-exposed configuration, identity, network, platform, application, database, and API telemetry, with exact visibility defined by the service and contract.
• Software as a Service (SaaS): The CSP manages virtually the entire technological stack, including infrastructure, operating systems, platform runtimes, and application code (e.g., Microsoft 365, Salesforce, Google Workspace). The customer normally cannot modify or directly monitor the provider’s server infrastructure. Customer responsibilities commonly include identity, authentication, tenant configuration, data governance, integrations, endpoints, access control, and use of vendor-exposed audit and security telemetry; the contract and product define the boundary.

Shared Responsibility Security Monitoring Matrix

---

Architectural Shifts: On-Premises SOC vs. Cloud-Native SOC

Modern cloud-native architectures introduce fundamental paradigm shifts that render conventional on-premises SOC methodologies ineffective. Security analysts must adapt their mental models, detection engineering strategies, and incident response playbooks to accommodate three foundational characteristics of cloud computing:

1. Workload Ephemerality and Dynamic Scaling

In an on-premises network, servers possess static IP addresses, persistent hostnames, and lifespans measured in years. SOC analysts historically relied on static IP-to-hostname mappings in CMDB (Configuration Management Database) systems to triage alerts. In the cloud, workloads are ephemeral:

• Auto-Scaling Groups (ASGs) automatically provision and terminate virtual machine instances based on CPU utilization or queue depth. An EC2 or Azure VM instance may exist for only four hours before being decommissioned.
• Containerized Environments (Docker, Kubernetes/EKS/AKS/GKE) run microservices in lightweight containers with lifespans measured in minutes or seconds. Pod IP addresses are dynamically reassigned from internal overlay network CIDR blocks.
• Serverless Computing (AWS Lambda, Azure Functions, GCP Cloud Functions) executes event-driven code in provider-managed, reusable execution environments. Instances may be created, reused across invocations, scaled, frozen, recycled, or terminated according to the provider and workload; analysts cannot infer a universal lifetime or one-request-per-instance model.

Operational Impact: Static IP addresses alone are insufficient for cloud triage. If an alert fires on source IP 10.0.4.12 two hours after the event, that IP address may have been reassigned to three different containers. Cloud SOC analysts should correlate addresses with provider resource identifiers, account or subscription context, instance or container IDs, workload metadata, deployment revisions, and precise timestamps. None of these fields should be assumed immutable without checking that platform’s lifecycle and log semantics.

2. Identity as the Primary Security Perimeter

In traditional environments, the corporate firewall and perimeter network (DMZ) served as the primary defensive barrier. In the cloud, traditional network boundaries dissolve. Corporate assets are accessible from any internet-connected location if authenticated, making Identity and Access Management (IAM) the new operational perimeter.

• Non-Human Identities: Cloud environments host far more service principals, managed identities, API tokens, and machine roles than human users. Microservices communicate using machine-to-machine tokens (e.g., AWS STS AssumeRole, OAuth 2.0 client credentials).
• Federated Access: Organizations utilize Security Assertion Markup Language (SAML 2.0) and OpenID Connect (OIDC) to federate on-premises identity providers (e.g., Okta, Ping, on-premises Active Directory) with cloud directory services like Microsoft Entra ID.
• Token-Based Ephemeral Credentials: Rather than static passwords, cloud systems rely on short-lived cryptographic session tokens generated by Security Token Services (STS). Triage focuses on token generation, token reuse across disparate geographic regions, and privilege escalation via role assumption.

3. API-Driven Control Plane

In an on-premises data center, provisioning a server requires physical racking, cabling, and hypervisor console configuration. In cloud environments, many control-plane actions are authenticated API operations, whether invoked through a console, CLI, SDK, infrastructure-as-code tool, or service integration. Whether an engineer spins up 500 virtual machines, alters a routing table, opens a firewall port, or deletes a database snapshot, the operation is mediated by the cloud control plane API (ec2:RunInstances, azurerm_network_security_group, gcloud compute instances delete).

Operational Impact: Provider audit services can give the SOC extensive records of supported control-plane actions, but completeness, identity attribution, retention, integrity, regional coverage, data-event configuration, and service-specific exclusions must be verified. However, it also introduces a massive attack surface: an adversary who obtains a single set of administrative API credentials can compromise an entire enterprise infrastructure in seconds without ever touching an operating system shell.

Cloud vs. On-Premises SOC Operational Comparison

---

Modern Cloud Threat Landscape & Attack Vectors

Threat actors targeting cloud environments exploit the architectural characteristics of public cloud platforms. The CSA guidelines highlight five high-frequency cloud attack vectors that SOC analysts encounter:

[Cloud Threat Progression Pathway]
Exposed Credentials / SSRF ---> Cloud Control Plane API Access ---> Privilege Escalation (IAM)
                                                                             │
       ┌─────────────────────────────────────────────────────────────────────┴───────────────┐
       ▼                                                                                     ▼
Data Exfiltration (S3 / Blob)                                                  Resource Hijacking (Cryptomining)
- Unencrypted Object Storage                                                    - High-Compute GPU Instances (p3/g4)
- Excessive 's3:GetObject' calls                                                - Stratum Mining Protocol over 3333/4444
- Publicly Accessible Bucket ACLs                                               - Disabling CloudWatch / CloudTrail Logs

1. Misconfigured Object Storage Buckets

Public cloud storage services—such as Amazon S3, Azure Blob Storage, and Google Cloud Storage—remain the leading source of catastrophic cloud data breaches. Misconfigurations occur when administrators apply overly permissive Access Control Lists (ACLs) or bucket policies, granting read or write permissions to AllUsers or AuthenticatedUsers (which in AWS historically included any authenticated AWS account worldwide). SOC analysts monitor for:

• API calls altering bucket policies (e.g., s3:PutBucketPolicy, s3:PutBucketAcl, Set-AzStorageBlobContent).
• Massive spikes in data egress traffic originating from storage buckets.
• Anonymous access events logged in S3 server access logs or Azure Storage analytics logs.

2. Over-Privileged IAM Policies and Privilege Escalation Paths

Cloud IAM configurations frequently suffer from privilege creep, where users, applications, or service accounts are granted administrative wildcards (Action: "*", Resource: "*"). Threat actors leverage over-privileged service roles to execute privilege escalation. Classic escalation paths include:

• iam:CreateAccessKey: Generating a programmatic secret key for an existing highly privileged service account.
• iam:PassRole: Passing an administrative IAM role to a newly created EC2 instance or Lambda function, then executing code within that resource to harvest the role's credentials.
• iam:AttachUserPolicy or iam:PutUserPolicy: Attaching an administrative policy (e.g., AdministratorAccess) directly to an attacker-controlled identity.

3. Exposed Cloud Credentials and Metadata Service Abuse (SSRF)

Programmatic access keys (e.g., AWS Access Key ID and Secret Access Key) are frequently hardcoded into application source code and accidentally published to public GitHub repositories or embedded in public Docker Hub images. Automated botnets scrape code repositories within seconds of publication to harvest these credentials.

Alternatively, attackers exploit Server-Side Request Forgery (SSRF) vulnerabilities in web applications hosted on cloud instances to query the internal Instance Metadata Service (IMDS) running at the non-routable link-local IP address http://169.254.169.254/:

• IMDSv1 Vulnerability: IMDSv1 responds to simple, unauthenticated HTTP GET requests. An attacker exploiting an SSRF flaw can force the web application to execute GET http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name> and exfiltrate temporary IAM session tokens (AccessKeyId, SecretAccessKey, Token).
• IMDSv2 Defense: Enforces session-oriented requests. Clients must first issue an HTTP PUT request with an X-aws-ec2-metadata-token-ttl-seconds header to obtain an ephemeral session token, which must be passed in subsequent GET requests via the X-aws-ec2-metadata-token header. The token-request method, hop limit, and session token add defense in depth against many common SSRF and proxy paths. IMDSv2 does not repair the application vulnerability, so teams must still remediate SSRF, restrict instance-role permissions, and monitor metadata and credential use.

4. CI/CD Pipeline and Software Supply Chain Compromises

Cloud environments are continuously deployed via Continuous Integration and Continuous Deployment (CI/CD) pipelines (e.g., GitHub Actions, GitLab CI, Jenkins). Attackers target insecure pipeline configurations, compromised runner environments, or poisoned third-party dependencies (such as malicious npm or PyPI packages). By inserting malicious code into deployment scripts, adversaries inject backdoors into production container images before they are pushed to registries (Amazon ECR, Azure Container Registry) and deployed across Kubernetes clusters.

5. Cloud Resource Hijacking and Cryptomining

Upon obtaining compute provisioning privileges, adversaries frequently launch unauthorized GPU-optimized compute instances (e.g., AWS p3, g4dn, or Azure NC-series virtual machines) to mine cryptocurrencies (Monero, Bitcoin). Attackers maximize profits before detection by:

• Deploying workloads across obscure, unmonitored cloud regions.
• Attempting to disable logging services (e.g., executing cloudtrail:StopLogging or DeleteTrail).
• Establishing outbound network connections using the Stratum mining protocol over non-standard TCP ports (e.g., 3333, 4444, 8333).

---

Cloud Security Tooling: CSPM vs. CWPP vs. CIEM in SOC Workflows

To manage risk and detect threats across complex multi-cloud ecosystems, enterprise SOCs deploy three complementary cloud security technologies:

1. Cloud Security Posture Management (CSPM)

CSPM solutions (e.g., Microsoft Defender for Cloud CSPM, Palo Alto Prisma Cloud, AWS Security Hub) provide agentless, continuous configuration auditing of cloud control planes. CSPMs connect directly to cloud provider APIs via read-only service principals to inspect resources against industry benchmarks (CIS Cloud Benchmarks, NIST CSF, PCI-DSS, HIPAA). Key SOC functions include:

• Identifying architectural misconfigurations (e.g., public S3 buckets, unencrypted EBS volumes, Security Groups allowing inbound 0.0.0.0/0 on port 22 or 3389).
• Detecting configuration drift between Terraform/CloudFormation templates and live infrastructure.
• Evaluating compliance posture and generating aggregated posture risk scores.

2. Cloud Workload Protection Platforms (CWPP)

While CSPM audits the control plane from the outside, CWPP solutions (e.g., Microsoft Defender for Servers, Trend Micro Cloud One, CrowdStrike Falcon Cloud Security) protect the runtime execution environment of compute workloads (VMs, containers, Kubernetes nodes, serverless runtimes). Utilizing lightweight OS agents or extended Berkeley Packet Filter (eBPF) kernel instrumentation, CWPPs provide:

• Runtime behavioral analysis and process lineage monitoring (detecting unauthorized binary executions, process injection, or reverse shells spawning from containerized web servers).
• Host-based file integrity monitoring (FIM) and vulnerability scanning.
• Container breakout detection and Kubernetes admission control enforcement.

3. Cloud Infrastructure Entitlement Management (CIEM)

CIEM technologies specialize in untangling complex cloud identity permissions. By analyzing effective permissions across users, groups, roles, and resource-based policies, CIEM enables SOCs to:

• Identify over-privileged human and machine identities operating with excessive blast radiuses.
• Calculate the delta between granted permissions and actually utilized permissions over 90 days, recommending least-privilege policy adjustments.
• Map out hidden privilege escalation pathways and toxic permission combinations (e.g., an identity possessing both iam:PassRole and ec2:RunInstances).