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.

Show Notes:

Links:

• An introduction to the mathematics of trust in security protocols: https://ieeexplore.ieee.org/document/246634
• No More Chewy Centers: The Zero Trust Model Of Information Security: https://www.forrester.com/report/No+More+Chewy+Centers+The+Zero+Trust+Model+Of+Information+Security/-/E-RES56682
• 800-207, “Zero Trust Architecture”: https://csrc.nist.gov/publications/detail/sp/800-207/final

Transcript

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 authenticat...