Your 29-Point Framework for Enterprise Cloud Security
This assessment framework is used by our security consultants to evaluate AWS environments across Financial Services, Public Sector, Energy and Gaming industries. Each item is risk-rated to help you prioritize remediation efforts.
Note: Regulatory and compliance standards (ISO 27001, NIST 800-53, PCI-DSS, etc.) are referenced for illustration purposes. Actual applicability depends on your industry, jurisdiction and specific compliance obligations. All standards reference current versions as of January 2025 (PCI DSS v4.0, ISO 27001:2022, NIST 800-53 Rev. 5).
Check:
Root access management enabled in AWS Organizations. For standalone accounts or management accounts where this cannot be applied: root account MFA enabled, access keys deleted, used only for emergency break-glass scenarios.
Why it matters:
Root account compromise = complete AWS account takeover. Required by PCI-DSS 8.3, NIST 800-53 IA-2(1).
Assess:
Is root access management enabled? For accounts where it cannot be applied: when was root account last accessed? Are there any active root access keys?
Check:
IAM users and roles follow principle of least privilege with no overly permissive policies (e.g. *:* on resources).
Why it matters:
Lateral movement prevention. NIST 800-53 AC-6 requires least privilege access controls. EU AI Act Article 10 mandates data governance controls.
Assess:
Scan for policies with wildcard permissions. Are developers using the AdministratorAccess policy in production?
Check:
EC2, Lambda and ECS service roles are scoped to specific resources, not entire account.
Why it matters:
Compromised workload shouldn't access unrelated resources. Key for PCI-DSS Requirement 7.
Assess:
Review AssumeRole trust policies. Do Lambda functions have broader permissions than needed?
Check:
IAM access keys rotated every 90 days maximum, unused keys deactivated.
Why it matters:
Reduces window of compromise from leaked credentials. NIST 800-53 IA-5(1) requires credential management.
Assess:
Run IAM Credential Report. Any keys older than 90 days? Keys used in last 90 days?
Check:
Cross-account roles use ExternalID and MFA when accessing sensitive accounts and follow least privilege.
Why it matters:
Third-party vendor compromise shouldn't cascade to your environment.
Assess:
Review all trust relationships. Are external accounts properly validated?
Check:
No security groups allow 0.0.0.0/0 ingress on sensitive ports (22, 3389, 3306, 5432, 1433).
Why it matters:
Direct internet exposure = scanning/exploitation target. PCI-DSS 1.3 prohibits direct public access to cardholder data.
Assess:
Scan all security groups for 0.0.0.0/0 rules. Which resources are publicly accessible?
Check:
Private subnets used for databases and application tiers, public subnets only for load balancers/bastion hosts.
Why it matters:
Defense-in-depth. Breach of web tier shouldn't expose database layer. Required by NIST 800-53 SC-7.
Assess:
Are RDS instances in private subnets? Do applications traverse NAT gateways for internet access?
Check:
Egress traffic restricted to approved destinations using AWS Network Firewall, prefix lists for AWS services or third-party appliances. Default-deny egress policy in place.
Why it matters:
Unrestricted egress enables data exfiltration and command-and-control communication. NIST 800-53 SC-7 requires boundary protection including egress filtering.
Assess:
Is egress traffic filtered beyond security groups? Are workloads restricted to required AWS service endpoints via prefix lists? Can compromised instances communicate with arbitrary internet destinations?
Check:
VPC Flow Logs enabled for all VPCs, logs retained for minimum 90 days.
Why it matters:
Network forensics, anomaly detection, compliance evidence. NIST 800-53 SI-4 requires network monitoring.
Assess:
Which VPCs lack flow logging? Are logs centralized in S3/CloudWatch?
Check:
AWS WAF protecting public-facing APIs, ALBs and CloudFront distributions with OWASP Top 10 rules.
Why it matters:
Application-layer attack prevention (SQL injection, XSS, DDoS). PCI-DSS 6.6 requires WAF or code review.
Assess:
Are public endpoints protected? Which WAF rules are blocking traffic?
Check:
NACLs used only for specific use cases: blocking known malicious IPs, subnet-level quarantine during incidents or compliance requirements for explicit deny rules. Default NACLs left permissive if security groups are primary control.
Why it matters:
Dual management of security groups and NACLs creates operational complexity without proportional security benefit. NACLs should complement, not duplicate, security group rules.
Assess:
Are NACLs actively managed or left at default? If customised, is there a clear use case? Do teams understand both when troubleshooting connectivity issues?
Check:
All S3 buckets use default encryption (SSE-S3 minimum, SSE-KMS preferred), public access blocked.
Why it matters:
Data breach prevention. PCI-DSS 3.4 mandates encryption. EU AI Act Article 10 requires training data protection.
Assess:
Run S3 bucket scan. Any unencrypted buckets? Any publicly readable objects?
Check:
All RDS instances encrypted at rest using AWS KMS, automated backups encrypted.
Why it matters:
Database compromise protection. Required by PCI-DSS 3.4, GDPR Article 32.
Assess:
Are production databases encrypted? What about read replicas and snapshots?
Check:
All EBS volumes encrypted by default, including root volumes for EC2 instances.
Why it matters:
Protects data at rest on compute resources. NIST 800-53 SC-28 requires cryptographic protection.
Assess:
Scan for unencrypted volumes. Are new volumes automatically encrypted?
Check:
TLS 1.2+ enforced for all public endpoints, internal communication encrypted where sensitive data flows.
Why it matters:
Man-in-the-middle attack prevention. PCI-DSS 4.1 mandates strong cryptography for transmission.
Assess:
Check ALB/CloudFront SSL policies. Are legacy protocols (TLS 1.0/1.1) disabled?
Check:
Customer-managed KMS keys used where required: cross-account resource sharing, custom key policies, cryptographic erasure requirements or compliance mandates for key control. AWS-managed keys appropriate for single-account workloads without these requirements.
Why it matters:
CMKs provide granular control but add operational overhead. The decision should be driven by specific requirements, not default assumption. NIST 800-53 SC-12 requires key management.
Assess:
Do you have cross-account sharing, cryptographic erasure or compliance requirements that mandate CMKs? If not, are AWS-managed keys with automatic rotation sufficient?
Check:
CloudTrail enabled in all regions, logs encrypted, integrity validation enabled, centralized to security account.
Why it matters:
Audit trail for all API calls. Required by PCI-DSS 10.2, NIST 800-53 AU-2.
Assess:
Is CloudTrail enabled in all regions? Are logs tamper-proof (log file validation)?
Check:
CloudWatch alarms configured for: unauthorized API calls, IAM policy changes, security group modifications, root account usage.
Why it matters:
Real-time threat detection. Reduces dwell time from months to minutes.
Assess:
Which security events trigger alerts? Who receives notifications?
Check:
AWS Config enabled in all regions, recording all resource types, compliance rules active (CIS AWS Foundations Benchmark minimum).
Why it matters:
Continuous compliance validation, drift detection. Required for ISO 27001, SOC 2.
Assess:
Is Config tracking configuration changes? Which compliance rules are failing?
Check:
Amazon GuardDuty enabled in all regions, findings integrated with incident response workflow.
Why it matters:
AI-powered threat intelligence, detects compromised instances, reconnaissance, data exfiltration.
Assess:
Is GuardDuty active? Are findings reviewed regularly or auto-remediated?
Check:
Security logs centralized in dedicated security account, cross-account access restricted, logs retained per compliance requirements.
Why it matters:
Tamper resistance, forensic capability, compliance evidence. NIST 800-53 AU-9 requires log protection.
Assess:
Where are logs stored? Can production accounts delete security logs?
Check:
Config rules deployed for PCI-DSS, NIST 800-53, ISO 27001 as applicable.
Why it matters:
Automated compliance checking, audit evidence. Reduces manual assessment burden.
Assess:
Which compliance frameworks apply? Are Config rules aligned with controls?
Check:
Amazon Inspector scanning EC2, ECR, Lambda for CVEs and network exposure, findings remediated per SLA.
Why it matters:
Proactive vulnerability management. PCI-DSS 11.2 requires quarterly scans.
Assess:
Is Inspector enabled? What's the average time-to-remediation for critical CVEs?
Check:
AWS Backup policies configured, cross-region replication for critical data, tested recovery procedures.
Why it matters:
Business continuity, ransomware resilience. NIST 800-53 CP-9 requires information system backup.
Assess:
Are backups tested? What's the RPO/RTO for critical systems?
Check:
Documented incident response procedures for AWS-specific scenarios (compromised IAM credentials, S3 data leak, GuardDuty alerts).
Why it matters:
Reduces response time, ensures consistent handling. NIST 800-53 IR-8 requires incident response plan.
Assess:
Are runbooks AWS-specific? When were they last tested?
Check:
SageMaker endpoints and Bedrock model invocations secured with IAM/VPC controls. Training data and model artifacts access logged. Bedrock guardrails configured to prevent prompt injection and data leakage.
Why it matters:
EU AI Act Article 10 mandates data governance. Model theft = intellectual property loss. Unsecured Bedrock endpoints can expose sensitive enterprise data through prompt manipulation.
Assess:
Are ML models and Bedrock endpoints network-isolated? Can unauthorized users access training data or invoke models? Are Bedrock guardrails filtering sensitive content?
Check:
AI training datasets encrypted, versioned, access-controlled and lineage tracked for compliance.
Why it matters:
EU AI Act Article 10 requires data quality/governance for high-risk AI. Poisoned training data = compromised models.
Assess:
Can you trace training data sources? Is PII properly handled in datasets?
Check:
AWS Organizations AI services opt-out policy configured to prevent AWS from using your content to improve their AI services where required by data governance or privacy policies.
Why it matters:
By default, AWS may use content processed by certain AI services (Lex, Polly, Transcribe, etc.) to improve service quality. Organisations with sensitive data or privacy requirements should explicitly opt out.
Assess:
Is an AI services opt-out policy attached to your organisation? Does it cover all required AI services? Are there exceptions for non-sensitive workloads?
Check:
Inventory of all cryptographic algorithms in use (TLS, database encryption, application-level crypto), assessment of quantum vulnerability.
Why it matters:
NIST post-quantum standards published August 2024. NCSC recommends cryptographic agility planning NOW. Migration takes 5-10 years.
Assess:
Have you catalogued all cryptographic dependencies? Which systems use RSA/ECC that will break under quantum attacks?
Our quantum readiness assessment identifies vulnerable cryptographic implementations across your AWS estate and provides a migration roadmap to post-quantum algorithms. Most organizations underestimate the scope of this challenge.
Immediate assessment recommended
Strategic improvements needed
Focus on advanced controls
Maintain and validate continuously