PCI Blog - Compliance Demystified

PCI DSS Requirement 6.6

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.

Verizon Data Breach Report

Bryan Sartin invited me to a Webinar last week that summarized the Verizon/Cybertrust data breach analysis. Kokie Tjan informed me there is a PDF summary available online of the Verizon Business Data Breach Investigations Report.

This is the 10,000 foot view of a horizontal industry (payment systems).  Don’t forget to focus on how data breaches and risk applies to your specific vertical industry (i.e. higher ed, hospitality, travel and entertainment).

Sometimes those risks that affect the wider industry apply directly to you and sometimes you have very specific vertical industry threats.  As you may recall, one of my manrtas is “attack vector based risk management”.  In order to understand your risk you must understand the threats and ways an attacker values your data and systems.

It’s not always just the type and volume of data you store.  It’s also understanding how attackers view your exposed systems and what they think is easiest to attack and monetize.  Just like sailing a boat is not only about your skills as a mariner, you are also affected by the wind and water around you.

PCI on Disaster Recovery and Backups

Have you considered disaster recovery for your payment systems?  Do you know the only thing that PCI DSS compliance requires you to backup?  David Bergert writes about the basics of how to prepare your payment systems in the event of a disaster.  But missing is the one critical element required for compliance.

The phrase “disaster recovery” does not appear in the PCI DSS.  The phrase “business continuity” only appears once in requirement 12.9.1 as, “[verify that the Incident Response Plan includes a] strategy for business continuity post compromise”.  Instead of referencing disaster planning the PCI DSS references backups.

There are a number of PCI DSS requirements relating to backups, such as:

• 9.5 “store media back-ups in a secure location”
• 10.5.3 “Promptly back up audit trail files”

What was that?  The answer is that audit logs are the only thing companies must backup for PCI DSS compliance.  Now, companies will want to continue business and as a result will backup all of their critical systems and corporate information, but this is outside the scope of PCI compliance which focuses on the security of payment card data.

CPISM Readiness Documents are Online

Many people ask me how they can become a Qualified Security Assessor (QSA).  The only want to become a QSA is to work for a QSA company, be accepted by the PCI SSC, and attend industry specific training.  But what about the rest of us who want a badge of legitimacy without changing jobs?  For this there is the CPISM.

The Certified Payment-Card Industry Security Manager (CPISM) is the de facto certification for those within the payment-card industry who want to prove their security and industry knowledge.  To prepare for this rigorous exam there are a few documents available online to assist you.

First there are the CPISM Knowledge Domains.

• 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

Check online for the following documents at the Society of Payment Security Professionals (SPSP):

• CPISM Overview Document
• CPISM Bibliography
• CPISM Study Guide

Still not ready?  Enroll in one of the in-person training classes and get direct education to help prepare you for the exam.  Check the SPSP website for dates and locations for the training classes.  The next one is August 13-14, 2008 in Salt Lake City, UT.

Fraudsters test AVS system

David Gamey pointed me to the Register article on yet another scam fraudsters are using to defeat credit card fraud checks.  We have discussed this topic before with pay-at-the-pump, but this new attack really goes to the heart of a fraud check that is called the Address Verification System or AVS.

Because AVS does not check all values in the address (i.e. just the house number or postal code) it is possible that an attacker could use an alternate address that has the same numbers (i.e. same house number but different street).

However fraudsters have begun exploiting the fact that many addresses can have the same AVS code. By making sure billing addresses and delivery addresses used in scams have the same code they make it more likely that purchases will go through.

This is, at best, a weak attack because it cannot be monetized quickly over a large number of card numbers.  In order to perpetrate the attack the attacker would need to have your name, address, and credit card number.  This information is usually obtained from e-commerce compromises, though could originate from other sources.  The attacker would then need to find a drop site that has the same information that is checked for in your address (i.e. same house number but different street).  This could work for one account number.  If they want to replicate it they need to find a new drop site, which is rather difficult and time consuming.

Also, let’s not forget that AVS is not used globally.   For example it is used in the UK, USA and some other regions, but not in continental-Europe and most of the Asia-Pacific region.  This diminishes the potential for attack.  Also, different Issuers may check different information via AVS which means you would need to know what information each Issuer checks, happen upon a card number from that Issuer, that is associated with an address similar to a fraudulent drop site you already have.  These stars do not align so nicely quite as often as one might think.

Verify that Compensating Controls work

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”)

Merchants please submit a Feedback form to the Council

People complain about many things, but the question is: have you filled out a feedback form?  What, you ask?  There is a feedback form?  Oh yes!  And you should be filling it out and sending it back to the PCI SSC (Council).

Check out the Supporting Documents page on the Council website and make sure you fill out and submit the feedback form to the Council directly.

The feedback form is so merchants and service providers can provide feedback to the Council on what their experience was like.  Did you like your QSA?  Did you like your ASV?  Did you have a positive experience?  They want to hear it all.

If you really want to have an impact on the standard then jump in and become a Participating Organization.  Then you can give your feedback not just on the audit but on the standard itself.

Kiosks and PCI

Someone asked me a great question today about edge-case-PCI situations.  The question involved kiosks and their adherance to PCI DSS compliance. We know that kiosks can be just like any other point-of-sale (POS) if they are used as such.  That’s the operative term - how are they used?

Some kiosks actually are POS systems that exist in-line with other POS systems.  These could include self-service POS stations that must be secured and treated just like any other POS.  This is the simplest of scenarios.

Let’s now say that the kiosk exists on the cardholder data environment but is only a web browser that has assess to one web page - the merchant’s e-commerce website.  This system is not meant to be an actual POS but more of an Internet access terminal - that can only access one site.  But if it’s connected to the cardhodler data environment then it would be considered in scope for the PCI DSS audit.

But what if there is no merchant?  What if your kiosk is an Internet access terminal in a mall that can only access 10 different e-commerce sites (from merchants resident in the mall.)  Does this system have to be PCI compliant?  Sure it’s a dedicated e-commerce browser but there is no merchant ID or service provider to adhere to the requirements.

I think the lines of what is a POS and what is not are going to blur in the future as companies deploy more and more of these systems.  Companies will realize they need less and less of the cardholder data and will move towards system that eliminate the data rather than store-and-secure.

Update: 7/30/08 the PCI SSC released an update adding two new device listings to the PCI PED program.  These are “Unattended payment terminals (UPTs) and hardware (also known as host) security modules
(HSMs)”.  As Walt Conway points out, UPTs are basically Kiosks.

Two-Factor Tokens

I finished a great training session today.  Everyone in the class really enjoyed the entertainment and several people described me as “animated” and “high energy”.  I hope that’s a good thing and I didn’t overdo it on the coffee.  One of the participants offered me a complimentary PayPal Security Key.  These are basically Verisign key fobs used for two-factory authentication.  These retail for about $15-20 but PayPal sells them at cost for about $5.

Being the security geek I am, I immediately enrolled it with my PayPal account.  I know nothing changed really, but I somehow felt more secure about my account (which I never use.)  I told Chipmonkey who immediately asked, “What if you loose the token?”  “Uhm… then I can’t log in… or have to jump through several hoops to log in w/o it.”

I think the mass market adoption of any two-factor technology will ultimately be in the form of cell phone payments.  Either your phone can be loaded with a “soft” token, or you simply get an SMS message with an authorization code you can enter into a POS.  Whatever the future holds, it’s nice to feel a little more secure in the present.

PCI Compliance and Virtualization

People have asked if Virtual Servers can be used in a PCI DSS compliant environment or if they violate requirement 2.2.1 which says, “Implement only one primary function per server”.  The answer is that virtual servers, virtual clusters, and even cloud computing are perfectly acceptable within the confines of PCI DSS compliance as long as they are properly configured.  The operative question when discussing the use of any technology within a PCI DSS compliant environment is always “Yes, but is it properly configured to prevent abuse?”

Hoff and Siebert both posted this question here and here.  People may think that <insert latest technology here> will somehow prevent a company from being PCI DSS compliant, when in reality the compliance program is built around protecting cardholder data.  That technology you want to implement is probably fine as long as it doesn’t put cardholder data at risk.  But people focus in on that one requirement and then everything falls apart.

PCI DSS Requirement 2.2.1 is like the ‘force’ in Star Wars - it can be used for good or for evil.  Unfortunately, it is the single most abused requirement in the standard.  Some people, using it for evil, go as far as to say that DNS and WINS cannot reside on the same server.  This requirement is meant for situations when companies try to pile every service imaginable onto one computer, causing a situation that actually puts cardholder data at risk.  For example, if a retail store manager uses the back office PC that aggregates their credit card transactions as their personal workstation for browsing the Internet.  This is a unsafe practice and violates several PCI DSS requirements.

Virtualization is an emerging technology that enables companies to securely leverage one physical server to run multiple virtual systems.  This is beneficial in areas with limited physical space.  If a company can run four virtual systems and only use the physical space of one server they can reduce the cost of housing and maintaining excessive hardware.

Additionally, virtualization provides a number of administrative benefits such as centralized data storage and security, centralized configuration and patch management, and a number of other processes.  Companies can benefit from using virtualized systems but they must also consider how these systems segment access from one to the next.

Just as with PCI DSS Requirement 2.4 (shared hosting environment) and the question of what defines “adequate segmentation” one must examine the security systems that separate one virtual system from another.  Any form of segmentation, virtualization, or shared hosting environment is acceptable under PCI DSS as long as it prevents one set of systems or people from negatively impacting the security of other systems or people.  The delineation point for what defines “adequate” virtualization is any system that can properly prevent one virtual system from negatively impacting the security of cardholder data on another virtual system.  It is the responsibility of the implementor to verify that such controls are in place.

Virtualization will continue to grow in popularity and, properly configured, can be used to adhere to PCI DSS compliance.  The technology itself is not often the culprit of non-compliance, instead it is how the technology is implemented or installed that can cause both security and regulatory compliance mishaps.