AWS Security: Vulnerability Identification and Event Detection

This guide covers the core AWS services used to identify security vulnerabilities, detect anomalous events, and maintain compliance within a DevOps environment, specifically focusing on Amazon GuardDuty, Amazon Inspector, IAM Access Analyzer, and AWS Config.

---

Learning Objectives

After studying this guide, you should be able to:

• Differentiate between threat detection (GuardDuty) and vulnerability scanning (Inspector).
• Explain how AWS Config monitors resource state and detects configuration drift.
• Utilize IAM Access Analyzer to enforce least-privilege and identify external resource sharing.
• Architect a centralized security finding pipeline using AWS Security Hub.
• Implement automated remediation patterns for common security events.

Key Terms & Glossary

• Finding: A standardized record of a security issue or compliance check (e.g., "S3 bucket is public").
• CVE (Common Vulnerabilities and Exposures): A list of publicly disclosed computer security flaws.
• Configuration Drift: When the actual state of a resource deviates from its desired or initial state.
• ASFF (AWS Security Finding Format): A standard JSON schema used by Security Hub to aggregate findings from different services.
• Reconnaissance: An attacker's initial activity, such as port scanning or unusual API calls, to gather info.

The "Big Idea"

In a modern cloud environment, security cannot be a one-time gate; it must be a continuous, automated loop. While traditional security focused on perimeters, AWS security focuses on Observability. By combining log analysis (GuardDuty), posture assessment (Config), and vulnerability management (Inspector), you create a "Defense in Depth" strategy where multiple layers of automation detect and respond to threats faster than any human operator could.

Formula / Concept Box

Hierarchical Outline

1. Intelligent Threat Detection (Amazon GuardDuty)
   • Regional Service: Must be enabled in every region.
   • Detection Classes: Reconnaissance, Instance Compromise, Account Compromise.
   • Log Analysis: Does not require logs to be turned on; it reads logs directly from the AWS backend.
2. Vulnerability Management (Amazon Inspector)
   • Network Reachability: Checks for unintended open ports.
   • Host Assessment: Scans for CVEs on EC2 (via SSM Agent) and Lambda.
   • Container Scanning: Scans images pushed to Amazon ECR.
3. Configuration & Compliance (AWS Config)
   • Resource Timeline: Records every change to a resource (e.g., Security Group rule change).
   • Managed Rules: Pre-built logic to check for compliance (e.g., s3-bucket-public-read-prohibited).
   • Remediation: Can trigger Lambda or SSM Automation to fix non-compliant resources.
4. Access Control (IAM Access Analyzer)
   • External Access: Alerts if S3, IAM Roles, or KMS keys are shared outside the account/org.
   • Policy Validation: Checks policy syntax and best practices during authoring.

Visual Anchors

The Security Findings Pipeline

Continuous Compliance Loop

Definition-Example Pairs

• GuardDuty (Instance Compromise): An EC2 instance starts communicating with a known Bitcoin mining pool IP address. Example: GuardDuty generates a CryptoCurrency:EC2/BitcoinTool.B!dns finding.
• AWS Config (Managed Rule): A rule that ensures all EBS volumes are encrypted. Example: An engineer creates a non-encrypted volume; Config marks it "Non-compliant" and triggers an SNS alert.
• Inspector (Network Reachability): Checking if an EC2 instance is reachable from the internet. Example: An Inspector scan reveals that port 22 (SSH) is open to 0.0.0.0/0 on a private instance.

Worked Examples

Example 1: Automated Remediation of Public S3 Buckets

1. Event: A developer mistakenly makes an S3 bucket public.
2. Detection: AWS Config evaluates the s3-bucket-public-read-prohibited rule and finds the resource non-compliant.
3. Trigger: Config triggers an Amazon EventBridge rule based on the compliance change.
4. Action: EventBridge targets an AWS Lambda function.
5. Resolution: The Lambda function executes PutBucketPublicAccessBlock to re-secure the bucket.

Example 2: Analyzing a Compromised Account

1. Alert: GuardDuty detects an API call from an unusual geolocation (e.g., a country your company doesn't operate in).
2. Investigation: Use Amazon Detective (linked to GuardDuty) to visualize the timeline of API calls made by the IAM User.
3. Mitigation: Rotate the credentials for the user and update the IAM policy to restrict access to specific IP ranges.

Checkpoint Questions

1. Does Amazon GuardDuty require you to enable VPC Flow Logs manually in your account to function?
   (Answer: No, it pulls data directly from AWS backend logs without requiring manual log activation.)
2. Which service would you use to find software vulnerabilities (CVEs) within a container image?
   (Answer: Amazon Inspector.)
3. What is the difference between a "Managed Rule" and a "Custom Rule" in AWS Config?
   (Answer: Managed rules are pre-built by AWS; Custom rules use Lambda functions for user-defined logic.)
4. How does IAM Access Analyzer help with the principle of Least Privilege?
   (Answer: It generates IAM policies based on CloudTrail access logs to ensure users only have permissions they actually use.)

Muddy Points & Cross-Refs

• GuardDuty vs. Macie: Students often confuse these. GuardDuty is for threats (behavior); Macie is for data (identifying PII/sensitive info in S3).
• Regionality: Remember that GuardDuty, Inspector, and Config are Regional. To have a global view, you must enable them in all regions and use Security Hub or Config Aggregators to centralize data.
• Logs vs. Findings: Logs (CloudTrail) are raw data; Findings (GuardDuty/Inspector) are the "so what?" — the actionable intelligence derived from those logs.

Comparison Tables