5 Winning PCI 3.0 Ways

As most security and compliance pros already know, PCI 3.0 is now officially out.

The specific changes it includes have already been covered in quite a bit of detail elsewhere in the industry press, so I won’t cover them all again here. However, one area that is often less discussed is how to use these changes to your advantage — specifically, strategies to carve out resources for things that benefit PCI compliance but also have benefits more generally.

Below are five changes to the standard that savvy practitioners can use to help accomplish things on their wish lists that might not be likely to come to pass otherwise by virtue of limited budget and strapped personnel resources.

1. Threat Intelligence

Threat intelligence is a complicated concept, but here I mean it as the creation (through building or buying) of an intelligence-analysis capability for the purpose of keeping tabs on the tools, methods and activities of attackers.

Why do this? To help you know which threats are real — i.e., which are likely to actually result in something you need to care about — and which are unlikely to be exploited. Note that while this isn’t a universal practice — a subset of practitioners believe the concept is just a bunch of hype — the truth is that if you think it’s valuable and want to do this, PCI 3.0 can help make it happen.

Among PCI 3.0’s requirements is that “for systems considered to be not commonly affected by malicious software, perform periodic evaluations to identify and evaluate evolving malware threats.” This is part of the AV requirement; essentially what they’re saying is you need to make sure you have a way to know when new threats affect a platform where you’re not using AV, such as mobile platforms or Linux.

One way (but not the only way) you might accomplish this is through the employment of a threat intelligence capability, or by knowing when and how something is actively being exploited. The data you gather isn’t just useful for the cardholder data environment, however — it could very well be useful throughout your whole security program scope.

2. Inventorying and Inventorying Tools

PCI 3.0 also requires you to “maintain an inventory of system components that are in scope for PCI DSS.” What is a system component? Page 10 of the standard spells it out, but the short version is that it includes hosts (both virtual and physical), network equipment and software/applications, among other things.

As we all know, inventorying is always a challenge in a large and complicated environment. For example, many organizations struggle with keeping just a physical or virtual inventory current, let alone one that includes both — and application software to boot. To accomplish this, many organizations will need to implement automated inventorying solutions, for which it can be challenging to get budget and staff time without some overarching driver.

However, if you’re going to deploy a tool like this anyway, why not pick one whose use can be extended to cover other areas besides just what’s included in the scope of PCI compliance?

3. Vendor and Service Provider Analysis

Prior versions of PCI required that you track your vendors’ PCI compliance status. Now, however, there’s an additional requirement to “maintain information about which PCI DSS requirements are managed by each service provider and which are managed by the entity.”

In the course of satisfying this requirement, you may very well need to do some digging and information gathering, such as to find out the specifics of how your business partners are using the vendors in question, which is a necessary factor in determining responsibility for individual requirements.

One way to approach this might be to define a standard process that can be followed across the organization. For example, maybe there’s a formalized set of usage-related questions that purchasing requires from business owners when they employ external technology service providers.

If you’re going to set up such a process, consider whether it could be leveraged outside just the scope of PCI, because this data can also help in other ways, such as by helping to reduce “shadow IT” and more rapid discovery (by you) of cloud (specifically, SaaS) technologies already in use.

4. Automated Data Discovery

While prior versions of PCI have required current network diagrams, the 3.0 revision requires that you maintain a “current diagram that shows all cardholder data flows across systems and networks.”

Imagine for a moment what you’d need to know to accomplish this manually. You’d need to understand the application logic for all the applications in scope (i.e., what sends data to what), for example, as well as all possible application and network failover paths; you’d also need to understand possible “bursting” scenarios or other on-demand data pathway adjustments, etc. The point is, for a large or complicated network, manually tracing these paths throughout interconnected physical and virtual systems is a tall order.

One way to make this process a bit easier is with automated data discovery tools, such as those that can analyze traffic and stored data to locate sensitive information like PANs (i.e., credit card numbers). Depending on the tool you select, you might be able to extend it to accomplish other types of data discovery as well outside the CDE.

For example, you might use a similar methodology to look for social security numbers or ePHI. Moreover, once you have the data flows mapped out, you can use them for other things, such as to compare a network diagram showing data flows to a data flow diagram such as you might use in a formalized threat modeling exercise. Look familiar?

5. Configuration Management

PCI 3.0 includes a requirement to “ensure that antivirus mechanisms are actively running and cannot be disabled or altered by users.” Of course, AV has been a requirement since time immemorial in PCI, but this new requirement implies an ability to lock down the configuration. This includes systems employed by users such as workstations and other endpoints.

Locking this down — such as via restrictions in the AV product itself, disabling administrative access for users or through whitelisting/blacklisting — can have a beneficial effect when extended beyond just the CDE and applied to user populations more generally.

These are not the only changes in PCI 3.0, of course, and they’re also not the only changes you can make to help support your security program. However, since you have to address these non-optional items anyway, leveraging them to the hilt to get a broader benefit can be one way to maximize efficiency.