Full Report
Wiz cloud security researcher, Scott Piper, suggests measures organizations can adopt to ensure secure defaults on AWS and improve their security posture.
Analysis Summary
# Best Practices: AWS Security Hardening via Service Control Policies (SCPs)
## Overview
These practices focus on using AWS Service Control Policies (SCPs) within an AWS Organization to establish preventative guardrails. The goal is to enforce secure defaults, override risky configurations, and prevent the modification of essential security settings across all member accounts, thereby significantly reducing the risk profile associated with public exposure and insecure resource configurations.
## Key Recommendations
### Immediate Actions
1. **Investigate Existing Usage:** Before deploying any preventative SCPs, review CloudTrail logs and use AWS Access Advisor data across your Organization Management account to identify which principals or accounts currently rely on the functionality you intend to block (e.g., public S3 access, specific cross-account sharing).
2. **Implement S3 Block Public Access (Account Level):** Run the command to enforce the account-level setting ensuring all new and existing S3 buckets are prevented from being made public across every AWS account.
3. **Enforce EBS Encryption in All Regions:** For every region in every account, enable the region-wide feature to encrypt all new EBS volumes by running the necessary API call, changing the region parameter sequentially.
### Short-term Improvements (1-3 months)
1. **Prevent Public EC2 AMIs:** Ensure the "Block Public Access for Machine Images" feature is enabled for all accounts, especially those that did not have public AMIs as of October 16, 2023.
2. **Disable Public SSM Document Sharing:** Apply the configuration in every region to prevent AWS Systems Manager documents from being shared publicly.
3. **Block Anonymous Lambda URLs:** Implement the SCP that mandates all AWS Lambda function URLs must utilize IAM authentication, preventing anonymous HTTP access.
4. **Add Foundational SCPs:** Apply the previously established SCPs from the foundational security baseline blog post (assuming this step has been completed).
### Long-term Strategy (3+ months)
1. **Prevent Modification of Security Controls:** Deploy SCPs explicitly designed to deny actions that could modify the newly implemented essential security features (e.g., denying modifications to S3 Block Public Access or EBS Encryption settings).
2. **Restrict External RAM Sharing:** Deploy an SCP across the organization to prevent Resource Access Manager (RAM) from sharing resources (like VPCs) with accounts outside of the AWS Organization boundary.
3. **Enforce Network Isolation:** Apply the recommended SCP to all workload accounts to prevent them from establishing their own paths to the internet, directing all traffic through the designated, monitored Network Account.
4. **Implement Role-Based IP Restriction:** For highly sensitive roles (like an explicitly named "admin" role), deploy an SCP to restrict their usage only to known, trusted IP addresses.
## Implementation Guidance
### For Small Organizations
* **Prioritize Quick Wins:** Focus heavily on enabling S3 Block Public Access defaults and enforcing EBS encryption immediately, as these are low-risk, high-reward implementations.
* **Consolidate SCPs:** Since you likely have fewer SCPs applied, actively work to combine multiple required SCP rules into fewer policy documents to stay under AWS limits.
* **Manual Verification:** Due to limited auditing tools, rely more heavily on manual spot-checks in the Management Account to verify SCP application status, complemented by CloudTrail review.
### For Medium Organizations
* **Phased Rollout:** Implement preventative SCPs region by region or account organizational unit (OU) by OU, rather than organization-wide deployment, to manage potential application risks.
* **Create Exceptions:** Be prepared to integrate necessary exceptions into SCPs (e.g., allowing specific principals or accounts) only where investigations have confirmed legitimate, necessary workloads depend on a blocked feature.
* **Automate Enforcement Check:** Use automation (e.g., AWS Lambda triggered by configuration changes) to report deviations from the SCP baseline compliance *before* an explicit SCP prevents it.
### For Large Enterprises
* **Establish an SCP Deployment Workflow:** Mandate a formal governance and review process, including security and workload teams, before applying any new organizational SCPs.
* **Utilize Separate OUs:** Place accounts with legacy requirements or known dependencies into specific OUs where SCPs can be applied with required exceptions, while enforcing tighter controls on newer OUs.
* **Leverage Data Perimeter Examples:** Investigate and integrate governance controls provided via AWS samples for establishing robust data perimeters.
* **Mandate Least Privilege for SCP Management:** Ensure that only a highly restricted Security or Governance team has permissions to manage or modify Service Control Policies.
## Configuration Examples
**SCP to Prevent Modification of S3 Public Block:**
*(Note: The exact JSON policy is dense and omitted here, but the action to prevent is denying `s3:PutPublicAccessBlock` and similar actions targeting security configuration changes.)*
**SCP to Enforce IAM Authentication for Lambda Function URLs:**
*(Policy focuses on denying the ability to create a Lambda Function URL resource with anonymous access enabled.)*
**SCP to Restrict Admin Access to Specific IPs:**
This SCP enforces that the role named "admin" can *only* be assumed from the IP address `1.2.3.4`.
json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RestrictAdminToSpecificIP",
"Effect": "Deny",
"Action": "sts:AssumeRole",
"Resource": "*",
"Condition": {
"ForAllValues:StringNotEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::*:role/admin"
]
},
"NotIpAddress": {
"aws:SourceIp": "1.2.3.4/32"
}
}
}
]
}
## Compliance Alignment
* **NIST SP 800-53:** Applicable controls include AC-2 (Account Management), SC-7 (Boundary Protection), and CM-6 (Configuration Settings).
* **ISO 27001/27002:** Aligns with Annex A controls related to access control (A.9) and system acquisition, development, and maintenance (A.14).
* **CIS AWS Foundations Benchmark:** Directly addresses many configuration points, specifically concerning S3 public access (Benchmark 1.6), EBS encryption (Benchmark 2.4), and IAM best practices.
## Common Pitfalls to Avoid
* **Deployment without Investigation:** Applying restrictive SCPs broadly without first checking CloudTrail/Access Advisor data, leading to immediate, organization-wide production service disruption.
* **Forgetting Cross-Region Requirements:** Assuming an action taken in one AWS region (like enabling EBS encryption) applies globally; these must be executed/enforced in every active region.
* **Over-reliance on IAM Policies:** Assuming IAM policies sufficiently protect against risky behavior; management-level SCPs are crucial because they restrict the *maximum* permissions an account can ever possess, overriding IAM where necessary.
* **Underestimating SCP Limits:** Attempting to create hundreds of independent SCPs instead of consolidating related security requirements into a smaller set of comprehensive policies.
## Resources
* **Preventing IAM Access Key Usage:** Consult the referenced blog series on moving away from IAM User access keys.
* **AWS SCP Examples for Data Perimeter:** Review the official AWS samples provided on GitHub for implementing data perimeter controls.
* **AWS Organizations SCP Documentation:** Consult the official AWS documentation for the precise SCP syntax and limitations for VPC isolation and EC2 configuration policies.