It’s a challenging situation to be in: You need to keep the environment compliant, but implementing new controls isn’t always in the cards for IaaS through a service provider because you may not control the infrastructure directly. For private deployments, PCI compliance in the cloud can be difficult because keeping pace with controls and control updates is expensive, and the main purpose of cloud computing is cost-control.
Fortunately, there are a few strategies that organisations can implement -- free of charge -- that help to ensure the environment stays compliant over a long-term deployment. None of these suggestions are rocket science, but putting them in practice can help enforce PCI virtualisation compliance when it really gets challenging: after one or two years in the field.
PCI virtualisation compliance: Assign a “shelf life”
VM sprawl -- the uncontrolled proliferation of VMs -- is one of the biggest operational challenges when it comes to private or public IaaS. Rogue VMs are always bad for security generally, but add PCI DSS to the mix, and you almost always have a recipe for non-compliance.
Rogue VMs are always bad for security generally, but add PCI DSS to the mix, and you almost always have a recipe for non-compliance.
This is because even spun down, disused, or vestigial snapshots represent areas where DSS security controls should be applied. And because the PCI Standards Council makes it clear in its virtualisation guidance that compliance of the hypervisor and VM are linked (i.e. if the guest is in the CDE so is the host and vice-versa), anywhere you move that image to, whether using vMotion or plain old copy/paste, becomes a part of your CDE. Imagine what happens over time as these new VMs -- created on the fly and unintentionally becoming part of the scope of compliance -- start cropping up in a QSA’s audit sample.
One effective strategy to combat this is to define an “upper bound” timeframe within which these VMs can persist. Keep a formalised inventory of mandatory VMs (maybe it’s your official virtual inventory and there’s a controlled process requiring approval to get on it); VMs that are not on the inventory beyond a certain age (for example, three months) get automatically deleted. That way, even if a problematic VM is created, there’s a hard and fast end date for how long it can stay around. Obviously a process preventing it from being created in the first place would be ideal, but implementing a formal inventory and time limits means that even if a mistake happens, the pain is limited.
PCI virtualisation compliance: Monitor dormant VMs
If a VM image is kept dormant (i.e. spun down) for long periods of time, critical security functions don’t always happen; for example, patching may not occur and malware signatures may not get updated. When that dormant image finally does get activated again, it may take some time before automated processes have a chance to bring that image to a secure state, and the longer the image has been on the shelf, the longer this process may take. This poses a problem when images contain cardholder data, have access to cardholder data, or live on the same hypervisor as other images that contain cardholder data because of PSS DSS requirements on patching (Requirement 6.1) and malware signatures (Requirement 5.2).
To combat this, a manual or automated process that monitors the “freshness date” of dormant images, and spins them up to make sure they get updates, can ensure secure configuration over time. So, should your QSA evaluate one of those images, required security parameters are current.
PCI virtualisation compliance: Follow a naming convention
While inventories of virtual images are critical, they’re notoriously unreliable in practice. It’s not unusual, for example, to have multiple, conflicting inventories specifying different functions and owners for the same VM. Recall that a PCI Report on Compliance (RoC) requires a list of all devices with access to cardholder data so conflicting inventories won’t pass muster.
Ideally, not letting the inventory get out of hand in the first place is best, but since that proves challenging in practice, using a naming convention that makes any image instantly recognisable is helpful. For example, explicitly labeling which images contain or have access to cardholder data (as part of the naming convention) helps prevent moving a VM to a hypervisor that doesn’t have PCI DSS-required security controls.
Each of the steps described above is designed to build in a “safety net” for the kind of bad behavior that challenges virtual environments operationally. They’re simple, but you’d be surprised how often organisations overlook them and end up in lengthy audit and remediation cycles.
About the author:
Ed Moyle is a senior security strategist with Savvis as well as a founding partner of Security Curve.
This was first published in March 2012