Archive for March, 2018

30
Mar
18

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.

24
Mar
18

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.

17
Mar
18

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.




March 2018
M T W T F S S
 1234
567891011
12131415161718
19202122232425
262728293031  

Months