Archive Page 2


Disaster Recovery And PCI

Boy!  When topics come up, they come up often and consistently.  Over the past couple of weeks the topic has been disaster recovery (DR) and its effect on PCI compliance.

The first thing that always seems to come up is in regards to where does the PCI DSS specify requirements for disaster recovery?  Most people are confused because they cannot find those requirements.  The reason people cannot find PCI requirements regarding disaster recovery is because there are none.  The PCI DSS does not concern itself with disaster recovery.  PCI does not concern itself with whether or not processes can be recovered, the PCI DSS only cares if sensitive authentication data (SAD) and cardholder data (CHD) are secured.

Which leads to the next question, “I have a hot/warm/cold DR site. Is it in-scope?”  Well, as in the immortal words of the Council, “that all depends.”

In all but the most very rare of cases, if your production data center is in-scope, your hot site is also in-scope for PCI compliance.  The reason is that there is already CHD stored in the hot site because it needs to take over immediately if the primary data center becomes inoperative.

Cold sites are never in-scope for PCI compliance.  By their very definition, a cold site has no equipment other than electrical power, telecommunications terminations, empty racks, HVAC and physical security.  As a result, there is no CHD or any other data storage/processing/transmission at a cold site.

Warm sites are always problematic.  In almost all of these cases, it falls to the QSA/ISA to determine if SAD is processed or transmitted or CHD is stored, processed or transmitted using the warm site.  And do not expect those data flow diagrams to necessarily point out that the warm site is in-scope.  In most cases, the people working on PCI compliance have forgotten how DR processes work or even exist.

This can be trickier than you might think.  The most common situation I encounter is where the people that set up the DR site/processes are no longer with the organization and the people left have no idea of what is stored/processed/transmitted at the warm site.  DR is one of those areas where IT people on their way out of the organization seem to end up.  And as soon as the DR plan is complete, out the door they go.

The next most common situation is data is being replicated SAN-to-SAN between data centers and there may even be servers there, but no production applications/processes are running.  That SAN-to-SAN data replication was likely overlooked because it is done by the SANs and therefore the application and network people likely will not know/remember it is even happening.  And it is always possible that SAD/CHD may or may not be at the warm site until it is used for production.  I have encountered that situation in a few rare cases.

I have also encountered situations were organizations load balanced their networks using their warm site and had SAD and CHD flowing through the warm site to transaction gateways/processors unbeknownst to others in the organization.

As a result, it can take a significant amount of effort to determine if a warm site is in-scope for PCI compliance.

But there is an even more disconcerting issue regarding DR that people do not think about until it is too late.  While the PCI DSS does not concern itself with DR, if production is moved to the DR site for any reason, that DR site immediately comes into PCI scope.  There is no grace period.  When you put production in the DR site, it immediately is in-scope.  So if there are PCI compliance issues at the DR site, they must be remediated as soon as possible because the organization is no longer PCI compliant until they are fixed.

And that is the rub.  DR sites typically are not assessed for PCI compliance because they are out of scope because there is no SAD/CHD there.  And people are vehement in their arguing about scope because assessing a DR site obviously adds to costs and time.  Yet if the DR site is ever invoked, the DR site is immediately in-scope.  This is why I tell my clients to assess their DR site(s) periodically for PCI compliance so they have as few surprises as possible should the DR site get used.  Particularly if there are changes to their DR site or they move to a new DR site.

So there you have it.  DR and PCI in a nutshell.


iFrame Hack Reported

This week brought news of an inline frame (iFrame) payment solution that was hacked in the UK.  For all of you merchants that use an iFrame solution because you were told it reduced your PCI scope, you may want to rethink your security strategy.  For all of you hosting companies that offer these iFrame solutions because of the scope reduction value, you too may want to rethink your security strategy as well.

For those of us that are not Web developers, an iFrame is:

“An HTML document embedded inside another HTML document on a website. The iFrame HTML element is often used to insert content from another source, such as an payment page or advertisement, into a merchant’s Web page.”

For merchants using an iFrame for handling payments, the PCI DSS rules that the iFrame makes the merchant’s Web site out of scope because the iFrame is managed by the payment provider, not the merchant.  Thus merchants using an iFrame or a redirect are allowed to fill out an SAQ A.  However, because of increased risks to merchant Web sites using iFrames and redirects, the Council has updated SAQ A in response to those risks.

But there has always been a risk that iFrames and redirects could be manipulated.  The attack used in the article was fairly sophisticated in that it required a lot of knowledge about how that particular iFrame worked and then used a man in the middle (MITM) approach to intercept the invocation of the payment processor’s iFrame and insert their own iFrame.  Not a easy, but definitely effective.

The easier approach is an attacker changes the script/executable that invokes the iFrame/redirect to invoke a malicious iFrame/redirect.  A merchant would be alerted to such a change if critical file monitoring were required, but SAQ A does not require critical file monitoring.

This is why a lot of QSAs have told their clients that only fools believe that the requirements in SAQ A will keep their Web sites secure.  At a minimum, merchants using iFrame/redirect solutions should have critical file monitoring and logging implemented as well as conducting quarterly vulnerability scanning so that they can secure their Web sites as well as alert on any changes or any suspicious activity on their Web sites.


Is The PCI DSS Even Relevant Any More?

First the National Retail Federation (NRF), then bloggers.  Organizations and people are piling on the PCI SSC and standards all because of the United States Federal Trade Commission’s (FTC) fact finding project.  Seems like PCI is now a bad three letter word.  But with the changes that have been implemented or will soon be implemented, I am starting to wonder about the relevance of the PCI DSS.  So I thought I would explore these topics and explain what has lead me to that conclusion.

Ever since the FTC announced there little fact finding mission, I have consistently said that the FTC is late to the party.

Why do I think the FTC is late?

The FTC’s fact finding efforts are I am sure in response to the Target, Michael’s, Home Depot, etc. data breaches which resulted in tens of millions of payment card accounts being exposed and potentially used for fraudulent purposes.  Remember, they are a governmental body, so taking action can take a bit of time, in this case at least three years and longer than most people would have desired.  But they eventually got around to it.  While this fact finding effort is a valid way to get up to speed on a problem, the trouble is that the threat landscape has changed since those notorious breaches and the FTC got its act together.

What in the threat landscape has changed?

The vast majority of mid-sized and large retailers have or are in the process of implementing point-to-point encryption (P2PE) or end-to-end encryption (E2EE) and tokenization solutions to minimize their PCI scope to only the point of interaction (POI) otherwise known as the card terminal.  As a result, the threat of large scale breaches at these merchants is or soon will be in the next 12 to 18 months (based on my knowledge of a large number of such efforts) near zero.  The reason being is that these merchants’ point of sale (POS) and other systems will no longer have access to cardholder data (CHD) or sensitive authentication data (SAD).

How can the threat be near zero?

The threat with P2PE/E2EE and tokenization limits scope to only the POI and is very, very low because of how the POI must be implemented to work with P2PE/E2EE and/or tokenization.  I am not going to discuss in detail the security features of these solutions so as not to tip the hand of those organizations implementing them.  Let me just say that there is a lot of information required that must be loaded into the POI in order to swap out terminals.  Even then, there are additional controls involving the registration of the device by the merchant and/or service provider that preclude terminal swaps without generating some form of alerts.

The one threat that still does remain is the use of an overlay for skimming cards.  But that risk varies from POI vendor to POI vendor and even by POI model within a vendor.  And it is not like vendors have not taken notice of the overlay problem.  Vendors have gotten a clue and are changing the design of their POI to make them as difficult as possible to use an overlay.  I have a client that went with a POI that has various angles, long swipe tracks, LED lights and other features that would make an overlay very expensive to engineer but also very difficult to appear seamless to customers and clerks.  Over time I expect to see all POI manufacturers adopt strategies to minimize the ability to use overlays.

The result of all of this is that merchants are no longer the risk (if they even present a risk) they were two or more years ago.

So who or what does that leave at risk?

ECommerce Web sites are still a huge problem.  EMV as it exists today does nothing to stem the problem of online fraud.  Even if a merchant has outsourced eCommerce, they still have to manage that environment as well as deal with the chargebacks and disputes that come from eCommerce card transactions.  I have heard rumors of solutions that are coming to address eCommerce, but I have yet to see any formal announcements of those solutions.  So for the foreseeable future, eCommerce will still be in-scope for some amount of PCI assessment.  So merchants with an eCommerce presence will likely still have to address some form of PCI assessment for that environment.

Any merchant that has not gotten on the P2PE/E2EE and tokenization bandwagon.  All merchants should be getting POI that encrypt and/or tokenize at the swipe or dip of a customer’s card.  Adopting such solutions will leave the merchant with only having to comply with requirements in 9.9 and 12.  I know for some merchants that will mean an investment, but the payoff is extremely reduced PCI scope and effectively taking almost all of the risk out of card payments.

The organizations that end up with a huge target on their backs are any service providers, transaction processors, issuers or financial institutions that have CHD and/or SAD stored in their files and/or databases.  An unfortunate fact of life is that transaction processors, issuers and financial institutions are always going to have to have some amount of CHD/SAD in their files and databases because of the nature of their business.  It is these organizations where the full on (i.e., Report On Compliance or ROC) PCI DSS assessment will never go away.

For merchants that have moved to P2PE/E2EE/tokens, I could see a move to an annual self-verification that those solutions are still implemented and functioning as designed.  I could additionally see that, every three years or so, the card brands requiring an independent assessment by a QSA/ISA that the controls for P2PE/E2EE/token solutions are still in place and functioning correctly.  The reason for independent verification is that changes get made and those changes might affect the environment making it less secure.  For merchants not using P2PE/E2EE/tokens, I would think the current SAQs and ROC will remain in place with an annual assessment required.

Will other PCI standards be marginalized or disappear?

The PA-DSS will never leave us.  Software developers need to develop secure code and those service providers, transaction processors, issuers and financial institutions that store CHD/SAD need applications that do that securely, so there is a built in constituency for the PA-DSS.  ECommerce solutions are also still going to need PA-DSS validation.  But regardless of whether P2PE/E2EE and tokenization are implemented, any application potentially dealing with CHD/SAD will need to be assessed under PA-DSS to ensure that any CHD stored is stored securely and is erased securely.  Then there are the unknowns of the future.  You never know what might come along in the future, so there is always a possibility that some solution might need to securely store CHD or other payment related information.  The bottom line is that I find it very hard to believe that the PA-DSS could ever be dropped.

The PTS standard will also not disappear because those POI need to be validated to handle CHD/SAD securely and work properly regardless of P2PE/E2EE solutions.  The PTS is the only standard that is a card brand requirement, not a PCI DSS requirement.  It is the card brands that demand merchants use only PTS validated POI and I do not see that requirement going away when the POI is going to become the remaining target at merchants.

The ASV standard will not go anywhere as there will still be eCommerce solutions that will require vulnerability scanning.  Most merchants will implement eCommerce solutions that minimize their PCI scope using a redirect or iFrame.  Although I can see it coming that even using those solutions will still require the merchant’s eCommerce site, now deemed as out of scope, to be scanned for vulnerabilities.  The reason is that the invocation point of the redirect or iFrame is at risk of modification by an attacker.

One standard I do believe that will eventually go away is P2PE.  The reason is that there is very little to gain with a P2PE versus an E2EE solution.  Both solutions are essentially the same, the only additional work required for E2EE is documenting that E2EE has been implemented appropriately and submitting that documentation to the client’s acquiring bank and getting the bank to agree to the PCI scope reduction.  As a result, I believe that the P2PE standard will slowly and quietly disappear into the night as the cost of going through the assessment process along with the Council filling fees just cannot be justified by a lot of influential vendors such as Verifone and First Data.

There is my rationale for where I think things are hopefully headed.  Only time will tell if the rest of the world sees things the same way.


The NRF’s Collective Amnesia

On May 23, 2016 the National Retail Federation (NRF) issued a scathing indictment of the card brands, the PCI SSC and the PCI standards, in particular the PCI DSS.  But what is truly amazing is the irony and collective amnesia expressed by this document.

The first thing that got to me was the hutzpah of the writer of this document.  Hutzpah is humorously defined as “a child who kills their parents and then throws themselves on the mercy of the court because they are an orphan.”

In this case, the writer has totally missed the whole reason why the PCI standards exist.  It was because of the NRF’s memberships’ short sidedness and refusal to secure their eCommerce Web sites and point of sale (POS) systems that we have the PCI standards.  If merchants had just done the right thing more than 15 years ago and secured their systems that deal with cardholder data (CHD), the PCI standards would likely have never come into existence.  Yet here we have the NRF going after the very thing they helped to create because they do not like it.  Talk about having your cake and eating it too.

The next thing that caught my eye was the NRF’s version of history regarding PCI.  Since I have been around the attempts to secure card data since 2002, I found the NRF’s version of events interesting if not missing a lot of facts.  In the NRF’s version of history, history starts in 2003.  However this should not surprise anyone for this lack of memory as it was the NRF’s own members that are the reason the Visa Customer Information Security Program (CISP) came into existence.  Heaven forbid the NRF should admit that fact.

To correct the record, the Visa CISP actually dates back to the very late 1990s.  Visa was concerned about the growing use of eCommerce and the security of using payment cards to buy goods and service through eCommerce.  Breaches were a new thing, but Visa was concerned that they would become a big thing.  The Visa CISP was codified around late 2001 to early 2002 and was published out to a limited number of consulting firms around the summer of 2002.  By that time, merchants using the new eCommerce approach to selling their goods and services were being breached in record numbers and customer payment information was being lost in what seemed like an almost every day occurrence.  The good news was that eCommerce was in its infancy and the Target or Home Depot type of huge breaches were still a ways off in the future.  The bad news was that, as things were going, banks would be replacing payment cards every week.

The next piece I found interesting was this.

“Around 2003, Visa approached NRF with a proposal to impose Visa’s proprietary data security system (“Cardholder Information Security Program” or “CISP”) on brick-and-mortar retailers for in-store transactions.”

The first reason this statement is interesting is because none of the other card brands had an information security program officially published as of 2003.  MasterCard’s Site Data Protection (SDP) program would be the only one published in the fall of 2003 but it was not really rolled out until early 2004.  American Express and Discover would not come out with their programs until early and late 2004 respectively.

The second thing that I found interesting is the “brick and mortar” comment.  Brick and mortar retail had always been included in the Visa CISP.  But because of all of the eCommerce breaches going on, Visa chose to focus the CISP assessments on eCommerce (does “risk-based approach” ring a bell with anyone?).  We see this selective amnesia with banks as well when it comes to PCI.  The risk when the Visa CISP first came out was predominately with merchants with eCommerce sites.  Banks were also under the CISP scope, but since they were heavily regulated in the US and their security was examined at least annually, Visa and the other card brands did not see them as the huge risk.  As a result, banks were not really assessed until only recently.

“NRF members balked at Visa’s plan largely because of concerns that the other card networks (e.g., MasterCard, JCB International) would also attempt to unilaterally impose their own—possibly different and conflicting—security standards on retailers.”

Given the way the merchant agreements are written (and have been written since the 1960s), the card brands through the acquiring banks can unilaterally implement whatever rules and regulations they want on the merchants.  I find it disingenuous to be calling out your displeasure with the rules and regulations when your legal counsel and management already agreed to those rules and regulations.  But to paraphrase a famous US Presidential candidate, “I voted for the agreement before I voted against it.”

That said, by the end of 2004 the remaining card brands had also introduced their security programs.  American Express and Discover were the first to recognize that multiple programs were not a good idea and told merchants that they would accept the Visa CISP assessment in lieu of their own assessment programs.  As of early 2005, American Express and Discover agreed to accept a Visa CISP review as proof of compliance with their security programs.

Even more interesting in this discussion is that MasterCard’s Site Data Protection (SDP) security program was focused entirely on eCommerce (hence the word “site” in the title), not brick and mortar.  So where the writer of the NRF paper got the idea that every program impacted brick and mortar I do not know.

But then there is the underlying message of this paper.  The NRF is essentially arguing to get rid of the PCI standards all together.  But the NRF makes no argument as to what they would do to replace the PCI standards.  Oh, that is right, I forgot, merchants do not need to be policed.  If we have followed that line of thinking, then we would have the NRF complaining about the over regulation of the government in this area.

Speaking of which.  This paper seems to imply a mistaken belief that the FTC investigation into the PCI standards will result in the removal of the PCI standards.  I am not sure how the writer of the NRF paper seems to think that will happen.  In all my years of dealing with the government, the last thing that happens as the result of an investigation of this sort is not the removal of regulations, it is with the imposition of additional regulations and even more intrusive oversight.  If the NRF thinks the PCI SSC and the card brands were a pain, wait until the government starts going through their members.

As with the FTC, the NRF is actually late to the party.  The vast majority of the NRF’s large members such as Walmart, Target, Home Depot and the like have all implemented or are implementing either end-to-end encryption (E2EE) or point-to-point encryption (P2PE) solutions with tokenization.  The data is therefore encrypted at the point of interaction (POI) and can never be seen by the POS solution.  Any data returned is tokenized so that the POS and other solutions do not have CHD.  That means that the days of the large merchant data breach are almost behind us.  As a result, the only PCI scope the NRF’s members will have is the POI at their checkout counters.  Talk about scope reduction, but that does not seem to matter to the NRF.

But this is an era of piling on and I am sure that has a lot to do with this NRF white paper and the vitriol it spews.  The NRF felt the need to vent and vent they did.  Unfortunately, their argument lacks any sort of basis in fact to make their point.


Just Had To Comment

A friend posted to LinkedIn an interesting article from Dark Reading titled ‘Epic Security #FAILS Of The Past 10 Years’.  It is an interesting read, but I had to comment on a few premises that I found totally misguided or uninformed.

Perimeter Security

“But clinging to the old castle/moat model has been a wakeup call for many enterprises, while others (mostly SMBs) are still in denial that their old-school firewall stops hackers.”

Firewalls, intrusion detection and intrusion prevention technologies are proven to stop hackers from hacking organizations through the use of network attacks.  As a result, hackers changed tactics and went to the use of social engineering techniques such as spear phishing and the like to get around these technologies.  But because tactics change does not mean that these technologies are worthless.  What it does mean is that organizations relying on only these technologies need to understand the changes in attacks and respond accordingly.  As a result, firewalls, intrusion detection and intrusion prevention technologies all still have a place in the information security ecosystem.

Where they have failed is in their implementation and execution.  In too many organizations, the rules implemented by these devices are sloppy and loose.  Why?  Because of the mistaken belief that it is the only way to be flexible and speedy in our ever changing world of business.  Business needs to be educated that security is the result of thoughtful inspection of what is only absolutely needed to ensure that known risks are properly managed.  Taking knee jerk responses and just tossing solutions out are not the way you secure anything.  Any intelligent leader will understand those facts.

“The network perimeter is evaporating. Mobile devices, cloud, and now the Internet of Things, have sucked the life out of traditional, static “set it and forget it” network security, and the bad guys are bypassing the corporate firewall with spear phishing emails that land on the desktops or devices of end users.”

While I agree the perimeter is changing, there still needs to be a defined perimeter.  Otherwise, how do people know where their responsibilities start and end?  The media keeps talking about the disappearing perimeter, but in fact the perimeter will never disappear.  It is not my job to secure the Internet, but it sure as Hell is my job to secure my organization’s network.  I have to consider the threats the Internet and networks I do not directly control present which is why I need to set where my organization’s perimeter exists.

But even more disconcerting is this concept of a “static” or “set and forget” mentality.  When did any information security professional ever think that information security was “static” or a “set it and forget it” situation?  The mantra I was always taught and have passed along in my classes and presentations was “information security is a journey, not a destination”.

End Users

“You can’t patch end users, so what is left?”

Why is it that people throw up their hands and say such things?  There is no doubt that security awareness training is a disaster.  But why is that a fact?  Could it be that we only lamely implement security awareness training.  Who really, truly believes that annual security awareness training will be effective?  Anyone?

People can be “patched” BUT … it takes a LOT of time, patience and persistence.  Attributes that seem to never exist with most security awareness programs I have encountered.

The example I love to trot out is from my own experience.  Right after I got married, my spouse constantly badgered me over my lack of consideration over putting the toilet seat down after using the bathroom.  Years went by and the badgering continued.  It took probably three to four years, but I finally got it down and began habitually putting the toilet seat down after using the facilities.  I learned my lesson and continue to put the seat down even now.

The lesson here is that it takes time and consistent and constant reminders to change human behavior.  Are you really going to put your lame annual security awareness training up against my example and claim it is actually effective?  I seriously doubt it.

Organizations have implemented all of the technological solutions they need to protect information and their networks.  The only last risk that exists are the people that use and interact with those systems.  That is why the hackers have switched over to social engineering techniques.  Why go after hardened systems when people can do it for you?

For the most part and unfortunately, information security professionals are great technologists and lousy people persons.  We need to partner with human resources and industrial psychologists to develop truly useful security awareness training that is focused on changing peoples’ behaviors so that they are more aware of the risks they present to the technology they use and interact.  As information security professionals, we can identify the risks.  But we need to leave the actual training to the HR and psychologists so that it is done effectively.

Point-of-Sale Systems

Point of sale (POS) systems are a dead end.  Just as hackers have changed tactics, so has the POS ecosystem.

With the advent of encryption or tokenization at the swipe/dip of a customer’s payment card, POS systems no longer encounter sensitive authentication data (SAD).  Add in the fact that transaction processors also return back a token instead of the PAN to POS solutions, the POS is no longer a source of cardholder data (CHD).

Most mid-sized and large merchants have implemented or are in the process of implementing these technologies.  Within the next 12 to 18 months, these efforts will be completed and the days of huge merchant data breaches will have come to an end.

This leaves small merchants as the risk of card data breaches.  The question then is will there be enough cards involved to make hacking small merchants worthwhile as a source of card data?  Do not get me wrong, small merchants will be breached, but the value to the attackers will not be the gold mines of breaching a Target or Home Depot.  As a result, attackers will have to move to breaching transaction processors and banks for those big scores and will, for the most part, leave small merchants alone.

Java and Flash

I do not think I really need to comment of Flash.  I think the risks of Flash speak for themselves.

“Many developers had written applications based on older versions of Java or to a specific version of Java that if upgraded to its latest iteration, wiped out some features or functions.”

If rapid application development has a downfall, it is with Java.  In all of the years I have been doing security assessments, I have yet to encounter any organization that developed in Java that does not have a Java security problem.  It never ceases to amaze any assessor just how old some organization’s implementations of Java can be.

But it is not just the loss of features and functions that creates issues with Java.  Typically the larger reason for antiquated versions of Java is just the simple fact that organizations do not have the manpower, time and/or budget to go in and rewrite applications to get them to newer versions of Java every time Java gets updated.  As a result, Java applications sit at their old and potentially risky versions.

Developing mitigation plans for such environments is also challenging.  The most typical approach is to increase log data generated by the application to increase the likelihood that an attack against the application can be identified.  Changes are made to the application to identify key issues that could be indicative of an attack and to generate appropriate log data or messages that can then alert operations personnel to the potential attack.

Another approach is to lock down as much as possible the ports/services and devices that can communicate or invoke the application through firewall rules.  Obviously this is not a good approach for anything Internet facing.

The bottom line is, whatever an organization can do to mitigate or remove the risks of Java it should be doing.  And the risk because of Java should be assessed often to ensure that it is properly managed.


Heads Up – Changes To SAQ A

I had a question this week regarding v3.2 of SAQ A that pointed out there have been some changes to that SAQ that people may have not noticed given the larger issues with the changes to the PCI DSS.  As a reminder, SAQ A is the least amount of PCI requirements any in-scope organization can comply.

Those added requirements to SAQ A are:

  • 2.1(a) – Are vendor-supplied defaults always changed before installing a system on the network?
  • 2.1(b) – Are unnecessary default accounts removed or disabled before installing a system on the network?
  • 8.1.1 – Are all users assigned a unique ID before allowing them to access system components or cardholder data?
  • 8.1.3 – Is access for any terminated users immediately deactivated or removed?
  • 8.2 – In addition to assigning a unique ID, is one or more of the following methods employed to authenticate all users?
  • 8.2.3(a) – Are user password parameters configured to require passwords/passphrases meet the following?
  • 8.5 – Are group, shared, or generic accounts, passwords, or other authentication methods prohibited
  • 12.10.1(a) – Has an incident response plan been created to be implemented in the event of system breach?

Even when a merchant outsources all of their card processing, these are controls that can still apply because in a lot of cases, a merchant is responsible for setup, management and maintenance of their outsourced payment processes and applications.

In addition, merchant employees will also interact with an outsourced payment system to handle chargebacks and disputes.  Those user accounts used by the outsourced environment will normally be managed by someone at the merchant, not necessarily the service provider.

In regards to incident response, the merchant will be involved with incident response even when they have totally outsourced their payment environment.  The merchant will work with their outsourcer to work through an incident and those responsibilities of the merchant need to be documented.

As a result, the addition of these controls should not be a surprise to anyone.


Hold Your Horses

UPDATE: The ROC Reporting Template is available as a PDF on the Document Library page after the Reporting Template and Forms banner almost all the way down the page. The Word version of the ROC Reporting Template is now available from the PCI Portal. No word yet on the PA-DSS and ROV Reporting Template.

Yes, the PCI SSC released the final version of the PCI DSS v3.2, an updated Glossary and Summary of Changes document on their Web site this morning, but we are missing a key piece.  The Report On Compliance (ROC) Reporting Template.

Why is that important you might ask?

The ROC Reporting Template is the document that contains all of the tests that a QSA/ISA needs to conduct to prove that an organization is PCI compliant.  It tells you and your QSA/ISA the evidence needed to gather, how to gather the evidence and level of effort required.  Without that information, an assessment under v3.2 cannot be performed.  Let alone do we truly know the breadth and depth of the changes the Council has made.

The Council promised on their Webinar a month ago that all documents would be released on the same date.  But as of this writing, the ROC Reporting Template is missing in action.

Until we have that document, we have nothing.

Also of note is that the PA-DSS v3.2 and its related Report On Validation Reporting Template are also missing in action as well.


If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.


October 2016
« Sep    

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,689 other followers