Zero-trust security: What architects need to know

Zero-trust security assumes that all traffic on your internal network is potentially malicious. Consequently, it requires taking measures to:

• Authenticate all connections
• Identify all devices, users, applications, and services
• Ensure that traffic goes only where it is needed, not just at the network level but also at the application level

Zero trust benefits security practitioners by providing a workable model for security systems design. Properly implemented, the design improves the safety of an organization's assets.

There is a huge interest in zero-trust security across industries and particularly in the federal government. In May 2021, the White House issued Executive Order 14028, requiring all agencies to submit a plan for implementation of zero-trust security in their IT systems. Since then, numerous agencies have produced guidance for zero trust:

• The Department of Defense has a reference architecture.
• The National Institute of Standards and Technology has issued two documents.
• The National Security Agency has published a maturity model.
• The Cybersecurity and Infrastructure Security Agency has generated a wealth of guidance on zero trust.

In a for-profit company, zero-trust can reduce cybersecurity premiums and enhance the company's overall risk profile with possible positive effects on its stock price and value. In government, improved security through zero trust can help prevent intrusions by adversarial nation-states or other enemies of the nation.

While guidance on zero trust abounds, one key question rarely arises: What problems is it trying to solve? Keep this question in mind as you read this article.

Implementing zero trust: challenges

A key concept in zero-trust security is the notion of the protect surface. A protect surface is the inverse of the attack surface: It is the catalog of all assets requiring protection, rather than a record of all possible avenues of attack.

The protect surface is orders of magnitude smaller and more manageable than an attack surface. Using the protect surface as a foundation for security architecture simplifies system design and focuses security controls efficiently. However, the road to zero trust can still be daunting.

Zero-trust security takes a comprehensive approach to a company's security activities, policies, and technology. Consequently, it significantly affects the company's culture, human resources, technical expertise, and budget.

Change management is essential to ensure the project launches and proceeds adequately. Demonstrating return on investment (ROI) or other success measures is critical to obtaining and retaining support from upper management. Technology is important in zero trust, but success requires support from management, technical staff, and end users. It is a cultural phenomenon as much as a technological overhaul.

Another challenge is providing authenticated users access and authority to execute functions. More application architectures are trending towards smaller, more granular workloads (microservices) to fulfill end-user requests. A microservice architecture has advantages for DevSecOps teams because it shortens time to market as decoupled services are easier to test and manage than monolithic systems requiring months to address and deploy stakeholder needs and remediations.

[ Download the guide to implementing DevSecOps. ]

When evolving towards a microservice architecture, you must account for east/west (service-to-service) traffic to ensure secure communications between system functions and north/south (end-user request) traffic (typically) over the internet. Where there once was an inner application call, there may be many (micro)service calls to execute a particular function, all requiring authentication and authorization checks. The right choice of technology platform is crucial to prevent chaos when addressing different approaches to solving zero trust challenges.

Remember: You're trying to solve a problem (or set of problems) with zero trust. If the solution resolves problems for all key stakeholders, prospects for success skyrocket.

Measuring success

Success measures depend largely on the type of organization where the zero-trust architecture is deployed. In a commercial, for-profit organization, demonstration of ROI is central. Some ways to measure success include:

• Are response times shorter?
• Are there fewer incidents?
• Is remediation more effective, limiting the financial damage of an intrusion?
• Can you quantify these elements and compare them to the tangible and hidden costs of a zero-trust implementation?

For government agencies, ROI is still important, but other success measures—typically a maturity model—can illustrate an implementation's progress. For example:

• Are security procedures well understood, clearly documented, enforced, and reliably practiced?
• Are key processes (such as incident response and limitation of lateral movement) manual, semi-manual, or automated?
• What percentage of systems are under the protection of the zero-trust architecture, and how long did it take to get them there?

[ Learn about the differences between Red Hat OpenShift and Kubernetes. ]

Use Kubernetes to help with zero-trust challenges

Containers and Kubernetes provide many options to implement micro and macro security across an entire platform or cluster and across multiple clusters in heterogeneous cloud environments. Kubernetes' namespace separation lays the groundwork for fencing access to workloads running in containers when trying to solve zero-trust challenges. Containers provide the requisite process isolation, the foundation for least-privilege access to agency services and data.

Kubernetes provides very granular resources for authorization and access to containers. However, complexity and confusion arise trying to manage hundreds or thousands of services communicating across clusters to accomplish a task. While containerization and Kubernetes system modernization are not required for zero trust, they are certainly recommended as you pull back layers of requirements when addressing security risks at any level, especially given the need for remediation speed once an issue or vulnerability is detected.

Given public sector risk aversion, it's important to select enterprise-grade Kubernetes implementations that are supported by a reputable company dedicated to keeping up to date with innovations and addressing vulnerabilities quickly. For example, OpenShift Container Platform implements controls including API gateways, namespaces, ingress/egress policies, Active Directory integration, and service mesh. These enable DevSecOps teams to collaborate and implement standard zero-trust controls compliant with agency governance criteria.

When measuring success, make sure you can show that zero trust is truly solving the problems you have defined at the outset of the journey.

Choose a maturity model for your zero-trust architecture

The US government has promoted several maturity models to measure the effectiveness of a zero-trust implementation. If you are in a government agency, you may be required to use a particular document. However, if you have a choice, look for specific, concrete, and, most of all, realistic guidance.

[ Learn about container security maturity models. ]

Some models simply amount to "good/better/best," while others provide clear guidance on what technology to implement at what phase and offer concrete milestones to measure progress. Unless you are mandated to adhere closely to a specific approach, do not feel obligated to follow it to the letter: Stick to the overall outline, but tailor it to your organization's needs and constraints.

What about private industry? You can still use the government guidance, or at least consider it. Other models include the Forrester ZTX approach, Gartner's CARTA method, the Google Beyond Corps approach, Red Hat OpenShift Compliance Operator, and guidance from Jon Kindervag, widely acknowledged as the founder of zero trust.

As you reach each level of maturity, are you closer to solving your problems? Can you demonstrate this success to all stakeholders, especially the non-technical senior management holding the purse strings?

Zero trust: a means to an end

Implementing zero trust may seem daunting as it likely requires an application overhaul to implement least-privilege access to application functions. The application might not have been designed to identify the requestor and requested activity, especially in legacy systems in the public sector. You must assess current workloads, purpose, owners, and access controls when moving towards a DevSecOps cultural transformation.

But it is also an opportunity for growth, as you can integrate more secure coding practices into your software applications from the start. A holistic approach requires collaboration between developers, security officers, and IT operations resources to address an agency's ability to achieve zero trust.

Since zero trust is a major undertaking, it's easy to think of it as a goal: "When we reach maturity level 5 out of 5, we'll be done." While there's some truth to that, the reality is that zero trust is really a means to an end—better security—rather than an end in itself.