Archive for May, 2010


Where Do I Find PCI Information?

This is a common question that comes up.  Where do you find all of the information on the PCI standards?

The first place to go looking is at the PCI Security Standards Council (SSC) Web site.  The PCI SSC Web site has a number of resources that you need to check out.  These include:

  • The PCI Data Security Standard (DSS), the Self-Assessment Questionnaires (SAQ), Payment Application Data Security Standard (PA-DSS) and PIN Transaction Security (PTS)
  • Frequently Asked Questions (FAQ)
  • Information Supplements
  • Locate a Qualified Security Assessor (QSA), Qualified Security Assessor Company (QSAC), Payment Application QSAC (PA-QSAC) or an Approved Scanning Vendor (ASV)
  • PCI training

The FAQ is where the PCI SSC posts all of the questions and answers about the PCI standards.  Questions can be asked by anyone accessing the Web site.  The answers come from representatives of the card brands with the PCI SSC staff collecting and publishing the card brands’ agreed to responses.  Answers to questions typically take four to six weeks to obtain an answer.  However, it is not unusual for answers to take quite a while.  For example, in the case of securing pre-authorization data, it has been almost four years and we are still waiting for a response which the PCI SSC has promised they will deliver in the coming year.

Information Supplements are white papers written by various authors (usually PCI SSC staff or the card brands) and approved by the PCI SSC and the card brands that discuss a PCI standard requirement in detail to further explain a requirement and explain how a merchant or service provider can meet the requirement.  Informational Supplements that have been published thus far include:

  • Skimming Prevention: Best Practices for Merchants
  • Wireless Guidelines
  • Requirement 6.6 (Application Code Reviews and Application Firewalls)
  • Requirement 11.3 (Penetration Testing)

The PCI SSC has indicated that more Information Supplements are going to be issued in the future instead of updates to the standards.

Locating a QSAC, PA-QSAC and ASV is provided by a PDF list for each type.  Individual QSAs can be looked up by their name so that you can confirm they are in fact QSAs.  The PCI SSC recently sent out a clarification in one of their newsletters to QSAs discussing the fact that once a QSA leaves their QSAC; they need to join another QSAC who applies to have them transferred by the PCI SSC to retain their QSA certification.  If they do not join another QSAC, they are no longer allowed to use the QSA designation.  So, it is important to confirm that the people and firms you are talking with are in fact QSAs and QSACs.

If a QSAC is listed as in remediation does not mean that the QSAC and their QSAs cannot continue to perform PCI assessments, this just means that the QSAC was found deficient in meeting the documentation and reporting standards of the PCI SSC.  Even though the PCI SSC issued a well written release on the meaning of remediation, a number of unscrupulous QSAs are telling prospects that because a QSAC is in remediation, it cannot perform PCI assessments.  This is patently false and any QSA that makes such a statement should be reported to the PCI SSC for telling such a falsehood.

Of course the most obvious thing provided by the PCI SSC’s Web site is the standards themselves.  Unfortunately, without the benefit of the PCI SSC’s training program, interpreting the various PCI standards can be difficult, if not impossible.  However, there are a number of independent resources for people to use to get interpretations of the PCI standards.  One that I have actively participated in is the Society of Payment Security Professionals (SPSP) Forum.  There is also the PCI Knowledge Base that has a large contingent of QSAs and other experts that can provide guidance regarding the PCI standards.  There are also forums provided through Yahoo and LinkedIn as well as other similar services, but I am not as well versed in the accuracy of the information provided through those venues so I cannot recommend them.

So the next time you are looking for information regarding PCI, here are some resources you can use.


Passing The Buck

When you are providing services to customers and those services are in-scope for compliance with any of the PCI standards, do not be shocked when your customer’s QSA asks you to prove that you are complying with the relevant PCI standards.  What sort of services are we talking about?  While not a completely inclusive list, here are some of the most common services I run across that are in-scope for PCI compliance.

  • Network management.  This includes management and/or monitoring of firewalls, routers, switches, etc.,
  • Server management.  This includes configuring of servers, patching of servers, add/change/delete of user accounts, monitoring of servers, management of server log files, etc., or
  • Network security management.  This includes management and/or analysis of infrastructure and/or server logs, monitoring of security devices such as firewalls and IDS/IPS, incident response, etc.

The most common point of confusion I run across is with those third parties that are providing network management services.  If the service provider is only providing a telecommunications circuit, then the service provider is not in-scope of PCI compliance.  This fact has been confirmed time and again by the PCI SSC.  However, once you start to be responsible for managing routers, switches or other networking infrastructure, those services are in-scope for PCI compliance.

What I think these service providers forget is that it is not just the storage of cardholder data that is the concern of the PCI standards.  It is the processing and transmission of cardholder data that is also covered.  Now, if cardholder data transmissions are encrypted and the third party does not have the ability to decrypt those transmissions, then the third party is not in-scope.  However, where service providers get in trouble is that the data stream is encrypted at the router that they manage or they manage other devices that come into contact with unencrypted data.  They think that because they are off the hook in one instance, they are off the hook for all which is not the case.

If your company is managing customers’ networks, then explain just how your customers can respond to the following sample of network management compliance tests from the PCI DSS.

  • 1.1.1 – Verify that there is a formal process for testing and approval of all network connections and changes to firewall and router configurations.
  • 1.1.4 – Verify that firewall and router configuration standards include a description of groups, roles, and responsibilities for logical management of network components.
  • 1.2 – Examine firewall and router configurations to verify that connections are restricted between untrusted networks and system components in the cardholder data environment …
  • 1.2.2 – Verify that router configuration files are secure and synchronized—for example, running configuration files (used for normal running of the routers) and start-up configuration files (used when machines are re-booted), have the same, secure configurations.

The bottom line is that your customers cannot respond to these requests if your organization is performing them, just ask your customers.  They expect as part of your service agreement to respond to these requests.  Given the ingenuity of entrepreneurs, almost anything can be outsourced for a price, hence why each service that is outsourced needs to be addressed individually to determine whether or not the service is in-scope for PCI compliance.

For those service providers that are reading this and are still unconvinced, I would ask you this question.  If your organization is not responsible, then who is?  Your customer contracted with you to perform the service; therefore they no longer have the knowledge to respond to anything regarding these requests.  If they cannot respond, then who does respond?  And I would point out that if a QSA cannot obtain satisfactory responses to these requirements, then the QSA is obligated to mark them as ‘Not In Place’ which means your customer is not in compliance and must  remediate the problem.

I would remind everyone that security is an all or nothing operation.  Either everyone and everything is secure in the business process chain or they are not secure.  All it takes is just one weak link and the party is over.  We live in a very interconnected world and therefore the security of any one entity can make or break the security of all others.

And if you are still unconvinced, I would have you ask your attorney what happens if a breach occurs at one of your customer’s and is the result of your organization’s failure to comply with one or more of the PCI DSS requirement that caused the breach?  My guess is that your attorney will tell you that you are legally on the hook and that likely all fines, penalties and any other sanctions will be against your organization, not your customer.

And finally, if you are still saying this is all BS, then you better get out of this business because this is what is coming down the line.  QSAs are just the messengers, so do not complain to or about us.  It is the PCI SSC and the card brands that set the rules.  And the PCI SSC is cracking down on QSAs and making sure that we all consistently interpret the PCI DSS and other standards.  So the fact that “no one has asked us about this before” is rapidly coming to an end as every QSA will begin asking for your compliance.

As they like to say, “If it’s too hot in the kitchen, then maybe it’s time to get out.”


Annoying Requirements – 9.7.1

There are some requirements that just seem silly and appear to have no real purpose other than to be lightening rods for PCI DSS naysayers as why the PCI DSS is an inconsequential standard.  One of those requirements is 9.7.1 which states, “Classify the media so it can be identified as confidential.”

I think we all understand what the PCI SSC is getting at here.  They want to make sure that all removable media, in particular magnetic tape, is labeled as “classified” so that if any removable media goes missing, people that find any such media know that it is to be treated as confidential and not be released in the public domain.  This is predicated on the idea that people are basically honest and would obey such a labeling and would not investigate further.  However, the people that are the threat could really care less that the media is labeled confidential, that is why they want to get a hold of it.

Then there are the security experts that argue that by labeling something as ‘confidential’ all you are doing is further identifying the media as something that needs to be further examined by a person to see why it is confidential.  After years of conducting social engineering testing, I tend to agree with these experts.  Human nature just begs some people to find out why something is labeled ‘confidential’.  This is why leaving thumb drives or CD-ROMs in parking lots labeled ‘Customer List’ and sending out spam with links to the latest naughty celebrity interview, pictures or video still are very effective social engineering ploys.

The PCI DSS was created with numerous requirements that cover one another such that if one requirement is not performing completely, the other requirements will fill the gap.  In this case, there are a number of other requirements that cover 9.7.1 such as:

  • 3.1 – Keep cardholder data storage to a minimum.
  • 3.2.1 – Do not store the full contents of any track from the magnetic stripe
  • 3.2.2 – Do not store the card-verification code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions.
  • 3.2.3 – Do not store the personal identification number (PIN) or the encrypted PIN block.
  • 3.4 – Render the PAN, at a minimum, unreadable anywhere it is stored (including on portable digital media, backup media, in logs).
  • 9.5 – Store media back-ups in a secure location, preferably an off-site facility, such as an alternate or back-up site, or a commercial storage facility and review the location’s security at least annually.
  • 9.6 – Physically secure all paper and electronic media that contain cardholder data.
  • 9.7.2 – Send the media by secured courier or other delivery method that can be accurately tracked.
  • 9.9 – Maintain strict control over the storage and accessibility of media that contains cardholder data.
  • 9.9.1 – Properly maintain inventory logs of all media and conduct media inventories at least annually.

Even if these other requirements are not met, just what does the PCI SSC and the card brands think a label is going to do?  It does nothing to improve security and ends up as “make do” work for some clerk to label all tapes, CD-ROMs, thumb drives, etc.  The epitome of those Dilbert cartoons from the 1990s that lambasted the ISO 9000 compliance craze.

To comply with this requirement, all I ask my clients to do is to declare all information, at a minimum, as confidential or whatever their second lowest data classification is called.  That way all employees know that, at a minimum, all information they come in contact with is confidential.  As such, they are not to share this information with anyone else unless there is a valid need to know that information for someone to complete their job.  But I do not require them to label removable media as ‘confidential’.

The message to the PCI SSC, get rid of this requirement.  It does nothing to improve anyone’s security.


Another Mindless Attack On The PCI DSS

Last week, Josh Corman of The 451 Group gave a speech at Interop in Las Vegas bemoaning the shortcomings of the PCI DSS.  Not only that, he stated that the PCI DSS is not protecting credit card data and the coming updates to the standard will not improve things.  So what did Mr. Corman suggest we do to improve things?  Nothing.  All he did was complain.  Supposedly, Mr. Corman is a leader in the security industry.  As a leader, do not whine and complain, give us some specific suggestions and guidance to improve things.

His first complaint is that the PCI DSS does not specifically address cloud computing.  Why does a security standard have to address a specific type of computing platform if it is not necessary?  The PCI DSS does address the differences of hosted computing environments of which cloud computing belongs.  However, the remainder of the PCI DSS should apply to any environment – hosted, cloud, whatever you choose to call it.  The PCI DSS is structured so that it addresses only those platform differences that are truly different.  For example, a change that is coming in the new version is requirements to address specific differences to virtual computing environments.

What I think Mr. Corman is complaining about is those of us in the PCI compliance business that have discussed the problems with PCI compliance in the cloud environment.  While the cloud computing movement offers some significant savings, it also opens up a number of new issues in meeting PCI compliance.  What I think Mr. Corman was implying is that he wants rules to get around these issues so that merchants can be even more insecure, but reap the benefits of cloud computing.

The problem with cloud computing is not that it cannot be secure and comply with the PCI standards.  The problem is that, like every other “next best thing computing platform” before it, cloud computing is moving faster than people can understand and secure it.  We do not even have a standard definition for cloud computing yet, let alone understand all the aspects of securing it.  As a result, early adopters are finding all sorts of flaws and issues that need to be addressed to improve security and PCI compliance.  So, by all means, we should all jump on the bandwagon before those issues are resolved so that we can all suffer from poor security together.  Great leadership.

Another point he makes is that patching does not prevent breaches.  He uses the statistics from the last Verizon Business Services report that stated that of the 90 breaches they investigated; only six were related to patching issues.  Therefore, Mr. Corman says the statistics do not support patching as a critical activity.  This is a damned if you do, damned if you do not issue.  The problem is that most organizations patch when they feel like it, not when they truly need to patch.  As a result, some patches are applied timely while others may not get applied until a problem occurs.  The real way to patch is to base patching on criticality and relevance to your environment.  Unfortunately, Microsoft, Sun, Red Hat and others do not make this sort of analysis easy to perform.  IBM and their PTF process for mainframes, does do this.  So, vendors need to take a page from the IBM mainframe playbook and start to make some sense out of patching so that it is not just a “throw it against the wall and see what sticks” type of approach.

That said, there has to be something done about patching.  While the PCI DSS does quote an arbitrary 30 day requirement, most QSAs I talk with understand that as long as an organization has a reliable and auditable patching process, it does not matter the speed with which the patches get implemented as long as they are implemented.  The problem is that most small and mid-sized merchants are very sloppy about patching.  As a result, the 30 day requirement was for their benefit so that they know there is a time limit.

His final remark that tweaked my craw was that “The bottom line is that there isn’t enough data to know whether PCI works or not and whether security controls businesses would have put in place in the absence of PCI might have worked better.”  Obviously, Mr. Corman has never been out in the field or he would know better.  In the organizations that I have worked with, the PCI DSS was the catalyst to shedding light on security and operations practices that were believed to be working.  However, detailed examination for PCI compliance determined that these practices were, in fact, not working and in some cases were not being performed at all because people did not understand their importance.  In other cases, while the practice was being followed, it needed changes so that it was properly focused on identifying issues and threats.  These organizations are all Fortune 1000, so one would think they have the experience and maturity in security that small and mid-sized companies do not.  However, until they had the PCI DSS to use as their baseline, they had no idea of the issues they faced.

Mr. Corman’s comments imply that security people know the right things to be doing and do them.  However, experience shows that every security person has their own ideas of “best practices” and those do not always add up to what the PCI DSS is requiring.  However, Mr. Corman is right in that the PCI DSS is only the start.  In order to be truly secure, an organization will need to go above and beyond the PCI DSS requirements to be secure.

Just like security is not perfect, neither is the PCI DSS.  However, barring any new approaches, it is the best we have at the moment to protect credit card information.  I am all for constructive criticism as long as it is backed up with ideas on how to make things better.  So, if Mr. Corman has ideas on how to make it better, then by all means tell us.  Just do not use the bloody pulpit to vent and then expect us to somehow read between the lines.

UPDATE: Please see Mr. Corman’s response to this post in the Comments.


One-, Two-, And Three-Factor Authentication

I have run into it again.  Another organization that thinks two user identifiers and passwords constitutes two-factor authentication and meets PCI DSS requirement 8.3.  With all of the documentation available on the Internet, you would think this topic would be covered cold.  However, there seems to still be confusion regarding what constitutes one-, two- and three-factor authentication, so I thought I would take this time to explain these concepts.

Let us talk about the definitions of the three factors of authentication.

  • One-factor authentication – this is “something a user knows.”  The most recognized type of one-factor authentication method is the password.
  • Two-factor authentication – in addition to the first factor, the second factor is “something a user has.”  Examples of something a user has are a fob that generates a pre-determined code, a signed digital certificate or even a biometric such as a fingerprint.  The most recognized form of two-factor authentication is the ubiquitous RSA SecurID fob.
  • Three-factor authentication – in addition to the previous two factors, the third factor is “something a user is.”  Examples of a third factor are all biometric such as the user’s voice, hand configuration, a fingerprint, a retina scan or similar.  The most recognized form of three-factor authentication is usually the retina scan.

The important thing to notice about the aforementioned definitions is that no where do they mention using two passwords or passphrases, two fingerprints or two retina scans.  Such use of two of the same factors is considered multi-factor authentication and is not related to any of the aforementioned definitions.  So those of you that are using two different user identifiers and passwords are not using two-factor authentication, you are using multi-factor authentication.  The PCI DSS is very specific in requirement 8.3 and requires two-factor authentication or better.  So multi-factor is not acceptable.

Another thing to mention is that security purists will argue that using a biometric for a second factor violates the rules of the third factor.  However, other security practitioners say that something a user has or they are can be either something like a token or a biometric.  Their logic is that a user has a fingerprint or a retina, so it qualifies as either factor.  The key is to only use a particular biometric once.  So if you use a fingerprint for your second factor, you cannot use a fingerprint for the third factor.

Finally, while obvious, a lot of people miss this point.  One-factor is less secure than two-factor which is less secure than three-factor authentication.  However, if users properly construct their passwords or passphrases and other logon restrictions are in place, one-factor authentication can be fairly effective against security breaches, possibly in the 90% range.  Two factor authentication typically raises the effectiveness to probably around 97 or 98%.  And three-factor authentication likely takes things to a six sigma level of effectiveness.  Note that even with three-factor authentication you only get to 99.9999% effectiveness.  As I have repeatedly pointed out, security is not perfect.

A lot of people do not realize the fact that they use two-factor authentication regularly.  In order to use an ATM you need a card (something you have) and a four digit personal identification number or PIN (something you know).  Another example that is common these days is in order to enter secure facilities, an authorized user is required to use their HID access card and enter a PIN into a keypad before a door will open.  Something to note is that it does not matter the order in which the factors are used.  In the case of the ATM and entry examples, you swipe your card (something you have) first and then enter your PIN (something you know).

Just because the second factor is something a user has, does not mean that the user must know they have it.  A prime example is in the case of a digital certificate.  A lot of organizations issue a digital certificate with their VPN software to provide two-factor authentication.  Most users are unaware that they need a digital certificate to make the VPN work.  The digital certificate is usually tied to the user or the computer and is installed as part of the installation of the VPN software.  The only way a user ever becomes aware of the digital certificate is if it is ever corrupted or becomes out dated resulting in an error when they try to connect to the VPN.

Another important point is that in instances where all you use is your HID access card, you are using one-factor authentication.  The definitions for the factors were established for ease of learning and memory.  However, using any of the factors alone is one-factor authentication.  Using each type of factor in conjunction with another, results in two- and three-factor authentication.  As such, you can use different combinations of all of the factors to decrease the likelihood of a compromise.  For example, in a lot of spy movies, there is an ultra-secure room where to gain entry, you need for example an ID card, a PIN, a retina scan and you need to say your passphrase.  This is not an example of four-factor authentication; this is three-factor authentication with the use of two biometric factors (i.e., multi-factor).

Finally, there is a risk in using biometric factors that most people do not like to talk about but is important to consider.  People suffer accidents all of the time.  Fingers get cut or even removed.  Hands get broken or maimed.  Eyes become damaged.  People lose their voices.  As a result, if you are looking to use biometrics for authentication, make sure you plan for such incidents.

Hopefully you now understand the various factors of authentication and understand how they are used.


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

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

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


May 2010
« Apr   Jun »

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

Join 1,884 other followers