PCI Compliance Is Good; Data Security Is Better

A 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.

If you are like many CIOs, a lot of your security budget is driven by compliance requirements, including PCI DSS. Although many merchants feel they are secure once they achieve PCI compliance, that is not necessarily true.

For example, a janitor can walk out the door with files of sensitive data, your shredding vendor may determine it gets a better price for the paper when it's not shredded or a staff member may decide he really does need to click on that infected e-mail attachment telling him he won a lottery.

To be secure, you need to go further. But what does it mean to go beyond PCI compliance? What are some ideas and suggestions you might consider? The idea is that you should not only be compliant; you should be more secure, too.

Just validating its PCI compliance does not mean a retailer is actually compliant.

To put it simply, validation (which is a one-time event) does not make you compliant (which is a continuous state). We now need to take it a step further, and observe that compliance does not equal security. Security means going beyond compliance. What follows are one QSA's examples for going beyond PCI to improve your security.

Let's start with vulnerability scanning. PCI requires you to pass both internal and external vulnerability scans quarterly. Increasing to monthly scanning detects issues sooner at relatively little additional cost. If you run a Web-based payment app, think about even more frequent scanning--maybe daily.

The same advice goes for penetration testing. PCI requires a penetration test annually and after "any significant infrastructure or application upgrade or modification." I'd give serious consideration to a full-scale social engineering penetration test sometime. You may be surprised at what the testers discover about your security. And the results can point to some needed improvements. (Full disclosure: My company is an ASV and we conduct penetration tests.)

Restricting today's unlimited employee Internet access is another good place to start. Getting that genie back into its bottle is not going to be easy, but maybe you can at least partially contain the situation. PCI Requirement 8 tells you to restrict data access based on a business need to know.

Taking a parallel approach, can you restrict Web access by job function or need? For example, some of your marketing staff needs to access to social networking sites, but does everybody in the company? Does every employee need to check auction sites, update their Facebook pages or plan their vacation while at work? A policy of restricting Web access by job function, together with some Web site whitelisting, can go a long way toward reducing the risk of your users downloading malware that compromises your network.If restricting access sounds too difficult, can you implement consequences for what I call bad (or at least thoughtless) behavior? Some companies have a policy that states if an employee damages a company vehicle, they lose the right to use a company car for some period of time.

Following that same line of thinking, why can't an employee who repeatedly needs to have his laptop re-imaged to remove malware or inappropriate content face a similar restriction?

I know one organization that produces a list of repeat offenders and sends it to both each division head and the COO to raise the visibility of the problem. From what I have seen, you do not want to be an employee--or the division head with such an employee--on that list.

We have to accept the fact that the deck is stacked against retailers achieving perfect security. As the CIO you have to be right all the time, while the bad guys only have to be right once to compromise your systems. Accepting that difficult truth means security needs to go beyond compliance and protect the data and applications as they move around inside your network perimeter. PCI addresses data at rest (Requirement 3) and data you transmit (Requirement 4).

Going beyond these compliance requirements and encrypting or tokenizing your cardholder data or any personally identifiable information (PII) as it moves through your network can increase security. These approaches cost money, and they are not necessarily easy to implement.

It will be interesting to see if internal network breaches become a more common attack vector and how the PCI Council will respond. Someday, protecting data in transit over your internal network may make it into the PCI standard. Until then, such protection is a good extra step that can increase your security.

Nothing in PCI protects retailers against a determined malicious insider or a serious business process failure. If your organization is victimized, a Data Loss Prevention (DLP) or other tool with similar functionality (e.g., a firewall that inspects outgoing packet contents) can stop the worst from happening by blocking your valuable data from leaving.

PCI Requirement 1.2.1 tells you to restrict inbound and outbound traffic to just what is necessary, but DLP goes further. DLP can be difficult to implement. Once it is in place, it can monitor and protect data in storage and as it moves through your network.

Again, something like DLP might someday make it into the PCI requirements. And just because it isn't there now does not mean it isn't a good idea to explore, especially if your focus is security and not just compliance.

PCI compliance requires, among other things, that you know where your cardholder data is stored, understand how that data is used and manage the partners with whom you share it. Data security requires you to go further and take responsibility for your users, protect the data in transit and at rest, and prevent the data from leaving your network without your knowing about it.

To the maxim "validation does not equal compliance," we now add "and compliance does not equal security." Then, as a professor of mine used to say, we get to the exercises for advanced pupils: "and there is no such thing as 100 percent security."

What do you think? Have you tried to limit employee Web access? Do you protect data in transit over your internal network? Have you looked at DLP or similar approaches to stop data from leaving your environment? I'd like to hear about your experiences. Either leave a comment or E-mail me at [email protected].