Security & Operations

Security, Deployment, and Operations

AWS Secrets Manager

Secrets Manager Overview

• Fully managed service to store and manage secrets in AWS
  • Secrets include passwords, API keys, and other sensitive credentials
• Accessible via console, CLI, API, or SDKs
  • Designed to be integrated directly into applications
    • Example: an app uses the SDK to retrieve or store secrets dynamically
• Encryption at rest using AWS KMS
  • Ensures role-based separation of duties
  • Protects secrets even if hardware is compromised
• Supports automatic secret rotation
  • Lambda functions can be scheduled to update secrets on a regular basis
• Direct integration with some AWS services, most commonly RDS
  • Secrets are updated automatically, so RDS authentication stays current
• Shares some features with SSM Parameter Store
  • Parameter Store can hold secure strings and other configurations (plaintext, lists, app settings)
  • Secrets Manager is specialized for secrets and adds automatic rotation, SDK integration, and direct service support
  • Exam tip: mentions of secret rotation or RDS synchronization usually indicate Secrets Manager; storing mixed configuration data may indicate Parameter Store

Secrets Manager Architecture

• IAM policies control which applications or users can access Secrets Manager
• Lambda functions that rotate secrets require execution roles with Secrets Manager permissions
• For supported services like RDS, Lambda functions also need permissions to update the service
• Applications that query Secrets Manager continuously always have access to the most recent secrets

Application Layer (L7) Firewalls

Traditional Firewalls

• Operate at OSI layers 3, 4, and 5
• Layer 3-4 firewalls (stateless)
  • Inspect packets and segments, including source/destination IPs and ports
  • Do not track requests and responses → treat each flow independently
• Layer 5 firewalls (stateful)
  • Recognize requests and responses as a single session
  • Reduces administrative effort (one rule can cover both directions)
  • Provides more contextual security → can differentiate requests from responses
• Layer 7 (application) is invisible to traditional firewalls
  • Cannot analyze application data (images, malware, file content)
  • Cannot interpret application protocols like HTTP (headers, hosts, response codes)
• Summary: Traditional firewalls focus on layers 3-5, using stateless and stateful inspection

Layer 7 Firewalls

• Operate at OSI layer 7, understanding application protocols and data
  • Retain all capabilities of traditional firewalls for layers below
• L7 data inspection allows content to be analyzed, blocked, modified, or tagged
  • Examples: block adult content, spam, or specific file types
  • Can enforce fine-grained rules (e.g., allow cat and dog images, block others)
• Protocol-aware actions
  • Can inspect DNS names, connection rates, header content, or detect abnormal requests
  • Can block specific applications such as Facebook or Dropbox
• HTTPS decryption for inspection
  • Traffic is decrypted by the firewall, analyzed, then re-encrypted before forwarding
  • This process is transparent to both client and server
• Limitations:
  • May not support all application protocols
  • Example: firewall can inspect HTTP(S) but may not handle SMTP

AWS Web Application Firewall (WAF)

Web Application Firewall (WAF) Overview

• AWS WAF is a managed Layer 7 firewall that protects web-facing resources
  • Supports resources like CloudFront, ALBs, API Gateway, and AppSync
• Primary configuration unit:Web ACL (WEBACL)
  • Associated with resources (e.g., CF distribution, ALB)
  • Contains rules and rule groups to control how WAF responds to traffic
• Key capabilities:
  • Filter legitimate users from bots and malicious actors
  • WEBACLs can be updated manually or automatically
    • Automatic updates can use event-driven architecture, e.g., EventBridge to import public IP lists
  • Logs can be delivered to S3, CloudWatch Logs, or Kinesis Data Firehose
    • Use Data Firehose for near real-time reactions; S3 is slower (~5 min delay)
• Feedback loop for automation:
  1. Collect logs
  2. Analyze and identify actionable insights (e.g., Athena, Lambda)
  3. Apply updates automatically to WEBACLs

WAF Components

Web Access Control List (WEBACL)

• Controls whether traffic is allowed or blocked
• Resource types:
  1. CloudFront (global)
  2. Regional services (ALB, APIGW, AppSync) – must select region
  • Regional WEBACLs cannot be assigned to CloudFront, and vice versa
• Default action: ALLOW or BLOCK traffic that does not match any rules
  • ALLOW ensures only known good traffic is processed
  • BLOCK explicitly prevents unknown or suspicious traffic
• Rules and rule groups are evaluated in order
• WEBACL Capacity Units (WCUs): compute limit for rules
  • Default: 1500 WCUs (can be increased via support request)
• Associations:
  • One WAF can protect multiple resources
  • Each resource can have only one associated WAF
  • Associating a WAF can take time to propagate, editing rules is faster

WAF Rule Groups

• Containers for multiple rules
• Do not define default actions; default actions are set at the WEBACL level
• Ownership types:
  • Managed by AWS or Marketplace
  • Customer-owned
  • Service-owned (e.g., Shield, Firewall Manager)
• Can be referenced by multiple WEBACLs
• Each rule group has WCU capacity, default 1500 (extendable via support)

WAF Rules

• Composed of Type + Statement(s) + Action(s)

Rule Types:

1. Regular – match specific conditions
2. Rate-based – match if traffic exceeds a threshold

Statements:

• Define what traffic to inspect
  • Examples: TCP port, HTTP headers, query string, URI path, cookies, country, body (first 8192 bytes only)
• Can combine multiple statements with AND, OR, NOT

Actions:

1. Allow – permit traffic (only for regular rules)
2. Block – deny traffic
3. Count – log matched traffic
4. Captcha – challenge the client; success counts as Count, failure blocks traffic

• Can add labels for multi-stage flows within a WEBACL
  • Labels work only if processing continues (Count and Captcha actions)

WAF Pricing

• WEBACL: $5/month per WEBACL
  • Can be reused across multiple resources; only charged per WEBACL
• Requests processed: $0.60 per 1 million requests per WEBACL
• Rules: $1/month per rule, rule groups may cost extra
• Optional features:
  • Bot Control: $10/month + $1 per 1M requests
  • CAPTCHA: $0.40 per 1,000 attempts
  • Fraud Control/Account Takeover: $10/month + $1 per 1,000 login attempts
• Use AWS Pricing Calculator to estimate costs: AWS Calculator

Distributed Denial of Service (DDoS) Attacks

DDoS Attacks – Overview

• The primary objective is to overwhelm websites or services with excessive traffic
  • Malicious requests compete with legitimate users and exhaust system resources
  • Analogy: a large number of unnecessary customers filling a queue, preventing real customers from being served efficiently
• The distributed nature makes mitigation difficult
  • Traffic originates from many different devices and locations
  • Blocking individual IPs is ineffective and may impact real users
• Main categories:
  • Application layer attacks (e.g., HTTP floods)
  • Protocol attacks (e.g., SYN floods)
  • Volumetric attacks (e.g., DNS amplification)
• Typically coordinated by a small number of attackers controlling large botnets
  • Botnet = many compromised devices infected with malware, often spread globally
  • Device owners are usually unaware their systems are involved

Normal Operation of a Web Application (Example)

• Servers deliver application functionality
  • Usually include some buffer capacity or autoscaling
• Connectivity to the internet is limited by bandwidth, speed, and connection limits
• Users access services via apps or browsers, with the vast majority of traffic being legitimate under normal conditions

Types of DDoS Attacks

Application Layer Attacks

• Target imbalances in processing effort between client and server
  • Example: HTTP flood
    • Small request from client (e.g., GET request)
    • Large or resource-intensive response from server
• Large volumes of such requests can overwhelm servers
• Traffic often appears legitimate, making detection more complex

Protocol Attacks

• Exploit how network protocols manage connections
  • Example: TCP SYN flood
• Process:
  1. Attackers send many SYN requests with spoofed source IPs
  2. Servers respond with SYN-ACK packets to invalid destinations
  3. No ACK response is received, leaving connections half-open
  4. Server resources remain tied up until timeout, reducing capacity for legitimate users

Volumetric (Amplification/Reflection) Attacks

• Exploit differences between request size and response size
  • Example: DNS amplification
• Process:
  1. Attackers send requests to multiple DNS servers using the victim’s IP as the source
  2. DNS servers respond to the victim, assuming it made the request
  3. The victim receives a large volume of amplified responses
• The attack overwhelms network bandwidth, not just application servers
• Amplification allows attackers to generate large traffic with relatively small input
  • DNS servers involved are not malicious, just responding normally
  • Blocking them may disrupt legitimate access

AWS Shield

AWS Shield – Overview

• AWS Shield provides protection against DDoS attacks
  • Two tiers: Standard (free) and Advanced (paid)
• Shields infrastructure from multiple attack types:
  • Network volumetric attacks (L3) → overload bandwidth or network capacity
  • Transport/Protocol attacks (L4) → e.g., TCP SYN floods (may also have volumetric elements)
  • Application layer attacks (L7) → e.g., floods of web requests
    • Certain operations like searches are vulnerable because requests are cheap to send but expensive to process

AWS Shield Standard

• Automatically included for all AWS customers
  • No setup required; operates in the background
  • No additional cost
• Provides perimeter-level protection
  • At the regional network level (VPC ingress) or AWS edge (CloudFront, Global Accelerator)
• Protects against common L3/L4 attacks
• Works best when using AWS services such as Route 53, CloudFront, or Global Accelerator
• Limited in configurability and lacks proactive engagement compared to Advanced

AWS Shield Advanced

• Paid tier: $3,000/month per AWS organization
  • Covers all member accounts in the organization
  • Requires a 12-month commitment
  • Extra charges may apply for outbound data
• Protects additional resources beyond Standard:
  • Includes R53, CF, Global Accelerator (like Standard)
  • Also protects Elastic IPs (EIPs) and load balancers (ALB, NLB, CLB)
• Must be explicitly enabled (not automatic)
• Key features:
  • Cost protection for unmitigated attacks
    • AWS reimburses excess costs caused by DDoS-induced scaling or other failures
  • Proactive support via the AWS Shield Response Team (SRT)
    • Fast engagement and guidance during attacks
    • 24/7 support and ticket handling
  • Integration with WAF
    • Provides protection against L7 attacks using WEBACLs, rules, and web requests
    • Shield Advanced handles automatic configuration and updates for WAF
  • Real-time monitoring
    • Metrics, reports, and dashboards for visibility into attacks
  • Health-based detection
    • Uses Route 53 application health checks to reduce false positives
    • Required for proactive engagement by SRT
  • Protection groups
    • Group related resources for easier administration
    • Resources meeting defined criteria are automatically added to protection groups

Hardware Security Modules (HSMs)

Local Key Management Without HSM

• Scenario: Virtualized setup using a VM host (e.g., VMWare)
• Encryption keys are stored in multiple locations:
  • Hardware (CPU, RAM, storage devices)
  • Software (hypervisor, operating systems, applications)
  • External backups (for redundancy and disaster recovery)
• Keys may leave the primary system (e.g., through backups), which reduces direct control and increases vulnerability to attacks

Hardware Security Module (HSM) Concepts

• HSM = dedicated hardware device(s) for storing and processing cryptographic keys
  • Standalone device or a cluster, segregated from main infrastructure
  • Handles all cryptographic operations internally
    • Data is sent to HSM, processed, then returned
• HSM manages the full key lifecycle (generation, storage, deletion)
  • Keys never exit the HSM
• Considerations:
  • Additional hardware adds cost and space requirements
  • Communication with HSM can introduce extra latency compared to in-memory key storage
• HSMs are ideal in environments with high-security requirements, such as banking

Local Key Management With HSM

• HSM is integrated into the previous architecture
• Encryption keys are exclusively stored in the HSM, so the VM host interacts with the HSM for any cryptographic tasks

HSM Architecture and Benefits

• Lower risk of key exposure because:
  • HSM is isolated from main systems
  • Keys remain inside the HSM for their full lifecycle
• Authentication is performed within the HSM, limiting the impact if other identity stores are compromised
• Tamper-resistant hardware, protected against physical and logical attacks
  • Similar to secure storage in smartphones for biometrics
• Access only through standardized APIs (e.g., PKCS11, JCE, CryptoNG)
• Separation of roles:
  • HSM administrators maintain hardware but cannot perform cryptographic operations
  • Supports compliance and audit requirements
• Example HSM use cases:
  • Offloading SSL/TLS operations from servers, with hardware acceleration improving performance and security
  • Signing certificates in private PKI systems

AWS CloudHSM

Refresher: KMS and HSMs

• AWS KMS is the default encryption-at-rest solution
  • Manages encryption keys within AWS, either AWS-managed or customer-managed
  • Integrated with many AWS services
  • Fine-grained permissions: customer-managed keys are isolated from other AWS customers
  • However, KMS remains a shared service
    • Some default service keys may be used by multiple customers without explicit knowledge
  • AWS controls the underlying hardware and software for KMS, giving AWS partial access
  • For high-security or compliance-sensitive scenarios, dedicated non-shared hardware with strictly controlled access may be required
• Hardware Security Module (HSM) → specialized hardware device for storing and processing encryption keys
  • AWS KMS internally relies on AWS-managed HSMs
  • HSMs can be deployed on-premises or in the cloud (e.g., AWS CloudHSM)

CloudHSM Overview

• CloudHSM = HSM-as-a-Service, providing dedicated single-tenant HSM hardware
  • AWS provisions and maintains the hardware, but does not manage key material
  • Customers fully control keys: losing access to the HSM means data cannot be recovered, though the HSM can be reprovisioned
• Compliance: FIPS 140-2 standard
  • CloudHSM is FIPS 140-2 Level 3 compliant
  • KMS is FIPS 140-2 Level 2 overall (some components meet L3)
  • Extra reading: https://en.wikipedia.org/wiki/FIPS_140-2
• Access through standard cryptography APIs:
  • PKCS#11
  • Java Cryptography Extensions (JCE)
  • Microsoft CryptoNG (CNG)
• No native integration with most AWS services
  • Example: S3 server-side encryption uses KMS, not CloudHSM
  • However, KMS can use CloudHSM as a custom key store, combining HSM security with AWS integration

CloudHSM Use Cases

• Client-Side Encryption (CSE)
  • Encrypt data locally with CloudHSM before uploading to S3
• Offload SSL/TLS processing from web servers
  • Reduces CPU usage on servers; HSM hardware accelerates cryptographic operations
• Enable Transparent Data Encryption (TDE) for Oracle databases
  • Oracle can use standard APIs to access HSMs
• Protect private keys for Certificate Authorities (CAs)

CloudHSM Architecture

• CloudHSM instances are deployed in AWS-managed VPCs (customers do not see the underlying infrastructure)
  • Each HSM adds an ENI into the customer VPC in its designated AZ
• Single-AZ deployments are not highly available by default
  • High availability requires multiple HSMs configured as a cluster
• Keys, policies, and configurations are replicated across the HSM cluster automatically
• Customer VPC clients connect to CloudHSM via the assigned ENIs
  • EC2 instances use CloudHSM client software and standard APIs (PKCS#11, JCE, CNG)
  • For HA, EC2 instances must access all cluster nodes, including cross-AZ
• HSMs are tamper-resistant and partitioned in the cloud
  • AWS can perform software updates and maintenance
  • AWS cannot access the secure key storage area

AWS Config 101

AWS Config – Overview

• Tracks changes to AWS resource configurations over time
  • Produces configuration items (CIs), which collectively form configuration histories
    • Useful for auditing changes and verifying compliance
  • Example: Enabling monitoring on a Security Group (SG) → Config records the SG’s state before and after changes, who made the change, and associated resources
• Does not prevent configuration changes
  • Config only monitors and records changes
  • Can provide alerts when changes occur
• Regional service
  • Configuration histories are stored in an S3 Config bucket in a consistent format
  • Supports cross-region and cross-account aggregation of configuration histories
• Two primary functions:
  1. Recorder functionality: logs configuration changes for specified resources
  2. Config rules: evaluate resources against compliance standards
     • Rules can be AWS-managed or custom (defined using Lambda functions that assess resources)
     • Example: A rule can flag an EC2 instance as non-compliant if CPU usage exceeds 90%
• Change notifications and automation:
  • Can generate SNS notifications
  • Can send near-real-time events to EventBridge
    • Events can trigger Lambda functions for remediation
    • Events can be routed to SSM, useful for managing EC2 instance configurations
  • While Config does not prevent changes, it enables automated remediation actions
• Architecture Diagram:

Amazon Macie 101

Amazon Macie – Key Concepts

• Service for security and privacy of data stored in S3
  • Discovers, monitors and protects data stored in S3 buckets
  • Can perform automated discovery of sensitive data
    • e.g. Personal Identifiable Information (PII), Personal Health Information (PHI), SSH keys, financial information…
• Data identifiers → identify and inventory sensitive data
  • Can be thought of as rules which objects & contents are assessed against
  • Two types
    1. Managed data identifiers
       • Built-in, use ML/pattern-matching
       • Can detect almost all common types of sensitive data
    2. Custom data identifiers
       • Proprietary, regex-based
       • Can e.g. find certain patterns in your business like employee IDs
• Discovery jobs use identifiers to find any matches in buckets → generate findings
  • Findings can be viewed interactively
  • Findings can integrate with AWS Services
    • e.g. Security Hub, or sending “finding events” to EventBridge
• Multi-account architecture
  • Administrator account can manage Macie within member accounts
  • Central management either via AWS Organizations or explicit account inviting

Amazon Macie – Architecture

1. Discovery job is scheduled
2. Discovery job uses managed and custom data identifiers to scan S3 buckets and generate findings
3. Findings can trigger events in EventBridge → can be used for event-driven remediation (e.g. Lambda function that masks PII in S3 buckets)

Macie Identifiers and Findings

Amazon Macie – Data Identifiers

Managed Data Identifiers

• Created and maintained by AWS
• Covers a wide range of common sensitive data types
  • Examples: credentials, financial data, health information, personally identifiable information (PII)

Custom Data Identifiers

• Created and maintained by the customer
• Based on regular expressions (regex)
  • Define patterns to match in data, e.g., [A-Z]-\d{8}
• Additional options (refiners):
  • Keywords: words or phrases that must appear near the regex match
    • If the keyword is not sufficiently close, the match is ignored
  • Maximum match distance: sets how far keywords can be from the regex pattern
  • Ignore words: if matched data contains these words, the match is ignored

Amazon Macie – Findings

Sensitive Data Findings

• Triggered when sensitive data is discovered in S3 objects
• Examples:
  • SensitiveData:S3Object/Credentials → exposed SSH keys, AWS access keys, etc.
  • SensitiveData:S3Object/Financial → credit card numbers, bank accounts, etc.
  • SensitiveData:S3Object/Personal → PII, such as full names, mailing addresses
  • SensitiveData:S3Object/CustomIdentifier → data matching custom regex patterns
  • SensitiveData:S3Object/Multiple → multiple types of sensitive data detected

Policy Findings

• Triggered when S3 bucket policies or settings are modified and reduce security
  • Only generated after Macie is enabled
• Examples:
  • Policy:IAMUser/S3BlockPublicAccessDisabled
  • Policy:IAMUser/S3BucketEncryptionDisabled
  • Policy:IAMUser/S3BucketPublic → bucket is now public
  • Policy:IAMUser/S3BucketSharedExternally

DEMO: Identifying Sensitive Data with Macie

Amazon Macie Demo – Step-by-Step

• Create an S3 bucket and upload files containing sensitive data. Include at least one file that does not contain sensitive data (e.g., a cat picture).
• Set up an SNS topic:
  • Create an email subscription using your email address.
  • Confirm the subscription through the confirmation email you receive.
• Create an EventBridge rule to detect Macie findings:
  • Select Macie as the AWS service and Macie Finding as the event type.
  • Set the target as your SNS topic.
  • Now, whenever a Macie finding is detected, an email will be sent with details of the finding.
  • Screenshot reference:

• Go to Amazon Macie and enable the service in your account.
  • Note: Macie has a free tier for the first 30 days after enabling.
• Create a one-time discovery job to scan your S3 bucket:
  • Use the recommended managed data identifiers only.
  • Let the job run—it may take a few minutes.
  • Screenshot reference:

• While the job is running, you should receive an email with any sensitive findings, such as financial information.
  • By the end, one high-severity finding should be detected.
  • Screenshot reference:

• Create a custom data identifier using the regex provided in the repository.
• Run a second one-time discovery job:
  • Select all data identifiers, including the custom identifier you created.
  • Let the job complete.
  • Screenshot reference:

• After the job finishes, you should see more findings than before, including results detected by your custom regex (e.g., Australian license plates).
  • Emails with findings should also be received.
  • Screenshot reference:

• Clean up your account:
  • Delete the S3 bucket, EventBridge rule, and SNS topic.
  • Disable Macie to avoid unnecessary charges.

Amazon Inspector

Amazon Inspector – Overview

• Automated scanning of compute resources for security issues
  • Supports the following compute resources:
    • EC2 instances (network configuration and operating system)
    • Containers stored in ECR
    • Lambda functions
  • Detects vulnerabilities, exposure, and deviations from best practices
    • Analyzes unusual traffic patterns or misconfigurations
• Security assessments (scans)
  • Duration options: 15 minutes, 1 hour, 8 hours, 12 hours, or 1 day
  • Rules packages determine the checks performed during an assessment
• Generates reports of findings ordered by severity, priority, and risk score
  • Can integrate with AWS Security Hub and Amazon EventBridge
• Inspector Agent
  • Software installed on EC2 hosts or container hosts
  • Provides OS-level assessments and more detailed network insights
  • Installed via AWS Systems Manager (SSM) agent

Amazon Inspector – Assessment Types

1. Network assessment
   • Evaluates network configurations using the Network Reachability rules package
   • Agent not required, though installing it provides additional OS visibility
   • Checks end-to-end reachability across EC2 instances, ELBs, ALBs, Direct Connect, ENIs, IGWs, ACLs, route tables, security groups, subnets, VPCs, VGWs, and VPC peering connections
   • Example findings:
     • UnrecognizedPortWithListener
     • RecognizedPortWithListener (recognized = well-known port)
     • RecognizedPortNoListener
     • RecognizedPortNoAgent (well-known port exposed, but no agent installed, so OS listener cannot be verified)
2. Host assessment
   • Focuses on OS-level vulnerabilities
   • Requires the Inspector Agent
   • Supported rules packages:
     • Common Vulnerabilities and Exposures (CVE)
       • Database of known cybersecurity vulnerabilities, each identified by a CVE number
     • Center for Internet Security (CIS) benchmarks
       • Industry-standard best practices that are consensus-based and unbiased
     • Amazon Inspector security best practices
       • Examples: disable root SSH login, enforce modern SSH configurations, password complexity, and other OS-level security controls

Amazon GuardDuty 101

Amazon GuardDuty – Overview

• Continuous security monitoring service
  • Runs in the background to protect AWS accounts and resources from potential security threats
  • Utilizes machine learning (ML) and AI, along with threat intelligence feeds
• Continuously analyzes supported data sources:
  • DNS logs from Route 53 (detects unusual DNS requests)
  • VPC Flow Logs (monitors anomalous internal traffic or suspicious IP addresses)
  • CloudTrail event logs (detects unusual API activity and unauthorized deployments)
    • Management events (control plane anomalies)
    • S3 data events (unusual access patterns to S3 objects)
  • Optional integrations: EKS audit logs, RDS & Aurora logs, EBS, Lambda, additional S3 data events
• Detects unexpected or unauthorized activity
  • Learns patterns automatically; no need to define threats manually
  • Customers can influence detection through IP whitelists or specifying allowed behaviors
  • Can notify or trigger automated remediation:
    • Example: findings sent to EventBridge, which invokes a Lambda function to update NACLs for protection
    • Example: alerts for cryptocurrency mining or other targeted attacks
• Supports multi-account management
  • Master-member architecture: a master account can manage and monitor multiple member accounts