Jesse Trucks is the Minister of Magic at Splunk, where he consults on security and compliance program designs and develops Splunk architectures for security use cases, among other things. He brings more than 20 years of experience in tech to this role, having previously worked as director of security and compliance at Peak Hosting, a staff member at freenode, a cybersecurity engineer at Oak Ridge National Laboratory, and a systems engineer at D.E. Shaw Research, among several other positions. Of course, Jesse is also the host of Meanwhile in Security, the podcast about better cloud security you’re about to listen to.

Jesse: Welcome to Meanwhile in Security where I, your host Jesse Trucks, guides you to better security in the cloud.

Announcer: This episode is sponsored by ExtraHop. ExtraHop provides threat detection and response for the Enterprise (not the starship). On-prem security doesn’t translate well to cloud or multi-cloud environments, and that’s not even counting IoT. ExtraHop automatically discovers everything inside the perimeter, including your cloud workloads and IoT devices, detects these threats up to 35 percent faster, and helps you act immediately. Ask for a free trial of detection and response for AWS today at extrahop.com/trial. That’s extrahop.com/trial.

Zero Trust is everywhere and nowhere. Over a decade old, Zero Trust feels like a new thing for many of us, but this feeling is likely because most of us experience or manage operational security methodologies following various forms of old-school trust and access models. In these models, a user or service authenticates to a network or service and gets all the things granted to them by their role or account permissions. This is often referred to as a trust but verify paradigm. Many organizations still use Virtual Private Network, or VPN, access mechanisms to connect from the outside to internal or trusted networks.

Accessing these internal or trusted networks provides access to a variety of systems with low to moderate security generally available to anyone granted access to the associated network. Each user accessing these networks is authenticated in some manner and then is trusted with the ability to connect to available resources. This is like many corporate office buildings: badge in or show ID to the security desk in the lobby, and you are granted access to wander the halls at will, with access to nearly any floor and office. In many modern office buildings, especially those with multiple tenants, there might be sections of the building that require additional verification using a badge reader or being cleared by guards at another security desk. This is like network segmentation trust models where each user must be granted specific access to certain networks.

Much like accessing different companies in the multi-tenant building works by being cleared by the front desk or using badge readers to unlock the doors and being granted access to all of the offices they’re in, access to resources and services on these network segments is controlled at the entrance by firewalls and/or authentication gateways. While most services today require authentication to get beyond the front door, similar to the network segmentation model but on an application or service level. Usually, there are static definitions of access granted to each user although most applications and services rely on role-based access controls or RBAC, these roles are statically defined with access to a list of resources, services, or capabilities for all users given that role. Searching network segmentation best practices finds dozens of results over the last couple of years with great advice on segmenting networks and limiting access to resources on those networks. Much of it is similar to one another and generally good advice to follow. I like to think of access to networks, resources, and services as being on a need-to-use and access to data on a need-to-know basis. Zero Trust upends the entire access model.

In June of 1993, IEEE published GJ Simmons’ article, “An introduction to the mathematics of trust in security protocols,” which, as the title implies, defines a mathematical approach to calculating trust in the context of computer systems. This concept opens possibilities for automating complex access authorization schemes. In 2009, while working as an analyst for Forrester Research, John Kindervag published a white paper titled “No More Chewy Centers: The Zero Trust Model Of Information Security,” outlining the Zero Trust model as a new paradigm for controlling access to resources and services.

Implementing a Zero Trust model creates the ability to dynamically grant access to resources and services based on real-time context, not statically defined need-to-use and need-to-know bases. Going back to the office building analogy, this is like the security station guards verifying things that are currently true before allowing you to access the building or any of the building spaces. For example, they could confirm you are currently employed by a tenant of the building and give you an access card that is good for one-time entry into your organization space. However, if you leave your offices and need to return, you have to go back to the security station to get another one-time entry pass to your suites. Even if you never leave the building, you still must go down to the security station to get your one-time access pass.

If you need to visit another space in the building, the security station guards would verify you have an appointment that grants you access to a different space, and they would give you a one-time access pass to enter those spaces. Once again, when you need to return to your own offices, you must go back for another pass to get in. This is exactly how Zero Trust works.

In an ideal Zero Trust world, every time you must access a network, resource, or service, you must also authenticate in some way to both verify your identity and to obtain authorization to access the network resource or service. This goes beyond having a token to use for multiple transactions, like when we store a website cookie or token to skip logging in when we return to a site. Instead, the site would require authentication for access authorization every time we return. In a realistic Zero Trust Architecture, or ZTA implementation, a cookie or token stored for a single session to skip login for every single page or image access is useful, but in a strict ZTA implementation, there would be an authentication action for every single file access even within the context of a site’s single page load with graphics.

Announcer: If you have several PostgreSQL databases running behind NAT, check out Teleport, an open-source identity-aware access proxy. Teleport provides secure access to anything running behind NAT, such as SSH servers or Kubernetes clusters and—new in this release—PostgreSQL instances, including AWS RDS. Teleport gives users superpowers like authenticating via SSO with multi-factor, listing and seeing all database instances, getting instant access to them using popular CLI tools or web UIs. Teleport ensures best security practices like role-based access, preventing data exfiltration, providing visibility, and ensuring compliance. Download Teleport at goteleport.com. That’s goteleport.com.

The US National Institute of Standards and Technology, or NIST, published the Special Publication, 800-207, “Zero Trust Architecture” to define how to implement ZT. I recommend NIST ZTA as a foundation for your approach to, or at least understanding of, an operational ZTA implementation in the absence of other guidance from a reputable source. To implement ZT takes some basic components, and at the heart of it all is the policy engine.

The policy engine contains the rules to determine whether to grant or deny authorization for an account to access any particular resource or service. These rules should contain contextual parameters such as the device and network being used to initiate the request, or whether an account is in a watchlist or is otherwise at a higher risk level or in a different risk category than it usually is at the time of the request. For example, if I require access to HR records to perform my job duties, by default, my account would be granted access to the HR system providing those records. However, whether I am granted such access for a particular request should depend on the device I’m using, the network my device is using, and the current risks associated with the device, the network, and my account. In this situation, if I used my organization-issued laptop to connect to the VPN, the policy engine could grant me access to the HR system which provides me access to the HR data.

However, if I used my personal smartphone from a public network and the security monitoring systems show anomalous behavior associated with my account, the policy engine should deny my access to the HR system. There are myriad ways to architect a ZTA solution and there are a number of reliable vendors with policy engines or whole CTA service offerings available as either implementation or ongoing managed services.

I strongly suggest you review your environment to see where Zero Trust is already in place or ought to be implemented. At the very core of a Zero Trust implementation is the ability to quickly change access rules for accounts connecting to resources or services. This can be done in simple or complex ways. In the next episode, I will explore Zero Trust architecture implementation in much more detail.

Jesse: Thanks for listening. Please subscribe and rate us on Apple and Google Podcast, Spotify, or wherever you listen to podcasts.

Announcer: This has been a HumblePod production. Stay humble.