Posts Tagged ‘Card Brands

24
Oct
21

Remote PCI Assessment Guidance Issued

At the end of September 2021, the PCI Council released a Guidelines and Procedures document on conducting Remote Assessments for PCI and card brand assessments.  Most of this document is a rehash of previous Council statements and guidance.  However, there is one new element in this document that all QSAs will need to read and comply with and that is the requirement of documenting a feasibility analysis to justify conducting a remote assessment.

Some of the examples the Council gives as valid reasons that an on-site assessment may not be feasible includes:

  • Restrictions on the ability to travel or meet in person due to health and safety concerns or government advisories.  We are all familiar with the COVID-19 pandemic and its impact on travel, particularly international travel.  However, I encountered this a while back due to a volcanic eruption in Iceland that cancelled my trip to Europe.  Since we had no way of knowing how long the eruption would cause travel disruptions and we were on a tight timeline, we conducted video conferences rather than travel.
  • Geographic locations that are physically inaccessible or difficult to reach.  I personally ran into this situation one several years ago when a data center in Europe that was supposed to be decommissioned before the next assessment remained operational.  The company I worked for had shut down their EU operations and there was no way to justify 16 hours of flight time for a two-hour data center walk through.  We held meetings with the data center operator via video conference and did a virtual walk through.
  • Testing required at a location is limited to documentation and interviews and no observations of processes, systems or physical environment apply.
  • The entity operates a virtual environment without physical premises or facilities.  This has become more and more common with entities that operate in The Cloud.  Why rent expensive office space when there is not need for it?  This situation only got more prevalent with the pandemic and will likely only increase in the future.

As the Council states in their guidance,

“For many assessments, a combination of onsite and remote testing may provide a suitable balance, as it allows for increased efficiencies in the assessment process while enabling an appropriate level of assurance to be achieved in the assessment result.  For example, documentation reviews can often be performed remotely without significant loss of assurance, whereas observations of processes and environmental characteristics will generally require an onsite review.”

Regardless of whether the assessment fits into one of the bullets above, the Council wants QSAs to formally document their analyses of why the onsite assessment cannot be performed and the risks that may present to meeting the assessment objectives.  This analysis needs to be completed prior to starting any testing and is supposed to be a joint effort between the assessor and the client.

Topics that the Council recommends be addressed include, but are not limited to:

  • Confidentiality, security, and data protection requirements.
  • Availability and effectiveness of the remote assessment technologies.
  • Effects on entity’s personnel.
  • Effects on operation support.
  • Assessment scope and completeness.
  • Quality and reliability of digital evidence.

The Council further states:

“During the analysis, the entity and assessor should identify any challenges and potential risks associated with the remote testing and determine whether it is feasible for testing to be thoroughly completed to produce a high level of confidence in the assessment results.

The results of the feasibility analysis—including the risks and challenges associated with use of the remote testing methods, and any mitigating controls for overcoming the risks and challenges—should be documented and agreed upon by both the entity and assessor. A copy of the feasibility analysis results should be included with the applicable ROC/ROV. Entities and assessors may be required to produce the analysis upon request by the PCI SSC or applicable compliance-accepting entity.

The key points from that statement above is that: (1) the feasibility analysis needs to be submitted with the ROC/ROV and, (2) if requested by the PCI SSC or compliance accepting entity (i.e., Brand or bank), the QSA is required to produce the analysis.  As a result, this is a non-optional exercise.

The feasibility analyses must document that:

  • The assessment is feasible to be fully completed at this time using onsite methods, remote methods, or a combination of onsite and remote methods.
  • The assessment is only feasible to be partially completed at this time.
  • The assessment is not feasible currently.

According to the guidance, it is only those assessments that are completely feasible that can be conducted.

The Council includes a very important note regarding the analyses.

“The feasibility analysis determines whether the use of remote testing methods is feasible for a particular assessment.  Determining that a remote testing method is feasible does not guarantee that use of the testing method will produce the level of assurance needed for the assessor to reach a finding; this will depend on how the remote testing method is implemented and used, whether the testing can be completed for all applicable components and areas, and whether sufficient evidence is provided for the assessor to make a determination.  Assessors and entities should continue to monitor and evaluate the effectiveness of the remote testing methods throughout the assessment to confirm whether the testing methods are performing as intended and whether additional testing may be needed.”

This concept of “assurance” appears to all be in the eye of the beholder.  Meaning, if the Council, Brands or Banks determine, in their opinion, that the remote methods are not providing appropriate levels of assurance, the ROC/ROV can be rejected.  Not that a lot of banks are going to reject ROCs/ROVs on this, but I can see the Council’s AQM reviews and Card Brands rejecting ROCs/ROVs on analyses that they deem flawed or incomplete.  The AQM process is the most concerning because a QSAC could end up in remediation due to a failure to appropriately document the remote assessment feasibility.

As with most edicts issued by the Council, they should have produced a form for this feasibility analysis so that everyone understands what is required from these feasibility analyses.  Can the feasibility analysis be documented in section 1.2 of the reporting template or is a separate document required?  I would recommend this for the obvious remote assessments of COVID and everything in The Cloud.  I would recommend a separate document for feasibility analyses that are longer in discussion.

Sadly, I foresee a lot of confusion and heartache in the QSAC community as we move through this new requirement.  That is because I see a lot of assessments that are blocked due to COVID travel restrictions or the assessed entity having no physical offices being rejected for “flawed” feasibility analyses when it should just be allowed with no further documentation or discussion.

It will take time to see how this shakes out.

UPDATE 11/29/2021 – I received a comment on this post (see below) and the confusion is beginning. A service provider has had one of their customers request the documentation regarding what is provided in Appendix A of the remote assessment guidance document as well as the remote assessment feasibility study. Since these are ROC documents, there is no requirement from the Council that requires any organization to turn over their ROC to any third party other than their acquiring bank or the card brands. The AOC is the communication document to third parties. If an organization wishes to turn over Appendix A from the guidance, that is the organization’s decision, but it is NOT mandatory nor it is required by the Council.

20
Apr
15

Why Requirement 5 Must Change

This issue came to a head recently when a colleague of mine attended an ISSA chapter meeting where there was a session given on anti-virus by someone from a US government intelligence operation. I had entirely forgotten about this until they brought it back up. The issue is the ineffectiveness of anti-virus solutions and why they are ineffective.

Most of us have seen the anti-virus testing results that are periodically pumped out by the various trade journals. They all point out that anti-virus is only around 30% to 40% effective in detecting malware. But what never seems to get brought up and clearly discussed is why anti-virus solutions are so bad at their job.

The reason is that anti-virus solution providers have taken a page out of the United States Centers for Disease Control (CDC) influenza playbook. The reason is the statistics that the speaker shared.

  • For every current piece of original malware, there are around 400,000 variants of that malware making the rounds on the Internet. Variants are easy to make which is why there end up being so many so quickly.
  • To scan a computer for every piece of malware developed since day one including variants would take around 40,000 hours (almost a month) to complete. And that is if you dedicate a core for that to run as well as a core to scan everything coming at you.
  • The signature files required to track all malware and their variants from day one would take up a significant portion of your hard drive.

Like the CDC does a scientific wild-ass guess (SWAG) to figure out what influenza vaccine to make every spring, anti-virus vendors do the same thing with their signature files every day. What anti-virus vendors do is select the most likely malware and variants your computer will encounter and that is what your anti-virus signature file will contain. The idea is that their heuristic engines and firewalls will hopefully detect the malware not included in the signature file.

Getting back to the PCI DSS, requirement 5.1.1 states that anti-virus solutions:

“Detect all known types of malicious software, remove all known types of malicious software, and protect against all known types of malicious software.”

Guess what?

Given the aforementioned revelations that signature files are incomplete, there is no anti-virus solution available today that meets those requirements of detecting and protecting against “all known types of malicious software”. All of us have, unknowingly or not, been “checking the box” on this requirement.

I along with a number of other security professionals have stated for years that anti-virus alone has never been adequate for protecting systems as portrayed in the PCI DSS, by the PCI SSC and by the card brands. If you truly want to protect systems from “all” malware as specified in the requirement, you need to use anti-virus in conjunction with a whitelisting/blacklisting and/or file change detection solution. Anti-virus alone is just not enough as the repeated tests of these solutions have pointed out over the years.

The reason you still need to keep anti-virus is that these solutions do what the others do not – quarantine or remove the malware. Quarantining or removing malware is truly an art form and has gotten even more so as operating systems have become more sophisticated in how they manage applications. The reason for this is that, while it is easy to install software, it has become very tricky in uninstalling it, if you can even uninstall it at all.

Anti-virus vendors spend the bulk of their research and development time and money in determining the best way at quarantining and/or removing malware. While a lot of whitelisting/blacklisting vendors have promised to add the ability of quarantining and removing malware, most have come to the realization that providing such features are beyond their current capabilities and not as simple as they have portrayed it in their sales meetings. As a result, I would expect it will take these whitelisting/blacklisting vendors years to have this capability if they even bother to develop it.

So what should the PCI SSC do?

The Council needs to require additional malware detection measures to requirements 5 so that organizations are truly protecting their systems against malware. In the immortal words of Bruce Scheier, what we have now is “security theater” – the appearance of security without security. Anti-virus alone is not cutting it, so it is time to enhance that capability by requiring more than just anti-virus.

The Council should also work with and demand that the anti-virus, whitelisting/blacklisting and file monitoring vendors provide some sort of integration between their respective products. That way when the whitelisting/blacklisting or file monitoring solutions detect an issue, the anti-virus solution can do the quarantine or removal of the suspected malware which it is typically very good.

Is this going to detect every piece of malware?

Sorry, but some will still get through (remember, security is not perfect). But the amount that gets through should be significantly less than with just anti-virus alone.

How much gets through will be up to how the tools are configured. As a lot of you have found out, just installing file monitoring software does not detect all file changes. That is because the installation does not get tweaked to protect everything it should. That takes time and effort that a lot of people do not provide because they have other things to get done. The better you implement the other tools, the fewer pieces of malware that will get through.

Reach out to the Council and let them know that you also think that requirement 5 needs improvement.

01
Mar
15

What Is A Level 3 Merchant?

This consistently keeps coming up as an issue because of the confusing definitions on the Visa, MasterCard and Discover Web sites.

“Merchants processing 20,000 to 1 million Visa e-commerce transactions annually”

“Any merchant with more than 20,000 combined MasterCard and Maestro e-commerce transactions annually but less than or equal to one million total combined MasterCard and Maestro e-commerce transactions annually”

“All merchants processing between 20,000 and 1 million card-not-present only transactions annually on the Discover network”

In my opinion, the reason for the confusion is that definitions only mention eCommerce or card-not-present (CNP) payment transactions and no other payment channels. As a result, people think that other payment channels do not count for Level 3 merchants or that Level 3 merchants only do business through eCommerce or CNP payment transactions.

I have even encountered merchants that argue that they are exempt from PCI compliance because their organization does more than 20,000 eCommerce or CNP payment transactions but they also process payment transactions through other payment channels but, in total, have less than 1 million payment transactions. Some people will argue any point to avoid PCI compliance.

So if this is not true, exactly what is a Level 3 merchant?

Based on training and from discussions with the card brands over the years, Level 3 merchants have 20,000 or more eCommerce or CNP payment transactions, but cannot exceed 999,999 payment transactions from all payment channels combined.

As examples:

  • A pure eCommerce merchant with no other payment channels can conduct up to 999,999 payment transactions through their Web site and be considered a Level 3 merchant.
  • A merchant with 20,000 or more eCommerce or CNP payment transactions that also has one or more of the following; brick and mortar, mail order, telephone order or other payment channels, cannot exceed 999,999 payment transactions from all of their payment channels to be considered a Level 3 merchant.

If an organization exceeds a total of 999,999 payment transactions from all their payment channels they are, by definition, classified as a Level 2 merchant. If the merchant has fewer than 20,000 eCommerce or CNP payment transactions, then they would be classified as a Level 4 merchant.

Hopefully we all now understand the definition of a Level 3 merchant.

15
Feb
15

New PCI Compliance Study

Dr. Branden Williams and the Merchants Acquirer Committee (MAC) have issued a new report on PCI compliance and the impact of breaches on merchants and MAC members.  I had the pleasure of getting a preview of the survey results from Dr. Williams a few weeks before its publication.  Based on some of the online chatter I have seen, the study is being both applauded and chastised for its results.

First, who is the MAC?

“The MAC community includes acquirers/merchant banks, processors, independent sales organizations (ISOs), and others. MAC membership exceeds 500 firms.”

What was the response rate for the study?

“Approximately 20% of MAC members participated in the survey (although not all survey responses could be used in the analysis due to incomplete responses).”

While 20% might seem an awful low response rate for a survey, for those of us that conduct surveys, 20% is actually quite good.

One set of facts that was missing in the survey that I felt was important was how many merchants do the 100+ survey respondents cover and what is their breakdown by merchant level?  Branden very kindly ran a query and sent me back the following.

Level 1 Merchants:                  73

Level 2 Merchants:                153

Level 3 Merchants:             3,832

Level 4 Merchants:      1,140,623

Total:                              1,144,681

Based on this information, I would say that it reasonably represents the breakdown of merchant levels out in the real world.

The biggest finding of the study and what most people are pointing to is the low compliance percentages across the MAC members’ merchants.  Level 1, 2 and 3 merchants are only compliant around 67% to 69% of the time during their assessments.  However, most troubling is that Level 4 merchants are only 39% compliant.

Depending on the merchant level, these figures are not even close to what Visa last reported back in 2011.  Back then, Visa was stating that 98% of Level 1 merchants were reported as compliant.  Level 2 merchants were reported to be at 91% compliance.  Level 3 merchants were reported at 57% compliance.  As is Visa’s practice, it only reported that Level 4 merchants were at a “moderate” level of compliance.

So how do we square the difference in compliance percentages between the MAC and Visa numbers?  We do not because the numbers are like comparing apples to oranges.

The purpose of the study was to examine breaches and their impact on merchants.  As such, the study’s numbers indicate not only PCI compliance but also the number of organizations breached that were deemed PCI compliant, hence the much lower PCI compliance rates.

Visa’s numbers are based on filings of PCI Attestation Of Compliance (AOC) forms with processors and acquiring banks who then report those statistics up to Visa.  Visa, or any card brand for that matter, has never shared the complete equation of the number of merchants that were breached but filed an AOC indicating they were PCI compliant.  As a result, the figures posted by Visa are not representative of the study’s results and vice versa.

I think this study provides a much better look into PCI compliance than we have had from the card brands.  It shows that merchants have a significant amount of work to do maintaining PCI compliance.  I would highly recommend you download a copy of the report and share it with your management.

31
Jan
15

Merchant, Service Provider Or Both?

Apparently there are a lot of newcomers to the PCI compliance business and are asking bizarre questions regarding PCI.  One of the most common is if their organization is a merchant or a service provider or both?

Merchant

According to the PCI DSS v3 Glossary, a merchant is defined as:

“For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard or Visa) as payment for goods and/or services. Note that a merchant that accepts payment cards as payment for goods and/or services can also be a service provider, if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers. For example, an ISP is a merchant that accepts payment cards for monthly billing, but also is a service provider if it hosts merchants as customers.”

One of the points that create some of the most confusion is the point made at the end of the merchant definition that it is possible for a merchant to also be a service provider.  A lot of people think that this is a black or white, either or type of situation which it is not.

The key thing to determining if your organization is a merchant is if your organization signed a merchant agreement with a bank and has a merchant account with that bank.  If your organization did, then you are definitely a merchant.

Service Provider

Now let us talk about service providers.  In the same document, a service provider is defined 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).”

The first thing to remember about service providers is that you can be tagged as a service provider and not be directly processing, storing or transmitting cardholder data (CHD) or sensitive authentication data (SAD).  We see this most often with organizations that provide managed security services (MSS).  In most cases, these organizations manage/monitor the devices that provide and/or secure the communications links.  As a result, these MSS providers can have access to unencrypted CHD/SAD whether they realize that or not.  If the MSS could be in contact with unencrypted CHD/SAD via the devices they manage, then they are in-scope for PCI compliance.

I can tell you from personal experience that service providers that are not directly processing, storing or transmitting CHD/SAD will push back and fight very hard to be ruled out of scope for PCI compliance.  It has gotten to the point that I have seen and heard of service providers taking customers to court for misrepresenting their business and to force their customer out of their service contract.  In the majority of the cases I am aware; it was shown that it was the service providers’ negligence from not explicitly asking whether or not PCI compliance was required by the customer.  So if you need to be PCI compliant, it is very important to make that clear to any service provider you are looking at just in case one or more of their services could come into contact with CHD/SAD.

Another way an organization can become a service provider is when they conduct card transactions on behalf of a third party.  The best example of this situation is with outsourced call centers.  While the call center might be conducting the card transactions on your systems, they are a third party that is processing and transmitting CHD/SAD through their workstations for your organization.  As a result, the call center is a service provider and is in-scope for PCI compliance.

Another way an organization can become a third party is if they are conducting transactions through their systems using a merchant account of a third party.  I have encountered this with call centers where the call center is using their own applications, but the merchant account used to process payments through is not the call center’s merchant account, it is the merchant account of the call center’s customer.

Both?

Finally, there is the example from the Merchant definition where the organization is both a merchant and a service provider.  As pointed out in the definition, this most commonly occurs with Internet service providers (ISP) and shared hosting providers that provide not only services for hosting a customer’s IT environment, but then accepts cards for payment for those hosting services.  From the hosting perspective, these organizations are a service provider and must comply with the PCI DSS for those services provided to their customers.  However, these organizations are also merchants because their customers can pay using a credit/debit card.

Some Closing Comments

Before I finish this post, I also want to add some comments regarding compliance reporting for service providers.

The first comment I would like to make is regarding reporting and compliance testing.  If you are a service provider, you only have the choice of a Self-Assessment Questionnaire (SAQ) D or a Report On Compliance (ROC).  If your organization processes, stores or transmits less than 300,000 card transactions, then you can use either the SAQ D or perform a ROC.  If your organization processes, stores or transmits 300,000 or more card transactions, then you are required to do a ROC.

If you are an ISP, MSS or similar service provider that does not process, store or transmit CHD/SAD, then you will not have a transaction count and therefore will fall on the under 300,000 transaction count rule.

Why would an organization that can do an SAQ D do a ROC?  If an organization desires to be listed on the Visa Global Registry of Service Providers or the MasterCard PCI Compliant Service Provider lists, then the service provider must do a ROC.  There are rules and fees for being included on these lists that each card brand Web site documents.  A knowledgeable QSA can help facilitate your listing on these sites as well as conducting the requisite ROC assessment.

A quick side note regarding Visa and service providers.  Visa is conducting a separate service provider inventory program that is outside of their Global Registry program.  This new inventory process has confused a lot of service providers and QSAs alike including yours truly.  For about the last year or so, Visa has been “registering” all service providers in an attempt to create a complete inventory of service providers.  This service provider inventory program has nothing to do with the Visa Global Registry and does not put any organization that is processed through it on the Visa Global Registry.

It is very important for service providers to know that the Attestation Of Compliance (AOC) form for the service provider is very different from the merchant version of the AOC.  The AOC for service providers provides a list of the services provided by the service provider that were assessed for the AOC.  This information is necessary for customers to know if all of their services were assessed for PCI compliance.  If a service was missed, then the merchant is responsible for assessing that service for PCI compliance.  So it is very important that you ensure that all services provided to your customers that require PCI compliance be assessed for PCI compliance.

Then there are the number of times I have received an AOC from a service provider only to find that it is a merchant AOC, not a service provider AOC.  With v3 of the PCI DSS, the Council has created separate SAQ D forms for merchants and service providers that will hopefully cure some of this issue.  It is incumbent on service providers to make sure that when they sign the AOC that it is a service provider AOC and all of the services are listed.  If not, then you need to go back to your QSA and get the right AOC form with the right information created.

And finally, my biggest pet peeve with service provider AOCs.  Some QSACs create these wonderful “Certificates Of PCI Compliance” that, while they look really nice, have no meaning to your customers and their QSAs.  No matter how many times the PCI SSC has stated that the only officially recognized document out of a PCI assessment is the AOC, I still encounter these certificates as “proof” of PCI compliance.  When asked to provide the AOC, I then get the indignant response that I should have everything I need.  In one case, I was even told I could not possibly be a QSA because I did not recognize the certificate as proof of compliance.

As I stated earlier, the service provider AOC is required to ensure that all service provided were assessed and QSAs are required to have copies of all service provider AOCs in order to show that all third parties have been officially assessed for PCI compliance.  No AOC means that the service provider is not PCI compliant and must be assessed as part of the customer’s PCI assessment.

I hope we are all now on the same page regarding the concepts of a merchant and a service provider.

04
Dec
14

It Is The QSA’s Fault

“Usually when PCI-compliant companies are breached, the real culprit is the assessor, the person who confirmed the company had met the PCI Requirements.” Jeff Multz, Dell SecureWorks

This is a very interesting approach for an employee at a qualified security assessor company (QSAC) to use to drum up business, toss all QSAs, including his own organization’s QSAs, under the bus.  I know that is not what he meant to do, but that is certainly what he did with this statement in his posting a few days ago.

I think most QSAs know where Mr. Multz is coming from.  He is more than likely venting over losses to QSACs that we all know are more interested in revenue generation than security.  They further that goal by incenting their QSAs to do as many PCI assessments as possible in the shortest amount of time as well as identify opportunities for selling the QSAC’s security appliances to solve compliance problems.  And to just pile on, they further their revenue generation by being the low cost provider through a focus on volume of work over quality.  As Kurt Vonnegut said in Cat’s Cradle, “In this world, you get what you pay for.”

Getting back though to Mr. Multz and his statement that QSAs are responsible for all breaches, let us see how that plays out with a few breaches.

During the Target breach, it was the QSA that was socially engineered and gave away the keys to the kingdom and missed all of the alerts generated by the FireEye software.  At Neiman Marcus, it was the QSA that missed the alerts for 60+ days that the malware was reinstalling nightly.  It was the QSA that swapped out the points of interaction (POI) at Barnes & Noble for malware infested POI.

Sorry Mr. Multz, but it was employees and/or contractors at all of these organizations, not the QSA that had a part in these breaches and all breaches for that matter.  I really do not see how you can hold a QSA responsible for the inaction and errors of employees/contractors.  Organizations are not going to pay to have QSAs on site, 24×7, to babysit all of their employees to maintain compliance with PCI or any other compliance program.  Not only that, no security framework is ever going to stop breaches, all they do is hopefully minimizing the impact when a breach occurs.

However, Mr. Multz was not done.

“The PCI Requirements were created so that organizations would focus on securing their networks, but many assessors only focus on meeting the requirements rather than security.”

From this statement it is painfully obvious that Mr. Multz does not understand what an assessment is about and how the assessment process works.  The job of a QSA is to execute the tests as defined in the PCI DSS Reporting Template and report the results of that testing – nothing more, nothing less.  Organizations are judged by a QSA as compliant with the PCI DSS whether they are just squeaking by or if they have a full on security program next to none.  Organizations do not get “extra credit” or “atta boys” if they have gone beyond the requirements.

While the original intent of the standards was to focus on securing cardholder data, that got morphed by the wonderfully misdirected marketing job that was done by certain card brands before the PCI standards came together.  For those of us around the security industry more than a decade ago, we advised Visa and MasterCard to stop pushing their cardholder information security program (CISP) and site data protection (SDP) standards as “The Way” that was going to stop breaches.  We explained that, properly implemented, CISP and SDP should minimize the number of PANs obtained, but it would not completely stop breaches.  It was only recently that the card brands started to realize this fact and stop pushing the PCI standards as a panacea of security.  If you have noticed with the rollout of EMV, Visa, MasterCard and the PCI SSC have stated that EMV is not a “silver bullet” solution and in other statements stated there are no “silver bullet” solutions.  That is a long way from a decade ago when their security standards were sold as the “be all to end all” for stopping breaches.  Unfortunately for QSAs everywhere, that message is out there and we have to deal with it every day.

All of this is not to say that QSAs cannot and do not make recommendations to organizations regarding their security programs and how and where it needs to improve.  I constantly make suggestions during my PCI assessments on how my client needs to improve their security posture.  However, it is ultimately up to the organization to put such changes in place, not the QSA’s responsibility.  If an organization chooses inaction, I will bring it up again and again.  But as the old proverb states, “you can lead a horse to water, but you cannot make them drink”.

Where the PCI DSS assessment process truly fails is the point in time approach (with the exception of vulnerability scanning and a few other select requirements).  To address that shortcoming, the Council has introduced the concept of business as usual (BAU) and it is my guess that we will see that concept placed into the standard in the next version.  It will be then that QSAs will have to test PCI compliance over a 12 month period similar to testing procedures financial auditors perform for annual financial audits.

As a result, the inclusion of BAU as part of the PCI DSS will likely be the straw that breaks the camel’s back for a lot of organizations.  This is because BAU will require organizations to track their compliance with the PCI DSS 24x7x365 as they should have been doing all along.  But from experience, I can tell you that there is no organization I have ever encountered that was compliant with any standard all of the time because people make mistakes.  As such, BAU is designed to shed light on those mistakes and require organizations to identify them and remediate them.  For organizations just squeaking by, this will probably make PCI compliance truly impossible to achieve.  If you are one of those organizations complaining about compliance with the current PCI DSS, just wait until BAU gets added.  Organizations that are truly interested in security are already implementing BAU because they see the operational value in integrating security controls with their other business controls.  BAU will show the true colors of those organizations that want security versus those that are checking a box.

And that gets me to Mr. Multz’s actual reason for his post, what makes a good QSA?  Good QSAs understand that the world is not perfect nor is security.  Good QSAs know that compliance with the PCI DSS does not and will not eliminate breaches.  Good QSAs know that the goal of PCI compliance is to minimize security control errors, provide an ability to recognize security control errors as soon as possible and then remediate those security control errors such that the security controls are only non-compliant for the shortest possible amount of time.

But just because a company has such errors does not automatically mean that they are not PCI compliant.  A good QSA only judges an organization non-compliant when the QSA has evidence that problems are consistently recurring and are not being corrected in a timely manner or corrected at all.

I appreciate Mr. Multz’s frustration but as a QSA I do not appreciate him tossing me under the bus with the QSAs that are doing a disservice to PCI compliance.  Like any industry, there are good service providers and there are bad service providers.  Those of us in this industry all know who the bad ones are and we hope they will get weeded out.  But from my own long experience in consulting, that does not always happen.

So in my very humble opinion, Mr. Multz needs to suck it up and deal with it, but stop tossing QSAs under the bus in the process.  QSAs are only the messengers.

19
Oct
14

The ASV Process Is Broken – Part 1

The topic of ASV scanning came up as usual at the 2014 PCI Community Meeting.  The questions all seemed to revolve around how to obtain a passing scan.  What the Council representatives suggested is that multiple scans can be put together to create a passing scan.  Unfortunately, what the Council keeps suggesting as the solution is impossible to implement and here is why.

In a typical environment, an ASV customer logs onto their account with the ASV and schedules their ASV scans of their PCI in-scope assets.  The customer may also add or subtract the number of IP addresses that are scanned as the scope of their external environment may change.  Depending on a number of factors, there may be one scan or multiple scans.  The vulnerability scans are executed on the schedule and the results are returned to the customer.

If there are false positive results or results the customer does not agree, they can apply back to the ASV to have those results removed.  If there are actual vulnerabilities, the customer can contact the ASV with how they have mitigated the vulnerabilities and the ASV can either accept those mitigates and give the customer a passing scan or allow the results to stand.

So where are the problems?

Whether or not the Council acted on facts that cheating was occurring or anecdotal evidence is unknown.  But because of the potential for cheating by customers, the Council mandated a number of years ago that ASVs lock down their scanning solutions so that customers cannot modify anything regarding testing other than the IP addresses involved.  The ASV Program Guide v2.0 on page 11, states:

“However, only an authorized ASV employee is permitted to configure any settings (for example, modify or disable any vulnerability checks, assign severity levels, alter scan parameters, etc), or modify the output of the scan.  Additionally, the ASV scan solution must not provide the ability for anyone other than an authorized ASV employee to alter or edit any reports, or reinterpret any results.”

So right off the bat, the Council’s recommendation of “putting together multiple reports” is not as easily accomplished based on their earlier directives.  That is because it will require the ASV’s customer to get the ASV to agree to put together multiple reports so that they can achieve a passing scan.  That implies that the ASV’s solution will even accommodate that request, but then the ASV needs to be agreeable to even do that task.  Based on the Council’s concerns regarding manipulation of scanning results and the threat of the Council putting ASVs in remediation, I do not believe the ASVs will be agreeable to combining reports as that would clearly be manipulating results to achieve a passing scan.

But it gets worse.  As a lot of people have experienced, they can scan one day and get a passing scan and then scan a day or even hours later and get a failing scan.  The reason this happens is that the vulnerability scanning vendors are adding vulnerabilities to their signature sets as soon as they can, sometimes even before vendors have a patch.  As a result, it is very easy to encounter different results from scan to scan including failing due to a vulnerability that does not yet have a solution or the vendor only just provided a patch.

But if that is not enough, it gets even worse.  Statistically, the odds of getting a passing scan are nearly impossible and gets even worse if you are only doing quarterly scanning.  A review of the National Vulnerability Database (NVD) shows that 94% of vulnerabilities from 2002 to 2014 have a common vulnerability scoring system (CVSS) score of 4.0 or greater.  That means that it is almost impossible to obtain a passing vulnerability scan, particularly if you are only scanning quarterly, when vulnerabilities are announced almost daily and vendors such as Microsoft are coming out monthly with patches.  Those of you scanning monthly can attest that even on a 30 day schedule, a passing scan is nearly impossible to get.

For an organization that has only one Web site, this situation is likely not a problem.  But when organizations have multiple Web sites which a lot of organizations large and small have, you are really struggling in some cases to get passing scans.

But let us add insult to injury.  A lot of organizations have their eCommerce environments running on multiple platforms such as Oracle eCommerce or IBM Websphere.  In those examples, this situation becomes a nightmare.

Platforms such as those from Oracle and IBM may run on Windows or Linux, but Oracle and IBM do not allow the customer to patch those underlying OSes as they choose.  These vendors ship quarterly, semi-annually or on some other schedule, a full update that patches not only their eCommerce frameworks, but also the underlying OS.  The vendors test the full compatibility of their updates to ensure that the update will not break their frameworks.  In today’s 24x7x365 world, these vendors can run into serious issues if eCommerce sites begin to not function due to an update.  However, that also means there is the possibility that critical patches may be left out of an update due to compatibility and stability reasons.  As a result, it is not surprising that in some updates, vulnerabilities may still be present both those that are new and those that have been around for a while.

But if Oracle and IBM are not patching on 30 day schedules, that means there is a high likelihood that the scans will not be passing.  This means that the customer must go to their ASV with compensating controls (CCW) to mitigate these vulnerabilities to obtain passing scans.

The bottom line is that the deck is stacked against an organization obtaining a passing scan.  While the Council and the card brands do not recognize this, the rest of the world sure has come to that determination.

In Part 2, I will discuss the whole ASV approach and how I believe the drive to be the cheapest has turned the ASV process into a mess.

11
Sep
14

2014 North American PCI Community Meeting

Another year has come and gone and so has another PCI Community Meeting.  There were a number of interesting events at this year’s meeting.  Some I will cover here and some I still have to digest and determine what they really mean.

Good Bye Bob

This year’s meeting is the last one for the PCI SSC’s current General Manager, Bob Russo.  Over the years, Bob has been a good sport and has been a cowboy and other characters.  This year’s community meeting was no exception.  At Wednesday night’s networking event, Bob showed up as Gene Simmons’ brother decked out in silver colored platform boots, black tights, leopard spotted top, long black hair and doing his best to show off his tongue.

A lot of us over the years have pilloried Bob for various edicts and clarifications as he was the leader of the Council.  However, if we step back, Bob got the PCI SSC off the ground and took on the thankless task of combining the disparate security standards of the five card brands and giving us the common set of standards we have today.  As well as then asking us to do our best to ensure that those standards were followed.

Even though I have been critical at times of Bob, he has always been pleasant and cheerful to me and others at the community meetings and other events where he was present.  Bob recognized that there are always some of us in the crowd that are very passionate about security and tried to assist us in channeling that passion.

Bob stated that he will be doing a “Goodbye Tour” to the other community meetings this year, so make sure to thank him for his efforts, shake his hand and say your goodbyes at whatever meeting you are able to attend.

P2PE v2

The first versions of P2PE were lambasted for being pointless and the number of solutions certified, now at six, has somewhat proven that the newest of the PCI standards needed some work.  As a result, in November 2014 we will receive version 2 of the P2PE standard.  According to people I spoke with at the meeting that have seen the new version, the new standard should be much better. Is it perfect, no. But it supposedly is a better version than the originals.

The most notable change to the standard is the approach the Council has taken.  Based on the presentation made, they seem to abandoning the complete end to end model and are moving to a component approach based on how the solution will be implemented.

But the huge change to the standard is that a certified P2PE solution can be managed by a merchant without a third party.  That is, merchants can manage the encryption keys.

It will be interesting to see just how much the standard has changed since its last iteration only a year ago.  But most of all, it will be interesting to see how the new implementation approaches will work.

SAQs

The biggest clarification to come out of the community meeting on SAQs is the Council’s and card brands’ endorsement of using multiple SAQs for documenting compliance with the PCI standard versus doing an SAQ D.

This situation occurs when a merchant has multiple payment channels such as with merchants that have retail stores using traditional card terminals (SAQ B or B-IP) and an eCommerce presence that is outsourced (SAQ A or A-EP).

The other area of discussion that seemed to cause a bit of a stir was related to Web sites that use redirects or iFrames for payment processing.  The reason for this contention is the result of claims from vendors of these sorts of payment solutions in the past that claimed that their solutions placed merchants out of scope for PCI as it related to their eCommerce operation.

Ever since the issuance of the eCommerce information supplement in January 2013 and with the recent issuance by Visa of their eCommerce guidance, the outsourcing world has been buzzing about the implications.  Merchants of course have been going back to their eCommerce outsourcers and complaining about the fact that their eCommerce is no longer out of scope.

Reliance On Other’s Work

My final comment will be related to a question I asked at the Open Forum session on Wednesday.  We have been getting push back from our larger clients on our limited use of their internal audit work, SSAE 16 reports, ISO 27K audits and similar work, if we used it at all.  The driver is that clients want to minimize the amount of disruption to their personnel by all of the audits and assessments that are occurring these days.  This prompted me to ask the question at the Open Forum as to the Council’s advice on reliance on other auditor’s work to reduce sampling.

The answer I received was, “No, absolutely not.”  Quickly followed by, “Of course, I mean other auditors, not other QSAs and PA-QSAs.”

This blunt answer apparently shocked the audience as the people on stage reacted to that shock as well.  The people onstage then backed off saying that the Council would have to take the issue back and discuss it.

After asking this question I was approached by a number of people thanking me for bringing up the topic.  The bottom line is that organizations are audited and assessed out.  Most feel like one audit/assessment ends and another one begins.  But the truly annoying thing is that there are certain portions of all of these audits/assessment that cover the same ground over and over and over again such as with physical security, access controls and end user management.  Handled properly, it would not eliminate all testing, but it would definitely reduce the amount of testing and also reduce sample sizes.

But a very telling comment came from a member of the American Institute of Certified Public Accountants (AICPA) who told me that the AICPA has repeatedly tried to meet with members of the PCI SSC to discuss the SSAE 16 standard and how it could be used to reduce a QSA’s work only to be rebuffed by the Council.

Organizations would be more willing to go through PCI assessments if work done by their internal auditors as well as outside auditors could be leveraged to simplify their lives, not complicate them.  This will only become more important as the Council pushes organizations to adopt business as usual (BAU).

If I had one important take away for the Council to work on, it would be to work with other standards bodies such as the AICPA, ISO, FFIEC and the like and work toward providing guidance to organizations on how to use internal and external audit reports.

20
Jul
14

Keeping It Simple – Part 1

Apparently, I struck a nerve with small business people trying to comply with PCI.  In an ideal world, most merchants would be filling out SAQ A, but we do not live in an ideal world.  As a result, I have collected some ideas on how merchants can make their lives easier.

Do Not Store Cardholder Data

It sounds simple, but it amazes me how many small businesses are storing cardholder data (CHD).  In most cases, it is not like they wanted to store CHD, but the people in charge just did not ask vendors that one key question, “Does your solution store cardholder data?”  If a vendor answers “Yes”, then you should continue your search for a solution that does not store CHD.

Even when the question is asked of vendors, you may not get a clear answer.  That is not necessarily because the vendor is trying to hide something, but more likely because the salespeople have never been asked this question before.  As a result, do not be surprised if the initial answer is, “I’ll have to get back to you on that.”  If you never get an answer or the answer is not clear, then you should move on to a different vendor that does provide answers to such questions.

If your organization cannot find a solution that does not store CHD, then at least you are going into a solution with your eyes open.  However, in today’s payment processing application environment, most vendors are doing all that they can to avoid storing CHD.  If the vendors you are looking at for solutions are still storing CHD, then you may need to get creative to avoid storing CHD.

That said, even merchants that only use points of interaction (POI) such as card terminals can also end up with CHD being stored.  I have encountered a number of POIs that were delivered from the processor configured such that the POI was storing full PAN.  Apparently, some processors feel it is the responsibility of the merchant to configure the POI securely even though no such instructions were provided indicating that fact.  As a result, you should contact your processor and have them walk you through the configuration of the POI to ensure that it is not storing the PAN or any other sensitive information.

Then there are the smartphone and tablet solutions from Square, Intuit and a whole host of other mobile solution providers.  While the PCI SSC has indicated that such solutions will never be considered PCI compliant, mobile POIs continue to proliferate with small businesses.  The problem with most of these solutions is when a card will not work through the swipe/dip and the CHD is manually keyed into the device.  It is at that point when the smartphone/tablet keyboard logger software captures the CHD and it will remain in the device until it is overwritten which can be three to six months down the road.  In the case of EMV, the device can capture the PIN if it is entered through the screen thanks to the built in keyboard logger.  As a result, most EMV solutions use a signature and not a PIN.  The reason Square, Intuit and the like get away with peddling these non-compliant POI solutions is that they also serve as the merchant’s acquiring bank and are accepting the risk of the merchant using a non-compliant POI.

The bottom line here is that merchants need to understand these risks and then make appropriate decisions on what risks they are will to accept in regards to the explicit or implicit storage of CHD.

Mobile Payment Processing

The key thing to know about these solutions is that the PCI Security Standards Council has publicly stated that these solutions will never be considered PCI compliant.  Yes, you heard that right; they will never be PCI compliant.  That is mostly because of the PCI PTS standard regarding the security of the point of interaction (POI) for PIN entry and the fact that smartphones and tablets have built in keyboard loggers that record everything entered into these devices.  There are secure solutions such as the Verifone PAYware line of products.  However, these products only use the mobile device as a display.  No cardholder data is allowed to be entered into the mobile device.

So why are these solutions even available if they are not PCI compliant?  It is because a number of the card brands have invested in the companies producing these solutions.  As a result, the card brands have a vested interest in allowing them to exist.  And since the companies offering the solutions are also acting as the acquiring bank for the merchant, they explicitly accept the risk that these solutions present.  That is the beauty of the PCI standards, if a merchant’s acquiring bank approves of something, then the merchant is allowed to do it.  However, very few merchants using these solutions understand the risk these solutions present to them.

First is the risk presented by the swipe/dip device.  Some of these devices encrypt the data at the swipe/dip but not all.  As a result, you should ask the organization if their swipe/dip device encrypts the information.  If it does encrypt, then even if the smartphone/tablet comes in contact with the information, it cannot read it.  If it is not encrypted, I would move on to the next mobile payments solution provider.

The second risk presented is the smartphone/tablet keyboard logger.  This feature is what allows your mobile device to guess what you want to type, what songs you like and a whole host of convenience features.  However, these keyboard loggers also remember anything typed into them such as primary account numbers (PAN), driver’s license numbers and any other sensitive information they can come into contact.  They can remember this information as long as it is not overwritten in the device’s memory.  Depending on how much memory a device has, this can be anywhere from weeks to months.  One study a few years back found that information could be found on mobile devices for as long as six months and an average of three months.

While encrypting the data at the swipe/dip will remove the risk that the keyboard logger has CHD, if you manually key the PAN into the device, then the keyboard logger will record it.  As a result, if you are having a high failure rate with swiping/dipping cards, you will have a lot of PANs contained in your device.

The bottom line is that if you ever lose your mobile device or your trade it in, you risk exposing CHD if you do not properly wipe the device.  It is not that these solutions should not be used, but the purveyors of these solutions should be more forthcoming in the risks of using such solutions so that merchants can make informed decisions beyond the cheap interchange fees.

There are more things merchants can do to keep it simple and I will discuss those topics in a future post.

26
Apr
14

Why SAQ A-EP Makes Sense

A colleague of mine attended the PCI SSC QSA Update session at the ETA convention a couple of weeks back.  One of the big discussion items was how the Council is being pilloried over SAQ A-EP.  This SAQ was developed to address the recommendations that were documented in the information supplement titled ‘PCI DSS E-commerce Guidelines’ that was published in January 2013.  Specifically, SAQ A-EP addresses the ecommerce sites that do redirects to a processor’s site that does the actual payment processing.

Based on the comments I have seen online and made in personal conversations, you would think that SAQ A-EP was heresy or a bad joke.  All of these derogatory comments are being driven by merchants that were sold a bill of goods by slick, non-PCI informed, sales people pushing redirected ecommerce solutions by claiming that it put the merchant entirely out of scope.  This was not the case and never was the case, particularly after the issuance of the information supplement.  However, we still encounter outsourcing vendors that continue to claim a redirect approach puts the merchant entirely out of scope.

To understand the rationale of SAQ A-EP we need to understand the risk surrounding these redirect solutions.  The risk is that an attacker modifies the redirect on the merchant’s server to now point to their own payment page, collects the customer’s cardholder data (CHD) on the attacker’s page and then, optionally, passes the customer on to the original payment page at the processor so the customer and merchant are none the wiser.

Under the PCI DSS and card brands’ security programs, redirect systems are still in-scope for PCI compliance because they are a key control in the payment process even though the merchant’s server issuing the redirect does not come into direct contact with CHD.

With all of that said, SAQ A-EP is not a full SAQ D, but it is not as short and simple as SAQ A either.  There are a lot of requirements to be met with SAQ A-EP which is why merchants are up in arms.  However, if you understand the aforementioned risk, you should understand why the requirements that have to be complied with in SAQ A-EP are there.

The requirement 1 requirements are all there to ensure that there is a firewall protecting the server that does the redirect.  This is Security 101 and I would doubt that any merchant would not have a firewall protecting all of their Internet facing servers.  Routers have always been optional and if the merchant does not have control of those devices, then they would not be included here.

Requirement 2 is all about making sure that all devices in the cardholder data environment (CDE) are properly configured and security hardened.  Again, this is Security 101 stuff.  If a merchant is not doing this for Internet facing devices, they are just begging to be attacked and compromised.

The requirements called out in SAQ A-EP for requirement 3 are there to confirm that the merchant is not storing cardholder data (CHD) or sensitive authentication data (SAD).  A merchant using a redirect should be marking these as Not Applicable (NA) and documenting that they do not store CHD in their system(s) because they use a redirect that processes and transmits CHD directly between their processor and their customer.  Any merchant that answers these requirements any other way should not be using SAQ A-EP.  All of that said, merchants need to have proof that they examined logs, trace files, history files, databases, etc. and did not find any CHD or SAD in those files.

Requirement 4 is provided to ensure that secure communications are used.  I would recommend documenting the SSL/TLS certificate information for your processor for the requirements in 4.1.  But do not pass over requirement 4.2.  A lot of ecommerce only merchants have call centers or take telephone calls and do order entry into the same Web site used by their customers.  As a result, merchants need to make sure that email, instant messaging, etc. are never used for communicating CHD/SAD.

Requirement 10 is important for any forensic research should the redirect be manipulated so that it can be determined when that event occurred so that the scope of any compromise can be determined.

While one would think that the vulnerability scanning and penetration testing requirements in requirement 11 would be thought of Security 101 and self-explanatory, you would be surprised at how many merchants argue about that fact.  Again, the driver of these redirect solutions was cost reduction and vulnerability scanning and penetration testing incur costs, sometimes significant costs depending on the number of servers, firewalls, load balancers, switches, etc. involved.  If you do not do vulnerability scanning and penetration testing as required, how do you know that the redirect system(s) are properly secured and patched?

However, the key requirement that cannot be missed is requirement 11.5 regarding critical file monitoring.  That is because the whole security of the redirect environment is pinned on detecting any modification of the redirect URL.  All of the other requirements in SAQ A-EP are there to minimize the risk of compromising the redirect.  11.5 is there to ensure that, if the other controls fail, at least the merchant would be alerted to the fact that the redirect had been changed.  If a modification to the redirect cannot be reliably detected by the critical file monitoring solution, then the security of the redirect cannot be assured.

The remaining requirements for 5, 6, 7, 8, 9 and 12 are all Security 101 items.  If you are not following these requirements as part of best practices for security and IT operations in general, then you need to consider what exactly you are doing.

Hopefully everyone now understands SAQ A-EP and why it is not as simple as that slick sales person implied.




December 2021
M T W T F S S
 12345
6789101112
13141516171819
20212223242526
2728293031  

Months