SBN

GUEST ESSAY: A primer on NIST 207A — guidance for adding ZTNA to cloud-native platforms

Zero trust networking architecture (ZTNA) is a way of solving security challenges in a cloud-first world.

Related: The CMMC sea change

NIST SP 800-207A (SP 207A), the next installment of Zero Trust guidance from the National Institute of Standards and Technology (NIST), has been released for public review.

This special publication was written for security architects and infrastructure designers; it provides useful guidance when designing ZTNA for cloud-native application platforms, especially those in enterprises where applications are hosted in multi-cluster and multi-cloud deployments.

I co-authored SP 207A, and it’s a great blueprint for any organization working to implement a ZTNA, whether they’re working with the U.S. federal government or not.

The 4th Annual Multi-Cloud Conference and Workshop on ZTNA is an upcoming event for anyone interested in how the federal government is advancing standards in ZTNA. The event—May 24-25; in-person and virtual—is hosted by NIST and Tetrate.

Attendees will include cybersecurity professionals, policy makers, entrepreneurs and infrastructure engineers. Registration is free and open to the public.

Useful publications

We’ve collaborated with NIST over the past four years to produce security standards in this space, resulting in several useful publications anyone can access:

•(SP 800-204A) Building Secure Microservices-based Applications Using Service-Mesh Architecture,

•(SP 800-204B) Attribute-based Access Control for Microservices-based Applications using a Service Mesh,

•(SP 800-204C) Implementation of DevSecOps for a Microservices-based Application with Service Mesh,

•(SP 800-207A) A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Location Environments (in public review)

A 10,000-Foot View

Zero trust is an approach to cybersecurity that denies access by default, granting authenticated users, devices, and applications access only to the data, services, and systems they need to do their jobs. It’s designed around the assumption that bad actors are already in the network, so it’s focused on mitigating what an attacker inside the perimeter can do via controls you can implement at runtime.

To accomplish this, we map out five runtime checks—named Identity Based Segmentation in the paper—that are made at every hop in the network. These are a minimum you should be doing to mitigate what an attacker can do even if they’re inside your network perimeter. Let’s look at each of those five.

Encryption in transit provides eavesdropping protection and payload authenticity. We want encryption in transit so no one can read sensitive data from our network traffic. More importantly, it provides message authenticity: a bad actor cannot change the data or instructions being sent.

Authentication use cases

When two applications are communicating, we want to know what those applications are. Often, we’re going to implement this using things like SPIFFE for providing cryptographic workload identity (we also get to use that identity for mTLS, accomplishing (1) at runtime too). A service mesh, like open source Istio, is a well-known way to accomplish encryption in transit and service authentication at the same time.

It’s not enough to know, for instance, that a user’s mobile phone banking app is calling their bank’s server. We must also authorize that the action the mobile app is doing is allowed on the server. Through authorization policy, we bound what an attacker can do in space: we limit how they can pivot to continue an attack across the network

It’s similarly not enough to know that the bank app running on the mobile device is allowed to talk to the bank server. We also need to know that the user is properly logged in to the application and has proven themselves to the system (they’ve authenticated themselves).

Authorization at every step

In the same way we want to authorize the banking app to call the banking server (3), we want to ensure that the user in session has the permission to take the action they’re attempting in the app – we need to make sure each action they take through our infrastructure is authorized at each step. This further helps to bound attacks in space: not only does a bad actor need to compromise an application, they also need to steal valid end user credentials with the correct capabilities to continue to pivot their attack through the network.

Butcher

To bring it all together, a common case we see is for organizations to exchange an API key for a JWT at the front door, authenticating the user as part of the exchange. Implementing Identity Based Segmentation, you must assert that the JWT remains valid and has not been tampered with at every network hop.

You then use properties of that authenticated user principle to confirm that a user remains logged in, that the action the app is executing on the server is allowed for this user, and that this communication from app to server is allowed (and that, e.g., the app is not trying to talk to a backend or database it shouldn’t). At every single hop, we ensure :

•Communication is encrypted.

•The applications communicating are authenticated and allowed to communicate.

•The user in session has been authenticated and is allowed to execute the actions being taken.

 Multi-tier policies

Importantly, in addition to these five core principles, 207A introduces the concept of Multi-Tier Policies. These are at minimum network-tier policies, like firewall and WAF, and identity-tier policies, like those you can implement with a service mesh such as Istio. By relaxing network-tier policies in exchange for adding identity-tier policies, we can maintain a same-or-better security posture while increasing organizational agility because identity-tier policies are built to be dynamic, and are easier and faster to change.

Join us on May 24 and 25 to learn how getting started with zero trust need not be a long, complex process. In fact, you can get started rather quickly, deploying real improvements quickly that deliver a measurable ROI. Given the need for security concepts that protect systems and data from attackers that are already in the network, zero trust should be something that every organization in a regulated or data-sensitive industry is taking steps toward embracing, sooner rather than later.

About the essayist: Zack Butcher is  the founding engineer of  Tetrate, which helps platform teams and developers safely and reliably transform their infrastructure for the modern, multi-cloud era.

*** This is a Security Bloggers Network syndicated blog from The Last Watchdog authored by bacohido. Read the original post at: https://www.lastwatchdog.com/guest-essay-a-primer-on-nist-207a-guidance-for-adding-ztna-to-cloud-native-platforms/