OMG the cloud! Everything must go to the cloud, and now! And sometimes finding a tool is about workflow. And the workflow should make sense and be awesome.
But there’s an argument that you shouldn’t even keep a lot of data unless it’s kept confidential and therefore properly secured. The liability of keeping information about other people and what they do is just too great to outweigh what you might otherwise use that data for.
Security matters. Workflow matters. And with the number of services out there that you can use for any given task, if any aren’t secure enough then there are probably ten others you could use that are. So why might you choose to use a given service:
Compliance. One of the best ways to verify that your data is secure with an online service is to check how various aspects of solutions are governed. Many cloud solutions list the controls they are governed by, often using industry standardized controls such as SOC 2 (https://en.wikipedia.org/wiki/Service_Organization_Controls#SOC_2_overview ), FedRAMP (https://www.fedramp.gov ), etc. Digging into which parts of these that an organization maintains compliance with will give you a pretty good idea of how seriously a potential cloud service you might use takes your privacy, and to whom they allow access to various types of your data stored in their cloud.
Authentication. Some services give you something more than a password to get logged into the service. For example, they can send you a text that contains a code when you log in. This is known as multi-factor authentication, which uses something you know (your password) and something you have (your phone) to get access to online services. Rather than forcing end-users to re-enter a password in multiple services, a number of vendors have a feature known as Single Sign-On. If you’re a small business (lets say less than 10 people), you can actually use most of these tools for free until you grow into a paid tier.
Encryption At Rest. How is your data stored at the cloud service? Any cloud service you choose should keep all of your data encrypted at all times. You can ask them questions like “Are your databases stored on an encrypted filesystem?” “What data from my company do you store in your database that is not encrypted?” “How exactly do you store files that I upload to your database?” and “Who specifically has the keys to decrypt that data, and how are those stored?” The thing to keep in mind with most forms of compliance is that the company can have some pretty insecure practices, provided they are transparent to customers about how insecure their practices are. So ask questions about areas you are concerned about.
Certificates. When we asked about those keys that can be used to decrypt data, there are also keys that protect your data when in transit. Make sure that all traffic is protected by secure protocols (if you don’t know you can ask each vendor) using strong encryption certificates, and that their private keys for those certificates are kept securely and not about to expire.
Privacy policy. Organizations with compliance should typically have a privacy policy. When you read the policy, it shouldn’t read How do you respond to a request for my data?
Geography. Cultural norms are different in various parts of the world. Most in the United States aren’t concerned about this. However, Europeans don’t typically want their data stored on servers outside of the EU (especially those in the US). This is due to systems administrators and customers alike being well educated about laws within the EU (and countries outside the EU), and the desire to force what is perceived in different regions as an acceptable level of privacy and security.
Service Level Agreement (SLA). If you can’t get to your data, what good is it? An SLA is an promise to meet certain service levels. A really good SLA includes a five nines uptime, or 99.999% of the time your stuff will be available. Keep in mind that 99% of the time means your data could be offline for days (3.65 of them in fact) and the vendor still meet their uptime requirements. Also look for what penalties are incurred if the vendor does not meet their SLA; if there are no penalties, then why actually have an SLA?
Backup. Backup is often the last aspect of security many think of. However, if the data is lost, then you might as well have kept it on paper instead. Backup requires a lot of space and takes time and often very expensive equipment. In fact, not having to back up our own servers is often one of the main reasons many want to move systems from our offices to the cloud. So make sure that you understand how long your cloud provider retains your data, how long it takes to restore that data in the event of a failure, and what process is required for that to happen. Also, see if you can have your own backup of their data.
A security scan. You can run your own scan, for free, and see if you get blocked from accessing the product, or if you uncover your own vulnerabilities that the vendor didn’t yet know about. A couple of caveats here, don’t scan really large vendors (like Dropbox or Google) and this is mostly pertinent if your vendor is giving you a dedicated server in their Cloud infrastructure.
In todays fast-paced business climate, new services seem to come online within large and small companies all the time. This might be a quick list making app or it might be a huge new tool that runs the entire organization. You don’t need to wear a tin foil hat, but you should take a few basic security precautions that keep you from being negligent. I recommend taking a list like this and turning it into an actual checklist – and auditing every app you have to verify that each one meets the requirements you come up with. That’s not wearing a tin foil hat, it’s just good business.