This post, the final in our Identity Credentials Risks blog series, focuses on Risk Category 3, which considers the risks associated with authorization or the activities someone has permission to perform. Authorization always follows Risk Categories 1 and 2 within both digital and real-life situations, because to determine what activities someone is allowed to do, you must first know exactly who they are. If not, then at the very least, you must confirm something about them.

Why is Authorization Important?

Let’s return once more to our recurring theme of checking in over 320 million Americans for a banquet.

  • Risk Category 1 (unique identifier) assumed an honest mistake by the registration desk handing out badge.
  • Risk Category 2 (identity credential) assumed the guest was nefarious and trying to impersonate someone else.
  • Risk Category 3 (authorization) somewhat splits the difference.

Regardless of whether the risk is accidental or deliberate, it’s critical to mitigate it immediately. To complicate matters, this risk requires constant vigilance to monitor and mitigate. Stale data about what people are allowed to access is a large contributor to this risk category.

We extended our analogy to feeding our guests three meals throughout the day. For our purposes, the registration desk hands out unique and secret QR codes along with badges. When they approach the desk for a meal ticket, they can simply provide their secret QR code. You scan the code and print out a ticket. The system keeps track of who has already received a meal to prevent multiple presentations of the same code.

In the last blog post, we imagined your manager separated the duties into two stations. One station registers new guests and gives identity proofed guests secret QR codes, and the second station prints out meal tickets after authenticating a guest with the QR code. You are operating the meal ticket desk, and someone else is greeting registrants.

Risk Category 3: Authorization

In this post, we’ll extend the analogy one step further. Imagine as part of this banquet, your manager informs you of a new rule. Parents of children younger than 16 are allowed to obtain meal tickets for their children in addition to themselves. Furthermore, your manager says that legal caregivers of the elderly are also able to obtain additional meal tickets. These additional tickets are for the elderly folks they care for. Your manager says the technology you’re using is up to date and knows the number of tickets each parent and/or caregiver is allowed to have.

To illustrate this risk, imagine the following scenario. Beth was the legal caregiver of an elderly person prior to the banquet. She has no children and has never cared for anyone else. Unfortunately, Beth fell temporarily ill before the banquet and had to transfer the person in her care to someone else. Beth approaches you at the meal ticket desk (let’s assume the attack we considered in the previous post on operational controls is mitigated). Beth hands you her QR Code and tells you the secret number she memorized, passing both tests for multifactor authentication. You print two meal tickets for Beth, who looks confused but then walks happily away. Beth received an extra meal ticket she was not allowed to have. What happened?

What is the Different Between Authentication and Authorization?

In the example above, you were aware of Risk Category 1. There may be more than one person with the same demographics as Beth in the system. However, you confirmed that wasn’t the case. You were also aware of Risk Category 2. Beth could be trying to impersonate someone else. Yet, she strongly authenticated herself, so you confirmed her identity with a high degree of assurance.

An attack on authorization is unique. No amount of identity proofing, strong authenticators, or unique identifiers is going to address this risk. The system simply was not up to date. It gave Beth more permission than Beth is allowed to have (i.e., receiving two meal tickets, even though she transferred her care duty).

Authentication and identity proofing encompass the processes and techniques to determine “who” someone is on the other side of the internet. Conversely, authorization encompasses the processes and techniques to determine “what” activities someone is allowed to do.

Authorization as Enterprise Security Versus Patient Access

Stale data is how many authorization attacks can occur. In a hospital, imagine a staff member moves to a different department. The staff member should no longer have access to the information relevant to the previous department. A child who turns 18 may no longer want their parents viewing their medical records. There are countless other examples, each of which requires diligence by the hospital system to ensure the permissions that people have are up to date. Admittedly, this is not an easy task. However, not all authorization attacks occur due to stale data. Sometimes it’s an insider who changes their own permissions to access data they aren’t supposed to. There are many other similar scenarios too.

This is why cybersecurity frameworks require organizations to implement a concept called “least privilege,” the absolute minimum permission someone needs to perform their job. The problem persists because it’s much easier to assign a particular role a lot of permissions that they may or may not need, rather than the bare minimum necessary. The example with Beth illustrates the importance of least privilege and up-to-date permissions when it comes to authorization.

DirectTrust’s Role in Supporting Authorization in Healthcare

Authorization is a challenging topic that takes on different forms, depending on the nature of the activities involved. Consider these examples: one is granting an IT administrator permission to access a server and the second is granting someone access to a relative’s health record. The first example occurs entirely within the organizational boundary and likely does not have legal implications. The latter example is the exact opposite.

Historically, DirectTrust has not focused a lot of energy on internal authorization policies. However, EHNAC, the recently merged cybersecurity accreditation arm to DirectTrust, does evaluate and maintain policies concerning least privilege. EHNAC also evaluates many other enterprise cybersecurity best practices.

The DirectTrust Trust Framework encompasses policies that help healthcare organizations collect digital consent from patients, which is the precursor to configuring authorization. Patients — not health systems — decide which relatives should have access to someone’s health records. Collecting and verifying consent is the mechanism used to update access authorization. This authorization should be reflected in the health system’s electronic health record (EHR), enabling other individuals access at the patient’s discretion.

Legal Implications of Consent and Authorization

Computable consent is a topic of intense debate in healthcare with many ways to achieve it. Each potential solution has benefits and drawbacks. Not the least of which is proving that someone did, in fact, consent to sharing their data at some point in time. Consent could have been received years in the past. Proving that such an event occurred in court may be a real consideration and risk for a health system.

DirectTrust considers the perspectives of many parties as it develops policies that govern the Trust Framework. There are many different stakeholders beyond core healthcare entities with an interest in this space that helps shape our policies, including release of information companies, remote online notaries, and those running clinical trials.

If you’re passionate about authorization and computable consent or if you have ideas about how to improve authorization processes within healthcare, we invite you to participate and help shape the way healthcare transactions get authorized!

This post was contributed by Kyle Neuman, DirectTrust Director of Trust Framework Development.