More Struggles Staying Compliant

I was recently on a conference call with one of our clients.  We are in the middle of conducting their annual PCI compliance assessment.

We were told that they had had an issue with processing of credit cards through one of their locations outside of the Untied States.  This client’s point of sale (POS) environment is consistent throughout the world.  As they were diagnosing the processing problem, application support personnel came across a series of files that contained cardholder data (CHD) in cleartext.  They were shocked, as a couple of years ago, they had requested and received a patch from their POS vendor to address this very problem.

So, what happened?  According to the vendor, the patch received years ago only addressed files named according to the organization’s US file-naming standard and not their international file-naming standard.  So, while all of the US systems were patched, their international systems were not fixed.  They do have a patch for this new problem and are rolling it out to all of the POS systems.

What did this organization learn form this event?

• The organization admits that its QA testing process was flawed.  The testing was only done in their US environment, not in their international environment as well.  From here on, all testing will be done in both environments.
• All systems will be scanned for cardholder data (CHD) to ensure that any other CHD can be identified and eradicated.  This scanning will include the QA environment after every test to ensure that new patches are not creating PCI compliance issues.
• A project is underway to develop a wiping program for this POS environment to ensure that all data in deleted files and slack space from the previous incarnation of the POS solution is removed from these systems.

Complying with the PCI standards is an ongoing process.  It is ongoing because the threat landscape changes every day.  In addition, vendors can create unknown problems with their updates and fixes.  The only way to find these issues is to have a complete testing environment and to conduct complete tests of all solutions that process, store or transmit CHD.  Then going back and making sure that the solution does not leave CHD behind.

PCI compliance requires diligence.  Those of you working in this arena need to explain this to management so that they give you the time for that diligence.

Advertisement

Chip and PIN

Chip and PIN is back in the news and since I am heading to Europe next week on vacation, I thought I would pass this information along.

In a recent interview, Ms. Ellen Richey, Visa’s Chief Enterprise Risk Officer, indicated that Chip and PIN would head to the United States at some point.  As usual, there was an impression given that Chip and PIN is some sort of magic bullet that will cure all ills.  However, as you will see, Chip and PIN is not the “silver bullet” solution.

For those of you that have not traveled to Europe a little background.  Chip and PIN was developed by the British government to implement the Europay, MasterCard and Visa (EMV) standard for credit cards containing a built-in integrated circuit (IC), also known as the ‘Chip’.  The PIN part comes from the fact that you no longer sign a receipt when you make a purchase, you enter your PIN, just like at an ATM.  The purpose of developing Chip and PIN was to reduce the amount of fraud in face-to-face credit card transactions.  Chip and PIN is a worldwide standard that has only been implemented in Europe.  With the exception of Discover Financial, all of the other major card brands (Visa, MasterCard, JCB and American Express) have adopted various forms of the Chip and PIN technology.

Chip and PIN replaces the swiping of the magnetic stripe and receipt-signing common in the United States.  With Chip and PIN technology, the information contained on the magnetic stripe is also recorded on the Chip contained in the card.  The data stored in the chip is encrypted using either the DES, 3DES, RSA or SHA encryption algorithms.  Rather than swiping the magnetic stripe, the card is inserted into the payment terminal where the chip is read and decrypted and the transaction is submitted for authorization.  If authorized, the payment terminal is given to the cardholder and the cardholder enters their PIN into the terminal, a receipt is generated and the transaction is completed.  Most Chip and PIN terminals also have a magnetic stripe readers – you want the tourists to be able to use their “old” cards.  Chip and PIN terminals can operate over wired, dialup, 802.11 wireless or cellular networks.  In all communication environments, the terminals use secure transmission technology to ensure the privacy of cardholder data.

Looks good so far, but as I have said before, security is not perfect.  While Chip and PIN has significantly reduced fraud in face-to-face transactions, there are a number of issues regarding the security of this technology.  Those issues include:

• The EMV specification is open source and available from a number of sources, including EMV Co.  Because of this, any attacker can obtain the specification to build their own hardware and software for creating and processing Chip and PIN cards as well as creating attack methods to compromise the cards.  This has lead to a number of successful attacks resulting in cloned cards as well as obtaining and computing valid PINs.
• The entry of the PIN can be bypassed by the merchant.  If bypassed, the receipt is generated and signed by the cardholder, no different from a transaction performed with a traditional credit card.  While banks have tried to discourage this practice, this option is still available which does not provide any additional protections against fraudulent transactions.
• Theft of physical credit cards has risen since the introduction of Chip and PIN.  Criminals often hold victims hostage and threaten them with bodily harm until they reveal their PIN, which the criminals can confirm with a simple card reader.  Card readers are very easy to come by as banks sent them to all their customers along with their Chip and PIN cards when they were introduced.
• Banks encourage credit and debit card customers to take their card readers along with them.  The readers require the entry of the PIN in order to get information displayed from the card.  Security researchers found that because of frequent use of these readers, the readers had four more heavily worn keys that reduced the likelihood of guessing a card’s PIN from 1 in 3,333 to 1 in 8.
• Chip and PIN cards connected to PCs can generate authentication tokens, but the standards do not specify how these tokens are to be used in an online environment.  In addition, most e-Commerce sites and many banks have not implemented this capability into their Internet processing environments.  As a result, security of online environments is not always enhanced by using Chip and PIN cards.  In fact, some banks will not allow their Chip and PIN cards to be used online.
• Offline entry of PINs is supported by certain cards in certain countries.  In offline mode, the PIN is not encrypted, so it can readily be retrieved in plaintext from the terminal.
• The introduction of Chip and PIN technology has moved attacks to the merchant terminal or integrated point of sale (POS) solution. In the case of terminals, the terminal is modified by the attacker to record the information on the chip after it is decrypted (skimming).  Since most terminals use some form of high-speed network connection, the compromised terminal periodically sends the captured chip data to an attacker any where in the world. For POS, the attacker compromises the POS station and then obtains the chip data by monitoring the program that processes the Chip and PIN card.  Again, since most POS terminals are on a network, the attacker has their capture program send the captured card data to their computer.A number of incidents involving the skimming of Chip and PIN cards using tampered software or terminals have been documented.  Skimmed cards are typically sold in areas like Asia and the United States where magnetic stripes are still used.  The incidence of compromised terminals and POS systems has risen significantly since the introduction of Chip and PIN technology.

Many European organizations believe that Chip and PIN makes them immune to complying with the PCI standards.  The standards promulgated by the PCI Security Standards Council are worldwide in nature.  So, regardless of the type of card used, all merchants and acquirers are required to comply with all PCI standards.  This is legally enforced through merchant and service provider agreements between these entities and the card brands.  All agreements were updated worldwide over the last three to four years to include addendums that require all parties to be PCI compliant.

While Chip and PIN cards and their terminals are different, the integrated POS and the back end systems that authorize and process transactions are not different.  These systems provide their functionality the same way regardless of the card used.  At a minimum, these back end systems process and transmit cardholder data.  But these back end systems may also store cardholder data.  As a result, these back end systems must comply with the PCI standards.

Chip and PIN terminals are no different than their magnetic stripe swiping cousins.  They require proper configuration to ensure that they mask cardholder data and that they transmit transactions securely so that they comply with the PCI Data Security Standard.  They are also required to comply with the PCI PIN Entry Device (PED) standard.

The bottom line is that Chip and PIN reduces face-to-face transaction fraud, but it does not remove all of the risks involved in the use of a credit card.  As a result, there is still some amount of effort required to ensure that an organization’s credit card processing infrastructure is secure and complies with the various relevant PCI standards.

Update: Bruce Schneier has an interesting post regarding a new flaw in the Chip and PIN card that basically makes the PIN unimportant.

After The Breach

As the old TV show Dragnet always started, “The following story is true.  Only the names have been changed to protect the innocent.”  This is a situation that the PCI SSC will need to get control of quickly or this will be another big black eye against the PCI standards.  It is not that I am against the process; I am against a process that does not make business sense.  This scenario is about a small business, but I have been through this with large businesses as well and all that happens is the costs skyrocket exponentially and blame gets assigned.

What we have is a franchisee of a fast food chain in a major metropolitan area.  This franchisee is the quintessential small businessperson with three locations.  Small businesses make up over 90% of all businesses in the United States, so this scenario is highly likely to happen again and again.  Fast food is a comfortable existence, but as F.W. Woolworth said, you make your money one or two pennies at a time.

One day our franchisee receives a call from their credit card processor indicating that one of the franchisee’s facilities has been involved in a data breach.  The processor identifies the source of the breach as one of the franchisee’s stores located in the downtown area.  Not only does the processor know the exact location, they also know that a card skimmer is involved.  The processor goes on to tell our franchisee that the amount of the breach is $5,000.  Then the processor informs the franchisee that under their merchant agreement they need to select one of three PCI-approved forensic examiners to conduct an examination to isolate the breach.  Therefore, our intrepid franchisee goes shopping for a forensic examiner.

Our franchisee contacts the three well-known forensic examination companies they were referred to and is essentially told the same story by each.  Its $25,000 up front to start the examination and the forensic examiner will tell them when to stop writing checks.  Since under the merchant agreement, there is no choice, the $25,000 fee is paid and the forensic examiner comes on site.

After conducting a preliminary examination of the facilities computer systems and interviewing employees for three days, the lead examiner tells our franchisee that, they cannot find any initial evidence that points to either tampering or misuse of the facility’s computer systems or that any employees are skimming cards.  The examiner then says that a more thorough and detailed investigation of the computers systems are called for and a more thorough interrogation of employees is justified.  Oh, and another $10,000 please.  Another check is written and the process continues.

After about two weeks, the investigation comes to a screeching halt.  It seems that a convenience store next door is the actual site of the breach according to the card brand.  Seems that the night clerk and some of his ‘associates’ had tampered with the ATM.  Sorry to have been so much trouble.  Please write us a check for our remaining fees and expenses (around $15,000) and we will be gone.

My first problem with this whole situation was that the breach was never alleged to have occurred at the fast food restaurant.  The processor was totally convinced that the franchisee was the cause of the breach.  That later proved to be false when no evidence was produced and another culprit was identified.  Nevertheless, at the time, there was no way to prove the allegations otherwise and the processor really did not care.  Therefore, merchants beware, in the event of an alleged breach; it appears you are guilty until proven innocent.

Second on my list of injustices is the processor’s unwavering commitment that the franchisee was the root cause of the problem and that they knew the cause of the problem.  There was likely some evidence to support skimming of cards due to the type of fraudulent transactions that were occurring.  However, based on my experience, there is a big difference in volume between a doctored ATM and a person with a skimmer.  That ATM was likely generating a lot more traffic than our franchisee’s single location and that information should have been available to the processor with the right data analysis.  That said, the processor totally missed the culprit in the breach.  In my experience, it is extremely rare that a processor or even the card brands can tell the exact location of a leak.  Their fraud detection/prevention systems are good, but they are not that good.  There are usually three or more potential suspects in any breach.  Therefore, merchants, when you get that call that you are the source of a breach, be skeptical.

Third, what businessperson in their right mind spends $25,000 up front on a $5,000 problem, let alone the $50,000 in total that ultimately got spent?  I can tell you that the card brands and processors will not spend that kind of money, they will reimburse the cardholders for their losses and move on.  That $50,000 was almost five months of profits for this operation.  Apparently, the forensic examiners attended the Bernard Madoff School of Business when it comes to their fees.

Finally.  The card brands are all pushing for more and more transactions, even transactions in the $1 to 2$ range.  They want everyone to use plastic instead of money.  However, these forensic practices will kill that effort if small merchants are under the constant threat of incurring huge costs should they ever even be accused of a breach.

Moreover, it is not just merchants, processors and other related entities that process, store or transmit cardholder data come under these forensic process as well.  So what should be done to fix this out of balance situation?  Here are my thoughts.

• Just because a breach has occurred and an entity MAY be the source does not mean that they ARE the source.  An entity is innocent until proven guilty, not the other way around.  A basic investigation needs to be performed to get the facts straight and rule suspects either in or out of any further investigation.  In my opinion, these initial costs should be born by the entity initiating the investigation.  If the facts warrant further investigation, then the initial investigation costs for that entity being further investigated should be borne by that entity.
• Entities under further investigation should have the right to recoup their costs of the investigation if they are ultimately cleared of being the cause.  Whom they recoup those costs from is up for debate, so I will leave that for the lawmakers, lawyers and courts to decide.
• The entity that is ultimately proven to be the source of the breach should bear all of the costs of the breach.  Yes, this will likely put most small business out of business, but someone has to be responsible.

As I said in my Carrot and Stick post, the card brands and their processors need to take another look at their ‘Big Stick’ approach and come up with more carrots to get people to do the right things.  By implementing these three bullet points, I think there is a lot of incentive to get more organization to comply with the PCI standards.  It is all in the approach.

What If I … ?

Go out to the SPSP Forum on any given day and you will see postings such as:

“If I implement XYZ Solutions’ credit card processing widget, do I still have to go through the PCI DSS process?”

“If I use Blah-Blah’s POS that is PA-DSS certified solution I’m automatically PCI compliant, right?”

Many organizations are expending tremendous amounts of effort trying to do or use something to avoid going through the PCI compliance process.  If only this effort was focused on being PCI compliant, these organizations would likely be PCI compliant.  Well, guess what people?  There is no way to avoid going through the PCI compliance process.  Oh, come on, there has to be a loophole?  Nope.  Nada.

When your organization signed its merchant agreement to accept credit cards for payment of goods and services, your organization agreed to be PCI compliant.  Moreover, being PCI compliant means that your organization must annually evaluate itself against the relevant PCI standard and then file a report to their acquiring bank stating that the organization is either compliant or non-compliant.

However, these efforts to get out of having to comply with PCI are not totally for naught.  Many organizations have done good work figuring out how to avoid storing cardholder data.  But, if you are a traditional brick and mortar merchant, your employees’ come in contact with credit cards every day and those contacts are still covered by the PCI DSS regardless of how they are processed by POS.  And for you e-Commerce folks.  You are not totally out of the woods either.  While you may use PayPal or some other third party to process your card transactions, I will guaranty you that there is someone in your accounting department that deals with disputes and chargebacks that are covered under the PCI standards.

While there are ways to reduce the amount of effort to get your organization PCI compliant, there is no way to avoid going through the process if your organization allows credit cards to be used for payment.  So, all of you folks trying to beat the system.  Either only accept cash and checks for payment or put your efforts toward being compliant and get over it.

Can PCI Compliance Be Maintained?

I am catching up on my reading and ran across an article on Computerworld’s Web site entitled, “Post-breach criticism of PCI security standard misplaced, Visa exec says.”  There are a number of interesting and very insightful quotes in this article that I think deserve further discussion.

The first quotes are from Ellen Richey, Visa’s Chief Enterprise Risk Officer.  In her first quote, Ms. Richey states that the PCI DSS, “remains an effective security tool when implemented properly.”  Later on, she is quoted as saying, “As we have said before, no compromised entity has yet been found to be in compliance with the PCI DSS at the time of the breach.”  And here is the payoff quote from David Taylor at PCI Knowledge Base.  Mr. Taylor states, “It’s easy to find somebody to be in noncompliance if that is the primary goal.”  Bingo!

Do not get me wrong.  I agree whole-heartedly with the concept of the PCI DSS and the other standards.  I think they are a good set of guidelines to ensure that organizations are properly protecting cardholder data as best they can.  What I do not agree with is the concept that seems to be put forth by the card brands and others that the PCI standards are some sort of magic silver bullet and that they cure all of our cardholder data security ills.  Any good security professional knows that they do not and they never will cure everything.  This is why there is a push back on the PCI program.  Good security people know that even if your organization does everything the PCI standards tell you to do, there is still a certain element of risk.  It is that risk that the card brands either refuse to acknowledge or believe does not exist.

Ask any security professional, security is not a perfect or exact science.  It never has been and it never will be.  If it were, banks and art museums would no longer be robbed and once the PCI DSS was implemented at any organization, the organization would never be breached.  Unfortunately, none of these statements is accurate, banks and art museums still are robbed and cardholder data still is compromised.  For whatever reason, the card brands do not seem to understand that the goal of security is to minimize, as best possible, the risk that what you are trying to secure will remain secure.  For example, that can mean that 98%+ of the threat has been removed.  It is that remaining 2% of risk that an organization’s management must be willing to accept.  If they are not, then they need to change their approach to provide a level or type of risk they are willing to accept.

The bottom line is that no matter how much we do and no matter how much we try, there is still a chance, however small, that our efforts will not be successful.  It is this fact that the card brands need to acknowledge and stop touting the PCI standards as the “Holy Grail” of security.  The truth is that, as long as there are people willing to go the extra mile to obtain useful information, there will continue to be data breaches.  All we can do is make it as difficult and unrewarding as possible.

Breach Insurance – A Bad Joke?

I had a client ask me today about data breach insurance and had to do everything I could to keep from laughing.

In my humble opinion, data breach insurance is possibly the biggest license to print money ever found by the insurance industry.

I have read a number of these policies and they read like a Who’s Who of security best practices.  They require an organization to ensure that they follow these best practices to the letter making it virtually impossible to collect.  Remember, security is not perfect.  Just some samples of the requirements I have seen in these policies include:

• Your organization must conduct monthly or more often vulnerability scans and penetration tests;
• You need to have a CISSP or other relevant certified individual on staff;
• You need to have a dedicated CISO or similar person overseeing security;
• You need to diligently follow specific standards such as the PCI DSS, GLBA, HIPAA or similar;
• You need to follow NIST, NSA or other relevant security guidelines.

Miss any one of these requirements, and you cannot file a claim against your policy.  Based on the requirements I have seen, compliance with the PCI DSS is a cake walk.

And just like the PCI DSS, suffer a breach and you are required to have an independent forensic examination conducted.  If this examination turns up any, and I do mean any flaws in your implementation of these best practices, you claim will be denied and your organization is responsible for the cost of the examination and all other related costs.  Can’t wait to sign up can you?

But, it gets even better.  Analysis of the premiums related to these policies and the costs involved in meeting the requirements to even have a chance to file a claim are such that over a five year period, your organization will likely pay just as much, if not more, than the coverage of the policy.  To add insult to injury, most organizations figure that their ability to file a successful claim is less than 5% because their own internal audit findings indicate that they cannot execute their existing security procedures consistently.

Bottom line.  Ask lots and lots of questions of the underwriter if your management is bent on getting one of these gems.  Focus on what’s necessary to collect.  Keep a tally of the costs to maintain compliance including any new tools and personnel that might be required.  Once the costs of compliance are known along with the premiums, I think your management will see that it’s likely cheaper to self insure.

Stick or Carrot?

Over the weekend, Visa released a statement on the Heartland and RBS WorldPay breaches.  In addition, the Deputy Chief Risk Officer was given a chance by InformationWeek to rebut their complaints regarding the relevance of PCI DSS compliance.  I am concerned about the mixed messages these two articles have for organizations trying to get to and maintain PCI compliance.

The Visa announcement regarding Heartland and RBS indicates that Visa is going to bring out a pretty big stick against these two organizations.  They have been delisted from Visa’s compliant processor list and have been told to conduct new PCI Report On Compliance (ROC) assessments.  However, unlike CardSystems almost three years earlier, Visa stopped short of giving either a death sentence by saying they would refuse to accept transactions after a certain date.  A number of security analysts complained about this saying that Visa should have been harder on both processors.

On the same day, InformationWeek released a rebuttal by the Deputy Chief Risk Officer of Visa, Adrian Phillips, on why PCI compliance is still relevant.  For those of you not following InformationWeek, they have been hard on the PCI Data Security Standard.  At the end of his article, Mr. Phillips states:

“In sum, there’s no silver bullet when it comes to protecting consumer data. As criminals get better at what they do, our efforts to stop them must keep pace. We should continue to explore new tools to help prevent or limit fraud in our system, including encryption, authentication technology, and customer alerts. But while we evaluate the costs and merits of these additional solutions, we must continue to deploy the best tools we have available today to fight fraud–starting with the PCI DSS. PCI DSS compliance simply remains the best defense for businesses against the loss of sensitive consumer information.”

If you are like me, you are scratching your head and saying to yourself, “What’s going on here?”  However, take a step back and think about it a bit.  While on its face, the two statements seem a bit schizophrenic, they are actually somewhat compatible.  Although, I would argue that eventually, Visa and the other card brands will have to pull back on the ‘really big stick’ approach and adopt more of the ‘carrot’ method, at least as it comes to its processors.

Why?  Because eventually, merchants will have systems that do not store cardholder data.  And those large merchants that do their own centralized switching of transactions and processors will have no choice but to continue to hold cardholder data for a variety of reasons such as recurring payments, loyalty programs, fraud analysis and other worthwhile business purposes.  They will become the targets along with the card brands’ systems.  And, as Mr. Phillips points out and I have argued in an earlier post, security is not perfect and all we can do is be diligent in protecting cardholder data.

As a result, Visa and the other card brands will have to get out of the penalty game with their processors and large merchants because no one has a perfect security environment and no one ever will.  If that is the case, how can the card brands justify the ‘big stick’ approach if security cannot always be maintained?  They cannot and ultimately they will figure this out.  Let us just hope they wise up soon.

Why Staying Compliant Can Sometimes Be Difficult

I ran into some situations in the last couple of weeks that are good examples of why organizations need to be diligent in maintaining their PCI compliance and why the annual PCI assessment can assist in that effort.  The reason I bring this up is that I’m starting to hear many organizations pushing back on annual assessments as the economy tanks.

In the first instance, we were assessing an application that we had assessed for the last three years and had found to be PCI compliant each time.  This is a Web-based application that transmits credit cards to a back end solution that then conducts the transaction and generates a receipt that is passed back to the customer.  Last year, the back end application was rewritten to improve its PCI compliance so that a compensating control could be eliminated.  We reviewed the new version of the back end application before assessing the Web-based front end.  After reviewing all of the documentation, we found the back end application to be PCI compliant.  However, when we reviewed the Web application that had not changed, we found an issue.  Unlike in years past, we found credit card numbers in this application’s log file.  Turns out that when the new version of the back end application finds an issue authenticating a credit card, it returned the credit card number back to the Web application which in turn put the information in its log file for later debugging of the problem.  The organization is in the process of correcting this situation.

In the second instance, the organization’s security personnel were conducting a follow up on an issue from our last year’s assessment.  In following up on that issue, they found that a temporary file that was supposed to be deleted at the end of every transaction was not being deleted.  We had investigated the temporary file during the previous year’s review and had confirmed that the file was encrypted and being deleted.  However, between the time of our review and the time of the follow up, something had gone wrong and the temporary file was no longer being deleted.  In fact, it had grown to contain a significant number of credit card numbers.  Worse yet, the file was being backed up unencrypted.  Since the temporary file was never expected to be backed up, they had never ensured that the file would be encrypted on their back ups.  While they have fixed the deletion problem, the data remains on backups and this organization is struggling with how to purge the data off their backups that are required to be retained.

Without diligence, these two organizations would likely have ended up with significant problems resulting in an inability to be PCI compliant.  However, because these issues were uncovered in a timely manner, both organizations have a better than average chance of addressing these issues and maintaining their compliance.

PA-DSS Certified – So What?

I have written about this before, but this needs to be discussed again.

A lot of applications are becoming PA-DSS certified and yet I continue to see the same issue occur over and over again with the vendors of these applications just like we saw with the PABP certification.  These vendors all think that because their applications are PA-DSS certified that their customers are automatically PCI compliant.  Wrong!  PA-DSS certification never implies PCI DSS compliance and visa versa.  PA-DSS certification merely means that the application properly processes, stores and/or transmits cardholder data (CHD) as long as it is properly implemented.

Properly implemented?  How do I know that I have properly implemented my PA-DSS certified application?  As part of the PA-DSS certification process, the vendor must provide a guide for implementing their application so that it retains it’s certification.  And that’s the first problem.  I’m still seeing a lot of applications that do not have an implementation guide to explain what needs to be done to ensure the PA-DSS certification can be maintained.  I’m not sure how these applications got their certification without this necessary requirement, but that’s for another discussion.  So, what’s the big deal?  The big deal is that without this information, it’s impossible to know if the application has been properly implemented to secure CHD.  And without that knowledge, a QSA will have to fully assess the application to ensure that it meets the PCI DSS requirements, thus making the PA-DSS certification pointless.

Speaking of pointless, there are some applications that are certified and there is no way to implement them without customizing them.  Since the certified application is essentially just a framework, only the framework is certified.  Thus, there is no way that the certification can be maintained because there is no way to implement the application without significant modifications.  I cannot tell you the grief I encounter when I have to review such a solution top to bottom since it no longer resembles the application that was certified.

Then there is the vendor’s response when you have to go back to them with questions because the implementation guide does not exist.  It’s as though you slapped them in the face.  They are indignant and sometimes very rude regarding the fact that you have questions.  Why?  Because, they think that because the application is certified, that’s all that’s needed and you are way out of line for having questions.

So, vendors, chill.

UPDATE: We were told at our 2009 re-certification training that framework applications will no longer be allowed to be PA-DSS certified because they are only frameworks.

In Scope versus Out of Scope

Here a topic that drives a lot of discussion and can, at times, create rifts between an organization and; their ASV, their QSA, their processor, or even the card brands.  By definition:

• Anything is considered in scope if it either processes, stores or transmits cardholder data (CHD); and
• CHD, at a minimum, is the cardholder’s name, the primary account number (PAN) and the expiration date.  Any additional information from a credit card such as CVV/CVC/CID and track data is also considered CHD, but it may not be stored except during the authorization of a transaction.

One would think such simple definitions would make this all clear.  However, there seems to be a lot of interpretation as to what is considered in scope.  And it’s all of this interpretation that is causing problems and consternation.  So I’m going to make an attempt to clear this up.

First let’s talk about applications because those are typically the easiest to identify as in scope.  An in scope application is one that either processes, stores or transmits CHD.  Obvious examples of applications that meet this criteria are integrated point of sale, an e-Commerce shopping cart and centralized credit card authorization and settlement.  Where it becomes tricky is when it is not clear if the application processes or transmits CHD.  Another tricky area is when the application in question is PA-DSS certified.  All PA-DSS certification means is that the application, when implemented to the vendor’s documented specifications, processes, stores and/or transmits CHD in accordance with PCI standards.  PA-DSS certification does not imply that the implementation of that application meets the PCI DSS requirements.  The implementation needs to be assessed to ensure that it was implemented to the vendor’s specifications to maintain its PA-DSS certification.  Once deemed to be compliant with the PA-DSS, a QSA can then rely on the PA-DSS certification to cover a number of PCI DSS requirements.

Where I see the most issues with in scope is around the network and servers.  So, let’s go back to our definitions.  If it processes, stores or transmits CHD, then it is in scope.  Servers are in scope if they process, store or transmit CHD such as with database servers and application servers.  Pretty straight forward as long as you can identify all of your databases and applications that are in scope.  Networks are in scope if they process or transmit CHD.  This is where network segmentation becomes important to minimize in scope items.  [See my entry on Network Segmentation for a full discussion on that topic.]  Where the network in scope issue becomes stickiest is when appropriate segmentation has not been maintained.  It is then that all devices on the network end up in scope because oneor more devices on the same network are considered in scope.

External vulnerability scanning and penetration testing also causes problems with a determination of what is in scope.  External vulnerability scans and penetration tests are only required when CHD is processed, stored or transmitted over the Internet.  Such applications would be any e-Commerce on your organization’s servers and/or networks.  If you totally outsource your e-Commerce or do not have e-Commerce, then external scanning by an ASV and conducting penetration tests is not required as there are no in scope applications or devices.  However, as a best practice, you should conduct external vulnerability scanning at least annually or whenever you make any significant changes just to make sure your security measures are functioning properly.  Internal vulnerability scanning and penetration testing is required at least quarterly or whenever significant changes are made to your internal PCI in scope environment.  However, those do not require an ASV to perform.

Hopefully I’ve cleared the air on this simple, yet demanding, topic.