Table of Contents
Most healthcare security teams we work with can quote their cloud posture score from memory. Ninety-four percent. Ninety-six. It's on the quarterly slide, it reassures the board, and it gives the compliance officer something concrete to hand an auditor. But understanding CSPM limitations matters more than the number itself, because a high CIS benchmark score measures how closely your AWS configuration matches a published checklist. It doesn't measure whether someone outside your organization can reach protected health information (PHI). Those are different questions, and the gap between them is where our analysts keep finding real exposure.
This piece explains why that gap exists, walks through four specific blind spots we see repeatedly in AWS environments, and lays out how to pair posture scoring with external validation so you're testing what an attacker actually sees.
What Is a CSPM Score Actually Measuring?
Cloud security posture management (CSPM) tools continuously read your cloud provider's configuration APIs and compare what they find against a ruleset. The most common ruleset is the CIS AWS Foundations Benchmark, a consensus document covering things like root account MFA, CloudTrail logging, S3 public access blocks, password policy, and security groups that expose SSH or RDP to the internet.
That's genuinely valuable. A CSPM tool will catch the forgotten public bucket and the unencrypted EBS volume faster than any human reviewer.
The limitation is structural, not a matter of tool quality. A benchmark check is a yes-or-no question asked about a single resource in isolation. Is logging enabled on this trail? Does this security group allow 0.0.0.0/0 on port 22? Real attack paths rarely live inside one resource. They live in the relationships between resources, identities, accounts, and people, and in context the API simply doesn't hold, such as whether the person who owns an access key still works for you.
So a 95% score tells you that 95% of the questions on the checklist got the right answer. It says nothing about the questions that aren't on the checklist.
Four Gaps Benchmarks Structurally Miss
1. Cross-Account Trust Relationships
Healthcare organizations run on vendors. Your EHR integration partner, your claims clearinghouse, your analytics firm, and your managed backup provider may each have an IAM role in your account that their AWS account is allowed to assume.
The CIS benchmark doesn't evaluate role trust policies for who is trusted or under what conditions. A posture tool will happily score an account where:
- A role trusts an entire external account (
arn:aws:iam::<vendor-account>:root) rather than a specific role inside it, so any identity the vendor creates can assume it. - A third-party role has no
sts:ExternalIdcondition, leaving you open to the classic confused-deputy problem, where another customer of the same vendor can trick the vendor's tooling into acting on your account. - A vendor relationship ended two years ago, but the trust policy and its attached permissions are still there.
None of these trip a benchmark control. Each one effectively extends your security boundary to include someone else's, and under HIPAA that someone else may or may not have a current business associate agreement.
2. Overly Permissive IAM Conditions
Benchmarks check for the obvious, like policies granting *:* administrative access. They don't parse the subtle logic that turns a seemingly scoped policy into a broad one. Patterns we flag regularly:
iam:PassRoleonResource: "*". A developer role that can launch EC2 instances or Lambda functions and pass any role to them can effectively become any role in the account, including the one with access to your PHI data lake.NotActionandNotResourcestatements. They read as restrictive at a glance and grant almost everything in practice.- Wildcard condition values. A
StringLikecondition onaws:PrincipalArnwith a trailing*, or a bucket policy keyed to an IP range that includes a shared NAT gateway, quietly widens who qualifies. - Conditions that only apply to some requests. An
aws:SourceIprestriction means nothing for calls made through an AWS service on your behalf, which is a frequent surprise.
These are reasoning problems. You have to evaluate what a principal can reach, chained across multiple policies, which is exactly what single-resource checks don't do.
3. Internal Services Exposed Behind Load Balancers
Here's a scenario we've seen more than once. The internet-facing Application Load Balancer serves your patient portal on 443. Its security group allows 0.0.0.0/0 on 443, which is correct and passes every benchmark control. Then someone adds a host-header or path rule that forwards /admin, grafana., or internal-api. to a target group that was never meant to be public.
The CSPM sees a compliant security group and a compliant load balancer. It doesn't see that a Grafana instance with default credentials, a Kibana dashboard indexing application logs full of patient identifiers, or an unauthenticated internal API is now reachable from anywhere.
This matters even more given how many internal tools ship with dangerous defaults. This week's disclosures for Plane, the open-source project management tool, are a good illustration:
- CVE-2026-105641 (CVSS 9.8): before version 1.4.0, Plane's
aioandclicommunity deployment manifests ship fixed, publicly knownSECRET_KEYandLIVE_SERVER_SECRET_KEYvalues that stay active unless operators override them. The setup script only randomizes secrets for the development Docker Compose path. - CVE-2026-105636 (CVSS 9.9): before 1.4.0, Plane's webhook delivery task follows redirects without re-validating the destination. The original URL is checked against private and loopback ranges, but the final URL after redirects isn't. In AWS, that's the shape of a server-side request forgery that can reach internal services, and potentially the instance metadata endpoint if IMDSv2 isn't enforced.
Remediation for both is the same: upgrade Plane to 1.4.0 or later, rotate any secret keys that were left at the shipped defaults, and enforce IMDSv2 on the underlying instances. But the broader lesson is that your posture tool can't tell you whether a tool like this is reachable from the internet in the first place. Only testing from the outside can.
The same goes for internal business apps holding credentials. CVE-2026-105763 (CVSS 9.6) affects Twenty CRM from 1.20.10 until 2.7.0: its /metadata GraphQL connectedAccounts query returned connection parameters for every connected account in a workspace, including plaintext IMAP, SMTP, and CalDAV passwords, without enforcing the caller's identity. If that instance is exposed through a misrouted load balancer rule, a single low-privilege account becomes a mailbox compromise. Upgrade to 2.7.0 or later and rotate every credential stored in connected accounts.
4. Dormant Access Keys Tied to Departed Contractors
To be fair, the CIS AWS Foundations Benchmark does address stale credentials. It recommends disabling credentials unused for 45 days or more and rotating access keys every 90 days. The problem is that both checks look at the key, not the human.
Consider a contractor who built your HL7 ingestion pipeline. They finished eight months ago. Their IAM user's access key is still active, and because they hardcoded it into a cron job that still runs nightly, it shows recent use. It may even have been rotated on schedule by an automation that nobody tied back to an owner. Every benchmark control passes.
Meanwhile, that same key may live in the contractor's personal laptop config, an old Git repository, or a credential dump traded on criminal forums. Your CSPM has no idea the person left, because offboarding lives in your HR system and your vendor management process, not in the AWS API.
Why This Matters More Under HIPAA
For a healthcare organization, these aren't abstract hygiene issues. Each gap maps directly to a Security Rule requirement, and each one is the kind of finding that turns a security incident into a reportable breach with a notification clock attached.
| Gap | Relevant HIPAA Security Rule standard | Evidence an auditor or OCR will ask for |
|---|---|---|
| Cross-account trust | Information access management, §164.308(a)(4); business associate contracts, §164.308(b) | Inventory of third-party roles mapped to current BAAs |
| Permissive IAM conditions | Access control, §164.312(a)(1) | Proof that access to ePHI is limited to authorized users |
| Exposed internal services | Risk analysis, §164.308(a)(1)(ii)(A) | Documented assessment of internet-reachable systems |
| Dormant contractor keys | Termination procedures, §164.308(a)(3)(ii)(C) | Records showing access was removed at offboarding |
Notice the evidence column. When OCR asks how you limited access to ePHI, a posture score isn't an answer. You need an inventory, a mapping, and proof you acted on it. That's the same evidence your HITRUST assessor wants, and it's the evidence most teams struggle to pull together quickly.
How to Pair Posture Scoring With External Validation
We're not suggesting you throw out your CSPM. Keep it. It's the right tool for catching configuration drift at scale. The fix is to add a second, independent view that starts where an attacker starts: outside your account, with no credentials.
Step 1: Build Your Attack Surface From the Outside In
Enumerate everything that resolves or responds publicly, without relying on your own asset inventory:
- Pull every subdomain from DNS records and certificate transparency logs.
- Map public IPs, Elastic IPs, load balancer DNS names, CloudFront distributions, and API Gateway endpoints across every account and region, including the ones nobody remembers creating.
- Fingerprint what's actually listening and compare it to what you expect to be listening.
The delta between your expected list and the observed list is usually where the interesting findings are.
Step 2: Probe What You Find
Discovery alone isn't validation. Follow up by testing reachable endpoints for default credentials, unauthenticated admin paths, exposed GraphQL introspection, SSRF-prone features like webhooks, and known critical CVEs in the software you identified. This is where a structured vulnerability assessment earns its keep.
Step 3: Analyze Identity as a Graph
Review IAM the way an attacker would chain it. Starting from each externally reachable foothold, ask: what role does this workload run as, what can that role pass or assume, and where does the chain end? Specifically:
- List every role with a trust policy naming an external account, and require an
sts:ExternalIdcondition and a named, current owner for each. - Search for
iam:PassRolewith wildcard resources andNotActionstatements. - Reconcile every IAM user and access key against your HR and vendor offboarding records, not just last-used dates. Treat any key without a current, named human owner as compromised until proven otherwise.
Step 4: Validate With a Real Test
At least annually, and after major architecture changes, have someone actually try to get from the internet to PHI. A cloud-focused penetration test proves or disproves the attack paths that posture tools and graph analysis only suggest.
Step 5: Make It Continuous
A point-in-time test is a snapshot. Your load balancer rules, vendor roles, and contractor roster change every week. External discovery and leaked-credential monitoring should run continuously, with findings feeding the same risk register your compliance team uses for HIPAA evidence.
Where Rogue Logics Fits
This is the problem our platform was built around. We run continuous attack-surface and domain scanning alongside 24/7 SOC monitoring and threat intelligence, so an exposed admin panel or a contractor key showing up somewhere it shouldn't gets triaged by our US-based analysts, not left in a dashboard. Because GRC lives in the same platform, every finding maps straight to the HIPAA and HITRUST controls it affects, which means the evidence your auditor asks for already exists. If you want a deeper look at your AWS environment specifically, our cloud security services team runs fast, fixed-scope reviews built around exactly the gaps described here.
The Takeaway
A CIS benchmark score answers a narrow question well: does each resource match a known-good configuration? Keep asking it. But it was never designed to answer the question your board, your auditors, and OCR actually care about, which is whether someone outside your organization can reach patient data. Cross-account trust, conditional IAM logic, misrouted load balancers, and orphaned contractor keys all sit outside the checklist by design. The only way to see them is to look at your environment the way an attacker does, from the outside and across relationships, and to keep looking. Treat your posture score as a floor, not a finish line.