Zero Trust Architecture (ZTA) is a security concept that assumes that all network traffic is untrusted and must be verified before it can be allowed access to sensitive resources. The traditional approach to cybersecurity, known as the “castle and moat” mentality, assumes that a perimeter defense is sufficient to protect the network and its resources. However, this approach has been shown to be not sufficiently flexible and secure by itself in today’s fast-paced, highly connected world. For example, many vulnerabilities are able to be exploited simply by making a network connection prior to authentication. Other types of software flaws allow unauthenticated access to certain data like metadata or headers in a network stream, which can give away enough information for an attacker to start exploiting the data. In recent years, organizations have begun to adopt a new approach to cybersecurity known as Zero Trust. This uses a security model that assumes that all network connections and communications are untrusted and must be verified before access is granted. This approach to cybersecurity is becoming increasingly popular as organizations seek to better protect against the growing threat of cyber attacks. What is Zero Trust and what are the architectures that support it? Does it work in tandem with traditional network security or is it a complete replacement (in other words: re-architecture for existing environments)? Do we still need firewalls and subnets? I will address this in this Part I – Overview. Part II will go into common misconfigurations and anti-patterns, and Part III will cover implementation examples. Part IV will introduce an example maturity model for ZTA implementation in a theoretical environment with example milestones and agile planning.
ZTA (Zero Trust Architecture) provides protection in multiple layers and is suitable for many different environments including ones of different classifications and security levels. The main purpose of Zero Trust is to ensure there is just that – no implicit or inherited trust – for users, devices, and services and to ensure every single one has the least privilege and is continuously monitored for compliance. For example, access to a host or application doesn’t mean that the user requires access to anything else outside their specific job function, even other applications or areas of the host. It works by verifying the identity of users, devices, and systems prior to their ability to connect or reach the requested system. The access policy is checked prior to the system allowing basic TCP/UDP network traffic. Often some form of PKI is used to help authenticate users, such as a smart card, certificate, etc. Once a user, device, or system is authorized for access, the requesting entity is continuously monitored for enforcement of the necessary and configured policies. All connections go through an encrypted connection that provides access to protected resources and applications. These tunnels are designed to ensure that all traffic between the user and the protected resources is secure and cannot be intercepted or accessed by unauthorized parties and all traffic is encrypted and routed through a secure gateway that provides access control, threat protection, and visibility into the traffic. The gateway evaluates each request to access a resource or application and determines whether the request is authorized based on the user’s identity, device posture, policy, and the sensitivity of the requested resource. The gateway also provides additional security features such as firewall protection, intrusion prevention, and malware detection to prevent unauthorized access and to protect against threats. This is coupled with the concept of Software Defined Perimeter (SDP) which when implemented allows connections only to specific applications based on policies not on where the source address of the request comes from.
What Can Zero Trust Architecture Protect
Zero Trust can be applied to many different types of environments. Cloud native environments such as those in AWS, GCP, Azure, Digital Ocean, can have a gateway deployed for clients to be managed for many types of person and non-person entities. Additionally, Zero Trust Architecture can be applied to protect the following types of systems:
- Internet of Things (IoT) devices
- Endpoint devices
- Mobile devices
- Industrial control systems (ICS)
- Critical infrastructure systems
- Government systems
- Financial systems
- Healthcare systems
- Supply chain systems
By implementing Zero Trust principles, organizations can secure these systems against cyber threats and enhance the confidentiality, integrity, and availability of sensitive information. However, Zero Trust may not be suitable for every type of asset or scenario. Some assets that may not be compatible with Zero Trust Architecture include:
- Physical assets, such as buildings or vehicles (although manufacturers could implement this on the CAN systems. For an interesting article on this, you should read Michaela’s article https://oteemo.com/can-vehicles-be-hacked/)
- Assets that are intentionally or accidentally exposed to the public such as public Wi-Fi networks, public APIs, or websites
- Assets that are not under the control of the organization, such as third-party data centers or potentially cloud based SaaS services.
- Assets that are not difficult to pair with the Zero Trust Model such as, ironically, security scanners. These tools require elevated privileges and wide scope inside of an environment in order to produce the results, which is outside the model of least privilege and
It is worth noting that some of these assets can still be partially protected by implementing appropriate security measures and procedures.
Zero Trust Architecture – Demystified
Ok, but what is the real difference between Zero Trust and traditional security measures and why does it matter?
Zero Trust solutions prevent any type of connection before the entity requesting access can connect, so it ensures, when configured correctly, that no one can perform network requests without being authenticated.
Wait, wait you said it was different from traditional network security, this sounds like VPN! I like my <insert vendors> VPN
Well, kind of, but miniature. Think, connection specific encrypted tunnels that don’t rely on source IP address but rather the policies applied to enforce the software defined perimeter. This is also coupled with Zero Trust Network Architecture (ZTNA). Unlike traditional VPN-based approaches that grant network access once inside the perimeter, ZTNA verifies and authorizes access to specific resources on a per-session basis. So we have the overall architecture of zero trust which incorporates ZTNA and SDP principles to 1) verify the person or non-person entity 2) authorize the person or non-person entity to every application they try to access 3) authorize the person or non-person entity to the specific data or parts of the application or system they are trying to access (if configured this way) 4) authorize access on a per session basis (every session the person or non-person entity attempts is validated and authorized) 5) enforce the perimeter of access any person or non-person entities are allowed to access based on policy not just source of request. Furthermore, functionality can be extended to ensure a device is following a set of compliance policies and person or non-person entity based authorization policies based on the data or boundary the client or server exists in. For example, some tools allow administrators to ensure a device meets a specified threshold against a standard like CIS, STIG, 800-53 or more limited standards such as just having an antivirus with updated definitions, etc., before that client connects. Traditional security pays special attention to where the client is coming from (source based ACL such as a subnet, whitelisted IP range, external IP, or specific server/load balancer) to determine trust while Zero Trust assumes no trust until a connection requestor is able to authenticate and authorization is allowed by policy grant. The assumption of traditional security is that any person or non-person entity or device outside of the company’s firewall has bad intentions and is a risk to begin with. Today’s data is architected in a way that is spread across multiple services, devices, applications, and people. Protecting access to all of these systems and devices takes more than a firewall setup or diverse passwords. The Zero Trust model will intelligently limit access and validate each person or non-person entity/device during each access attempt. By assuming that all network connections and communications are untrusted, organizations can take a more proactive approach to security. This helps to reduce the attack surface and minimize the risk of data breaches and other security incidents. When deployed and configured to their full potential, ZTA provides organizations with better visibility and control over who has access to their network and resources. This can help to prevent unauthorized access and ensure that only authorized persons or non-person entities can access sensitive information. Given all of the above, ZTA is pivotal in organizations that need to meet regulatory requirements for data privacy and security. An analogy to this would be a secure facility where to access any files in a cabinet the person has to scan a badge every time they not only open the cabinet but access any file or folder in that cabinet. A security system checks their badge for each one and denies access either at the container (application) level or file (item) level. In addition, to this, zero trust tools offer continuous assessment on compliance – has the device maintained antivirus updates, OS patch levels, other security controls such as NIST or CIS control standards, etc.
Zero Trust Architecture – Opportunities
Great! I’m sold…but this sounds too good to be true
There are some challenges in implementing a good zero trust solution, it’s not all a bed of roses…oh wait roses have thorns. It’s all a bed of roses. It is fairly complex and time-consuming to initially set up Zero Trust solutions and policies. Are all of your current endpoints, servers, or resources using applicable policies such as CIS or another NIST standard, or STIGs? The answer is generally probably not. This is most likely the biggest hurdle in the path to implementing Zero Trust and this is exactly why you should seek an expert partner, a guide, to help you in this journey. Users also have to adjust to the new paradigm which can be difficult. User devices and authentication must comply with the policy or they cannot access the resources that policy is applied to protect. It can be difficult to integrate this into current systems and applications especially when it comes to legacy applications. Finally, ensuring users are able to access the applications and resources that they need to access can be time-consuming and will require updating for every new application.
Now that we have an understanding of what makes Zero Trust Architecture different from traditional security measures we need to think about the most common use cases for ZTA and SDP. How can we create a setup that marries traditional network security with the SDP and ZTA/ZTNA tools? In part II of this series, we will go through the most common anti-patterns and mistakes when setting up these new-fangled tools. While there are many ways to skin a cat, there are pitfalls to watch out for! Part III of this series will be a lab set up using ZTA/ZTNA and SDP to show readers an example of how to apply these concepts. Though each organization will likely choose their own toolsets, the concepts are applicable. Part IV will be a maturity model for how to implement these concepts over time. Nothing can be slapped together overnight, especially in an already existing environment. We don’t want to break our users, automation tools, deployments, and applications while we augment our security and access management. Rome wasn’t built in a day, and neither is a secure environment. I hope you enjoyed reading this and got something valuable out of it.
