How Security Pros Can Leverage PCI Compliance Initiatives

PCI tends to induce fear, frustration, or, at best, indifference among security practitioners. Because of the technical specificity of the controls the standard requires, it’s almost certain to involve (and distract) technical resources from all over IT. But because it focuses only on areas where credit card data is processed, it won’t necessarily directly improve the overall security of the environment.

This makes it tempting to view PCI compliance as an activity without direct benefit for the practitioner with a risk-based approach, but that doesn’t have to be the case. By partnering with peers on the compliance side, doing appropriate scoping and preparation, and paying attention to emerging standards, the security practitioner can leverage PCI compliance activities to gain benefits for the security posture of the company as a whole.

PCI’s value to the security practitioner comes about through enforcing a technical "minimum bar." The standard defines a set of controls that can be valuable in reducing risk, but difficult to justify -- and get funded -- under other circumstances.

For example, security practitioners know that file integrity monitoring has value from a security standpoint, but getting funding to purchase a tool to do it can be challenging. It’s "in the weeds" technically, and quantifying return on investment is difficult. However, PCI explicitly requires file integrity monitoring, so the discussion about whether to fund it is partially removed from the table -- at least for the cardholder data environment (CDE).

Implementing controls in one area (notably, the CDE) decreases barriers to deploying those same controls in other areas. Because you already own the tools, it reduces expense, and since you’ve deployed them in the past, it decreases planning and deployment overhead for subsequent efforts.

Since the requirements of the PCI standard are stringent, the level of protection prescribed isn’t appropriate in every context. Conversely, not every security control in use in the enterprise can pass muster in the CDE.

Consider, for example, a situation in which a manager at a retail location runs Skype on a system in the CDE. Since Skype can arguably be considered to support "remote access” (because it can support desktop sharing), an auditor might conclude that two-factor authentication is mandated per requirement 8.3 (not an uncommon conclusion in the audit community).

This breeds circumstances in which successfully passing an audit becomes difficult or even impossible. When this situation arises, the question shouldn’t be, "How do we make Skype compliant?" but, "How can we get Skype out of the CDE?"

Compliance and technical risk management don’t have to be at odds, but it’s important to realize that differing goals can create complications as you determine scope and prepare to proceed.

For example, consider the intersection of PCI and patching. Under earlier versions of the standard (prior to 2.0), requirement 6.1 was worded in such a way that it mandated a maximum of "one month" between patch issuance and application in the CDE.

Those familiar with production support will recognize the complication here: Is it always a positive risk trade-off to deploy every patch (or even just critical patches) in every circumstance according to a narrowly defined timeline? No, right? So a requirement like this creates an area of potential disconnect between security and compliance. A 30-day window, while high priority for the compliance side, creates complexity for the security and risk side because it can introduce availability issues.

It’s important for both the security and compliance side of the house to close gaps like this amicably. That takes planning, coordination, and communication.

To find out more about the process of combining PCI compliance and enterprise security efforts, as well as the potential pitfalls and benefits associated with the compliance effort, download the free report.

Have a comment on this story? Please click "Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.