The Virtualization Field Day delegates joined the Virtualization Security Podcast as guest panelists on 2/23 and the topic of the day was cloud security. There were questions about compliance, security of the tenant, and security of the administrators, and legal issues. There were answers from Rodney Haywood (Rodos), another Virtualization Field Day Delegate and cloud architect as well as the podcast standard panelists. So what did the questions boil down to?
The podcast opened with the question to the Virtualization Field Day delegates about what they have experience with respect to virtualization and cloud security. But the conversation soon morphed into a conversation about cloud security and compliance. Primarily how to achieve cloud security and compliance. So how would you achieve compliance within the cloud and how would you secure your cloud?
Previously, we had a discussion on cloud security from the tenant perspective (Virtualization Security is NOT Cloud Security!). However, we never did show this from the cloud administrator perspective. Even so, the tenant perspective becomes quite important when you talk about compliance, as the Tenants must rely upon the Cloud Provider to guarantee compliance. As such, any compliance audit would soon point to the cloud provider documentation about compliance. Given this, it is important that you choose Cloud Providers that have the compliance documentation required of you available for perusal before you enter the cloud. Why? If your cloud instance carries a requirement to be PCI compliance, then your Cloud Provider also has the requirement of being PCI compliant and should be able to prove this to an auditors satisfaction. This proof is usually in the form of a QSA report of the cloud providers cloud compliance. Yet, just having the document is not enough. As the tenant you need to understand what aspect of the cloud was in scope when the report was created. Why is scope important?
Scope is important as your cloud instance may or may not be within the boundaries of the audit. The Scope could have been defined for a tier of functionality that is outside the bounds (or scope) of your cloud instance. Compliance documentation is a point in time document of compute resources bounded by the defined scope, which may or may not include all aspects of the tenants computing resources. Even if one switch is not within the scope of the compliance report, then, for PCI specifically, such an audit will fail. So in essence, the report of the cloud provider on which your audit relies must share the same scope as your cloud instance. This may not always be the case.
In addition to scope, there was a discussion about logging and how to review the audit and other logs of your cloud instance. Today, there is no definitive way to determine what aspect of a cloud provider’s logs belong to which tenant. While it is possible to know this at the higher levels, anything that touches hardware goes through so many proxy users that their is no definitive way to determine which tenant actually performed a task at the lower levels. Granted, you can correlate the events based on time and activity, but when two events happen a the same time to the same set of resources it becomes difficult to decide who did what. Correlated events are the best we can do at this time. Unless there is some way to pass a unique variable that represents a tenant from the higher levels to the lower levels. Even so, do we need to know what happens at the hypervisor level or do auditors and forensics only care about what happens within the cloud portals? Auditors would look at the cloud portal logs and claim success, while forensic scientists will want to look at the complete path of the data to determine who did what where when and how. Given that auditors have a lower burden of proof than a forensic scientist, this capability exists today, but extracting the logs just for one tenant is quite difficult and a very large burden on cloud providers. Which means the tools need to be improved as do the techniques used for Large Scale Cloud Forensics.
However, if all the logs you want are those from within your Cloud Instance, it is quite easy to create and setup a log server within your cloud instance and use that for all your non-cloud tenant administration events gathering. At least in this way a tenant can correlate its own data for its own applications and not rely on the cloud provider to manage the application log files for them. Even so, this solution only works for IaaS and PaaS style clouds. For SaaS clouds we are back to the difficulty of software not designed to track individual tenants.
This Podcast was a discussion about cloud compliance and security from the perspective of those trying to put together clouds, those using clouds, and those thinking of using clouds. The issue with compliance will always remain the scope of the audit which includes audit logs of some form. So when you design a cloud ensure tenants have the ability to stand up their own log servers and that as the cloud provider you have a means of separating each tenant within your own log servers. This will make audits for compliance and security go quite a bit easier.