The Challenge
The client is a health provider that delivers services across multiple sites and holds a large volume of sensitive patient information. Over several years it had moved core systems into the cloud, running workloads across both AWS and Azure, often configured by different teams and vendors at different times. That organic growth left the security team without a clear, current picture of how the environment was configured or where patient data was exposed.
Healthcare carries a particular combination of pressures: the data is among the most sensitive an organization can hold, clinical systems cannot be taken offline for testing, and the sector is a standing target for ransomware crews who understand that a hospital under pressure is more likely to pay. The provider needed an assessment that was thorough without being disruptive.
Our Approach
StrikeCyber ran a configuration and identity review across both cloud platforms, working against read-only access and coordinating closely with the clinical engineering team so that no assessment activity touched systems in active patient use.
- Identity and access management review across both platforms, mapping every path by which a low-privileged account could escalate toward patient data.
- Storage and database exposure review, including public accessibility, encryption at rest, backup configuration and cross-account access grants.
- Logging and detection coverage assessment, establishing whether an intrusion into either platform would generate evidence anyone would see.
Findings were triaged by an operator rather than handed over as tool output, so the provider received a ranked set of genuinely reachable exposures rather than a benchmark report with several hundred rows.
What We Found
- Over-permissive IAM. A number of service accounts and human roles held far broader permissions than their function required, including several with effective administrative reach across an entire subscription.
- Exposed storage. Two storage locations holding clinical documentation were reachable with credentials that a compromised low-privilege account could obtain, and one had no logging enabled at all.
- Inconsistent multi-factor authentication. MFA was enforced for most staff but not for a set of legacy service and vendor accounts, which are exactly the accounts an attacker looks for first.
- Blind spots in logging. Control plane activity was captured in one platform and largely absent in the other, meaning an intrusion in the second would have left little trace.
The Outcome
The provider rebuilt its permission model around least privilege, starting with the accounts that carried administrative reach, and closed the storage exposures within the first week. MFA was extended to the legacy and vendor accounts, with the small number that could not support it isolated and monitored instead. Logging was brought to a consistent standard across both platforms and connected to the provider's existing monitoring.
A retest confirmed the escalation paths to patient data were closed and that the same activity now generated alerts. The security team also gained something durable: a written, current picture of how its cloud estate is configured, which it now reviews on a set cadence rather than reconstructing under pressure.
Why It Matters
Cloud environments rarely become insecure through a single decision. They drift, one reasonable-looking permission grant at a time, until the accumulated result is an escalation path nobody designed and nobody can see. For providers subject to the HIPAA Security Rule, that drift is also a compliance exposure, because the rule expects a current and accurate assessment of risk to electronic protected health information. To get a clear picture of your cloud estate, get in touch.