PCI DSS Compliance Blog

Third Party Agent Registration and PCI DSS Compliance for Software as Service (SaaS) Providers

By Susan Kohl

As a software vendor, do you know what is required for your application to accept payments and be compliant with industry regulations? In order to understand the requirements independent software vendors (ISVs) need to determine which category is applicable to their business model.

Table 1:  Software Provider Categories 

As illustrated in the table above the requirements vary based on the business model which is representative of the types of services a software vendor provides to their customers.  This article focuses on clarifying the requirements for SaaS and hybrid models and can best be summarized with the following steps.

Registration with Credit and Debit Card Brands

The card brands (Visa, MasterCard, STAR, etc.) require “Registration” of all entities providing the following services to the payment industry (referred to as Third Party Service Providers or Agents (TPAs)):

• Solicitation of payment activities
• Chargeback, fraud and settlement management services
• Enabling authorization and/or settlement activities (gateway and hosting services)
• Performing payment encryption management services
• Payment program processing, managing, monitoring and/or reporting (such as loyalty programs)

SaaS ISVs provide services that hosts the software that stores, processes, and/or transmits cardholder data on behalf of their merchant therefore they qualify as a TPA. 

The purpose of Registration is to clearly identify all parties that handle payment transactions and/or cardholder data in any way.  TPAs must be registered by a card brand sponsor Member.   A Member must be a financial institution (aka bank) that meets the criteria of the card brand to sponsor TPAs.  We will refer to these Members as a “Sponsor Bank” for purposes of this article.  There are many other types of Members not relevant to this article.  TPAs can select their own Sponsor Bank or work through their payment processors’ Sponsor Bank to complete the proper Registration.  

The table below highlights key information required, at a minimum, from you for the Sponsor Bank to properly complete Registration.  Each Sponsor Banks’ Registration program requirements may vary, however some basic information standards are required by all Sponsor Banks as dictated by the card brands operating rules and bank regulations.

Table 2: Registration Information Required

	You Provide	Sponsor Bank Performs	Result
1.	Memo describing your business activities related to payments and provide a process flow that outlines incoming and outgoing activity (authorization pass through, settlement points, etc.), third party service touch points. If possible, request a face-to-face meeting with the Sponsor Bank and/or Processor.	Review to determine Registration category and how to underwrite the risk and identify what third party companies handle cardholder data (TIP: Sponsor Banks may not request this, however to avoid confusion on what category you should be Registered as and the risk associated with your business it is prudent to provide such documentation)	The more clear and concise the business overview and operations the less frustrating and misclassification will occur during your Registration process.
2.	Application for Registration	Information used for underwriting and to prepare the card brand specific forms	In some cases, the TPA may be requested to complete all of the card brand forms rather than a single application. Each Sponsor Bank may differ on their procedures. Inaccurate and/or in complete information may be grounds for denying an application.
3.	Registration and Application Fee(s) (Fee range is $10,000 to $25,000)	Submits fees to card brand and maintain a small portion for the administrative process	Fees along with submission of the required documents to the card brands yields “Registration”, if approved.
4.	List of all principal owners (for non-public entities only) (TIP: Run a federal and state background check on each of the principal owners first and be prepared to address any known issues.)	Background checks (criminal, credit, financial)/tax liens	Ensure the results do not violate company policy for items such as federal offenses and related financial crimes.
5.	Financial statements and tax returns (most recent year and 1 -2 previous years)	Financial analysis to determine credit and financial risk	The analysis may yield a required reserve and/or principal owner guarantee to cover risks that may exceed credit and financial ability.
6.	W-9 (Tax ID)	Run a company background check	May be denied Registration if the company Tax ID and business existence cannot be validated
7.	Business License, Declaration of Corporation (non-public entities only)	Validate business existence and purpose of conducting business	May be denied Registration if the company existence and business purpose cannot be validated
8.	Credit check authorization form (non-public entities only) (TIP: Review credit bureau reports for all principal owners first and be prepared to address any known issues.)	Perform a credit check	Derogatory credit information may either pend the Registration process requiring more information from the TPA or a higher requested reserve. The TPA may be denied if bankruptcy or poor credit scores were noted.
9.	PCI compliance status/validation (Estimated costs range from $250,000 - $2.5 million, includes implementation)	Review the list of approved service providers and the PCI status (Global List of PCI DSS Validated Service Providers) If not listed and/or a Report on Compliance (ROC) has not been provided by the TPA, they will request an action plan to achieve PCI DSS.	Entities not PCI validated may be denied Registration unless they can provide evidence that cardholder data is not “handled” (stored, processed and/or transmitted) in the TPA environment.
10.	Other information/forms specific to the Sponsor Bank (e.g. business insurance verification)	Varies depending on the information requested; ensure proper liability coverage	Will vary depending on the information requested. If insurance coverage is insufficient to cover the risk

PCI Data Security Standards (PCI DSS)

The PCI DSS applies to any entity that stores, processes, and/or transmits cardholder data. It covers technical and operational system components included in or connected to cardholder data. If your business accepts or processes payment cards, it must comply with the PCI DSS.

PCI DSS is an important component of the Registration process, one not taken lightly by a Sponsor Bank and the card brands. TPAs are not only required by the card brands to be Registered; they must also be PCI DSS compliant if they store, process and/or transmit cardholder data. PCI validation requirements vary slightly based on the Service Provider PCI Level as noted in the table below.

Table 3:  Service Provider PCI Levels and Requirements Summary

Service Provider PCI Compliance Level	Criteria (varies per card brand)	Requirements
Level 1	All third party agents that store, transmit, or process greater than 300,000 transactions annually (evaluated by individual card brand)	1. Annual Onsite Assessment by a Qualified Security Assessor 2. Quarterly Network Scan by an Approved Scanning  Vendor
Level 2	Includes all service providers that store, transmit, or process less than 300,000 transactions annually (evaluated by individual card brand)	1. Annual Self-Assessment Questionnaire (SAQ) – Version D 2. Quarterly Network Scan by an Approved Scanning Vendor

For more information about specific card brand PCI requirements review the following websites:

• Visa Third Party Agent or Service Provider(“CISP” Program)
  
• MasterCard Service Provider (“SDP”)
• American Express Service Providers
• Discover Service Provider (“DISC”)
  

Registration and PCI DSS Costs

Registration as a TPA typically costs between $10,000 and $25,000. Becoming PCI DSS compliant can add up anywhere from $250,000 to over $2 million. As a SaaS provider, you have the option of outsourcing your payment processing, which would eliminate the need (and cost) for registering as a TPA and decrease the burden of PCI DSS compliance.

Susan Kohl is CEO of ThoughtKey, a payment industry boutique consulting firm focused on PCI, regulatory compliance, risk management and expert testimony serving all parties of the payment industry value chain. You can reach Susan via email or phone (678)522-2466 or on Twitter @PCISK.

PCI Compliance Solution? Be PCI Free

By Susan Kohl, CEO, ThoughtKey, Inc.

PCI is more than just a three-letter acronym that most do not wish to associate with their business environment.  It can be your enemy or your ally depending on your business.  If you are:

1. Vendor benefiting from the profits of providing PCI related solutions = PCI is clearly your ally

2. Payment processor paying the ongoing price tag of maintaining PCI compliance = PCI is your enemy

The most difficult of them all:

3.    Merchant who simply struggles to achieve the desired profit =  does not even want to think about PCI unless someone forces them to do so

I spend endless hours advising clients on how to “cope with” the onerous PCI standards plus the numerous state data security laws (we will refer to these collectively as “standards” for purposes of this article).

Translating these standards into an implementation plan can be complicated.  The solutions and procedures needed are highly dependent on the specific operation and technology environments. Unfortunately, there is not a one size fits all implementation plan!

My PCI Strategic Risk Advisory approach often catches my clients off guard.  They engage me to help them implement PCI, the core of my business, but my first objective is to figure out how to eliminate PCI applicability from their environment.  Other than not accepting credit and debit cards as a payment method, how can merchants achieve this objective?  The answer is simple – ELIMINATE ACCESS, TRANSMISSION, AND/OR STORAGE OF CARDHOLDER DATA.  One of my Florida clients termed this appropriately as “Be PCI-Free”.  The slogan fits and makes sense.

With the advent of hosted solutions (often referred to as “SaaS” or software as a service/solution) merchants can now achieve a Be PCI-Free objective while accepting credit and debit cards as payment.  What makes several hosted solutions even better is the recent availability of tokenized data elements. Merchants that need certain payment transaction details to assist customers can still do so when they select a hosted solution that provides tokenized data.  For example, merchants may need payment data to manage 1.) customer dispute resolution, 2.) recurring/subscription payments, and 3.) targeted marketing and analytics.

The first step with my merchant client projects is to begin by asking a few key questions.  Then, use their responses to build a data inventory and to determine what data security strategy is best for their business model.   

Data Types:  What types of non-public data (bank account information, credit and/or debit card data, social security numbers, etc.) exist in the business environment?

Quantity:  How much of this data exists?

Where:  Where is this data?

Handling:  How is this data handled (access, transmitted and/or stored)?

Why:  Is this data necessary?

Whenever possible, dependent upon the above responses, I strongly advise my merchant clients to avoid handling any cardholder and/or other non-public data by using a hosted solution with tokenization.  We then work collectively to evaluate the appropriate hosted solutions vendor that matches their business model and industry.  The benefits to a merchant for using a hosted PCI compliance solution with tokenization are priceless. 

• Significant reduction of data breach liability (shifted to the hosted provider) - $$$$
• Elimination of PCI managing costs (shifted to the hosted provider)  - $$$
• Reduce internal data storage and managing resources (shifted to the hosted provider) - $$$

If a hosted solution and tokenization is not possible for their environment, then we begin evaluating the business environment with the PCI and other data security rules. 

Susan Kohl is CEO of ThoughtKey, a payment industry boutique consulting firm focused on PCI, regulatory compliance, risk management and expert testimony serving all parties of the payment industry value chain. You can reach Susan via email or phone (678)522-2466 or on Twitter @PCISK.

PCI Compliance Interview

PCI Compliance Thought Leader Q&A
Interview with Rick Dakin, President of Coalfire

PCI DSS Compliance Blog: Tell us about Coalfire.
Rick Dakin: Coalfire is an IT audit and compliance firm.  We spun out of an application hosting company in 2001 and have remained focused on a single mission since that time - to provide cost-effective IT audits and compliance advisory services.  This focus allows us to provide an independent view of compliance to stakeholders subject to Payment Card Industry (PCI), banking, healthcare and privacy regulations and laws.

The company provides a wide range of security and IT audit and advisory services through a team of 50 professionals from offices in Colorado, Washington and New York.

What work does Coalfire do in the area of PCI compliance?
Coalfire provides a full range of PCI assessment and compliance advisory services that includes certification to perform the following activities:
•    Qualified Security Assessor (QSA) – provide level 1 Report on Compliance (ROC) reports after on-site testing, and facilitation for completion of a Self Assessment Questionnaire (SAQ).
•    Payment Application – Qualified Security Assessor (PA-QSA) – Perform application testing and validation to the Payment Application-Data Security Standard (PA-DSS).
•    Approved Scan Vendor (ASV) –perform internal and external network vulnerability scans.
•    Penetration testing services are provided to all PCI clients.

What does it take to become a certified QSA? 
A QSA must work for a QSA company.  The requirements for QSA companies include registration (with fees), $2 million of professional liability insurance, and compliance to the rules published by the PCI Security Standards Council (PCI SSC).  All QSA companies are subject to review by the council.

Once a QSA company is established, an individual QSA must first obtain a security industry certification like a CISSP or CISA certification, 3 or more years of industry experience and hands-on PCI experience supporting another certified QSA.  All QSA participants must then pass a background check and complete formal PCI training and certification testing. 

At Coalfire, we estimate that each individual QSA costs us $7,500 per year to maintain industry certification, registration fees and insurance in addition to 50+ hours per year in training or off-site testing.  In short, it is a significant commitment by both the QSA and the QSA company to provide certified services in the industry. 

Merchants and software developers are often confused by the various levels of advice available to them.  Some companies do not complete the rigorous QSA training, testing, certification or peer reviews that guide our processes and methods to determine compliance to PCI standards.  Accordingly, the advice provided by a certified QSA may differ from advice provided by an industry observer who is not subject to the QSA process.

How many assessments are you doing per year?
Coalfire will perform over 1,000 assessments this year for more than 600 clients.  Over 60% of those assessments will be performed for clients with PCI DSS or  PA-DSS requirements.  Our processes and methods to determine compliance have been developed and vetted through thousands of tests, council peer review and success in preventing compliance failure for any of our validated clients.

Are more of your customers concerned with PA-DSS (ISVs) or PCI DSS (merchants)?
Since merchants outnumber the payment application vendors in the market, we conduct more merchant and service provider level 1 and 2 ROC and SAQ testing.  However, we are seeing a dramatic increase in the amount of PA-DSS compliance validation work from payment application developers.  This trend clearly verifies that merchants are improving security infrastructure more quickly than payment applications are being updated to comply with the Payment Application Data Security Standard (PA-DSS).

As a result, processors and merchants are facing critical deadlines to verify that payment application vendors comply with PA-DSS or force merchants to switch applications to a version that is already compliant.  This change is disruptive to many merchants since the updated applications typically require changes to platforms or infrastructure.

The problem cascades through the payment ecosystem because payment application vendors are having trouble finding a PA-QSA with resource availability to complete pre-audit testing or final validation testing on a timetable that will enable merchants to fully deploy PA-DSS compliant applications prior to the July 2010 deadline.

Can you walk us through a brief step-by-step process that you go through with your clients in the area of PCI compliance?
Our process is consistent across all product areas to include ROC, SAQ and PA-DSS test and reporting.  The following example is provided to outline the payment application validation process.

1.    Prospects enroll in an online audit preparation and self assessment tool called Navis.  The Navis platform has RapidPA-DSS, RapidSAQ and RapidROC modules.
2.    Prospects enter evidence that they meet specific controls in a “Turbo Tax” styled online questionnaire and data collection portal.
3.    Once the prospect data is entered and indicates that the payment application is ready to test, Coalfire’s staff reviews the data entered into the online platform and advises the prospect on the process to complete PA-DSS validation testing.
4.    After a contract is signed, Coalfire performs PA-DSS validation testing and provides a final gap analysis report to the developer to complete program modifications required to comply with PA-DSS standards.
5.    Final testing is completed and a PA-DSS reporting is submitted to the PCI Council.
6.    To become registered on the PCI Council PA-DSS list, each payment application vendor must sign a compliance agreement and pay a registration fee to the PCI Council.

What’s the area of greatest confusion for your customers? (ISVs or merchants)
The biggest area of confusion that we typically see is the separation of compliance responsibility between the ISV and their merchant clients.  Many clients think that the payment application vendor is solely responsible for PCI compliance.

Another common misconception among some merchants is that if they use PA-DSS-compliant payment applications, the merchant itself has met its obligations for PCI validation.  Coalfire works with payment application developers to help them guide their customers through a process to meet the full PCI standard and reduce the merchants’ risk of fines and penalties for non-compliance.  At the same time, this helps mitigate the payment application developer’s risk from civil claims from merchants using their technologies. 

There is perhaps no greater concern for merchants and software vendors than the cost of PCI DSS and PA-DSS compliance. How do you see the costs of PCI compliance weighing out against the cost of non-compliance?
How does the old Carpenters’ song go? … “We’ve only just begun.”

While the amount of investment in data security is growing at a breath taking rate, so is the investment being made in the personal injury litigation market.  We are seeing a dramatic increase in the amount of litigation being pursued to recover costs associated with identity theft and data breach, including credit card compromise.

In the last 3 years, over 40 states have passed aggressive new data breach legislation that will enable even more litigation.  Most breached merchants contact us with fears that they will be fined by VISA.  This is the least of their concerns.  I see most of the losses associated with litigation, fraud recovery costs, breach notice and post-breach system remediation.

Coalfire is not a law firm, but we see the damage caused by data breach up close.  This has taught us that the cost of compliance is really the investment to defend your organization from growing claims of negligence.  In the retail sector, the PCI Data Security Standard is the reasonable standard being used to determine negligence.

The trade off that we have experienced from our support of compromised merchants is that a dollar of compliance investment will save $10 of potential breach costs. Accordingly, we see the card brands like VISA moving into a secondary role.  We see state data privacy laws and the liability attorneys driving the need to validate compliance in the future.

How aggressive do you foresee credit card companies like MasterCard and Visa being with the new fines for non-compliance? What about specifically for smaller businesses?
For level 1 and 2 merchants, fines for non-compliance have become commonplace.  For level 3 and 4 merchants, enforcement has been “spotty” due to the various levels of tracking performed by the merchant processor.  We expect this random review of merchant compliance to change in 2010 since every processor must understand the status of merchants using only validated payment applications. 

Processors are making significant investments in their ability to track compliance of their level 3 and 4 merchants as a part of the process to inventory all payment applications to the PA-DSS requirement.  Accordingly, we expect fines for level 3 and 4 merchants to grow starting later in 2010.

Again, the fines are secondary.  We see the bigger risk that software vendors are offering non-compliant payment applications to customers who use them after July 2010 as a reason for the liability attorneys to pursue claims of negligence in the case of a data breach.  The PCI Council set the standard for reasonableness and now the attorneys have a clear path to collect huge sums for negligence on the part of merchants, processors and software developers who continue to use non-validated payment applications.

With PCI standards evolving, how do you stay at the forefront of the industry?
Unfortunately, the demands for more secure payments are driving investment in evolving PCI requirements at a time when merchants want their software developers to help them provide higher quality and more focused service to consumers. 

It is clear that the PCI standards that are being used today are not yet adequate to mitigate all risks to the payment processes.  The PCI Security Standards Council is providing leadership for a number of “next-generation” controls that will likely be included in future PCI Data Security Standards at both the application and infrastructure levels.

Many larger payment application vendors are removing payment modules from other merchant application services in order to contain the cost of data security.  By removing payment modules from commerce platforms and installing a shared payment service (managed by the application or by a third party), payment application developers can release updates to other non-payment modules without the expense associated with PA-DSS testing.  For the payment modules, application developers can focus more effort on enhancing controls when the platform is shared.  As a result, we see the trend for payment application developers continuing to move towards shrinking the payment environment and continuing to remove payment modules from other commerce functions.  Over the next few years, we would expect that the number of payment modules to shrink by a significant percentage.

Where do you see this industry in five years?
The payment industry is maturing.  Merchants and payment application vendors are faced with the market demand to simplify the PCI-compliance process and to reduce the cost of compliance.

Over the next 5 years, I expect that this overwhelming market demand will be met with solutions like centralized management of payment data to dramatically reduce the amount of data that is placed at risk in a distributed commerce environment.  The industry will have to keep innovating to allow consumers to get in and out of a retail environment more quickly while receiving higher quality and inherently more secure service.

The sophistication of payment processes will also have to continue developing at a rapid pace to keep up with online, mobile, in-store and unattended commerce opportunities.  Accordingly, only a few players will be able to make the investment in these dramatically shifting payment solutions to embed more encryption and continuous monitoring.

PCI Compliance & Data Security Around The Web

Looking around the web this month, we see that yet another hacking operation has resulted in the arrest and indictment of four men on charges of computer fraud and aggravated identity theft.  The men are accused of stealing more than $9 Million from ATMs in a matter of only hours last November.  The breach involved more than 2,100 ATMs globally and ended when the four men were arrested overseas, where they remain detained.  The four have been indicted by a grand jury in the U.S. District Court for the Northern District of Georgia.

Of course, data breaches seem to make big news, but the reality is that there are far more data breaches than are widely reported.  Looking at A Chronology of Data Breaches (hat tip - Application Security, Inc.), we see that the number of data breaches is, in fact, staggering.  While not all of those data breaches are related to payment cards or financial information, it is still a frightening number.  Perhaps the Federal Data Breach Legislation currently making its way through Congress will help. 

As we’ve discussed here before, PCI compliance alone isn’t sufficient.  In order to do more than just raise the bar, PCI compliance, vigilance, and a willingness to adapt to new threats helps to ensure that merchants, software vendors, and payment processors are as secure as possible. Martin McKeay makes this point in his Willingness to Do Anything post (great analogy in there).

With potential payment innovations on the horizon, and others being unveiled, the future of the payment space clearly involves ongoing evolution. 

How to Become PCI Compliant

By now you have heard about PCI compliance and are vaguely familiar with how it may apply to your business. So now what?

We’ve created this two-part article to clearly outline the steps merchants and independent software vendors must complete in order to become PCI compliant (PCI DSS and PA-DSS compliant, respectively).  We hope it guides you through this process clearly.  

This week, we’ll focus on how merchants become PCI compliant:

Merchants

For starters, get familiar with the compliance standard that applies to you: the Payment Card Industry Data Security Standard (PCI DSS).  The PCI DSS requirements are broken down into six different categories:

Build and Maintain a Secure Network

Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data

Requirement 3: Protect stored cardholder data
Requirement 4: Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

Requirement 5: Use and regularly update anti-virus software
Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know
Requirement 8: Assign a unique ID to each person with computer access
Requirement 9: Restrict physical access to cardholder data

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11: Regularly test security systems and processes

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security

The next step is to figure out your PCI compliance level.  Merchants fall under four categories of PCI compliance, depending on the number of transactions they process each year, and whether those transactions are performed from a brick and mortar location or over the Internet. Remember: all merchants that process credit cards—whether small or large—must be PCI compliant. 

Now here is where PCI compliance for merchants can get a bit tricky: each payment card brand (Visa, MasterCard, etc.) has their own requirements for PCI compliance.  We’ve written a comprehensive article on the different PCI compliance deadlines for each payment card brand, along with their different PCI compliance requirements.  To give you a general idea of what you need to do as a merchant, here are Visa’s PCI requirements for merchants:

Level 1 Merchants

- Annual Report on Compliance (ROC) by a Qualified Security Assessor (QSA)
- Quarterly network scan by Approved Scan Vendor (ASV)
- Attestation of Compliance Form

Level 2 and 3 Merchants

- Annual Self-Assessment Questionnaire (SAQ)
- Quarterly network scan by ASV
- Attestation of Compliance Form

Level 4 merchants

 - Annual SAQ recommended
- Quarterly network scan by ASV if applicable
- Compliance validation requirements set by acquirer

Some resources to help you complete these requirements:

•    List of approved QSAs
•    List of approved ASVs
•    Instructions on how to complete the SAQ
•    PCI Compliance Deadline List, including links to each payment brands’ PCI compliance sites
•    Article on how businesses that should complete the SAQ D can opt for a shortened SAQ

Depending on your compliance level, complete the appropriate requirements (above).  Then for each payment card brand you accept, check the site to see what kind of reporting you have to supply each brand. 

Next week we will post an article on how ISVs become PA-DSS compliant.  Sign up for our email updates in the top right corner or to the RSS feed to be sure you don't miss it!

Related Posts and Pages:

PCI Compliance Reflects a Moment in Time

PCI Compliance for Franchisors

Are you a PCI Compliance Guru?

PCI Compliance Deadline List

Remote Credit Card Storage Facilitates PCI Compliance

PCI Compliance Costs

PCI DSS Compliance for Merchants

PCI Compliance: A Moment In Time

When it comes to PCI compliance, merchants and software vendors alike often make the mistake of viewing their compliance as a “checklist” rather than an ongoing process.  Too many people assume that PCI compliance is achieved once.  In reality, however, it is maintained, through vigilant adaptation to both PCI requirements and evolving security threats. 

A closer look at PCI DSS requirements should make it quite clear that compliance is an ongoing exercise.  For example, requirement 1 reads, “Install and maintain a firewall configuration to protect cardholder data.”  Requirement 5 mandates that you “Use and regularly update anti-virus software.”  Requirement 6 states that you “Develop and maintain secure systems and applications.”  Requirement 11 implores that you “Regularly test security systems and processes.”  And, of course, Requirement 12 states that you must “Maintain a policy that addresses information security.”

Clearly, five of the twelve PCI requirements explicitly mention either maintaining or updating, which should make it clear to all paying attention that there is no finality to PCI compliance.  

In fact, any proclamation of “PCI compliance” is best viewed as a snapshot of compliance at a specific time.  While merchants and software vendors are able to use a variety of means to test compliance at any given date, the truth remains that ongoing compliance requires both vigilance and, often, quarterly and yearly compliance assessments.   

Merchants and software vendors must ensure that their processes, or their applications as the case may be, are PCI compliant.    But how does one know if they are PCI compliant?  What is PCI compliant?  Well, the answer to those questions is slightly more complicated that it might seem.

Assuming that you have a good understanding of PCI compliance basics, and that you’ve moved beyond the “checklist” mentality, verifying your compliance involves understanding the ongoing nature of PCI compliance.  At its root, PCI compliance is about securing data and, by that process, protecting cardholders/customers.  For PCI standards to be effective, periodic re-evaluation and adaptation is imperative.

People sometimes forget that PCI compliance requirements apply to all “system components,” and that ongoing assessments, on both a quarterly and yearly basis, are mandatory for most merchants.  This means, of course, that any change in hardware or software within your network must meet PCI requirements on an ongoing basis.

PCI compliance is dynamic, requiring ongoing adaptation.  PCI compliance starts with a set of 12 basic requirements, it continues with vigilance and adaptation, and it ends with….well, it doesn’t end. 

Related Posts and Pages:

How to Become PCI Compliant

PA-DSS Implementation

PCI DSS Compliance for Merchants

End to End Encryption Emerges a Winner from the PCI SSC Meeting

At the PCI Security Standards Council community meeting last week in Las Vegas, end-to-end encryption came out at the top of the list of payment card industry “emerging technologies.”

PricewaterhouseCoopers presented findings of an independent study (which the PCI Security Standards Council enlisted them to do) that examined twelve technologies on the market that potentially could help merchants satisfy PCI compliance mandates like PCI DSS and PA-DSS.  After initial research, the study narrowed its focus to end-to-end encryption, tokenization, virtual terminals and magnetic stripe imaging. 

While it may yet be too early to declare end to end encryption (E2EE) the clear leader among these emerging technologies, as Dan Kaplan from SC Magazine wrote:

Based on their findings, PwC determined that end-to-end encryption, which encrypts data from point-of-sale at the merchant across the processor's network, may have the most success at reducing PCI compliance scope for merchants.

While most people tend to associate credit card data theft occurring when that data is stored but not sufficiently protected, the hackers at the front of the data security battle are increasingly intercepting data while it is being sent across networks, relying on packet sniffing malware and SQL injection attacks to breach networks large and small.

Most of the emerging technologies PwC researched seek to address the vulnerability of such data in transit.  End to end encryption helps protect data in transit by ensuring that cardholder data is fully encrypted, across all networks, from card swipe through bank processing.  PCI Requirement 4, the current PCI requirement that relates to data encryption, mandates that merchants and software vendors “encrypt transmission of cardholder data across open, public networks.”  Clearly, though, data is at risk across all networks which the most recent breaches have proven.    

Since current PCI standards were crafted prior to this trend of shifted risk, PCI requirements could very well change as a result of the current review.

Related Posts and Pages:

Tokenization and PCI Compliance

Data Security Around The Web

The last two weeks in the payment (and information security) industry has been filled with various accounts of Albert Gonzalez (a.k.a. “soupnazi”), his accomplices, and their roles in the largest ever credit card fraud and identity theft conspiracy in U.S. history.

Naturally, of course, Gonzalez’s crimes appear to have been large enough, and bold enough, to quickly make him infamous, especially around the internet.  Is Gonzalez a “folk hero?”  Is he “Dr. Evil or Lee Harvey Oswald?”  Is he a “computer genius or common hood?”  Is he a “cybercrime mastermind?”

Regardless of what you’d like to call Gonzalez, and his attorney would prefer that you not call him kingpin, this high-profile crime has many wondering the same thing, namely, “how did ‘soupnazi’ allegedly steal 130 million credit cards?”  Prosecutors contend that “Gonzalez and his associates exploited vulnerabilities that remain widespread,” relying on structured query language (SQL) injection attacks on vulnerable websites. 

In what might be the security incident of the year, Gonzalez and his cronies reminded those of us concerned with secure payments that the security threat is very real, and that serious vulnerabilities remain for those who choose to take that threat lightly.  Commentators and consumers can take some small solace from Gonzalez’ arrest and indictment, as, obviously, can prosecutors and investigators, but the reality is that the best defense against future large-scale attacks is vigilance and improved security.

PCI DSS Training

For most merchants, PCI compliance can be complicated.  Recognizing this, the PCI Security Standards Council is seeking to close the information gap by offering a comprehensive PCI Standards Training program for merchants and their security staff.  

The inaugural training program is offered this calendar year, with three events remaining, one in Las Vegas, at the Mandalay Bay Hotel, September 21st and 22nd, one in the Czech Republic, at the Marriott Prague, October 29th and 30th, and one at a as yet undetermined U.S. location December 8-10.

The training will use much of the curriculum the PCI SSC uses to educate prospective PA-QSAs.

While the PCI SSC Training program is not a certification course, it does provide merchants and IT staff with the requisite knowledge to better understand and prepare for an on-site PCI assessment.  The training program will also assist merchants and IT staff in developing and maintaining a post-assessment compliance program.

Whether you’re a merchant looking to better understand PCI compliance or an IT person hoping to gain a better understanding of information security best practices, the PCI DSS training program seems likely to increase your knowledge base.  Given your choice of cities, too, you’re very likely to have a great time, be it gambling away your budget in Las Vegas or drinking away your hours in Prague…

Penetration Testing and PCI Compliance

One area where merchants and software providers struggle with PCI compliance relates to PCI DSS Requirement 11.  Here’s a breakdown of the requirement.

PCI DSS Requirement 11 is comprised of seven sub-requirements and 14 testing procedures.  It mandates that any business handling credit cards “regularly test security systems and processes,” a requirement that is intended to secure the network environment in which most merchants and software providers operate.

Some of the sub-requirements contained within PCI DSS Requirement 11 require validation by a Payment Card Industry Security Standards Council Approved Scanning Vendor (ASV).   Others, like sub-requirement 11.3, require no validation by an ASV or Qualified Security Advisor (QSA).  Sub-requirement 11.3 can be met using a “qualified internal resource,” leaving merchants and software vendors free to go it alone.

A closer look at PCI DSS Requirement 11.3 reveals that it requires businesses:

“Perform external and internal penetration testing at least once a year and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).”

Such penetration testing, also referred to as ethical hacking (or in some cases white hat hacking) is a PCI DSS requirement mandated by sub-requirement 11.3 (and clarified by PCI SSC in supplemental information). 

The reality is that many small businesses do not have a “qualified internal resource.”  Among merchants especially, many businesses end up paying an external third party to perform penetration tests.

As with any security standard, of course, performing more diligence than the minimum requirements is generally the best way to stay digitally secure.  This is why we perform multiple penetration tests instead of merely the one required by PCI DSS to our entire network every year.

Related Element Payment Services Pages:

PCI DSS Requirements
PCI DSS Compliance Level