AWS Security | CyberHub

☀ Shared Responsibility Model & AWS Fundamentals

The AWS Shared Responsibility Model is the single most important concept to understand before deploying anything in AWS. Misunderstanding it is the root cause of the majority of cloud security breaches. AWS is responsible for the security of the cloud — the underlying hardware, global infrastructure, Availability Zones, and physical facilities. You are responsible for security in the cloud — everything you build, configure, and deploy on top.

AWS Responsibility (Security OF the Cloud)	Customer Responsibility (Security IN the Cloud)
Physical data center security and access	IAM users, roles, policies, and permissions
Global network infrastructure and hardware	Operating system patching on EC2 instances
Hypervisor and virtualization layer	Application security and code
Managed service underlying infrastructure (RDS engine, Lambda runtime)	Data classification, encryption, and access control
Availability Zones and Region redundancy	VPC configuration, security groups, NACLs
AWS service availability and SLAs	Incident response and forensics

Root Account Protection

The AWS root account has unlimited access to everything and cannot be restricted by IAM policies. It must be locked down immediately after account creation.

Enable hardware MFA (YubiKey) on the root account immediately
Create an admin IAM user for daily operations — never use root
Store root credentials in an offline, physical safe
Set up a root account usage CloudWatch alarm
Remove all root account access keys (they should not exist)

AWS Organizations & Multi-Account Governance

Large enterprises use AWS Organizations to manage many AWS accounts under a single governance umbrella. This is the recommended pattern for production workloads.

Separate accounts by environment: dev, staging, production
Use Service Control Policies (SCPs) to set guardrails at the OU level
Centralize security tooling in a dedicated Security account
Use a Log Archive account for immutable CloudTrail storage
AWS Control Tower automates landing zone setup

Common Misconception

Many developers believe that because AWS is "secure," their application is automatically secure. AWS handles the physical rack — you are still fully responsible for every IAM policy, every S3 bucket ACL, and every security group rule you configure.

🔑 IAM Security

AWS Identity and Access Management (IAM) is the foundation of all AWS security. Every API call in AWS is authenticated and authorized through IAM. Getting IAM right — applying least privilege, avoiding long-lived credentials, and using roles over users — is the highest-leverage security investment you can make in AWS.

IAM Roles vs Users

IAM users have permanent credentials (access keys) that can be leaked. IAM roles provide temporary credentials via STS and are the preferred mechanism for everything except human console access.

Use IAM roles for all EC2 instances (instance profiles)
Use IAM roles for Lambda, ECS tasks, and Glue jobs
Use cross-account roles instead of shared access keys
Rotate and audit human user access keys regularly
Prefer SSO/identity federation for human access

Advanced IAM Controls

Beyond basic policies, AWS provides several mechanisms to add layers of control and prevent privilege escalation across complex organizations.

Permission Boundaries: cap the maximum permissions a role can ever have
Service Control Policies: org-level guardrails applied to accounts/OUs
IAM Access Analyzer: finds externally accessible resources and unused permissions
IAM Conditions: restrict by MFA, IP, time, source VPC, and more
IAM Roles Anywhere: extend roles to on-prem workloads

Minimal IAM Policy Example

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadSpecificS3Bucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-app-bucket",
        "arn:aws:s3:::my-app-bucket/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "us-east-1"
        },
        "Bool": {
          "aws:SecureTransport": "true"
        }
      }
    }
  ]
}

Common IAM Mistakes

Avoid these patterns that introduce privilege escalation and excessive access:

Using Action: "*" or Resource: "*" — always be specific
Attaching AdministratorAccess to application roles
Embedding access keys in source code or Docker images
Not enabling MFA for human IAM users
Ignoring IAM Access Analyzer findings

Least Privilege IAM Roles Permission Boundaries SCPs Access Analyzer

🌐 Network Security in AWS

AWS network security is built around the Virtual Private Cloud (VPC). A well-designed VPC with proper subnet segmentation, security groups, and flow logging is essential for protecting workloads from lateral movement and external threats.

VPC Design Principles

A secure VPC separates public-facing resources from internal workloads using subnet tiers and enforces strict routing rules.

Public subnets: only load balancers and NAT Gateways
Private subnets: application servers and databases
Use multiple Availability Zones for resilience
Enable VPC Flow Logs to S3 or CloudWatch for traffic analysis
Use VPC Endpoints to access AWS services without internet traversal
AWS PrivateLink for accessing third-party SaaS privately

AWS WAF & DDoS Protection

AWS provides layered DDoS and web application attack mitigation through managed services at the edge and application layers.

AWS Shield Standard: automatic DDoS protection included for free
AWS Shield Advanced: enhanced DDoS with 24/7 DRT access ($3,000/mo)
AWS WAF: OWASP rules, rate limiting, IP reputation lists
Deploy WAF on CloudFront, ALB, API Gateway, or AppSync
Use AWS Managed Rules for rapid baseline protection
Transit Gateway for centralized security inspection across VPCs

Feature	Security Groups	Network ACLs (NACLs)
State	Stateful — return traffic automatic	Stateless — must allow inbound AND outbound explicitly
Scope	Applied to ENI / instance level	Applied at the subnet level
Rules	Allow rules only (implicit deny all)	Allow and Deny rules; evaluated in order by rule number
Default behavior	Deny all inbound, allow all outbound	Allow all inbound and outbound (default NACL)
Best for	Fine-grained instance-level control	Blocking specific IPs or CIDRs at subnet boundary
Use case	Primary network security control	Secondary defense; blocking known bad actors

🔎 Threat Detection & Monitoring

AWS provides a comprehensive suite of native security monitoring services. Used together, they create overlapping layers of detection covering account-level threats, resource misconfigurations, and data exposure risks.

Service	What It Detects	Cost Model
Amazon GuardDuty	Compromised EC2/credentials, crypto mining, port scanning, DNS exfiltration, unusual API activity, EKS/RDS/Lambda threats	Per GB of analyzed logs (CloudTrail, VPC Flow Logs, DNS); ~$1–4/account/month at low volume
AWS CloudTrail	All API calls across every AWS service — who did what, when, from where; critical for forensics and compliance	One trail free per region; additional trails and data events billed per 100K events
AWS Security Hub	Aggregated findings from GuardDuty, Inspector, Macie, IAM Access Analyzer; compliance checks against CIS, PCI, NIST	Per finding ingested; first 10K findings free; ~$0.001/finding thereafter
Amazon Macie	Sensitive data discovery in S3 (PII, PHI, credentials, financial data); bucket policy misconfigurations	Per GB of S3 data scanned; per S3 bucket evaluated monthly
AWS Config	Resource configuration compliance over time; drift detection; custom rules via Lambda or managed rules	Per configuration item recorded and per rule evaluation
Amazon Detective	Security investigation graph; correlates GuardDuty findings with VPC flow, CloudTrail; behavioral baselines	Per GB of data ingested from connected services

GuardDuty Finding Types

CryptoCurrency: EC2 instance communicating with known mining pools
Backdoor: EC2 performing C2 beaconing or DDoS participation
UnauthorizedAccess: credentials used from unusual geography
Recon: port scanning originating from your EC2 instances
CredentialAccess: unusual calls to IAM or STS from compromised role

CloudTrail Best Practices

Enable multi-region trail to capture all regions (including unused ones)
Enable CloudTrail log file validation (integrity hashing)
Store logs in a dedicated Log Archive account with S3 Object Lock
Enable data events for S3 and Lambda if compliance requires it
Set up CloudWatch alarms on critical API calls (root usage, SCP changes)

✅ AWS Security Best Practices

Achieving a strong AWS security posture is not a single action but a continuous program. The following checklist covers the highest-priority controls drawn from the CIS AWS Foundations Benchmark and AWS Security Hub standards.

Identity & Access Hardening

Enable MFA on root account and all IAM users
Delete or rotate all IAM access keys older than 90 days
Enable IAM Access Analyzer in every region
Apply SCPs to prevent disabling GuardDuty or CloudTrail
Enforce permission boundaries on all developer roles
Use AWS SSO / IAM Identity Center for federated human access

Data & Storage Protection

Enable S3 Block Public Access at the account level
Enable S3 default encryption (SSE-S3 or SSE-KMS)
Enable RDS encryption at rest and in transit (force SSL)
Use AWS KMS for customer-managed keys on sensitive data
Enable EBS default encryption for all new volumes
Enable S3 Versioning and Object Lock for critical data

Network & Detection

Enable GuardDuty in all regions, including unused ones
Enable Security Hub and connect GuardDuty, Inspector, Macie
Enable multi-region CloudTrail with log file validation
Use VPC Endpoints for S3 and DynamoDB to avoid internet exposure
Enable VPC Flow Logs for all VPCs
Run AWS Trusted Advisor Security checks weekly

Top AWS Breach Root Cause

80% of AWS security breaches involve misconfigured IAM policies (overpermissioned roles, leaked access keys) or publicly exposed S3 buckets. Before optimizing anything else, ensure your IAM follows least privilege and that no S3 buckets allow public access. These two controls alone prevent the majority of real-world AWS incidents.

CIS AWS Benchmark Security Hub AWS KMS S3 Block Public Access VPC Endpoints Trusted Advisor