Full Report
Service Control Policies (SCPs) can be a great way to prevent actions from happening in AWS accounts. In this post, we will illustrate a specific use case of SCPs that protects the security baseline, or landing zone, configuration you’ve created for accounts
Analysis Summary
# Best Practices: Establishing and Enforcing AWS Security Baselines with Service Control Policies (SCPs)
## Overview
These practices focus on defining an initial, desired security configuration (security baseline) for all AWS accounts within an organization and enforcing this configuration using AWS Organizations Service Control Policies (SCPs). The goal is to prevent accidental or malicious modification of critical security settings, even by users with administrative privileges inside the member accounts.
## Key Recommendations
### Immediate Actions
1. **Implement Root User Access Prevention:** Deploy an SCP immediately to deny all actions performed by the root user across all member accounts, except for specific, documented exceptional use cases (e.g., fixing policies denying all access).
2. **Prevent Account Withdrawal:** Implement an SCP to explicitly deny any action that would allow a member account to leave the AWS Organization to ensure baseline enforcement remains active.
3. **Audit Existing Baselines:** Run audit scripts against all current AWS accounts to identify existing deviations from the desired security baseline (e.g., disabled CloudTrail, disabled GuardDuty).
### Short-term Improvements (1-3 months)
1. **Protect Core Services via SCPs:** Deploy SCPs specifically designed to protect the modification or disabling of core security services like **CloudTrail** and **GuardDuty**, especially where organization-level features are not being used.
2. **Secure Vendor/Tooling IAM Roles:** Create and deploy an SCP that specifically prevents the modification or deletion of critical, predefined IAM roles (e.g., vendor access, tooling roles) within member accounts.
3. **Configure Contact Information Protection:** Implement SCP controls to deny modification of critical account contact information (phone numbers) to mitigate account takeover risks.
### Long-term Strategy (3+ months)
1. **Establish Baseline Definition Standard:** Formalize the definition of the security baseline across the organization, documenting required services (e.g., logging, threat detection) and non-negotiable IAM structures.
2. **Automate Remediation:** Develop or refine automated scripts (manual or auto-remediation flows) that periodically scan all accounts against the established baseline and automatically correct any drifts.
3. **Review and Refine SCP Usability:** Periodically review all deployed SCPs to ensure they are not creating excessive usability problems or debugging difficulties for legitimate engineering tasks. Consolidate SCP statements where possible to manage the SCP limit.
## Implementation Guidance
### For Small Organizations
- Focus initially on core preventative SCPs: **Root User Denial** and **Account Leaving Prevention**.
- Leverage AWS Control Tower if available, as its **Mandatory Controls** provide pre-built, effective SCP enforcement for many baseline requirements.
- Use simple, well-documented SCPs rather than overly complex rules that require extensive exception handling.
### For Medium Organizations
- Standardize the process for deploying and updating SCPs through Infrastructure as Code (IaC).
- Integrate SCP enforcement directly into the account provisioning pipeline (e.g., using AWS Organizations features or Control Tower).
- Implement robust **Delegated Administrator** roles to provide limited visibility into applied SCPs for engineers needing to debug access denials.
### For Large Enterprises
- Implement separate SCPs for different policy tiers (e.g., foundational compliance, service protection, IAM protection) to manage complexity and debugging.
- Develop comprehensive exception management processes documented clearly in the SCP documentation and accessible via a delegated administrator structure.
- Ensure all critical IAM roles are explicitly listed within the role protection SCPs, paying attention to roles created by service-linked permissions (which SCPs cannot restrict).
## Configuration Examples
**Example 1: Protecting critical IAM Role Names (Based on Control Tower Mandatory Control)**
(Note: Specific resource ARNs and role names must be substituted for your environment, e.g., changing `WizAccessRole` and the role creation exception.)
json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyModifyProtectedRoles",
"Effect": "Deny",
"Action": [
"iam:DeleteRole",
"iam:UpdateRole",
"iam:PutRolePolicy",
"iam:AttachRolePolicy"
],
"Resource": [
"arn:aws:iam::*:role/WizAccessRole",
"arn:aws:iam::*:role/VendorAdminRole"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::*:role/StackSetExecutionRole"
]
}
}
}
]
}
**Example 2: Preventing Root User Usage**
(Note: Account ID `111111111111` must be replaced with the designated account authorized to use the root principal for emergencies.)
json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyRootActions",
"Effect": "Deny",
"Principal": {
"AWS": "arn:aws:iam::*:root"
},
"Action": "*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:PrincipalAccount": "111111111111"
}
}
}
]
}
## Compliance Alignment
- **NIST SP 800-53 (AC-2, SC-7):** Enforcing baseline configurations directly applies to enforcing access control settings and system security configurations.
- **CIS AWS Foundations Benchmark:** Directly aligns with requirements to ensure logging (CloudTrail) and threat detection (GuardDuty) are enabled and protected from modification.
- **ISO 27001 (A.8.2.1):** Deals with configuration management and ensuring changes adhere to defined baseline standards.
## Common Pitfalls to Avoid
1. **Over-Permissive Root Exemptions:** Creating blanket exceptions in the root denial SCP that allow too many actions or too many accounts, defeating the purpose of the control.
2. **Ignoring Service-Linked Roles:** Assuming SCPs can prevent modifications to AWS service-linked roles (e.g., CloudFormation StackSet roles); these must be handled through alternative mechanisms or policy stacking.
3. **Failing to Change Placeholders:** Deploying SCP examples without replacing generic placeholders (like `CHANGEME`, `111111111111`, or default role names) specific to the organization's deployment.
4. **Lacking Visibility into SCP Denials:** Not setting up a mechanism (like using Delegated Administrator) that allows engineers to understand *why* an action was denied due to an SCP, leading to excessive debugging time.
## Resources
- AWS Control Tower Mandatory Controls Documentation
- AWS Organizations SCP General Guidance Documentation
- AWS Documentation on Root User Tasks Requiring Root Access (for defining SCP exclusions)
- Documentation on changes to `aws-portal:ModifyAccount` privilege retirement (for legacy checks).