In May 2024, Ascension, one of the largest health systems in America, was reported to be impacted by a ransomware attack. The fallout affected operations on a large scale: staff could not access electronic health records and reverted to paper charts, ambulances had to be diverted away from hospitals, and data including PHI belonging to millions of people was stolen.

This event was triggered when one unsuspecting employee downloaded a legitimate-appearing file on their computer, which unleashed chaos across the hospitals Ascension operates.

It's unclear whether an Endpoint Detection and Response (EDR) agent was running on that computer, but this is the type of activity it is designed to contain. Let's pivot back into our fictional company, Valleywind Health, and its security architecture.

Endpoint & Device Security

Every workstation and server at Valleywind runs an EDR agent. That agent looks for suspicious behavior patterns, malware signatures, and any activity that resembles an attack.

The EDR agent on these workstations would look for things like:

  • A script creating new user accounts silently
  • PowerShell executing from an Excel document
  • A process rapidly encrypting a large number of files
  • A laptop scanning the network

If a workstation begins encrypting files faster than is possible for any user, Valleywind's EDR would detect that behavior, kill any associated processes, isolate that machine from the network, then alert the SOC. The isolation step is critical to prevent the attack from spreading and eliminate an opportunity for Command and Control (C2) communication.

Application & API Security

Valleywind’s patient portal uses APIs to pull data from the Electronic Health Records and billing systems and to run patient insurance eligibility checks with insurers. Every API call is a potential attack vector if not properly secured.

Let's say the portal's API checks whether a user is logged in before returning a record, but it never checks whether that record belongs to them. If a patient logs in with their own account, this authorization lapse enables them to change the patient ID in their request and get someone else's chart back. Without strong authorization, the API only asks whether a user is valid (authentication), but fails to check whether the data they ask for belongs to them (authorization).

Beyond the thought of exposing PHI, what makes this worse is that without rate limiting, an attacker could successfully execute a script that requests the entire range of patient IDs, and instead of a single exposed chart, it becomes a bulk PHI breach.

Valleywind Health secures their API by enforcing an authorization check on every request so a user only receives the records that belong to them. The API also caps how many requests one connection can make to prevent abuse and DoS attacks.

Oftentimes, it seems like the main objective in application security is to secure the code, but it's also in understanding how applications talk to each other and tightening the trust boundaries between them.

Data Security

Valleywind Health handles some of the most sensitive and highly regulated data there is: patient records. Protecting this data means thinking about how it lives in the system, how it moves, and how people actually use it day to day. The company works with different types of data: Electronic Health Records and billing data, files like PDFs and patient notes, operational logs and audit trails, and anonymized patient data used for research and analysis.

If a nurse downloads a report containing PHI and sends it to her personal email to finish up some work from home, the guardrails Valleywind implements stop that from happening.

  • Data Loss Prevention (DLP) rules flag or block anything that looks like outbound PHI
  • Downloads are encrypted before they leave the system
  • Role-Based Access Control (RBAC) limits large data downloads to only specific employees
  • Download activity is logged, and unusual patterns generate alerts in the Security and Information Event Management (SIEM)

In an insecure environment with missing or poorly configured DLP tools, this incident would slip through unnoticed.

Good data architecture sets clear boundaries for how sensitive information should be moved, shared, and stored, without making regular tasks impossible for users. It gives employees the room to do their work while still keeping patient data exactly where it belongs.

The Trail of Each Layer

Throughout this series, A Layered Introduction to Security Architecture, every layer has produced a record of what it saw. In the third and final part of this series, we will cover monitoring, logging, and detection, with a focus on how each reports on events and can tell the story of an attack.