Eight Steps For Cloud Security

These are the questions to ask any potential cloud vendor:

1.   What is the security of the facility running the servers?

2.   Is client data encrypted? If so, what encryption method is being used?

3.   Is the cloud provider's internal system segregated from its internet-facing cloud servers?

4.   Does the provider have a security audit they can share with us?

5.   What safeguards do they employ on their web service interface and/or API?

6.   Do they back up their data regularly and perform test restores for proper disaster recovery?

7.   What general data breach and protection policies are in place?

8.   Is client data shared with any third parties?

If you can't get satisfactory answers to these questions, deciding to do business with such a provider boils down to a decision about how much risk your firm is willing to take on to gain the potential benefits the service will provide. And, if this is an app for doing client work, you will also be passing on that risk on to your clients. That has to be fully understood at the Partner level.

So, what are the considered "satisfactory" answers to the questions above?

1.   Facility: Many cloud startups choose AWS, Google or Microsoft for their server hosting. All three of those providers have top-notch security controls, so physical facility security should not be an issue. In case they are using a lesser-known provider you would want assurance that the facility meets industry standard security compliance specifications. 

2.   Data Encryption: This is a tricky thing to get an answer to, because encryption can happen at many levels and be implemented in different ways. A simple answer of "yes we encrypt all client data" is just not sufficient. You need the details on what hashing and symmetric encryption algorithms are being used, and at what level. For instance, many database servers have an option to encrypt the data in their tables. But, in case of a SQL injection attack, that encryption exists at a lower level and doesn't prevent the data from being accessed.

3.   Service Segregation: This is a critical piece of knowledge. What you are asking is whether the servers running the cloud application are connected in any way to the cloud provider's own internal company network. Do staff workstations at CloudApp, Inc. have access to the databases and servers used to store client data? If so, something as simple as opening an infected email by a staff person at the cloud app organisation could impact the service and client data stored in it. Bottom line is that there should be no integration between those two networks.

4.   Security Audit: Is the cloud provider in question being audited on a semi-regular basis to a known standard such as SOC1/2/3 or the like? If so, it would definitely go a long way to confirming their security footing.

5.   Service Safeguards: Any competent cloud provider should be able to provide a document that spells out their basic security protocols. You are looking for such things as password complexity requirements, two-factor authentication, API token granting and revocation processes and account lockout and recovery protocols. In essence, you're asking the cloud provider to explain what hoops a person or application has to jump through in order to gain access to their service. Those hoops should be high.

6.   Data Backup: This is a no-brainer. You will want assurances that the cloud vendor takes data backups seriously. In 2017 already seen two notable cloud services (GitLab and Instapaper) severely impacted by lack of disaster recovery testing, being "in the cloud" just means an application or service is hosted on publicly accessible infrastructure. That in no way implies that the data is secure or backed up responsibly. That's up to the provider itself.

7.   Breach Response: Running and protecting a large cloud service is difficult. Just because a provider has been breached before doesn't mean that they are not trustworthy or competent. What you really want to know is what their response to a breach looks like. Do they have a policy in place for responsible, timely disclosure? Have they been breached in the past and it became known that they covered it up? Will they provide you documentation on their breach response strategy? The information provided in response to these questions will be very telling about the culture of the company being evaluated.

8.   Information Sharing: Is any of the data stored in the cloud application shared with "partners", vendors or other third parties? If so, they should be willing to provide documentation on who it's shared with and under what circumstances.

Not answering one of the above questions doesn't necessarily shut the door on using the service. As long as the refusal to answer makes sense. For instance, a provider might tell you they definitely hash passwords stored in their database, but for security reasons they don't want to divulge which hashing algorithm they use. 

Unfortunately, you will run into many startups that refuse to give straightforward answers to these questions. It's not enough that an app works well or solves a problem. If the people running the service don't have enough experience running and protecting such a service reliably at large scale, it's up to us to identify that ahead of time before we commit the data of our firm or our clients into their hands.