ISSA E-News: April 2, 2009

In this Issue

April Issue of The ISSA Journal: Now Available Online
ISSA Web Conference - Preparing for Investigation: Forensics and eDiscovery
Win a Year's Membership When You Visit ISSA's Booth, Number 353, at RSA Conference
ISSA Members Microsoft Feedback Survey
The April ISSA Journal Featured Article: The Art of the Compensating Control
The ISSA Journal Goes Green

April Issue of The ISSA Journal: Now Available Online

This month's issue of The ISSA Journal is now available online and features peer-reviewed articles on:

The Art of the Compensating Control
Who is Minding the Legal Risk around PCI?
The PCI DSS: Friend or Foe?
Compliance: Getting More Secure or Just a Check in the Box?
Into the Cloud We Go
Reverse Turing Testing with CAPTCHA
The Dark Side of Computing: The Study of Computer Crime

If you would like to receive your Journal electronically, just log in to the ISSA website and update your member profile.

ISSA Web Conference

Date: April 28, 2009

Theme: Preparing for Investigation: Forensics and eDiscovery

Start Time: 9am US Pacific /12 noon US Eastern/ 5pm London Time.

Length of Web Conference: 2 Hours

Preparing for Investigation: Forensics and eDiscovery

Register now for this April 28th ISSA Web Conference. Join your fellow ISSA Members in listening to experts as they of discuss trends, laws and case studies for forensics investigation and eDiscovery. Members will have an opportunity to ask questions and will be eligible for CPE credit, after successful completion of the post event quiz.

Complete ISSA Web Conferences recording and slide decks will be made available to members after the live event.

To register for this ISSA Web Conference CLICK HERE

Win a Year's Membership When You Visit ISSA's Booth, Number 353, at RSA Conference

Stop by our booth, number 353, at RSA Conference for a chance to win a one-year ISSA general membership, inclusive of chapter dues (can be used to extend an existing membership).

80% of people who join associations do so because a friend invites them. So invite your colleagues who are not ISSA members to visit the ISSA booth. For each person you bring or refer to the booth, you will receive an additional entry into the membership drawing.

For more information on RSA CLICK HERE

ISSA Members Microsoft Feedback Survey

As part of Microsoft's Trust Worthy Computing efforts to support the information security community they would like to ask you, the ISSA members, to give your feedback on Microsoft's security programs. Please take a moment to take this brief survey. One lucky respondent will win a XBOX 360 through a random drawing.

To begin the survey CLICK HERE

For more information on Microsoft's Trust Worthy Computing efforts CLICK HERE

The April ISSA Journal Featured Article: The Art of the Compensating Control

By Branden R. Williams - ISSA member, North Texas Chapter

This article describes compensating controls: what they are, how to create them, what situations may or may not be appropriate, and what to avoid.

Few payment security professionals can find a hotter topic than compensating controls. They always look like this mythical accelerator to compliance used to push PCI compliance initiatives through completion at a minimal cost to your company with little or no effort.

Compensating controls are challenging. They often require a risk-based approach that can vary greatly from one qualified security assessor (QSA) to another; There is no guarantee a compensating control that works today will work one year from now, and the evolution of the standard itself could render a previous control invalid.

My goal for this article is to paint a compensating control mural. After reading this article, you should know how to create a compensating control, what situations may or may not be appropriate for compensating controls, and what land mines you must avoid as you lean on these controls to achieve compliance with the Payment Card Industry Data Security Standard (PCI DSS).

What a compensating control is

In the early years of PCI DSS (and even my experience under the CISP program), the term compensating con-Why? Because we are not provided a common risk model to use. Please visit http://www.pcisecuritystandards.org trol was used to describe everything from a legitimate work-around for a security challenge to a shortcut to compliance. If you are considering a compensating control, you must perform a risk analysis and have a legitimate technological or documented business constraint before you even go to the next step. We will see more of the documented business constraints coming our way for review based on the current economic situation. Just remember the word legitimate and the phrase perform a risk analysis before proceeding to the next step. Bob's being on vacation is not a legitimate constraint, and an armchair review of the gap and potential control is not a risk analysis. QSAs should ask for documentation during a compliance review, and having it ready to go will make sure you are efficiently using their time. If they do not, you can bet that your assessment will not be thorough.

Every compensating control must meet four criteria before it can be considered for validity:

For an example of a completed compensating control, review the Appendix C of PCI Version 1.2.

An example of a valid control might be using extra logs for the su command in UNIX to track actions executed under a shared root password. In rare cases, a system may not be able to use something like sudo to prevent shared administrator passwords from being used.

What a compensating control is not

Compensating controls are not a short cut to compliance. In reality, most compensating controls are actually harder to do and cost more money in the long run than actually fixing or addressing the original issue or vulnerability.

Imagine walking into a meeting with a customer that has an open, flat network, with no encryption anywhere to be found (including on their wireless network which is not segmented either). Now imagine someone in internal audit telling you not to worry because they would just get some compensating controls. Finally, imagine they tell you this in the same voice and tone as if they were going down to the local drug store to pick up a case of compensating controls on aisle five.

Compensating controls were never meant to be a permanent solution for a compliance gap. Encryption requirements on large systems were made unreasonable early in this decade. Not only was there limited availability of commercial off-the-shelf software, but it was prohibitively expensive to implement. For Requirement 3.4 (Render PAN, at minimum, unreadable anywhere it is stored), card brands (largely Visa at the time) were quick to point out that compensating controls could be implemented for this requirement, one of those being strong access controls on large systems.

For mainframes, assessors would typically do a cursory walk through the controls and continue to recommend an encryption solution at some point for those systems. At one point, compensating controls were deemed to have a life span, meaning that the lack of encryption on a mainframe would only be accepted for a certain period of time. After that, companies would need to put encryption strategies in place.

Compensating control life spans never materialized. Compensating controls can be used for nearly every single requirement in the DSS - the most notable exception being permissible storage of sensitive authentication data after authorization. There are many requirements that commonly show up on compensating control worksheets, Requirement 3.4 being one of them.

Even with no defined life span, compensating controls are not an eternal free pass. Part of the process during every annual assessment is to review all compensating controls to ensure that they meet the four requirements as currently defined by the PCI Security Standards Council, the original business or technological constraint still exists, and it proves to be effective in the current security threat landscape. If certain types of attacks are on the rise and a certain compensating control is not effective in resisting those attacks, it may not be considered OK on your next assessment.

To further cloud the situation, it is up to the QSA performing the assessment to decide to accept the control initially, but the acquiring bank (for merchants) has the final say. Substantial documentation and an open channel of communication to your acquirer is essential to ensure money is not wasted putting together controls that ultimately do not pass muster. Don't get discouraged, though! Compensating controls are still a viable path to compliance even considering the list of reasons why you may not want to use them.

I would not be a true security professional if I did not have a fun story or two based on my experiences coaching companies or individuals to better security. No names will be used, and I am going to change enough details to protect those who were most likely being forced to try the old "push back on the auditor" routine. I hope you enjoy reading them as much as I enjoyed listening to them.

The funniest controls that you did not design

Some of my most cherished stories and experiences come from customers and vendors that had the right intentions but never seemed to follow the basic doctrines listed above on how good compensating controls are made.

During my career I did some IT auditing for a bank that was owned by my employer. I know the drill of responding to auditor findings. They usually start with a meeting bringing all the key stakeholders together to mull over a spreadsheet listing all the findings. Findings are separated out in the "To Fix" pile, and the "To Push Back" pile, each item being assigned to an expert to push back on the auditors. "We don't need that control because of a control over here" or "This gap does not apply to our environment" are common phrases heard in these meetings. Eventually, a happy (potentially unhappy) medium is established, and the audit is closed out.

The same process is often applied to PCI, and the compensating control Cha Cha commences.

Before I poke fun at the following examples, please understand that I am only illustrating a point. At no time were these suggestions made by people who didn�t understand both the requirement and the capabilities of the technology in question. These people were professionals, and based on their credentials and experience, they should have known better.

Encryption has always been a hotly debated topic from the early "Just Do It" message that was pounded into our heads, to the cooler-headed "Slow down, it's a mainframe" axiom that we live by today. My favorite failed compensating control for Requirement 3.4 comes from a vendor that called me late one afternoon. They brought in their product team and tried to convince me that RAID-5 was essentially an equivalent to encryption. Their argument stated you could not take any one drive and reconstruct useful data that could be considered compromise worthy, thus their product should be considered valid to sell to companies as encryption. So if one drive (probably damaged) falls off of a truck during transport, the technology does prevent someone from reconstructing all the data that was on that system. If the system was large enough, chances are that the data on the drive may not provide any use to nefarious individuals either. But that's not really the goal of the requirement, is it? Physical theft prevention is covered in other areas of the standard. The point of the requirement is to render the data unreadable anywhere that it is stored. RAID may render the data unreadable on one physical drive, but it does not render it unreadable in any other circumstance. A simple compromise of one area of the system could lead to the access and theft of massive amounts of unencrypted data. Speaking of encryption, disk-only encryption inside data centers is not very useful either, unless additional user credentials are tied to the decryption process. Another favorite was a vendor that offered PCI compliance through an encryption appliance that was completely transparent to the operating system. So basically, you were only protecting the data as it sat on disk, in a secured facility, with gates, cameras, and Buck, the not-so-friendly security guard that looks like a hiring manager gave a night shift and a taser to the exbouncer of a dance club. If applications sat on disk drives housed in the unlocked part of a post office, then I could see the value here. Until then, the solution only focuses on the physical media and nothing else. Encryption is really not the big problem with Requirement 3; key management is. Once companies figure out that encryption technologies are available for their platforms, they realize that key generation and management is a whole different problem. One vendor who apparently thought I had already checked out for the weekend make a case for using the COBOL Random Number Generator (RNG) to spit out sixteen digits (technically 12 8 bits of data) to use as an encryption key. Yes, you are trying to be random and you will end up with a 12 8-bit key. Anyone with a basic knowledge of encryption will quickly find the problem with that approach. Not that COBOL's RNG is less than R, but that you have eliminated a giant section of possible key space! A 12 8-bit key generated in that manner is the equivalent of (approx.) 53 bits of encryption, thus making it computationally feasible to brute force that key.

How to create a good compensating control

We have spent quite a bit of time setting this section up. We talked about what compensating controls are, what they are not, and some of the best misguided attempts to create them. Before discussing the examples, please remember that they should be used for illustrative purposes only. I have over simplified the scenarios for brevity, and things are rarely this simple in the corporate world. Ultimately, compensating controls must be approved first by a QSA, or barring that, your acquiring bank. I know I do not like it when someone brings an article about PCI to an interview during an assessment, so please don't do that with this one. Now let's walk through a couple of examples of how one might create a good compensating control.

To continue reading or for the complete article CLICK HERE

The ISSA Journal Goes Green

If you would like to receive The ISSA Journal in electronic format you can now opt-in to this new alternative by updating your ISSA member profile. Those who prefer the hard copy will continue to receive their usual copy unless they opt-in to e-delivery.

E-News Archive