Branden Williams' Security Convergence Blog

The definition of cardholder data for most of us usually stops at the Primary Account Number, or PAN. Those pesky digits that we have to protect as they run through our systems cause CIOs to cringe and security professionals to salivate over potential budget money. Before you can embark on your information security journey, you need to understand what you must secure, and where it is. I've posted about this before.

At this year's community meeting, the definition of cardholder data was a hot topic in both general sessions and one of the Special Interest Groups (SIGs). I've always thought the definition of cardholder data was quite clear, but here's a good rule of thumb. This information is pulled directly from the PCI DSS that can be found on the Council's website.

• The PAN. That's the 13-16 digit number that you see on the payment card itself. I don't think that's ever been in question. A truncated number (123456XXXXXX1234, whereby X represents MISSING data, not MASKED data) is NOT considered a PAN. Encrypted card data is still considered card data, hashed data (in some cases) is not.


• If you store the Cardholder Name, Service Code, and/or Expiration date in conjunction with the PAN (such as in a database table), those items are also considered cardholder data and must be protected in the same way you would protect a PAN under PCI DSS.

• A database stores the Cardholder Name and Service Code ONLY. Are those items considered cardholder data? NO, because they are not stored in conjunction with the PAN.


• A VSAM file on a mainframe contains an Expiration Date and the PAN. Are all elements considered cardholder data? YES, because the Expiration Date is stored in conjunction with the PAN.


• A flat file contains the PAN, Cardholder Name, Address, and Expiration Date. Is the Address considered cardholder data? NO. It is not one of the three elements noted as considered cardholder data when stored in conjunction with the PAN. What about the Expiration Date and Cardholder Name? You bet!


• A database stores PAN, CVV2, and Cardholder Name. Is CVV2 cardholder data? YES, but it falls under a different category of data that must not be stored post-authorization. Other types of data that may never be stored include Full Magnetic Stripe Data, CAV2/CVC2/CVV2/CID, and PIN/PIN Block. So if you see this stored in a file, and you know the card has already been authorized, you have other issues you need to deal with and are probably not complying with PCI DSS.

Posted by Branden Williams at 5:28 AM | Permalink | Comments (0)

Vegas is in the bo0ks, baby! I'd call it a successful community meeting. The networking opportunities were fantastic, and the sights were awesome ((including seeing Russo dress up like Elvis which I did not take a picture of... see Bob? I can play within the rules :). More on the handling of social media later.... it was not handled well.)). For those staying in THEhotel, we got to walk off calories consumed with the long walk from the room to the conference center that we made at least twice daily. Of course, it is Las Vegas. It's REALLY hard to concentrate when you know that you don't have to walk far to be bombarded by flashing lights, bells, whistles, and other sensory delights designed to make you give money to the casino. I came out about even.

WIN.

The first posts and stories have already started coming out; I've submitted my feedback on the meeting, and now it's time to analyze!

One of the first things that I wanted to address follows the same theme that traditionally spawns some of my most popular posts about the community meetings.

I think we've gotten to the point where it's time to split out the Q/A into two groups. Some of the same questions are being asked in the Q/A session that have been asked for the last two years. These questions are still valid, but do we need to stop down a room of 700 folks for them? Probably not. The new professionals responsible for working on PCI NEED this information, but maybe we can do a basic Q/A first while other attendees can do something else, then do the advanced one later with everyone. That way everyone has the benefit of listening to the advanced questions with some set baseline.

Most questions provoked nothing from the audience, but there was ONE question that garnered a HUGE round of applause from the room. Bless the attendee who asked when issuers will be required to comply. You'd have thought that someone took over the PA at Fenway and screamed "YANKEES SUCK" into a live microphone.

I like sitting in these sessions because I need to know the pulse of the PCI community. This year is by far the most sophisticated crowd. There were no questions like "Uhh, what's a Web Application Firewall, and what do I do with it?" ((Yes, we had one like that in 2007.)) Instead, we had some great technical questions that, unfortunately, left many people wanting based on the answers they got back from the Council.

I'm seeing a trend that I'm not sure how to fix. Many questions that were asked had answers available to them either on the PCI SSC website or FAQ, or on the payment brand website itself. The sites are easy for me to navigate, but I've been doing this for many years now and I'm a bad benchmark on the availability of information. In fact, we're so used to Google telling us exactly what we want the first time, that few people actually know how to harness its power. The information available to PCI stakeholders is, for the most part, accessible. There is a LOT of it, but it's there. Becoming a Google power user might help people find the information as well.

Like in most things, you get out of this process what you put into it. Spend a little time thinking of your questions BEFORE you come to the meeting to make sure you will get an answer other than:

1. Read PCI DSS.


2. It's up to your QSA.


3. Ask your Acquirer.


4. Read the PCI DSS FAQ.


5. It's on the website.

Before you can ask the question, you need to make sure you are talking to the right people! Missing this step will almost guarantee you will end up with one of the five answers listed above.

• The PCI Council (Intent): Only answers questions about the intent of PCI DSS. Don't ask about fines, complain about Level 2 Merchants having to get a QSA, or ask if Bit9 will comply with Requirement 5. Those will lead you into one of the five buckets above.


• The Payment Brands (Enforcement): Only answers questions about their specific compliance program. Visa's CISP, MasterCard's SDP, American Express's DSOP, Discover's DISC, and JCB's DSP all refer to PCI as the common set of controls, but all have different requirements to comply ((Look for more on this topic in coming days)). You should ask them about fines or when to submit an SAQ. Don't ask them about the intent of a PCI requirement (though they will likely answer to assist you) or if RSA's SecureID is the only thing that will satisfy Requirement 8.2. While they may try to assist, I typically see (with one exception) payment brands avoid those discussions, especially when their competitors are present.


• Your Acquirer (Enforcement): Most compliance questions are better suited for your acquirer because they are responsible for your actions on the payment network. Acquirers don't have all the answers, and you should not ask them if VeriSign EV-SSL will comply with Requirement 4.1 (hint... it will) or the intent behind a particular requirement. Again, they may try to point you in the right direction, but Payment Brands are responsible for enforcement of PCI, and they enforce it on your Acquirer who then enforces it on you.


• Your QSA (Interpretation): Your QSA is an important step in the PCI DSS process. If you don't like her, the process is going to be a pain. Alternatively, if she works well with your company, things will work out much better for everyone in the end. It's your QSAs job to weigh all the guidance from the Council and apply it to your individual environment to determine it's compliance with PCI DSS. Ask her questions about specific technologies and their compliance in your environment. Don't forget to tell her EVERYTHING about the solution. Context is a real issue with these types of questions.

Never-ever-never-ever-ever-not-ever-never start a question with something like "I have a client that ..." or "I deployed Microsoft Sharepoint..." Those questions are probably too specific, smell of someone fishing for free consulting, and do not get to the intent of a requirement. Even if you have a valid question on the intent of PCI DSS, starting your inquiry off this way will cause members of the Council to get a little skittish. Let's walk through an example.

Christopher is the compliance manager for a regional, medium size retailer. For some of his stores, he is considering installing a single beefy server that will run some kind of bare metal hypervisor and multiple guest instances to replace the existing four servers in each store. Some of these servers must comply with PCI DSS, some may not. Christopher read PCI DSS Requirement 2.2.1 and is wondering if his virtualization strategy will comply with PCI DSS.

Here's how Christopher can ask the question to guarantee he will get one of the five answers above:

Can I run VMWare ESXi in my store and comply with PCI DSS?

Here's how the question SHOULD be asked.

Is the intent of PCI DSS 1.2 to define a server as a physical machine or would virtualization work?

Excellent! An answer that is meaningful! The first of those two questions is best asked of a PCI Expert, the second is one where you have done your basic research, and are really trying to understand the intent of the controls so you can design a compliant solution.

So when you go to ask the Council a question, be sure that they are the correct group to ask, and that you ask it in a way they can answer it. More posts coming soon including my next installment, How To Define Cardholder Data!

Posted by Branden Williams at 5:20 AM | Permalink | Comments (1)

Ahh, the haters. Everyone that deals with PCI on a regular basis knows one. Sometimes they take the form of a guy that doesn't want to actually do his job, or an armchair security gal, or your nemesis that uses his industry position to irresponsibly spread false propaganda, or true security experts that point out serious concerns or flaws with the standard. As security professionals, we key stakeholders (including QSAs, ASVs, payment brands, and the framers of the standard itself) need to listen to the last group intently to ensure that we understand the risks as it pertains to the changing threat landscape, making adjustments where appropriate to protect the data entrusted to us.

PCI haters are valuable people. By and large, the majority of the individuals (normally falling into the first three categories above) hating on PCI are doing so out of a fundamental misunderstanding of the standard, or an attempt to apply it to a larger area than it was intended.

For example, if you take PCI-DSS and make it your security TOPline (meaning the best you will ever achieve security-wise), you will be missing key sensitive data elements in your security program, potentially leave gaping holes for hackers to hurl their bits through. Or maybe on the fundamental misunderstanding side, like if you still think that the payment brands force merchants to store cardholder data.

"If you think that the payment brands force merchants to store cardholder data, you might be a PCI haytah." If that was as painful for you to read as it was for me to write, I win.

The amount of misinformation about PCI is about as enormous and incredible as the number of people that spread it. So why should we love people like this?

For one simple reason, people are TALKING!

Sometimes these folks cannot be reasoned with because their minds are closed. Getting help in Security is like getting help with addiction. Step 1, admit you have a problem. For those folks that do not want to change, you are wasting your breath. They have to walk off the cliff on their own before they will listen. They may outwardly say, "Don't tell me how to do my job!" What we really hear is, "Don't tell me how to do my job, I can run this thing into the ground just fine on my own."

But for those that have open minds, it's amazing what a little dialogue will do to further both your cause and theirs. I recently had a discussion with someone who complained about password complexity requirements. They believed that all of these controls were too prescriptive. When I showed him how easy it was to break his six character password, and an easy way for him to keep his six character password, but add a second layer of authentication with a token and exponentially increasing the strength of his authentication system, he promptly began to open dialogues with his management to roll the technology out to all key users.

For his business, this made sense. It's not for everyone, but you will never know unless you open a dialogue.

So go find a big PCI hater that you know and engage her. Many of the haters have useful points and need to be understood. If your hater is more of the closed-minded zealot variety, smile, nod, and get to know his boss. She might be calling you one day.

Posted by Branden Williams at 6:35 AM | Permalink | Comments (0)

I hope to see many of you next week at the PCI Community Meeting in Las Vegas! VeriSign will have a booth and is a sponsor for the event. If you are going, please do stop by our booth and attend our sponsored cocktail hour! We'll have some goodies and some exciting news for everyone that stops to chat!

At this point, I'm not sure what kind of coverage I'll be able to provide from the meeting, but more on that soon.

Before you arrive for the sessions, I urge you to review the myriad of information available on the PCI Security Standards Council website, including the recently published SIG papers, and prepare your questions. This is your chance to ask the Technical Working Group and other members of the Council directly! Although, be prepared for them to tell you it is up to your QSA.

The best way to avoid that answer is to ask questions that don't start with "My environment has X technology," and ask for their intent behind requirements. As an example, a bad question to ask would be "Can I use whitelisting instead of anti-virus?" A good version of that question might be "Is the intent of 5.1 to stop the execution of malicious software, and can compensating controls be considered?"

It requires that you do a little homework, but as with most things in life, you will get out of the event what you put into it. Preparation goes a long way when talking to the framers of the standard.

Hope to see you there!

Posted by Branden Williams at 3:10 AM | Permalink | Comments (0)

Bob Carr gets it.

He had to suffer through one of the largest credit card breaches on record to get there, but he gets it.

Digital Transactions Magazine published an article featuring Carr entitled Don't Hire a QSA by Seeking the Lowest Bid, Warns Heartland's Carr. In it, Carr painfully recalls how his previous assessors did not provide him much value, and how the low-cost bid rarely ever the best bid. If you read his article, he doesn't specifically argue that costs should start escalating quickly, but rather he argues that companies should spend the time to get a QSA that does a thorough job, and is not motivated to get in the door, go as quick as possible, and get out the door to have a prayer at breaking even.

On Friday, I wrote about Bill Brenner's "4 Ways to get the Most from your QSAs," and believe that his first point, "Choose your vendor wisely" falls into the very essence of what Carr is talking about. I've noticed that more merchants are taking our general advice of interviewing your QSA before you hire them. If price is your only motivating factor, be prepared to be both disappointed and disillusioned with the entire QSA process. If you underestimated the cost of your assessment, it's time to go back to the well to get the funds to do it right.

Of course, this attitude requires foresight. Which would you rather do: ask for more money today, or ask for a TON more money tomorrow because you had a breach? Most would pick the former, but their actions paint a different picture.

Hindsight is, of course, 20-20.

Posted by Branden Williams at 9:26 AM | Permalink | Comments (1)

Bill Brenner of CIO magazine published a feature article on Wednesday entitled "4 Ways to Get the Most From Your PCI QSAs" where picks four main things to focus on when using the services of a QSA. VeriSign published a whitepaper last year going over several items to consider when shopping for a QSA, all of which tied back to Brenner's recommendations.

Brenner asserts that the four ways to get more from your QSA are:

1. Choose your vendor wisely. PCI compliance is probably an important project to your organization, so be sure you find a QSA that will make your project successful. Don't hastily throw a solution together, treat it like the strategic project it is (and then treat it like the program it should be once you meet compliance).


2. Lay the groundwork. Don't go into assessments wondering if you will pass. KNOW the outcome before you start! That mean's pre-assess!


3. Give the QSA access to key players. Many times I have been on engagements where the wrong people are presented for interview. Either they are too junior, they are the FNG, or even the wrong department. Giving access to key players saves both your time and money.


4. Don't treat the QSA like an enemy! This one is the MOST important of the four. Your relationship with your QSA should be a partnership. If you treat your QSA like an auditor, you are only doing harm to yourself.

Posted by Branden Williams at 4:39 AM | Permalink | Comments (0)

Are you a service provider frustrated with the steps you have to go through to become listed on Visa's global list of PCI DSS validated service providers? The process of getting listed when you are not a member or a direct agent of a member seems clouded and painful, until now!

Visa recently added a very detailed Third-Party Agent (TPA) section to the Risk Management section of their website that details exactly what needs to be done to be listed on the site. If that were not enough, there is a fantastic FAQ in PDF form that you can take with you wherever you go.

As part of this change, Visa eliminated all of the old classifications like Independent Sales Organizations (ISOs), Third Party Servicers (TPSs), Encryption and Support Organizations (ESOs), and Merchant Servicers (MSs), though that terminology is still used to describe services provided by a TPA.

If you fall into this TPA category, check out that FAQ document. There is a step by step process listed there that will guide you through this new process!

Posted by Branden Williams at 8:36 AM | Permalink | Comments (0)

Did anyone else giggle a little bit when they saw that Oracle delayed its quarterly patch release because it would coincide with the OpenWorld 2009 Oracle conference? According to Oracle, they didn't want administrators to have to choose between installing updates in a timely manner and attending the conference.

That's funny for me because I have NEVER met an Oracle DBA that was excited about pushing patches to their servers in a couple of days (the original release was slated for October 13, and the conference ends on the 15th). In fact, between Oracle DBAs and z/OS Administrators, I don't know who wins the prize for yelling the loudest about patching within thirty days.

THIRTY days.

Not two days. THIRTY days. OH the screaming that would ensue. "HOW DARE YOU TELL ME HOW TO PATCH MY SERVERS!! There is NO way I can do it in thirty days! I'M SUING EVERYONE!" *stomp* *stomp* *stomp* *stomp* *stomp* *stomp* *SLAM*.

That was a fun day, and I think that gentleman was reassigned shortly after that outburst.

One of my favorite Oracle installs was a database I was assessing a couple of years ago, that had never been patched since it's original installation sometime in 2005. In fact, October 2005 was the first quarterly rollup that this particular version would have received, but of course, it was not present on the server.

So while I do applaud Oracle's decision not to make the two events coincide, I think everyone is giggling a little bit in the background because we all know that nobody (ok maybe 1%) patches their production databases within two days of their release. Sure, starting the process, but not production.

Posted by Branden Williams at 6:57 AM | Permalink | Comments (0)

Do you ever wonder how we got into this situation? Where merchants are facing tremendous fines for non-compliance, companies are being compromised by hackers here and overseas, and data security programs seem to be non-functional at best (if not non-existant)?

I'll tell you how... MBAs. Yep, those pesky folks that learn the inner workings of how to take advantage of numbers to best increase their own personal compensation?

Yes, another MBA dog-pile. And I feel qualified to pick on my MBA brethren because I are one.

All seriousness aside (did I do that right?), let's think about how payment systems started inside retailers. This is a classic example of the Build vs. Buy problem in every single MBA finance class. In the last three decades of the 20th century in the US, retailers faced more pressure to accept branded bank cards for payment--those brands being virtually the same as they are today. Before the significant advances in computing power in the 1970s and 1980s, credit cards typically were processed by hand with something affectionately referred to as a knuckle buster. The first electronic authorization systems were not even released to the market until the 1973.

So in the late 1970s and early 1980s, MBAs were presented with the following problem. Outsource processing to a third party, or build my own processing systems and pocket the difference in cash.

As we all know, most went with the latter.

The financial models typically were quite compelling and showed a relatively rapid payback of the initial investment. The problem is that early in this decade, the financial models changed. Various governments and industry institutions created regulations for protecting data--something that security professionals have argued for years. Now the maintenance costs for touching this data has dramatically increased, thus rendering the old financial data that went into the original Build vs. Buy model irrelevant.

In fact, I challenge any merchant to take a hard look at this part of their business. Why are you processing and/or storing all of this data? Shouldn't you go back to your core competencies (another fun MBA term) and focus on retailing? Why are you building a giant cost center around processing credit cards for a few cents per transaction? Isn't that the money that you should be spending toward information security (and as a secondary supported by the first point, compliance)? Knowing information about your customers is essential to doing business, but what information do you need? What can you outsource?

Information Security IS a cost of doing business, but it's impact on your bottom line can be greatly reduced by smartly outsourcing items that do not fall under your core competency.

So there you have it. Blame those savvy MBAs for making the numbers work in such a way that caused this giant mess!

Posted by Branden Williams at 10:50 AM | Permalink | Comments (0)

We're getting REALLY close. All of the content is in, and the publisher is working toward production! Anton & I have worked hard to bring you the most technically accurate and useful reference book to carry with you during all of your PCI DSS efforts. You will notice that the book reads much better than the first edition, and we've included some GREAT case studies for you!

Well, I think they are great anyway; I wrote almost all of them. That was my favorite part of this process--writing the case studies. In fact, I had to put off all case study writing to the end of each chapter and use it as my motivator to get through all of the content!

All in all, about 80% of the material in this book (maybe even more, just an estimate) is NEW. Some of the larger chapters contain more than 15,000 words, while the smaller ones are under 4,000. Regardless, we've worked hard to make sure that your reading experience with this edition leaves you thinking about how to apply our teachings to your environment, and laughing a little bit along the way.

We're working on a website, but it's SUPER secret right now. If you have suggestions for what you might like to see in the site that supports the book, please leave them in the comments field below. We'll also have a couple of contests with prizes for our readers! But more on all of that LATER!

The book is scheduled to release on December 15, 2009, but pre-order now to ensure you get your copy quickly! I believe there will also be a Kindle edition, so watch for that!

Click here to see the book listed in Elsevier's catalog, and then on Amazon and Barnes & Noble (the typos in the online stores are corrected in the catalog, and should be corrected on the other sites soon).

Posted by Branden Williams at 9:33 AM | Permalink | Comments (2)

Are you at the VMWorld show? If so, be sure to attend my panel discussion entitled: "Virtualization and Compliance: The Auditor's Perspective" today at 11:30am in room 310! Joining me on the panel will be Nigel Tranter, Partner at PSC, Ray Zadjmool, Principal Consultant at Tevora Business Soltions, and Bill Hau, Vice President at Foundstone. The panel is moderated by Charu Chaubal of VMWare.

Hope to see you there!

Posted by Branden Williams at 8:28 AM | Permalink | Comments (0)