This was a draft post from some time ago. Interesting how little has changed.
Security models, business alignment, capacity planning, and performance management are more important than ever before in virtual environments. Smaller environments may have a few virtually hosted servers running on a single powerful physical server, whereas larger environments support hundreds or thousands of virtually hosted servers and desktops running on a complex infrastructure of clustered servers connected to a massive Storage Area Network (SAN).
The scale may change the scope or approach to the audit, but the same business requirements and controls exist. Resource management and monitoring of each of the components separately and collectively enable the virtual environment to function. The hypervisor has control requirements similar to those found in a server, but it also has unique requirements to ensure that the hosted environment doesn't present additional control weaknesses to the guest operating systems. The guest operating systems have unique control requirements because of the necessity to keep appropriate segregation controls in place between servers processes, and to control its unique attack surface. Somewhat complicating this mix are different conceptual approaches to creating the virtual environment.
Great! I think. Where do I start? Now I have a cloud audit!
Start with scope. Identify exactly what you want to be part of the audit. Where does the data exist? What are the boundaries? Where's the management tools for that infrastructure? What systems access that scoped boundary?
Remember the basics. They don't change. They haven't changed for decades. Identity provisioning and deprovisioning, authentication mechanism and protocols, authorization grant/scope/enforcement, data protection, malware protection, malicious use detection/prevention, log management, change controls, backups, etc. Applies to nearly every single system directly or indirectly as an entity level control. Don't forget additional administrative controls, policies, documented procedures. Remember physical security and additional entity level controls. Finally, think about data and system lifecycle…
But this is a… [firewall/storage system/hypervisor/… etc.]. Excellent! Now let's look at the additional configurations and controls that are unique for each technology.
Documentation is everything. There's an art to documenting audit output and artifacts. What's the use case? Who will use the information? Internal use? External customer review? For example, how much information must be documented and to what level such that the purpose of an external review is satisfied while still protecting internal trade secrets? Maybe we don't trust the external party, or the security infrastructure of the external party to keep the data we provide to them confidential. Certainly understand that there are many times where we don't have a choice in this discussion – and I've been there many times – but if you have a choice in the matter then you should execute that choice. Not everyone agrees with me on this. This is my own opinion. I'm a fan of transparency, but not transparently providing potential attackers information that can be used to harm my infrastructure.
Help with the cloud! Okay, this is more complex because some of the technologies and architectures change the game. However, from a control objective perspective, that still hasn't changed. The objective is the same. Now, whether you own the technology or execution may have changed, and that's where you need to look into what visibility you have into your provider's enforcement of the controls. You have a certain risk profile/risk threshold and you have to make the call based on the situation whether you are comfortable with what contractual obligations they have to [1] enforce specific control objectives, [2] have them reviewed by an independent third-party, and [3] report the results to you.
Security models, business alignment, capacity planning, and performance management are more important than ever before in virtual environments. Smaller environments may have a few virtually hosted servers running on a single powerful physical server, whereas larger environments support hundreds or thousands of virtually hosted servers and desktops running on a complex infrastructure of clustered servers connected to a massive Storage Area Network (SAN).
The scale may change the scope or approach to the audit, but the same business requirements and controls exist. Resource management and monitoring of each of the components separately and collectively enable the virtual environment to function. The hypervisor has control requirements similar to those found in a server, but it also has unique requirements to ensure that the hosted environment doesn't present additional control weaknesses to the guest operating systems. The guest operating systems have unique control requirements because of the necessity to keep appropriate segregation controls in place between servers processes, and to control its unique attack surface. Somewhat complicating this mix are different conceptual approaches to creating the virtual environment.
Great! I think. Where do I start? Now I have a cloud audit!
Start with scope. Identify exactly what you want to be part of the audit. Where does the data exist? What are the boundaries? Where's the management tools for that infrastructure? What systems access that scoped boundary?
Remember the basics. They don't change. They haven't changed for decades. Identity provisioning and deprovisioning, authentication mechanism and protocols, authorization grant/scope/enforcement, data protection, malware protection, malicious use detection/prevention, log management, change controls, backups, etc. Applies to nearly every single system directly or indirectly as an entity level control. Don't forget additional administrative controls, policies, documented procedures. Remember physical security and additional entity level controls. Finally, think about data and system lifecycle…
But this is a… [firewall/storage system/hypervisor/… etc.]. Excellent! Now let's look at the additional configurations and controls that are unique for each technology.
Documentation is everything. There's an art to documenting audit output and artifacts. What's the use case? Who will use the information? Internal use? External customer review? For example, how much information must be documented and to what level such that the purpose of an external review is satisfied while still protecting internal trade secrets? Maybe we don't trust the external party, or the security infrastructure of the external party to keep the data we provide to them confidential. Certainly understand that there are many times where we don't have a choice in this discussion – and I've been there many times – but if you have a choice in the matter then you should execute that choice. Not everyone agrees with me on this. This is my own opinion. I'm a fan of transparency, but not transparently providing potential attackers information that can be used to harm my infrastructure.
Help with the cloud! Okay, this is more complex because some of the technologies and architectures change the game. However, from a control objective perspective, that still hasn't changed. The objective is the same. Now, whether you own the technology or execution may have changed, and that's where you need to look into what visibility you have into your provider's enforcement of the controls. You have a certain risk profile/risk threshold and you have to make the call based on the situation whether you are comfortable with what contractual obligations they have to [1] enforce specific control objectives, [2] have them reviewed by an independent third-party, and [3] report the results to you.
