Following up on the May 2021 executive order (EO), which requires Federal agencies to adopt zero trust, the Office of Management and Budget (OMB) issued memorandum 22-09 (M-22-09) in January 2022. It sets forth a Federal zero trust architecture strategy, requiring agencies to meet specific cybersecurity objectives by the end of 2024. M-22-09 also provides specific direction for implementing identity-driven security measures such as multi-factor authentication (MFA) to prevent sophisticated online attacks.
What do the memo’s requirements mean for Federal agencies? How can they best implement zero trust? What exactly is “phishing-resistant MFA”? MeriTalk sat down with Bryan Rosensteel, U.S. Federal CTO at Ping Identity, to get the answers to these questions and learn how agencies can best institute zero trust.
MeriTalk: M-22-09 specifies certain conditions that Federal agencies must meet by the end of 2024. How much of a challenge will it be for agencies?
Rosensteel: That is an intensive timeline. And some aspects of zero trust must be accomplished even sooner, such as phishing-resistant MFA, which has a one-year deadline.
Fortunately, agencies aren’t starting from scratch. If we look at phishing-resistant MFA, the government has spent more than two decades investing in the best enterprise-grade authenticators, which happen to be phishing resistant: the personal identity verification (PIV) card and the common access card (CAC). Agencies don’t have to stand up that infrastructure, and they know how to work with it.
The tricky area is making sure those authenticators can operate with their applications across the board. Organizations must understand where MFA needs to be, and they must have central communication to identify and address all the use cases. In the past, edge use cases – where PIV and CAC have struggled – have been filled piecemeal by different groups in an agency or department, instead of centrally.
Ultimately, M-22-09 gives the framework to put the pieces of zero trust together and the Technology Modernization Fund can pay for it. Ping is actively working with the government and bringing in technology partners because no one solution will deliver all of M-22-09. We need to work together.
MeriTalk: What makes MFA resistant to phishing?
Rosensteel: Phishing-resistant MFA requires a physical interaction with the user during the actual authentication, and proximity to the device where the authentication is occurring. For example, I need to insert my PIV into a card reader for proximity-based contact and then enter the pin. It can’t be done remotely.
Contrast that with the following scenario: A bad actor puts up a fake site for a relay-style attack. A one-time passcode (OTP is relayed to the legitimate website; everything looks good. But when the legitimate user is finished on the site, they are still logged in without realizing it. This is because there is no proximity-based requirement for that OTP authenticator, and the actual authentication is occurring from outside of the device where the user is authenticating.
That doesn’t happen with a PIV card because the attacker can’t send an authorization to your card when you’re not in front of that computer and using the pin. So it’s significantly harder to phish a PIV or CAC card.
MeriTalk: OMB’s memo calls for centralized identity management systems for agency users that can be integrated into applications and common platforms. Do you have advice for agencies as they work to achieve this?
Rosensteel: The first – and hardest – step is the culture part: getting your stakeholders to the table and understanding your use cases. The government is really making strides there. We’ve been on meetings with more than 100 individuals across an agency. That’s phenomenal. Usually, we’re just dealing with small groups.
The next part is figuring out what centralization means. I recommend a master user record—a directory or user store combining all user attributes. That does not mean that I stand down all other directories and data stores. It means breaking down the walls surrounding them, so information can flow centrally and I have a lot more information to use for stronger authorization decisions. Then, we can apply a centralized policy engine, or control plane, to the master user record to make policy enforcement decisions.
You will not have one-size-fits-all central management; some systems require a separation. The key is to determine what can and cannot be centralized.
MeriTalk: What are some of the biggest dangers of siloed identity information, and how does Ping Identity reduce those risks?
Rosensteel: Identity silos are dangerous because they require a manual rectification of accounts, and humans, even really good admins, are prone to error. One of the best-known examples of identity silo problems is Colonial Pipeline. Their legacy virtual private network had a privileged account that was hacked; the username and password was compromised. While it is true that the account did not have MFA enforced, the bigger issue is that the account had not been in use for several months.
That account should have been deactivated. If they had that central management to ensure deactivation everywhere, even with a compromised username and password that didn’t have MFA, the attackers couldn’t have logged in.
So, how do you break down identity silos? In some cases, you can combine or eliminate redundant datastores and directories, but there may be use cases where that is not possible, where some separation is required. An example could be with citizen-facing applications, where an agency might not want contractors or citizens validating against its centralized repository. For these use cases, data synchronization is helpful, and allows for centralized enforcement but keeps the working directory data separate.
Also, centralizing authentication and authorization policies limits over-privileging users. This happens in a number of different ways, but essentially you end up with users having far more access than they should, without a scalable way to rectify this from an administrative perspective. With a central source of truth, you can manage data around least privilege access.
MeriTalk: Network segmentation prevents users from going wherever they want, but some systems must be interoperable among government agencies. How can agencies reconcile the segmentation requirements of zero trust with the need for systems to be interoperable?
Rosensteel: This is why Ping Identity says identity is the new perimeter. You want to collapse the perimeter from the broad network down to the application level so you can do your identity interrogation at the application instead of the network.
In fact, M-22-09 is forcing this. There’s a line in the memo that made my eyes pop out of my head: “In the near term, every application should be treated as internet-accessible from a security perspective.” That doesn’t mean the general public gets to log in, but you can hit it from the internet. OMB is saying: Stop sitting behind your network perimeter walls; put applications out there and protect them so that only the right people access them.
Agencies are used to strong network-based perimeter defenses such as firewalls, and that usually throws a few wrinkles into interoperability. Basically, it’s hard to authenticate from agency to agency if you can’t get to the application without being on the other agency’s network. This also makes remote work more difficult as well, and it is something many departments and agencies have been trying to solve.
Now, an application could be configured to accept multiple identity systems, which is easier because you don’t have the network authentication challenge. That is the interoperability the government always wanted, and it makes remote work much easier to enable and govern.
MeriTalk: OMB requires agencies to move to attribute-based access control (ABAC) from role-based access control (RBAC). Why is ABAC better at ensuring cybersecurity?
Rosensteel: M-22-09 specifically says agencies need to switch away from RBAC, which is very limited. What department am I in? What role do I have? Am I a privileged user? Traditionally, authorizations were built around those limited attributes.
Digital identity is a combination of the person behind the keyboard, the other elements they use to authenticate, and the context of their access, such as location, device type, and sensitivity of the resource they’re trying to access. ABAC looks at all these attributes to authenticate and make authorization decisions. Bringing in those different contextual pieces lets you do pretty sophisticated things.
Here’s one example: It’s possible to set up a master user record with all the user’s attributes that connects to a physical access control system. When I badge into a building, it creates an associated attribute that I am in the building, so that can be part of the authorization decision process. Perhaps I can access a specific resource only when I’m in this location. That’s the power and flexibility that ABAC affords.
I’m getting excited, because the trade winds are flowing toward the more sophisticated controls that we’ve been wanting for a long time. Authentication gets you in the door of an application; authorization is what you can see and do. It’s easy to say that, but you need these controls to enforce it. And we’re getting closer to that reality.