Author Archive for PCI Guru

18
Jul
16

Third Party Service Provider PCI Compliance

This has recently become a very hot topic as more and more businesses get serious about controlling their supply chains not only for PCI but for information security in general.  It has only taken three years after the Target breach for organizations to really understand that their computer systems and networks are all part of a larger technology ecosystem and that their security depends on the security of everyone else they are connected.  This post provides guidance for service providers and merchants alike.

The first question that can come up is what is the difference between a third party and a service provider?  Technically there is no difference.  “Third party” is a term that comes from the financial audit industry which is where I first encountered it a long time ago.  Third parties are those outside organizations that provide services under contract to another organization.  Examples can include services such as office cleaning, facility management, mailroom management, lock box services, secure document destruction, human resources and a whole host of other business services.

In today’s complex corporate structures, functions such as information technology or human resources as well as whole business units can be separate legal entities and provide business services to other parts of the corporation.  While not truly outside organizations, for regulatory assessments they may also be treated as third party organizations.  I have a number of large clients that take this approach because it simplifies their audit/assessment and compliance reporting processes.  However if a merchant or service provider is going to take such an approach, it should be discussed with their acquiring bank and/or the card brands to obtain their formal approval before assessing and reporting under that approach.

What Organizations Are Service Providers?

The next question that comes up is what organizations qualify as a third party service provider under PCI?  The PCI SSC defines a service provider in the PCI DSS Glossary as:

“Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities. If an entity provides a service that involves only the provision of public network access—such as a telecommunications company providing just the communication link—the entity would not be considered a service provider for that service (although they may be considered a service provider for other services).”

Under that definition any third party organization that directly processes, stores or transmits sensitive authentication data (SAD) or cardholder data (CHD) are service providers.  Examples of these organizations are transaction gateways, transaction processors and some loyalty program providers.  One notable exception is acquiring banks.  Acquiring banks are only third parties if they provide services in addition to being an acquiring bank such as card terminal management and transaction processing.

Where things get messy is third party service providers that do not directly come into contact with SAD or CHD but could come into contact with it.  While I have written two posts on this topic, there still seem to be a lot of managed service providers in denial over whether they need to be PCI compliant.  The bottom line is that if you are a service provider and you could impact the security of SAD/CHD, you must comply with the PCI standard (see PCI SSC FAQ 1092).

But that is where complaints and arguments from such peripheral service providers focus.  Most have no idea if their customers need PCI compliance unless they ask or get asked by a customer.  As a result, they tend to argue that because they do not know they do not need to comply.  Unfortunately, ignorance and/or lack of knowledge are not a valid reason to not be PCI compliant.  That is why it is incumbent for all service providers to ask every customer and prospective customer if they require PCI, HIPAA, GLBA or any other regulatory compliance so that the service provider can ensure that they can properly comply with those requirements.

Service Provider Levels Explained

Service providers, like merchants, are categorized into levels by the card brands.  The most commonly referenced service provider levels are those defined by Visa, MasterCard and Discover.

  • Level 1 service providers conduct 300,000+ transactions annually on behalf of their customers, and
  • Level 2 service providers conduct less than 300,000 transactions annually for their customers.

JCB and American Express have their own service provider level definitions, but there are very, very few service providers that only process exclusively for those brands.  If you are one of those rare service providers, I would tell you to visit the appropriate brand’s Web site and review their service provider level definitions.

Level 1 service providers must conduct a PCI assessment that results in a service provider Report On Compliance (ROC) and related Attestation Of Compliance (AOC).  That assessment can be conducted by a QSA or an ISA just as with merchant PCI ROCs.  Level 2 service providers can use either the service provider SAQ D or create a service provider ROC.

These levels also add confusion to those service providers that do not process or transmit any transactions.  As they rightfully point out, their transaction volume is zero.  I then point out to them that zero is less than 300,000, so they are considered a Level 2 service provider.  Problem and confusion solved.

The most important thing to understand about service provider levels are that if your organization is a service provider level 1 for any card brand, your organization is a level 1 for all card brands.

The next important thing to note about these assessment processes is that they must use the service provider specific SAQ D, ROC and AOC forms.  I cannot tell you the number of times I have gotten a service provider’s AOC and/or SAQ/ROC and it is not the service provider specific version.  More on this topic later.

The Global Registries

Once we get these third parties to admit they are in scope for PCI compliance, the next issue that typically comes up is in regards to the card brand global registries for service providers.  Both Visa and MasterCard have public registries of service providers on their respective Web sites.  These are strictly marketing schemes run by the respective brands and it is not mandatory that service providers be listed on either of these lists.  Since they are marketing schemes, they have no real meaning regarding any merchant organization’s PCI compliance and are not a substitute for getting an AOC from a service provider.  What they do provide is a quick way for merchants to find PCI compliant service providers providing services they wish to outsource.  As a result, a lot of service providers like to be listed on these Web sites just so that merchants will consider them.

To be listed on either of these Web sites, the service provider must have a PCI QSA (an ISA cannot be used) conduct an assessment and then the QSA must file the resulting compliant ROC and AOC with the appropriate card brand.  In the case of service providers that process or transmit SAD/CHD, they will have a relationship with a bank that must sponsor the service provider with the brands to get listed on the Web site.  For service providers that do not have a relationship with a bank because they do not process or transmit SAD/CHD, those service providers must contact the appropriate card brand who will then sponsor them.  Once approved by the brand, the service provider then pays a fee to be listed.  To stay listed on the brands Web site, the service provider must annually revalidate their compliance using a QSA, have the QSA file their compliant ROC/AOC with the brand and pay a renewal fee.

To add confusion for service providers, Visa also maintains a separate, private inventory of service providers.  This list is for Visa and their acquiring banks to reference and is not available to the public.  Visa is trying to ensure that all service providers are tracked for their annual PCI compliance even if they do not register for their public Global Registry.  So if you are a service provider and are filing a service provider SAQ D/ROC or you do not register for the public Global Registry, you will be asked to fill out information for this private Visa service provider inventory.

Service Provider AOC Issues

The most common AOC problem we encounter with service providers is that they only assess some of their services provided, not all of their services.  For third party run data centers the most common requirements assessed are requirements 9 (physical security) and 12 (policies) but no other requirements are assessed even if that same firm provides managed services such as network security, network monitoring, virtualization, server management and network management.  I will address this situation later on in the post when discussing service providers that do not have a PCI assessment.

The next most common problem is that the AOC provided to the merchant is not a service provider AOC.  The biggest problem this mistake creates is that there is no way to know what services provided to the merchant were assessed for PCI compliance.  Then you have a very embarrassing conversation for all involved as you inform the service provider that their PCI compliance is reported on the wrong form(s).  Worse is the fact that most times this results in a whole new assessment being conducted because service provider requirements were not assessed and too much time (i.e., more than 90 days) has passed since the assessment was completed.

With the introduction of v3 of the PCI DSS, the service provider AOC has had a number of changes to facilitate merchants’ evaluation of the service provider’s PCI compliance.  The first change was to list not only what services were assessed in section 2a, but what services were not assessed.  Then for each service that was assessed, the QSA/ISA is required to individually document in separate sections of 2g of the AOC which of the 12 requirements were tested for each service.

Which brings us to the third most common problem.  The AOC does not document each service individually in section 2g.  As I stated earlier, this was a change with v3, but many QSAs/ISAs did follow the instructions in the section.  In addition, the Council has not helped this situation as the AOC document is locked so adding additional sections for 2g are not possible using the Council’s form.  The Council’s advice is to copy that section and then paste additional sections as necessary to the end of the AOC.

Another situation that we occasionally run into is service providers that have gone through the PCI assessment process but refuse to provide their customers with a copy of their AOC.  Reasons for not providing the AOC vary (from the stupid to the absolutely idiotic), but it happens more often than I would like to admit.  The PCI SSC has repeatedly reinforced at their Community Meetings and in FAQs that if a service provider has been independently assessed, they must provide their service provider AOC to their customers.  If you encounter such a situation, I would recommend contacting the appropriate card brands and complaining to them about the service provider particularly if that service provider is listed on the card brands’ public Global Registry.  In most cases, such complaints will result in the brand suspending the service provider’s listing until they comply.

The last problem we encounter with AOCs is their timing and availability.  In a perfect world, every service provider would have an AOC less than a year old available for every customer.  But in the real world, a merchant conducting their assessment encounters service providers that either: (a) are also in the process of conducting their assessment, (b) had their assessment delayed and will not be able to provide an AOC by the time the merchant’s assessment is completed, or (c) does not have an AOC.

The first two conditions are timing issues and should not be a problem unless the service provider has not been compliant in the past.  As the Council has repeatedly pointed out, no organization’s PCI compliance is affected by the PCI compliance of any other organization.  In addition, the Council has also said that the PCI assessment process are not conducted to the standard of an AICPA SSAE 16 assessment which needs reliance on third party assessments.  As a result, you need to work with your QSA/ISA, bank and service providers to agree to an approach to handling these first two conditions.  My recommendation is as long as there is close to a year between assessments (give or take 30 to 60 days), I would accept whatever current AOC is available from the service provider.  For situations where there is going to be significant differences in time, I would consult with your acquiring bank or the card brands.

It is the third condition that creates the most heartburn for a merchant and the service provider.  In this situation, a merchant has no choice but to include that service provider as part of the scope of their PCI assessment (see PCI SSC FAQs 1065 and 1290).  Most of the time, this is covered under the service provider’s contract under a section regarding regulatory and legal compliance audits and assessments.  The service provider agrees to allow the merchant’s staff or authorized representatives to conduct any audits/assessments whenever required.  In very rare situations, I have encountered older contracts that do not have such audit/assessment provisions and it becomes a painful issue to get the service provider to comply with the assessment process.

However, this third condition creates a larger scope and will result in increased costs for a merchant’s PCI assessment.  Sometimes that increase can be extremely significant if the service provider is doing a substantial amount of the work that needs to be evaluated such as hosting and managing a merchant’s IT environment.  While QSAs try to minimize the occurrence of this sort of situation when scoping engagements, they still encounter it as the merchant is confused and does not understand the implication of their decision to use a non-PCI compliant service provider and their responsibilities under the PCI DSS and their Merchant Agreement.  As a result, the QSA does not get accurate answers to their scoping questions and does not find out about the service provider’s involvement until they are performing the assessment.

Non-PCI Compliant Service Providers

Before discussing this, I first need to dispel a myth.  Nowhere does the PCI DSS require a merchant to use only PCI compliant service providers (see PCI SSC FAQ 1312).  That is a requirement specified by certain card brands in their Merchant Agreements (most notably Visa and MasterCard).  Therefore not using PCI compliant service providers does not and should not result in a PCI compliance issue provided they are assessed as part of the merchant’s assessment as stated earlier.

Getting back to the topic at hand.  As an example, you have a service provider AOC and it says that section 8 is not compliant (with the latest changes in v3.2 for service providers, this is a situation that is becoming more and more common.)  As a merchant, what do you do?

This is where requirements 12.8 and 12.9 come into play as part of an organization’s vendor management process.  As part of your organization’s vendor management process you should have the following processes, at a minimum, in place.

  • Have a complete inventory of service providers including the date of their last AOC, expected receipt date of their next AOC, and whether the current AOC was PCI compliant. If not PCI compliant, it should note for each service provider those areas of non-compliance and the dates each area will be compliant.
  • For any non-PCI compliant service providers, periodic meetings need to be held with the non-compliant service provider to obtain updates on their remediation efforts. Depending on the duration and complexity of the project(s), these meetings may be conducted quarterly, monthly or even weekly.  However notes need to be kept for all of these calls and information updated as to the project(s) status.  These updates should not be suspended until the service provider is judged PCI compliant.
  • Any adverse changes in remediation efforts status should result in a review of the service provider and possibly result in seeking a new PCI compliant service provider.
  • To be judged compliant, the service provider must have a QSA/ISA submit proof (for example, a letter outlining evaluation procedures followed with a revised AOC) that they have evaluated the remediation efforts and that those efforts are complete and the PCI requirements in question have been judged PCI compliant.

The most important take away in this whole discussion regarding non-PCI compliant service providers is that it does not affect the PCI compliance of the organization using the service provider.  That said, anyone following such procedures outlines above should be prepared to provide their acquiring bank and/or card brands with proof of all of these monitoring activities.

As with all topics related to PCI compliance, this one is no different and there will be nuances to all of these discussions.  But hopefully you now understand all of the basics regarding third party service providers.

03
Jul
16

The Council Issues A New Information Supplement

Back in May, the PCI SSC issued a new information supplement titled ‘Effective Daily Log Monitoring’.  It probably slipped under most people’s radar because of the issuing of v3.2 of the PCI DSS.  And for my friend, Anton Chuvakin, this will be on his reading list immediately if he has not read it already because his book, ‘Logging and Log Management: The Authoritative Guide to Understanding the Concepts Surrounding Logging and Log Management’, is listed in the information supplement’s bibliography and from the way this supplement reads, figured prominently in its content.

First some overall impressions.  Unlike a lot of other information supplements, this one actually clarifies and provides a significant amount of knowledge and great advice.  Every organization that needs to meet PCI compliance should read it.  But more importantly, any organization that does not fully understand the collection and analysis of log data should read it to get a foundation in these practices.

One of the best recommendations comes in section 5.2 in the supplement which instructs organizations to develop a baseline from log data.  This is the biggest problem when an organization gets serious about analyzing log data, they fail to baseline the exceptions.  I cannot tell you the number of times that I have discussed logging with the personnel responsible for monitoring for alerts and they cannot tell you what is “normal” activity versus “abnormal” activity.  As a result, they either: (1) chase every alert as though they are an attack (they are not), or (2) ignore alerts because they assume they are “normal” activity (they are not).  The result in case #1 is that they cause burn out in the organization and, of course, in case #2 the organization is likely getting attacked and compromised.

I cannot understate the importance of this activity both in getting a log monitoring project going but also as something that needs to also be an ongoing activity.  No organization’s IT environment is static, so it is important to continuously baseline the log data and adjust for changes.  This can be done by adding an item on change control tickets to evaluate the impact on log data or re-baselining every quarter.  The bottom line is that baselining is not something done once, the baseline must be periodically updated.

The most glaring omission in this document is a reference on page 27 to Appendix B that promises to provide readers with a list of “sample tools” for normalizing log data.  But guess what?  There is no Appendix B.  Hopefully the Council will issue a revision to this document and add Appendix B to that future revision.

If I had to ding this information supplement for anything it is the downplaying of the need to have one or more tools to collect and analyze the log data.  The Council obviously has to walk a fine line on this, but let us be honest.  Anyone that believes that log monitoring and analysis can be done without one or more commercial tools is kidding themselves.  Yes, a person can put up a centralized log collection server and the parse that collection of data with tools such as Grep, Perl or Python.  Again, let us be honest, no one has the time to write all of the necessary scripts or search patterns to find all of the conditions you need to find.

It used to be that there were open source tools such as Splunk and similar available for log gathering and analysis.  However, those days disappeared a number of years back and only commercial versions are available.  So everyone needs to be prepared to spend a certain amount of money to get a toolset that will provide the information gathering and analysis toolsets necessary.

I also fault this document for focusing too much on log information normalization.  This is exactly why organizations need to invest in a commercial tool.  This was the big complaint with using open source tools.  People found that they got basic functionality, but then had to essentially conduct a full-fledged system development effort to get the analysis and alerting done.  This was the big selling point with commercial tools such as LogRythms and ArcSight that came the basics as well as a whole host of analysis templates both free and for purchase.

Another ding I have is the minimal number of requirements that the information supplement identifies as being satisfied by log monitoring and alerting.  I can find at least 15 instances where requirements can be met by monitoring and alerting, not just the eight that are identified in the supplement.

Even with these concerns and shortcomings, this is possibly one of the better information supplements issued by the Council and is a must read by everyone.

To get your own copy of the information supplement, go to the PCI SSC Document Library, select ‘Guidance Documents’ and scroll down to the ‘Logging’ banner.

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

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.

20
May
16

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.




Announcements

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.

Calendar

July 2016
M T W T F S S
« Jun    
 123
45678910
11121314151617
18192021222324
25262728293031

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

Join 1,632 other followers


Follow

Get every new post delivered to your Inbox.

Join 1,632 other followers