As Log4J and SolarWinds have proven, attacks on the software supply chain are increasingly frequent and devastating to both the private and public sector. The Department of Defense (DoD) and its industry partners also face these risks. In its 2021 State of the Software Supply Chain report, Sonatype reported 12,000 cyber attacks aimed at open-source suppliers, a 650 percent increase from the year before. Virtually all products or services that an organization acquires are supported by or integrated with information technology that includes third-party software and hardware components and services. Each represents a potential source of cybersecurity risk.

For many organizations, practices and decision points critical to monitoring and managing supply chain risks are scattered. Security and supplier risk management typically lie outside of program risk management, and DoD acquisition practices we have observed show parts of this information detailed in many documents, such as the Program Protection Plan (PPP), Cybersecurity Strategy Plan, System Development Plan, Supply Chain Risk Management Plan, and Statement of Work.

Consequently, effective cyber risk-management activities undertaken throughout the organization must be addressed collaboratively across the lifecycle and supply chain. Moreover, to be taken seriously, these risks must be integrated with program risk management. Doing so will help relieve the current status quo in which the activities of isolated stovepipes lead to inconsistencies, gaps, and slow response at best. In this post, I introduce the Acquisition Security Framework (ASF), which helps organizations identify the critical touchpoints needed for effective supply chain risk management and describes a set of practices needed for proactive management of supply chain cyber risk­­­.

Today’s Threat Landscape

Today’s systems are increasingly software intensive and complex, with a growing reliance on third-party technology. Through reuse, systems can be assembled faster with less development cost. However, this approach carries increased risk. All software contains vulnerabilities that are hard enough to manage directly. Inheritance through the supply chain increases the management challenges and magnifies the risk of a potential compromise. In addition, suppliers can become propagators of malware and ransomware through features that provide automatic updates.

The supply chain intersects the acquisition and development lifecycle at many points. The DoD and other organizations need an integrated focus across engineering, development, and operations to reduce the risk of vulnerabilities and increase security and resilience. So much of system development is now assembly of third-party technology, with each component a decomposition of elements collected from other sub-components, commercial products, open-source components, and code libraries. These elements are frequently hidden from the acquirer, resulting in components of unknown provenance, unknown quality, and unknown security. An attacker’s capabilities to reach and leverage available vulnerabilities increases exponentially each year.

The types of supply chains that can impact a system include the following:

• hardware supply chains
  • conceptualize, design, build, and deliver hardware and systems
  • include manufacturing and integration supply chains
• service supply chains
  • provide services to acquirers, including data processing and hosting, logistical services, and support for administrative functions
• software supply chains
  • produce the software that runs on vital systems
  • comprise the network of stakeholders that contribute to the content of a software product or that have the opportunity to modify its content
  • use language libraries and open source components in development

With so much risk distributed and embedded throughout an acquisition supply chain, traditional segmented management approaches no longer suffice. Greater rigor is needed to meet the requirements for a program to have effective supply chain risk management. A typical acquisition integrates several types of approaches for technology inclusion as follows, essentially ignoring the vulnerabilities inherited from each element that is increasing cybersecurity risk:

• formal acquisition and contracting language, including requests for proposal responses and negotiated outcomes bounded by cost and schedule
• commercial off-the-shelf purchases of existing third-party products that include continuing service agreements for updates and fixes
• informal selection that involves downloads from open source libraries, as well as code extracted from prior versions or similar projects

In prior publications, I stressed the importance of creating a cybersecurity engineering strategy that integrates with the software supply chain to identify and address the potential threats that impact an acquisition. It is equally important to effectively translate the strategy into requirements and practices for determining how an acquisition addresses security and resilience risks across the lifecycle and supply chain. Put another way, the next logical piece that we must focus on is implementing a range of effective practices for the acquisition’s supply chain risk management. ASF provides the framework of what these practices should include. The framework defines the organizational roles that must effectively collaborate to engineer systematic resilience processes to avoid gaps and inconsistencies. It also establishes how an organization should ensure it has effective supply chain risk management that supports its mission and objectives. The ASF contains proven and effective goals and practices, and it is consistent with supply chain risk management guidelines from the International Organization for Standardization (ISO), National Institute of Standards and Technology (NIST), and Department of Homeland Security (DHS).

We have structured ASF to facilitate the enhancement of systems development and management processes to enable better management of cybersecurity and software risk. This improvement in risk management helps reduce the impact of disruptions and cyber attacks on the acquired system’s ability to achieve its mission. The ASF is purpose-built to provide a roadmap for systems resilience that leverages a proven set of integrated management, engineering, and acquisition leading practices. The ASF is designed to

• address risk through collaboration among acquisition participants and suppliers
• facilitate the identification and management of risk by applying leading practices that can be tailored to meet the needs of the acquisition

Within an acquisition, program management establishes the governance for supply chain risk and supplier-management structures and supports the relationships between the program and supplier; and engineering integrates the supplier components, tools, services, and capabilities into the system under development. Too many organizations try to separate each of these as if they operated independently, but effective supplier risk management requires close collaboration. For today’s mix of technology to perform effectively, it must be coordinated, verified, and connected through supply chain risk management. Additional challenges of supply chain risk arise for organizations implementing DevSecOps, where many of the develop steps are automated through the use of third-party tools and software-driven processes, further increasing the impact of vulnerabilities from these components while often reducing the visibility of the processes to oversight.

In this new reality, organizations must somehow manage the supplier risk of each integrated piece that they acquire, but the visibility of that risk is spread across many organizational roles. Through ASF, we are working to give organizations a framework to integrate the work of these roles toward the common goal of supporting supply chain risk management.

SEI Experience Addressing Challenges to Supplier Risk Management

In a 2010 SEI research project, we found that few organizations considered supply chain risk within the acquisition and development lifecycle beyond a narrowly defined vetting of the supplier’s capabilities at the time of an acquisition. This failure to consider the responsibilities the acquirer had to assume based on the lifecycle use of the third-party product left the organization open to an extensive range of cyber risk that increased over time. In later research, we investigated the lifecycle issues of supply-chain risk and identified that the operational and mission impact of cyber risk increases as organizations become more dependent on suppliers and software.

Our experience indicated that acquisitions include lengthy lists of requirements in a statement of work (SOW) and assume a contractor will adhere to them all. Each critical functional and non-functional area (including safety, cybersecurity, and anti-tamper) specifies a range of ideal needs that assume that the acquired system will be built to meet these needs with no consideration of how these various pieces must work together. However, the vendor will primarily ensure that the system (including hardware, software, and network interfaces) will be built to be cost-efficient in leveraging available components that meet functional needs. Verification that the delivered system meets functional requirements will happen during testing. Confirmation that non-functional requirements are met will depend on the certification mandates. No one currently has the responsibility to ensure that the supply-chain risk is sufficiently low in all aspects.

If acquiring organizations use only testing to verify that requirements have been met, they will see only what they chose to verify. It is a drain on resources to test for every requirement, so an approach that integrates core evidence is needed.

In too many organizations, it is assumed the contractor manages all necessary supply-chain risk. The acquiring organization has no visibility into the subcontractor relationships and is unable to confirm that the primary contractor is imposing the requirements designated in the SOW on system subcontractors, often because the primary contractor has not done so. Through our work, we have learned that in many cases the subcontractors have not received the requirements and therefore have not followed them.

The Acquisition Security Framework

As stated earlier, the Acquisition Security Framework (ASF) is a collection of practices for building and operating secure and resilient software-reliant systems. The ASF is designed to proactively enable system security and resilience engineering across the lifecycle and supply chain. It provides a roadmap for building security and resilience into a system, rather than attempting to add it once the system has deployed. The ASF documents widely used security and resilience practices and provides organizations a pathway for proactive process management integration. This dual focus on practice and process produces an efficient and predictable acquisition and development environment, which ultimately leads to reduced security and resilience risks in deployed systems.

These practices are relevant no matter what acquisition and development approach is selected. However, where and how the practices are performed—and by whom—can vary widely. Which components are acquired, and who makes the selections and integrates them into the system, will be unique for each acquisition, but the need to address supply chain risk and manage vulnerabilities will exist for each technology acquired.

The ASF helps acquiring organizations correlate management of supply-chain risk across the many components of their systems, including hardware, network interfaces, software interfaces, and mission capabilities. The ASF helps organizations incorporate security and resilience practices into the system lifecycle by

• defining a risk-based framework that
  • provides a roadmap for managing security and resilience practices across the system lifecycle
  • manages complexity through increased consistency and collaboration
• adapting system and software engineering measurement activities to include security where appropriate
• supporting multiple cyber-focused standards, laws, and regulations with which all programs and systems must comply

The ASF practices can be categorized into the following six practice areas:

• program management
• engineering lifecycle
• supplier dependency management
• support
• independent assessment and compliance
• process management

Within each of these practice areas are two to three domains. Within each domain, there are six or more goals, each with a group of practices that support an organization in meeting each goal. The practices are phrased as questions that can be used in determining and evaluating current and planned organizational capabilities. Presently, we have finished the development of four of the six practice areas.

For the Engineering Lifecycle practice area, we identified the following domains:

• Domain 1: Engineering Infrastructure
• Domain 2: Engineering Management
• Domain 3: Engineering Activities

For Supplier Dependency Management, we identified the following domains:

• Domain 1: Relationship Formation
• Domain 2: Relationship Management
• Domain 3: Supplier Protection and Sustainment

For Program Management, we identified the following domains:

• Domain 1: Program Planning and Management
• Domain 2: Requirements and Risk

For Support, we identified the following domains:

• Domain 1: Program Support
• Domain 2: Security Support

In the remainder of this post, we will look at the details for the second area, Supplier Dependency Management. Although we have narrowed the focus for the purposes of this blog post, I stress that to implement effective supply-chain risk management, organizations must consider all four practice areas.

ASF Practice Area: Supplier Dependency Management

Supply chain cyber risks stem from a variety of dependencies, and in particular from the processing, transmittal, and storage of data, as well as from information and communications technology. Each of these cyber risks within the supply chain is broad and significant. Important mission capabilities can be undermined by an adversary’s cyber attack on third parties, even in situations where an acquiring organization is not explicitly contracting for technology or services, such as data hosting.

As shown in Table 1 below, the area of Supplier Dependency Management, the ASF identifies specific domains for each supplier that organizations must consider when creating a cybersecurity strategy to address supply chain risk.

Each of those goals then introduces multiple questions that will help organizations tailor a supply chain risk management approach to their program. The following shows the specific questions assigned to Domain 1: Relationship Formation.

Organizations that are acquiring software need to define how they will address concerns in each of these domains. Unaddressed areas in this domain must be considered potential gaps that represent unknown risk. Just as importantly, organizations need to allocate the funds, personnel, and oversight for these domains to ensure that they have the practices in place to monitor the risk and respond quickly if unacceptable results materialize to minimize impact.

The New Reality: Victim by Relationship

With each Log4j and each Solar Winds attack, the impact continues to grow. It is no longer a single organization that is attacked: The fallout spreads to all of the interconnected organizations that have used software originating from the compromised source. Our new reality is that organizations will fall victim to an attack as the result of a relationship with a software supplier rather than a direct attack.

For far too long, organizations have simply inherited the risk. This is one of the driving forces behind the push for adoption of a software bill of materials (SBOM) to itemize the pieces of software that are included by suppliers as a first step to evaluating. Many organizations can’t identify all the suppliers that contributed to a software system because that system comprises software from subcontractors who are sometimes three levels removed, and it is impossible to trace its origins.

If you are interested in piloting an early model of the ASF, please let us know. We would welcome your feedback.