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.
About the authors
Certified as a Forrester zTx Strategist, Don Maclean currently serves as DLT’s Chief Cybersecurity Technologist. A recipient of the FedScoop 50 award and ICIT Fellow, Mr. Maclean’s duties include formulating and executing cybersecurity portfolio strategy, speaking and writing on security topics, and socializing DLT’s cybersecurity offerings. In this capacity, Mr. Maclean also advises CEOs on federal go-to-market strategies for cybersecurity products.
Before joining DLT in 2015, Mr. Maclean ran security programs for U.S. federal agencies, including DOJ, DOL, FAA, FBI, and Treasury. This experience allowed him to observe the strengths and limitations of traditional cybersecurity defenses. Mr. Maclean holds a CISSP, CEH, AWS Certified Practitioner and CCSK certifications in addition to an M.S. in Information Security and a B.A. in Music; he is also a Registered Practitioner (RP) for the CMMC program.
An avid musician, Don organizes a concert for charity every year, often competes in chess and Shogi (Japanese chess) tournaments, and has recently started building model ships.
Certified as a Project Management Professional (PMP) and Agile Certified Practitioner (ACP), Rick Stewart currently serves as DLT’s Chief Software Technologist. His duties include formulating and executing DevSecOps portfolio strategy, speaking and writing on SDLC topics, and socializing DLT’s Secure Software Factory (SSF) offerings. In this capacity, Mr. Stewart also advises CEOs on federal go-to-market strategies for application lifecycle management products.
Before joining DLT in 2013, Mr. Stewart had vast experiences in the IT industry, progressing through technical and leadership roles in the telecommunications, mobile entertainment, federal government, and manufacturing industries. His current duties are in support of DLT to promote the sharing and adoption of Red Hat, CloudBees, and GitHub technologies with within the federal government and state, local, and higher education (SLED) enterprise accounts. He assists these customers to define, develop, and deploy their next-generation Application Life Cycle (ALC) and middleware strategies. He is responsible for building strategic relationships with technical executives and key business leaders to identify and scope project technical needs and to promote Red Hat's portfolio of middleware products, including application development, application and service hosting, business rules management, business process management, content aggregation, data federation, and service integration onsite or in the cloud.
More like this
Browse by channel
Automation
The latest on IT automation for tech, teams, and environments
Artificial intelligence
Updates on the platforms that free customers to run AI workloads anywhere
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
The latest on how we reduce risks across environments and technologies
Edge computing
Updates on the platforms that simplify operations at the edge
Infrastructure
The latest on the world’s leading enterprise Linux platform
Applications
Inside our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Customer support
- Developer resources
- Find a partner
- Red Hat Ecosystem Catalog
- Red Hat value calculator
- Documentation
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit