This tip is a part of the SearchCloudSecurity.com learning guide, PCI and cloud computing: Cloud computing compliance
Everybody who’s been involved in the Payment Card Industry Data Security Standard (PCI DSS) compliance process realizes how hard getting and staying compliant can be. Organizations transitioning services to the cloud, particularly public cloud, can find themselves in the sticky situation of maintaining “joint custody” of technical controls between themselves and their service providers. This can happen either because organizations intentionally move aspects of the cardholder data environment (CDE) outside their perimeter or -- or even more challenging -- when companies discover after the fact that a cloud migration has already impacted the CDE.
Because PCI DSS requirements are so prescriptive, with respect to the technical controls required to achieve compliance -- particularly those for log management -- this scenario can be quite detrimental. Vendors may not have addressed the requirements fully and/or customer-implemented controls may not play well in a cloud context. David Schneier, author of the Regulatory Reality blog and managing director at compliance consultancy R.I.S.C Associates, described the situation this way: “We’ve struggled for two decades to find ways to secure homogenous (let alone heterogeneous) infrastructures and build in controls so data classifications and their associated risks can be managed if not mitigated. Without ever truly solving that mystery, we’re now moving what runs on those infrastructures into some amorphous conflagration of virtual devices that dynamically changes based on demand,” Schneier said.
Make you nervous? You’re not alone. The highly prescriptive nature of PCI DSS requirements for log management technical controls demands careful planning and tight integration between components to be successful. Organizations that need to stay compliant with PCI DSS and also make use of cloud services have a lot to consider; the only problem is, sometimes they don’t realize what’s required until it’s too late.
PCI DSS requirements for logging
It’s important to first understand specifically what’s required by the standard with respect to logging:
- Log content: The log must be able to reconstruct security-critical events (access to cardholder data, administrator actions, invalid authentication attempts, etc.) [Requirement 10.2].
- Log completeness: Log data must contain sufficient detail that each event can be traced to a source (user, time of occurrence, point of even origination, etc.) [Requirement 10.3].
- Time consistency: Log data is tied to an accurate, reliable and coordinated time [Requirement 10.4].
- Log protection: The log data is tamper-protected and tamper-evident [Requirement 10.5].
- Visibility and review: The log data is reviewed by the organization [Requirement 10.6].
- Log retention: The log data is stored for a sufficient period of time [Requirement 10.7].
Are vendors doing these things by default? Some are, but most aren’t.
Anton Chuvakin, principal at Security Warrior LLC, a consulting firm focused on logging and SEIM and author of a book on PCI compliance, summarized what he’s seen on the vendor side with respect to these requirements: "The state of affairs is pretty sad: Merchants are at the mercy of their cloud providers. I’ve seen cases from ‘no logs here -- if you don’t like it, tough luck’ to infrastructure logs (OS) being dumped into a public directory on a Web server for sharing with merchants.”
Obviously, failure to retain logs or the indiscriminate dumping of log files to a public Web server is a far cry from what the standard requires. But keep in mind that PCI DSS requires organizations go one step beyond just OS logging; in order to put events in context, organizations need to tie together what’s happening at the OS level with application-level events. For example, tracing the root cause of a security event -- such as in the worst case, fraud or theft -- may involve investigating an attack path as it moves from the application through to supporting middleware and then ultimately to the underlying host OS. It’s here that Chuvakin paints an even more dire picture: “Things get worse when you look at cloud/distributed application logs (yes, even payment apps); in many cases there is no logging, no matter what the PCI DSS and now the PA-DSS [Payment Application Data Security Standard] says.”
No logging? What do organizations seeking to address PCI DSS requirements do? We all recognize the importance of forethought; having the luxury to evaluate vendors ahead of time and make a go/no-go decision based on compliance requirements is workable -- as is scoping out systems from cloud transition efforts that store/process/transmit cardholder data. But what about the security pro who discovers mid-stream that a cloud transition is already in progress that impacts the CDE? Or the security pro who discovers that a system already transitioned contains cardholder data?
Should that situation occur, it’s important the organization take steps to regain control. There are a few strategies for doing this, but one useful strategy is two-pronged: an externally facing approach combined with an internally facing one.
Internally, take stock of two things: Understand fully the controls you already deployed in support of Requirement 10, as well as the systems that need to be covered but aren’t. Start by itemizing the systems and components deployed internally to satisfy PCI DSS requirements for logging (maybe it’s a SEIM, a manual procedure or a blend of both). By understanding fully how you meet -- or don’t meet -- the standard currently, you’ll have a good idea of what you need to do to best architect integration points between your own operating model and what your vendor might be able to provide. Next, construct a data flow model between systems in the CDE (you have to do this anyway in support of requirement 1.1.2). This model will help you understand the intersection points between CDE components you manage vs. what might be at your vendor.
Externally, determine what log information you can gather from your service provider and compare it to what’s required by the applicable PCI DSS controls (specifically, all of requirement 10 and its sub-requirements). Once you have an idea of what’s missing, approach your service provider to determine what they can do to help you get all the way there. It’s helpful to be specific; vendors vary in terms of their knowledge of the standard. While some have gone through PCI DSS certification audit and will instantly grasp what you’re looking for, others may still be in the planning stages and will need you to spoon feed them. For service providers that have offerings around PCI compliance, approaching them with a list of requirements may help you fit into a plan they already offer. If your vendor doesn’t offer a plan that helps you meet the standard? Well, at least you’ll know.
Keep in mind that as the customer, you hold the cards. Service providers worth their salt know that helping one customer get to where they want to be from a security and compliance perspective strengthens their service offering overall. This is the promise of cloud: By offering a relevant, usable service to you, they make themselves more competitive overall.
About the author:
Ed Moyle is a senior security strategist with Savvis as well as a founding partner of Security Curve.