Executive Order 14028: How to Adopt Zero-Trust Architecture
President Biden issued an "Executive Order on Improving the Nation's Cybersecurity" (Executive Order 14028) as of May 12, 2021. The order includes numerous actions and mandates to confront the dangers of cyber attacks that are increasing in frequency and sophistication. Cybersecurity has real and significant implications, both in economical and national security terms.
At the time of this writing, the Colonial Pipeline cyber attack caused quite a stir on the USA's east coast. In 2020, a high-profile breach was arguably more severe. Cybersecurity is therefore a legitimate and pressing concern for all organizations.
Section 3 of the order indicates that, among other things, the federal government shall develop plans to adopt Zero-trust architecture (ZT). ZT aims to improve the security of IT systems by removing the assumption that any trust is implicit in a computing environment. That is, trust must be continuously earned and re-established in a dynamic, non-static manner.
Secured Communications
Furthermore, the permissions granted based on earned trust will be for the bare minimum time and capabilities to meet required legitimate needs. All communications must be encrypted to ensure confidentiality and integrity.
As part of adopting this architecture, sufficient monitoring and logging are required, as is automation of the application of security policies. This naturally demands good governance in implementing IT systems.
ZT excels when compared to static, network-based perimeter security. ZT offers stronger protection to computing resources given its default posture to reject any activity unless explicitly and dynamically approved.
Adopting Zero-Trust Architecture
The executive order requires agencies to develop plans to adopt ZT. Kong encourages organizations to adopt ZT as soon as practicable. In this post we detail 5 Ways to Adopt Zero-Trust Architecture in observation of the NIST Special Publication 800-207 recommendations. This is not an exhaustive list.
1. Segment communications as practical
In ZT, segmentation translates to controlling the communication between various computing components. A typical API gateway is an implementation of this, acting as an isolating entry point for access to any service/API resources it protects. Said resources may only permit communications from the API gateway alone, making them inaccessible otherwise.
This is a significant improvement over a network where all communications are allowed. Only traffic that is trusted and is subjected to the policies determined at the gateway will be allowed.
However, no one system ever works in isolation in a distributed environment. Opening up communication to a portion of the network is necessary. How is this approached for microservices? It is here where a service mesh becomes important.
This is a subject of an article by Kong's CTO, Marco Palladino: The Importance of Zero-Trust Security When Making the Microservices Move. We may take this a step further still. Kong Mesh allows a rather useful multi-tenant segmentation via its multi-mesh feature.
We demonstrated how both Kong Gateway and Kong Mesh can help in enforcing segmentation. The combination of both technologies place a strong emphasis on applying security policies at the perimeter and in a distributed context.
2. Encrypt all traffic
In line with not granting any trust by default and assuming that any given network may be compromised, it follows that encrypted traffic is a prudent, if not mandatory, hedge against potential exploitation of otherwise clear traffic. Once again, both Kong Gateway and Kong Mesh can be useful in achieving this.
At the gateway level, in addition to only exposing traffic over a secure channel, such as HTTPS, as an example, we can further apply additional security policies to accurately further restrict access. IP filtering is one approach; however combining it with Mutual TLS (mTLS) is a superior approach still. Aside from this example, there are other possibilities for authentication, naturally.
When considering communications within a distributed application, as in a service mesh, mTLS can be quite an undertaking. In this instance, Kong Mesh's Mutual TLS is a convenient approach, given its ability to automatically generate a root CA (Certificate Authority) and to provision SPIFFE-compatible certificates to data planes in the mesh and further manage automatic certificates rotation.
3. Allow minimal permissions based on identity
Assuming a communication channel is secure, it follows that we should be able to verify that the entity on the channel is adequately identified, and from there, we can determine what authority this entity has.
Fortunately, part of this requirement may be already met during encrypting traffic. If we use mTLS, we already have a way to identify resource consumers. What follows, therefore, is authorization.
Once again, we have a few options. OpenID Connect and ACL are possible at the gateway, whereas OPA as well as traffic permissions are well-suited for mesh applications.
Kong Mesh by default ties mTLS with traffic permissions. This means as soon as traffic encryption is enabled, no communication is considered allowed unless explicitly identified as such.
4. Log and trace traffic adequately
ZT encourages adequate intelligence on the network traffic. While packet logging and in-flight inspection have their use cases, it is also useful to obtain metrics on traffic, as well as set up logging and tracing features.
Once again, both Kong Gateway and Kong Mesh support this via out-of-the-box tracing, logging and monitoring. While metrics have tactical, and even strategic utility, they also are frequently used to trigger alerts.
While alerts. are intended for operational purposes, they can also help identify potential threats. This is especially so when alerts uncover out of the ordinary patterns. Kong Immunity is built on this premise.
Logging, having a higher granularity than classic metrics, can be used on a longer time horizon or for forensics purposes. It is naturally more expensive computationally; however its applicability to ZT should not be neglected. Likewise, tracing of requests is not to be neglected in ZT. These capabilities apply in perimeter security, and they remain important in ZT architectures.
The speed and flexibility of the previously mentioned logging, monitoring and tracing in ZT deployments should aid in making the transition.
5. Start today and do not wait for containerizing your applications
Embracing ZT is not a switch that can be made immediately. Most organizations cannot deploy new applications with new technologies at will. The reality is that for most organizations, a gradual transition is more likely. With this in mind, technologies with the greatest breadth of applicability to operating environments and platforms are advantageous.
Kong Konnect was designed to be a non-greenfield only solution. By supporting non-containerized environments, organizations can begin immediately to segment their applications into meshes, apply authentication and authorization, enforce encryption, and adequately log and trace traffic - all while enforcing strong perimeter security. "Leave and layer" is a less risky strategy than "Rip and Replace."
Conclusion
We covered quite a few aspects of ZT and shed some light on their utility, significance and advantages. We reiterate that these aspects are not comprehensive. We encourage all readers to continue to learn and apply ZT, and we recommend a gradual application of ZT, as possible.
At Kong, we are happy to see the White House take this step towards addressing cybersecurity. We look forward to zero-trust security becoming a reality across U.S. businesses and organizations. Check out our On Demand Webinar – Microservices: Making Digital Transformation Work for You
