Supply chains present significant cybersecurity challenges due to their complex and interconnected nature and numerous external service providers with varying levels of security maturity. These external partners – in particular the large number of cloud suppliers that we are directly and indirectly reliant on – can pose potential risks.
The potential for a cyber attack on a supply chain has been with us for a long time. For example, Ken Thompson talked about in 1984. It is worth asking yourself if the type of attack he described is any different from some of the attacks we’ve had in the 2020s, for example the MOVEit data breach or the one related to SolarWinds.
It is only in the last five years or so, though, that the security risks posed by our suppliers have really become a mainstream issue and gained a high profile in discussions and countermeasure development. Many organizations have become pretty proficient in the science of analyzing supply chain risk. But there is a special type of service that we buy whose security threats we need to consider: cloud services.
There are, of course, plenty of common factors in supply chain risks. The main one is that we have little or no direct visibility into our suppliers’ systems or operational processes, which means we have – at least for our most critical suppliers upon which an attack could cause us serious damage – to go through a rigorous exercise of interrogating them regarding how they operate, what risk assessments they have done, what resilience exists in their processes and systems, the controls they have put in place to mitigate the risks discovered, what plans they have in place to respond to and deal with incidents and so on. All of this applies just as much to our cloud suppliers as to any other type of supplier.
There are four key elements that, if not unique to cloud service suppliers, are hugely amplified relative to vendors that we just buy platforms or services from.
The Risk Assessment Exercise
First, we have the challenge of assessing the risks presented by the supplier. The typical exercise we do generally involves asking a supplier to complete a questionnaire that asks a load of pertinent questions about the things we already mentioned – incident response, resilience and the like. Some suppliers will engage rigorously with us because they want our business, while others will be tardy but will generally deliver the information eventually, even if only to stop the barrage of reminders we eventually start bombarding them with.
This type of exercise is a two-way street: we ask questions, the supplier gives answers, we probably go back with a few follow-ups and eventually we (in most cases) get to a stage where we are satisfied that the vendor is operating within the scale of our risk appetite.
Now try the same with the big names in the cloud. You want to risk-assess Microsoft Azure? Or Salesforce? Or AWS? Just imagine writing the email to them. “Hi there, we’re thinking of using your service, please fill in our puny little questionnaire so we can consider whether you’re up to the job”.
Of course, the big-name providers cater for most of what we need by having the materials everyone wants to see on their web sites. In some cases, they’re behind a password wall, but it’s usually pretty straightforward to apply for access to the portal. The main problem, then, is that the communication is one-way: the sum total of the information the vendor will provide is what is on its web site. The result is simple: we have to be flexible in the criteria we use to decide whether the vendor is suitable. You want a SOC 2 report that’s less than six months old and the only one the vendor has is from eight months ago? It’s unlikely you will get anything more recent: you either accept the risk, or you look elsewhere.
The plus side of signing up with the big names, of course, is visibility of incidents. Any time they put a foot wrong in terms of service quality or cyber deficiencies, the press shout it from the rooftops like the Bat Signal over Gotham. Any significant failings by big providers are big news, so the lack of direct information from vendors is largely offset by what you can find in the public domain.
The Multi-Hop Cloud Problem
The “big vendor” due diligence problem is compounded, though, when you are looking to contract with, say, a SaaS service provider that uses one of the big names as an upstream cloud provider. The reason is simple: you simply cannot demand something from your provider that they cannot get from their provider. You want to demand an RPO of 30 seconds? Good luck with that if the service your provider gets from their upstream vendor has a “typical” SLA of less than 15 minutes but no service guarantee.
Again, you have to be pragmatic. Yes, your supplier may be small enough for you to insist on lots of things and to push them into complying, but there is no point demanding the impossible if they have insurmountable dependencies imposed by their upstream suppliers.
Incident Response and Business Continuity
The next key consideration is one that should always be in mind when taking on a supplier: what will happen if something unexpected and big goes wrong?
This is a critical part of your risk assessment. If one of the major cloud players has a big outage that stops your business in its tracks, no amount of complaining to its support team is going to get the problem fixed any faster than if you were to sit back and wait for the service to be fixed. Vendors are highly unlikely to provide a service level promise around the fix time for problems because they would be irresponsible by making a guarantee about something they cannot fully control or which could break in such spectacular ways that a predicting the repair time would be impossible.
Your business continuity plan must therefore cater for the potential for there to be an extended outage that you can do nothing about except wait for the vendor’s techies to do their thing. If you cannot align this with your risk appetite, you need to consider whether you want to be using that service at all.
Exit Plan
Whenever you sign up with a supplier you must consider what will happen when the relationship comes to an end – which might be a graceful expiry of the contract or maybe even a forced exit thanks to poor service or some other unexpected event. With a cloud provider, moving out and going to another vendor is made vastly more complicated because there will be so much change required and a lot to uncouple.
An exit plan is essential, then, as it is imperative that you include the technical teams when you write it as most of the main problems with exiting a cloud supplier are technical. Your internet IP ranges may belong to the supplier, for instance, so you will need to plan a transition to new addresses in that scenario. The architecture will be different – you are unlikely to be able to lift-and-shift your virtual servers from one IaaS provider to another without some kind of modification. If you have connectivity to other vendors (such as site-to-site VPNs) then switching provider will often mean adopting a different VPN technology or changes to processes and protocols. Also, never forget the training element: a technical team that is fully comfortable with cloud provider X may be rendered absolute beginners regarding cloud provider Y. Always consider the eventuality that you may end up one day exiting the cloud supplier you’re about to sign up with; we guarantee that when you have thought a little bit about the logistics, you will see it is far harder than you thought it would be.
Summing Up
There is, of course, no absolute supply chain-related blocker for signing up to cloud services. If there were, nobody would be signing up to them. You do, however, need to have your eyes fully open and be completely honest with yourself about the risks around the confidentiality, integrity and availability of the data you will be processing in their world. Accept that you are a minnow in the ocean as far as the big suppliers are concerned and acknowledge that when something bad goes wrong, it’s you that will have to either work around it or simply accept some impact. Understand your suppliers’ suppliers and make clear to your senior management that if you are buying a service from company A and they’re using company B to provide the service, then the absolute best possible service level agreement you can make company A give you is the one that company B gives them.
Finally, make sure you consider the entire lifetime of the relationship. One day, you may well be going through this whole cycle again, but with the added technical complications of an inter-vendor move.
Related Insights