PCI Blog - Compliance Demystified

Society going global

Even though we have already trained thousands of merchants, acquiring banks, and service providers in many countries around the world, we have not yet trained these groups in Africa - until now.

The Society of Payment Security Professionals (SPSP) is both attending and presenting an educational PCI conference in Johannesburg, South Africa.  This event will be 27 January 2009 at the Hyatt Regency Hotel. The Society will expand the current educational, training, association and certification opportunities to participants from South Africa.

I met a friend last year who attended one of the PCI training sessions we put on in Prague.  He said, “this is the kind of training we need in South Africa.”  That conversation and many other fortunate events have brought the Society to ZA.  I’m excited about this event because over the past year Africa has put itself on the map as a place for more secure payments.  In addition to South Africa, merchants and banks from other countries have become interested in the Payment Card Industry.  These countries include: Egypt, Algeria, and even Rwanda.

Also, the Society will also be keynoting the ITWeb Security Summit in Johannesburg on 26-28 May 2008.

(In addition to these international events, the Society is also presenting at a number of conferences based in the USA.)

PCI already addresses Virtualization

I’ve written about how PCI already addresses virtualization here, here, and here.  A recent article discusses how PCI needs to address this technology.  My question is why?  Does PCI also need to clearly outline how you should use HSMs, IDS, FIM, user authentication, and firewalls?  Where do we stop?

Some people often complain about how specific the PCI DSS standard is and that it should be more generic to enable flexibility.  But when it comes to technologies they wish to promote, suddenly it is not specific enough.  Why are the current requirements not enough?  I did a podcast on PCI compliance for cloud computing environments and outlined the current rules that already address virtualization.  Instead of pushing for more information around one technology, which will surely change over time, how about simply clarifying the current requirements, such as 2.2.1 the infamous and misused “only one primary function per device”.

I like less complexity and not more.  If the PCI Council did start a SIG on virtualization then there would be another 10-20 page information supplement.  Ok.  Now that document gets added to the pile that needs to be updated with every new version of the standard and as technologies change.  Instead, I would like to see the vendors themselves leading the way and publishing their own “virtualization best practices”.  Let the industry lead the way instead of demanding that someone else read the tea leaves for them.

The basic premise of the PCI DSS is to protect cardholder data.  If you can accomplish this, you are doing the right thing.  Let’s all just do the right thing.

Payment Security Professional of the Year Nominations

I can’t belive the year is almost over.  The Society of Payment Security Professionals (SPSP) has seen great success with a membership of almost 500 and several hundres of those being certified CPISM and CPISA individuals.  The Society board members have put together working groups on Application Security, Network Segmentation, and Legal Issues. Each of these groups is made up on individuals who work to help raise the awareness and clarity on these issues.

The PCI Answers blog had about 200,000 hits.  We keep getting a stream of emails and phone calls for more information and clarification.

Since you have made the Society such great success, we’ve decided to give back to you!  That’s right, the Society is now taking nominations for the Payment Security Professional (PSP) of the year.  Nominations will be collected over the next six weeks and the winner will be chosen by Advisory Board and announced on January 30, 2008.  Here is what you could win:

• 15 in MacBook Pro
• Feature article in Secure Payments, the SPSP magazine set to debut in Q1 2009.
• Highlighted profile on the Payment Security Professional of the Year page
• Recognition Plaque

Did we just say we’re giving away a MacBook Pro?  Oh yes we did!  To nominate someone, please write a 250 word brief on the individual and their contribution to payment security over the last year.

Update: Correction, please read the SPSP is currently taking nominations for PSP of the year.

SaaS Compliance and Levels

A reader recently wrote in and asked about Software as a Service (SaaS) companies and their need for PCI DSS compliance.  Let’s begin by discussing a few terms and then a few reminders about ‘levels’.

A SaaS firm, by definition, is a service provider.  The question is what kind of service provider are they.  If the software the firm provides is not involved in aggregating transactions (i.e. connectivity or remote access software) then they are a generic service provider.  If the SaaS firm does aggregate transactions (i.e. payment processor or shared e-commerce provider) then they are a specific type of service provider called a ‘gateway’.

The most basic definition of a gateway is anyone who sits between the merchant/customer and acquirer/processors for the purposes of authorization/settlement of transactions.  The typical example of this would be a shared e-commerce provider or independent sales organization (ISO) that aggregates transactions.  All service providers that “store, process, or transmit” cardholder data need to comply with the PCI DSS requirements.  One way to avoid this was documented in another post.

Up until recently this definition has been critical, but in February 2009 that is all changing.  Visa Inc. (all regions except Europe) has defined new level definitions for service providers and removed the usage of ‘gateway’ from this definition.  This change does not take effect until Feb. 1, 2009 so companies wishing to validate now should do so under the current rules.

Service Provider or PA-DSS?

Chris asks,

Our company doesn’t do any credit card transactions whatsoever.  However,
some of our clients need to install our software on their back office
computers.  And some of those clients are worried that we aren’t PCI
“Certified”.  How do we assure them that we are OK with PCI compliance
rules?  Is there a certification we can get for our application?

If your company does not store, process, or transmit cardholder data then you do not need to be PCI compliant.  One question for you is if your software is used for the storage, processing, or transmission of cardholder data. Two things:

• If you resell software that is used by others for transaction processing then you may want to look into PA-DSS compliance for your software.
• If you remotely manage that software, such that you could negatively impact the security of cardholder data, then you may be considered a service provider and thus need to comply with the PCI DSS.

If your software is not used for handling payments and you do not have access to your client’s cardholder data environment then you may not need to be PCI compliant.  The question is, are you a Service Provider or do you create PA-DSS applications.

The PCI SSC has language that defines the PA-DSS as it pertains to software vendors:

The PA-DSS applies to software vendors and others who develop payment applications that store, process, or transmit cardholder data as part of authorization or settlement, where these payment applications are sold, distributed, or licensed to third parties.

Got Jobs?

Just a reminder that if you are a member of the Society of Payment Security Professionals (SPSP) you can post your resume online for others to find and hire you.  I’ve seen people looking for people who have skills in PCI compliance and privacy legislation.  What better way to find them than by posting your resume in the center of such action?

A number of job postings have been asking for the QSA certification.  It’s important to remember there is no such thing as a QSA certification, as it is only a qualification.  I recommend reading the CPISM vs QSA document that Chris wrote.  It’s very thorough and explains the differences well.

Call centers with VoIP phones could expand PCI scope

I have always said I could talk for half a day on the scoping considerations of call centers.  They are complex beasts that exist for the purpose of servicing customers, which often involved either accepting or retrieving cardholder data.  I won’t go into every detail of call center compliance in this post, but I do want to bring up the topic of scope.

Last weekend I was speaking with an engineer who installs VoIP connections for enterprise corporations.  I asked him if the voice and data networks were ever separated, and he said “no” due to quality of service (QoS) purposes.  I then asked about the data port usually connected to most VoIP phones and if it could be used to access the data network.  Of course, it could access the network thus leading me to think that every call center that uses these phones could be seen as risk.  Someone could enter a facility with poor physical security controls, or even a temporary employee, and install a device on the network.

Remember, the scope of the Cardholder Data Environment (CDE) is any system that “stores, processes, or transmits” cardholder data or “any connected system”.  It is the connected system that companies should explore.  Companies should examine the different attack vectors and how those could negatively impact the security of cardholder data.  The implementation of insecure VoIP phones in a company could expand the scope of compliance.

Many times I work with companies to remove their call centers from scope (depending on the service offered) so they can reduce the overall cost of compliance.  The problem is that unregulated systems such as these could expand the scope once again.  I recommend reading JJ’s post on Securing Multiple Device Auth on 802.1X.  I don’t know many companies that use 802.1X authentication but it can certainly help reduce the risk of unauthorized or rogue devices.

Successful CPISM/CPISA Training Class

Chris just finished another successful CPISM/CPISA training class and we now have 30 newly certified CPISMs and 20 CPISAs.  The training and certification have already received great reviews, and now the list of individuals who are certified continues to grow into the hundreds.  I’m honestly suprised at the demand we have had in just the first year alone.  The Society has hosted several classes designed to make individuals into Payment Industry experts.

The content and subject matter material is listed on the site.  The CPISM has subject areas that include:

• Payment card industry structure
• Payment card structure and data
• Payment card transaction processing
• Compromise fraud statistics and trends
• Merchant risk analysis
• Laws and the regulatory environment
• Payment card security programs
• Third party relationships

It’s something everyone should prepare for before hand and NOT walk into the class unprepared.  Some people have even aggregated many of the reference items from the study guide and posted them as a download.

I’m excited to see the demand grow, both in the US and globally.

Gartner misses the point of PCI

The goal of the PCI DSS is to prevent the electronic and paper theft of cardholder data.  That said, the PCI DSS is not the only standard within the family of PCI family.  The collection of PCI standards includes:

• PCI DSS :: Targets merchants and service providers who “store, process, or transmit” cardholder data
• PCI PED :: Targets the PIN Entry Device (PED) used in PIN-based debit and ATM transactions
• PCI PA-DSS :: Targets payment applications that are resold and involved in the authorization and settlement of cardholder data

Gartner makes a critique that the PCI DSS v1.2 update should have included reference to Chip and PIN technology.

Acknowledge the substantial investments in chip and personal identification number (PIN) card technology made in many parts of the world, including most European countries. These investments should limit the scope of compliance efforts, but the updated standard does not even acknowledge these compensating controls and implementations.

This is the wrong approach for several reasons, but requires a better understanding about the differences between Chip-PIN and PCI DSS.  Chip and PIN has made a dent in payment card fraud, but does not limit the “scope” of compliance in any way.  Dipping your chip card can leave ‘track equivalent’ data just as swiping a credit card can leave track or magnetic stripe data on the POS.  The ‘track equivalent’ data cannot be used to recreate the chip but can be used to encode the track data on a magentic stripe.

I do agree with Gartner that the following areas are important, but not something that should be included in a standard document.

• “end-to-end encryption of card data”
• “inconsistency in the quality of assessments by qualified assessors”

Web application vulnerabilities at large

Improperly coded web applications continue to plague the world, not least of which the payments service space.  Here are a few important clarifications about PCI DSS Requirement 6.

1. Developers must be trained in secure coding practices.  They should understand vulnerabilities their application is susceptible based on the (1) functional use and (2) language it is developed in
2. Internal code reviews must be incorporated into the software development process.
3. Security testing of the application must be incorporated into the quality assurance or testing phase of the software development live cycle (SDLC).

Web application compromises account for 75-85% of compromises in Europe and a sizable number of the compromises in North America.  As a result we have mandates such as requirements 6.5 and 6.6.  One should know the following about these sub-requirements.

• 6.5 :: for all web applications developed in-house, and used either internally or publicly
• 6.6 :: for all web applications regardless of origin (internal or COTS), and public facing

Damon Cortesi, founder of Alchemy Security and author of StartupSecurity.info, is giving a presentation on secure software development and PCI.  If you are in Seattle check out the StartPad event November 25th @ 6pm.