A Role for ISACs in Software Supply Chain Assurance

If one is focused on assuring security for the vast array of software, it may be a natural inclination to break it up into industry-focused initiatives. Several models have been proposed to the Multi-State Information Sharing and Analysis Center (MS-ISAC) and other ISACs for a role in software assurance for supply chains using the Software Bill of Material (SBOM) information and associated digital signatures.

Analyses that explore a role for industry-focused groups in software supply chain assurance must consider the potential effectiveness, feasibility, and funding models. As such, an important comparison is the current ISAC model(s) and the future of information sharing and threat intelligence dissemination. 

How ISACs Might Factor into Software Assurance

Two specific roles have been proposed for ISACs:

1. Industry-specific groups to vet software assurance 
2. A clearing house for vetted software for that industry

It is important for the software owner to fully own the software assurance process included in the software lifecycle to enable expedient patching and updates for remediation. If the organisation responsible for the software is notified of a vulnerability and follows a responsible disclosure process, there is a set number of days to deliver patches to the affected systems prior to the vulnerability's announcement.

In a traditional development and deployment model, the time period is usually 90 days. Here, the SBOM describing the software is updated to reflect the version or patch information and, in some cases, incorporate additional details about the update. Quality assurance procedures that are part of the software development lifecycle are followed and possibly included in the SBOM, as well. In this instance, the vendor places a signature on the SBOM, taking responsibility for the assurance process followed in their development lifecycle and thus maintaining ownership and responsibility for the security of their software.

If software is managed through a DevSecOps process and the team has embraced continuous delivery or continuous deployment models, the owner of the software is the only party that can effectively manage the update and assurance flow when following a responsible disclosure process. This is due to individual timelines established by the organisation that may include remediation for vulnerabilities that cannot be disclosed at the time the patch is released. In some cases, one party may remediate software vulnerabilities of a certain type before other organisations that follow traditional software development models have a chance to do so. If a third-party vetting process is required, the software owner should be the party to initiate that request and pay for the accreditation process. In this way, the software owner would be fully responsible for their product timelines and the costs surrounding the assurance process. The software creator benefits from assurance markers, attesting to the security levels met by their software in that it may open up markets with specific requirements on assurance.

Third-party software assurance could be offered at varying levels. It could be indicated by various means, including a certificate associated with the digital signature on an SBOM. This model would give the software creator the choice to have software assessed (or not) and at what level. SigStore, for instance, may not require any third-party vetting; other sources for signatures may follow stringent accreditation processes aligned to NIST’s Secure Software Development Framework (SSDF), SafeCode, and other sources for software development best practices.

Assurance by Industry Group Model

Let’s map out what it would look like to use a "per-industry group" to vet software versus the vendor owning that process. A software creator/owner would create and sign an SBOM providing details on their software including version, processes followed, etc. The third-party organisation vetting software would:

• Analyse the quality of the software, including any process followed for development, to provide an indicator of an assurance level. This requires staff to be well-versed in software development security best practices and tools so that they can support the vetting process.
• Identify a method to indicate approval – or not – of the software vetting. This may be a digital signature with associated properties included in a certificate that uses a key for signing, or it might be written to a ledger (distributed or not).
• Offer funding source options:
  • Vendor-requesting accreditation connects directly with revenue streams for the product and offers a long-term support option with direct ties to financial benefits from accreditation.
  • Member-funded avenues (in the case of industry-specific groups) have highlighted the problems that result when a solution requires distributed resources from members of variable means.
  • Government-funded routes are a large ask, as there are 11 sectors (based on the Global Industry Classification Standard) and 24 industry groups

Using a ‘per-industry group’ to vet software leaves additional questions to be answered:

• Would these vetting organisations have member countries, or would they be country-specific?
• Would the vetting process be codified in a standard, and would that standard be internationally accepted?

Full integration has the highest rate of success in meeting the needs of a diverse supply chain in terms of access to resources and people. This full integration has the greatest impact when directly present in products where AI/ML might be used to make decisions natively without the need for bolted-on solutions. An expectation of distributed experts in an architectural model places an increased burden on information security, expanding the required number of experts and further increasing the existing deficit of security professionals. Industry has experience to build off and do better with scaling software assurance by reaching all organisations in the supply chain, including those with few resources. It seems clear, therefore, that the software owner being responsible for the assurance process of that software is the most efficient and effective method.

Financial responsibilities and expertise requirements help shape the viable options for accreditation or assurance on software. The assessment of SBOMs and any associated accreditations or assurance processes should follow current best practices where software assurance "shifts left" and is built in. A proven method is the use of public key infrastructure (PKI) markings on certificates and path validation on the certificate, associated keys, and the root certificate. The Certificate Authority (CA) with the root certificate is established and managed following a Certificate Policy, instantiated by a Certificate Practices Statement – which, for higher levels of assurance on a CA, is attested regularly through external audits to meet the supported policies and practices. Distributed systems are then able to make judgments based on the certificate, the indicated properties and assertions, and associated keys in an automated way.

Clearinghouse of Vetted Software

Now let’s consider the other proposed model in which an ISAC serves as a clearinghouse of vetted software. Assuming software has been vetted to the degree desired by the software owner and the SBOM has been created with details of the software and assurance process, clearinghouses for software should be able to make decisions based on the provided information:

• Code and SBOM are digitally signed and assured by the software owner
• Assurance process and software details are included in SBOM
• If a portion of code is included in build, this is represented in SBOM for accurate evaluations
• Assurance performed on software is signed by accrediting party

The clearinghouse function might be performed by an ISAC or through an ISAC using approved partners. Software clearinghouses also exist in operating system-based application stores and through cloud hosting providers, for example. In both cases, this type of vetted assurance "shifts left" the task of validating software, ensuring the responsibility for maintaining secure code rests with the software creator.

In terms of applying lessons learned from information sharing, the objective of organisations running secure software to some level of assurance is met in this model. This model considers "shift left" where security is built in and managed at scale. SBOMs for each software package provide a transparent audit trail; however, the additional overhead of vetting SBOMs is centralised, reducing a set of potentially unrealistic responsibilities on each organisation to perform this function.

Going Beyond Automation and Built-in Security

As new solutions are considered and designed, it is imperative that we consider simplification, shifting left security, and the requirements for ongoing management to ensure these solutions are sustainable. Automation and building in security are not enough; the architectural patterns for managing security must also reduce the overall number of professionals required. Reducing the burden on under-resourced and underserved organisations – of all sizes – is critical to reducing the possible attack surface of applications, systems, and networks.

This second proposal was provided by Jon Geater, Chair of the Security and Trustworthiness Working Group for the Digital Twin Consortium. Jon is also the co-founder and Chief Product Officer at RKVST. The Center for Internet Security (CIS) will explore the second proposal and others with partners, as it has the potential to reduce the demand on individual organisations and improve their overall security posture.

This article was originally posted over on the CIS blog.