Security in the Cloud. Install #1

There are a number of different vendors providing cloud services. You can buy space and processing power from vendors like IBM, or Amazon or many other service providers. In the interest of full disclosure, I use cloud services all the time for email, backups and web services. These are services that are critical to my business.

There are a number of advantages to using the cloud. You don’t have to worry about maintaining a complex environment and keep a staff of highly paid systems administrators on staff. You are not losing sleep about your backups. Well, maybe you should be losing sleep over your backups, we will come back to that. You can also purchase disaster recovery services giving you the ability to get back online quickly with minimal disruption of business. The public cloud can give a businesses the edge they need to succeed.

In the public cloud one down side is you don’t know who your neighbors are. There have been cases where a group like Anonymous or another criminal element gets into the same cloud where you are and your cloud becomes dark and stormy. In Texas the FBI raided a data center taking some businesses off line. http://www.wired.com/threatlevel/2009/04/data-centers-ra/. And more recently the FBI raided a data center in Reston Virginia taking many businesses offline. http://www.pcmag.com/article2/0,2817,2387447,00.asp.

Do you see where I’m going with this? If you don’t have full control of your systems, there can be activity on the systems that can cause law enforcement to come in and take the cloud for evidence; effectively taking your business offline. Larger organizations may want to invest in a private cloud to keep control of who is playing in their back yard.

Another down side is you have not personally vetted your system administrators. An Oracle DBA can access everything in the database. They can make changes to the database. They can extract information from the database. And to make is more interesting, in a lot of cases they can go back and clean up the audit log. You really need to know who is watching the store. Oracle has tools to protect the database from a rogue database administrator. Ask a lot of questions about how the cloud provider protects your data from an insider.

What can you do to protect yourself from an insider threat.
1) Make sure Oracle Database Vault is installed and configured properly. Databases Vault allows the Database Administrator to do their job without accessing production data.
2) Audit trails should go to either syslog or Oracle Audit Vault. I would recommend using Audit Vault that can send you alerts when someone accesses sensitive data.
3) Audit what needs to be audited and review the audit trail.
4) Perform a risk assessment on your data and identify all sensitive data. Once you have identified all sensitive data, encrypt it and audit it.

Another down side, is your sensitive data encrypted? If it is encrypted, is the encryption done once the data gets to the cloud or is the encryption done at the workstation? If the data is encrypted on the cloud, I can read the data as it gets pushed over the internet to the cloud. I can also read the data that is being stored in memory prior to it getting encrypted. If you encrypting the data on the workstation prior to pushing it to the cloud, how are you dealing with key management? Is a copy of the private key located on the workstation?

For your consideration:

If the application / data is critical to your business? Then:
1) Have a backup plan. Putting your data in the cloud does not necessarily protect the data. Amazon users found this out the hard way. You may want to have backups of your applications and data or pay for DR services. When the cloud is shutdown because of a bad neighbor and you have a backup of your applications and data, you can get back online. If you have DR services you can get back online. If you are not in possession of your backups then you are at the mercy of the law enforcement entity that took your data.
2) Consider using a hybrid private / public cloud. Have your critical applications running on a private cloud using a public cloud for surge processing, non-critical applications and backups.
3) Consider using the public cloud as your backup. I do this in my businesses; I backup my critical files to local storage and also backup to to the cloud. Yes’ I believe in wearing a belt and suspenders. By running a backup set to the cloud, if I were to lose all my hardware, I can still recover by pulling my backup down off of the cloud.

What you must do at least once a year.
1) Run through a complete restore of your data. I have seen more then a few times where complex systems were backed up and no-one ever tried to do a restore. Then when a real life disaster happens, people are running around trying to restore services they have never restored before. Believe me; the end result is not pretty.
2) Run through a compete risk assessment. Lets face it; data changes, schemas change, copies are made. Ask yourself this simple question. Can you identify where all your sensitive information is? If not; you are at risk. Okay this does not always apply to the cloud; but it’s something you need to do.
3) Review need to know. Yes this does not apply to the cloud but I thought I would repeat one of my many matras.
4) Go through the SLA. Things change. Yea’ that’s ambiguous, but it’s true.
5) If you are backing up to the cloud, then encrypt your backups. You really want your data sitting out in the open? It’s not that difficult, there is no reason not to encrypt your backups. I really hate reading the Washington Post and learning yet another company or government entity lost a set of unencrypted backups with PII.

This entry was posted in Database Stuff, Security and tagged . Bookmark the permalink.

Leave a Reply