The software supply chain will continue to be a challenge in 2022, with some anticipating a potential cyber catastrophe as worldwide governments race to defend themselves in the cyber arms race. The US is in a particularly vulnerable position. As Nicole Perlroth states in her book, This Is How They Tell Me the World Ends, “The biggest secret in cyberwar – the one our adversaries now know all too well – is that the same nation that maintains the greatest offensive cyber advantage on earth is also among its most vulnerable.” While we’ve focused heavily on offense, our defense has been slow to keep pace. That is why agencies must consider ways to build resilience and trust into their software supply chains and shore up those defenses.
To that end, the greatest risk to our nation’s infrastructure is the complexity and dependence on software. However, since we can not get rid of software, we have to come up with stronger ways to build resilience into our infrastructure to mitigate the vulnerabilities that can be introduced through software.
Reflecting on my testimony in front of the US Senate in 2017 I laid out five key concepts: Identity, Trusted Data, Isolated Networks, Intelligence and Orchestration. Many of these concepts are key ideas that are currently addressed in DevSecOps, but we still have a lot of room for improvement. To continue to build resilience in software supply chain security in May of this year the United States issued Executive Order 14028 on Improving the Nation’s Cybersecurity to address more of the gaps within our Software Development capabilities.
The core of my testimony, and the underpinning of the executive order is trust. Software supply chain attacks completely erode trust. So strengthen that trust the software industry is coming together with the government to build a better approach to software development. Currently NIST working with the public is putting together the Secure Software Development Framework.
To create an anchor of building greater trust, the Software Bill of Materials, originating out of the NTIA, spearheaded by Allan Friedman, has been put forward to allow organizations greater visibility into the core components of software they purchase and operate. The Software Bill of Materials is a great first step in starting to build transparency into the software development process by giving an organization a list of all the software they may have in their inventory. SBOM is one of many practices that will be required to understand the risk of operations and the ability to create greater resilience in software.
Why is This Such a Hard Problem to Solve
All software is made up of other software. The larger the software application, that challenge is compounded. As enterprises and governments buy tens of thousands of software products, complexity increases by many folds. To continue adding to this tangled web is that software is running in large organizations and it is often interoperating and sharing data and controls with 100’s of other pieces of software. Which means if one vulnerability in one software application exists it can have horrific cascading effects.
That’s why currently methodologies such as DevSecOps are critical to build resilience into how organizations can respond to those vulnerabilities. DevSecOps when implemented through best practices can help organizations build rapid automation into the response to attacks. Additionally when paired with the intelligence that SBOM can give an organization as to the component parts you start building some great strength and resilience into your organization.
Understanding Resilience
Our best chance of responding to cyberattacks, regardless of type, depends on our resilience. That’s made up of four key components: best practices, automation, asset management and auditability and integrity.
Asset Management: NIST best practices set the foundation for resilience by standardizing protocols and aligning everyone to the same goals. That cybersecurity framework is flexible, allowing its application across entities regardless of size. The framework core breaks systems down into five key areas: identify, protect, detect, respond and recover. Mainly, you should know what you have and the threats you face, have a method of locating anomalies, respond to them and then learn from the incident.
Best Practices: DevSecOps is actually a key principle in NIST best practices. It makes security a central part of your system that adapts to threats over time. Automating standard tasks, like testing code and threat detection, limits the risk that they’ll be overlooked and provides proactivity in the face of changing threats.
Automation: You can’t protect what you have if you don’t understand it. This is one area where the software bill of materials (SBOM) will be imperative. The complexity of modern software makes it difficult to locate potential vulnerabilities. SBOMs create system roadmaps where you can find and eliminate those issues as soon as they’re detected. They give us the intelligence we need to build greater resilience to resist and recover from security incidents.
Auditability & Integrity: This is an area that we’re still struggling with today. When I testified, I talked about identity and trusted data. That hasn’t changed. We need a way to verify the individuals who access our systems and ensure the stability of the data we exchange with them. Auditability builds in transparency across the entire software supply chain, allowing us to make better decisions about who we give access to and why.
Governments across the world are racing to create a cyber advantage as our conflicts move into digital spaces. While we continue to learn about cybersecurity, so do bad actors, both private and state-sponsored ones. The only thing that keeps us ahead of them is our resilience. The above components are pillars in a resilient strategy that will continue to support us even as threats change.
