What Is Zero Trust Architecture?
The ZT architecture approach assumes that no connection, user, or asset is trustworthy until verified. Conversely, the traditional perimeter security paradigm trusts connections once authenticated and grants them access to the entire network, leaving enterprise assets potentially open to cybercriminals. Transformative and time intensive, ZT projects build upon and rework existing architecture.
Zero trust architecture
ZT architecture is an evolving concept that at present has no certifications or practical standards. Many enterprises rely on certifications such as International Organisation for Standardisation (ISO) compliance, and the absence of well-defined parameters in the case of ZT creates a measure of confusion.
Adding to the confusion, some vendors label a product or a service as a complete ZT solution, ignoring the basic premise that ZT is an approach that utilises existing and new products and services but does not reside in a particular set of products or services. Worse, many will apply this practice of “zero trust washing” to legacy products despite missing core properties.
Zero trust frameworks
Various ZT frameworks and approaches are available. ZT is a concept, but the basics of a ZT framework have been defined by the National Institute of Standards and Technology (NIST) and by analyst firms such as Gartner, Forrester, IDC, and ESG.
- In its special publication Zero Trust Architecture, NIST discusses how the U.S. government is employing ZT strategies. The 50-page document defines the basics of an ideal ZT implementation and offers federal government deployment scenarios and use cases. While Gartner, Forrester, IDC, ESG, and other analyst firms are in agreement with NIST on the term “zero trust” and many definitions, approaches, and frameworks, these firms differ in terminology for many of the same concepts
- For example, Gartner uses the term Secure Access Service Edge (SASE) to describe the combination of Cloud Access Security Broker (CASB), secure web gateway (SWG), and advanced virtual private network (VPN) while Forrester calls it Zero Trust Edge (ZTE).
Analyst firms are beginning to offer roadmaps along with valuable guidance, and organisations can find excellent information from those sources to start their ZT journey.
Zero trust basic principles
ZT starts with a set of principles that each enterprise implements according to its business and security needs.
- Consider all data and services as resources – many different classes of devices and services make up today’s networks. Services such as SaaS, cloud services, and personal devices that access enterprise resources are candidates for inclusion under the ZT umbrella.
- Do not trust network location or identity – traditional perimeter-only security operates with a single door for users to gain access to enterprise resources. Once authenticated, a user gains broad access to enterprise-owned assets. This practice opens the door for malicious actors as well. Once they gain access, they can move laterally throughout the network, installing malware and ransomware as they go.
- Grant access to a resource for only one session – establish trust before granting access and give the lowest level of privileges to get the task done.
- Determine access based on a dynamic policy – policy is a set of access rules assigned to a subject, asset, or application. Establish policy based on the needs of your business and the amount of risk you can accept. A dynamic policy may include continuously monitored risk levels of users, devices, and behavioral attributes such as observed usage patterns. It may also include environmental attributes such as network location, time, and active attacks.
- Presume no asset is inherently trustworthy – evaluate the security posture of the asset during a resource request using a continuous monitoring system. Include personal devices as well, selecting the level of access these devices will have. This is not as radical as it seems, because of how quickly proven secure servers can be exploited through vulnerability disclosures or a change in a small component, such as an open-source library inclusion.
- Verify trust continuously – trust is not a fixed state. If user or device risk increases, take action immediately by terminating connections or resetting accounts.
- Strictly enforce authentication and authorisation – use dynamic principles to constantly scan, assess threats, adapt, and reevaluate trust during communications. Establish an identity, credential, and access management system (ICAM), including multifactor authentication (MFA) for applicable resources. Base policy reevaluation on time, unexpected activity, or a request for a new resource, for example.
- Collect as much information as possible – information about asset security posture, network traffic, and requests for access are extremely valuable. Use them to gain insight to improve security policies and enforcement.
Zero trust model components
A ZT deployment comprises different components. Some may be in-house services, and others may be cloud based. Recognise that any ZT architecture you implement will roll out over time. During this period, it's critical to educate stakeholders on all the moving pieces and convey that ZT is a continued effort without clearly defined start and finish. Stay mindful that as changes in your IT and business needs disrupt your progress, you can maximise the impact of your ZT approach by continually reassessing your architecture.
Experts emphasise there is no one-size-fits-all ZT infrastructure. Every enterprise, and thus every ZT deployment, will be different. Additionally, ZT infrastructure is typically implemented over time in a series of smaller infrastructure modernisation projects. The ideal ZT model rarely, if ever, exists.
One of the attributes of the ZT model is its dynamic nature, so today’s ideal ZT model may not be ideal tomorrow.
Example diagram from the NIST document, page 18. Zero trust model components.
- Policy engine (PE) – the PE makes decisions as to whether to grant access based on policy and input from CDM systems and threat intelligence services.
- Policy administrator (PA) – the PA creates or shuts down a communication based on decisions from the PE.
- Policy enforcement point (PEP) – the PEP grants, monitors, and terminates connections.
A number of data sources provide input to assist the policy engine in making access decisions.
- Continuous diagnostics and mitigation (CDM) system – a CDM system informs the policy engine as to whether an enterprise or non-enterprise asset requesting access has the correct operating system (OS), integrity of software components, or any known vulnerabilities.
- Industry compliance system (ICM) – most enterprises have a set of compliance regulations to adhere to: healthcare, for example. The ICM contains the policy rules and monitors for compliance.
- Threat intelligence feed(s) – these are internal or external sources that provide information about new vulnerabilities, software flaws, and malware to the PE, which then decides whether to deny access.
- Network and system activity logs – these provide real-time feedback about assets, traffic, access actions, and other events. They enable you to evaluate recent activity and make relevant policy decisions.
- Data access policies – data access policies are the rules that define how access privileges are granted. They are based on the organisation’s mission, roles, and needs.
- Enterprise public key infrastructure (PKI) – this system generates and logs certificates to resources, subjects, services, and applications.
- ID management system – this system creates, stores, and manages user information, including name, email address and certificates. This system manages user information for non-enterprise employees who may be collaborating with the enterprise.
- Security information and event management (SIEM) system – the SIEM collects security information that can contribute to policy creation and may warn of attacks.
Zero trust architecture diagram
Other critical success factors
Other critical considerations include prioritising components within your existing architecture that are outdated and those that have a significant impact. Another key factor is focusing on one of the most often neglected aspects in early ZT projects - visibility. As early adopters of ZT have remarked almost universally, you can only trust what you see.
Micro-segmentation is a viable technique, but without a strong ZT identity component, extra investment in segmentation has diminishing ZT returns.