Opening Framing
Virtual machines remain the workhorse of cloud computing. Despite the rise of containers and serverless, most organizations still run significant workloads on EC2 instances, Azure VMs, or Google Compute Engine. These instances inherit the full complexity of operating system security—patching, hardening, access control, monitoring—with added cloud-specific considerations like instance metadata, IAM roles, and image management.
The shared responsibility model places OS-level security squarely on you. The cloud provider secures the hypervisor and physical infrastructure, but everything above that—the operating system, runtime, applications, and data—is your responsibility. A misconfigured instance, unpatched vulnerability, or compromised image can expose your entire environment.
This week covers instance hardening, secure image management, patching strategies, instance metadata security, and compute monitoring. You'll learn to build and maintain secure compute environments that resist both external attacks and insider threats.
Key insight: Immutable infrastructure—replacing instances rather than patching them—transforms security from reactive to proactive.
1) Instance Hardening Fundamentals
Hardening reduces attack surface by removing unnecessary components and configuring secure defaults:
Hardening Principles:
ATTACK SURFACE REDUCTION:
┌─────────────────────────────────────────────────────────────┐
│ Default installation = Maximum attack surface │
│ Hardened instance = Minimum necessary functionality │
│ │
│ Remove: │
│ - Unnecessary packages and services │
│ - Development tools (compilers, debuggers) │
│ - Unnecessary user accounts │
│ - Sample applications and documentation │
│ - Unused network protocols │
│ │
│ Disable: │
│ - Unused network services │
│ - Unnecessary kernel modules │
│ - USB/removable media (if not needed) │
│ - IPv6 (if not used) │
└─────────────────────────────────────────────────────────────┘
DEFENSE IN DEPTH LAYERS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Cloud Layer: Security Groups, NACLs, VPC │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ OS Layer: Firewall, SELinux/AppArmor, Hardening│ │ │
│ │ │ ┌─────────────────────────────────────────────┐ │ │ │
│ │ │ │ Application Layer: WAF, Input Validation │ │ │ │
│ │ │ │ ┌─────────────────────────────────────────┐ │ │ │ │
│ │ │ │ │ Data Layer: Encryption, Access Control │ │ │ │ │
│ │ │ │ └─────────────────────────────────────────┘ │ │ │ │
│ │ │ └─────────────────────────────────────────────┘ │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Each layer provides independent protection │
└─────────────────────────────────────────────────────────────┘CIS Benchmarks:
CIS Benchmarks Overview:
WHAT ARE CIS BENCHMARKS:
┌─────────────────────────────────────────────────────────────┐
│ - Industry-standard security configuration guidelines │
│ - Developed by Center for Internet Security │
│ - Available for OSes, cloud platforms, applications │
│ - Regularly updated │
│ - Free to download and use │
│ │
│ Available Benchmarks: │
│ - CIS Amazon Linux 2 Benchmark │
│ - CIS Ubuntu Linux Benchmark │
│ - CIS Red Hat Enterprise Linux Benchmark │
│ - CIS Windows Server Benchmark │
│ - CIS Amazon Web Services Foundations Benchmark │
│ - CIS Microsoft Azure Foundations Benchmark │
│ - CIS Google Cloud Platform Benchmark │
└─────────────────────────────────────────────────────────────┘
CIS BENCHMARK LEVELS:
┌─────────────────────────────────────────────────────────────┐
│ Level 1: │
│ - Basic security controls │
│ - Minimal performance impact │
│ - Should be applied to all systems │
│ │
│ Level 2: │
│ - Defense in depth │
│ - May impact functionality │
│ - For high-security environments │
│ │
│ STIG Profile: │
│ - Most restrictive │
│ - Government/military requirements │
│ - May significantly impact usability │
└─────────────────────────────────────────────────────────────┘
SAMPLE CIS CONTROLS (Linux):
┌─────────────────────────────────────────────────────────────┐
│ 1.1 Filesystem Configuration │
│ - Disable unused filesystems (cramfs, freevxfs, etc.) │
│ - Set nodev,nosuid,noexec on /tmp │
│ - Ensure sticky bit on world-writable directories │
│ │
│ 1.4 Secure Boot Settings │
│ - Set bootloader password │
│ - Require authentication for single-user mode │
│ │
│ 3.4 Network Configuration │
│ - Disable IP forwarding │
│ - Disable source routing │
│ - Enable TCP SYN cookies │
│ │
│ 4.1 Configure Logging │
│ - Enable auditd │
│ - Configure log rotation │
│ - Send logs to remote server │
│ │
│ 5.2 SSH Configuration │
│ - Disable root login │
│ - Use SSH protocol 2 │
│ - Set strong ciphers and MACs │
│ - Configure idle timeout │
└─────────────────────────────────────────────────────────────┘Linux Hardening Checklist:
Linux Hardening Commands:
SSH HARDENING (/etc/ssh/sshd_config):
┌─────────────────────────────────────────────────────────────┐
│ PermitRootLogin no │
│ PasswordAuthentication no │
│ PubkeyAuthentication yes │
│ X11Forwarding no │
│ MaxAuthTries 3 │
│ ClientAliveInterval 300 │
│ ClientAliveCountMax 2 │
│ AllowUsers ec2-user admin │
│ Protocol 2 │
│ Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com │
│ MACs hmac-sha2-512,hmac-sha2-256 │
└─────────────────────────────────────────────────────────────┘
KERNEL HARDENING (/etc/sysctl.conf):
┌─────────────────────────────────────────────────────────────┐
│ # Disable IP forwarding │
│ net.ipv4.ip_forward = 0 │
│ │
│ # Disable source routing │
│ net.ipv4.conf.all.accept_source_route = 0 │
│ │
│ # Enable SYN cookies │
│ net.ipv4.tcp_syncookies = 1 │
│ │
│ # Disable ICMP redirects │
│ net.ipv4.conf.all.accept_redirects = 0 │
│ net.ipv4.conf.all.send_redirects = 0 │
│ │
│ # Enable address space layout randomization │
│ kernel.randomize_va_space = 2 │
│ │
│ # Restrict core dumps │
│ fs.suid_dumpable = 0 │
└─────────────────────────────────────────────────────────────┘
USER AND ACCESS:
┌─────────────────────────────────────────────────────────────┐
│ # Remove unnecessary users │
│ userdel games │
│ userdel ftp │
│ │
│ # Set password policies │
│ # /etc/login.defs │
│ PASS_MAX_DAYS 90 │
│ PASS_MIN_DAYS 7 │
│ PASS_WARN_AGE 14 │
│ │
│ # Lock inactive accounts │
│ useradd -D -f 30 │
│ │
│ # Restrict su command │
│ # /etc/pam.d/su │
│ auth required pam_wheel.so use_uid │
└─────────────────────────────────────────────────────────────┘
SERVICE HARDENING:
┌─────────────────────────────────────────────────────────────┐
│ # Disable unnecessary services │
│ systemctl disable cups │
│ systemctl disable avahi-daemon │
│ systemctl disable rpcbind │
│ systemctl disable nfs-server │
│ │
│ # List enabled services │
│ systemctl list-unit-files --state=enabled │
│ │
│ # Remove unnecessary packages │
│ yum remove telnet-server rsh-server │
└─────────────────────────────────────────────────────────────┘Key insight: Hardening should be automated and applied to images, not manually performed on running instances.
2) Golden Image Management
Golden images provide consistent, secure, pre-configured base images for all instances:
Golden Image Concept:
WHAT IS A GOLDEN IMAGE:
┌─────────────────────────────────────────────────────────────┐
│ A pre-configured, security-hardened machine image that │
│ serves as the standard base for all instances. │
│ │
│ Contains: │
│ - Hardened operating system │
│ - Security tools and agents │
│ - Approved software packages │
│ - Standardized configurations │
│ - Logging and monitoring setup │
│ │
│ Benefits: │
│ - Consistent security baseline │
│ - Faster deployment │
│ - Reduced configuration drift │
│ - Easier compliance │
│ - Known-good state for recovery │
└─────────────────────────────────────────────────────────────┘
GOLDEN IMAGE PIPELINE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Base │───►│ Build │───►│ Test │ │
│ │ AMI │ │ Hardening│ │ Security │ │
│ └──────────┘ └──────────┘ └────┬─────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Deploy │◄───│ Approve │◄───│ Scan │ │
│ │ to Prod │ │ │ │ Vulns │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ Automated pipeline ensures every image meets standards │
└─────────────────────────────────────────────────────────────┘Image Building with EC2 Image Builder:
EC2 Image Builder:
COMPONENTS:
┌─────────────────────────────────────────────────────────────┐
│ Image Recipe: │
│ - Base image (Amazon Linux 2, Ubuntu, etc.) │
│ - Components to install and configure │
│ - Tests to run │
│ │
│ Build Components: │
│ - Install packages │
│ - Apply configurations │
│ - Run hardening scripts │
│ - Install agents (CloudWatch, SSM, etc.) │
│ │
│ Test Components: │
│ - Verify configurations │
│ - Run security scans │
│ - Validate functionality │
│ │
│ Infrastructure Configuration: │
│ - Instance type for builds │
│ - VPC/subnet for builds │
│ - IAM role │
│ │
│ Distribution Settings: │
│ - Target regions │
│ - AMI sharing settings │
│ - Launch permissions │
└─────────────────────────────────────────────────────────────┘
SAMPLE BUILD COMPONENT (YAML):
name: HardenLinux
description: Apply CIS Level 1 hardening
schemaVersion: 1.0
phases:
- name: build
steps:
- name: DisableUnusedFilesystems
action: ExecuteBash
inputs:
commands:
- |
echo "install cramfs /bin/true" >> /etc/modprobe.d/CIS.conf
echo "install freevxfs /bin/true" >> /etc/modprobe.d/CIS.conf
echo "install jffs2 /bin/true" >> /etc/modprobe.d/CIS.conf
echo "install hfs /bin/true" >> /etc/modprobe.d/CIS.conf
echo "install hfsplus /bin/true" >> /etc/modprobe.d/CIS.conf
- name: ConfigureSSH
action: ExecuteBash
inputs:
commands:
- |
sed -i 's/#PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
echo "MaxAuthTries 3" >> /etc/ssh/sshd_config
- name: InstallSecurityTools
action: ExecuteBash
inputs:
commands:
- yum install -y aide
- aide --init
- mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
- name: validate
steps:
- name: ValidateSSH
action: ExecuteBash
inputs:
commands:
- grep "PermitRootLogin no" /etc/ssh/sshd_config
- grep "PasswordAuthentication no" /etc/ssh/sshd_configImage Security Scanning:
Image Scanning:
AMAZON INSPECTOR FOR EC2:
┌─────────────────────────────────────────────────────────────┐
│ Automated vulnerability assessment: │
│ - CVE scanning │
│ - CIS benchmark checking │
│ - Network reachability analysis │
│ - Agentless (SSM-based) or agent-based │
│ │
│ Integration: │
│ - Scan on schedule or on-demand │
│ - Findings in Security Hub │
│ - EventBridge for automation │
│ - Integration with Image Builder │
└─────────────────────────────────────────────────────────────┘
SCANNING IN IMAGE PIPELINE:
┌─────────────────────────────────────────────────────────────┐
│ 1. Build image │
│ 2. Launch test instance from image │
│ 3. Run Inspector scan │
│ 4. Check for critical/high vulnerabilities │
│ 5. If pass: Approve image │
│ If fail: Reject, fix, rebuild │
│ 6. Tag approved image with scan date │
└─────────────────────────────────────────────────────────────┘
VULNERABILITY THRESHOLDS:
┌─────────────────────────────────────────────────────────────┐
│ Example Policy: │
│ │
│ Critical vulnerabilities: 0 allowed │
│ High vulnerabilities: 0 allowed │
│ Medium vulnerabilities: < 5 allowed │
│ Low vulnerabilities: Informational only │
│ │
│ Age Policy: │
│ - Images older than 30 days: Must be rebuilt │
│ - Images with new critical CVE: Immediate rebuild │
└─────────────────────────────────────────────────────────────┘
THIRD-PARTY TOOLS:
┌─────────────────────────────────────────────────────────────┐
│ - Trivy (open source, fast, comprehensive) │
│ - Anchore (policy-based scanning) │
│ - Qualys/Tenable/Rapid7 (enterprise scanners) │
│ - Snyk (developer-focused) │
└─────────────────────────────────────────────────────────────┘Key insight: Never trust a public AMI. Build your own golden images from trusted base images with your security controls.
3) Patch Management
Keeping systems patched is critical but challenging at scale. Cloud enables new patching strategies:
Patching Strategies:
TRADITIONAL PATCHING (In-Place):
┌─────────────────────────────────────────────────────────────┐
│ Process: │
│ 1. Scan for missing patches │
│ 2. Test patches in lower environment │
│ 3. Schedule maintenance window │
│ 4. Apply patches to running instances │
│ 5. Reboot if required │
│ 6. Verify systems operational │
│ │
│ Challenges: │
│ - Downtime during patching │
│ - Risk of patch failures │
│ - Configuration drift over time │
│ - Difficult to roll back │
│ - Scaling to many instances │
└─────────────────────────────────────────────────────────────┘
IMMUTABLE INFRASTRUCTURE (Replace):
┌─────────────────────────────────────────────────────────────┐
│ Process: │
│ 1. Build new golden image with patches │
│ 2. Test new image │
│ 3. Deploy new instances from new image │
│ 4. Shift traffic to new instances │
│ 5. Terminate old instances │
│ │
│ Benefits: │
│ - No configuration drift │
│ - Clean, known-good state │
│ - Easy rollback (keep old image) │
│ - No patching downtime (rolling deployment) │
│ - Consistent across all instances │
│ │
│ Requirements: │
│ - Stateless application design │
│ - External state storage (databases, S3) │
│ - Automated deployment pipelines │
│ - Infrastructure as code │
└─────────────────────────────────────────────────────────────┘
COMPARISON:
┌────────────────────┬─────────────────┬─────────────────────┐
│ Aspect │ In-Place │ Immutable │
├────────────────────┼─────────────────┼─────────────────────┤
│ Downtime │ Per instance │ Zero (rolling) │
│ Consistency │ Drifts over time│ Always identical │
│ Rollback │ Difficult │ Easy (old image) │
│ Complexity │ Lower initially │ Higher initially │
│ Audit │ Harder │ Easier (image hash) │
│ Best For │ Stateful/legacy │ Cloud-native apps │
└────────────────────┴─────────────────┴─────────────────────┘AWS Systems Manager Patch Manager:
AWS Systems Manager Patch Manager:
COMPONENTS:
┌─────────────────────────────────────────────────────────────┐
│ Patch Baseline: │
│ - Defines which patches are approved │
│ - Auto-approve rules (e.g., critical after 7 days) │
│ - Exception lists │
│ - OS-specific baselines │
│ │
│ Patch Group: │
│ - Tag-based instance grouping │
│ - Associates instances with baseline │
│ - Enables different policies per environment │
│ │
│ Maintenance Window: │
│ - Scheduled time for patching │
│ - Target patch groups │
│ - Run Command or Automation │
└─────────────────────────────────────────────────────────────┘
SAMPLE PATCH BASELINE:
{
"Name": "SecureLinuxBaseline",
"OperatingSystem": "AMAZON_LINUX_2",
"ApprovalRules": {
"PatchRules": [
{
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "SEVERITY",
"Values": ["Critical", "Important"]
},
{
"Key": "CLASSIFICATION",
"Values": ["Security"]
}
]
},
"ApproveAfterDays": 0,
"ComplianceLevel": "CRITICAL"
},
{
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "SEVERITY",
"Values": ["Medium", "Low"]
}
]
},
"ApproveAfterDays": 7,
"ComplianceLevel": "MEDIUM"
}
]
}
}
PATCHING WORKFLOW:
┌─────────────────────────────────────────────────────────────┐
│ 1. Scan: Identify missing patches │
│ aws ssm send-command --document-name AWS-RunPatchBaseline│
│ --targets "Key=tag:Environment,Values=Production" │
│ --parameters "Operation=Scan" │
│ │
│ 2. Review: Check compliance in Systems Manager │
│ │
│ 3. Install: Apply patches in maintenance window │
│ aws ssm send-command --document-name AWS-RunPatchBaseline│
│ --parameters "Operation=Install" │
│ │
│ 4. Verify: Re-scan to confirm compliance │
└─────────────────────────────────────────────────────────────┘Patch Prioritization:
Vulnerability Prioritization:
CVSS SCORE CATEGORIES:
┌─────────────────────────────────────────────────────────────┐
│ Critical (9.0-10.0): Patch immediately │
│ High (7.0-8.9): Patch within 24-72 hours │
│ Medium (4.0-6.9): Patch within 30 days │
│ Low (0.1-3.9): Patch in next maintenance cycle │
└─────────────────────────────────────────────────────────────┘
BEYOND CVSS - CONTEXTUAL PRIORITIZATION:
┌─────────────────────────────────────────────────────────────┐
│ Consider: │
│ │
│ Exploitability: │
│ - Is there a known exploit in the wild? │
│ - Is it being actively exploited? │
│ - CISA KEV (Known Exploited Vulnerabilities) catalog │
│ │
│ Exposure: │
│ - Is the vulnerable component internet-facing? │
│ - Is it behind multiple security layers? │
│ - Can it be reached by attackers? │
│ │
│ Impact: │
│ - What data/systems could be compromised? │
│ - What's the business impact? │
│ - Is it a critical production system? │
│ │
│ Compensating Controls: │
│ - Can other controls mitigate the risk? │
│ - WAF rules? Network isolation? IAM restrictions? │
└─────────────────────────────────────────────────────────────┘
PATCH SLA EXAMPLE:
┌─────────────────────────────────────────────────────────────┐
│ Category │ Internet-Facing │ Internal Only │
├───────────────────────┼─────────────────┼───────────────────┤
│ Critical + Exploited │ 24 hours │ 48 hours │
│ Critical │ 72 hours │ 7 days │
│ High │ 7 days │ 14 days │
│ Medium │ 30 days │ 30 days │
│ Low │ 90 days │ 90 days │
└───────────────────────┴─────────────────┴───────────────────┘Key insight: Immutable infrastructure is the most secure patching strategy. Replace instances with new, patched images rather than patching in place.
4) Instance Metadata Security
The instance metadata service is a powerful feature that can be exploited if not properly secured:
Instance Metadata Service (IMDS):
WHAT IS IMDS:
┌─────────────────────────────────────────────────────────────┐
│ Special endpoint at 169.254.169.254 │
│ │
│ Provides: │
│ - Instance ID, type, region │
│ - Network configuration │
│ - IAM role credentials (temporary) │
│ - User data scripts │
│ - Public keys │
│ │
│ Access: │
│ curl http://169.254.169.254/latest/meta-data/ │
│ curl http://169.254.169.254/latest/meta-data/iam/ │
│ security-credentials/role-name │
└─────────────────────────────────────────────────────────────┘
IMDS SECURITY RISK:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Attacker ──► SSRF Vulnerability ──► Web Application │
│ │ │
│ ▼ │
│ ┌────────────────┐ │
│ │ Request to │ │
│ │ 169.254.169.254│ │
│ └───────┬────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────┐ │
│ │ IAM Credentials│ │
│ │ Returned │ │
│ └───────┬────────┘ │
│ │ │
│ ▼ │
│ Attacker uses credentials │
│ to access AWS resources │
│ │
│ This is how the Capital One breach worked │
└─────────────────────────────────────────────────────────────┘IMDSv2 - Session-Based Protection:
IMDSv2 (Instance Metadata Service v2):
HOW IT WORKS:
┌─────────────────────────────────────────────────────────────┐
│ 1. Application requests session token via PUT request │
│ │
│ TOKEN=`curl -X PUT │
│ "http://169.254.169.254/latest/api/token" │
│ -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` │
│ │
│ 2. Application includes token in subsequent requests │
│ │
│ curl http://169.254.169.254/latest/meta-data/ │
│ -H "X-aws-ec2-metadata-token: $TOKEN" │
│ │
│ Why This Helps: │
│ - SSRF typically can only make GET requests │
│ - Token requires PUT request │
│ - Token has hop limit (doesn't traverse proxies) │
│ - Token expires (TTL) │
└─────────────────────────────────────────────────────────────┘
ENFORCING IMDSv2:
┌─────────────────────────────────────────────────────────────┐
│ At Instance Launch: │
│ aws ec2 run-instances │
│ --metadata-options │
│ "HttpTokens=required,HttpEndpoint=enabled" │
│ │
│ Modify Existing Instance: │
│ aws ec2 modify-instance-metadata-options │
│ --instance-id i-1234567890abcdef0 │
│ --http-tokens required │
│ │
│ Account-Level Default (recommended): │
│ aws ec2 modify-instance-metadata-defaults │
│ --http-tokens required │
│ --http-put-response-hop-limit 1 │
│ │
│ In Launch Template: │
│ MetadataOptions: │
│ HttpTokens: required │
│ HttpEndpoint: enabled │
│ HttpPutResponseHopLimit: 1 │
└─────────────────────────────────────────────────────────────┘
ADDITIONAL IMDS PROTECTIONS:
┌─────────────────────────────────────────────────────────────┐
│ 1. Disable IMDS if not needed: │
│ --metadata-options "HttpEndpoint=disabled" │
│ │
│ 2. Use iptables to restrict access: │
│ # Allow only root to access IMDS │
│ iptables -A OUTPUT -p tcp -d 169.254.169.254 │
│ -m owner ! --uid-owner root -j DROP │
│ │
│ 3. Limit hop count: │
│ --http-put-response-hop-limit 1 │
│ (Prevents access through containers/proxies) │
│ │
│ 4. Least privilege IAM roles: │
│ Even if credentials stolen, limit what they can do │
└─────────────────────────────────────────────────────────────┘
AWS CONFIG RULE:
┌─────────────────────────────────────────────────────────────┐
│ Rule: ec2-imdsv2-check │
│ │
│ Checks that all EC2 instances require IMDSv2 │
│ Flags non-compliant instances │
│ Can trigger auto-remediation │
└─────────────────────────────────────────────────────────────┘Key insight: Always enforce IMDSv2 and use least privilege IAM roles. Defense in depth protects against SSRF exploits.
5) Compute Monitoring and Endpoint Protection
Visibility into instance behavior is essential for detecting threats and maintaining security:
Compute Monitoring:
CLOUDWATCH AGENT:
┌─────────────────────────────────────────────────────────────┐
│ Collects: │
│ - System metrics (CPU, memory, disk) │
│ - Custom metrics │
│ - Log files │
│ │
│ Security-Relevant Logs: │
│ - /var/log/secure (authentication) │
│ - /var/log/audit/audit.log (auditd) │
│ - /var/log/messages (system events) │
│ - Application logs │
│ │
│ Installation: │
│ sudo yum install amazon-cloudwatch-agent │
│ sudo /opt/aws/amazon-cloudwatch-agent/bin/ │
│ amazon-cloudwatch-agent-config-wizard │
│ sudo systemctl start amazon-cloudwatch-agent │
└─────────────────────────────────────────────────────────────┘
SYSTEMS MANAGER (SSM) AGENT:
┌─────────────────────────────────────────────────────────────┐
│ Enables: │
│ - Remote command execution (no SSH needed) │
│ - Patch management │
│ - Inventory collection │
│ - Session Manager (secure shell alternative) │
│ - Parameter Store access │
│ │
│ Security Benefits: │
│ - No inbound SSH ports needed │
│ - IAM-based access control │
│ - Full session logging │
│ - Audit trail in CloudTrail │
│ │
│ Session Manager Access: │
│ aws ssm start-session --target i-1234567890abcdef0 │
└─────────────────────────────────────────────────────────────┘
AMAZON INSPECTOR:
┌─────────────────────────────────────────────────────────────┐
│ Automated vulnerability scanning: │
│ │
│ Scans For: │
│ - Software vulnerabilities (CVEs) │
│ - Network reachability issues │
│ - Unintended network exposure │
│ │
│ Coverage: │
│ - EC2 instances (SSM agent required) │
│ - Container images (ECR) │
│ - Lambda functions │
│ │
│ Continuous Scanning: │
│ - Scans on new instance launch │
│ - Rescans when CVE database updates │
│ - Rescans on software changes │
└─────────────────────────────────────────────────────────────┘Endpoint Detection and Response:
Endpoint Protection:
AWS GUARDDUTY FOR EC2:
┌─────────────────────────────────────────────────────────────┐
│ Threat detection for EC2: │
│ │
│ Data Sources: │
│ - VPC Flow Logs │
│ - DNS logs │
│ - CloudTrail events │
│ │
│ EC2 Finding Types: │
│ - Backdoor:EC2/DenialOfService.Dns │
│ - CryptoCurrency:EC2/BitcoinTool.B │
│ - Trojan:EC2/BlackholeTraffic │
│ - UnauthorizedAccess:EC2/SSHBruteForce │
│ - Recon:EC2/PortProbeUnprotectedPort │
│ │
│ Runtime Monitoring (agent-based): │
│ - Process execution │
│ - File access │
│ - Network connections │
│ - DNS queries │
└─────────────────────────────────────────────────────────────┘
THIRD-PARTY EDR SOLUTIONS:
┌─────────────────────────────────────────────────────────────┐
│ Popular Options: │
│ - CrowdStrike Falcon │
│ - SentinelOne │
│ - Carbon Black │
│ - Microsoft Defender for Cloud │
│ │
│ Capabilities: │
│ - Real-time threat detection │
│ - Behavioral analysis │
│ - Automated response │
│ - Threat hunting │
│ - Forensic investigation │
│ │
│ Deployment: │
│ - Install agent in golden image │
│ - Connect to cloud management console │
│ - Configure detection policies │
│ - Integrate with SIEM │
└─────────────────────────────────────────────────────────────┘
HOST-BASED SECURITY CONTROLS:
┌─────────────────────────────────────────────────────────────┐
│ File Integrity Monitoring (FIM): │
│ - AIDE (Advanced Intrusion Detection Environment) │
│ - OSSEC │
│ - Tripwire │
│ │
│ # AIDE example │
│ aide --init │
│ aide --check │
│ │
│ Monitors: │
│ - Critical system files │
│ - Configuration files │
│ - Binary changes │
│ - Permission changes │
└─────────────────────────────────────────────────────────────┘
AUDITD FOR LINUX:
┌─────────────────────────────────────────────────────────────┐
│ System call auditing: │
│ │
│ Key Rules: │
│ # Monitor file access │
│ -w /etc/passwd -p wa -k identity │
│ -w /etc/shadow -p wa -k identity │
│ │
│ # Monitor command execution │
│ -a always,exit -F arch=b64 -S execve -k exec │
│ │
│ # Monitor network connections │
│ -a always,exit -F arch=b64 -S connect -k network │
│ │
│ Integration: │
│ - Send to CloudWatch Logs │
│ - Parse with SIEM │
│ - Alert on suspicious activity │
└─────────────────────────────────────────────────────────────┘Key insight: Layer monitoring from cloud-native services through OS-level auditing to endpoint detection for comprehensive visibility.
Real-World Context
Case Study: Log4Shell Response
When the Log4Shell vulnerability (CVE-2021-44228) was disclosed in December 2021, organizations with mature compute security practices responded effectively. Those using immutable infrastructure rebuilt golden images with patched Log4j within hours and redeployed all affected instances. Organizations with good inventory knew exactly which instances ran vulnerable Java applications. Those with runtime monitoring detected exploitation attempts immediately. In contrast, organizations relying on traditional patching struggled to identify vulnerable systems and took weeks to fully remediate. The incident demonstrated the security value of immutable infrastructure, comprehensive inventory, and defense in depth.
Case Study: Cryptomining via Compromised AMIs
Attackers have published community AMIs containing cryptomining malware that activates after instance launch. The malware runs quietly, consuming resources and generating cryptocurrency for attackers. Victims pay for the compute costs. Detection requires monitoring for unexpected CPU usage, unknown processes, and suspicious network connections to mining pools. Prevention requires never using untrusted community AMIs—always build from known-good sources (official Amazon, verified publishers) or build your own golden images.
Compute Security Checklist:
Compute Security Best Practices:
IMAGE MANAGEMENT:
□ Build golden images from trusted base images
□ Automate image building with EC2 Image Builder
□ Apply CIS benchmarks to all images
□ Scan images for vulnerabilities before deployment
□ Rebuild images at least monthly
□ Never use community AMIs in production
INSTANCE HARDENING:
□ SSH key-only authentication (no passwords)
□ Disable root SSH login
□ Remove unnecessary packages and services
□ Configure host firewall (iptables/firewalld)
□ Enable SELinux or AppArmor
□ Apply kernel hardening (sysctl)
PATCHING:
□ Define patch SLAs by severity
□ Use immutable infrastructure where possible
□ Automate patching with Systems Manager
□ Monitor patch compliance
□ Subscribe to security advisories
METADATA SECURITY:
□ Enforce IMDSv2 account-wide
□ Set hop limit to 1
□ Use least privilege IAM roles
□ Consider disabling IMDS if not needed
ACCESS:
□ Use Session Manager instead of SSH
□ No direct internet access to instances
□ Bastion hosts in separate security group
□ MFA for privileged access
□ Regular access reviews
MONITORING:
□ CloudWatch agent for logs and metrics
□ Inspector for vulnerability scanning
□ GuardDuty for threat detection
□ Auditd for system call logging
□ File integrity monitoring
□ EDR solution for endpoint protectionDefense in depth at the compute layer combines hardening, patching, monitoring, and access control for comprehensive protection.
Guided Lab: Golden Image Pipeline
In this lab, you'll build an automated golden image pipeline with security scanning.
Lab Environment:
- AWS account with EC2, SSM, and Image Builder access
- AWS CLI or Console
- Linux shell access
Exercise Steps:
- Create EC2 Image Builder pipeline
- Add hardening component (SSH, kernel settings)
- Add security agents (CloudWatch, SSM)
- Add test component (verify hardening)
- Build initial image
- Launch instance from image
- Run Inspector scan
- Verify IMDSv2 enforcement
- Document security controls applied
Reflection Questions:
- How does automated image building improve security?
- What would happen if a vulnerability is found post-deployment?
- How would you ensure all instances use the latest image?
Week Outcome Check
By the end of this week, you should be able to:
- Apply CIS benchmarks to harden Linux instances
- Build secure golden images using EC2 Image Builder
- Implement vulnerability scanning in image pipelines
- Compare in-place patching vs immutable infrastructure
- Configure AWS Systems Manager for patch management
- Secure instance metadata service with IMDSv2
- Deploy compute monitoring with CloudWatch and Inspector
- Implement endpoint protection strategies
🎯 Hands-On Labs (Free & Essential)
Harden cloud compute resources and build secure VM images with hands-on practice.
💻 TryHackMe: EC2 Instance Exploitation
What you'll do: Attack and defend EC2 instances—exploit instance metadata,
IMDSv1 vulnerabilities, and hardening techniques.
Why it matters: Instance metadata is a common entry point in cloud
breaches.
Time estimate: 2-3 hours
🛠️ AWS Skill Builder: EC2 Image Management
What you'll do: Build secure AMIs with AWS Systems Manager and automate
patching workflows.
Why it matters: Golden images are only secure if the build pipeline is
secure.
Time estimate: 2-3 hours
☁️ Microsoft Learn: Azure VM Security
What you'll do: Secure Azure VMs with disk encryption, update management, and
security baselines.
Why it matters: Multi-cloud skills are essential—Azure VM security differs
from AWS.
Time estimate: 2-3 hours
💡 Lab Strategy: Always use IMDSv2 (session-oriented) instead of IMDSv1—it prevents SSRF attacks on instance metadata.
Resources
Lab
Complete the following lab exercises to practice compute security.