The hackers who compromised SolarWind’s Orion network-performance monitoring software pulled off one of the most thorough compromises of a target that has ever been carried out, and they did this by subverting a vendor’s software supply chain.
The attack has made thinking about (or at least talking about) the security of software supply chains trendy. Lots of meetings are being held to discuss the topic. I have already sat—or rather, Zoomed—through many.
Many enterprises are requiring all of their software vendors to fill out long questionnaires of dubious value so that they can reassure their auditors that they have taken commercially reasonable steps to ensure that they haven’t suffered a similar compromise. Software vendors in turn are requiring their subcontractors to fill out such questionnaires, and so on and so on.
It’s not hard to imagine this trickling down to the developers, who, because they can’t make someone else fill out a long questionnaire, will instead annoy the people at fast food drive-through windows by asking them about their supply chains.
“Hello, sir, may I take your order?”
“How do you know that fully refined paraffin wax was used to make your drink cups instead of a less expensive semi-refined version?”
“What?”
“Oh, never mind.”
But with timing that’s so perfect that it must have started a conspiracy theory or two somewhere on the Internet, NIST just released NISTIR 8276, “Key Practices in Supply Chain Risk Management,” which talks about best practices that you can use to ensure that your software supply chain is reasonably secure.
Being a good summary of current best practices for doing this, it’s a document that you should take a look at if you’re interested in this topic. It identifies eight key practices that can be used to implement a robust cyber supply chain risk management program (S-SCRM).
Supply chain management best practices
NIST’s eight key practices for supply chain security are:
- Integrate C-SCRM across the organization
- Establish a formal C-SCRM program
- Know and manage critical suppliers
- Understand the organization’s supply chain
- Closely collaborate with key suppliers
- Include key suppliers in resilience and improvement activities
- Assess and monitor throughout the supplier relationship
- Plan for the full lifecycle
It also has a list of 24 recommendations for how to improve your own S-SCRM. They’re on page 13 of the document and are too long to include here. They make lots of sense and are the sorts of things that everyone should probably seriously think about doing.
But NISTIR 8276 should also remind you of Peter Allen singing “Everything Old Is New Again.” NIST has been publishing documents of one form or another since at least 2012 that talk about the security of software supply chains and even has a significant project dedicated to the problem. In addition to the recent NISTIR 8276, NIST has published:
And it’s not just NIST that has thought about how to deal with software supply chain issues. The people at Carnegie Mellon’s Software Engineering Institute also have had a thought of two, as demonstrated by “Evaluating and Mitigating Software Supply Chain Security Risks” (2010), “Software Supply Chain Risk Management: from Products to Systems of Systems” (2010), and “A Systemic Approach for Assessing Software Supply-Chain Risk” (2013).
There’s even an ISO standard on the topic: ISO/IEC 27036-3:2013, “Information technology — Security techniques — Information security for supplier relationships — Part 3: Guidelines for information and communication technology supply chain security” (2013).
These documents have lots of good information, which is what you get when smart people have been working on a topic for a while. But the issue of software supply chain security, as well as how to deal with it, isn’t new. The NIST publications alone go back several years. And if there’s an ISO standard for something, that probably means that it’s been around for more than a few years.
Is that Peter Allen I hear singing?
But if we know so much about securing software supply chains, how was it possible that an attack as effective as the one on the SolarWinds product was possible?
A likely explanation for this is that the very existence of the NIST documents (and ones like them) caused this. But this isn’t a reflection on the usefulness of what NIST has done. It’s just that when it comes to security, people think they can get by checking a series of boxes.
“Yes, we comply with Requirement 1.”
“Yes, we comply with Requirement 2.”
…
“Yes, we comply with Requirement 96.”
“That’s the last one. We’re secure! What a relief!”
But with this approach, checking the boxes often becomes the goal, while the more meaningful goal of getting effective security is generally forgotten about.
Chuck the checkbox approach
Information security is a complicated and hard job. It’s so complicated that it’s essentially impossible to get it right all of the time. But in this complex and ever-changing field, there seems to be at least one universal principle that’s always true: You never get a meaningful level of security by focusing on checking a series of boxes. Never.
But because that’s easier than solving the hard problem of securing our software supply chain, it’s likely that we’ll see more box-checking in the future, and the security of our software supply chain won’t get any better.
That means we can expect more compromises in the future that will be just as effective as the SolarWinds compromise was—meaning more Zoom meetings will be in my future. More questionnaires that everyone has to fill out will probably follow. And the guys selling hamburgers may have to answer even more questions from annoyed developers.
But I really hope that I’m wrong about this.
Recent Comments