Many people know by now that PCI DSS Requirement 6.6 is going into effect (meaning you must be compliant) on June 30, 2008.  What these same people are asking is, how does this apply to me and my business?  And how can or should I comply with this requirement?  There have been a number of blog posts about this requirement and even more discussions about what it all really means.

What does it mean?

In order to understand this you have to take my Attack Vector based Risk Management (AVRM) approach towards the intent behind this requirement.  One could easily reference that the intent behind this requirement is to prevent Internet-facing web-application compromises and you would be correct, but also missing the deeper meaning and back story.

Although card-present (typically IPOS) systems account for a greater number of credit cards stolen, about half of all account compromises are a result of web-application data breaches.  Of this population, about 90%+ of the data compromises are a result of the top 5-10 web-application vulnerabilities.  These include, but are not limited to, SQL injection, cross-site scripting, cross-site request forgery (CSRF) and other input/output validation issues.  Knowing this you can now imagine that if we could mitigate the risk of these top attacks we could reduce the population of credit card data breaches by almost half!  (This does not reduce the number of credit cards stolen by half.)

The consideration here is not just to protect against the OWASP Top 10 but to consider those that apply to your web-application and understand those that cause the highest risk to your application.  Consider the risk you could mitigate simply by properly validating the input/output on your application.  Would this address all risk?  No, but it would get you significant progress towards that goal.

Also, remember there is a difference between compliance and validation.  If you validated your compliance prior to June 30 you do not need to re-validate for 12 months, but you do need to be compliant with the standard at all times.  Compliance is a state of being that you must maintain at all times; for this requirement it means on or after June 30, 2008.

How can I comply?

The best part about this (and other) requirements is the large number of ways to comply.  Remember, the goal is to meat the intent - so how can we do this?  Well the standard states two options, and the intent leaves it open to many others.  Let’s list the two given options first:

• Have all custom application code reviewed for common vulnerabilities by an organization that specializes in application security.
• Install an application-layer firewall in front of web-facing applications

First, remember that it is not comparing apples to apples here, but providing options that different enterprises can implement depending on their specific needs and abilities.  We are still aiming to meet the same intent.  Notice that, agnostic of technology, we can meet the intent using either of the prescribed methods.

Second, we should use the ‘intent’ defined above, via the AVRM model, to understand what “common vulnerabilities” means.  To clarify the meaning of “an organization that specializes in application security” they are saying you should use a company that can identify the “common vulnerabilities” and remediate them, rather than your 8 year old nephew who just took her first computer programming course.

Now people are always asking what is an “application-firewall”.  They know what it is, but want to know what you think it is.  We should no longer have to answer that question again, because agnostic of technology an “application-layer firewall” should satisfy the intent behind this requirement as outlined above.

Still not enough?  Well, the PCI SSC has released an Information Supplement that clarifies Requirement 6.6.  Among other things, this supplement offers four additional alternatives towards meeting the intent of this requirement:

1. Manual review of application source code
2. Proper use of automated application source code analyzer (scanning) tools
3. Manual web application security vulnerability assessment
4. Proper use of automated web application security vulnerability assessment (scanning) tools

Still not enough to meet your business requirements?  Then document a compensating control and write up how it mitigates the risk, to meet the intent, that could not be accomplished due to a legitimate business or technical issue.

Popularity: 20% [?]

If you build a new deck in your backyard, would you test it out before inviting your friends and family over for a bar-b-que?  Well it turns out that many merchants are documenting compensating controls but not actually testing them to make sure they work.  How could this be?  I’m asking myself the same question.

There is a simple approach to understanding compensating controls that starts with asking the question, “When would I use a compensating control?”  The answer to that is any time that you have a legitimate business or technical reason.  For example, you may have some specialized technology that meets the intent of the requirement but not in the prescribed manner of the Security Audit Procedures (SAP).

Then you should document your findings, so you can show them to people if they ever ask, “what in the world were you thinking?”  This documentation should include those items listed in the Compensating Controls Worksheet.

1. Constraint - the business or technical constraint precluding compliance with the original requirement
2. Objective - the intent of the original control
3. Identified Risk - the risk posed by the lack of the original control
4. Compensating Controls - the controls in place that mitigate the risk to meet the intent that could not be achieved via the constraint

But you cannot stop here!  You actually need to test these compensating controls to make sure they hold up.  It’s not sufficient to say that a company uses RACF security on their Mainframe as a compensating controls for something else if you do not evaluate the security of the RACF configuration.  For each compensating control you must actually TEST it to make sure it is sufficient to mitigate the risk to cardholder data.

As Ronald Regan always said, “Trust, but verify!” (“doveryai, no proveryai”)

Popularity: 18% [?]

It has come to my attention that software vendors do not fully understand their responsibilities regarding Payment Application Best Practices (PABP) compliance and their customers’ PCI Data Security Standard (DSS) compliance. PABP compliance does not automatically imply PCI DSS compliance and visa versa. What follows is a recent real-life example of how a major vendor handled this situation and how it adversely impacted their customer.

One of my clients is implementing a new point-of-sale (POS) system in one of their operations so that this operation will be PCI DSS compliant. This POS vendor is not only providing the software solution but is also providing remote management and support of the solution.

The first problem my client ran into was their demand that the contract with the vendor contain language to ensure that the vendor’s services being provided were PCI DSS compliant. The vendor explained that their software was PABP compliant and that they were therefore PCI DSS compliant. We explained that the software was only part of the equation because the vendor would be remotely administering the system and that those services needed to be PCI DSS compliant. The vendor continued to argue that their PABP compliance was all that was needed but finally relented to the PCI DSS compliance provision.

We are now assessing the implementation of the vendor’s software for revising their PCI Report On Compliance (ROC). While the software is definitely PABP compliant, we have consistently had difficulty getting information out of the vendor regarding how to assess my client’s implementation of the solution. They have finally, and very reluctantly, admitted that cardholder data (CHD) is stored encrypted on the server at each location. In very tense discussions, they have also finally relented and released the process for managing the encryption keys to my client for their management. My client was relying on the fact that since the software was PABP compliant, they would not have to worry about additional controls. However, my client now has to rapidly make implementation changes to make sure that they meet the PCI DSS requirements for data center monitoring and controls because the new solution stores CHD locally on each server.

All through this process, the vendor has been arrogant and indignant. They have repeatedly stated that as they understood the process, PABP compliance was all they needed to be compliant with all PCI processes.

This has been meant to give software vendors a relevant example of why it is so important for them to be forthcoming with all information regarding their solutions with their customers. There is important information regarding the solution that the customer needs to know so that their implementation will be PCI DSS compliant. PABP compliance means that an application properly protects, manages and controls CHD. It does not mean that your customers will not have to implement their own management procedures and controls at their end to ensure their PCI DSS compliance.

If a vendor is providing management or other services to their customers that are covered by the PCI DSS, vendors need to understand that those services are not covered by any PABP compliance process and that these services need to comply with the PCI DSS.

And this situation will not change with the introduction of the PA-DSS.

Popularity: 47% [?]

One of the more difficult questions to answer about PCI is how to define the scope of a project. This is a topic that does not receive much conversation because it is so very specific to the actual environment. There are things to consider such as:

• Network and operational segmentation
• Type of data stored (i.e. track data vs. just PAN)
• Volume of data stored
• Who has access and how often do they have access
• Format of the data (flat file, database, audio/image file)
• Online vs. offline data stores

As you can see the factors are many, but how deep does an auditor need to look when performing an audit? Here are some factors they may examine:

• Can they sample similar systems?
• Will they rely on third-party reports?
• Do they need to inspect the security of every application?
• Will you need to give them copies of sensitive data for their work papers?
• Who will send the final report to the acquirer or card brand?

Each auditor will vary in how deep they need to go when auditing a company, but most will need to review and examine all settings, configurations, and documents on their own. The reason for this is because they are promising that everything they write in the report is true and accurate at the time of the audit.

This means that a QSA may need to review your system settings even if you had those settings reviewed as part of a different audit several months ago. Also, if the time between the ‘gap analysis’ and the ‘compliance audit’ is very long they may need to update their work papers. This means you will provide them updated copied of the material you gave them previously. The reason for this is to confirm you still have all of the required controls in place.

If you do not want to give them copies of your sensitive data (i.e. firewall rules) they may ask you to sign work papers stating that they reviewed the information and documented any findings. This is an alternative to forking over a large volume of secret information, but comes with the price of filling out large volumes of paperwork.

Sampling is something at the discretion of the auditor, but something that almost everyone does. You need to check with your QSA during the pricing and planning phase to confirm they understand the need for sampling of similar systems. Some companies may price an audit high if they do not know they can sample your similar systems. We could spend another post talking about the details of sampling, but here we will just remind you that it is an option and one you should examine.

Popularity: 36% [?]

With PCI companies are classified into different categories. A company may be a merchant, service provider, acquirer, issuer, etc. Most banks understand their compliance obligation, but the remaining categories of merchant and service provider are looking for guidance on what is required.

The question is, can a company be both a merchant and service provider? The answer is yes! There are many companies that are both merchants and service providers, remember these designations are simply verbs - actions. A company may perform both actions as different lines of business.

A company may sell products (and accept payment via credit cards) and are thus a merchant. They could also be a service provider if they offer services to merchants or other payment entities. In this case they could look for what Level merchant and service provider they are for validation purposes.

Popularity: 27% [?]

A few weeks back I was invited to the Qualys annual conference in San Francisco. Their theme was Software as a Service (SaaS). No sooner had I returned than CIO Magazine has Software as a Service as their cover article. I think they are on to something here, that is bigger than just security or software.

While at the event I had a chance to speak with many on the Qualys team (some of whom I had met just days before in Tokyo.) One of the most interesting characters was Philippe Courtot, the Chairman and CEO. He is a consistent entrepreneur who, aside from being well connected, is well informed about the industry. He is French, a physicist in his prior life, and enjoys extreme skiing as a sport.

He purports that software is moving to a service (or subscription) based economy. For example, take Google with their online service based suite of office tools (word processor, spreadsheet, email, calendar, etc.) We made a bet on Windows Vista being the last operating system that Microsoft makes, with his argument being that all software will move to a service based offering. (Bill, please release another operating system or I loose the bet.)

Qualys has put their company where their mouth is by releasing QualysGuard. One thing you may not know is that Qualys is the approved scan vendor (ASV) of choice for most merchants. Why is this? Because the majority of companies listed on the ASV list actually resell Qualys. This means that Qualys scans a large percentage of all PCI compliant merchants.  This new service offering of theirs delivers another type of SaaS — the Security as a Service.

I’m now wondering how many other companies will follow suit and offer Security as a Service and what other products can be delivered via this method. We already offer this (partially) via managed service companies. These would be your remotely managed IDS and audit log review providers. But managed services are still only partially on-demand security.

The question is: what, when, and how will the security industry move to a service based offering? Is this something we want, need, or could use?

Popularity: 49% [?]

According to Digital Transaction News, Visa USA is ready to introduce account-level processing (ALP).

“Visa claims ALP will allow smoother transitions to new cards for cardholders, and will let merchants, in partnership with issuers, design more effective rewards programs.”

Sounds good so far, but wait there is more.

“The key change is the switch from managing transactions through the six-digit bank identification number (BIN) within a card’s 16-digit number and instead using the full account number.”

Wait a minute, did we read that right? Did they say what we thought they said? Yes they did. To paraphrase, the key change is the switch from using the six-digit BIN (3.3 compliant) and instead using the full PAN. This will just add fuel to the fire over storing the full PAN.

And it just keeps getting better.

“The new process affecting Visa-branded consumer cards will allow a credit cardholder to keep the same account number even if his issuer upgrades his card”

Yes, that is right, not only do we now encourage storing the PAN, but we are going to allow the PAN to remain the same even when the card changes. This just sounds like a way to generate even more replacement card numbers.

Does anyone think that encryption will not be critical to managing this situation? How many organizations are handling encryption properly right now? Some, but not enough. Think this will just make things worse? Probably, at least in the near term. Think the “bad guys” will take advantage of this new capability? Without a doubt.

The article goes on to say that this new approach will likely cause merchants a POS software upgrade headache to support ALP. POS software will have to be able to insert a field code, known as 62.23, in the authorization message. This field code will be a single alphabetic code that indicates the card product that was presented for the transaction.

As of October 2007, Visa will require all acquirers to be able to receive the new field code in the authorization message. Acquirers will use the code to determine the correct interchange, chargeback rights and other characteristics such as loyalty points to be accrued for each individual transaction.

Popularity: 61% [?]

Many companies have been PCI DSS compliant for a few years. I get reports from people saying year 3 is much easier than their first time around. Others are just dipping their feet into the waters of PCI compliance. What is it they should be aware of when navigating the process for the first time?

We wrote a two part segment on Meet Your Auditor, basically tips on how to pick and utilize your PCI auditor.

The Burton Group just released what they call “a list of recommendations to help merchants and payment service providers get the most out of the payment card industry (PCI) data security standard (DSS) compliance work.”

They mention one very important point: “Payment Card Industry Data Security Standard - Not a Security Panacea” There is a difference between security and compliance and you should understand that going into the process. PCI is a MINIMUM baseline. Your level of security beyond that will depend on your risk tolerance.

Popularity: 24% [?]

I had an IM chat this morning with Martin McKeay asking why everyone feels there are no teeth to PCI compliance. I worked with him on such a project and wanted his feedback. It seems everyone feels there is no monetary reason for large companies to comply. And those who take that stance would be correct - there is no direct cost, but there are indirect costs.

Let’s consider this for a moment. Not to pick on any one, the card brands can fine a merchant for non-compliance with PCI. (Remember that PCI includes the PCI DSS and the PCI PIN requirements.) This means that each card brand can fine a merchant. (MasterCard does not provide fee numbers, so let’s assume they are the same as Visa’s.)

• Up to $500,000 per incident (PCI DSS)
• Up to $500,000 per incident (PCI PIN)

Ok, so let’s say that you accept 3 credit card types and you have the worst compromise possible (storage of both Track and PIN block data.) This means your direct fines would only account for $1m x 3 brands = $3m. And don’t forget the proactive fines for non-compliant merchants.

This is a large issue for small merchants and a small issue for large merchants.

Why should large merchants care? I’ve outlined a number of reasons here. It’s all about the multiples. If a small merchant looses 1,000 credit card numbers the re-issuance costs, fraudulent transactions, and remediation costs will all be (relatively) small. They comply because of the fines.

Large merchants may not see the fines as a big issue but they should care about all the things the smaller merchants don’t worry about. If you take class action lawsuits, re-issuance fees, fraud cost recovery fees, credit report monitoring, remediation costs, and possible FTC monitoring and then multiply it by 20 or 40 million cards you end up with a very, very large number.

I am frustrated when people say there is not a big enough stick, because all they read about are the fines. Even after a compromise, TJX only reported having spent $5m on forensics and fines. Nobody ever sees the longer term costs of compliance because what reasonable merchant would ever publicize these numbers?

You cannot fear what you do not know. Educate yourself about the cost of credit card compromise.

Popularity: 40% [?]

Although the Ukraine has not yet been accepted into the EU, they do have a PCI compliant Level 1 service provider.  (Certificate of Compliance)

TechnoPark Corp. is the first Ukrainian IT company to make the product which has got the certificate of compliance against PCI DSS. The certified software is mobile payment system MPPS. It was developed by TechnoPark for the Maltese MPPS Solutions Ltd.

The only problem is, they got their press release a little wrong.  It reads:

The PCI Data Security Standards are not an obligatory condition of payment systems operation. Nevertheless, VISA strongly encourages all online payment service providers to go through the certification. PCI DSS requirements cover mostly the piece of software, which operates the system, as this is the crucial factor providing the service’s reliability. Thus, software developer is responsible for PCI DSS compliance.

First off, PCI compliance is obligatory.  Second, PCI does not mainly focus on the software, but on all areas of the network, servers, and applications.  Certainly the software is part of it (requirement 6) but there are many other areas to examine.

I think they sum it up well in their last paragraph, which shows the now changing perception that Westerners will have towards Eastern Europe and outsourcing in general.

The Ukrainian software product’s PCI DSS compliance is an important achievement for the whole Ukrainian IT outsourcing industry. TechnoPark Corp. has made the first step towards changing the image of Ukrainian IT products from “cheap staff” to “high-quality and reliable software products”.

They never needed to get compliant and could have gotten by without it.  You don’t see many compromises in the news in Europe so the pressure is low, unlike in the US.  They are acting proactively to show the world that they are a mature player.

Being compliant with PCI may not mean much overall, but it provides a baseline of security, which is all compliance with anything can provide.  But this baseline is arguably a competitive advantage over others in their area.  I equate it with having the CISSP certification.  Nobody cares that you have a certification, but it’s a qualifier.  It shows a baseline, or at least that you cared enough to get it.

Another thing I really like about this company is they have a blog!

Popularity: 17% [?]