For the federal government, a zero trust architecture assumes that all traffic on an agency’s 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 a federal agency’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.
For the federal government, improved security through zero trust can help prevent intrusions by adversarial nation-states or other enemies of the nation. But 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 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 government agency’s security activities, policies, and technology. Consequently, it significantly affects the agency’s culture, human resources, technical expertise, and budget.
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.
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. For government agencies, some ways to measure success include:
-
- Are response times shorter?
- Are there fewer incicents?
- 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?
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 U.S. 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.
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.
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 a zero trust architecture.
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.
This article originally appeared on Red Hat’s official blog, HERE.
