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% [?]

Several people have written in to ask me about the different web application scanners and their applicability to PCI. One should remember that there are several requirements that a web application scanner could use used for, mainly 6.5, 6.6, and 11.3. This is not to say that a web application scanner will meet these requirements, but that it could be leveraged to assist compliance in these areas.

Liquid Information has a blog post referencing a paper on ha.ckers.org comparing the top tools.

He chose three scanners for the test, less known NTOSpider and two major players that are WebInspect and AppScan. He then ran these in default configurations against different kind of web applications and collected statistics/metrics on coverage and accuracy (e.g. amount of false positives, found vulnerabilities etc).

It looks like NTOSpider came our ahead, but read the results and let me know what you think.

Popularity: 33% [?]

As many of you know by now, when meeting a PCI control requirement with a compensating control two things should happen:

1. The control should be marked “In Place” with a comment added that it is being met with a compensating control, and
2. The Compensating Control Worksheet should be completed.  This can be found in the Appendix of the Security Audit Procedures (SAP)

In order to determine the “Objective” one must first understand the intent of the original control.  What many people forget is that they want to know not only what the requirement intended, but also what it did NOT intend.  Sound confusing?  This is an advanced area of PCI compliance.

The intent only tells you the direction you want to go, but does not tell you the directions you want to avoid.  For example, if a requirement says you should not use FTP because it is susceptible to password sniffing you can either leverage:

• VLAN+ACLs, IP address restrictions, or tunnel it through FTP
• Truncate the card number or encrypt the payload with public-private key pairs

Both methods work to mitigate the risk, but from different control vectors.

Popularity: 27% [?]

PCI is confusing. The requirements themselves are simple enough, and aim to strike a balance between business objectives and prescribing network topology. I have found it a useful guideline at CSO-level, even when engineers find it a little frustrating, and upper management are confused by detail.

What PCI has done well however is not to dictate too precisely, to the point where companies can automatically fail because of their configurations. This is done in the form of “compensating controls”. An example of this reached me today via Martin McKeay’s PCI DSS Yahoo! group. The question was around holding non-encrypted credit card data, and how long it was viable to do it for. Now under strit PCI DSS rules, you shouldn’t do this at all. But compensating controls suggest that if you have issues, such as a mainframe that will not support encryption (as posted by Marting in reply) then there are ways of avoiding the penalties

He then goes on to say: “You cannot put in a series of controls you think are okay and hope it will pass the audit. Compensating controls are something that have to be run through the PCI system on an individual basis. The worst part of that is, what gets an okay for one merchant may not get passed for another simply because of the way your auditor presents it. There’s no standard for compensating controls.”

If there’s confusion over parts of PCI, or you don’t think there’s a way to achieve a part of it in your environment, the chances are there’s a compensating control. Your QSA should be aware of all of these and advise accordingly. Personally I would be wary of any QSA affiliated with or creating their own software/hardware solution to address anything but the audit itself as this will create a bias in the report, but the QSA is there to help.

To get the comments ball rolling, I’d like to know 2 things. Should we be trying to standardise compensating controls in some way? If so, how? And, should QSAs be required to be independent?

OK, that’s 3 things.

Disclaimer: I work for a vendor, but it is in no way associated with Aegenis. I am an associate of Heather’s from a previous job and a friend of Mike’s. I do not sell my wares here, or try to push people towards them in my replies.

Popularity: 38% [?]

Mike Rothman of Security Insight regularly links to our blog so we figure it’s time we return the favor in an article on compensating controls. I should first point out that we have written on PCI compensating controls in several key articles: compliance through compensating controls and the category ‘compensating controls‘.

I disagree with this article’s view of compensating controls as a “loophole”. The reasons is that because compensating controls are sometimes based on subjective information, the process is flawed. To say this would be the equivalent of saying there is a loophole in every compliance program. Let’s just nip this one in the but and say that “security” is subjective.

I like that Mike went into some potential security measures that a company may try to leverage as compensating controls, but the fact of the matter is that compensating controls are (still) situational. There were several ways to take this article. It could have been written from “here are several areas that could use compensating controls” or (as this article did) “here is one requirement and several items that companies leverage as compensating controls.”

From this second perspective the subject of evaluation was encryption and alternatives to implementing it as required. With this requirement I almost always have seen multiple controls used to compensate for the lack of encryption. The article lists the several controls and puts database security as the only one really good enough. I would say that any compensating control for encryption should include several of the security measures listed in the article, not just one.

Another thing the article does not discuss (probable due to space limitations) is that “encryption” is a nebulous area and applies to many different data stores: database, flat file, email, etc. So, when the article says that email encryption is a bad alternative to data encryption one has to ask, where is the data we are trying to protect? If it is being sent via email then, yes, email encryption will actually meet the requirement without a compensating control.

I like that people are writing about examples and case studies, but it’s a little more situational specific.

Update: Any time we reference compensating controls it is important to reference the PCI Security Audit Procedures (SAP), which contains Appendix B - Compensating Controls for requirement 3.4 (encryption) and Appendix C - Compensating Controls Worksheet.

Popularity: 39% [?]

While listening to the This American Life episode of the Ten Commandments, I’m thinking about the ten commandments of PCI. I would like to know what your PCI “commandments” are, but here are mine.

1. Thou shalt comply with PCI. All those who store, process, or transmit cardholder data must comply with PCI.
2. Thou shalt use the Security Audit Procedures (or Self-Assessment Questionnaire) and not leverage any other compliance standard before PCI.
3. Thou shalt use compensating controls carefully, and only to meet the intent of the original control. See also Commandment 6.
4. Thou shalt remember your acquirer’s validation deadline (or Visa CAP deadline) and keep it holy. If you cannot, let them know your timeline and update them often.
5. Thou shalt honor thy QSA and ASV, but not let either control you.
6. Thou shalt not get compromised. Ever. End of story. But if you do, “Thou shalt have an efficient and highly effective Incident Response Programme to ensure compromises are identified and dealt with as quickly as possible.”
7. Thou shalt not store sensitive cardholder data after authorization. Rid thyself of track data, card verification value 2, and PIN block data.
8. Thou shalt map out your transaction flow and all locations where credit card data is stored. Now render the PAN unreadable!
9. Thou shalt use compliant service providers and payment applications. Do not commune with non-compliant entities.
10. Thou shalt not covet your neighbors compliance certificate. Get to work on your own compliance (and information security) program and do not wait around thinking it will pass.

Popularity: 26% [?]

I’m curious to see if anyone was affected by the 0-day Microsoft vulnerability that was released right before the end-of-quarter.

Did your company wait until the last minute to submit their PCI report to their issuing bank (as many companies tend to do)?

Did you have problems with your ASV or auditor — as there is no official patch available? Here is an unofficial/temporary patch by-the-way.

What compensating controls did you come up with?

How did it ultimately affect your compliance effort?

Popularity: 32% [?]

I was talking with someone (at this age I forgot who) about compensating controls for file integrity monitoring and they suggested a bootable point of sale (POS) system with read-only access. What an excellent idea, and if it was yours please come and claim your prize.

There are so many PCI controls that must be implemented on each retail register that it is cost prohibitive in many cased to meet the letter of the PCI law. Most retailers use compensating controls for addressing one or more areas of compliance on their POS systems.

If you have a read-only POS system you can reduce maintenance and address the following:

• Storage of cardholder data on the register (requirement 3)
• File integrity monitoring (requirement 11.5, 10.5.5)
• Baseline configuration standards (requirement 2)

I suppose audit logging could be a problem, because you cannot write the logs locally, but you never wanted to do that in the first place anyway.

So I googled for “bootable POS” and received two options:

1. The first from Microsoft, a network bootable thin-client POS system (more info)
2. The Squirrel POS system running Linux, which features a bootable image and RemoteFS

I think when people finally start upgrading their old POS systems they should seriously consider bootable or centralized POS systems to reduce maintenance and compliance costs.

Popularity: 40% [?]

I agree with Michael that security is not seasonal but feel a little education is needed for the other Mike when it comes to his views on compensating controls.  I used to be in the criticize-and-critique camp, but that was before I spent so much time with PCI that I taught it to others.  (Am I sounding like a religious convert?)

Mike argues the following:

For a little while, the way PCI was structure was actually pretty good and made it relatively clear where the line would be drawn relative to network and data protection. But then they introduced this concept of “compensating controls” back in November. That really screwed things up. Why? Because basically it gives every vendor a way to spin how their stuff offers an alternative to the right answer of actually protecting the data.

It sure sounds like it doesn’t it.  I mean if any merchant can get out of a compensating control just by invoking the ghost of “compensating controls” then where are we left in terms of security?

The problem with this logic is several pieces.

• First, let’s define compensating controls.  These are controls that are “above and beyond the current control” and “meet the intent and rigor of the original requirement.”  Two criteria that are not so easy to meet.
• Second, the company’s auditor (the QSA) must sign off on all compensating controls.  This means that the auditor is putting their company on the line for the work they do.  Do you remember the CSSI data compromise?  Did you notice that one assessor was no longer on the approved list after that event?  Coincidence?
• Third, compliance is just a point in time (as many people have agreed.)  The state of being in compliance for one audit means very little compared with the loss that can occur if you are out of compliance while the attackers are siphoning credit card data from your network.  The trade-off is not worth it.
• Finally, the requirements could not be written in such a way that they are both specific (a very good thing) and apply to companies of all sizes.  The concept of compensating controls is necessary to enable companies to map their compliance program back to their security program!

PCI was not meant to create more paperwork and documentation (that is called SOX… the real test of this is how many “SOX Auditor” rooms have you seen in a company?  Ok, now how many “PCI Auditor” rooms have you seen?)

The reason for having concepts such as “compensating controls” is to companies who are securing their networks properly can leverage those controls instead of implementing other just in the name of security.  Could this concept be abused? Certainly, any concept can.  Even compliance requirements can be abused.  But try to look at the good instead of the bad.

An example of compensating controls would be a mid-range AS/400 system that stores credit card data.  If that system wanted to be in compliance it would have to encrypt the data on the disk.  The AS/400 administrator would argue that they have RACF installed, secured, and are properly implementing their security program.  In addition, they monitor and log every action of every user.  They may also have an IPS blocking rogue attacks against the system.  Do they really need to encrypt the data?  or do these controls compensate for the lack thereof?  I would say that compensating controls is not only a good thing but a necessary aspect of or any compliance program.

Remember COBIT?  That takes a risk based approach to compliance and so should PCI.  Thus the compensating controls.

Popularity: 23% [?]

From the last post you can infer that I was frustrated at the volume of mostly correct information available on the Internet. One of the reasons for writing this blog is to clarify the confusion and answer common questions raised regarding the PCI program.

While searching for information on PCI security I came across “The New Payment Card Industry (PCI) Industry Data Security Standard FAQ” [PDF]. Now, there are two problems with this title:

1. Never name something “new” because invariably it will become old and your document will itself look aged.
2. Although I believe in recursive acronyms and understand their usage, saying “…Industry (PCI) Industry…” is just wrong.

But let’s ignore the details and provide answers to the questions that they ask. This post will reiterate their questions and provide answers of our own.

What is the new PCI Data Security Standard?

The PCI DSS is one of the PCI initiatives that came about from the collaboration (don’t ever say “collusion”) of the different credit card associations including: Visa, MasterCard, American Express, and Discover. (JCB may also be thrown in there.) It is a set of requirements that require everyone who stores, processes, or transmits credit card data to properly protect that data from compromise.

It came about for several reasons:

• The Issuers absorb credit card fraud even when it is other players (or their service providers or agents) in the credit card transaction process that leave the data open to compromise. This left the Issuers at the mercy of the insecure merchants and service providers until the PCI DSS set mandatory requirements for security.
• With all of the bad (or good) press that credit card theft received in 2005 it would have only been a matter of time before federal legislation interfered by enacting laws on handling credit card data. Creating a security standard enabled self-regulation and prevented federal regulation of the industry.
• Increasing security reduces credit card theft which increases consumer confidence and in turn increases revenue for everyone. From Wiki: “there also exists an economic argument that credit card use increases the ‘velocity’ of money in an economy, the result, higher consumer spending rates and higher GDP.” (More on this in another post.)

When did the standard go into effect?

The PCI standard went into effect on December 14, 2004 as the document points out but it fails to mention that Cardholder Information Security Program (CISP), which now implements PCI and was its precursor standard in the US, has been a requirement since 2001. Back in the early days of credit card security compliance the scope of CISP was limited to just e-commerce systems. In the following years the CISP scope began to increase to the internal network and down to the point of sale (POS) software themselves. The MasterCard Site Data Protection (SDP), which merged with CISP to form PCI, has only ever focused on e-commerce.

Who is required to pass the new PCI Data Security Standard?

They got this one right in that any entity that “stores, processes, or transmits” cardholder data must be compliant. When? Now! Everyone that meets the above criteria must be compliant now and validate compliance based on their annual renewal date, which is the shorter of: (1) notification by your Acquirer/Visa or (2) one year from previous compliance validation. If the Merchant or Service Provider levels change or new requirements are enacted, the entity has usually one year to meet these new validation requirements.

What steps should I take to comply with the PCI Data Security Standard?

The first thing a company should do is to take a look at the Visa PCI web site.

The second thing a company should do is to engage a qualified or trained person to assist them with the compliance process. This may sound like a sales pitch because Level 1 Merchants can do the audit internally, but having someone (anyone) who can interpret the PCI DSS requirements, make recommendations on common implementations, and provide assistance with more complex questions will prove invaluable. An external assessor will help you manage the way your information security dollars can be best spent to navigate the compliance waters. You want someone who knows the industry and isn’t just there to learn at your expense.

The third thing a company should do is get to work on the top most difficult requirements:

• Network Segmentation
• Encryption
• Policies and Procedures

What are the requirements of the PCI Data Security Standard?

I agree that there are two parts: (1) Internet vulnerability scanning and (2) on-site assessment performed by qualified external assessor or internal auditor. Rough estimates say that about 25% of Level 1 merchants use an internal auditor while 75% of merchants use an external assessor. This means that most companies look for assistance from trained professionals. But do not despair, much of that 25% are the using outside help of trained professionals, which is a good thing. Just make sure those people know what they are doing and not using your company as a learning experience.

Also, although Level 2-3 merchants need only submit a self-assessment questionnaire (SAQ) and Level 4 need not validate, all companies must comply with the same PCI DSS requirements. Most companies do not know this and only meet the requirements laid out in the SAQ not the Security Audit Procedures (SAP).

What can I do on my own?

Lots! You can project manage your compliance effort, perform the necessary remediation, even audit the process. The only thing a company should not attempt is to interpret the requirements on their own. This requires someone who has “been there and done that.” It’s not that your information security or audit employees are not trained it’s that everyone can interpret the requirements differently. There is really no way around this and an outside trained professional should be consulted to answer questions about:

• Intent of requirements
• Advice on compensating controls
• Examples of what others in the industry are doing
• Recommend remediation options
• Guide and manage the process (hand-hold) as necessary

Update (Sept. 27, 2006): Wells Fargo Merchant Services has a FAQ on-line that discusses many questions that go into more detail. They also address specific questions that many merchants have. What follows are some of the questions from the WFB FAQ with more elaboration.

What is “cardholder data”?

The definition of cardholder data has been clarified in the executive summary portion of the PCI Security Audit Procedures v1.1. There is a matrix that lists items such as PAN, cardholder name, service code, expiration date, magnetic stripe, CVV2/CVC2/CID, and PIN block data. The matrix shows that the service code can be stored, which is a change from previous requirements. It can get a little confusing because the definition of cardholder data is two things:

1. Cardholder data refers to all the information from the credit card that is used in the transaction.
2. Cardholder data compliance shows that the PAN must be encrypted when stored and the “Big 3″ (track data, CVV2, PIN block) cannot be stored post authorization.

What is the scope of a PCI audit?

Scoping a PCI audit requires more than a simple answer, but the short story is well documented in the Security Audit Procedures (SAP) v1.1. Here is an excerpt:

The PCI DSS security requirements apply to all “system components.” A system component is defined as any network component, server, or application that is included in or connected to the cardholder data environment. The cardholder data environment is that part of the network that possesses cardholder data or sensitive authentication data. Network components include but are not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances. Server types include, but are not limited to the following: web, database, authentication, mail, proxy, network time protocol (NTP), and domain name server (DNS). Applications include all purchased and custom applications, including internal and external (Internet) applications.

Adequate network segmentation, which isolates systems that store, process, or transmit cardholder data from the rest of the network, may reduce the scope of the cardholder data environment. The assessor must verify that the segmentation is adequate to reduce the scope of the audit.

Merchants have slightly different validation requirements than compliance requirements, which for service providers are the same. (If that made no sense, see other article on PCI audit scoping.)

The SAP also outlines this in the scoping section saying that merchants must address: all external connections, all authorization and settlement connections, all data repositories (sans <500k outside auth/settlement), and the POS environment.

What is a “High Risk” merchant?

I’m very happy that merchants are reminded that some are higher risk than others. Compliance is not a black and white science as some would like to believe. What we are talking about is risk mitigation and so there are many areas of grey.

One place there is no grey area is on the storage of magnetic stripe (track) data, CVV2/CVC2/CID, or PIN block data, which is prohibited. It is also important to mention that even if the corporation does not knowingly store this information it may be retained and stored by third-party applications (payment applications). For merchants this is especially true and they should work to confirm the applications they use have been properly validated for compliance.

How is IP-based POS environment defined?

Both the FAQ and the PCI SAP have good descriptions of what POS systems should be included and what can be excluded. Many merchants misinterpret this to read that the POS environment is out of scope — this is anything but true. POS systems are a large part of the scope for retail merchants. The SAP says:

If there is no external access to the merchant location (by Internet, wireless, virtual private network (VPN), dial-in, broadband, or publicly accessible machines such as kiosks), the POS environment may be excluded.

The thing is, most POS systems have some form of remote access either from the corporation (frame-relay or VPN) or remotely managed (pcAnywhere via DSL/cable or modem).

Do merchants need to include their service providers in the scope of their PCI Data Security Standards Review?

The answer is “Yes” just as the FAQ says, but let’s classify service providers here. Technically, a processor or gateway handling transactions for a merchant is a service provider of that merchant; that is not what we are talking about. It’s the service providers who either (1) given credit card information or (2) given access to credit card information, with the exception of the merchant’s acquirer.

Basically, merchants should examine who they are handing off credit card information to and determine if (1) they are PCI compliant and (2) if contractual agreements are in place to pass on liability in the event the service provider ever exposes credit card information to theft.

Popularity: 27% [?]