Misconceptions about PCI-DSS

A lot of people, including security experts, love to state that PCI is useless and does nothing to make an organization really secure. The supporting argument for this is that it is easy to meet the requirements without actually doing too much. I think this is a big misconception and I am going to try to dispel that notion.

For example, in section 6.6, the requirement is that applications should be scanned for the OWASP Top 10 issues.  Now, there is no direction from the PCI-DSS as to whether you should also login and scan the whole application or just scan the application without logging in. A lot of ASVs (Approved Scanning Vendors) will just scan the application without logging in. The problem with this method is that a large portion of the application is not tested at all and even though there might be vulnerabilities in those parts, the scan might end up being clean. A lot of security experts have commented that this makes PCI useless, because your applications can be vulnerable and still pass.

Here is the thing. The testing procedures in Section 6.5.c states the following:

Verify that processes are in place to ensure that web applications are not vulnerable to the following:

And then it goes on to list the OWASP  Top 10 issues. Nowhere does it say that you should NOT login. Since it does not say that you have to login, people assume it is enough to scan without a login. If you read 6.5.c again, you will see that the application cannot have any of the vulnerabilities. The last time I looked, the “logged in” portion of an application is also part of the application, which means that it will need to be scanned. I don’t understand where the misunderstanding is. This misconception probably was caused by the PCI council stating that they would accept reports from certain managed scanning tools such as QualysGuard. My understanding is that for a PCI scan, these tools do not login and since they were accepted by PCI council, everyone assumed that there was no need to login and test the application.

My contention has always been that there is the literal interpretation of the requirement and the intent of the requirement. One thing that people miss is that PCI requirements are intended to make your environment, processes, networks and applications adequately secure. If you are going to try and find the smallest set of things that will make you pass, then you are going about this the completely wrong way. Your goal should be to make your system secure and PCI-DSS is just one of the ways to help you do that. I cannot stress this point enough. PCI-DSS compliance is not Mt.Everest. It is just one of the camps on the way to Mt.Everest. You have to go above and beyond PCI-DSS to be secure and you have to do that over time.

Another thing that keeps coming up is that since PCI-DSS compliance is a snapshot in time, can you be sure that once compliance has been achieved, the system is secure? The answer is that you cannot. That is why, PCI-DSS requires ongoing monitoring. For example, all networks and applications need to be scanned every quarter and after any significant change. A penetration test has to be performed at least every year. Firewall rules have to be reviewed at least every 6 months and so on. All these have to be backed up by documentation. These requirements will ensure that your systems are reasonably secure.

One of the things that people keep bringing up is the fact that a lot of the companies that were involved in breaches recently (Hannaford, Heartland, etc) were supposed to be PCI compliant. If they were compliant, why were they be breached? Since they were breached when they were supposed to be compliant, surely the compliance requirements must be crap.

The problem with this argument is that you cannot make that leap and say that the requirements were crap. The QSA is the one that is supposed to define scope and ensure that all the requirements were met. If the QSA doesn’t do his/her job properly, you can end up with a situation where a company can be certified PCI-DSS compliance without actually be so. And in a decently sized organization, someone may end up doing something that they are not supposed to do or at least did not think of the consequences before they did it. PCI-DSS has safeguards against this: it requires a change control process with appropriate approvals etc. But how many times have you encountered a situation where someone changed a firewall rule or something else without going through the proper procedure? The organization also has its own priorities. In these times, where everyone is working to cut costs, cutting corners becomes easier.

For instance, during one of the recent application assessments that I was involved in, the client told us that we only needed to look at the payment pages of the application, even though the other parts of the application were on the same domain and also on the same physical server.  What the client did here was define the scope, which is actually the QSA’s job. In this case, we were doing a pre-assessment, so I let that slide. When we found some cross-site scripting (XSS) issues in the parts that were not the payment pages, we marked it a PCI-FAIL. The client asked us why we did that and I explained that even though the hosts were different, the cookies were tied to the domain and was available from the root directory. Also the cookies did not have the secure flag. So, any XSS in any part of the application could potentially affect the payment pages too. Then the next question was why we failed the application when another QSA had passed it just a couple of months before. My answer was that I could not say. I could only justify what we did with evidence and explain why we did it.

Now, if you are a client faced with fixing all these issues, you will think about the cost and time and effort and probably decide to go with the other QSA who passed your application. You end up with your short-term goal of meeting compliance fulfilled, but have an insecure application. When you get breached, you along with others will probably end up blaming PCI-DSS and how it doesn’t do anything for security. The PCI council has instituted a quality assurance program where all QSAs will have their work reviewed at least every 2 years. If done right, this will ensure that all these fly-by-night operators will be weeded out sooner or later.

With more awareness, hopefully more companies look at the intent of PCI-DSS rather than look at it is one more thing that needs to be done. By the way, the council is starting a training program for companies so that they can understand the requirements better.

Point to remember: The company needs to be successful (in protecting itself) all the time.  The hacker has to be successful only once.