A major buzzword passed around this year is the term "zero trust." As with similar phrases that have come before, there are different definitions depending on who you ask and what area of technology they care about. I wanted to talk about what it means in the context of building and delivering secure applications to the federal government, and the role Sonatype's products play in this space. Today, I'll talk about how we help support a zero trust architecture strategy.
Credited to John Kindervag, "Zero Trust Network" first appeared in a 2010 article in CSO Online when he was a researcher for the well-known Forrester Research company. Since then, the concept has evolved into a strategic approach to combine modern tools and all areas of IT from users to network devices, to components in the software supply chain, and all environments regardless of location or logical separation. To condense zero trust down to one simple statement; it means not assuming any part of your IT infrastructure is secure.
Wait, isn't that a little cynical you might say; or how are we supposed to operate without trusting that our applications are running safe software on secure networks and servers?
Previously, a strong security perimeter would enable an internal, "trusted" domain, implicitly granting trust to all entities within this domain boundary. Despite the name, some trust is granted in a zero trust model, but it is conditional and neither permanent nor explicit. The focus is instead on a "trust but verify" approach that affects even "internal" resources that previously would not have their identity or authorization challenged.
Another big change in a zero trust architecture is the lifecycle of servers. Previously, they were akin to special pets that you kept patched and fought relentlessly to keep at 100% availability and functionality. In the zero trust model however, servers are analogous to cattle, where any member of the herd that fails a health check or is not providing value can be eliminated.
As an example of this concept, if I have a virtual machine or container that I trusted as secure but it fails an automatic security test, I will:
My customers see no interruptions or changes in their service.
The model is heavily supported by DevOps methods and tools, which I will explore more later in this article, along with how Sonatype's products support that model.
So now you have a fair understanding of the zero trust definition, but how does it benefit you? In-depth protection from sophisticated attacks against your systems is the primary aim. Second, attacks that cannot be prevented will at least have their impact minimized.
While laudable goals, even with all of the security mechanisms in place, you still have to find a balance between security and the ability for stakeholders to operate and innovate. Zero trust changes that bring progress to a halt can result in pressure by the company or team to rollback to less secure practices.
Security steps like the following have significant benefits:
However, these can also impede innovation if not done right. These technical steps must be part of a larger, holistic solution that includes policies, procedures, and controls to make up a secure software practice. Because it can be a confusing and highly challenging process to create that practice, success requires a team approach with internal stakeholders and vendors working together.
Since there is no single zero trust vendor tool out there that solves for every issue, the complexity of automating solutions and headaches around integration are a real risk. Fortunately, some guidance is available in the federal space, as well as a framework to facilitate DoD Zero Trust Architecture (ZTA) implementation across the entire Department of Defense Information Network (DODIN). In February 2021, the CIO for the Department of Defence (DoD CIO) rolled out a new reference architecture document: "Department of Defense (DOD), Zero Trust Reference Architecture" (defense.gov, PDF format).
To aid in the understanding of the scope and functional concerns for mission owners (MOs) to align their architectures, the ZTA document provides a set of focus areas they call "pillars." These pillars serve as a logical separation of concerns that result in a layered architecture of different capabilities that encompass an effective zero trust implementation.
The seven pillars in the ZTA include:
These are depicted in Figure 1 below, taken from the ZTA document with their respective capabilities listed. The diagram also makes it apparent that some capabilities will cross thresholds between pillars, as is the case of application delivery for example. This has relevance to both the environment and application columns.
Figure 1 - Seven Zero Trust Pillars (from https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf)
The ZTA document further provides a mapping of regulatory standards and guidelines to each of the pillars. Much of the content revolves around users, devices, and data, but the biggest thing I found that was missing in the mappings was anything related to the software supply chain. Since the other pillars are covered, I scratched my head for a while on this one and wondered if maybe it was an oversight.
After doing some research, I came to the conclusion that there is no standard at this time to tie to the "Application and Workload" pillar for a specific capability that ensures a secure software supply chain. Perhaps the concept is too new, or there has not been enough attention until now on the importance of securing all the bits of code that make their way into finished applications.
Whatever the reasons, we find ourselves in a time where the software supply chain standards are now being formed, as evidenced by the April 2021 publication of the CISA guidance on "Defending Against Software Supply Chain Attacks" and the NIST workshop held June 2nd and 3rd where NIST invited input from industry experts on standards for securing software supply chains. In the near future, NIST will create a new federal standard for software supply chains as mandated by the recent US Presidential executive order issued in response to the cyber attacks on US infrastructure.
While the new standards are being written, one of the big changes that will come alongside adherence to a zero trust mindset is the requirement for a software bill of materials (SBOM).
What does the SBOM mean to the software supply chain? One way to think of it is similar to car manufacturing in that every part that goes into a vehicle can be traced back to the original source. Big car manufacturers create some but not all of their parts, therefore, they must buy them from a variety of different suppliers. The car company will inherit the risk that comes with using third-party components, whether from incidental things like cup holder and radio, to critical infrastructure like an airbag or door locks.
In the event of a safety issue with a specific part, an included manifest makes it easy to see if any of those parts are in active use.
Modern software development functions the same way: most applications consist of 85% open source libraries sourced from publicly available repositories. As a result, a software manifest helps better address and resolve issues. If you find out an open source library is opening a backdoor into production environments, you want to be able to know immediately if any of your applications use that component.
So now that the ball is rolling on defining a standard for federal software supply chains, you might wonder: how can you get ahead of the curve?
Fortunately, we at Sonatype have been championing products that perform some of the capabilities outlined in the ZTA, in particular the central "Application and Workload" pillar. This would be where many of Sonatype's products fit by providing scanning of open source software (OSS) components and the use of policy enforcement across all of the software supply chain and software development lifecycle (SDLC) to block unsafe components.
We can also mitigate the risk from software licensing.
To highlight the capabilities that Sonatype provides for ZTA, I want to focus on the text in the DoD document, specifically in the Applications & Workload pillar:
Applications and workloads include tasks on systems or services on-premises, as well as applications or services running in a cloud environment. Zero Trust workloads span the complete application stack from application layer to hypervisor. Securing and properly managing the application layer as well as compute containers and virtual machines is central to Zero Trust adoption. Application delivery methods such as proxy technologies, enable additional protections to include Zero Trust decision and enforcement points. Developed Source Code and common libraries are vetted through DevSecOps development practices to secure applications from inception. (source: defense.gov, PDF format)
Important capabilities mentioned in the definition above includes creating enforcement points in a DevSecOps approach to an SDLC. This includes scanning and control over both custom source code and common OSS libraries. Sonatype's tools are an integral part of creating a secure application stack at every stage, from the developer writing code to the application running in production. Here is a quick look at Sonatype products and the high level value they provide:
We at Sonatype welcome the opportunity to help you secure your software supply chain and get ahead of the pending regulations to meet ZTA objectives. I hope that you found the information helpful. Please feel free to reach out to me or any of my colleagues at Sonatype if you have questions or would like to have one of our representatives schedule a deeper dive into how we can help.
Contact Us or Request a Demo | Accelerate Software Innovation