While at InfoSec World 2012’s summit on Cloud and Virtualization Security, the first talk was on Securing your data. The second was on penetration testing to ensure that data was secure. In essence it has always been about the data but there is a huge difference between what a tenant can do and what the cloud or virtual environment provider can do with respect to data protection and security. This gap is apparently becoming wider instead of smaller as we try to understand tenant vs cloud provider security scopes. There is a lack of transparency with respect to security, but at the same time there are movements to gain that transparency. But secret sauces, scopes, legislation, and lack of knowledge seem to be getting in the way. At RSA Conference 2012 CSA Summit, one of the speakers mentioned that
attacks move at the speed of the network.
I tweeted soon after this,
that defense, unfortunately, moves at the speed of legislation.
And what we heard at InfoSec World 2012 is that we need to defend our data, which has been many a cloud security specialists mantra for years now, yet we are still struggling over how to do this. Verizon has a 12 step program for us now, we can go to meetings and exclaim our issues with cloud security, and finally come to a conclusion. However, this 12 step program is all about the data, from data classification to the type of data you believe will be safe in the cloud based on your understanding of cloud security. There are two steps to assess cloud security. But if the cloud vendors are not transparent, how can you assess a cloud’s security posture and whether it meets your own?
On of the most common needs is to protect personally identifiable information (PII) and the PCI standard does a great job at this, however, what is assessed for PCI Compliance is bounded by the scope of the assessment. The scope is defined in most cases by the cloud provider, and not the assessor. Another common security document is a SAS 70, which implies you are following your own processes. However, SAS70 is also bounded by a scope decided upon by the cloud provider and not the assessor. Due to lack of legislation cloud providers do not need to share these documents with you before you purchase their product and in some cases would be considered a violation of law (granted I am not a lawyer but this was brought up at the summit). You would think cloud providers would want to share their security measures but in doing so, could open themselves to attack so they practice security by obscurity until they can bind you within their own contracts and service level agreements.
Even so, what tools do tenants have and what tools do cloud providers have? This is where knowledge comes into play as well as the need for transparency. A few examples that have vexed me lately:
- Data Protection: What Replication Receiver Cloud components exists? Is it one of the well known virtualization and cloud backup tools from Quantum, Veeam, Quest, or Zerto. Or is it a vendor lock-in proposition? Is this Replication Receiver Cloud tool bi-directional? Or do I need to stand up my own tool within my tenant instance, which Quantum and Veeam can provide?
- Secure Data Erasure: What mechanism does the cloud provider have to ensure that when my data is storage vMotion’d, deleted, etc. that it is securely deleted from static storage? Or do I need to maintain encryption keys for each VM that I would then destroy, effectively destroying the ability to access to the data? Is it hardware encryption (encrypting fabric switches, self encrypting drives) or is it a secure data storage layer (such as provided by AFORE)?
- Encryption of data in flight: All data is in flight within a fully virtualized cloud, what protections are available to ensure cloud administrators cannot see or manipulate my tenant’s data. Should I encrypt within the application container, does the cloud provider have hardware that will aid in this (such as Intel Processors with AES&I instruction sets that can speed up encryption?
- Firewalls: Does the cloud provider have a shared firewall, or is there a firewall per tenant. Who controls this firewall? Is there also an application firewall? Does the cloud provider use hardware of software firewalls or both? Do they take advantage of introspection to protect my data from myself?
- Role Based Access Controls: How can my roles and access controls be implemented within the cloud, do I need to setup my own, how can I ensure that the cloud provider administrators do not violate my tenants controls?
- Trust: How can I trust a cloud provider administrator as they are the ones that can literally see everything.
There are still many questions and the ones listed above have some answers associated with them based on existing technologies? If the tenant does not ‘trust’ the cloud provider completely? Is there an alternative set of tools they can use to impose security upon a cloud without knowing or caring about the clouds own security measures? Or is there a middle ground that can be reached where the security of the data is in the hands of the tenant, but the security of the cloud is in the hands of the cloud provider?
In either case, we need to understand the scope of all security and compliance measures within a cloud. Where are the boundaries, so that as tenants we can augment or improve the security and compliance based on our own policies and not have a policy imposed upon us from outside.
I was left with quite a lot more questions than answers. Some answers I already know, however some I will find out as the year goes on. I feel that the Tenant today has much more control over their environment than they used to and that they can impose security upon cloud providers but still should fully understand what security exists and the scope of those measures so as to not duplicate that security and therefore not waste expensive resources. In the US, at least, the security of the Data is still the responsibility of the Tenant until legislative changes come around. We need to have transparency, have knowledge of the tools and the scope of cloud based security measures before we buy, it should be part of the decision process.
All in all it was a great Summit, and the talks were lively and informative. I look forward to next years!
Share this Article:
Latest posts by Edward Haletky (see all)
- Scale and Engineering - March 23, 2017
- SDS and Docker: The Beginnings of a Beautiful Friendship - March 21, 2017
- Security Operations Center: Not Just Visibility - March 14, 2017