“Everyone’s using Evernote! What’s infosec got to do with it?”
“…but it is free for up to 5 users and we are not more than 5 users!”
“This is way cheaper than what my accounts package costs…and I can access it from home.”
These are words that strike terror in the heart of infosec professionals.
After the denial, however, has come the acceptance. We ALREADY have users of cloud services and they do not look like going away anytime soon. The more pertinent question is what do we do? The answer is quite banal.
What could be more boring that writing a policy for cloud security? Writing a good one. Here are the steps that you need to take to write a good and effective cloud security policy.
Start by defining what the cloud means to you. Surprised? Don’t be. The definition of cloud is rather vague.
1. Analyse all the data that is on the cloud already. This includes not just your poster boys like salesforce.com, but also under the radar plumbing - like dropbox. Again, you might be surprised with the results.
3. Evaluate the elephants in the room. If you are completely dependent on certain cloud services and there is nothing that you can do about it, for example, say you are depending on Google for mail, document what the risks are. It is always better to knowingly accept the risk than to act like an ostrich with your head in the sand.
4. Now, once you know the risks, define your absolute no-nos. What is it that absolutely cannot be on the cloud. How do you do this? Get your management on board with this. Yes, those people who use iCloud for backup unknowingly all the time saying “We don’t use the cloud.” Set up a brainstorming about what you want to allow and what you would rather not risk. Be clear with what you present. Remember to include the costs of each option. “Gmail charges us $5 per user per month, which amounts to $50k of op-ex, while hosting an exchange server will cost $100k in server and license cost + we will need people to manage it.” Your end result should be a list of data that can go on the cloud and another list of data that cannot go on the cloud, no matter what.
5. After knowing what data can be on the cloud and what cannot, you will need to identify what services are allowed and what services are not. This is the boring part of your work. Read the privacy policies of the services being used. Read the fine print. You might get stuck in legalese, or you might have to give up your first born! Discuss with your legal teams in case you are stuck. Meet the service providers if they are accessible and willing. Understand their willingness to change certain sections that are uncomfortable for you. Make a list of service providers that are allowed for the cloud service. This might be a continuous task, but one that needs to be done.
6. Update your third party policies to ensure that cloud based service risks are addressed. How will you audit a cloud service provider? For example, if you have set up a server on Amazon AWS, how will you ensure security? Will you audit the Amazon data centres? Will they allow you to do it? Will it be of any use?
Update your incident management plan. It should now include the process of handling incidents related to your cloud services. Who will call whom in case a cloud service is not working?
7. Update your BCP for cloud services. Do you have local data backup? What alternatives do you have in case the cloud services are not available?
8.After following this process, you will be sufficiently equipped to define a cloud security policy for your organisation. Your cloud security policy should contain, at a minimum, the following:
The cloud security policy cannot stand by itself. A good cloud security policy is not a stand alone policy. It links itself to various other policies of the organisation.
This will give you a starting guideline to creating a policy for the use of cloud services. It is by no means complete. You can refer to various other documents as well. The cloud security alliance has detailed checklists for use.