Have you heard this before:

“Our data is all stored in the cloud so it’s totally secure” or “we have guaranteed 99.9999% uptime as we use the cloud?” I have heard this from IT teams, executives and board members alike. These misconceptions can lull entire leadership teams into a false sense of security, thereby reducing the amount of effort on building and testing incident response plans and leaving organisations exposed to massive risks.

Before I launch into the risks and how to check exposure, just a few comments on using large cloud service providers. They spend heavily on:

• Top-of-range servers and storage
• Highly resilient data centres
• Fast and resilient networks
• Dedicated, highly qualified and experienced cybersecurity personnel
• Many other security and resiliency risk mitigation techniques

One of the largest cloud service providers suffered an incident on 23 October 2019 with some of their customers experiencing up to 12 hours of service interruption. Also, an Australian bank that has all the above technology themselves experienced a system outage down on Thursday 17th of October 2019 causing so many repercussions that they took responsibility and have already provided some financial compensation to those affected. They took responsibility but some have assumed that the root cause of the problem was a patch from their 3rd party software vendor.

This is just in the last three weeks. Countless organisations and individuals all over the world were affected by these issues caused through their service providers’ dependence on 3rd parties for delivery of technology services:

• In the example of cloud companies, they are the 3rd party platform provider – aggregators of service
• For the bank they are a 3rd party provider and aggregator of financial services

So, the rabbit hole goes very deep in terms of cause, impact and responsibility. For these few incidents alone, I read a story about an individual who was denied critical surgery overseas due to an inability to access funds. I also heard of a company that missed out on a tender due to a lack of access to critical software. What about the problems these incidents also caused for millions of people who had no part in the cause of the outages?

The larger and more regulated an entity is, the more likely that they will have one or more teams that look specifically after 3rd party service providers. They investigate important details like service level agreements (SLAs), contract small print, termination of contracts and limitations of liability. They can do this because they have lawyers who understand contracts and service delivery managers who understand SLAs etc.

But what about everybody else who wants the shiny cloud computing, and ultra-fast internet, and 6-nines of uptime billed by the nanosecond of utilization, with no lock-in clauses, right now? Unfortunately, a lot of people just click the ‘Accept” box.

Briefly on the large, regulated entities. They, like all organisations, can also be susceptible to 3rd party service provider risks from “shadow IT,” Sounds scary because it is. This is where despite (and maybe because of) the best intentions of procurement policies around the adoption of new systems, sometimes people can’t wait for the correct approvals from IT and procurement. With cloud-based software and infrastructure access only a credit card number away, there are many examples of organisations using systems for operations that the IT department, let alone procurement and legal, didn’t know they had.

I remember individuals plugging in access points all over the place when WiFi came about because their IT departments hadn’t decided the technology was safe for the organisation to adopt. One of the first WiFi security standards, WEP, was quickly and relatively easily compromised.

Now back to the subject. “…it’s not our fault!” Yes, it is, and most likely you will be held accountable. Without a diagram let’s see if this explains some of the responsibility chain: Let’s say your organisation is XYZ that holds several thousand customer records which can be considered sensitive. XYZ was an early adopter of cloud services and uses Cloudy Cloud (not a real company unsurprisingly) for compute and data storage, with no problems so far. Cloudy Cloud has built a perception that they are unbreakable/unhackable.

Cloudy Cloud has a data breach and XYZ’s customers’ personal records are available for sale on the “dark web” to the highest bidder. In October I posted a piece on what XYZ should do should there be in incident, but here is a high-level breakdown of responsibilities:

• The customers affected by the data breach are under contract with XYZ
• XYZ is contracted to Cloudy Cloud for data storage services
• There is no contractual relationship between Cloudy Cloud and XYZ’s customers and they may not be aware of where their data is physically stored
• XYZ most likely has an obligation under the Federal Privacy Act to notify the individuals affected and the Privacy Commissioner

While the breach might be Cloudy Cloud’s fault, the impacted individuals have no direct recourse to Cloudy Cloud, only to XYZ, whose rights in relation to Cloudy Cloud fall under the terms of their service agreement. In most cases there are limitations of liability in these agreements which may not cover any flow-on costs to XYXZ.

In many cases we have seen that the fault for data breaches of cloud customers has been due to incorrect or insufficient implementations of the cloud providers’ security management frameworks. There is a shared responsibility security model between the customer and the cloud provider.

Therefore, ultimate responsibility for managing the incident and any impacts to their customers lies with XYZ. In reality the circumstances are far more complex, however it is a good strategy to assume that your organisation, as a provider of services to your customers, is responsible for any incident that impacts them.

In any case 3rd party IT service providers are a part of most organisations’ IT capabilities, and adoption continues to increase rapidly. Here are a few simple recommendations on 3rd party cyber risk management:

• Build a 3rd party service provider register that includes specific sections on incident handling and liability
• Review the contracts with your legal team in the context of a major incident
• Build out risk scenarios, and formulate an incident response plan that includes the third-party service provider response capabilities, and involve them in planning and exercises
• Test one or more of the scenarios with risk simulations, these will highlight gaps before an incident happens

Should you have any questions or would like some assistance with the above recommendations, please get in touch.