LegalSEC® - Cybersecurity

 View Only

Multi-tenant Cloud? You bet.

By Jon Washburn posted 06-03-2015 12:28

  

I remember when you'd be crazy to consider putting your law firm's data in the cloud. Dedicated, managed hosting maybe, but multi-tenant?  No way.

Back in the 'crazy' days, everyone was worried (legitimately) that their data was likely living on the same equipment as someone else's data, giving some mystery person that wasn't on their staff administrative control over it.  Sure, there were firewalls and IDS/IPS and vendor contracts that defined the security measures in place to protect your data, but ultimately it was out of your control.   Performance was also an unknown quantity, since the technologies and process for managing even the dedicated resources weren't mature yet.  From a risk perspective it just wasn't worth it, for anything other than maybe your dev environment.

With advances in managing encryption and the virtualization of practically anything, the philosophy that building thicker virtual walls around equipment that you can put your arms around is a practical way to keep you safe is becoming out of date.  The need to focus on protecting the data and applications independent of the infrastructure has helped open the door to a more broad use of cloud platforms, especially multi-tenant cloud. 

With the shrinking of budgets since 2008, it's tough to argue that the relatively limited number of IT professionals at your firm - even if they're rock stars - are better at protecting your data than vendors with infrastructure on a vast scale, and the deep knowledge of a staff of hundreds focusing on maintaining the confidentiality, integrity and availability of your data.  However, since your in-house staff know your business better than your vendors, a hybrid model where your IT rock stars leverage these resources while still retaining ultimate control of your data can be developed into an ideal solution.  Here's how:

 1. Encryption, using your keys

A number of encryption solutions exist now where you can set your own private keys for encrypting your data at your cloud provider.   AWS has had this for some time, but vendors like Microsoft (Azure) and VMWare (vCloud, via their recent acquisition of HyTrust) have invested in similar interfaces now where you can set your own encryption key and isolate your data from everyone else's.  It's a win-win for you and your cloud vendor - you retain ultimate control of the data, and your vendor now has a reduced level of risk as it's far less likely that, in the event of a breach, your data would actually be exposed - and even less likely that you could argue that they exposed it, since they can't even see it.  Since that vendor is already encrypting their infrastructure everywhere they possibly can as a baseline for providing cloud services, this may end up being a more secure storage/compute solution than anything you've ever had in-house.

2. Pay for performance - you'll need it, and it's not as expensive as you think

Yes, it takes a lot more resources to manage encrypted data (if you've encrypted your SAN at rest, you've seen this.)  But by moving into the cloud, you're offloading all that hassle to your vendor - not to mention the costs of maintenance, power and cooling, scaling, management, etc.  And the biggest hassle of all?  The insurance.   You can run your storage and compute in the cloud in the high 90th percentile of efficiency, but running your SAN or ESX hosts at 98% capacity in your datacenter would be reckless at best.   When factoring  the overall cost don't forget to include these "resources on demand" the vendor keeps on hand for you in case you have to scale up.  Sure, they pass these costs on to you - but more efficiently at their economy of scale.  And you're no longer holding onto those extra boxes of equipment you keep on the shelf just in case…

3. When you're done building it, get a security audit before it goes live

We leveraged the multi-tenant cloud last year as a platform for our in-house ediscovery solution.  Before we turned it over to litigators and started uploading data however, we subcontracted independent security firms for both an outside-in pen test/assessment and an inside-out vulnerability assessment, to ensure that it met the same high standard of security that it would have met had we built it in our datacenter.  The value of this step cannot be understated - make it a requirement.

4. Make sure you have a plan in case it goes south

Just like in your datacenters now, it's important to have a BC/DR plan for anything you put into the cloud, regardless of the guarantee your cloud vendor gives you - Amazon S3 for example famously touts eleven nines of durability.  But what about government intervention, or a contractual dispute, or a major geographical event?  I once had someone tell me about a client of theirs that had contracted with a cloud vendor for a number of services, but had got into a contractual dispute and wanted to back out.  Their IT staff had calculated that it would take more than 3 months at 100% bandwidth utilization to copy out all the data they had there - if they froze it.  Since the data was live and changing who knows how they really copied it out, or if they just swallowed the contract issue.  Be sure you maintain some kind of offline backup of your data (sometimes a second cloud vendor is a good idea). 

Resources:

Amazon KMS: http://aws.amazon.com/kms/

Microsoft Azure Key Vault: http://azure.microsoft.com/en-us/services/key-vault/

VMware vCloud/HyTrust: http://blogs.vmware.com/vcloud/tag/hytrust

Amazon High-IO options: http://aws.amazon.com/ec2/instance-types/#highio-instances

Eleven nines?  Yup: https://aws.amazon.com/blogs/aws/new-amazon-s3-reduced-redundancy-storage-rrs/

0 comments
137 views

Permalink