Posts Tagged ‘PCI DSS

11
Dec
15

Have You Noticed?

I was on a call with our person who coordinates and does most of our quality assurance (QA) reviews for the firm. They were asked if they had any updates to provide the team regarding PCI. They took over the meeting and had us go to Part 2g of the Service Provider Attestation Of Compliance (AOC). The topic of the discussion was that we needed to make sure that we followed the Note in that section that states:

Note: One table to be completed for each service covered by this AOC. Additional copies of this section are available on the PCI SSC website.”

PCI SP AOC Part 2gThey said that in conversations with other QA people in the PCI arena, this had come up in the discussions as to how he was dealing with the requirement. They said that, until it had been pointed out, they really had not thought about it until just recently when one of our Service Provider clients needed their AOC created and their multiple services necessitated multiple 2g tables.

But that brought up the concern as to how many QSAs and their QA people have noticed this requirement, let alone are doing it correctly? Likely only a few.

However, it is important that the Service Provider AOC gets properly filled out as the service providers’ customers are relying on the AOC to fill out their own matrices based on the service provided by the service provider.

As a result, for every check box checked below in Part 2a, there needs to be a corresponding table filled out in Part 2g.

PCI SP AOC Part 2aIf you are doing service provider assessments and are not following that process expect a big black checkmark in your next PCI SSC AQM review. The question is, will it cause any QSACs to go into remediation?

Happy holidays.

24
Nov
15

Information Supplements Versus The PCI DSS

At various times over the years, the Council has repeatedly told QSAs, Participating Organizations (PO) and anyone else that has asked questions about statements in the Information Supplements the following.

“Information Supplements only offer guidance to organizations and do not replace or supplant anything stated in the PCI DSS.”

So what are the point then of the Information Supplements?

Boy is that a good question. As a QSA, I often ask myself that very question after some of the inane conversations with clients and prospective clients regarding Information Supplements and their supposed “guidance”.

The first thing everyone should remember about Information Supplements is that they are developed and written by a committee at the suggestion of the Council, POs or as part of special interest work groups. These committees are made up of personnel from interested POs, QSAs, ISAs, vendors and anyone else willing to participate in their development. They are edited by a representative from the Council and reviewed by the Committee and are then submitted to all POs, QSAs and ISAs for review and comment. Similar in concept to the development and review of RFCs by the IETF.

The other key point about Information Supplements are that they are developed to give QSAs, ISAs and organizations ideas and guidance on how best to appropriately meet the requirements of the PCI DSS and the Reporting Template testing. Again, as the Council has repeatedly stated, the Information Supplements do not replace the explicit guidance and testing requirements in the PCI DSS and the Reporting Template. They are merely suggests on an approach.

Yet time and again, QSAs and ISAs get these priceless documents tossed in our faces and are told we do not know what we are talking about. “The Information Supplement says …” is always put out there as the justification as to why an organization is doing something it should not be doing or as the rationale for why the organization is not in compliance with the PCI DSS. And we again are forced to explain that the Council never has said that an Information Supplement replaces the guidance and testing in the PCI DSS or the Reporting Template.

The first question anyone, and I do mean anyone, should ask about any statement in an Information Supplement is, “Does the PCI DSS and/or the Reporting Template explicitly say the same thing?” Those are the only two documents that matter and the only documents that your organization will be assessed against. If it is not explicitly called out in either of those documents, then it is not accurate and does not reflect the compliance requirements.

As an example. I was on a conference call recently regarding the Council’s Information Supplement on penetration testing. This supplement was issued in March, 2015 and is possibly one of the most confusing and contradictory pieces of “guidance” we have ever encountered. In fact, it has created more confusion than it has actually clarified. In my very humble opinion, the Council would be better off taking it out of circulation because of all of the trouble it creates for QSAs, penetration testers, ASVs and clients. It is possibly one of the worst written of the Information Supplements and, while people both on the Committee that developed it and externally supplied the Council with numerous suggestions for changes, those changes were not incorporated into the document. Why those changes were not incorporated is anyone’s guess. But we in the PCI community ended up with possibly the worst expressed and misunderstood guidance available.

As usual, the client was arguing over the scope of their penetration testing. I get the fact that organizations want to minimize costs and scope as much as possible. However when you listen to some security professionals arguments on this topic, you just wonder how they got to their positions as they argue over not testing systems and devices that are painfully obvious to be in scope.

And as also is usual, the first piece of confusion regarding scope is in Section 2, page 5, first paragraph after the bullets and states the following.

“It is not a requirement to test from within the CDE to the servers inside the CDE; and testing exclusively from within the CDE perimeter will not satisfy the requirement. However, when access to the CDE is obtained as a result of the testing, the penetration tester may elect to continue exploring inside the network and further the attack against other systems within the CDE, and may also include testing any data-exfiltration prevention (data-loss prevention) controls that are in place.”

One would think that to any reasonably intelligent information security professional, the first part of the sentence, “It is not a requirement to test from within the CDE to the servers inside the CDE;” would be considered a pure line of garbage. Never mind that none of the recognized penetration testing methodologies ever suggest such an approach. But people arguing never consider that fact. Nope. The people arguing are so focused on cutting their PCI compliance bill that it does not matter that the statement is pure and unsupported garbage. It is considered the gospel truth. Otherwise, why would the Council allow such a statement? Good question. We have asked the Council that question and the answer back is? You guessed it.

“Information Supplements only offer guidance to organizations and do not replace or supplant anything stated in the PCI DSS.”

Again, never mind it is in no way supported by the guidance provided by the PCI DSS for requirement 11.3 which says:

“The intent of a penetration test is to simulate a real-world attack situation with a goal of identifying how far an attacker would be able to penetrate into an environment. This allows an entity to gain a better understanding of their potential exposure and develop a strategy to defend against attacks.”

But argue that point they do even when you point out that arguing this point is basically arguing that any attacker would stop at the perimeter of the CDE and would go no further.

Seriously? If you believe that fact, you must also believe in Santa Claus, the Easter Bunny, the Tooth Fairy and any other of the multitude of mythical fictional creatures. Or you are just lying to yourself and are in serious denial about your organization’s security posture. But argue on they do.

Then you pair that to the second part of that first sentence of this paragraph that says, “… and testing exclusively from within the CDE perimeter will not satisfy the requirement.” Just adds to the out of scope argument.

As I point out when bitch slapped with this terrible writing, if you go back and carefully re-read the second part of the first sentence, what it points out is that penetration testing from only inside the CDE is not sufficient to meet the penetration testing requirements of the PCI DSS requirement 11.3. In no way does that sentence say or even further imply that the CDE is out of scope. It is actually saying that penetration testing should be done from within the CDE, but that penetration testing only inside the CDE does not meet 11.3. But people will still argue that the CDE is out of scope.

That the CDE is in scope is further supported by the definitions of “critical systems” from section 2.2.1 of the document which defines that not only are systems within the CDE in scope, but also those that are outside the CDE but could affect the security of those systems inside the CDE (i.e., what the Council and the Open PCI DSS Scoping Toolkit refer to as “connected to” systems). However, people arguing over scope rarely, if ever, tie these two section together and then argue that because they are in separate sections they cannot be possibly together even though the entire document is about only one subject, penetration testing and requirements in 11.3 of the PCI DSS.

So before you go off telling your QSA or ISA that the Information Supplement says something. Think about what the information supplement says. Is the guidance from the Information Supplement even implied in the PCI DSS? Read the guidance in the PCI DSS and the testing procedures from the Reporting Template. If the PCI DSS or the Reporting Template do not explicitly have the same language in them that the Information Supplement has, then the Information Supplement is merely a suggestion.

And if the guidance from the Information Supplement does not make sense, pull your head out of your posterior and use some God given common sense. Ask your QSA or ISA to explain it, before going off halfcocked and thinking that someone could actually think such things made sense.

But again, why would the Council allow such statements? Good question. We have asked the Council that question and the answer back is? You guessed it.

“Information Supplements only offer guidance to organizations and do not replace or supplant anything stated in the PCI DSS.”

Clear as mud? You bet.

But what did you expect? It is PCI.

For all of you in the United States, have a happy and safe Thanksgiving holiday.

14
Nov
15

Small And Mid-Sized Businesses

At this year’s PCI Community Meeting, the push was to address the security issues faced by small and mid-sized businesses, otherwise referred to as SMB. However, in my opinion, the approaches being suggested are still too complex. Great security results from simplicity, not complexity. As a result, I propose the following approach for SMBs because SMB executives typically have little time to fully educate themselves in information security, let alone, PCI. And while I am of the opinion that executives should have such knowledge, it is just not happening.

There Are No “Silver Bullet” Solutions

First and foremost. There are no “silver bullet” solutions that will entirely remove your organization from PCI scope. Any vendor telling you that their solution removes your organization from PCI scope is lying to you. If you hear such a statement from a vendor, the vendor does not know what they are talking about and their statements regarding PCI should no longer be trusted. The bottom line is that, if your organization accepts credit/debit cards for payment for goods/services, the organization will always have some PCI scope. The least amount of scope an organization can achieve is complying with the requirements listed in the SAQ A. There is nothing less. Anyone telling you otherwise does not know what they are talking about.

DO NOT STORE CARDHOLDER DATA (CHD)

This is probably the biggest single thing an SMB can do. In this day and age, there is no reason that any organization needs to retain CHD. Period. The most common business justification is that the organization does recurring transactions and that is the reason to retain CHD. Processors have a solution for that situation and many others. So I say it again. There is no valid business reason for any organization to retain CHD. None. Nada. Zip.

The first question out of an SMB executive’s mouth to a payment solution vendor should be, “Does your solution store cardholder or sensitive authentication data?” If the answer is anything other than an immediate and definitive “NO”, the meeting or telephone call is over, done, complete. There is nothing more to discuss. SMBs must stop being an easy target for attacks. The easiest way to do that is not having the CHD in the first place.

The second question that a payment vendor should be asked is, “How does your solution minimize my organization’s PCI scope?” If the vendor cannot provide you with a whitepaper on this subject, run away. If the documentation provided by the vendor leaves you with more questions than answers for PCI compliance, you also need to run away. In all likelihood, if this is what you encounter, the vendor’s PCI compliance is questionable, complex or requires too much effort on your part to be PCI compliant. This question should result in a one to three page whitepaper on PCI and how the vendor’s solution minimizes your organization’s scope.

So what solutions reduce scope to the minimum?

If you are a traditional brick and mortar retailer, end-to-end encryption (E2EE) from the card terminal, also known as the point of interaction (POI), to the transaction processor. PCI has a validation program called point-to-point encryption (P2PE). P2PE solutions are independently validated to ensure that they are secure. Solutions such as Shift4’s Dollars on the Net, First Data’s TransArmor and Verifone’s VeriShield are E2EE solutions that could meet the P2PE standard, but for various reasons the providers chose not to validate them to the P2PE standard. The key capability for any such solution is that the solution encrypts the CHD/SAD immediately when it is read from the card and none of your organization’s technology can decrypt the information and therefore read it.

If your organization does eCommerce, then you want to use a redirect or iFrame to process transactions in order to reduce PCI scope. The best example of a redirect is when a merchant uses PayPal for processing payments. The merchant’s Web site has a PayPal button that sends the customer to PayPal who then processes the customer’s payment transaction. At no time does the sensitive authentication data (SAD) encounter the merchant’s Web site. One of the concerns from merchants about redirects is the myth that customers vacate their shopping carts because they are redirected to a different site for payment. While this was true in the early days of eCommerce, with the increased use of PayPal and similar payment services, customers seem to have gotten over that practice and vacated shopping carts are no longer an issue. But if this is still a concern, use this as a teaching moment and educate your customer base that you do the redirect to ensure the security of their SAD.

An iFrame is essentially a Web page within a Web page. But the key thing from a PCI compliance perspective is that the iFrame is produced and managed by a third party, not the merchant. An iFrame can be a Web page, but more often than not it is a series of fields that gather the SAD for conducting a payment transaction. As with the redirect, the SAD never comes into contact with the merchant’s Web site.

Both of these solutions take your organization’s Web site out of scope so you do not need external and internal vulnerability scans and penetration tests. However, just because your Web site does not have to go through the rigors of PCI compliance, you still need to ensure its security. See my post on SAQ A and SAQ A-EP for a more detailed discussion on this topic.

Tokenization

Tokenization is the act of encrypting or tokenizing the primary account number (PAN) so that when it is returned to the merchant for storage it has no value to anyone if it is disclosed. Tokenization can occur at the time a card is swiped or dipped at the terminal or it can be done by the transaction processor at the back end of the transaction. Regardless of where the tokenization occurs, paired with E2EE or P2PE, tokenization further minimizes PCI scope.

If your organization needs to perform recurring transactions such as with subscriptions or automatic reorders, tokens can be generated by the processor so that they can be used just like a PAN. While a token is not a PAN, in situations where they can be reused for future transactions, it is incumbent upon the merchant to protect access to the token so that it cannot be sent to the processor for fraudulent charges.

And that is it. Not storing CHD, E2EE/P2PE and tokenization will reduce an organization’s PCI compliance footprint to the absolute minimum. It really is that simple. However, finding the solutions that bring all of that to the table is where the work comes in. However, any SMB that asks the right questions of its vendors can put together a solution that minimizes their scope and provides protection for CHD/SAD as good as with the big boys.

21
Jul
15

An Update On Network and Dataflow Diagrams

A number of years ago, I wrote a post on how to diagram for your QSA. While my original post still has validity, there have been a few changes have occurred so I thought it was a good time to update everyone so that diagrams meet what your QSA needs for documentation.

One of the changes that came with v3 of the PCI DSS was with requirement 1.1.3 that now explicitly calls out that the data flow diagram be overlaid on the network diagram. The purpose of this was twofold. First, such an approach allows the organization being assessed to further refine their scope for their PCI assessment. Second, it allows the QSA an easier time to confirm that the scope of the PCI assessment is accurate.

Prior to v3, organizations had a tendency to deliver data flow diagrams that had no basis in reality as to how they were physically implemented. A lot of this was due to the fact that developers and networking types never communicated between one another. As a result, QSAs would hear comments such as, “All I know is it just works”, “You’ll have to ask the developers …” or “You’ll have to ask the networking people …”. This obviously resulted in a lot of discussions (i.e., arguments) over scope accuracy between QSAs and their clients. Under the new v3 requirements, hopefully all of those discussions will go a lot easier and faster.

Regardless of what requirement 1.1.3 states, QSAs are still encountering data flow diagrams that look more like cubist or surrealist paintings. This situation seems to be driven by the fact that a lot of organizations either do not want to or cannot get their developers and networking folks together to come up with a data flow diagram that can marry up to the network diagram. Let me tell you that going through this exercise greatly reduces the issues surrounding scope because scope becomes very clear once everyone can “see” how data flows through the network. However, it is not surprising when organizations come back and say they found the exercise too daunting. Lots of organizations operate in such a siloed structure, that: (1) it takes an act of God to get everyone necessary together for such a discussion, (2) everyone agrees on the flows and networks used and (3) somewhere there is a flow that no one knows about or knows how it works. All of this can be resolved, but it takes time and information to work out and can end up being incredibly tedious particularly in a complex environment.

Unfortunately, while the scope becomes much clearer once the dataflow is overlaid on the network, the scope also tends to end up much larger than anyone realized. That is because systems that were thought to not have any connectivity (Category 3) to the cardholder data environment (CDE) end up as connected systems that could impact or influence the security of the CDE (some form of Category 2). It is then that there is a “mad dash” to minimize the number of these systems that need connectivity, i.e., reduce scope. It is during these scope reduction efforts that we encounter twisted and contorted arguments regarding systems that are clearly in-scope, but the client does not want to be in-scope and will do anything and everything imaginable to remove them from scope. Some of these discussion become so tortured in their logic as to be laughable, e.g., “Can’t we just ignore them?” and my personal favorite, “If I paint these servers “blue” will they then be out of scope?”.

But to further confirm scope, v3 introduces us to a revised requirement 11.3 that went into effect on July 1, 2015. As part of that change, the penetration test methodology now requires that the penetration testing exercise prove that network segmentation is in place as documented and therefore further prove that the scope for PCI compliance is accurate. This basically requires the penetration tester to confirm that your network diagram overlaid with the dataflow in fact fully documents your organization’s scope for PCI compliance. Therefore, if your dataflow and network diagrams are junk, do not be surprised if your penetration tester and/or QSA come back and tell you that your scope is larger than you thought.

Behind the scenes, there has been a change made by the PCI SSC through their reviews of QSAs’ ROCs under their quality assurance program. The Council is concerned that the diagrams put in ROCs are not always legible to readers. While organizations provide the original diagrams, the Council wants diagrams in reports to be legible for the banks and processors when they review the reports. As a result, QSAs and ISAs have been informed that their ROCs need to break out or section large diagrams so that they are legible on standard paper (i.e., 8.5”x11” or A4). As a result, a lot of ROCs are exponentially increasing in size to accommodate the network and data flow diagrams that now require many additional pages to ensure that the diagrams are legible in the ROC.

This should bring us all back up to date on network and dataflow diagrams.

01
Jun
15

Supplemental Validation Procedures Coming

In the April 2015 Assessor Newsletter (received just last week) from the PCI SSC was the following announcement.

Coming Soon – Supplemental Validation procedures for Designated Entities

The analysis of PCI DSS compliance trends as well as the recent data breaches involving cardholder data has revealed that many organizations continue to view PCI DSS compliance as a periodic exercise only, and fail to implement processes to ensure that their PCI DSS controls are continuously enforced. This approach has been shown to result in a lapse in security controls between validation assessments. Organizations must remember that security is an ongoing process that must be incorporated into an entity’s overall strategy and PCI DSS security controls must be maintained on a continual basis.

In response to these trends, the PCI SSC is planning to issue additional validation procedures that are designed to help organizations illustrate how they are maintaining PCI DSS security controls on an ongoing basis. These supplemental validation procedures are due to be published in the upcoming weeks, along with guidance for understanding how and to whom these procedures may apply. Stay tuned!

Could it be that business as usual (BAU) is coming before v4 of the PCI DSS is released?

Who are these “designated entities”?

As the newsletter says, “Stay Tuned!”

UPDATE: On Friday, June 5, the Council issued the ‘PCI DSS Designated Entities Supplemental Validation’ standard. It can be downloaded from the Council’s Web site.  The document gives the following as examples where these supplemental procedures apply as entities that: (1) store, process, and/or transmit large volumes of cardholder data, (2) provide aggregation points for cardholder data, (3) have suffered significant or repeated breaches of cardholder data, or (4) anyone the card brands determine should go through this process.

25
Apr
15

PCI Survey

A gentleman working on his Masters Thesis at the University of East London approached me a month ago for my take on PCI and his questions resulted in the post PCI SWOT Analysis.

Now this gentleman is looking for further feedback via a Survey he has constructed. I would like to encourage my readers to take his survey to further his research as well as provide all of us with feedback on PCI.

The survey can be taken here.  (https://docs.google.com/forms/d/1ua_KAPvBu0Ziu1GQ18vZj6qq1selSMMnLtVD-D1NBJo/viewform)

Thank you.

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.

14
Apr
15

SSL Update

“The report of my death was an exaggeration.” – Mark Twain

Today the PCI SSC announced that SSL and “early TLS” (whatever that means) will not truly die until July 1, 2016. This will allow a transition period for all of you stuck with vendor baked-in SSL as well as the procrastinators amongst us to get converted to TLS 1.2. I say TLS 1.2 because if you are going to convert, you really should go to the most current version and not just with whatever will get you by.

The complete summary of PCI DSS v3.1 changes can be found here.

UPDATE: Late on Wednesday, April 15, the PCI SSC released v3.1 of the PCI DSS. The Council uses NIST SP800-52 rev1 as the definition of “early TLS”. You can get a copy of the new version of the PCI DSS here.

27
Mar
15

PCI SWOT Analysis

SWOT – strengths, weaknesses, opportunities and threats

I had someone ask me about my thoughts on this sort of analysis of the PCI DSS. While these comments are PCI focused, I found that they actually apply to all security frameworks.

Strengths

The biggest strength in any security framework, PCI DSS included, is they are all based on the “best practices” from a wide variety of leading experts and organizations. Essentially, security frameworks are the shared knowledge base of what it takes to have basic security. We talk today about sharing breach information better and potentially in near real time, but security frameworks are the original method of sharing such information.

Weaknesses

Unfortunately, I see a number of weaknesses with security frameworks.

The largest weakness with security frameworks I see is that most people, including a lot of security professionals, seem to believe that complying with the framework is all it takes to be secure. With the PCI DSS a lot of this misinformation can be laid at the feet of the card brands. It was the card brands that originally marketed the PCI DSS as the “be all, to end all” for securing the payment process.

The unfortunate fact of life for security frameworks is that they only minimize and manage security risks, they rarely ever eliminate them. Therefore, even following the PCI DSS to the letter is no guarantee that an organization could not be breached. Yet this concept of risk minimization, risk management and the fact that security is not perfect consistently gets missed by executives. So when the inevitable breach occurs, executives go after the security people for supposedly misleading them.

Another area of weakness is the time with which it takes to make an update to the framework. In October 2014, the National Institute of Standards and Technology (NIST) issued a bulletin on secure sockets layer (SSL) indicating that they had found a flaw in the protocol and that they no longer found the protocol secure. A few weeks later the Internet was introduced to POODLE and SSL was declared insecure. It took a few months for the PCI SSC to react to this and officially declare SSL was no longer to be relied upon for secure communications. It took vulnerability scanners almost a month to begin flagging SSL implementations as high vulnerabilities as the CVE had not yet been updated. And we were recently informed that it will be April at the earliest before we will get the latest version of the PCI DSS. In the meantime, all of this administrivia did not stop attackers from using POODLE to their advantage.

The final weakness I see with security frameworks is that organizations find it impossible to execute them consistently at near 100%, 24×7. In theory the PCI DSS will provide reasonable security for all but the most dedicated attacks such as with advanced persistent threat (APT). For an organization to achieve basic security, they would have to execute the requirements of the PCI DSS at least at 95%+ and would have to remediate any issues within a few days. Unfortunately as we have seen in the recently released Merchant Acquirer Committee study, merchants are typically only compliant with the PCI DSS between 39% and 64% of the time – far from 95%+. Verizon’s recently released PCI report backs this up with their findings. The bottom line is that most organizations lack the discipline to execute any security framework consistently enough to achieve basic information security.

Opportunities

The biggest opportunity I see for the PCI DSS is it gives organizations the impetus to simplify their environments. The biggest reason for the failure to execute the PCI DSS consistently is because a lot of organizations have technology environments that mimic a Rube Goldberg cartoon. Only by simplifying that environment will an organization have a reasonable chance of securing it.

Another opportunity this gives organizations is a reason to enhance their security operations. Most organizations run bare bones security operations no different than other areas. However, what PCI compliance assessments typically point out is that those security operations are grossly understaffed and not capable of ensuring an organization maintains its compliance at that 95%+ level.

Related to these two opportunities is what the PCI SSC calls business as usual (BAU). BAU is the embedding of the relevant PCI requirements into an organization’s business processes to make it easier to identify non-compliance as soon as possible so that the non-compliance situation can be rectified. BAU is primarily designed to address the execution weakness but can also have a significant effect on the other weaknesses.

Finally, the last opportunity is to address the failings of an organization’s security awareness program. Organizations finally come to the realization that all it takes to defeat all of their expensive security technology is human error. The only way to address human error is extensive security awareness training. No one likes this, but in the end it is the only thing that remains when you have implemented all of the requisite security technology.

Threats

The obvious threat that will never go away is the attackers. As long as we have our interconnected and networked world, attackers will continue their attacks.

The final threat is complacency. A lot of organizations think that once they achieve PCI compliance that their work is done and that could not be further from the truth. Security is a journey not something you achieve and then move on to the next issue. The reason is that no organization is static. Therefore security must constantly evolve and change to address organizational change.

There are likely even more items that could be added to each of these categories. However, in my humble opinion, these are the key points.

21
Feb
15

Incidental Contact

I have had a number of questions recently regarding how to deal with the occasional customer that sends cardholder data (CHD) or sensitive authentication data (SAD) to the merchant via email or instant messaging in blatant disregard to security.

Most people point to requirement 4.2 in the PCI DSS v3 and say it is not allowed for PCI compliance.  However, that is wrong.  Requirement 4.2 states:

“Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.).”

The operative word is “send”.  Requirement 4.2 does not say a merchant or service provider cannot receive PANs by end-user messaging technologies, only that they cannot send them by those same messaging technologies.

The Council has always recognized that there were always going to be a small percentage of people that would ignore security and will send their CHD/SAD via any number of insecure methods all in the name of expediency or convenience.  As a result, the PCI DSS has been structured to allow for those occurrences, something a lot of QSAs refer to as “incidental contact”.  What is important to a QSA is how you handle incidental contact.

The first important point to make is that once CHD/SAD is received via an end-user messaging technology, the merchant or service provider cannot then forward the information on using email or similar technologies.  The merchant or service provider must break the chain of that communication as soon as possible.

Security purists will point to the fact that deleting such messages from their sources is not secure.  In some cases a message could exist overnight and therefore exist on backup tapes of some technologies.  While this is all true, we are not talking about a consistent flow of CHD/SAD, we are talking about an occasional occurrence.  Organizations will have to accept the risk that their end-user messaging systems will have some CHD/SAD in them but that the amount is trivial because of how they deal with such occurrences.  If your organization is not willing to accept this risk, then you will have come up with an approach that will allow you to stop such occurrences.

The other key point to make is that incidental contact does not necessarily bring the end-user messaging technology into scope for PCI compliance.  In my opinion, what a merchant or service provider needs to prove to their QSA is that such occurrences are not condoned by the organization (i.e., by policy, such exchanges are not recommended), employees are trained to handle such exchanges securely, and that the exchanges occur only occasionally.  The term “occasionally” is the tough one and is up to the organization to define for the QSA.  I have dealt with large organizations that could receive around 50 such messages a day on bad days, but the annual total of incidental contact was well below 1% of the total number of transactions.  The rule of thumb that I use is that as long as the volume of transactions received over end-user messaging never exceeds 1% of the total I consider that as incidental contact.  However, I could see acceptable arguments for a 2% threshold based on the type of customers of the organization.  However, going higher than that value would, in my opinion, be too great.

With that stated, what is an organization to do with such messages?

Some organizations prefer to not act on any end-user messaging that contains CHD/SAD.  They prefer to record the sender’s communication account information, delete the message and then send a message back to the sender explaining that they cannot accept CHD/SAD through the communication method and tell the sender to use one of their approved methods for communicating CHD/SAD.

Other organizations are all about customer service and will reluctantly accept such communications.  They will print out the communication and delete the original message.  Once they have processed the transaction, they redact the CHD/SAD, take a copy of the redacted original and then securely destroy the original.  I recommend redaction using a Sharpie marker or similar.  The reason for taking and retaining a copy of the original is so that, when held up to a light, the redacted digits cannot be determined as would be the case if the redacted original were retained.

Some organizations will use the transaction confirmation process as an opportunity to remind their customer that the sending of CHD/SAD via the end-user messaging technology should be avoided in the future.

We live in an imperfect world where people are not necessarily as security conscious as the world sometimes demands.  As a result, merchants and service providers need to be flexible in how they approach situations where their customers communicate with them through insecure channels.  Hopefully I have given you some ideas as to how to approach these situations and deal with them in as secure a manner as possible.




Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

October 2021
M T W T F S S
 123
45678910
11121314151617
18192021222324
25262728293031

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

Join 2,422 other followers