Archive for June, 2016

23
Jun
16

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.

18
Jun
16

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 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.

10
Jun
16

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.

06
Jun
16

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.




June 2016
M T W T F S S
 12345
6789101112
13141516171819
20212223242526
27282930  

Months