GIAC GDSA — Cloud Security Architecture

Service Model Definitions:

• IaaS (Infrastructure as a Service): Provider: physical hardware, hypervisor, networking, storage infrastructure. Customer: OS, middleware, runtime, applications, data, IAM configuration. Examples: AWS EC2, Azure VMs, GCP Compute Engine.
• PaaS (Platform as a Service): Provider adds: OS patching, runtime, middleware. Customer: application code, data, IAM, some network config. Examples: AWS Elastic Beanstalk, Azure App Service, GCP App Engine.
• SaaS (Software as a Service): Provider: everything except customer data and IAM configuration. Customer: data classification/protection, user access management, configuration of the SaaS application's security features. Examples: Microsoft 365, Salesforce, Google Workspace.

Customer Always Responsible For:

• Data classification and protection — regardless of service model
• Identity and access management — who can access your cloud resources
• Compliance obligations — GDPR, HIPAA, PCI DSS compliance is customer responsibility even in cloud
• Security configuration of cloud services — provider provides tools, customer must use them correctly

Common Misconceptions:

• "Cloud is secure by default" — false. Provider secures infrastructure; customer secures their configuration. Public S3 buckets, open security groups, disabled MFA are all customer failures.
• "Provider handles compliance" — false. Provider can be certified (SOC2, ISO27001), but customer's use of the platform must also comply.
• "Migration to cloud improves security automatically" — false. Lifting-and-shifting poor on-premises security practices to cloud doesn't improve security.

Provider Certification Review: Review cloud provider SOC2 Type II reports, ISO27001 certificates, and FedRAMP authorization (for US government) during due diligence. These confirm provider's security controls — not customer's configuration quality.

Hypervisor Types:

• Type 1 (Bare Metal): Runs directly on hardware — no host OS. VMware vSphere/ESXi, Microsoft Hyper-V Server, KVM. Better performance and security isolation. Production data centers use Type 1.
• Type 2 (Hosted): Runs on top of a host OS. VMware Workstation, VirtualBox. Host OS vulnerabilities can affect all VMs. Development/test use only.

Hypervisor Hardening:

• VMware vSphere Security Hardening Guide — disable unnecessary services, enable lockdown mode, use dedicated vCenter NIC
• Hyper-V Server Core — minimal attack surface (no GUI, minimal components)
• Management network isolation: dedicated physical NIC and VLAN for hypervisor management (vCenter, IPMI/iDRAC). Never share with VM traffic.
• Disable unused features: USB passthrough, clipboard sharing between host/VM, 3D graphics acceleration, serial/parallel port passthrough
• VM sprawl: unmanaged VMs = forgotten systems with unpatched OS. Implement VM lifecycle management — regular inventory and decommission of unused VMs.
• Snapshot management: snapshots reference old disk state. Stale snapshots may contain vulnerable OS versions. Limit snapshot count; delete old ones.

Hyperjacking Attack: Attacker installs a thin malicious hypervisor below the legitimate OS, making the OS a VM running on the attacker's hypervisor. Extremely sophisticated, rare in practice. Detection: TPM attestation — hardware root of trust verifies boot chain integrity. Secure Boot, UEFI password for BIOS protection.

VM Escape: Exploit in hypervisor software allows VM to break out of isolation and access host OS or other VMs. Historically rare (VMware VM escape CVEs). Mitigations: keep hypervisor patched, disable guest VM communication features (clipboard), restrict VM privileges.

Security Groups (AWS) / NSGs (Azure) — Stateful, Per-Instance:

• Attached to elastic network interfaces (ENIs/NICs), not subnets
• Stateful: return traffic is automatically allowed — only need to define inbound rules for inbound-initiated connections
• Default deny — no inbound traffic unless explicitly allowed
• Reference other Security Groups as source — e.g., "allow inbound 3306 from sg-app-servers" (not IP ranges)
• Multiple SGs can be applied to one instance — rules are unioned (all applies)

NACLs — Stateless, Per-Subnet:

• Applied at the subnet level — affects all resources in the subnet
• Stateless: must define both inbound AND outbound rules. Inbound allow port 80 + outbound allow ephemeral ports 1024-65535 for responses.
• Numbered rules — evaluated in order (lowest number first). First match wins.
• Explicit deny rules available (unlike Security Groups which are allow-only)
• Useful for subnet-level blocking (blacklisting bad IPs) as a second layer

VPC Flow Logs: Capture metadata for all network traffic (src/dst IP, ports, bytes, accept/reject). Equivalent to NetFlow. Stored in S3 or CloudWatch Logs. Essential for incident forensics, traffic pattern analysis, security group validation. Enable on all production VPCs.

Egress Filtering: Prevent C2 callbacks and data exfiltration. NAT Gateway with outbound Security Group restrictions. Web proxy for HTTP/HTTPS inspection. AWS Network Firewall for stateful Suricata rules on egress.

VPC Endpoints (PrivateLink): Access AWS services (S3, DynamoDB, SQS) from private subnets without internet routing — traffic stays within AWS network. Gateway endpoints (S3, DynamoDB — free). Interface endpoints (most services — ENI with private IP). Prevents data exfiltration via public internet path to AWS services.

Transit Gateway: Hub-and-spoke connectivity between multiple VPCs and on-premises. Avoids full VPC peering mesh (n*(n-1)/2 peering connections). Centralize security inspection (firewall in inspection VPC).

Container Image Security:

• Image scanning: Trivy, Clair, Snyk — scan layers for CVEs before deployment. Integrate into CI/CD pipeline (fail build if critical CVE). AWS ECR, Azure ACR have built-in scanning.
• Minimal base images: Alpine Linux (~5MB) vs Ubuntu (~188MB). Smaller base = fewer packages = less attack surface. Distroless images (Google) have no package manager or shell.
• Never use :latest tag: Non-deterministic — :latest changes with new pushes, breaks reproducibility, and can silently introduce vulnerabilities. Pin to specific digest: image@sha256:abc123...
• Multi-stage builds: Build stage (full compiler, dev tools) → copy only artifact to minimal runtime image. Dev tools not in production image. Compile-only dependencies removed.
• Non-root user: Dockerfile: USER appuser (create with useradd). Running as root = container escape → root on host (with write access to host filesystem). Critical security requirement.
• Read-only root filesystem: Dockerfile: --read-only flag. Attacker cannot write malware to container filesystem. Writable volumes only for known paths.

Kubernetes Security:

• NetworkPolicy: Default Kubernetes allows all pod-to-pod communication within cluster. NetworkPolicy implements firewall rules between pods. Best practice: default-deny all ingress and egress, then explicitly allow required paths. Requires compatible CNI (Calico, Cilium, Weave).
• Pod Security Admission (PSA): Replaces deprecated PodSecurityPolicy. Enforce/warn/audit modes. Baseline profile: no privileged containers. Restricted profile: no root, no host namespace, read-only root FS.
• Secrets management: Never bake secrets into Docker images (accessible via docker inspect) or environment variables (visible in pod spec). Use Kubernetes Secrets (base64, not encrypted by default — enable etcd encryption at rest), or HashiCorp Vault with Vault Agent injector, or AWS Secrets Manager via External Secrets Operator.
• RBAC: Principle of least privilege for service accounts. Avoid binding ClusterAdmin to application service accounts. Create specific roles per application namespace.

Runtime Security: Falco (CNCF) monitors Linux syscalls and generates alerts when container behavior deviates from expected patterns — detect unexpected network connections, file writes in read-only paths, shell spawns in containers. Supply chain: sign images with cosign/Notary, verify signatures before deployment (admission controller policy).

IAM Roles vs Long-Term Access Keys:

• IAM Roles (preferred): Use AWS STS to generate temporary credentials (15 min to 12 hours). Automatically rotate. No credential management required. Assigned to EC2 instance profile, Lambda execution role, ECS task role.
• Long-term access keys (avoid): Never expire unless manually rotated. Commonly committed to source code repositories (truffleHog, git-secrets detect this). Use ONLY for local development; use roles in production. Require MFA for sensitive API calls.
• Detect exposed access keys: GuardDuty, AWS Config rules, git-secrets pre-commit hook

Principle of Least Privilege for Cloud IAM:

• Avoid wildcard permissions: "s3:*" on "*" resource. Specify exactly: "s3:GetObject" on "arn:aws:s3:::specific-bucket/*"
• Never use AdministratorAccess/Owner roles for applications — only for break-glass scenarios with MFA
• Cross-account roles: define explicit trust policies. Confused deputy problem — validate ExternalId parameter
• AWS SCPs / Azure Policy: guardrails applied at the organization/management group level. Prevent any account from disabling CloudTrail, creating IAM users without MFA, deploying to unapproved regions.

CloudTrail / Activity Logs:

• AWS CloudTrail logs all API calls: who, what resource, from which IP, at what time. Stored in S3 — immutable audit trail.
• High-priority CloudTrail alerts: root account login (should never happen), access key deletion, IAM user creation, CloudTrail disabled, security group opened to 0.0.0.0/0, S3 bucket policy changed to public
• Forward to SIEM (Splunk, Sentinel) via CloudWatch Events and Kinesis

CSPM (Cloud Security Posture Management):

• Continuously checks cloud configuration against CIS Benchmarks, NIST 800-53, PCI DSS, HIPAA controls
• AWS Security Hub: aggregates findings from GuardDuty, Inspector, Macie, Config. Dashboard with severity. CIS Benchmark compliance score.
• Microsoft Defender for Cloud: multi-cloud support (AWS, GCP, Azure). Secure Score. Regulatory compliance dashboard.
• Prisma Cloud (Palo Alto): multi-cloud CSPM + CWPP (workload protection). Most comprehensive.
• Top detections: public S3 buckets, open security groups (0.0.0.0/0 on port 22/3389), root account without MFA, CloudTrail disabled, unencrypted RDS, unrestricted IAM policies

Cloud WAF:

• AWS WAF: attach to CloudFront, ALB, API Gateway, AppSync. Managed rule groups (AWS, partners). Custom rules with rate limiting and geo-blocking. Logs to S3/CloudWatch.
• Azure WAF: on Application Gateway or Front Door. OWASP CRS managed rules. Bot protection.
• OWASP Core Rule Set protects against: SQLi, XSS, local/remote file inclusion, command injection, PHP attacks, Java exploits.

Cloud DDoS Protection:

• AWS Shield Standard: free, automatic protection on all AWS accounts. Protects against common L3/L4 attacks (SYN floods, UDP reflection). No configuration required.
• AWS Shield Advanced: $3,000/month base. DDoS Response Team (DRT) access, cost protection for scaling during attacks, network flow monitoring, advanced detection. Required for L7 protection with WAF integration.
• Azure DDoS Protection Standard: per-VNet protection, adaptive tuning, attack analytics, SLA guarantee.

Cloud Monitoring Services:

• AWS GuardDuty: threat detection from VPC Flow Logs, CloudTrail, DNS logs. ML-based. Detects: crypto mining, C2 beaconing, port scanning, compromised instance behavior, credential exfiltration.
• Amazon Macie: ML-based PII detection in S3. Discovers: SSNs, credit card numbers, AWS credentials, personal information.
• AWS Config: compliance rules for resource configurations. SNS alerts when rule violated. Required for CIS Benchmark compliance monitoring.
• Azure Sentinel: cloud-native SIEM/SOAR. Connects to Microsoft 365, Azure, AWS, GCP logs.

Object Storage Security (S3):

• S3 Block Public Access: account-level setting. Enable on all accounts. Overrides bucket policies that attempt to grant public access.
• Bucket policies: JSON resource-based policies. Deny: "Principal": "*" unless condition met. Use aws:SourceVpc condition to restrict to VPC endpoints only.
• Server-Side Encryption: SSE-S3 (AWS manages keys, free), SSE-KMS (customer controls CMK, additional cost, audit in CloudTrail), SSE-C (customer manages keys outside AWS).
• Versioning + MFA Delete: protect against ransomware attacks on S3 objects.