Software Identification & Traceability: Essential to Securing the ICT Supply Chain

By Carlos C. Solari, VP of Product Development at SecureG

Software identification and traceability (SWID&T) is essential to securing the information communications technology (ICT) supply chain, especially considering the central role software assets play in today’s ICT networks and virtually everything we do. As such, SWID&T controls are key part of SCS 9001, the upcoming TIA supply chain security quality standard.

Let’s take a closer look at the approach.

A Shift of Focus is Needed

In today’s digital era where everything is built on a foundation of software, trust that was previously associated with people is now also associated with digital activity, devices, and software. Software runs our chemical plants, our transportation systems, our electric grid, and even our national defense systems. It is responsible for everything from network bandwidth allocation, system and device management and control, and modern-day communications, to the processing, analyzation, transmission, and storage of data. With the implementation of 5G and emerging IoT/IIoT, the role of software will continue to grow – in the data, control, management, and user planes – across every aspect of systems and how we as societies use these systems.

As the software revolution continues to expand, so does the attack surface, and we need to figure out how to secure it. The trend towards open source software that now exists in nearly all codebases and software-defined networking technologies like Network Functions Virtualization (NFV) within 5G and in backhaul networks further increases security concerns.

The first step to securing software is to shift the focus. There are essentially three stages in the deployment of software—point of creation (i.e., software and application development), point of aggregation and integration (i.e., implementation of software into a systems, device, or piece of equipment), and end user (i.e., where the software actually gets used). In the past, many had the mindset that the responsibility for security resided at the end user level, and it was up to them to implement security measures such as firewalls, encryption, and anti-virus software. However, placing the onus on the end user does not get to the root of the problem and significantly increases vulnerability to attack. We need to shift the focus and accountability back to the point of creation to ultimately ensure that security is inherently designed into software as part of its development lifecycle and how it is distributed and operated.

Accountability Through Standards

Technology providers that implement software into their systems, devices, and equipment (i.e., point of aggregation and integration) hold the purse strings and ultimately determine what software they are going to purchase. If these companies implement SWID&T and require it of their suppliers, it forces accountability down to the supply chain to those that are developing, packaging, and licensing software.

There are many examples where this kind of discipline is already working. We can see the success of this approach in the United Arab Emirates for example. Before any government agency can put out a smartphone app associated with UAE, it must go through comprehensive testing and validation. Accountability is assigned to the agency developing the software. Once software developers from those organizations started submitting their apps and failed to meet the requirements, they had to address the problems if they wanted their app to be available in the app store.

Placing accountability at the point of creation is best achieved via standards—any entity purchasing software can require suppliers to follow a standard that is measurable and enforceable, essentially leveraging the power of commerce. Standards also allow technology providers to ensure security requirements are identified up front across all systems and they provide suppliers with a reference point to know what they need to do to comply—all while maintaining the reputation of both provider and supplier via standards compliance.

A key concept gaining traction is the idea that technology (software) developers are accountable to maintaining software bills of materials (SBOMs) in the same manner that is already done by manufacturing companies. Software today is rarely built from scratch but rather by combining a variety of components that include source code, firmware, APIs, operating system functionality, middleware, and web and mobile applications. SBOMs essentially include granular information (e.g., owner, author, license, release number, version, etc.) about the origin of every software component that goes into every piece of equipment or device, allowing it to achieve its intended function. There are also additional resources and empirical data that should be leveraged as part of a standards-based approach. For example, OWASP (Open Web Application Security Project) provides guidance to developers and routinely updates the top 20 mobile application security risks.

Implementing SWID&T in SCS 9001

SWID&T is a key part of the SCS 9001 standard, and the SWC Workgroup’s SWID&T team has been diligently determining the process requirements and security controls that serve as the basis for this critical objective.

During the initial landscape analysis that analyzed more than 30 existing security standards across multiple industries, the SWID&T team found that while existing well-practiced standards for cybersecurity included some aspects of SWID&T that could be adopted into SCS 9001, there were significant gaps in security controls needed to address software at its point of creation across many forms and within the broader ICT supply chain.

To address the gaps, the team has identified the following ten key definitions that form the attributes for SWID&T security controls within SCS 9001:

• Software –Achieves assurance in the development of software
• Authenticity – Establishes that the software is from its claimed source
• Accuracy –Determines via testing whether software performs only its stated capabilities
• Validity—Verifies that software is developed for and performs its intended purpose and nothing else
• Legitimacy—Establishes that code was acquired from permitted and authorized sources, can only be modified by authorized means, and is used with licensed permission and legally-permitted purposes
• Verifiable—Evaluates code via a third party in ways that limit the ability of an attacker to insert code and hide the code
• Provenance—Determines the software origin and attributes related to its legitimacy via the concept of SBOMs
• Integrity—Ensures methods that assure quality in the development and testing process as related to identifying and removing vulnerabilities
• Attestation—Ensures software authenticates itself to other resource such as a remote server, which is essential in software-defined networks
• Trustworthy—Combines all ten attributes to make a trust determination based on empirical data and contextually with relation to purpose, time, location, usage, etc.

 

Carlos Solari is VP of Product Development at SecureG, a company working to develop universal security technologies in Public Key Infrastructure for 5G. Carlos has held several senior management roles in cyber technology, previously served as CIO at the Executive Office in the President, George W. Bush Administration, was a member of the Senior Executive Service team at the FBI in the 1990s and was the principal author in the Bell Labs commissioned cybersecurity book entitled, “Security in a Web 2.0+ World.” Carlos currently chairs the TIA Supply Chain Security Workgroup’s Software Identification and Traceability team.