The zero trust information security model, which denies access to applications and data by default, is a strategic differentiator and a mission imperative, as agencies strive to meet requirements laid out in Federal strategies and mandates. In a new interview with MeriTalk, Brandon Iske, a principal solutions architect at identity platform provider Okta, and Bill Wells, a senior solutions architect at cloud provider Amazon Web Services (AWS), evaluate the successes and challenges that agencies are experiencing as they implement required identity protections and offer advice and best practices for agencies as they continue to plan and implement components of their zero trust architectures.
MeriTalk: Identity is the first pillar in Cybersecurity and Infrastructure Security Agency’s (CISA) Zero Trust Maturity Model, and user is the first pillar in the Department of Defense (DoD) Zero Trust Capabilities Roadmap. Does this mean identity takes priority over the other pillars, and if so, why?
Brandon Iske: Identity is a foundational capability that enables the other pillars in the CISA and DoD models, and therefore, it can have the most impact, if it’s done well. Identity’s priority is a little bit subjective, depending on where folks are on their identity journey. For agencies that have been operating a legacy, on-premises environment for decades, identity may be a high priority. Agencies that have already moved to the cloud have seen the criticality of modern identity, and how it can be a huge enabler to improve security and usability. For those folks, identity is still important, but they might prioritize resources and new activities on the other pillars.
Bill Wells: The best security doesn’t come from making a binary choice of identity or network protection, but rather layering them together, so they can augment each other. For example, AWS VPC endpoints can layer in both network and identity controls.
MeriTalk: Based on your work with Federal civilian and defense agencies, what successes are you seeing as agencies work to implement the identity protections called for in the Federal Zero Trust Strategy and the DoD Zero Trust Strategy?
Iske: Identity and access management is a strategic focus in most ICAM (identity, credential, and access management) programs. Most agencies have an identity platform, are looking to procure one, or are in some phase of implementation.
We are seeing rapid expansion of phishing-resistant multifactor authentication (MFA) in response to the Federal Zero Trust Strategy, M-22-09, and in response to malicious activity. Obviously, we don’t want to be in a reactive or firefighting position, but we are seeing opportunities for quick response as well as strategic investments.
Wells: Agencies are looking to centralize their identity and then bring that forward to AWS for access. So, they’re strongly authenticating with their enterprise identity provider, such as Okta, and then bringing that to AWS, where they can manage the authorization to resources.
MeriTalk: What challenges are you seeing as agencies bring their identity protections together?
Iske: Consolidation of capabilities can be challenging. If agencies haven’t consolidated their identity protections on premises, moving to the cloud is going to be a big lift as they try to enable stovepiped capabilities in a centralized fashion.
Wells: To reinforce that – the customers we work with are often operating at massive scale with a lot of historic infrastructure. It is challenging for them to even be aware of all of the security services they currently operate, which they could leverage to implement architectures that allow them to achieve zero trust outcomes. They also may not be aware of all the resources they have that support a function because there’s so much siloing. If you have identity spread across a multitude of teams that manage it, consolidation can be challenging.
Iske: Agencies and departments can face an overwhelming number of requirements. Prioritizing those requirements and focusing on the key objectives or outcomes that you are trying to achieve under zero trust are big challenges. And frankly, sometimes the highest priority requirements are also the hardest problems to solve. So, it’s a balance between improving security and usability, and having demonstrable wins as well along the way.
MeriTalk: Okta specializes in identity protection. Tell us a little bit about how Okta helps agencies meet their zero trust requirements.
Iske: Okta helps agencies address critical identity and access management functions. The first one is authentication. Today, in most of the Federal space we have Personal Identity Verification cards, Common Access Cards and certificate authentication, as well as passwords and some MFA. With M-22-09, agencies were instructed to adopt phishing-resistant MFA.
Typically, that is still going to require either PIV, CAC or a FIDO or WebAuthn credential. We support all of these options as phishing-resistant MFA to help agencies strengthen how users authenticate, and to provide choices in how users authenticate. Part of the zero trust movement is about offering multiple options for phishing-resistant authentication. Maybe I use a smart card for critical mission applications or human resources, but maybe I don’t need it for email or other basic collaboration capabilities. It’s about tying the right level of assurance to the right access.
The second function is identity stores, where users, roles, and permissions are managed. Okta centralizes user identities and attributes through a universal directory and secure policy engine that sets consistent, context-based access policies. It’s critical to have a central point of view of what users have access to. If you have fragmented identity, or you manage it at the individual application layers, it’s hard to have centralized visibility and enforcement.
The third functional area is risk, or contextual authentication. We help agencies move away from a binary, yes or no answer about whether the user has a valid authenticator. We help them assess additional context, such as whether the user is on a managed or unmanaged device, what network they are on, and the health of the device.
We also help ease the transition to an identity platform with the Okta Integration Network, which enables agencies to integrate third-party applications. That’s how we integrate with AWS in their IAM Identity Center, for example. Users get the Okta sign-in experience with AWS, and administrators can configure roles and access centrally in AWS IAM Identity Center across multiple AWS accounts.
Also, we just launched our FedRAMP High service. We’ve had our Moderate service for many years now, and last fall we launched our DoD Impact Level 4 service. So, we have DoD unclassified covered, and the two big cloud certifications in the Federal civilian space.
MeriTalk: Bill, how is AWS helping agencies achieve zero trust?
Wells: We are working with customers to understand the zero trust outcomes they want and show them how they can use AWS services and our best of breed partners to achieve those. Our team works closely with our partners, like Okta, to address DoD use cases. For example, we are working toward a proof of concept for zero trust outcomes at the tactical edge. It uses a Snowball Edge computing and storage device, and it involves partners including Okta. From a service perspective, we offer building blocks to agencies so they can piece together multiple services to achieve specific outcomes.
We’re also offering some services that are built on zero trust principles and address specific use cases. For example, AWS Verified Access addresses workforce mobility and ease of use. It integrates with identity and device management services, and using data from these services, it verifies the trustworthiness of users and devices against defined security requirements to determine whether the user should have access to an application.
MeriTalk: Can you tell us a little bit more about Okta’s integration with AWS?
Wells: AWS supports open standards-based protocols like Security Assertions Markup Language (SAML) and System for Cross-domain Identity Management (SCIM), so agencies can easily integrate their workforce identities in the Okta identity platform with AWS services, including AWS IAM Identity Center. They can manage their workforce users and enforce strong identity requirements centrally in Okta, and then assign and manage permissions centrally in AWS IAM Identity Center across their AWS accounts and resources. AWS IAM Identity Center recently achieved FedRAMP High status in GovCloud – and agencies that are looking for FedRAMP High compliant services can use that service to integrate Okta with AWS, and vice versa.
The AWS Marketplace makes it easy to get started, too. Agencies can provision their licensing through the marketplace and then start using Okta immediately.
Iske: The Okta Integration Network offers more than 7,000 applications that we can integrate with; AWS is one of the largest. We want to create great experiences, so we integrate with vendor application programming interfaces and also support SAML, SCIM, and OpenID Connect. So, if an integration hasn’t been built, we can rely on those common standards. And by adopting open, interoperable standards, we can share signals across applications and devices.
MeriTalk: What is the benefit of shared signals?
Iske: From a zero trust perspective, shared signals provide more context about risk. For example, if I have an endpoint detection capability and it sees some nefarious behavior, shared signals could trigger a security information and event investigation and quarantine the device, the user, or their permissions. It’s about trying to act in a near real-time basis.
MeriTalk: Zero trust isn’t one technology solution. It’s a mindset. It’s also a set of capabilities enabled by multiple products and services and integrated to form a complete solution. What advice do you have for agencies as they evaluate products and services to build this complete solution?
Wells: It’s best to think of zero trust concepts as additive to existing security controls and concepts. You don’t have to rip and replace what you already have. My advice is to be aware of your existing products and services that may address the use case you’re trying to achieve, understand the gaps in those products and services, and learn how those gaps can be closed with other products. AWS has a robust marketplace where agencies can search for services and products to address their security gaps.
Iske: Defining and prioritizing use cases and achievable outcomes is critical.
MeriTalk: For agencies that have taken initial steps towards zero trust, but still have a ways to go, what best practices can you recommend as they continue to plan and implement components of their zero trust infrastructure?
Wells: Make sure you’re not getting mired in low-value discussions about “Is this zero trusty enough?” Prioritize your efforts on the criticality of what you’re trying to protect, and where that effort is commensurate with the benefits that you’re achieving. Zero trust touches on so many aspects that it shouldn’t be worked on in silos. Try to ensure that your efforts are coordinated across the whole of IT or a whole team effort.
Iske: I agree. The cross-cutting nature of zero trust makes it challenging. Having senior champions to help break down barriers is important. You need visibility into activities that are happening across an organization or a department. Many activities may look and feel similar, but they may have a different scope. You need to understand and communicate that, whether you’re talking to your internal customers or up the chain of command. That’s how you make sure folks aren’t duplicating efforts, ensure efforts are aligned to achieve security outcomes, and share lessons learned.