CSPM False Positives

Security and engineering teams use CSPMs or cloud security posture management tools to monitor cloud environments for risky misconfigurations. With a larger cloud footprint, security professionals have been inundated with mountains of alerts based on simple rules. This begs the question: How are standard CSPM tools falling short today?

Based on discussions in the Cloud Security Forum Slack, interviews with security professionals, and investigations of popular open source CSPMs (ScoutSuite, Prowler, Cloudsploit, etc.), I came up with a few patterns. I’ll break down the most common false positive misconfiguration alerts and some potential fixes.

The IAM Traps

IAM users MFA is not enabled. This rule pretty commonly came up as one that generated a lot of false positives. When IAM users have no console passwords, it is unnecessary to enable MFA. 

Root account MFA is not enabled. When service control policies (SCPs) restrict the permissions of the root account, MFA for the root account is extraneous. Parsing SCPs and computing what actions an IAM principal can take remains a huge challenge for almost all CSPM tools. Most CSPM tools cannot parse SCPs to make this judgment.

AWS IAM password policy does not expire passwords in 90 days. Many security teams avoid using IAM users, and hence have no need for an IAM password policy. CSPM tools can easily check if IAM users exist in the AWS account, but they don’t.

‍Over-permissive cross account access. Attackers can use over-permissive cross account access to enter your environments and to move laterally through them. But there are too many false positive alerts because of errors processing principals or conditions in trust policy documents.

Networking

Security groups have bad ports open. Lack of context about security groups makes it frustratingly hard to triage CSPM rules about them. When a security group has no associated workload or the associated OS is not listening on a flagged port, the alert is likely a false positive. Security groups infamously have non-descriptive names, and many tools do not provide visual context around how they interact with other network and compute constructs.

Security groups with unrestricted ingress/egress access.  Many CSPM tools create an alert if a security group has 0.0.0.0/0 as a source or destination. Unfortunately, such alerts are often useless if the security group is not attached to any meaningful workload. Exact checks on IP ranges can be pretty easily fooled too, so checks should incorporate more robust IP range checks.

Security groups marked as unused. Tools frequently mark security groups as unused without checking association with services like AWS ECS and EKS. CSPMs should analyze the relationship between security groups and these types of compute in more detail.

Data Stores

S3 bucket is public. While this can be a security concern, S3 buckets may be intentionally left public (e.g. when serving static files for websites). Perhaps looking at file types or naming conventions could help reduce these false positives.

RDS instances without any backup plan. More business context is necessary around which RDS instances are viewed as business critical. Of course, some basic data collection around data access, exposure of the databases, etc. would also reduce the number of false positives.

Secrets Scanning

Secrets in EC2 user data scripts. Many CSPMs use poor regex and entropy checks to determine whether sensitive secrets are present in user data scripts. Higher fidelity secret scanners like TruffleHog and Gitleaks can be used to reduce false positives.

Conclusion

False positives are the most common complaint about CSPM tools. In this article, we've documented some of the most frustrating false positives in traditional CSPMs.

Interested in reducing false positives and getting better context on CSPM alerts? Checkout the ZeusCloud repository and join our Slack community!

‍

‍