NIST Special Publication 800-161 on “Supply Chain Risk Management Practices for Federal Information Systems and Organizations” was issued about 5 years ago (it is currently going through a revision). It is a long document (based off the NIST 800-53r4 document on controls) and covers just about everything you could think of that is needed for a supply chain risk management program. I guess the hope was that the practices would be adopted and it would be game over for supply chain attacks.
…and then there was SUNBURST – an extremely successful supply chain attack that breached the US treasury (among around 17,000 other Solarwind customers). So, if the government had a supply chain risk management program defined for 5 years – why did the attack succeed?
I think it goes back to complexity combined with lack of appropriate process and automation. The document has a lot to say the vendor acquisition and management process. None of which would have done anything to prevent the attack. The breach couldn’t have been prevented using vendor management – no matter how good. I am sure there were a lot of spreadsheets created for the Solarwind risk assessment before the technology was purchased and for ongoing management of the relationship. The problem was the lack of automation for the “monitor” (i.e. continuous monitoring) phase of risk associated with managing vendor risk in light of the continuous drift in the external threat and internal control environment.
However, at the very back of the document starting at page 241, the appendices C and D hold the key to making this (and many other) cyber programs successful. These appendices focus on threat (or what we call attack path) scenarios and analysis. My guess is that this part of the document wasn’t given the attention it deserved (hey, it is only an appendix after 241 other fun filled pages) – but it is the only part that really focused on ongoing monitoring and management of issues caused by drift in the internal control and external threat environment. It doesn’t provide automation, but at least it has a recipe for a structured approach to monitoring with well-defined goals and scope. Another way to think about threat (attack path) scenarios and analysis is as a continuous, comprehensive “zero trust” risk assessment process.
Like everything in the document the appendices are very comprehensive, and a lot can be learned from them. But as I learned early in my career if the recommendations are expensive, complex and without automation – they are bound to fail.