CNAPP solutions are essential for detecting misconfigurations and vulnerabilities in cloud environments. In many cases, these platforms trigger alerts for issues that could be or have already been mitigated by existing security controls. One of the key mechanisms for mitigating risks and controlling what can or cannot be done across an AWS environment is Service Control Policies (SCPs).
In this blog, we’ll explore how SCPs can be used to mitigate security risks, provide examples of common CNAPP alerts that might overlap with these controls, and discuss how ZEST can help you manage and reduce the noise by identifying which resources are already covered by your SCPs.
What Are Service Control Policies (SCPs) in AWS?
SCPs are a feature of AWS Organizations that allow administrators to define guardrails that restrict or allow certain actions across all accounts in an organization. SCPs help ensure that even if an IAM user or role has permissions to perform certain actions, those actions can still be blocked at the organizational level if the SCP denies it. They are extremely powerful for enforcing security best practices and controlling access.
How SCPs Help Mitigate Cloud Risks
SCPs are designed to:
- Set Permissions Boundaries: SCPs define the maximum permissions allowed in your AWS environment, limiting users, roles, and services from taking actions that could lead to security vulnerabilities.
- Restrict Actions Across Accounts: SCPs can be applied to specific accounts or organizational units (OUs), helping you enforce policies based on your organizational structure.
- Implement Guardrails: They act as a safety net, preventing actions such as the creation of insecure resources, overly permissive IAM policies, or public exposure of sensitive assets.
For more information on how SCPs can be used as a mitigation pathway to enable security teams to block attacker activity, check out our latest release.
Common CNAPP Alerts Mitigated using AWS SCPs
CNAPP tools continuously scan your cloud infrastructure to flag potential security risks. However, there are instances where these alerts may not represent real threats due to the overlap with existing SCPs.
Let's look at a few examples:
Example 1: Publicly Accessible S3 Bucket
CNAPP Alert: "S3 Bucket is publicly accessible."
Risk: A publicly accessible S3 bucket can expose sensitive data to unauthorized users or allow external attackers to read or modify the data in the bucket.
SCP to Mitigate Exploitation: While SCPs won't prevent the bucket from being public, an SCP can be created that prevents malicious users from modifying or deleting objects in the bucket, which reduces the risk of data manipulation or theft.
Example SCP (AWS):
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"s3:DeleteObject",
"s3:PutObject",
"s3:PutObjectAcl"
],
"Resource": "arn:aws:s3:::your-bucket-name/*"
}
]
}
How It Helps:
This SCP would deny any user the ability to delete objects, upload new objects, or change the permissions (ACLs) of the S3 bucket, even if the bucket is publicly accessible. While the bucket is still publicly accessible (meaning someone could read the data), this SCP prevents someone from making any harmful changes to it, such as overwriting or deleting objects.
Example 2: Unrestricted Access to EC2 Instances
CNAPP Alert: "EC2 Instance is publicly accessible and has open security group ports."
Risk: A public-facing EC2 instance with open security group ports (e.g., port 22 for SSH) can be targeted by attackers for unauthorized access, potentially leading to a breach or exploitation of the server.
SCP to Mitigate Exploitation: Although the instance may still be publicly accessible, you can create an SCP that blocks any unauthorized changes to its security group settings, preventing attackers from altering the firewall or opening additional ports.
Example SCP (AWS):
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ec2:AuthorizeSecurityGroupIngress",
"Resource": "*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": "192.168.1.100/32"
}
}
}
]
}
How It Helps:
This SCP prevents users from modifying security groups to allow further inbound traffic, except from the trusted IP (192.168.1.100
). So, even if an EC2 instance is initially misconfigured with open ports, the SCP ensures that unauthorized users can't alter the security group to expand their access (e.g., open new ports or allow unrestricted access). This mitigates the risk of exploitation by preventing attackers or misconfigurations from increasing their foothold.
Example 3: Overly Permissive IAM Role
CNAPP Alert: "IAM Role has excessive permissions (e.g. permissions to delete EC2 instances)."
Risk: An IAM role with excessive permissions could potentially be exploited by an attacker, allowing them to perform destructive actions like terminating critical EC2 instances or deleting resources.
SCP to Mitigate Exploitation: Even though the IAM role might have broad permissions, you can create an SCP that prevents the deletion of critical resources, such as EC2 instances.
Example SCP (AWS):
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ec2:TerminateInstances",
"Resource": "*"
}
]
}
How It Helps:
This SCP denies the TerminateInstances
action across all EC2 instances in your organization, even if the IAM role has broad permissions. This means that no one can terminate EC2 instances, protecting against accidental or malicious deletion of critical infrastructure, even if an attacker somehow gains access to an overly permissive IAM role.
Example 4: Exposing CloudTrail Logs
CNAPP Alert: "IAM User has unrestricted access to CloudTrail logs."
Risk: An attacker who gains access to CloudTrail logs can potentially modify or delete them to cover their tracks, making it harder for you to detect and respond to security incidents.
SCP to Mitigate Exploitation: You can use SCPs to prevent the deletion or modification of CloudTrail logs, ensuring that any malicious activity does not go unnoticed.
Example SCP (AWS):
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "cloudtrail:DeleteTrail",
"Resource": "*"
},
{
"Effect": "Deny",
"Action": "cloudtrail:PutEventSelectors",
"Resource": "*"
}
]
}
How It Helps:
This SCP would block the deletion of CloudTrail logs (DeleteTrail
) and the modification of event selectors (PutEventSelectors
), preventing attackers from tampering with CloudTrail logs and ensuring that critical auditing information is preserved.
How ZEST Helps Reduce Noise
While Service Control Policies (SCPs) are essential for securing your AWS environment, it can still be challenging to manually track which resources are covered by which policies and ensure that CNAPP tools recognize the existing security controls so that alerts can be accurately prioritized. This is where ZEST can make a significant difference. ZEST helps reduce the noise so you can prioritize remediation efforts on risks that are actually exploitable and reachable. With ZEST, security teams can easily:
- Identify SCP Coverage: ZEST helps teams identify which resources are covered by your SCPs in context of risks identified by your CNAPP solution.
- Reduce False Positives: By recognizing where SCPs are applied, ZEST helps filter out irrelevant alerts that are already mitigated by your existing security policies.
- Manage SCPs: ZEST integrates with Terraform to automate the management of SCPs and track which controls are applied to different parts of your cloud infrastructure.
Conclusion
Service Control Policies (SCPs) are a powerful tool for managing security in AWS environments. SCPs can both reduce risk and serve as critical context that helps security teams better prioritze their remeidation efforts.
- When full remediation takes time (e.g. patching, code changes, or upgrades can’t be implemented immediately), SCPs can be used to limit exposure by restricting actions such as accessing sensitive resources, disabling encryption, or making resources public. This provides an immediate layer of protection while permanent fixes are in progress.
- When risks can be deprioritized: Based on your current configurations and SCP coverage, some issues flagged as "critical" or “high” by a CNAPP tool may not actually pose a real threat. For example, if an SCP prevents the risky action from occurring, the alert can be deprioritized or disregarded entirely.
ZEST enhances this process by identifying and mapping which resources are covered by your SCPs. This enhances prioritization and ensures remediation efforts are focused on the risks that have the greatest impact to your unique environment.
To learn how you can integrate ZEST into your vulnerability management workflow to help security teams cut through alert noise, focus on truly critical risks, and strengthen your cloud security posture, schedule a demo with our team.