How does the industry effectively assess software security, enabling an approved list (allowlist) of software and libraries on distributed systems across multiple industries? This is a difficult question; multiple architectures are currently under consideration. We already have industry-specific Information Sharing and Analysis Centers (ISACs). So, is there a role for ISACs in automated software assurance?
This topic and potential solutions have been raised multiple times. This blog post along with future installments will explore these questions.
The ongoing task of software assurance
Supply chain security and the ability to easily assess software asset security depend on reliable ways of describing the software, verifying software security properties, and assessing trust. Trust in this case may be a party responsible for correcting discovered vulnerabilities in a timely manner. Alternatively, it might be an assurance that the software has been assessed for security with an understanding that vulnerabilities do occur.
While there has been significant work done on supply chain security, efforts surrounding automated software assurance continue to evolve. Today, we have some level of assurance provided by app marketplaces that assess software to particular requirements, but this is limited in scope and varies between platforms. The May 2021 Executive Order on Improving the Nation’s Cybersecurity requires the use of the National Telecommunications and Information Administration’s (NTIA’s) Software Bill of Materials (SBOM) to describe software acquired by the US federal government. In response, vendors and standards participants are working to build off of the defined formats and digital signature requirements specified in the Minimum Elements for an SBOM (PDF).
Accounting for different levels of resources
While it is important to think about scale in terms of implementation, we must also consider scale for users and organizations who might evaluate supply chain security at the system level or on an individual network. That is, if the verification process requires distributed talent at each organization or a large number of resources per industry, the solution will not adequately advance supply chain security or software assurance for organizations that are resource-constrained.
Every day, the Center for Internet Security (CIS) supports numerous under-resourced organizations. For these entities, implementing yet another technology can often inhibit adoption. That’s why working with others in the industry toward better outcomes for organizations of all sizes is imperative. Built-in security that’s managed at scale is essential for successful adoption, not only for small organizations but also for large organizations constrained by resource limitations.
The processes and architectural model for assurance should therefore consider the following questions to account for a difference in resources:
- What process and format does each vendor follow to create an SBOM?
- Who is responsible for the software and assurance if a problem is found?
- What quality assurance processes and procedures are required, when are they performed, and by whom?
- Are the quality assurance processes indicated in the SBOM by a policy associated with a certificate tied to the key used for the digital signature, properties of a distributed ledger, or some other mechanism?
- As there’s a massive amount of software and some are industry-specific, how is each software package or library vetted?
- How do we handle vulnerabilities and patches to software within an assurance process?
- How do responsible disclosure processes fold into the software assurance processes?
- How is open-source software assured? Is it the same process as proprietary software?
- How are the processes and personnel supported over time for each piece of software or library and in each industry?
- Are there planned levels of assurance, and if so, how are they managed?
Navigating potential pitfalls
The industry is at the early stage of determining steps toward automated software assurance based on NTIA’s SBOM. Exploring both requirements on how to secure the supply chain for software and lessons learned from similar initiatives may lead to a more successful outcome — or at least help us avoid some pitfalls.
With this in mind, we’ll dive into some of these questions using the lessons learned from information sharing in a future blog post.
Kathleen Moriarty is Chief Technology Officer at the Center for Internet Security and the former IETF Security Area Director. She has more than two decades of experience working on ecosystems, standards, and strategy.
Adapted from the original on CIS Blog.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.