Securing healthcare environments is a complex task, and it’s not getting any easier. The Internet of Things (IoT) even has its own terminology specifically for medical devices, the Internet of Medical Things (IoMT). These days, there’s a plethora of devices used in a healthcare setting — wearables tracking patient vitals, tablets used by physicians and nurses, connected scales, wheelchairs, and ambulances. A massive amount of data flows between these devices, all through API calls, that is stored and used to comprise an electronic medical record.

With all these medical devices connected to the internet, it becomes very clear that the old perimeter model of controlling access is not going to work. These devices no longer reside and operate within a single network’s boundaries. There’s a mix of personal, doctors’ office, and hospital devices all gathering information, and, in many cases, this data is distributed and not stored in one common place or network.

Enter Zero Trust

Access control needs to shift from the perimeter to each service or device. Every access attempt to this critical medical information needs to be scrutinized — don’t trust the user, device, workload, or service until properly verified. Access should, by default, be denied unless it’s possible to verify the identity of who or what is trying to access the data.

The approach of “never trust, always verify” is known as zero trust. The name implies that no one or no thing is trusted unless its identity is verified. This, however, is easier said than done and doesn’t involve just one tool or application. Zero trust is an architectural principle and touches on several components within an overall architecture. It involves:

1. Identity and access management
2. Device security
3. Network security
4. Data security
5. Workload security
6. Visibility tools
7. Orchestration platforms

Identity First

Although these areas are essential in achieving zero trust, identity and access management (IAM) is a prerequisite for all others. If the identity is not known, it’s not possible for a service, device, or workload to verify the caller.

OAuth and OpenID Connect are two standards-based approaches that enable a token-based architecture to handle authorization which also enables authentication. Users and systems are authenticated and issued an access token that is used to verify the identity. If verified successfully, further authorization can be performed to determine precisely what is allowed to be accessed. This model fits well within the healthcare environment where many different devices and services need to communicate and frequently verify their identity. As the approach is standards-based, it therefore enables interoperability.

HEAlth Relationship Trust (HEART)

All these devices and systems collecting and storing health data need to communicate with each other to comprise a user’s complete health profile. With different systems come challenges around interoperability in how these systems communicate and share all this data.

The HEAlth Relationship Trust Working Group has outlined how this patient data can be shared and defined several profiles with recommendations around how to implement this securely. This includes how patient information is accessed and transmitted across systems and between different healthcare providers.

Part of the interoperability recommendation of HEART is for the authorization server to issue access tokens as JWTs so that a protected resource can quickly determine the integrity of the token without having to make additional calls to, for example, an introspection endpoint. This includes determining what authorization server issued the token, if the token is still valid, and more. If that validation is sufficient, the resource server can then introspect the token further to obtain additional information to authorize the requested data.

Wrapper Tokens

Care must be taken when designing a token-based architecture. The general recommendation is to not let public clients or apps use JWTs as this could increase the risk of leaking PII held within the JWT itself. Remember, JWTs are great for validating that the data within the token has not been tampered with, but it doesn’t protect any of the data from being viewed. This, however, contradicts what the HEART profile stipulates.

The alternative is to use opaque (reference) tokens. This type of token is just a reference string and doesn’t hold any information unless they are introspected. There’s a tradeoff here in that opaque tokens require a call to the IDP to obtain the token’s details. Whereas JWTs can be validated immediately by the consumer without a call to the authorization server.

A best-of-both-worlds approach here is to combine the two and leverage a so-called wrapper token. This is a JWT that contains the essential claims needed for any initial verification such as the audience (aud), issuer (iss), expiration (exp) and other details defining what the token is going to be used for. The wrapper token also contains (wraps) an opaque token that can later be introspected to obtain the full dataset needed by the service called.

Treat Medical Records as Financial Records

Medical records are high-value targets for attackers as they contain a lot of Personal Identifiable Information (PII). The information itself can be very damaging if leaked and can also be used to launch further attacks for financial gain. As such, medical records would benefit from the same level of security as financial-grade APIs (FAPI) in addition to the security measures outlined by the HEART profile.

Sender-Constrained Access Tokens

HEART requires that the client for Identity Server communication is TLS-protected and that the client verifies the Identity Server’s certificate. This can be taken one step further, and Mutual TLS (mTLS) can be implemented, and with that, the use of sender-constrained access tokens. This binds the token to the client’s certificate and safeguards the token from being used by another client if it’s stolen.

Pushed Authorization Requests (PAR)

In a traditional authorization request to the authorization server, parameters are sent in the query string. These parameters don’t end up being protected at all. They are visible and susceptible to tampering. The information in these parameters could reveal a lot of information and might end up in logs.

A more robust and secure approach is to leverage Pushed Authorization Requests that wrap up the parameters in a request object that is signed and then sent in the body of a POST request. The authorization server can then validate the request to make sure it has not been tampered with.

JWT Secured Authorization Response Mode (JARM)

If PAR enhances the protection and integrity of the request, JARM is the equivalent for the response. When JARM is leveraged, the authorization code response is encoded as a signed JWT that the client can verify to ensure it has not been tampered with. This also protects against so-called replay or mix-up attacks.

Client Initiated Back Channel Authentication (CIBA)

The most common form of authentication takes place in the front channel. The user initiates and performs the authentication on the device requesting authentication. This couples the authentication or authentication device to the relying party (RP) requesting authentication.

CIBA allows authentication to be decoupled and only requires the user to have access to the authentication device. The RP initiates authentication, and the user is prompted to authenticate out-of-band in some way. The RP is then informed of the successful or failed authentication, and a token is issued.

This is an excellent approach to identifying a user in a customer support or over-the-phone scenario where a helpdesk person can trigger authentication that the user (or patient) on the phone performs out of band.

Conclusion

Massive amounts of data flow between devices and services in modern healthcare environments. Some of this data is very critical information that attackers can use for further financial gains in future attacks. Protecting this information and securing the healthcare services and APIs that hold the data and enable data sharing is crucial.

A zero-trust approach where no one is trusted and any user or service accessing data are always verified is the path forward for these environments. Zero trust is not a single product, and as this post outlines, several techniques are available to implement it. For example, the HEART profile outlines several aspects that aim at enabling interoperability between systems, and in conjunction, wrapper tokens can be used to facilitate efficiency. By treating patient data as financial information and applying the approaches of FAPI, the access tokens and the process around obtaining tokens can be safeguarded and integrity-proofed.