Non-Compliant ROCs

There really is such a thing, but you rarely ever see or hear of one.  But unlike the Loch Ness Monster or Big Foot, they can and do exist.

There is no reason that an organization cannot file a Report On Compliance (ROC) that is not compliant.  The topic came up again because we have a client that is addressing some issues related to complying with v1.2 of the PCI DSS.  Their remediation efforts will not be done for another five or six months, but their PCI ROC needs to be filed in one month and they do not think they can put in place compensating controls to address the remaining issues.  As a result, there will be a couple of items on their PCI ROC that are in the dreaded ‘Not In Place’ column.

The first thing everyone needs to be aware is that there is nothing in the PCI DSS that says an organization must file a compliant PCI ROC.  It is just that filing a compliant PCI ROC makes for much less work for the acquiring bank and the merchant or service provider involved.  But there are those out there that believe that a merchant or service provider must file a complaint ROC and that is just false.

So, what happens if an organization files a non-compliant PCI ROC?

If an organization needs to file a non-compliant PCI ROC, then they need to be prepared for the additional scrutiny required by their acquiring bank and/or the card brands.  When a merchant or service provider files a non-compliant PCI ROC, the organization that receives the PCI ROC must initiate an effort to track the requirements that are Not In Place.  They need to periodically follow up on the Not In Place requirements and report the status of any Not In Place requirements to the card brands.  The term ‘periodically’ is left to the acquiring bank to determine.  But how often they follow up can be as little as quarterly and as often as weekly.  The most common timeframe seems to be monthly meetings, but your experience will likely vary.  This process is required to continue until all Not In Place requirements are deemed in place.

So, how does the acquiring bank determine that your organization’s Not In Place items are now In Place?  Well that is where things are not so well defined.  What is defined is that the merchant or service provider informs the acquiring bank or card brands during the follow up meeting/call that the Not In Place requirements are now In Place.  What is not well defined is what happens after being informed that requirements are no In Place.  Since there are no procedures documented in the PCI DSS, by the PCI SSC in an FAQ or by the card brands, what happens next varies from acquiring bank to acquiring bank.

In most cases, the acquiring bank requests the merchant or service provider to get their QSA to update the ROC by reflect the changes in the Not In Place requirements.  My Firm’s problem with this approach is that in updating the PCI ROC, we are only looking at those requirements that have been updated from Not In Place to In Place.  We are not re-conducting all of the testing in the PCI ROC.  As a result, we only update those requirements that have changed and we place a disclaimer in the PCI ROC that states what items were updated and when those updates occurred.  We do not update the date of the report as the entire report was not updated.

Our preferred approach is to issue a letter with an attachment that contains the individual requirements that are now In Place.  The letter documents the scope of the re-review and the approach taken to test the updated requirements.  This approach allows for the updating of the PCI ROC, but only those items that changed and does not alter the original PCI ROC that was issued.  In this way, anyone reviewing the original report and the update has a clear understanding of what changed and why.

Advertisement

Why The PCI Standards Seem To Constantly Change

One of the biggest complaints about the PCI standards is that they always seem to be changing.

The reason why this seems to be the case is that the security measures of networks and applications are always changing.  Why?  It’s the attackers.  Every time we close up one way in, they find another.  When the threats change, so do the tactics to secure resources.  Hence, the PCI SSC issues clarifications to the PCI DSS to address new threats.

As an example, in v1.2 of the DSS, you now have to conduct vulnerability AND penetration testing on the inside of your network.  Vulnerability scans at least quarterly and penetration testing at least annually or whenever significant changes are implemented.  Why?  For a number reasons that are the result of changes in the threat landscape.

• First, because applications are becoming browser-based, you now not only have Web-based applications facing the big, bad Internet, but they are also on your internal network.  If they can be abused from the Internet, do you think they can also be abused on your internal network? You bet!
• Second, it’s not just the Internet you have to worry about these days. You need to worry about your own employees. Huh? You think those 20-somethings you have working for you are working all of the time? They get breaks and they tend to want to surf the net. The other bad news is that in a lot of cases, your younger employees may know as much or more about your technology than your IT department. FBI statistics state that 70% or more of all attacks have an internal component. Either an attacker used social engineering to get information for accessing your network or computers or an insider is an active participant.
• Finally, statistics point to security threats increasing on the inside of your network. Of course your IT department is on top of internal security, right? But, you haven’t funded a lot of security initiatives on the inside because you have all of those policies and standards that tell people not to do bad things to your network and the information you store. You have invested in all of those new browser-based applications. While those applications may not face the Internet, they still could be susceptible all sorts of vulnerabilities such as cross-site scripting or SQL injection attacks. And those vulnerabilities could be used to compromise your cardholder data as well as any other sensitive information.

All you have to do is look at the latest breaches such as Heartland and RBS.  They all had a strong internal component. In response, the PCI DSS is being adjusted to address the new internal threat.

So, if you want the PCI DSS and related standards to remain static, you need to stop the attackers from finding new methods of attack.