8 steps to write a cloud security policy
Everything is moving to the cloud - a cliche we have heard so often that we have started to believe it to be true. To some extent, it is. The infosec professional has been caught on her heels about cloud security. Just when she got round to analysing the risks of virtualisation, the monster of cloud based services crept up behind her. The simplicity and attractive pricing offered by cloud service providers makes the shadow IT sign up for the service before you could say ‘cloud security’. There are myriad arguments flying around…
“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.
We do what we have always done: DEFINE A CLOUD SECURITY POLICY.
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.
Steps for writing a cloud security policy
Start by defining what the cloud means to you. Surprised? Don’t be. The definition of cloud is rather vague.
- Do you call your virtualised environment your ‘private cloud’?
- Do you consider WhatsApp as a cloud service?
- How about Office 365?
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:
Contents of a cloud security policy
- Definition of cloud as per your organisation - be specific wherever possible. “WhatsApp is also considered data on the cloud” can be a valid statement.
- Allowed and disallowed data on the cloud (This may also affect your data classification policy. Don’t forget to look it up and change it, if required.)
- Allowed and disallowed cloud services
- Risk Assessment of cloud services - what risks to look at and who will look at the different risks before deciding on the cloud service How to add a new cloud service - define the process in detail as the IT team might not be involved in the procurement process
- Links to - third party policy, incident management plan, BCP. If it is specific to cloud, you can include it as a part of the cloud policy itself.
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.