If you work in the IT space, you’ve undoubtedly seen the federal government modernizing its approach to cybersecurity, speeding up and keeping pace with the increasingly sophisticated and dynamic modern cybersecurity environment. According to Gartner (link), software supply chain attacks will increase three-fold over the next three years, affecting around 45% of organizations worldwide.

Currently, the government primarily focuses on security best practices, secure cloud services, maturing a security architecture, and accelerating the push towards enhancing automation and machine learning. This has resulted in a wide and complex landscape of government efforts to enhance security personnel’s visibility into threat activity and risk, producing things like Zero Trust methodology and, consequently, the Software Bill of Materials (SBOM). Functioning as an “ingredient list” or “recipe” of IT assets, an effective SBOM is intricately tied to three specific pillars of the Zero Trust framework. These are the pillars of Device and Endpoint, Data, and Application and Workload, the last of which ties into today’s blog.

The Push for Zero Trust

The push for Zero Trust implementation and development is being driven by governmental actions such as Executive Order (EO) 14028, Improving the Nation’s Cybersecurity, and the more recent Memorandum M-22–18. These actions have led to the adoption of security policies like least-privilege access control and micro-segmentation. If implemented correctly, Zero Trust architecture should ultimately replace the legacy “implicit trust” method with a dynamic approach that assumes a breach, verifies gathered intelligence, and appropriately limits access to data. The cybersecurity challenges presented by software supply chain attacks, insider threats, the Internet of Things (IoT), and edge devices require changes to all elements of existing security architectures: people, processes, and technology. The seven Zero Trust pillars, and specifically the Zero Trust model, require these elements to be considered untrusted regardless of where they reside, and require that every instance of data access is authenticated and authorized based on policy constraints before access is granted.

Cooking with the SBOM

When a new vulnerability is discovered, organizations spend countless hours figuring out the material impact on the applications and services in their environment. Unfortunately, many recent cybersecurity incidents have exposed a lack of knowledge of code dependencies, digital signatures, and licenses, just to name a few. These new vulnerabilities eat up a lot of time and effort as security professionals spend valuable man-hours to detect the real impact on the applications and services running in their environment. This realization, along with the desire to catalog software dependencies more efficiently for other time and cost-saving purposes, has led to the inception of the SBOM. As a “recipe” of software (and occasionally hardware) elements, the SBOM seeks to bridge the gap between research and response in the wake of newly discovered vulnerabilities.

It should be noted that the SBOM is not a new idea by any stretch, with the concept dating back more than 10 years. However, several significant cyber-attacks (including the 2017 Target Hack and the 2020 SolarWinds Attack) have highlighted its utility and necessity, with the nation’s cyber supply lines appearing as prime targets for any attacker looking for a soft spot. The SBOM enables cyber professionals to quickly ingest the comprehensive components that make up each software package, allowing them to efficiently determine which systems need to be patched, updated, or re-worked.

Application and Workload

Fully understanding the application of the SBOM also means understanding the way in which it interacts with the different pillars of Zero Trust, starting with the Application and Workload pillar. This pillar deals with securing the agency systems, computer programs, and services that execute within an extended enterprise, including both on-site and cloud environments. Most importantly, this also extends to the application development process, as well as any relevant application containers or software packages.

Maturing this pillar and establishing a solid base of functional working materials means properly emphasizing all its components, including concepts such as Software-Defined Compute and SecDevOps. From this base, you can synthesize a much more operational and comprehensive SBOM by weaving its development into the application workflow process. This allows developers and technicians to avoid the arduous process of retroactively establishing an SBOM, and thus permits any response to cybersecurity incidents the benefit of an easy-to-access reference library. If dependencies, components, and weaknesses are tracked as part of the development lifecycle, they can be used by any development team member as necessary, increasing the likelihood that security vulnerabilities will be mitigated and strengthening the SecDevOps process.

Another key component of establishing a competently managed Application and Workload stack is the use of micro-segmentation. Recent pushes from federal leadership have resulted in widespread adoption of hybrid-cloud or full-cloud models, resulting in a dynamic and difficult-to-secure IT infrastructure for IT security professionals. As a result, a Zero Trust architecture necessitates micro-segmentation as a security best practice for organizations operating in such volatile and dynamic environments. This concept has a wide range of applications such as zone segmentation, application isolation, and service restrictions. By developing a plan and applying a segmentation and micro-segmentation capability, individual workloads can be rendered safer against attacks from hackers and cyber criminals. Micro-segmentation will significantly reduce the likelihood of data exportation and malicious attacks with the correct architecture and deployment models. It also works in conjunction with a development-embedded SBOM to create an environment that is simultaneously a maze for attackers, but easily navigable to approved IT professionals.

Application and Workload isn’t the only pillar of Zero Trust tied in to SBOM, however. Recognizing the need for an effective SBOM means recognizing every area and component that it touches, and it expands much further beyond the purview of Application and Workload. Join us in our next blog post, where we will discuss how the Device and Endpoint pillar of Zero Trust ties into the SBOM.