Blog Inforeseau.com – Alexandre Blanc Cyber Security

My take on Zero Trust – SP 800-207

Published by in 2019, copied from my initial linkedin article to here

Zero Trust, this hot topic..

There is a growing and needed noise about Zero Trust, and all of this is either very conceptual, or commercial, so I felt the need to go through the NIST special publication 800-207 to get my own take on this.

This is mostly a paraphrasing of NIST publication, but writing this, allows me to put things together in my mind, and maybe, it will drive your curiosity toward coming Zero Trust journey.

The very first points that drove me nuts about Zero Trust discussion in the place, are all the acronyms used to speak about this. While people aware of the topic really enjoy using them, it’s kind of killing the concept accessibility for newcomers on the topic.

Zero Trust – Acronyms

lI’l break down the mostly used acronyms related to Zero Trust below (keep this on a post-it with you, so you can catch up on the fancy hot topic discussions ) :

ZTA – Zero Trust Architecture (or Zero Trust Network Architecture)

ZTN– Zero Trust Network

ZTE – Zero Trust Ecosystem

ICS – Industry Compliance System

FISMA – Federal Information Security Management Act

RMF – NIST Risk Management Framework

FICAM – Federal Identity, Credential, and Access Management

TIC – Trusted Internet Connection

CDM – Continuous Diagnostics and Mitigation (What is connected ? Who is using the network ? What is happening on the network ? How is data protected ? )

PDP – Policy Decision Point (can be broken in 2 logical components, PE – Policy Engine and PA – Policy Administrator)

PEP – Policy Enforcement Point

MFA – Multi Factor Authentication (2FA, 3FA and so on depending on the amount of factors involved)

CSA – Cloud Security Alliance

SDP – Software Defined Perimeter

PA – Policy Administrator

PE – Policy Engine

TA – Trust Algorithm

NPE – Non-Person Entities (Usually in ZTA administration)

NCPS – National Cybersecurity Protection System (aka EINSTEIN)

HWAM – HardWare Asset Management

SWAM – Software Asset Management

HVA – High Value Assets

NIST – National Institute of Standards and Technology

SIEM -Security Incident and Event Monitoring

FCAPS – Fault, Configuration, Accounting, Performance and Security

VUCA – Volatility, uncertainty, complexity and ambiguity (more here)

CGM – Comprehensive Governance Model – As CDM (Continuous Diagnosis and Mitigation) is like CGM but without the network design creating the isolated communication paths to handle MFA (multi factor authentication) through yet another lacking function of CDM compared to CGM. CGM PaaS is effectively a CDM (Thanks to Dennis Di Toro for his permanent support on the concepts)

Though CGM is itself a concept for frame work

Think of PaaS as a single lens to the entire digital domain

Note : Most acronyms are available on page 44 in Appendix A of the SP800-207 Document

Walk through ZTA in NIST 800-207

An operative definition of ZTA

Zero Trust Architecture (ZTA) provides a collection of concepts, ideas, and component relationships (architectures) designed to eliminate the uncertainty in enforcing accurate access decisions in information systems and services

ZTA is about resources (system, data, application) access and not just data access : Resources are all the digital assets, tools, storage, devices etc, available in the architecture.

Zero Trust applies on authentication and authorization : Authentication and Authorization are 2 different steps, and ZTA break this down to achieve its control goal. Who is requesting, What is requested, and from there, is the « who » allowed to access the « what » (to be verified on a permanent basis).

The PDP (Policy Decision Point) and PEP (Policy Enforcement Point) applies a common set of controls such as all traffic beyond the checkpoint has a common level of trust (see this as a micro segment of your network).

All communication should be done in a secure manner (encrypted and authenticated) at all level and all time, as there is no perimeter anymore.

– Policy Engine (PE) is responsible for the ultimate decision to grant access to a resource for a given client or subject (based on many inputs, such as IP Blacklists, threat intelligence services).

– Policy Administrator (PA) component is responsible for establishing (applying allowance from PE) the connection between a client an a resource.

– Policy Enforcement Point (PEP) is responsible for enabling, monitoring and if need be, terminating connections between subject and enterprise resources.

– Continuous Diagnostics and Mitigation (CDM) system(s) gathers information about system’s current state and apply updates to configuration and sofware components (Feed the CDM about either system making access request is running appropriate security level, if system has known vulnerabilities etc.)

– Industry Compliance System (ICS) make sure enterprise remains compliant with regulation (FISMA, HIPAA, PCI-DSS etc.)

– Threat Intelligence Feed(s) (TIF) – provide information from outside sources that help Policy Engine make access decisions. (attacks, vulnerabilities, DNS blacklists, new malwares, blacklisted C&C)

– Data Access Policies (DAP) – Policies defining how access can be granted to resources (requirements/rules) in the Policy Engine, or auto generated by Policy Engine

– Enterprise Public Key Infrastructure (PKI) – system managing certificates issued by the enterprise, including the global CA ecosystem and Federal PKI, which may be integrated with the enterprise PKI (should the enterprise system consider external certificates or not)

– ID Management system – responsible for creating, storing and managing enterprise user accounts and identity records. Works together with PKI.

– Security Incident and Event Management (SIEM) System – Basically all the logs centralized to allow analysis and alert and report security posture

Deployment scenarios of ZTA

How Zero Trust implementation can take place in different deployment contexts.

Device Agent/Gateway-Based Deployment

Match a situation where all the infrastructure and devices are organization managed, any connection between resources is orchestrated directly through the PEP (Policy Enforcement Point), basically, each access request goes through a smart ACL. No BYOD here, as all the infrastructure is deployed including needed tools to enforce policy.

Microperimeter-Based Deployment

This approach is kind of network micro segmentation, where the control is placed around small perimeters. It is used to cover legacy systems which do not offer integration with PEP (Policy Enforcement Point), and where access control must be managed from an external resource. Issue is, the security here is only efficient to protect the perimeter, so it does allow lateral movement in the perimeter in case of corruption of any resource. This approach could be combined with the previous one, so as lateral movement would be more restricted, but systems requiring access to the legacy system could still achieve lateral movement (in an attack scenario). Issue in this model is that clients could see resources which they are not supposed to see. Client are still managed in this setup.

Resource Portal-Based Deployment

This is the first approach that does not require the client devices to be organization controlled. Therefore, it’s the way used to publish application open to third parties. In this approach, the control is applied at gateway level where PEP (Policy Enforcement Point), does ensure the requirement and restrictions are met. The enforcement may only happen from the client connection, to the infrastructure. This is the typical approach for BYOD, as the client device is not under organization control. This also requires the gateway to be widely exposed, and therefore open to DoS attacks (no authentication is required to attempt a connection)

System Application Sandboxing

Trusted applications run compartmentalized on systems (either in VMs, containers, or other sandboxing implementations), with the main goal of limiting impact that an app corruption can have to itself only, and hopefully, only on the dataset portion it is supposed to access. The Policy Enforcement Point (PEP), will grant access to needed resources for the compartmentalized application, only for allowed applications (I don’t like to use the word « trust » to describe how « Zero Trust » is supposed to work, Kind of nonsense :P ). This is a good approach because apps are isolated from system, and from other apps. When client systems run sandboxed apps, the drawback is that the actual distribution model doesn’t allow to audit the client system for requirements, as the app itself is isolated.

Trust Algorithm in ZTA

It’s kind of funny to have a « trust algorithm » in zero trust environment. It’s flying close to a divide by zero, but ok, you get the point, this is more like a risk rating approach.

Access granted or not

This is the process that decide if an access is granted or not. It’s based on multiple evaluation factors :

Access Request

The actual request, made of requestor info (client device info etc), and the requested target

User Identification, attributes and privileges

Figuring « who » in the trust equation, is attempting to access a resource, all the attributes belonging to an individual/user (id, password, biometric data, localization, voice attribute etc).

System database and observable status

The actual organization systems inventory, including its current and expected status checked against access request

Resource access requirements

These are resource centric requirements (policies) to be allowed to access a resource. Does the requestor provide required attributes to access the resource (login, IP Range, MFA used,etc.)

Threat intelligence

Is the current request matching any kind of existing threat or ongoing attack campaigns, most likely relying on third party feeds, can contain attacks signatures and mitigations.

The Policy Administrator (PA), determine which above criteria are requested and if they pass the requirements or not. The Policy Administrator configure all the PEP (Policy Enforcement Points) to enable the connection. The PA must also implement connection termination policy (timeout, end of workflow etc).

Trust Algorithm Variations in ZTA

I would rather call the « Trust Algorithm » something like « risk rating », because in Zero Trust, I see risk evaluation and assessment, not trust :D

Each implementation of Zero Trust Architecture (ZTA) differ as the weight of the factors vary accross organizations. Is it binary factor, pass or fail, or score based evaluation (quality of identification or device assessment etc).

Criteria VS score based

Either the client sending request match all required criterias, or get access refused, OR, each attribute of the client weight in the total score, which must be above a certain threshold to get access granted. These attributes requirements, are resource based.

Singular VS contextual

Singular will take each request as fresh and ignore previous ones, match is pass, no match is drop. Contextual will take in consideration the other requests from a user/client, and compare against previous requests. Previous login activities are compared, and behavior analytic may trigger different behavior if an anomaly is detected (ie – 2 logins requests, at almost the same time from distant locations).

During ZTA deployment, adjustments are needed, a tuning phase is required to adjust to real case scenarios.

Network Components in ZTA

Basic and old topic, you need a separation (physical or logical) between communication flows used to configure and control (manage) the network, and the application communication used to perform the actual work of the organization.

Usually broken down to « control plane » for network and control communication, and « data plane » for application communication flows.

Network requirements to support ZTA

Here is what it takes to support ZTA from a network perspective. As you’ll see, this is a new concept that moves out of perimeter concept, to resource security oriented concept. It is indeed a much more granular approach, compared to existing legacy systems.

– 1. Enterprise systems have basic network connectivity

– 2. The enterprise must be able to determine which systems are owned or managed by the enterprise and which devices are not owned or managed

– 3. The enterprise can capture all network traffic

– 4. Enterprise resources should not be discoverable without accessing a Policy Enforcement Point (PEP).

– 5. The Data Plane and Control plane are logically separate.

– 6. Enterprise systems can reach the Policy Enforcement Point (PEP).

– 7. The Policy Enforcement Point (PEP) is the only component that can access the Policy Administrator (PA) and Policy Engine (PE).

– 8. Remote enterprise systems should be able to access enterprise resources without needed to traverse through enterprise infrastructure (no more VPN concept, direct secured application access).

– 9. Enterprise systems may not be able to reach certain Policy Enforcement Points due to observable factors.

« As enterprises move to more cloud-hosted applications and services, it becomes apparent that relying on the enterprise perimeter for security becomes a liability. »

Zero Trust Architecture Associated Threats

You’ll find below a list of threats related to ZTA, that should be considered when heading toward your Zero Trust journey.

– Subversion of Zero Trust Architecture (ZTA) Decision Process

– Denial-of-Service (DoS) or Network Disruption (counter measure is replicate Policy Enforcement across infrastructure and sites)

– Insider Threat (reduced scope of attack by MFA and contextual trust algorithm, but still)

– Visibility on the network (in most case, we can’t have full network visibility, and this is more and more a fact with remote infrastructure), only traffic out of enterprise owned system should be monitored, as the internal one totally falls under Policy Enforcement Points (PEPs)

– Storage of Network Information – Obviously, security by obfuscation helps in ZTA, if actual network diagrams or policies are not protected, they offer a wide range of information on the attack surface (policies design flaws most likely to be identified this way)

– Reliance on Proprietary Data Formats – As with existing architectures, non standard and interoperable format are a threat to organizations. Interoperabiity and standard communication across Zero Trust Architecture (ZTA) is a key point to achieve a reliable long term viable solution.

– Use of Non-Person Entities (NPE) in ZTA administration – AI and other software based automation agents, are an issue because their authentication requires a bypass of most essential security controls. Such tools ending corrupted by attackers would lead to corruptions of Zero Trust Architecture integrity (agent impersonation)

The list above gives you a good idea of the potential issues we might face in Zero Trust implementation.

Overall considerations in regards to ZTA

Wile I approach above the conceptual base of ZTA according to NIST 800-207, there is a long way ahead toward Zero Trust goals actual implementation.

You may also want to check point 6 of NIST 800-207 draft, in regards to Zero Trust Architecture and Existing Federal Guidance (page 33 of https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207-draft.pdf ).

Check point 7 of NIST 800-207 draft, in regards to Migrating to Zero Trust Architecture (page 37)

Reaching ZTA, is a long path, but there are a lot of steps toward this goal, and each of them actually enhance your security posture.

As an initial step, check the Risk Management Framework (RMF) [SP800-37] as this is the first step to reduce risk before even looking into Zero Trust : https://csrc.nist.gov/publications/detail/sp/800-37/rev-1/final

Now, as we can read appendix B of NIST SP 800-207 publication, the current state of the ZTA ecosystem is not mature enough for widespread adoption.

We can also read that ZTA is well designed for cloud use as it aims to make the security posture adjusted out of perimeter security. While ZTA is suitable for this environment, it is highly transactional and NIST publication very well put the fact that « even cloud services have been known to become unreachable either through an attack or simple error ». When this happens, due to ZTA nature, work can no longer be achieved. (see page 48 of SP800-207).

Just lately, we faced an 8 hours DDoS on AWS which made the infrastructure unavailable, so ZTA definitely needs some asynchronous tools, with buffering capability to remain operational in a way, but without jeopardizing its secure concept. As we introduce flexibility, it comes with an augmented attack surface, therefore, there’s a trade-of to consider in here too. (https://www.techradar.com/news/aws-hit-by-major-ddos-attack)

Next step on your ZTA journey, is not a super shiny magical box that will come as turn key solution, as ZTA concept, as you saw above, is a new approach, and require to compose with legacy setup, while not disrupting production.

You may already have bunch of ZTA ingredients in your actual security posture, and the ZTA definition will help you strengthen your situation over the years.

Unlike some articles state, ZTA does not allow your to ignore backups, redundancy etc. Some will say firewalls are no longer needed in ZTA, well, to me this is more like the use of smarter firewalls that will allow the required micro segregation. The coming software defined network, is all about being a huge integrated smarter firewall. SDN will definitely help achieve the Zero Trust journey.

I don’t know if this article will help you catch up with Zero Trust, but it did definitely force me to do so.

I hope it did shade some light, hopefully in a quicker read than the full special publication 800-207 !