AWS Cloud Security Threats & Mitigation Study Guide

This guide covers the critical security threats identified in the DOP-C02 curriculum, focusing on insecure traffic, exposed credentials, and S3 misconfigurations, along with the automated solutions used to remediate them.

Learning Objectives

After studying this guide, you should be able to:

• Identify the risks associated with unencrypted web traffic and how to implement TLS via ACM.
• Recognize the dangers of exposed IAM access keys and the lifecycle of remediation.
• Configure S3 security posture including Block Public Access and Default Encryption.
• Select appropriate AWS services (GuardDuty, Inspector, Config) to monitor and audit security events.

Key Terms & Glossary

• Hardcoded Credentials: Plain-text access keys or secrets embedded directly in source code, making them vulnerable to exposure if the code is shared.
• S3 Block Public Access: A bucket-level and account-level setting that provides a centralized control to ensure S3 buckets never become public, regardless of individual policy settings.
• Data-in-Transit Encryption: The process of protecting data while it moves across a network, typically using TLS (Transport Layer Security).
• Server-Side Encryption (SSE): Encryption of data at its destination by the service that stores it. In S3, this is often handled by SSE-S3 or SSE-KMS.
• Least Privilege: The security principle of granting only the minimum permissions necessary to perform a specific task.

The "Big Idea"

In a DevOps environment, security is not a perimeter check but a continuous, automated process. The "Big Idea" is Defense in Depth. By layering identity controls (IAM), resource-based policies (S3), and continuous monitoring (GuardDuty/Config), you create a resilient architecture where a single failure (like an exposed key) does not lead to a total system compromise.

Formula / Concept Box

Hierarchical Outline

1. Insecure Web Traffic
   • Threat: HTTP traffic is unencrypted; data can be intercepted.
   • Solution: Use AWS Certificate Manager (ACM) for SSL/TLS certificates on Load Balancers (ALB/NLB).
   • Enforcement: Use AWS WAF or ALB listener rules to redirect HTTP (80) to HTTPS (443).
2. Exposed IAM Access Keys
   • Threat: Keys leaked to public repositories (e.g., GitHub).
   • Detection: Amazon GuardDuty (detects unusual API calls) and IAM Access Analyzer.
   • Remediation: Deactivate key immediately, rotate credentials, and use IAM Roles for EC2/Lambda instead of static keys.
3. S3 Misconfigurations
   • Public Access: S3 buckets accidentally set to PublicRead or PublicReadWrite.
   • Encryption: Data stored without SSE-KMS or SSE-S3.
   • Auditing: Use AWS Config rules (s3-bucket-public-read-prohibited) and Amazon Macie to find PII.

Visual Anchors

Threat Detection Flow

S3 Security Layers

Definition-Example Pairs

• Insecure Web Traffic
  Definition: Transmission of sensitive data over cleartext protocols like HTTP.
  Example: A login page sending passwords over HTTP, allowing an attacker on a public Wi-Fi to capture the password via a packet sniffer.
• Exposed Access Keys
  Definition: Long-term AWS credentials accidentally committed to version control.
  Example: A developer pushes a .env file containing AWS_ACCESS_KEY_ID to a public GitHub repository, resulting in automated bots launching expensive GPU instances within minutes.
• Unencrypted S3 Bucket
  Definition: An S3 bucket where objects are stored without server-side encryption enabled.
  Example: A financial report stored in S3 is physically stolen from an AWS data center (hypothetical), and because it wasn't encrypted, the thief can read the data immediately.

Worked Examples

Example 1: Remediating a Public S3 Bucket via AWS Config

1. Detection: AWS Config evaluates the rule s3-bucket-public-read-prohibited and finds my-public-data-bucket is non-compliant.
2. Automation: The Config Rule triggers an SSM Automation Document.
3. Action: The document executes PutPublicAccessBlock on the bucket, overriding any permissive ACLs or policies.
4. Result: The bucket is secured within seconds of the misconfiguration occurring.

Example 2: TLS Implementation for Web Traffic

1. Request: Request a public certificate in ACM for api.example.com.
2. Validation: Use DNS validation to prove ownership of the domain.
3. Deployment: Attach the certificate to an Application Load Balancer (ALB) HTTPS listener on port 443.
4. Redirect: Create a listener rule on port 80 to redirect all traffic to 443 with a 301 Moved Permanently status code.

Checkpoint Questions

1. Which service is best suited for identifying if an S3 bucket contains personally identifiable information (PII) that shouldn't be public?
2. What is the difference between an IAM User's access keys and an IAM Role's temporary credentials regarding security risk?
3. How can you ensure that all new S3 buckets created in an organization automatically have encryption enabled?
4. If GuardDuty detects a "Backdoor:EC2/C&CActivity" finding, what is the most likely cause?
5. Which AWS service can automatically check your environment against the CIS AWS Foundations Benchmark?

Muddy Points & Cross-Refs

• GuardDuty vs. Inspector: Remember that GuardDuty monitors network logs (VPC Flow Logs, CloudTrail) for behavioral threats, while Amazon Inspector scans the internal state of an EC2 instance or Container for known software vulnerabilities.
• Security Groups vs. NACLs: Security Groups are stateful and operate at the instance level; Network ACLs are stateless and operate at the subnet level. For "Insecure Web Traffic," both are used in defense-in-depth.
• Cross-Ref: See Unit 5: Incident Response for how to use Lambda to automate the deactivation of the keys mentioned in this guide.

Comparison Tables