Archive for April, 2011


QSA Re-Certification – 2011 Edition

It is that time of the year, time for the PCI Guru to take the PCI SSC’s QSA re-certification training and test.  As with last year, the process is all online.

The process started this year with our Key Contact person emailing me the invoice for the training.  Since the PCI SSC is creating individual invoices for each QSA to be trained, our firm is requiring the invoice to be paid by the QSA and then expensed through the firm’s expense reporting system.  Why the PCI SSC cannot just issue a single invoice for a firm and get it over with, I just do not know.  I had to fax the invoice into the PCI SSC with my credit card information.  They make it very clear that they have a secure fax server.  I will say this, I faxed in the invoice on Monday and by Tuesday I had my logon credentials for the training and examination.  So the registration process is very quick.

The PCI SSC appears to have contracted with a new CBT provider that has better capabilities than last year’s provider.  The site is simple but functional and easy to navigate.  I did have some issues with getting the training content to process properly.  From time to time, I would get messages indicating that there was a “bad URL” supplied.  This appeared to be related to timeout issues as I could click again on the content and it would eventually be displayed and played.

The training is broken into four modules.  The first module covers the usual topics related to the PCI SSC, the various PCI standards, card processing and other general topics.  The second module covers an overview of the PA-DSS, roles and responsibilities of the various PCI players, validation requirements and overview of the PCI SSC’s assessor quality management (AQM) program.  The third module is all about the PCI DSS v2.0.  The fourth and final module covers miscellaneous topics such as virtualization, documentation required for Report Of Compliance, cardholder data discovery, scoping the cardholder data environment and compensating controls.  There are quizzes at the end of each module to test how well your retention is on the material covered.  Each quiz is around eight questions and the questions seem to be representative of what is on the examination.  According to the documentation on the Web site, this material takes around six and a half hours to cover.

The examination is comprised of 60 true/false and multiple choice questions.  You are given four hours to complete the examination and, according to the documentation, you can pause the examination any number of times and come back at a later time to complete it.  You only get one chance to go through the examination, so being able to pause it is nice to have available should you get an interruption.  I am not sure whether you can skip questions and come back to them later.  It took me about 45 minutes to go through the test and I had some interruptions.

I liked the new Web site but was frustrated at times that content was not always available.  I am not positive if the problem was at my end or the CBT provider’s.  But since I was on a couple of different networks while I went through the content, I am guessing the problem was with the CBT provider as I got the content availability errors on all of the networks I used.

As with last year, the training slide decks are not available for download.  I just do not understand why the PCI SSC does not make the slides and notes available as one or more PDFs.  Not only would it be useful for offline review, but it would also be nice to have as a reference.  I am guessing that they feel that people who have the training material available longer than others have a better chance at passing the examination.

Of the four modules, module three is probably the best of the lot because of its discussion of the PCI DSS.  Each of the 12 requirements is organized around:

  • The general concept of the requirement;
  • Understanding the requirement; and
  • Assessor recommendations.

The general concept of the requirement is just a re-iteration of what is in the preamble of the requirement as written in the PCI DSS.  The Understanding discussion goes into a more detailed discussion of the various high points of the requirement (i.e., the X.1, X.2, X.3, etc. level).  Not only are these sub-requirements generally discussed, but there is also a discussion about why these sub-requirements are necessary.  These first two items are very useful for training clients about why the PCI DSS process is necessary.

The real value though is with the assessor recommendations.  For the first time, the PCI SSC goes on the record and states, in general terms, what types of observations, interviews and documentation need to be obtained and reviewed by the QSA to ensure the requirements are satisfied.  Based on some of the Reports On Compliance I have seen lately, I think a lot of QSAs are going to find out that what they are currently doing for fieldwork is not acceptable.  This information would also go a long way to helping clients appreciate why a Report On Compliance takes the amount of time and money it takes.

The examination is similar to last year’s re-certification examination – a variety of true/false and multiple choice questions.  The questions appear to be written to focus the QSA on black and white issues and to avoid any nuances.  For example, I had a true/false question that stated, “An application that processes, stores or transmits cardholder data sold to a single merchant by a software company must be PA –DSS certified.”  Now, I know what they are trying to get at with this question and the answer is false.  However, the real answer is not so simple and depends on the software vendor.  If we are talking MICROS as the vendor, there is a high likelihood that the software will be resold to more than just one organization, so the software should go through the PA-DSS certification process.  Regardless of whether or not software is PA-DSS certified, the bottom line is that a QSA is going to be required to assess the application for compliance with the PCI DSS and will have more work effort if the software is not PA-DSS certified.

In the end, the good news, or bad news for some of you, is that I was re-certified to be a QSA for another year.


An Update On The MPLS Privacy Debate

The MPLS private network discussion continues.

A lot of network administrators and carriers argue that MPLS networks are private because the PCI SSC says they are private.  As more and more organizations migrate from ATM and Frame Relay, this topic keeps coming up again and again lately.  Because of the push back from carriers and network administrators, I went back and re-read FAQ number 8705.

“In general, MPLS networks are considered “private” networks and do not require encryption. This, however, is dependent upon the specific provider and/or configuration. If the IP addresses are public and the MPLS network provides exposure to the Internet either through the LSR or other device (if the edge router has an Internet port) then it should be reviewed carefully as it is likely considered “untrusted”. The QSA should review the implementation and determine whether the IP addresses are public such that the MPLS network provides exposure to the Internet, before concluding that the MPLS network is considered private. If the QSA cannot gain that assurance, then the whole network should be in scope. The PCI SSC is not compiling a list of approved MPLS solutions nor do they have any plans to do so. This requirement for encrypted transmissions is intended to apply to transmissions outside of an internal network to an external third party, going over an open, public network; this requirement does not apply to transmissions over an internal network protected by external facing firewalls, since that is not considered a public network.”

Apparently, carriers and network administrators only read the first sentence of the FAQ and conveniently forget the next three sentences.  But it is those three sentences that document the criteria to determine whether or not an MPLS network is private.  The criteria a QSA is to use to evaluate an MPLS network’s privacy are:

  • How is the MPLS network configured?
  • Does the LSR come into direct contact with the Internet?

While these appear to be fairly simple questions to be answered, these questions are anything but simple or even easily answered.

The first question, how is the MPLS network configured is a problem for a lot of QSAs and network administrators as well as carriers.  MPLS is just a specialized IP network, so how the network is engineered drives just how private is private.  The problem with relying on IP addressing as the only criteria of whether or not an MPLS network is private is not proof positive.  I would argue that, even if the IP addressing on the MPLS network is RFC 1918 compliant, if the subnet is not the same as the network connecting to the network, then a QSA should look into the network to confirm that it is private.  This is particularly true if the addressing on the MPLS network is an ARIN registered address block belonging to the carrier.  Yes, such a network would be private for the carrier, but could be anything but private for the carrier’s customers’ traffic.

The second question is also not as straight forward to answer.  Just because private addressing is used on the MPLS network does not mean that it does not come into contact with the Internet or Internet traffic.  Unless you have visibility through the entire network and the rules used for that network, it is anyone’s guess as to whether or not it comes into contact with the Internet.

Of course all of this implies that the carrier is willing to show you their MPLS network configuration and share other information about their MPLS network.  But getting such a candid talk about a carrier’s network is sometimes anything but easy.  I have personally encountered carriers that refused to explain anything about their network and also refused to allow anyone to look at their LSR configurations.  As a result, we had no way to confirm or deny that the network was private.  To add insult to injury, I have been told by carriers that I was wrong in requesting to look into the configuration of their network and that this was not what the PCI SSC intended.  That said, I have also jumped through hoops to work out a way to confirm as best I could that the MPLS network was private.

MPLS is just an IP-based wide area network and because it uses IP, it can have a number of vulnerabilities just like IP networks.  Carriers use human beings to manage these networks and they are fallible just like our own employees.  Therefore, it is highly likely that mistakes will sometimes occur that will affect the privacy of the network.  I am guessing that once we have a breach in the MPLS cloud, MPLS will no longer be automatically considered private and encryption will be required.

And it is not just MPLS networks.  Most ATM and Frame Relay networks are routed over MPLS backbones by the carriers.  So just because you do not use MPLS does not mean that you are immune to the risks of MPLS.

In the end, we will have to rely on the statements and representations of the carrier as to whether or not the network is private.  Is this a good way to secure your organization?  It is as long as your carrier never causes a problem.


What Can We Learn From The Epsilon Breach?

April Fool’s Day 2011 will go down in history as one of the worst April Fool’s Days in history.  For on this past April Fool’s Day, the Epsilon Data Management breach was announced.  At first, it was considered just another April Fool’s Day Internet joke, but it has since turned out to be anything but funny.  More than 60 organizations have been affected by this breach and the count just keeps going up.

According to Epsilon’s parent’s news release on April 6, the good news is that Epsilon personnel detected the breach quickly and shut it down.  However, the attacker got away with 2% of Epsilon’s database for email generation.  When you consider that an organization like Epsilon has around 300M or more email addresses in its database, a 2% loss is still a large number at six million plus.  But this breach is the gift that keeps on giving, so there could be more to the story as time goes on.

The thing I found the most interesting is that Epsilon has reiterated in all of their statements that no personally identifiable information (PII) was released in this breach.  However, what Epsilon has been very silent about is whether or not demographic information was taken as a result of the breach.  Demographic information is not PII, so their statements to the press are accurate.  However, their statements, no matter how accurate, may be misleading if demographic information was obtained.  Based on my work with companies like Epsilon and how they operate, one has to assume that there was demographic information taken in addition to names and email addresses.

One of the first questions I got regarding the Epsilon breach is whether or not it mattered for PCI?  After all, no PII was released, so what is the big deal?  I was stunned.  Of course it matters, it matters a lot.  I reminded those who questioned this that while the Epsilon breach did not release any PII, the attackers likely have enough information in their possession to mount the mother of all spear phishing attacks to obtain the PII from the source.

But even with all of that, the Epsilon breach offers some good lessons regarding PCI compliance and why you should be doing what the PCI DSS requires.

  • Security is not perfect. I know I keep beating the drum about this, but people still seem to think that security is perfect or they think that I am just trying to give myself an out when a breach occurs.  However, this statement has never been truer.  While I cannot personally attest to the level of Epsilon’s security and procedures, the information released thus far seems to indicate that Epsilon’s security was above average.  I base this on the facts that the breach occurred on March 30, was announced on April 1, that only 2% of their data was compromised and only their email system was involved.  If they were not doing the right things, then all of this information would have been a very long time coming.  However, even with an above average security posture, Epsilon was still breached.
  • Monitoring matters. Epsilon appears to have caught this breach quickly because they must have been monitoring their network and systems.  What this incident points out is that even when you are monitoring your environment, it takes a while to recognize that a breach is in progress and then act upon that information.  As a result, information was still obtained by the attacker.
  • Logging matters. As I stated in my comments regarding security not being perfect and monitoring, there is just too much information about this breach to believe that Epsilon was not doing an appropriate amount of logging.  In addition, if I had to guess, they were also likely analyzing their logs in real-time which is why they so quickly identified the breach and were able to determine how much information was likely involved.  The bottom line is that with this excess of information available for analysis, Epsilon was able to identify and isolate the breach.
  • An incident is never good. Someone once said, “Bad publicity is better than no publicity at all.”  Unfortunately, when a breach occurs, the bad publicity generated does no one any good that is associated with the breach.  However, this leads to my last learning point.
  • Incident response planning matters. Look at how this incident has been handled and how quickly it was handled.  This was not done be a group of people navigating this incident by the seat of their pants.  This incident was planned for and they are working their plan.  Since the incident was identified and quantified quickly, they issued a press release as soon as they could with a lot of information.  Yes, this could all still be theater, but I highly doubt it.  There has just been too much information and knowledge shared to think it is all a show.

Spear Phishing Season Is Declared Open

With the Epsilon breach announcement of last Friday, it seems every merchant under the sun is notifying their customers of the expected onslaught of electronic mail messages asking for bank account and credit card numbers among other personally identifiable information (PII).  Just in the last two days, I have received at least a half a dozen messages informing me of this possibility.

The result of this breach is likely to be the best spear phishing attack we have seen to date.  These phishing attacks will likely be highly targeted since the people that took the information from Epsilon know not only your name and email address, but also the merchant that the email address belonged.  While Epsilon states that only names and email addresses were taken, I would also think that all sorts of demographic information necessary to make these attacks very focused was also obtained.  That will mean the percentage of people responding to them will likely be higher than usual because of the level of detail that the attacks will be able to rely upon for targeting.  As a result, a lot of credit card numbers will likely get exposed.

So let us be prepared.  Even though you send out messages to your potentially affected customer base warning them of this possibility, there will likely be a lot of your customers that will end up getting caught in whatever scams get dreamed up.  Therefore you probably need to get your legal counsel up to speed as Epsilon and your company will likely end up embroiled in lawsuits regardless of the amount of warnings you issued.

Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

April 2011