Vulnerability Management

Amazon Inspector automatically assesses applications for vulnerabilities and deviations from best practices. It scans EC2 instances, container images in ECR, and Lambda functions.

EC2 Assessments scan for network exposure, software vulnerabilities, and unintended credential exposure. Inspector analyzes the instance against Common Vulnerabilities and Exposures (CVE) databases and known misconfigurations. For example, Inspector identifies an EC2 instance running an outdated version of OpenSSL with a known remote code execution vulnerability.

ECR Container Scanning scans container images for OS and package vulnerabilities when images are pushed to ECR. Enable automated scanning so every image push triggers an assessment. Inspector identifies packages with known CVEs and provides remediation guidance.

For example, a Docker image built with python:3.9 base contains a vulnerable version of libxml2. Inspector flags the vulnerability with severity, CVE ID, and recommended upgrade path.

Lambda Function Scanning identifies vulnerable packages in Lambda deployment packages. Inspector scans package dependencies against the National Vulnerability Database.

Assessment Targets define what Inspector scans. Create target groups for different environments (production, staging) with different scan schedules and thresholds.

Findings include severity (critical, high, medium, low, informational), affected resource, vulnerability details, and remediation steps. Prioritize critical and high findings for immediate remediation. Integrate Inspector findings with Security Hub for centralized visibility.

AWS Secrets Manager protects credentials, API keys, and other secrets. It eliminates hardcoding secrets in application code and provides automatic rotation.

Secret Storage stores secrets as key-value pairs. For example, a database connection secret contains host, username, password, and engine fields. Applications retrieve secrets at runtime using the Secrets Manager SDK.

Automatic Rotation uses AWS Lambda functions to rotate secrets on a schedule. Secrets Manager has built-in rotation templates for RDS, Redshift, DocumentDB, and ElastiCache. Configure rotation every 30, 60, or 90 days.

For example, configure automatic rotation for an RDS MySQL password. Secrets Manager creates a Lambda function that generates a new password, updates the RDS instance, and updates the secret value. Applications retrieve the new password transparently using the SDK; no code changes or restarts required.

Multi-Region Secrets replicate secrets across Regions. When you update a secret in the primary Region, it automatically replicates to secondary regions. This is essential for multi-region architectures where applications in different Regions need the same database credentials.

Secret Rotation Strategies:

• Single user rotation: Rotate the password for a single database user
• Alternate user rotation: Create a second user, rotate between them, avoiding downtime
• Service-specific rotation: Use built-in templates for RDS, Redshift, etc.

Security Best Practices:

• Never store secrets in code, environment variables, or configuration files
• Use resource-based policies to control who can access secrets
• Enable CloudTrail logging for all Secrets Manager API calls
• Use encryption with customer-managed KMS keys for sensitive secrets

AWS Systems Manager Patch Manager automates the process of patching managed instances with security updates. It keeps EC2 instances and on-premises servers compliant with your patching policy.

Patch Baselines define which patches to install. AWS provides pre-configured baselines for Amazon Linux 2, Ubuntu, Windows Server, and other operating systems. Customize baselines to include or exclude specific patches, set approval rules, and define auto-approval delays.

For example, create a patch baseline for Amazon Linux 2 that auto-approves security patches after 7 days, approves critical patches immediately, and excludes patches marked as deprecated.

Patch Groups organize instances by patching requirements. Tag instances with Patch Group: Production or Patch Group: Development to apply different baselines. Production instances might receive patches after a 14-day testing period, while development instances receive patches immediately.

Maintenance Windows define when patching occurs. Schedule maintenance windows during off-peak hours (e.g., Sunday 2:00 AM) to minimize impact. Maintenance windows specify a duration, an SNS topic for notifications, and an IAM role for the patching operation.

Scan vs Install Modes:

• Scan: Reports which patches are missing without installing them. Use for compliance reporting.
• Install: Actually installs missing patches. Use during maintenance windows.

Compliance Reporting uses Systems Manager Inventory and Compliance to track patch status across all managed instances. Create dashboards showing patch compliance by instance, patch group, or region.

Automated Remediation uses State Manager to enforce patch compliance continuously. Schedule recurring associations that scan instances and install missing patches automatically.

A comprehensive vulnerability management program combines multiple AWS services into a continuous cycle of discovery, assessment, remediation, and verification.

Discovery Phase:

• AWS Config discovers all resources in your account
• Inspector scans EC2 instances, ECR images, and Lambda functions
• Macie identifies sensitive data in S3 buckets
• Resource groups organize assets by environment, application, or sensitivity

Assessment Phase:

• Inspector assigns severity scores to vulnerabilities
• Security Hub aggregates findings and calculates compliance scores
• GuardDuty detects active exploitation of vulnerabilities
• Prioritize by severity (critical first), exploitability, and data sensitivity

Remediation Phase:

• Patch Manager installs security patches during maintenance windows
• Secrets Manager rotates compromised credentials
• Systems Manager Automation remediates misconfigurations
• Inspector re-scans after remediation to verify fixes

Verification Phase:

• Config rules continuously evaluate compliance
• Inspector confirms vulnerabilities are resolved
• Security Hub tracks compliance score improvement
• CloudTrail logs all remediation actions for audit

Metrics to Track:

• Mean Time to Remediate (MTTR) for critical vulnerabilities
• Percentage of instances passing compliance checks
• Number of open critical findings over time
• Percentage of secrets rotated in the last 90 days

For example, a DevSecOps team runs Inspector weekly, triages findings in Security Hub, patches via Patch Manager in weekly maintenance windows, and tracks MTTR in a dashboard. Critical vulnerabilities must be patched within 72 hours per their policy.