Cloud Considerations

Logically, we want to understand how our data is processed, how it’s dealt with in transit. In a shared environment, do we have dedicated hardware? If it’s not dedicated hardware, and we talked about resource pooling already, if it’s not dedicated, how is it isolated and segregated? Data needs to be secured during process and also during transit within the data provided, within the service provider, and also beyond the service provider’s cloud network. If we’re using SSL TLS, we need to make sure we’re using the right version. We need to understand what the vendor’s approach is, depending on the deployment type, what the vendor’s approach is to vulnerability management, to proactive upgrades of their applications.

For data portability, if we end a contract with a cloud provider, how do we get the data back from the cloud, or how do we transfer it to a new provider, or how do we integrate it? If we have a disposition process, a deletion process, how is this managed? Is it securely managed? Do individuals have access to our systems, to our passwords, to our configurations? From a personnel perspective, it’s easy to forget that there are people involved in managing the cloud service remotely. Does the cloud provider undertake personnel screening? Where are the administrators? The administrators may not be on the same continent, never mind the same country, as the data centre, as the cloud data centre.

Do the third parties have access to your sites or service? Do any other third parties beyond the cloud provider have access to sites or services? If we’re a technology company and we’re using a cloud service, is a vendor or a managed service provider to the cloud provider one of our competitors? Are they somebody we would not want to have access to our systems? Are there any standards, regulations, or accreditations in place with our cloud provider? This isn’t a golden bullet, it’s not a panacea, but it can be a starting point for subsequent verification. If there is a certification or an accreditation in place, we can check that the company meets that requirement or meet that standard.

We can also ask for historical declarations relating to data loss or any compliance issues. We can ask for any payment mechanism or any service-level credits that are in place for service failures. So if the organization failed to meet their service standards, will they deal with any consequential loss arising from that? If a data breach happens and we are fined as an organization, will the cloud provider cover the cost? With smaller providers, this kind of negotiation is sometimes possible. With bigger providers, quite often, it’s a case that you take it or leave it. If you look at some of the very big services, they offer a best endeavours service-level agreement.

You don’t have compensatory payments if there is an outage or if there is a breach. Of course, we also need to think about, when we’re using cloud services, the connectivity. Is it secure? How do we access it? And if we’re using these cloud services, we need to make sure that the services are appropriately integrated within our environment and that we have the correct levels of availability. We want to think about the customer. Can they access our services? The enterprise, can we access our services? Are there pre-built connecters to third-party services? Is there a standards-based approach in place that we can use? What kind of bandwidth and latency is on offer, and what kind of bandwidth and latency do we have?

So if we look at some voice-over-IP-based services that were implemented, some of those were pulled. Microsoft pulled its first iteration of its cloud-based voice service so it could address issues around latency and bandwidth. Systems may end up working well at some sites and not others. If we have multiple sites with different levels of connection, the user experience may vary. So we need to be aware of our customers and vendors, our supply chain if we’re using any cloud-based ERP system. Can everybody access it? Is it accessible to everybody that we need it to be accessible to? If connectors are available, pre-built connectors, that’s great. It can save time and money.

If we just have an API, then we may need some development capability to integrate those APIs into our systems or into other third-party systems. If we’re using third-party APIs, we also need to make sure that they are appropriately secured. Identity and access management applies to APIs. APIs are a subject trying to access an object. The same principle applies. So much of this boils down to trust. We need to trust the different vendors involved in the process. We focused on this a lot, but this is ultimately what it boils down to. We need to have something to trust.

We need some dialogue with the provider to understand what they are stating they will do and some way, ideally, of checking that they are doing what they say. If we can look at their financial viability, what hardware and software they’re using, where they’re storing our data, how they’re managing our data, is there any escrow arrangement in place? Are they, are they willing to place access if they go bankrupt? Will they place access to their code or to their services and systems? Will they trust that to a third party? Ultimately, with cloud services, we are trusting a third party.

And ideally, we want to make sure this isn’t blind trust, that we have done some level of investigation into what we’re getting ourselves into if we’re drawing down these services. The very easy way we access these cloud services mean that people can just slide into accessing them without taking the proper approach of assessing the security implications and the implications and strategic fit more widely with our existing services.