Author Archive for PCI Guru


We Are Getting The Band Back Together

On Friday, May 25, 2018, (GDPR Day) the PCI Dream Team will be back at BrightTalk taking all of your hardest PCI compliance questions at 10AM EDT/1400UTC for a fun hour testing the PCI knowledge of the Dream Team.

Go to BrightTalk ( to register for this session.

In the meantime, feel free to send your questions ahead of the session to pcidreamteam AT gmail DOT com.

We look forward to all of you attending our fourth gathering of the PCI Dream Team.

As with past sessions, any questions we do not get answered during the hour we will post the questions and answers here on the PCI Guru blog.


The “New” PCI DSS Is Coming Next Month

Not a surprise and really not that big a deal.

The Council announced on their blog that v3.2.1 of the PCI DSS will be released sometime next month.

No major changes just as they promised earlier this year on a QSA update call.  They will remove all of the deadline dates that have or will soon pass, they will update Appendix A2 to reflect changes in SSL and early TLS and do the requisite punctuation and spelling updates.


Audit Fatigue Is Real

I was talking with a client at a very large organization and they were lamenting about their audit processes.

“It’s like I get one auditor out of my office and another one is waiting.  All it seems I do these days is answer the same questions over and over and over again.” – Anonymous Auditee

I had to concur with their comment because I encounter this and similar comments a lot, particularly with IT personnel.

To address this, there have been a lot of schemes put together in the last few years in a vain attempt to try and reduce this audit fatigue.  These schemes would be great except for one little flaw – the scope they cover.

For PCI assessments, the scope is focused on the systems that process, store or transmit sensitive authentication data (SAD) or cardholder data (CHD).  But with most organization’s focus on segmenting PCI away from everything else to reduce scope, a PCI assessment will likely focus very narrowly on point of sale (POS) and little else.  But the PCI DSS brings a whole new level of detail to the assessment process.  Where most security standards ask if an organization has for example firewall configuration standards, the PCI DSS goes above and beyond by asking if they are implemented and followed and to prove it by reviewing samples of firewall configurations.

For Sarbanes-Oxley (SOX) audits, the scope of the audit covers systems and technology that have a material effect on the financial statements of the organization.  From what I have seen over the years, that has placed focus of the audit on the accounting systems and little else in the organization.  The result of the audit is to ensure that the information in those financial systems can be trusted to provide accurate information to the external auditors.

For HIPAA HITECH assessments, the focus is all about where patient information is processed, stored or transmitted and the security surrounding that environment.  This results on a focus on an organization’s electronic medical records (EMR) solution, health care monitoring devices and the networks that connect all of this to the hospitals and clinics.  As with PCI, most health care organizations have focused a lot on isolating their health care systems away from the rest of their systems and networks.

As a result of these differing foci, is it any wonder why some areas of the organization feel inundated with auditors and assessors?

But it gets worse.  Thanks to the certifying bodies for PCI assessors and HIPAA assessors, these people are taught to not trust any of the others’ work products.  Interestingly, accountants have a process in place to allow the reliance of others’ work product.  But given the positions of PCI and HIPAA organizations, is it any wonder that some people feel that they never get rid of auditors/assessors?

But to add insult to injury, the attempts to bring rationality to the situation have totally messed up the mapping of the various assessment processes by misinterpreting the requirements in each and then incorrectly mapping them together.  Having been involved in SOX, HIPAA and PCI assessments, I know the programs and I have found significant errors in a number of these attempts to integrate the programs.  As a result, there are a lot of people running around thinking they are doing a world of good and not realizing that they are actually doing more damage because they are missing tests and not conducting the tests to the proper level of detail.  So, is it any wonder why the PCI and HIPAA organizations do not trust the results of others?

Ultimately the problem of audit fatigue persists and is still not being addressed.  So here are my thoughts and a possible solution.

  • All security standards focus on certain common control subjects such as change management, software development, device configuration standards/procedures, user management and other common controls. Audit/assessment planning will define the common control environment and all auditors/assessors will approve the common environment.
  • The audit/assessment will use the lowest common denominator for testing (likely the PCI DSS), merge any special control tests from any other work programs and have that new, consolidated work program conducted for the entire common environment. This will ensure that the entire environment is properly assessed to the right level of detail by the right number of controls that all other auditors/assessors can reference.  The auditors/assessors will agree to the work program to be conducted.
  • Any auditor/assessor is welcome to participate in the common assessment process.
  • Sampling of anything is done to the AICPA’s haphazard sampling methodology.
  • The audit/assessment will follow the AICPA principles outlined in AT section 101 as it pertains to non-financial audits. This will likely result in larger sampling as well as sampling done over a period of time (usually 12 months).
  • The auditors/assessors are responsible for reporting the results of this common audit/assessment approach in their specific reporting formats.
  • Evidence will be retained by all auditors/assessors involved unless that violates the client’s security or privacy policies/standards. Then the client will be required to comply with the various audit/assessment work paper retention and standards bodies review requirements.

With the common areas assessed, the auditors/assessors would be free to conduct the rest of their work programs as necessary covering their specific scope.

This is the only rational way I see this issue of audit fatigue getting addressed.


There Is No Such Thing As PCI “Magic”

It still amazes me the amount of effort some people and organizations expend in vain and silly attempts to “avoid” PCI compliance.  But an entire industry has popped up that claims to have just such “magical” solutions.

First and foremost is the fact that when your organization signed the merchant agreement to accept payment cards with your acquiring bank, you agreed to comply with the PCI DSS.  Unless your organization is willing to stop accepting payment cards, you are stuck with complying with the PCI DSS.

What you can do though is implement solutions that minimize your PCI scope and therefore simplify your PCI compliance efforts.  For those of you that need to cut to the chase, here are the ONLY solutions that minimize your PCI scope.

  • If you operate a brick and mortar retail store, implement a point-to-point encryption (P2PE) validated solution or end-to-end encryption (E2EE) solution – both with tokenization. Do NOT enter primary account number (PAN) and sensitive authentication data (SAD) through anything other than the P2PE/E2EE terminal.  This will reduce your scope to those requirements in SAQ P2PE.
  • If you conduct mail order and/or telephone order (MOTO), use a P2PE/E2EE solution with tokenization. Do NOT enter PAN and SAD through anything other than the P2PE/E2EE terminal.  This will reduce your scope to those requirements in SAQ P2PE.
  • If you have an eCommerce Web site, use a redirect solution such as PayPal or an iFrame solution from a transaction processor such as those available from Vantiv, Elavon or TrustCommerce with tokenization. Implementing either of these solutions will reduce your scope to the requirements in SAQ A.
  • If you need to do recurring transactions, do not store card information at all. Have your transaction processor send back reusable tokens instead when a customer puts a card on file.  Your processor can also likely provide you with a service to automatically update card expiration dates and card validation codes for a fee and save you from badgering customers to update their payment card accounts every three to four years.  How much this approach reduces your scope will depend on your organization’s payment channels such as eCommerce, MOTO, or brick and mortar retail.

There are no other ways to minimize PCI scope other than these.  For those that are interested, the absolute minimum PCI scope any organization can achieve are the requirements documented in SAQ A (i.e., a merchant with ONLY an eCommerce site using a redirect or iFrame).  There is nothing less.  Period.  Anyone that tells you otherwise does not know what they are talking about.

An important caveat on this discussion.  The more payment channels your organization uses, the less scope reduction you get.  For example, if your organization operates brick and mortar stores and also has an eCommerce site, you will have to comply with the requirements in both SAQ A AND SAQ P2PE if you follow my advice.  So keep that in mind as you evaluate and implement these solutions.

Yet time and again, I encounter organizations spending lots and lots of time, effort and money on all sorts of “magical” PCI compliant solutions sold by “snake oil” salespeople praying on the PCI uninitiated.  They promise all sorts of “magic” that will reduce PCI scope or, worst of all, remove your organization from PCI scope.  None of them deliver and people are deeply disappointed when they finally contact a QSA (or worse, their bank calls out the solution) and they find out that the money spent was all in vain and did not actually reduce or remove them from scope like they were promised.

Adding insult to injury is the fact that if the merchant had truly understood the solution and the PCI compliance process, it was all documented in the vendor’s contract as to how much scope reduction would actually be delivered (i.e., not a lot).

Stop spending so much time and money on Rube Goldberg solutions.  In the end, they are typically costly, complicated and likely do not reduce scope any better than the solutions outlined above.

The bottom line here is, if it sounds too good to be true, it likely is.


When A Client Refuses To Provide Evidence

As a QSA there are occasions when a client tells you that you cannot be allowed to have copies of evidence.  The most common occurrence is with firewall and intrusion detection/prevention configurations.  But there are odd instances as well for things like software development lifecycle documentation and information security policies where it makes no sense.

As a “recovering” penetration tester, I get some of these requests.  I once got into a financial institution because their network engineer wanted advice on their firewall configuration and posted the configuration on a forum for people to provide advice.  So, people are right to be concerned.  That said, qualified security assessor companies (QSAC) are required to provide a secured storage area for storing client evidence, so it’s not like evidence is stored just anywhere.

To be clear, a QSA is required to obtain evidence that supports their assessment of the PCI DSS requirements.  The reason is for the PCI SSC’s assessor quality management (AQM) process.  The Council has the right to review not only the redacted Report On Compliance (ROC) and Attestation Of Compliance (AOC), but also the evidence that supports the ROC.  This has always been the case under the AQM process, but it has only been recently that the Council has started exercising that right and reviewing samples of evidence.

Regardless of all of these precautions and requirements, there are still those times when a client refuses to provide copies of the evidence.  What is a QSA to do?

The Council has provided QSAs with an option when this situation happens, it sounds simple, but is not always as simple as it appears.

When a client refuses the QSA to leave with the necessary evidence, the QSA must then require the client to securely store the evidence reviewed for a maximum of three years and agree to make that evidence available if the Council pulls their ROC for review under the QSAC’s AQM.

The key to this solution is that they client must store exactly what the QSA reviewed for a period of three years.  In the case of a firewall configuration, the client needs to create a human readable file (i.e., text, PDF, screen shots, etc.) and then store that file securely either on their network, a CD/DVD or even a USB thumb drive.  A lot of clients create an encrypted archive for storing this information which is a very good idea.  I have heard of a few situations where the client misplaced the archive resulting in a finding against the QSAC for not being able to provide the evidence to the PCI SSC for review.

This evidence solution is likely outside of the original contract with the QSA.  As a result, the QSA will have to make an addendum to their original agreement to cover this situation.  Expect a bit of legal work to come up with getting such an agreement and getting the client to agree with it.

But suppose the client refuses the conditions of the addendum.  What then?

This is where the client’s acquiring bank comes into the picture.  A client’s acquiring bank is required to arbitrate such disputes between QSAs and their client.  Whatever the acquiring bank decides, the QSA needs to make sure that they get the decision in writing (e.g., email, letter, etc.) and put that decision in with the rest of their evidence.  A QSA should also write up a brief memo to provide the background of the situation so that anyone going back and reviewing the evidence understands what happened and therefore has some context as to why the bank issued their decision.

There you have it.  Another situation addressed.


Can Every Requirement Be Met With A Compensating Control?

“In theory, theory works.” – Jeff Hall

Some years back, the PCI SSC came out at the Community Meeting and stated that every PCI DSS requirement could be addressed by a compensating control worksheet (CCW).  A rather broad statement but it started a bunch of us in the PCI community thinking, “Is that really the case?”

Before reading this post, I highly recommend reading my post on writing CCWs so that you can fully appreciate why not every requirement can be met by a CCW.

That said, it turns out that there are a lot of requirements where there is no way to develop a CCW.  Here are just a few examples.

1.1.2 – Network Diagram(s) and 1.1.3 – Data Flow Diagram(s)

What would be the mitigating controls here?  There are none because diagrams are diagrams.  There is nothing you can do to compensate for these missing other than provide them.

1.1.6 – Firewall Rules

As with 1.1.2 and 1.1.3, what could possibly serve as a mitigating control?  If the firewall rules are not able to be reviewed, there is nothing you can rely upon to go above and beyond the control.

I have had people suggest that the QSA could rely on Nmap and vulnerability scans of the firewalls.  But that does not necessarily confirm all of the ports/services that are configured for the firewall nor does it necessarily confirm that the devices using those ports are the same ones that are in scope for PCI compliance.

1.2.3 – Wireless Networking

QSAs have repeatedly been told that this requirement can never be marked as ‘Not Applicable’.  The QSA is required to respond to how they confirmed at wireless was either in or out of scope.  But can you create a CCW for these requirements?

The controls that you need to assess to meet these requirements are the same controls you have to use in the CCW for mitigation.  So, if you have to document and evaluate the controls regardless, why would you bother to write a CCW?  You would not.  You would document and meet the requirements and move on.

3.2 – No Storage of SAD

This is the requirement that started the whole CCW debate.  When the PCI DSS was originally issued, QSAs were trained that this requirement could NEVER, EVER have a compensating control.  But that changed when the Council issued their proclamation a few years back.  But is that really the case?

Remember, a CCW must go above and beyond the intent of the original requirement.  3.2 also states in a note that SAD cannot be stored even if encrypted.  Encryption would be the only mitigating control available to an organization that wants to store SAD.  So what replaces encryption if that cannot be used?  Tokenization by a third party would be an option, but if you go that route, you are not storing the SAD, so the discussion becomes moot.

8.3 – Multifactor Authentication

Some form of multifactor authentication (MFA) is required for non-console administrative access to cardholder data environment (CDE) systems and remote access to an in-scope network.  Since the Council has clearly defined MFA and also knocked down multiple logons with different credentials, what is left?  In the end, there is no way around meeting this requirement other than doing what the requirement states.

10.1 – 10.3 and 10.6 – Log Data

Here is another example of where there really is no way to write a CCW.  You are either gathering log data (centrally or on individual systems) or you are not.  You are either reviewing the log data daily or you are not.  Then there is the requirement of sending log data from internet facing devices to an internal device.  No matter how creative you think you are, there are no controls that will mitigate this situation and also go above and beyond.

As I said at the beginning of this post, these are just some of the examples where a CCW is just not going to make it.  So, the next time you think about meeting a PCI DSS requirement by using a CCW, make sure you understand the requirement and that there are controls that will mitigate the risk and go above and beyond the original intent of the requirement.  You will save yourself and your QSA a lot of time and consternation.


Pre-Authorization And Post-Authorization (Part 2)

I discussed the concept of pre-authorization in a prior post.  Now it is time to cover post-authorization (aka “post-auth”) and the PCI requirements it drives.  Post-authorization is where the PCI DSS got started even though pre-authorization was always present.  That is because it was in post-authorization where merchants were losing cardholder data (CHD).  While this post is mostly about post-authorization, it still contains some important references and points about pre-authorization.


First, let us define what we mean by “post-authorization”.  Post-authorization starts immediately once a transaction has been processed and the payment has either been authorized or declined.  It is at this point that only the cardholder name, PAN (encrypted or tokenized) and expiration date are allowed to be stored in any post-authorization systems.

On page 8 of the PCI DSS, the PCI SSC provides an excellent chart on what can be retained and what must not be retained in post-authorization.

Post Auth PCI DSS Chart

However, this chart also creates confusion regarding pre-authorization and post-authorization because it is not labeled as such and that the discussion on this topic occurs after the chart, not before it.  The following is from the second paragraph following the chart and is usually missed.

“Sensitive authentication data must not be stored after authorization, even if encrypted. This applies even where there is no PAN in the environment. Organizations should contact their acquirer or the individual payment brands directly to understand whether SAD is permitted to be stored prior to authorization, for how long, and any related usage and protection requirements.”

The first sentence makes it very clear that SAD must never be stored post-authorization.  The second sentence is to ensure that those entities that tokenize/encrypt the PAN do not think they can store SAD because they technically no longer have the PAN (believe it or not, people do think this is true and then claim it as such).  The last sentence was added to tell merchants to discuss with their acquiring bank whether or not they can store SAD as pre-authorization data.  While technically the merchant should have explicit approval from their acquirer for storing pre-authorization data, I can tell you from experience that very, very few merchants have such evidence.  Not so much because they did not ask (most do not), but even more so because acquiring banks do not recognize their responsibility for providing such approval and therefore are reluctant to provide it.

From a post-authorization perspective, any merchant that is storing SAD in a point of sale (POS) solution as pre-authorization data needs to have a secure delete or destruction process in place to remove the pre-authorization data once the card transaction completes (approval or decline).  But a very important point is that pre-authorization data stored for customer convenience in pre-authorization applications is not affected by this change in status.

For the fuel station example in the pre-authorization discussion, the POS system that is storing the encrypted SAD/CHD while you pump the fuel needs to securely delete that information when you complete pumping and the payment is processed.  In some cases, when you swiped your card at the pump, the system not only did the pre-authorization of your payment, but it also may have tokenized your PAN and now is holding that token, not the SAD/CHD.

To continue on with our hotel example.  The hospitality management system is going to pre-authorize payment and then either encrypt the PAN on that initial swipe/dip at check in or it may tokenize it for storage.  At check out, the PAN is either decrypted or the token is submitted for payment.

Most phone orders have the CHD directly entered into systems no different from any consumer buying something over the internet.  In fact, for a lot of call centers, the order is actually entered into the same Web-site that consumers use.  After all, why reinvent the wheel?

However, with telephone orders, there are going to be rare instances where systems are not available.  In those cases, merchants can take a couple of approaches.  During such an outage, I have clients that do not accept orders.  They tell their customers to call back later when systems are operational.  I have other clients that will take the order on a paper form in the name of customer service.  The forms are securely collected and stored until systems are back online.  The forms are then entered into the system(s) and then the people follow secure destruction procedures of the forms.  The important lesson is that either approach can be used depending on your organization’s customer service desires.  The only issue is ensuring security of the information if you choose the manual form approach.

For facsimile and mail order examples we definitely have the issue of the SAD/CHD existing on paper.  So you need to do something to secure that SAD/CHD once the form has been processed.  For facsimiles, the PCI DSS requires a secure facsimile solution be used.  The simplest way is to have a dedicated facsimile machine that is only used for receipt of orders.  This facsimile machine needs to be placed in a locked room or a locked cabinet so that only authorized personnel can access the facsimiles that come to that machine.

On the more automated side, I have seen simple solutions that utilize an outsourced facsimile solution through a secure gateway.  Customer service personnel can only view and print out the facsimiles to process them.  I have other clients that have sophisticated solutions that start out similar to the secure gateway, but the gateway delivers the facsimiles to secure printing solutions that allow the customer service person to use any printer on the network because they can only print after physically going to a printer and tapping their facility access card against a reader connected to the printer thus securing the output until the user is ready to print it.

In the case of mail orders, those require securing the mail upon receipt in the mail room from the post office.  The orders should be secured until they are picked up by customer service personnel or whomever in the organization is responsible for processing mail orders.  Only a limited number of customer service personnel should be allowed to pick up the mail at the mail room to take to the area for processing.  When picking up the mail, the person picking up should sign a log indicating that the mail was picked up, when it was picked up and by whom.  Once taken back to the processing area, the mail needs to be secured there until it is processed.

The easiest approach is what I call “Sharpie redaction”.  That involves using a black ink permanent marker (i.e., a Sharpie marker) and redacting the PAN to the last four digits, blacking out the three- or four-digit card verification code (if provided), copying the redacted form so that the redacted information cannot be read, filing away the copied form and destroying the original by shredding it.

To avoid the “Sharpie” approach, merchants are modifying their mail order and facsimile forms so that the portion containing the SAD/CHD are either at the top or bottom of the form and can therefore be torn off and securely shredded leaving the rest of the form able to be retained without the SAD/CHD.

These are all just examples.  There are many more ways that can also work.  But I prefer simple methods as that is always the easiest to implement and follow.

The bottom line is that, regardless of pre-auth or post-auth, the data needs to be kept secure and the processes used to secure it need to work in your organization consistently and effectively.


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.


May 2018
« Apr    

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

Join 1,964 other followers