This technical tip is part of SearchSecurity.com's Compliance Security School lesson, "Virtualization and Compliance: Balancing Emerging Technology with Existing Demands." See other materials from this lesson or visit the school homepage for more information.
The use of virtualization technology has become increasingly popular to the point that it is no longer just the domain of QAs and IT architects. It has moved firmly into enterprise production environments, ideally under the watchful eyes of security managers.
Yet as is the case with any new technology, the implementation of virtualization in the enterprise comes with a number of security and compliance concerns. While the most notable issue with compliance in the virtualization space is that the majority of regulations don't even address the role of virtualization, most security questions can, in general, be addressed through sensible architecture and configuration-management processes. The larger issue is that virtualization means the security manager can no longer walk into the data center, count the physical boxes and know how many machines there are. There might be two or 10 (or more!) times as many machines that require management. And this is where the real security and compliance issues arrive. Without knowing where the data might be, how can you tell if it's been lost or manipulated?
While keeping track of all of the virtual machines may seem like an impossible task, in reality, it's purely a case of having sufficient operational discipline -- a straightforward proposition. I'll warn you, though: straightforward doesn't necessarily mean easy.
The process of ensuring operational discipline starts with cataloging physical assets; if you can't succeed there, you are doomed to complete failure when you get to your virtual machines. The real starting point, however, is for you and your organization to become obsessed with documentation and process.
It's necessary to be incredibly consistent about doing things the same way every single time: Document the processes that needs to be followed, which processes were followed and to which devices the processes were applied. Similarly, document -- in detail -- the configurations of every single physical and virtual device you have on hand, what the baseline configuration should be for any new devices created in the future, and the process for making all changes that should happen to those devices.
Sounds mind numbingly boring, doesn't it? I'll admit it is not the sexiest part of IT, but this will make virtualization compliance possible and will save you just as often (if not more so) as good backups.
Such documentation is particularly useful during a compliance audit, as it demonstrates that consistent, repeatable processes are in place and the organization possesses a strong understand of the state of its systems, which means there's high confidence in the state of their security.
The documentation doesn't have to be complex, but it has to be thorough, understandable and easily accessible. The list of data you collect should include -- but not be limited to -- a physical inventory of the system as well as the software configurations and operating system versions (including which patches are installed) as well as any relevant software policies. Finally, record who is responsible for each aspect of the system, including who the data owner is, what the classification of the data is on the server and any compliance or special requirements the system falls under.
When putting your documentation together, keep in mind that these guidelines should also be part of a disaster recovery program, so the information needs to be comprehensible by someone who may not be part of the IT organization. Fortunately, there are a variety of commercial tools (both IBM Corp.'s Tivoli and Hewlett Packard Co.'s OpenView, to name a couple, have modules for this) and open source tools for managing both documentation and asset databases, but even a basic spreadsheet can serve as a database if the systems aren't terribly complex.
Finally, please note that nothing I've said above is specific to virtual systems; it's important for an enterprise to understand its assets regardless of whether they are physical or virtual (though the need for accurate records is especially important for virtual systems, due to their ease of deployment). The basics I described above will help you in the long run. Not only will it make day-to-day operations easier, it will also make you look really good when the auditors come through and you can show them exactly where everything is.
About the author:
As CSO-in-Residence, David Mortman is responsible for Echelon One's research and analysis program. Formerly the Chief Information Security Officer for Siebel Systems, Inc., David and his team were responsible for Siebel's worldwide IT security infrastructure, both internal and external. He also worked closely with Siebel's product groups and the company's physical security team and led up Siebel's product security and privacy efforts. A CISSP, Mr. Mortman sits on a variety of advisory boards including Qualys and Applied Identity and Reflective, amongst others. He holds a BS in Chemistry from the University of Chicago.
