Archive for the 'PCI DSS' Category


PCI Compliance And Financial Institutions

I remember being at one of the early PCI Community Meetings and someone from the PCI SSC promised that the PCI DSS would be periodically updated to reflect changing business conditions as well as changing threats.  Here we are more than a decade later, and we have version 3.2 of the DSS, but it has been changed more for changes in threats and very little for business.

Their rationale was that they wanted to minimize the number of compensating control worksheets (CCW) that would be needed for the majority of organizations.  This was in response to v1 of the PCI DSS that required that data encryption keys change annually.  Most large merchants who were participating organizations (PO) complained that it was taking six months to a year or more to encrypt their transaction databases and files.  Requiring annual key changes would leave those databases and files at risk because they would always be in a state of perpetual decryption/encryption.  As a result, almost everyone had a CCW for that requirement.  So, the Council changed the requirement to require the changing of encryption keys when they were believed to be compromised or if one or more persons who know the keys leave the company or change roles.

The reason I bring this up is that I have been dealing with financial institutions and their PCI compliance issues for the last few years.  If there is anything more frustrating, it is trying to apply a standard written for merchants to organizations that are not merchants.  It seems like every time I turn around; a requirement needs a CCW, particularly when concerning requirement 3.4.

I am sure the Council will point to requirement 3.2 as their token change that took into account issuers.  But that does nothing for the other requirements that financial institutions struggle.  The biggest reason a lot of the PCI requirements are a struggle is that financial institutions are in the business of; surprise, surprise; processing, storing and transmitting cardholder data.  That IS their business.  3.2 was a great change for issuers, but a lot of the rest of the PCI DSS is a huge pain for a financial institution without a lot of CCWs and the blessings of the requisite card brand(s).

Let us look at a few requirements where CCWs are needed when assessing an FI.

3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) – this can be very problematic for financial institutions.  The reason is that while they can encrypt or tokenize the data, they also need to decrypt/detokenize it as well.  In a lot of cases, they need to do those operations quickly and very often.  It is not that the FIs do not want to protect the information, it is just that they have some unique issues in meeting PCI requirements.

The best example of this situation is debit cards.  Debit cards must be tied to a demand deposit account (DDA) such as a checking or savings account.  That means somewhere there must be a mapping of the debit card into the core application system.  But to process transactions from the card networks when customers use their cards, the PAN must be decrypted/de-tokenized so that the payment can be approved or declined.  This decryption/de-tokenization process needs to meet a timing standard, so adding to the processing time is usually not an option.  As a result, it is not unusual to find that the PAN to DDA mapping file is not encrypted or tokenized.

6.4.3 Production data (live PANs) are not used for testing or development – when part of your business is all about processing, storing and transmitting sensitive authentication data (SAD) and/or cardholder data (CHD), using a few card brand test accounts like a merchant would use for testing is not going to work.  Particularly when you are testing with one of the card brands to certify your application.  In those instances, the FI and brands are going to demand the use of a large and varied set of PANs to ensure that systems are functioning properly.  The only way to do that is with live data from production.

3.2.1 Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere) after authorization

3.2.2 Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card used to verify card-not-present transactions) after authorization

3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block after authorization.  – requirement 3.2 addresses that issuers that have a business reason to retain sensitive authentication data (SAD) can retain it.  However, 3.2.1, 3.2.2 and 3.2.3 say that all of this data cannot be stored right after authorization. These requirements then go on to say the QSA must inspect incoming transaction data, log data, databases, etc.  Well, guess what?  The incoming transaction data always has SAD in it of some form because the FI has to authorize the transaction.  As I said earlier, databases can have it because of the speed required to authorize.  This is the FIs’ business, yet the standard does not recognize this fact.

The bottom line is that the PCI DSS does not reflect the realities of financial institutions.  As a result, FIs require numerous CCWs to meet the PCI DSS requirements.  As I stated at the beginning, the Council promised that they would address such issues to make CCWs the exception not the rule.  Well, here we are, and in the FI world CCWs are commonplace.  And as we move forward, it will be FIs that will be the focus of the standard, not merchants.  Merchants will very soon be out of the payment card data business altogether with the exception of their POI.  So, it only makes sense to adapt the PCI DSS to securing FIs.

We have separate PCI DSS and AOC documents for service providers.  Maybe we need separate such documents in addition to revised requirements for financial institutions?

Seems like a good discussion topic to bring up at the upcoming Community Meeting.


Why Voice Over IP Matters

“Voice over IP are the most insidious set of communication protocols ever invented by man.” – Jeff Hall

I have been having some interesting conversations of late with prospects and clients regarding Voice over IP (VoIP).  These conversations all seem to revolve around whether or not VoIP is in scope for PCI compliance.  Ultimately the conversation turns to a discussion of why I believe VoIP is in scope for PCI and almost every other QSA seems to never bring the subject up.

The primary reason I believe VoIP is in scope is that the PCI SSC says so.  If you read FAQ #1153 titled ‘Is VoIP in scope for PCI DSS?’ the Council makes it painfully clear that VoIP is definitely in scope if VoIP transmits sensitive authentication (SAD) or cardholder data (CHD).  If you doubt it, here is the exact quote from the first paragraph of that FAQ.

“While PCI DSS does not explicitly reference the use of VoIP, VoIP traffic that contains cardholder data is in scope for applicable PCI DSS controls, in the same way that other IP network traffic containing cardholder data would be.”

Yet even when it is stated that clearly, I still run into people that claim I am making a mountain out of a mole hill and their VoIP is not a risk because other QSAs have never inquired about it.  What that merely means is that other QSAs are ignoring it when they should not be ignoring it.

The first problem with VoIP seems to be that very few people understand it which is the biggest reason in my opinion that a lot of QSAs avoid the discussion.  But it is not just QSAs.  I speak with network administrators, information security personnel and other technology people all of the time and if there is one topic that will glaze over all of their eyes, it is VoIP.  When the discussion turns to VoIP, people seem to hark back to that old PBX system tucked away in the basement or closet.  No one seems to remember that the PBX did get updates (usually two or three a year).  All anyone remembers is that it just worked and that it got replaced once, maybe twice, in a generation.  And the biggest risk was toll fraud from the Caribbean.

But scarier yet is that these people do not seem to completely understand how VoIP and its protocols work let alone the risks.  The biggest problem with VoIP are the protocols used and the reason for my quote at the start of this post.  Regardless of whether you are talking SIP, H.323, H.248, whatever, they all operate the same.  Call set up (start of a call) and call tear down (end of a call) are the only points of a VoIP telephone conversation that are stateful, i.e., conducted via TCP.  The actual call itself is all done via streaming UDP just like any other audio/video stream.  Adding insult to injury, VoIP also requires a large number of the ephemeral UDP ports above 32767 to be open.  UDP, being what it is, provides one of the best transport mechanisms for delivering malware.  There are hundreds of exploits for VoIP from the most benign DDoS attack to turning a VoIP telephone into a spying device by surreptitiously enabling its microphone and video camera (if it has a camera).  But my personal favorites are the attacks that use the VoIP network as an entry point into an organization’s data network.  The bottom line is that the only way to firewall any of the VoIP protocols for actual protection is to keep them away from the rest of your network.

But it can and does get worse.  Add in VoIP trunks from your telephone carrier and you really begin to have a recipe for disaster.  When you have VoIP trunks from your carrier, your internal VoIP network is really only protected from every other VoIP network by the carrier and your call managers.  It is that sad fact that keeps a lot of information security professionals up at night.  If security is all about your weakest link, how do you protect yourself and minimize your risk when your weakest link is essentially the entire world’s phone systems?

Let us add insult to injury in this tale of woe and bring in the concept of unified communications and its primary tool, the softphone.  A softphone is software that turns a PC into a telephone using VoIP. All users need is the internet and a VPN connection to the office network and they have their office telephone right there no matter where they are in the world.  However, the softphone opens up that PC to the same risks that exist for every other phone using that call manager.  But if your VoIP system is used to take calls that discuss cardholder data (CHD), you have now turned that PC with a smartphone into a Category 1, in-scope device because it is now connected to a Category 1, in-scope system and network.  Suddenly all of that effort to achieve PCI scope reduction flies right out of the window.

But this all gets the more fascinating as people go back to their VoIP vendors and find out even more troubling issues with their VoIP solutions.  I remember numerous conversations where people thought once a call was connected to a phone that a call manager was no longer involved therefore the call managers could be put on a different network segment, only to find out that call managers act as bridges when calls are conferenced, involve telepresence or they are to/from outside lines.  They also find out that with the advent of unified communications, services such as instant messaging and email integration are no longer separate servers/functions from the call manager and cannot be easily segmented from the call managers to take them out of scope.

But then there is the revised draft version of the VoIP information supplement from the PCI SSC.  Great guidance if you have a call center.  Worthless for any other sort of implementation of VoIP.  It treats VoIP as a discrete operation as though only the call center model exists for VoIP implementations.  Granted call centers are the largest risk when they are in scope because their call volume is typically 80%+ of calls involving payments.  But all sorts of organizations take payment information over the phone but are not a call center model.

So, what about the organization that has call centers and also normal business people all on the same system?  Based on the information supplement, every phone is a Category 1 device unless the call center VoIP system is separate from the rest of the organization.

Must the call center be on a separate VoIP system from the other users?  It would appear to be that way to manage scope.  But again, there is no explicit guidance for any other implementation model other than a call center.

And if the other users take overflow calls from the call center or occasional calls dealing with PAN, how would separate systems help with that situation?  Near as I can tell, it does not help.

And what about unified communication solutions?  No idea as the information supplement does not reference a unified communication solutions.  However, given the whole premise of unified communications is that it is tightly integrated in most VoIP solutions, other communication methods such as instant messaging and telepresence would likely be in scope as well for PCI compliance.

The bottom line is that the advice I provided over six years ago in this blog is still accurate today.


NESA – Guidance In Search Of A Problem

On Thursday, June 29, the PCI SSC held their quarterly Assessor update webinar.  One of the more interesting discussions was on the topic of the non-listed encryption solution assessment or NESA.

For those unfamiliar with NESA, it is an attempt by the Council to have all end-to-end encryption (E2EE) solutions such as First Data’s TransArmor and Verifone’s Verishield assessed against the relevant PCI P2PE standards to ensure they are secure.  The problem is that the card brands and the banks have not gotten behind the NESA approach so it has effectively stalled out much like the P2PE program has stalled out.  But on the Thursday webinar we found out that it has really stalled out and the Council seems to be getting desperate to salvage it.

The goals of NESA are:

  • The Council reiterated that the NESA requires that a P2PE-QSA is required to conduct the assessment using the PCI P2PE assessment programs as guidance. Essentially, the NESA is a P2PE validation without the Council’s certification and listing of the solution on the Council’s Web site.
  • NESA provides a consistent approach to evaluating non-listed encryption solutions against “best practices”.
  • It provides other PCI assessors, acquiring banks and merchants with information about the risk and PCI DSS responsibilities when using a non-listed encryption solution.
  • It provides input to a merchant’s QSA to consider when conducting the merchant’s PCI assessment.

All of these are admirable goals of the NESA.  But the question still remains, do we need the NESA?

According to the Council a lot of people in the “payments community” have been clamoring for NESA.  I am not sure exactly who the Council is referring to as the “payments community” but it certainly has not been the banks or the brands.  Those two constituencies are already partnered up with E2EE and P2PE solutions and have not been clamoring for anything other than to use those solutions.

The Council did bring up the organizations behind the solutions already listed as P2PE validated.  That would make sense as they have a vested interest in forcing non-listed encryption solutions through the process.  But as to banks, the brands and QSAs pushing this agenda?  I would seriously doubt it.

Then there is the issue that the Council says that QSAs are stumped when they encounter an E2EE solution.  The process of assessing E2EE solutions has been known by QSAs since E2EE solutions were rolled out years ago by the various vendors.  But with the introduction of P2PE, I would bet that the Council’s QSA/ISA training does not cover how to handle E2EE solutions.  And I am sure since the invention of the NESA process, they have even more reasons not to instruct QSAs on how to assess an E2EE solution.  Yet I am sure that they still discuss how to assess an application that is not PA-DSS validated.  That is a “shame on them” for ignoring the realities of the real world.

But the process is not that involved.  When encountering an E2EE solution, the QSA needs to ensure that the E2EE solution is implemented according to its implementation guide (IG).  A transaction processor/gateway or an acquiring bank may also require packet captures to ensure that the data stream is encrypted.  All of that assessment and testing documentation is submitted to the acquiring bank and the bank explicitly grants the merchant scope reduction.  Then the QSA can follow the requirements in SAQ P2PE for an assessment.  All of which adds probably two hours to a merchant’s PCI assessment versus the costs of a full on P2PE assessment.  When looking at the costs of a P2PE assessment plus the listing fees to have the solution placed on the Council’s Web site, is there any wonder a lot of E2EE solution providers have eschewed the P2PE program.

First Data and Verifone have been adamant since P2PE was introduced that they will never go through P2PE because it is not needed.  Given they are partnered with most of the large processors and banks, their lack of support for P2PE means a lot and also means that until they get on board with either NESA or P2PE, both of these standards are in trouble.

But the most troubling comments occurred at the end of the Council’s brief discussion of NESA.

  • NESA is NOT a program. It is only “guidance”.
  • NESA may not result in scope reduction.
  • There is no formal NESA documentation or template.

When the Council says that something is “guidance”, there is no mandate for anyone to do anything.  This is how QSAs are to treat those Information Supplements published periodically by the Council.  In this case, NESA is only a suggestion.  So, until the brands and banks get behind the NESA process, there is no reason to have a NESA performed.

The next two comments go together.  If there is no formal deliverable for QSAs to review, how does a QSA evaluate that any NESA process was conducted adequately?  And if that is the case, of course the granting of scope reduction is not likely.  After all, if a QSA is not sure about the NESA, how is the bank supposed to evaluate it let alone pay for it.  And if scope reduction is not achieved, then what in the world is the point of NESA in the first place?  The only purpose I can see is to give P2PE QSACs an ability to push their services on the E2EE solution vendors to make their services worth the cost incurred with the Council.

The only other benefit that I can see is an opportunity for certain P2PE-QSACs to flood us all with NESA Certificates since their PCI Compliance certificates are worthless.

But in the end, you really start to wonder what the Council was thinking when they put this process together.  Time will tell, but I am guessing and hoping that NESA, like P2PE, will die a quick and quiet death.


We Need A Change To 2.3.b

I just wanted to give everyone a “heads up” about some guidance we recently received from the PCI SSC regarding jump boxes or out-of-band (OOB) system management solutions and the use of insecure protocols such as SNMPv1/2 and Telnet.

But did everyone know that this solution also requires a compensating control worksheet (CCW)?

For years (at least since the Phoenix Community Meeting years ago), the Council has been recommending the use of firewalls and jump boxes as a way to secure instances where organizations need to use insecure protocols.  These enclaves are firewalled, VLAN’d and configured so that only the jump box can be used to remotely connect to the devices over Telnet and allowing other insecure protocols to be kept away from other networks.  However, I do not recall any of those discussions ever explicitly calling out the need for a CCW.  I suppose the Council just figured we would all be bright enough to write one up.

What led me to this revelation you ask?

When I was going through my QSA Requalification this spring, they had a scenario with a jump box solution.  One of the questions related to the scenario involved how you would create a CCW for the insecure protocols used in the administrative VLAN that the jump box provided access.  While I answered the questions correctly, it triggered a new question regarding why a CCW was needed in the first place.

Then when the question was posed back to the Council, we got a reply indicating that a CCW would be required because of requirement 2.3.b which states:

“Review services and parameter files on systems to determine that Telnet and other insecure remote-login commands are not available for non-console access.”

The problem with the requirement is that it treats all Telnet with equal distain regardless of risk.  Yes, Telnet is always a clear text protocol, but when it is buried two or three layers away from any general network or the internet and requires administrator credentials and MFA, it is hardly as “at risk” as it would be when PCI started over 15 years ago and networks were as flat as a piece of paper.

As a result, I would like to recommend that the Council work to change 2.3.b to take into account the use of network segmentation, firewalls, VLANs, ACLs, MFA and jump boxes to allow the use of Telnet and insecure protocols when in a properly isolated and secure environment.  It seems silly to me that someone goes through all of the right steps to secure their environment only to be told that they still need a compensating controls to meet a requirement that does not reflect the real risk.

The other reason I feel this needs to be addressed is that a lot of banks and processors seem to see CCWs as a huge red flag.  Something to be avoided at all costs because it implies to them non-compliance.  And non-compliance is a “bad” thing.  I cannot tell you the collective hand wringing some banks go through for really simple CCWs all because they do not want to have any PCI assessments with CCWs.

Ultimately I think this all comes down to the fact that those banks and processors have no clue as to the amount of risk any CCW presents.  This is because most banks and processors staff their PCI compliance areas with auditors and compliance professionals, not technicians.  Given that the PCI DSS is predominately all about security technology and its implementation, these auditors and compliance people are not equipped to make the decisions that typically need to be made regarding CCWs.  As a result, they are all high risk in their eyes and treated accordingly.

Hopefully the Council can address this situation and we can avoid needless documentation for a preferred “best practice”.


Answering Some Dream Team Questions

After our PCI Dream Team event on May 17, I thought I would take some questions that do not require long and involved answers and publish them in this post.  FYI – I have edited and spell checked these, so they likely do not look like you entered them but they should convey your questions as you asked them.  Hopefully I answered on of your questions.

Q: Does anything special need to be done with the use of Virtual Terminals?  We use the virtual terminals to manually enter credit cards from time to time.  The computers used are normal user computers with the basic security done, but I have been wondering if they need to have extra limitations or security put in?

A: There are a lot of solutions that imply they take the workstation/terminal out of scope or magically reduce scope when using virtual desktop (VDI) solutions.  None of it is true.  If a device is used to enter PAN (regardless of HOW), it is a Category 1 device because it is used to enter PAN.  The bottom line is that any device used to enter PAN is in-scope for full PCI compliance.  There is no “magic” to change that fact.

Q: Do all POI devices have a keypad? I’m thinking of PC’s with integrated MCR’s – will those all change to separate POI’s with a keypad?

A: All point of interaction (POI), aka card terminals, that are customer facing have a keypad because they need to be able to accept PIN entry.  Merchants that are going to P2PE/E2EE solutions end up with a separate POI that is connected to the POS PC/terminal via USB so that the POS solution can communicate the total price of the sale as well as to know if the transaction is approved or declined.  The POI securely communicates with the transaction processor over Ethernet or using the USB connection and the Ethernet connection of the POS PC.  In both cases, the POS PC never has access to the sensitive authentication data (SAD)/cardholder data (CHD) as it is encrypted at the POI.  However is using an E2EE solution, the QSA will need to validate that the E2EE solution to ensure that they do in fact encrypt at the POI and therefore the POS PC/terminal is out of scope.  In addition, the merchant will have to contact their acquiring bank to get formal approval that the E2EE solution gives scope reduction for the merchant.  This will likely require the QSA to provide their evidence and assessment procedures to the acquiring bank for that approval.

Q: Are administrator workstations always in scope for PCI DSS regardless if an administrator is connecting to CDE servers via jump box?

A: Yes, because they are “connected to” systems when they access the jump box.  They may not be entering cardholder data (CHD), but they likely can access it or influence its processing/transmission because they are administrators.  That said, I would treat them in the Open PCI Scoping Toolkit vernacular as a Category 2x system.  That means they can probably avoid the bulk of PCI requirements but, at a minimum, need to be properly security hardened, kept updated, have anti-virus/anti-malware and are monitored “periodically”.  And as a reminder, administrators will need to use multi-factor authentication (MFA) after January 31, 2018 when accessing the cardholder data environment (CDE).

Q: Are you having/forcing your clients to follow the December scoping guidance, and are you bringing administrator workstations into scope?

A: I guess I am curious as to when anyone would have thought that administrator workstations ever were out of scope?  Nothing has changed in that regard as they were always in scope for PCI compliance.

Q: Are “crash kits” in restaurants for use when the system is down in scope for compliance?

A: The kits themselves are not in scope, but when they get used, the forms that get generated which contain the embossed image or handwritten PAN and other sensitive authentication data (SAD)/cardholder data (CHD) place those forms in scope for PCI compliance.  They therefore need to be securely stored, securely transmitted and subsequently securely destroyed in accordance to the relevant requirements in section 9.

Q: Does pushing non-cardholder data out of CDE system excludes connected system out of PCI scope? For example pushing non-cardholder data such as CPU usage for monitoring or number of transactions per day used for reporting etc.

A: According to a discussion at the 2016 Community Meeting and a subsequent Assessor call, the Council has publicly stated that if it can be unequivocally proven that the flow is only outbound from the cardholder data environment (CDE) to a device and that the data does not contain cardholder data (CHD), that device can be ruled out of scope.  However you have to get your QSA to buy into that argument and I do not know too many QSAs that will agree with that decision.  In my experience, there is still too much of a risk that cardholder data (CHD) could leak through that flow and saying it is out of scope is not accurate nor is it good practice as it leads to an exfiltration point that is not monitored.  The question you have to ask yourself is, how will it look in that newspaper headline when your organization is breached that you ruled it out of scope because it was outbound only?

Q: PCI DSS requires a firewall in place, are host level firewalls meeting that requirement?

A: Yes, as long as they perform stateful packet inspection (SPI), they are properly and securely configured and they are appropriately monitored like any other in scope firewall.

Q: Regarding vulnerability assessments for internal scans, do we have to address medium vulnerabilities or only critical and high vulnerabilities?

A: The PCI DSS and the Council have been very clear on this which is why it is disconcerting when this question constantly gets asked.  The guidance for requirement 6.2 is very clear as it states, “Consider prioritizing patch installations such that security patches for critical or at-risk systems are installed within 30 days, and other lower-risk patches are installed within 2-3 months.”  The bottom line is that you need to apply ALL patches/updates to all in scope systems as soon as possible.  So get on with patching and updates, no excuses.

Q: More than once I’ve been told that the decision to implement PCI compliant controls is a financial decision. What are the expected fines and penalties for failing?

A: No organization gets to ignore any PCI requirement because of financial or any other reasons.  However in those cases where a requirement cannot be directly met, an organization must then come up with compensating controls that go above and beyond that requirement in order to be in compliance.  In my experience, it is almost always cheaper to meet the PCI requirement than to go the compensating control worksheet approach.  You will have to talk to the card brands as they are the ones that come up with the fines and penalties.

Q: Do you ever foresee the card brands implementing any sort safe harbor clauses in regard to PCI?  If a merchant is doing their best to be secure and (more importantly, as far as PCI is concerned) compliant and they are breached, as it stands right now, PCI will not help you.  Instead, PCI seems to be wielded as a weapon to extract fines from the merchant.

A: You are joking right?  LOL!  Actually, with merchants going to P2PE/E2EE and tokenization solutions, I could envision changes in the PCI compliance process at the merchant level because the risk is only with the POI.  Time will tell.

Q: Have you heard anything further regarding the FTC’s review of PCI?

A: Not a word and I would not expect to hear anything until the FTC decides to tell us anything.  I do know that issues regarding the FTC’s information requests from the QSACs were supposedly worked out and that the requested information was delivered to the FTC.  But that is the extent of my knowledge on the matter.


The Five Stages Of PCI

Had a meeting with a prospect recently that is bound and determined to avoid PCI compliance yet still will accept payment cards.

My response?  Good luck with that!

You would think after 15 years of PCI (and actually even longer) that people would understand that PCI compliance is a fact of life.  But I continue to find that PCI is no different than the five stages of grief.


This is where that prospect is now.  They cannot believe that there is no way to avoid PCI compliance.

For once and for all, if your organization accepts payment cards, you MUST comply with the PCI DSS.  Do not like that answer?  There is nothing as a QSA I can do to effect that fact.

However, for merchants there is a way out.  Do not accept payment cards for payment.  It is that simple.

That answer though immediately leads to the next stage.


I once had a prospect tell me very emphatically that PCI was unenforceable.  I asked them if they had read their Merchant Agreement with the bank that allowed them to accept payment cards for payments.  To my astonishment they said, “What the [expletive] does that have to do with anything?”

You can be angry all you want but PCI compliance is a legal, contractual requirement documented in the Merchant Agreement, Card Operating Rules and other documentation referenced in those documents.  Someone in your organization signed that Merchant Agreement – most likely your Chief Financial Officer (CFO), Controller, Treasurer or heaven forbid – the person that is blowing their cork.  That is the person you should share your anger with, not me.  As a QSA, I am just the messenger.

Anger is even worse with service providers.  Particularly those that provide services tangential to card processing such as those that provide network, firewall or server management services.  They had no idea that their customer(s) needed them to be PCI compliant because they never realized that their service(s) could affect the security of payments.  These folks get totally blindsided by PCI compliance and hence their anger.

I have found that anger over PCI can last a long, long time with some organizations and people.  I still have clients that are angry about it.  It may be less aggressively displayed, but you can tell that they are still angry.


A lot of organizations get stuck in this stage.  They are bound and determined to find that “silver bullet” that somehow magically gets them to PCI compliance with the minimum amount of effort (i.e., none).  They know it is out there and all they need to do is find it.

Because of this stage and the fact that organizations get stuck in it, there are any number of “snake oil” PCI compliance solutions that prey on those in the ‘Bargaining’ stage.  All of them have “The Solution” that will solve your organization’s PCI compliance problem.  They have a pitch for every day of the week and for every situation.  Just ask them.  But at the end of the day, all of these solutions just address one or two PCI compliance issues and do not result in that magical “silver bullet” that those in this stage continue to seek.

Another indicator of organizations stuck in this stage are that they go through compliance and IT leaders like a teenage girl goes through boyfriends.  You immediately know an organization is in the ‘Bargaining’ stage as a QSA because you are always dealing with someone new every year.

Another telltale of a ‘Bargaining’ stage organization is that they are constantly arguing with their QSA over what PCI DSS requirements they need to comply.  PCI is not anything at all like “Let’s Make A Deal”.  It gets even worse when they argue the PCI DSS like it is a legal document and you get discussions over the meaning of the word ‘is’.  At the end of the day, your QSA or acquiring bank cannot cut you a deal on what PCI DSS requirements your organization can ignore.

The bottom line is that the absolute least level of PCI compliance any organization can have are the requirements documented in SAQ A.  Period.  There is nothing less than those requirements.  And SAQ A requires that an organization totally outsource to a third party everything related to card processing.  And I do mean everything.  Nine times out of ten, complete outsourcing is unacceptable to organizations who demand control over their business processes and the “look and feel” of their operations.


Once an organization realizes that there are no “silver bullets”, depression quickly sets in.  With some clients you can see depression get deeper with every data breach announcement that hits the media.  All they can imagine is that their organization is next.

Then there is the fact that PCI compliance is going to cause changes and cost people, time and money to address compliance gaps.  This is where a good QSA can be of great help.  A good QSA can give you options to minimize those resources.  Good QSAs understand that most merchants do not exist on huge margins and that investments with an ROI of more than three years are very painful and difficult to justify.

Unfortunately, in a lot of cases, there are not a lot of options available and even good QSAs are not miracle workers.  This is particularly true when the organization has not invested in infrastructure and application software in a long time.  Worse is when they have invested (usually heavily) in one or more of those “silver bullets” from the ‘Bargaining’ stage and they assist in their compliance efforts only minimally.


I would like to tell you that I have a lot of clients in this stage, but I do not.  Although the number is growing slowly but surely.

But the good news is that if you can get your organization to this stage, there are benefits.

The biggest benefit in my view is that organizations in Acceptance “get” security and why it is a necessary “evil” in today’s ever more connected world.  Never mind the PCI component.

Those at this stage are great to deal with because they have taken steps to minimize their PCI scope and simplify their card processing as much as possible.  They have standardized processes.  They understand that PCI compliance improves their organization’s security.  And not just for the security of cardholder data but for the security of all sensitive information and the whole organization.  Their investments in PCI compliance have paid off (sometime in spades) as they simplified their operations and got rid of sensitive information that they have no longer deemed necessary to retain.

A lot of organizations in this stage have integrated some or all of the PCI DSS requirements into their everyday operations.  As a result, PCI compliance is a daily affair, not the once a year fire drill that it is for most organizations.

These organizations are not perfect by any sense of the word.  But they are a level or more above other organizations and that is all it takes.  Because information security is no different than those movies that show a herd of animals being chased by a lion or tiger.  To survive, you just have to make sure that you are not one of the weakest animals in the pack.  Or as a friend of mine has said for years, “My security program does not have to be the best, just better than yours.”


MFA – It Is All In The Implementation

I have been challenged over the last few weeks over requirement 8.3.1 along with the implications of the Council’s latest Information Supplement on multi-factor authentication (MFA).  Requirement 8.3.1 does not go into effect until February 1, 2018, but there are a lot of organizations trying to get a jump on it.  As a result I am hearing from QSAS that they are getting more and more questions and scenarios to see if they are PCI compliant.

As a reminder, requirement 8.3.1 states:

“Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.”

The most common and biggest challenge has come from organizations that have implemented MFA across their entire network and therefore believe that they are automatically in compliance with 8.3.1.

Not so fast.  The guidance for 8.3.1 states:

“If the CDE is segmented from the rest of the entity’s network, an administrator would need to use multi-factor authentication when connecting to a CDE system from a non-CDE network. Multi-factor authentication can be implemented at network level or at system/application level; it does not have to be both. If the administrator uses MFA when logging into the CDE network, they do not also need to use MFA to log into a particular system or application within the CDE.”

According to this guidance, it is the cardholder data environment (CDE) that is the border for the MFA, not the network as a whole.  So while an organization might have implemented MFA as part of their general security, having MFA for the entire network does not meet the requirement of 8.3.1.

We need to remember what drove the development of requirement 8.3.1 was a lesson learned from the Target and similar breaches.  In all of these breaches, system administrators were spear phished allowing the attackers to access the CDE in one way or another.  Requirement 8.3.1 minimizes this threat by requiring MFA to gain access to the CDE.  So even if an attacker obtains an administrator’s credentials or compromises an administrator’s system, that fact in and of itself would not compromise the CDE.

This is why the guidance for 8.3.1 puts the MFA border at the CDE.  If you have MFA implemented in order to gain access to your network, how does that stop the threat of phishing?  It does not.  A spear phishing attack against such an MFA implementation defeats the MFA because it has already been applied.  The MFA in this scenario does not stop access to the CDE.

But keep in mind, MFA only minimizes the risk to administrators.  You still need to be vigilant in ensuring that administrator systems remain secure and free of viruses and malware.  As such, it is not unusual to find that organizations are taking more active approaches to securing administrator systems including adding other technologies such as file integrity monitoring, white listing and/or black listing in addition to anti-virus.

But it is not just administrators you need to worry about.  Anyone that has access to bulk cardholder data (CHD) that is stored is also at risk.  As a result, we are starting to see organizations also requiring these users to use MFA to access the CDE as well as having their systems implement enhanced security to ensure they remain uncompromised.

Just some things to think about as you got through your MFA discussions.


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.


September 2017
« Aug    

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

Join 1,868 other followers