Skip to Content

Do you Understand Supply Chain Risks?

The NIST have put out a standard for risk management of supply chains, which is a reasonable set of models to start thinking about supply chains. But for most organisations, we struggle to articulate the difference in threat between several different scenarios. For example, would you describe all of these as “supply chain risks”?

Do you Understand Supply Chain Risks?

  1. Your company is reliant on a technology provided by a third-party company. One of your direct competitors has just decided to a significant stake in that company and will now sit on its board of directors
  2. Your company outsources a critical piece of business information processing to a third-party company, but that third party company has been hit by ransomware and says they won’t pay the ransom so the data will be exposed
  3. Your company uses a third-party management company to manage a number of internal systems, and that management company has been compromised by attackers
  4. Your software is reliant on libraries written by a third party, and that third parties software writing and delivery pipeline has been compromised
  5. You use a critical piece of management equipment or software that has privileged access to much of your organisation, but the supplier of that equipment has been compromised

I think that many of you would easily be able to argue that all 5 scenarios belong in the world of “supply chain”, but they all present wildly different risks to your business, and they all need to be managed totally differently.

Secondly, supply chains are by nature recursive. For those of you without a background in computer programming, recursion is where the definition of a function is reliant on executing the function itself. A good example is a dictionary entry for recursion might say “see recursion”. The most common example is the definition of a factorial, which is simply the number multiplied by itself minus 1, so 5 factorial is 5 x (4 factorial). In this case, we always declare that 1 factorial is a special case of 1, and so we end up with 5 factorial = 5 x (4 factorial) = 5 x (4 x (3 factorial)) = 5 x (4 x (3 x (2 factorial))) = 5 x (4 x (3 x (2 x (1)))).

This act of essentially doing the same thing every time you descend is important here. Because you aren’t just worried about a single scenario. If you have scenario 5, the SolarWinds example, then you aren’t just worrying about whether you use SolarWinds on your network, but you are also worrying about scenario 3, where there’s a managed security company operating your systems, and you are now having to worry about whether that managed service company is using SolarWinds on their network.

This is what makes supply chains so difficult to comprehend, because you can end up in chains of dependencies and trying to work out just how big an issue it is for you.

At a recent event, I was chatting with a supplier who was asking me if we could improve the way we ask commercial questions of our suppliers. It was said that it’s quite common to have a clause in the contract that requires us to be able to inspect their data centers if we need to. But since they have started using cloud systems, they are unable to fulfil some of the clauses of the contract, because they don’t own the data centers that are being used by their SaaS tools. The question there then starts to be, what level of assurance or accreditation can bubble up. If they are asking for SOC2 compliance in their suppliers, is that sufficient for us, providing they have a good risk management process (as verified by something like ISO27001)?

It feels like this has got to be part of the solution, but I don’t think we’re agreed on what we are actually worrying about, and so asking for SOC2 compliance or even ISO27001 compliance for use case 1 is an exercise in futility.

I hope that we’ll soon come to an industry agreed definition of supply chain, that enables us to separate out commercial concerns from technical concerns from change and risk management concerns, and be far more easily able to articulate, in contracts, if possible, just what levels of assurance we are looking for.

Otherwise, we’ll be left worrying about an endless fractal and therefore infinite supply chain, and pushing that boulder up a hill for eternity doesn’t sound fun to me.

    Ads Blocker Image Powered by Code Help Pro

    Your Support Matters...

    We run an independent site that\'s committed to delivering valuable content, but it comes with its challenges. Many of our readers use ad blockers, causing our advertising revenue to decline. Unlike some websites, we haven\'t implemented paywalls to restrict access. Your support can make a significant difference. If you find this website useful and choose to support us, it would greatly secure our future. We appreciate your help. If you\'re currently using an ad blocker, please consider disabling it for our site. Thank you for your understanding and support.