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)

Skimming (in the credit card world) is commonly defined as capturing magnetic stripe data during the normal payment process by swiping it through an external (or even inline) device before or after the authorization swipe. External devices are commonly found in stores where a payment instrument is presented, and someone takes the card away from view to process, like at a restaurant. Inline skimming occurs where the cardholder is present during the swiping, and usually involves tampered swipe devices.

The PCI Security Standards Council recently released an EXCELLENT guide with tips on preventing skimming, with sample forms that you can use to track your progress. Most of the skimming techniques employed can be addressed with physical inspection, something with which this guide goes into great detail. Consider doing your visual inspections during a shift change, or at least upon the opening and closing of the stores. Simple visual inspection can go a long way to preventing skimming.

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

PIN-based debit authorization rates have recently increased dramatically, some merchants complaining that their auth rates have increased up to four times their previous rate. In some armchair research, I learned that Interlink (Visa) and Pulse (Discover) have removed interchange caps on transactions. For most merchants, it is still cheaper to process a PIN-Based Debit transaction than a credit card transaction (on a per transaction basis), but for others it is about the same. Or at least the difference in cost is so minimal that their volumes don't force an advantage one way or the other.

Visa is enforcing PIN Entry Device (PED) mandates, effective on July 1, 2010, whereby all PEDs must comply with the PCI PED Standard. For retailers purchasing new equipment in the last five years, this should not be an issue. But for one industry in particular, the desire for electronic signature capture or other payment initiatives has not driven the purchase of replacement payment equipment.

Fuel!

Think about your last trip to the gas station to fill up on petrol. Did you use a credit card or a PIN-based debit card? Actually, the card you used PROBABLY can do both, so which functionality or network did you use? Did you stick with Visa? Or did you use the debit side, Interlink?

If you used the debit side, the payment processing equipment in the pump may have used extremely weak or just single DES-based encryption. This equipment simply does not (in most cases) have the ability to do Triple-DES encryption for PIN-based debit authorization. So as a fuel provider that is looking at a five to ten year payback on any equipment purchased, do you make the jump to comply with these standards now? Or do you just turn off the PIN-based debit support?

Technically, providers can still use Signature-based debit authorizations (if you went inside to pay), so they would not be saying no to debit all together. Will new methods of payment be introduced that might render an investment in equipment today useless? Possibly, but I think what is worse is that the equipment providers woefully underestimated the demand for the product, and prices are likely to increase as merchants race to deploy compliant equipment.

If you are a fuel provider, would you consider disabling PIN-based debit at the pumps? Since nearly all cards that use PIN-based debit can also be used as a straight credit card authorization, wouldn't the extra per-transaction cost be worth it when facing a multi-million dollar (or at least into the tens of thousands for smaller franchisees with just a few locations) upgrade cost? What if you could slowly upgrade over the next five to ten years, and the upgraded equipment could also allow you to buy other things like sodas, fuel additives, or other convenience items right at the pump? Would your return far exceed that if you had to do the upgrades twice?

Consumers, would you not shop at a gas station that did not offer PIN-based debit as a payment option? Since you don't sign a receipt or signature pad at the pump, punching a PIN into the device seems like a lot of work!

Posted by Branden Williams at 9:04 AM | Permalink | Comments (0)

On Thursday, I threw out a blog post which I hope to be the start of a series playing on Dave Ramsey's style for financial peace, and realized I played the role of a consultant PERFECTLY (just like Marshall Eriksen might LAWYER you). SK pointed that out for me when he asks me to elaborate. In a back to school fashion, imagine this conversation as played through your teenage daughter's cell phone.

"I was all, 'Just find the data!', and he was all, 'Whatever.'"

I am so in touch with today's youth.

SK brought up a good point. Let's say you are working with an enterprise that does not have any of the following: 1) a working DLP solution, 2) a reasonable data architecture and framework defined, 3) a reasonable understanding of business process and data flows, and 4) a reasonably accurate configuration management database. Where do you start? Is data discovery even worth it?

First off, throw DLP out the window. Nearly every single DLP vendor missed the boat (or at least their sales and marketing arms have). Note to DLP vendors, it's really hard to sell the $7 million suite, but pretty easy to sell a $20K data discovery engagement (which could, of course, lead to that $7 million suite, or it could lead to a $50K/yr licensing deal for the tool). Most of my customers don't even want to hear about DLP because they don't see it as something for which they have budget.

Secondly, attack number three (TRICKY!), but use software to help validate what you learn by talking to people. Your business folks will not be 100% sure where their data is, or what data is on the systems they use. Talking to them will yield you an 80% picture (at best), so you need software to validate what they are saying. Free software like Spider from Cornell, or grep can be used to find sensitive data in your unstructured data space (like flat files). Trust your business folks, but VERIFY what they say.

While you are going through the verification process, see how your structured data is set up. This will be data that you find in databases all over your enterprise (yes, VSAM too). You will be amazed at what you can learn about your applications and your data by dumping schemas from every database WITH some sample random data out of each table. BE SURE to randomly select records from different operating times. Applications change; maybe the newest version of your application do not store social security numbers, but older versions may have. If someone did not go back and clean up the data after the upgrade, you've got a breach time-bomb on your hands.

Finally, if it applies, review your configuration management databases. Depending on your setup, this may or may not apply. If your applications rely on a configuration management database, you will absolutely need to address this.

Granted, finding out where your data lives will give you a massive amount of information. If you don't have a reasonably mature information security program in place already, you will be overwhelmed by the results of this exercise. As always, you and your organization will benefit greatly from a good security program, but if you don't have the funds for that, start by going on an electronic discovery and destruction initiative to effectively reduce the risk carried by the business.

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

I've been on a Dave Ramsey kick lately. I like his message and his concept of declaring war on debt. One of his mantras can save people TONS of cash if they would just use basic things they learned in school.

"Do the math!"

Everyone out there has a brother-in-law, church buddy, or friend of a friend who is "a finance guy." We tend to listen to people we consider experts without questioning their motives, simply because we don't believe we can comprehend the complexity of the question enough to figure the answer out ourselves.

For example, several years ago I went to a car dealership to buy my wife a new car. I had just recently graduated with my MBA, brought my Texas Instruments BAII Plus, and got ready to talk numbers ((Hey, that education should be good for SOMETHING, right?!?)). I left my wife at home and headed out with strict instructions on make, model, and of course COLOR. Negotiators at car dealerships want you to focus on the monthly payment instead of what you are paying for the vehicle (at least in my experience). When I got the first offer back, I did the math and learned while most auto loans at the time were going for 6%, this dealer wanted to put me into a 9.5% loan. I ran the numbers MANY times thinking that my MBA failed me.

It didn't.

Because I did the math, not only did I save money on the monthly, but I also cut the money I paid in interest over the life of the loan almost in half!

You know what? I dreaded doing the math, but once I did it, I found it was easy to do, and kicked myself for not doing it more often. By starting with the basic math going into a financial instrument like a car loan, I was able to make smart decisions about the purchase to save money and ensure that it did not have an adverse effect on my financial situation.

If Dave Ramsey were a security pundit, I think he would modify the phrase to say "Find the Data!" In fact, let's call that Baby Step #1. FIND THE DATA.

Information security is designed to protect information (or data). So how exactly can we protect it if we don't know where it is?

(Please pause for a moment to let the enormity of the question sink in....)

How many of you out there work for companies with extensive data maps? My guess is probably no-one does. There may be a few of you out there that do, but most companies just make assumptions about systems needing to be secure, but pay no attention to the data stored on said systems. Here's why that is important.

Groups have tried to attach a cost per record should that record be stolen and part of a data breach. The data backing up these numbers is so wildly varying that making any decisions based on the results are foolish. It is a nice benchmark that can at least legitimize the cost associated with a data breach. And, more importantly, it quickly points out that if you don't store the data, you don't need to secure the data!!

So if you really go "Find the Data," you will exit that tremend0usly difficult project with a good idea of how bad the situation is. I promise you, it is worse than you think. You will find data that will shock you into rapidly doing SOMETHING about the mess. That is a vital tipping point to the whole process. Now that you know what data you store, and where you store it, you can begin to securely destroy data you do not need, and evaluate options for the data you do.

For the data that you DO need (and really, ask the hard questions), you should fight to the death to protect it. Centralized data is easier to protect than distributed data, but there are options to protect both.

Going about finding data in your enterprise looks like a daunting, near impossible task. I would probably agree! But spending the time to REALLY find it out will pay off in spades when you let someone else get breached.

Posted by Branden Williams at 6:14 AM | Permalink | Comments (4)

Well, I was waiting to see if anyone would catch it, and unfortunately it looks like a couple of industries struggling with Visa's Payment Application Mandates are not going to get a reprieve.

Earlier this month, I posted about some new Visa Payment Application Mandates. What I didn't drop into the blog post was that Visa made sure this new mandate did not supersede their previous mandate, meaning that US and Canada merchants do not get a two year reprieve and that these are now GLOBAL mandates. Non US/Canada merchants now have a reason to get moving and deploy up to date payment applications!

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

Bob Carr was recently quoted in a Computerworld article saying that QSAs let [Heartland] down. Of course, he is not referring to his most RECENT QSA, but I'm sure that was an editorial change to make the story more interesting.

The article is a fantastic read, but also slightly humorous in nature. I'm going to leave Heartland's situation out of this post, and look at how other companies that have dealt with breaches. If you want to see what others are saying, check Rich Mogul, Mike Rothman, and Andy Willingham.

Nearly every company I have worked with suddenly "Gets Religion" after a breach. Prior to it, security is not top of mind, therefore things like PCI become burdensome as opposed to easy.

Security always becomes much more important after you've been bitten. It's a massive pendulum that swings WAY out on the over-reacting/knee-jerk edge, where before it was way out on the other edge of complacency and letting the risk ride. By the way, the blame for this lies securely on our shoulders--security professionals. We do not do a good enough job working with the business to help them understand real risks and costs of doing business, thus preventing something like this from happening.

Don't believe me? Here are some phrases I have NEVER HEARD come from one of my customers or prospects:

• Hey Brando, this price is OK, but can you double it and really dig beyond what is required by PCI DSS?


• I know this area over here is TECHNICALLY not in scope, but can you include it anyway so we can ensure we have good security controls there too?


• I need you to do a statistically valid sample with a higher error rate so I can do more validation on our IT processes.

• You don't need to look at any of these systems, they don't store CC data (which is technically a misconception because PCI applies to areas that also transmit or process data), so don't go into that room.


• Are you sure you have to perform that test? I only want the bare minimum.


• You have to pass me! My anniversary date is in two weeks and I cannot patch this two-month old vulnerability by then!


• Come on, two passwords is practically two-factor!


• Look at the real risk here! There's only 100K cards in plain text on this machine at any given time, that's not a big deal, right?

So here's the thing. Some QSAs WILL let you down. You get what you pay for, and some QSAs may not do a good job. The Q/A process from the Council is working to address this. But you are letting yourself down if you allow something like this to happen. If you realize that the assessment is not thorough, you should either work with the QSA to fix it or terminate the contract and find one that does have your best interests in mind.

______________________________________
¹ This is an important distinction. Companies that suffered breaches in the past sometimes become complacent and forget what they learned until the next one happens.

Posted by Branden Williams at 8:07 AM | Permalink | Comments (3)

FINALLY! An official statement from MasterCard! Last night, MasterCard posted a four page FAQ on their website to help us deal with the onslaught of buzz that came from their original posting. Some of it anecdotal and humorous (albeit literally true), some of it from this very blog.

Here's the meat of what you need to know:

• Level 1 merchants that engaged an internal audit team before 15 June 2009 must validate compliance with a QSA by December 31, 2010.
• Level 2 merchants must ALSO validate compliance with a QSA by December 31, 2010.
• Internal assessments MAY NOT be performed. The way that MasterCard words this, it appears to be a punt over to the Council. If the Council would offer QSA training and certify employees of non-QSA companies, MasterCard may alter their position.
• These deadlines do not alter a merchant's (or service provider's) annual anniversary date.
• Merchants must be compliant with PCI DSS upon boarding. Expect to provide a compliant ROC and AoC if this applies to you.
• Level 2 merchants that currently fill out SAQ-A MAY STILL validate their compliance this way! They DO NOT require an on-site assessment.
• Merchants not compliant with PCI DSS will need to let their Acquirer know where they are in relation to the council's Prioritized Approach document. I'm not sure what MasterCard will do with this information, but as we've discussed before, where you fall on the prioritized approach may not be representative of the actual risk you carry.
• Service provider changes don't seem any different from what Visa has already enacted for the CISP program.

• If I accept 1 JCB card (JCB only has 2 merchant levels), am I a Level 2 MasterCard merchant, thus require an on-site assessment even if I only accept 10,000 MasterCard transactions annually?
• Level reciprocity is also clouded with American Express's merchant levels... 50K transactions puts you at a Level 2.

Time will tell, but in order for MasterCard to avoid something like this in the future, they really need to communicate better to ALL of their stakeholders, not just their members. All it would have taken is a quick run of the new program by a few key outsiders to point out some of the issues that have been addressed above, thus re-framing the new requirements and avoiding this mess.

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

Don't worry, you don't need to tear up your existing compliance assessment. Troy Leach recently alerted the world, via press release, that PCI DSS version 1.2.1 is now the most recent version of PCI DSS, though he states, "As there are no changes to the intention or requirements of the DSS, your compliance programs will be unaffected by the change from DSS 1.2 to DSS 1.2.1."

This change is minor in nature, and does not constitute a new version per the PCI Lifecycle document released earlier this year. Most of the changes are typos or alterations in the document, some based on new policies or fees.

Let's walk through the changes.

Three documents were modified with this new version. For PCI DSS, the following four changes were made:

1. Page 5: Add sentence that was incorrectly deleted between PCI DSS v1.1 and v1.2.


2. Page 32: Correct "then" to "than" in testing procedures 6.3.7.a and 6.3.7.b.


3. Page 33: Remove grayed-out marking for "in place" and "not in place" columns in testing procedure 6.5.b.


4. Page 64: For Compensating Controls Worksheet - Completed Example, correct wording at top of page to say "Use this worksheet to define compensating controls for any requirement noted as 'in place' via compensating controls."

1. Page 9: In "To which Applications does PA-DSS Apply?" section, provide further clarity about what is considered a "payment application."


2. Pages 4 & 12: Add reference to the new PA-DSS Listing Summary, in "Related Publications" and "Release Agreement and Delivery of Report" sections. The PA-DSS Listing Summary is for PA-QSAs to submit with report, to specify report and listing information for PCI SSC to use. The form is not included in PA-DSS Program Guide but is available here.


3. Page 9: Add fraud-scoring or detection applications as examples of non-payment applications that may be part of a payment application suite.


4. Page 13: Clarify language in "Fees" section to eliminate previous "quarterly" wording, add annual maintenance fee of $500, clarify that grandfathered PABP applications will be charged a one-time fee of $1,250 (rather than an annual fee), add reference to Figure 4 for details about renewing expired applications, and add a $125 listing fee for minor updates.


5. Page 14: Add column to the table of figures, to refer to page numbers with additional Program Guide content related to each figure.


6. Pages 16, 21, 22, 37: Change terminology used previously for changes to listed payment applications to "minor update" in "Overview of PA-DSS Processes," Figure 2, and "Changes to Listed Payment Applications"; added terms "major update," "minor update," and "no update." Clarified process in "Minor Update - No Impact to PA-DSS Requirements." Changed title related to self-attestation form in Appendix C to "Self-Attestation for Minor Update."


7. Pages 17, 18, 23, 24, 35: Changed "Not acceptable for new deployments" to "Acceptable only for pre-existing" deployments."


8. Page 20: In "PA-DSS Report Acceptance Process Overview" section, changed "release agreement" to "vendor release agreement" to match language in "Legal Terms and Conditions" section.


9. Page 23: In "Renewing Expired Applications" section, added second sentence to Item 2.


10. Pages 24, 25: Clarify language in sections for "Payment Applications undergoing PABP Reviews During Transition" and "PA-DSS Transition Procedures." Deleted part of footnote that referred to PABP 1.4 and the October 15, 2008 date, since the date is past. Clarify that PCI SSC will not accept PABP Transition Procedures after September 30, 2009.


11. Page 28, 32: In "PA-DSS Reporting Processes" section and Appendix A, clarify process and change language used for contents of List of Validated Payment Applications to match language used in posted list. Expanded Appendix A to include tables with details about payment application types and the reference number.


12. Page 29: In section formerly called "Notification Following a Security Breach or Compromise," add "vulnerability" throughout--now the language is "security breach, compromise, or known vulnerability."


13. Page 31: Change language in "Legal Terms and Conditions" section to match that currently included in the PA-DSS Vendor Release Agreement.

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

As many of us in the industry had suspected, Visa has delayed its payment application security mandates two years to 2010 (newly boarded merchants) and 2012 (all merchants). The information was officially released on June 24, but I certainly did not see any public reference to it until recently. This is rumored to be largely in response to a low supply and high demand issue in the fuel industry.

So those of you that were dealing with unrealistic deadlines, you've got a reprieve! Keep pushing though, don't be one of those guys limping in at the eleventh hour!

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

Steven Fox, blogger for CSO Online and fellow columnist in the ISSA Journal, interviewed me for his Art of War Podcast where I discuss the parallels between Sun Tzu's teachings and PCI Compliance. Of the podcasts I've done, this one was particularly fun for me because I had to grab my Art of War book off the shelf and study up for it!

Sun Tzu's teachings apply to PCI and Information Security (it is a war, people) when you read his book in the light of an information security perspective. Go check out Steven's column in the Journal, his excellent podcast, and Sun Tzu's Art of War!

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

No, this is not one of those posts poo-pooing PCI because it is the popular thing to do. But after my marathon writing sessions working on the book, I started to think about all the customers that I had visited over the years, and all the problems I have seen, and how even today the problems that come up are essentially caused by common root issues.

BTW, I'm hoping you guys all LOVE the case studies. Some of you readers might even be business owners or playing a part in them! That was, by far, my favorite part of writing the book. Maybe I'll try some bad fiction writing next? (FAIL)

Anyway, one of the things that the information security rants about is how PCI should never be viewed as your total security program. PCI by itself is not good security. Many retailers, through no fault of their own, "know enough to be dangerous" with data mining and information management. They have digitized data about their customers, products, financials, marketing plans, inventory, and employees to help make them more efficient. Retailers have an amazing amount of data available right at their fingertips, and it helps them have (only) the right products in front of the right customers at the right time, increasing their ability to turn inventory.

With this much data flying around, not only do you need a way to manage it, but you need a way to secure it. Retailers traditionally ignored information security until PCI forced their hand. And I mean REALLY forced their hand. As in fines being assessed. Had Visa not fined merchants, PCI DSS compliance rates would have increased over the last two years, but not nearly as rapidly.

Why do you think that is? Is it because retailers never really viewed their data as super secret? Maybe they concentrated only on the Availability and Integrity of their data?

Regardless, now companies are having to deal with PCI, so they begrudgingly comply. Bare minimum. No additional expenses. Hire people to deal with PCI only, not really interested in security. Well, let me rephrase that. If you speak to the executives, they will tell you they are concerned about security, but their actions (and the actions of some employees) clearly state differently.

Companies that intensely focus on ANY compliance initiative are doing themselves harm in the long run. Compliance comes and goes, but you will always need to address security. In fact, you might argue that compliance initiatives like PCI or HITRUST all stem from data breaches caused by poor security. Complying with the bare minimum requirements from one initiative only leaves you vulnerable to new compliance initiatives that may cover related security issues outside the original scope.

PCI was meant to be a component of the overall security infrastructure, not THE ACTUAL security framework. In a mature security program, you would have controls defined and mapped back to compliance initiatives. This way you can save yourself a TON of time and energy by managing to your specific control set, not to each individual compliance initiative. Imagine the metrics you could pull from that!

PCI will damage your company if it becomes your security framework. Remember, it changes every two years. Theoretically, most of the changes are minor and in response to community feedback and compromise trends, but do you really want to be scraping the bottom of the barrel and doing a major overhaul every time PCI changes? Imagine spending tens (or hundreds) of thousands on a compensating control that barely passes PCI DSS, and then having to undo and redo the work the next year because of a change in PCI? It happens all the time.

How do you solve this problem? First, you have to find an executive in your company with the testicular fortitude to stand up for Information Security. Not only must this person be charismatic and full of gusto, he (or SHE of course) must understand why security is important, and be able to relate to other executives in a manner which they will understand as well. Security is a BUSINESS issue, and the business has to be on-board or you will have lost the race before the gates ever open.

Next you need to get back to basics and start with a wide-reaching enterprise security assessment. As far as frameworks go, I'm partial to ISO 27002, but choose one (or a hybrid) that makes sense for your business and environment. Figure out how you match up. Are you close? Do you just need to define lots of stuff? Or is it going to be a long, hard ride?

Finally, create your plan and work on getting there! It will require time, resources, probably some new hardware and/or software. Be sure to review industry BEST practice, and figure out how you can smartly better your posture without creating situations where users work around your new controls and you don't adversely impact the business. The business may need to change some of what it does, but you don't want to shut it down while in process. Focus on doing things RIGHT first, then look at where that puts your completion estimates. Depending on your level of maturity and size, a 2-3 year implementation plan may not be unreasonable. Going much beyond 5 years signifies some major barriers to completing the project, and a 1 year deadline either means you had most of it right, are a small and nimble company, or you grossly underestimated your timelines.

Remember folks, spend for security, not compliance. And definitely don't implement a compliance target as your main security framework. That's how PCI can ruin you.

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

OK folks, bring on the love. Ready? I'm going to stick my neck way out there.

PCI is easy.

*GASP*

OK, taking a company that ignored security (or only focused on one particular element of a good security program) to compliance is hard, painful, and will result in lots of kicking and screaming and other tantrum like actions. Why? See this post.

But take PCI DSS on the surface. It's prescriptive (potentially overly so in some cases), it is based on a good, common set of security practices that, quite frankly, you should already be doing, and its impact to your organization can be limited dramatically depending on how you approach it. If you look at the high level twelve requirements for PCI, all of them map into ISO27002 standards. Want to know what an assessor will ask you, or exactly what you have to do to comply with a particular requirement? Read the testing procedure! It's right there!

One of the issues customers and industry folks have with PCI is they will pick one particular area of PCI and latch on to it as a problem. "I can't do PCI because of X," or "Y is TOTALLY insecure.... if I do Z, I am more secure but not compliant?"

Sometimes these conversations come from people who simply do not want to go through the effort of PCI DSS and are trying to delay taking any action to resolve a gap. Maybe they think if they delay it long enough, they will be promoted out of the job, and it will be someone else's problem. I once had a (former) customer tell me he could not wait to be done with PCI so he could get back to security. What this gentleman didn't know is that PCI was the only thing delaying him being pwned because his security was so poor.

I think if the folks screaming about PCI would stop for just a second and take a look at the item for which they scream (ain't ending in no preposition here, baby! YEAH!), they would realize that (in most cases) good security practice tells them to do the same thing! If we are truly security professionals, or if we care about security at all, shouldn't we focus on improving security in our companies? The answer is Yes, and if the method by which we motivate our companies is the stick of PCI, why not use it?

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

On Monday, I told you all about a MasterCard fine schedule but I was unsure on when it was going to start. Well, as it turns out Level 2 and 3 merchants are being fined NOW, not sometime after the December 2010 date.

That's right, some Level 2 merchants have already received their first $25K fine from MasterCard under their new fine program. Apparently, that's how many of the acquirer's found out about the program!

Posted by Branden Williams at 4:43 AM | Permalink | Comments (2)

OK, SOMEONE out there has some explaining to do. Like, right now. Who poked MasterCard hard enough to wake them from hibernation?

When it comes to actions against merchants, MasterCard has typically been much quieter than Visa. We've had several customers come to us with new fines from MasterCard that will begin sometime in the next 18-21 monthsNOW.

Why the ambiguity? None of our customers seem to have a date when the fines start! This is a huge assumption here, but I will suggest that the fines would start after the 2010 deadlines for Level 1 & 2 merchants.

Revisiting those deadlines, Level 1 & 2 merchants must produce a Report on Compliance from a QSA by December 31, 2010. Non-compliant Level 1 & 2 Visa merchants are currently being fined under the Visa Compliance Acceleration Program (CAP) as follows:

• Level 1 Merchant: $25K/mo ($300K/yr) plus tiered merchants bumping down one tier (total $$$ unknown)


• Level 2 Merchant: $5K/mo ($60K/yr)

Level 1 & 2 merchants will be treated the same. We already know they are the same from the new reporting and validation requirements, but they will also be the same from a fine perspective! Level 3 merchants, currently NOT fined by Visa, will also be subject to fines (though in a much smaller amount than Levels 1&2). My understanding (though their appears to be some question about this) is that these fines are assessed quarterly until compliant¹.

• Level 1 & 2: $25K, $50K, $100K, $200K ($375K/yr)


• Level 3: $10K, $20K, $40K, $80K ($150K/yr)

MasterCard rolled out another change to acquirers as well, and require newly boarded Level 1 & 2 merchants to provide a compliant ROC from a QSA before they are allowed into the network. So those Level 2 merchants that have been changing processors every year, it finally caught up to ya!

None of this information is published on the MasterCard SDP website, nor was I able to get this information directly from MasterCard, so your best bet is to contact your acquiring bank to understand how this new policy from MasterCard will affect your business.

_________________________________
¹ OK smart guy, I know what you are thinking. What happens in Quarter 5?!? Again, this seems a bit unclear but it appears that the fines reset to the lowest amount and continue their normal escalating procedure.

Posted by Branden Williams at 5:19 AM | Permalink | Comments (2)

Why is Requirement 11.2 one of the most failed by merchants and service providers alike?

Requirement 11.2 has shown up here a few times, but after looking back, I never really explored the issues in detail. Those who have been unfortunate enough to attend one of my sessions where this topic came up know where you can make a mistake.

Requirement 11.2 mandates quarterly scans for all hosts in scope for PCI, both internal and external. Scope reduction techniques like segmentation can do wonders for limiting what needs to be scanned, but makes the biggest impact internally. In one of my case studies, I talk about a customer that reduced the number of in-scope systems to less than 1% of their infrastructure thanks to good network segmentation. From a risk & compliance perspective, that alone pays for any added cost associated with new equipment and maintenance.

So what's the big deal? I mean, seriously, how freaking hard is it to scan a few systems? Isn't that how security became mainstream in the first place? Vulnerability scanning? ((Tongue in cheek of course!))

The fact is, of all of the requirements in PCI, 11.2 is one that companies struggle with more than they care to admit. In more than half of the PCI assessments we did in 2008, Requirement 11.2 came up as an initial gap. If it's just scanning, why can't we get it right?

Two reasons.

Reason the First: You scanned, but you forgot to obtain CLEAN scans for every quarter. Remember, the testing procedure for Requirement 11.2 states that QSAs must "Verify that the scan process includes rescans until passing results are obtained." Just scanning is not enough, you have to scan, patch, and re-scan until you have a clean scan ((How many times shall we put "scan" into a sentence?)). Most companies do well on their external scans; it's the internal ones that trip them up. The reasoning on why this occurs is usually something like, "Well, the firewall blocks that type of connection, so you can't exploit it from the outside anyway."

Sorry chief, that doesn't cut it.

The hardest part for companies to deal with is managing the vulnerability lifecycle. Companies must play all four parts of the vulnerability management quartet: Discover, Patch, Retest, and Close. Companies tripped up by this requirement typically stop at the first or second part, leaving the rest unplayed. Try listening to a song you know well, but instead of all of the instruments, imagine what it would sound like if played by only two instruments instead of four.

Vulnerability Management is exactly that, a management process that must oversee the tactical steps required to comply with 11.2.

A QSA will require four quarters of CLEAN scans!

Reason the Second: You scanned externally, but forgot to scan INTERNALLY. Yep, strange as it is, this is actually as common as Reason the First. Back in 2004 when I first started doing CISP assessments, companies faced with complying with the monthly scan requirement (at the time, Requirement 10.2) always found some geeky tech guy from their version of the Pit of Despair to do this work. As a testament to how far information security has come in retail, guys like that are not relevant anymore. That guy has gone on to earn an MBA and maybe is a manager or director now, or maybe he just left retail and went to a company more suited to his skillset. Regardless, that guy left a gap that remains unfilled.

Expanding on the management problem described above, internal scans suffer the most. Countless companies I have worked with put internal vulnerability management on the back burner and only focus on external security threats. Remember the Armadillo Network Model? Hard crunchy exterior, soft chewy middle? Works great if you have no insider threat, and there is no chance someone might accidentally open up a vulnerable service through a mis-managed firewall change.

A QSA will require both internal AND external scans!

Don't let your next PCI Review become a PCI COMPLIANCE FAIL because this critical periodic maintenance requirement was overlooked.

Posted by Branden Williams at 6:00 AM | Permalink | Comments (2)

Please join me on July 7 for an informative webcast on Maintaining PCI Compliance! To register or attend, please go to: http://www.brighttalk.com/webcasts/4431/attend.

Now that Level I merchants have undergone a few annual Payment Card Industry (PCI) assessments (and Level 2 merchants are soon to be doing the same), they are addressing the realization that a mature, sustainable compliance program requires more than once-a-year rallying to prepare for, participate in, and pass an assessment. Daily operational focus and ongoing effort are vital to protect investments in compliance, manage risk, and minimize the business disruptions and costs associated with achieving and demonstrating compliance year after year. This presentation discusses best practices for building a compliance program that can be supported and maintained year-round while also alleviating the burden on IT staff. When implemented effectively, the practices can help your company mitigate risk, reduce costs, and boost confidence in compliance by developing a cohesive plan for ongoing PCI assessment, maintenance, and refinement.

Posted by Branden Williams at 12:43 PM | Permalink | Comments (0)

The Merchant Maven posted a release about Merchant Warehouse's new Blackberry version of MerchantWARE, following in the footsteps of the apparently successful iPhone application. This new trend is yet another example of a need for good moble payment security.

While the software company states that the application complies with both PCI DSS and PABP, it is not listed on the official Validated Payment Application list as either validated under PABP or PA-DSS. That only means that they have not had an assessment performed and paid the required fees to get it listed on the site.

Acquirers are wary of Point of Sale (POS) vendors and POS implementers, all because of a few bad apples. The restaurateur is at a particular disadvantage. A high failure rate and a desire to carry a small amount of debt when opening a restaurant (see high failure rate) causes some of the same equipment to be used in multiple locations throughout its usable lifespan. Not just tables, chairs, and griddles, but POS terminals as well. This means that some of the same vulnerable equipment keeps surfacing because proprietors simply don't know they need to upgrade.

The card brands, specifically Visa, have invested heavily to fix this. First, by starting the Payment Applicaiton Best Practices program (now the Payment Application Data Security Standard), and later by imposing certain payment application mandates on new (and soon to be existing) merchants.

Merchant education is getting better, but you will do yourself a favor by ensuring that any third party POS applications you rely on for your business are listed on the Validated PA-DSS applications, and be sure that you keep up with the patches associated with that version.

Posted by Branden Williams at 6:01 AM | Permalink | Comments (2)

It's been a little over a week now since MasterCard tool the PCI world by surprise and changed their reporting requirements for Level 2 merchants. Whether you are currently a Level 1 or Level 2 merchant, these changes affect you. Here's the summary and rundown.

MasterCard posted a change to their Site Data Protection program that requires Level 2 merchants to use a QSA and perform an on-site assessment before December 31, 2010. In addition, Level 1 merchants that were previously self-assessing may not self assess anymore, and must use a QSA for their PCI Assessments. This is a dramatic change from the current, industry wide requirement of self-assessing for merchants processing less than six million transactions annually, and allowing merchants that process more than six million transactions annually self assess if they choose.

So far, none of the other card brands have changed their status; however, if you have a business unit defined as a Level 2 merchant with any card brand, you are automatically a Level 2 with MasterCard and are now required to have an on-site assessment. Below are a few clarifying points around the change to the levels from an inside source.

1. Level 1 and 2 merchants MAY NOT self assess anymore. They must use the services of a QSA to complete their assessment (still awaiting final confirmation on this).


2. Level 2 merchants must be validated by a QSA prior to December 31, 2010, as well as maintain their current processof submitting a Self Assessment Questionnaire (SAQ). MasterCard's intent is to use the next eighteen months as a transition period (VeriSign can provide both deliverables for you at the same time).
   With this short timeline, VeriSign (and MasterCard) recommends that Level 2 merchants have readiness assessments performed immediately to prepare them for any remediation required to be completed before the on-site assessment in 2010.


3. The on-site assessment must yield a Report on Compliance (ROC), NOT an SAQ. Effectively, Level 1 & 2 merchants will have the exact same reporting requirements for PCI.


4. This does not only apply to merchants processing more than one million MasterCard transactions annually; this applies to any merchant classified as a Level 2 merchant from any other card brand. MasterCard defines that their Level 2 also includes "Any merchant meeting the Level 2 criteria of a competing payment brand." This means that if any other brand defines you as a Level 2 merchant, you are now subject to this requirement. For example, did you know that according to these rules anyone processing more than 50,000 American Express Card transactions per year is now subject to this requirement?

Parts of this may not be as relevant to some Level 1 merchants, after Visa clarified their expectations of what makes up a Level 1 merchant earlier this year. If you are a Level 1 merchant in one country or region, and are also a merchant of a lesser level elsewhere in the world but share data with (or are connected to) the Level 1 merchant operations, all operations should be treated as a Level 1 and reported that way.

For example, Garrett's Gas Guzzling Garage operates 800 car repair locations across the United States. Garrett's recently opened twenty locations in Mexico City to help maintain and upgrade the fuel efficiency of older cars with a patented fuel particalizer. Even though the twenty Mexico locations process through Bancomer locally, the data is shared with the US Headquarters for settlement, reconciliation, and analysis. According to Visa's rules, the Mexican entity is considered a Level 1 based on its relationship with the parent, and a Level 1 assessment must be performed.

When in doubt, always ask your acquirer(s) what is expected of you. Some acquiring institutions may still treat certain subsidiaries as lower levels depending on the circumstances.

Regardless, your PCI Team is ready to assist you with any new PCI needs that you may have! Click here to email us to get in touch with one of our seasoned QSA consultants!

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

Don't write Savvis off yet! Dave Navetta posted an update to the Merrick v. Savvis case that every QSA is closely watching. Savvis filed a motion to dismiss in response to the lawsuit.

I'm not a lawyer, but I'm glad David is. He explains the reasoning, and even mentions that Merrick's potential procedural error (or end-around) could get this case dismissed before the substantive merits of the case can be explored, thus continuing to leave the world in the dark about more potential liabilities involved with performing PCI Assessments.

Go check it out!

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

Javelin Strategy & Research posted an update to the new MasterCard Requirements. After speaking with John Verdeschi, Robert Vamosi pointed out an error in our initial analysis. After re-reading my material, I looked at one piece of information and made a leap (incorrectly) about the intent.

John clarified that the intent is to use the next eighteen months as a transition period. Level 2 merchants should both submit a SAQ, and also have an On-Site assessment completed so they can submit a Report on Compliance by December 31, 2010.

This means that Level 2 Merchants effectively have eighteen months to complete a readiness assessment, remediate, and validate compliance.

Sorry for the confusion folks, and thank you to Robert & John for setting us straight!

VeriSign is sending a consolidated information briefing on this update with some special discounts on our consulting services for Level 2 Merchants. If you don't get your copy of this alert by Friday, please email me so that you have the information needed to get the discount!

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

You've probably heard about it by now. Thanks to a friend doing business in Nevada, I was alerted to this new law last week. Nevada is now the second state to enact laws requiring companies to comply with PCI (though, arguably, the Massachusetts Identity Theft Prevention Regulations seemed to have been lifted at a high level from PCI), the first being Minnesota.

David Navetta has a great analysis from a legal perspective, and Chris Mark published his thoughts as well. One thing that is interesting about the Nevada law is an apparent Safe Harbor provision.

Will this added pressure force more religious views on payment security and compliance inside companies? Or will companies continue to roll the dice with their compliance?

You decide!

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

A couple of weeks ago, I jotted down a few thoughts on the letter from the NRF to the PCI-SSC about the PCI Standards. My post was a bit rant-ish, but Anton Chuvakin threw down a great review in his blog yesterday.

The only point that I wanted to add a different opinion on is the use of WEP.

I've been a proponent for wide open wireless networks in corporations for a few years. I argue that because network compromises are either hit-or-miss with advanced encryption technologies, most hackers default to attacking hosts instead. One of our own testers is known to breach networks that security professionals thought were virtually impenetrable. He didn't do it by packing a Cray into his car. He just set up a louder, fake access point that caused a laptop to associate with him, then launched an attack against that laptop.

Instead of trying to protect the network, why not assume that wireless networks are the equivalent of a user operating from home, and make that user interface with it in that manner? Sure, you can cut down on the noise by doing some basic filtering of MAC addresses, or even a basic WEP key. But inside that setup, run VPNs with firewalls on the endpoints (BOTH sides) to connect the machine to the network. Treat a user sitting in your office using wireless as a remote user, and treat your wireless network the same way you would the internet.

From a handheld device perspective (like the ones often found in retail), things get complicated. Almost to the point that it is virtually impossible to continue their use without upgrading them to WPA/WPA2. Add to that the key management issue that can arise when faced with a pre-shared key (which most of those devices have).

Fundamentally, weak wireless security will be compromised. ASSUME it is compromised. Then build your controls around that hostile intermediary. You have already done it at least once, just duplicate it here. Where have you done it? Probably at least two places. 1) Remote access as I mentioned above, and 2) your external website. In both cases, you assume the internet is compromised (oh my stars, is it ever!), and build your security around that assumption.

Posted by Branden Williams at 6:03 AM | Permalink | Comments (2)

On Wednesday, we discussed MasterCard's new requirement for Level 2 merchants to have an on-site assessment performed instead of submitting the Self-Assessment Questionnaire. This news prompted a flurry of information around the new requirement and has merchants asking lots of questions.

I clarified a couple of items from my last post and wanted to make sure they were clear.

1. MasterCard's 2010 deadline is more of an end to submitting SAQs as opposed to a deadline to be validated by a QSA. This means that Level 2 merchants will continue to be able to submit SAQs until December 31, 2010, after which they will need to have the on-site assessment, performed by a QSA.


2. The On-Site assessment must yield a Report on Compliance (ROC), NOT a SAQ. Effectively, Level 1 & 2 merchants will have the exact same reporting requirements for PCI.


3. This does not apply only to merchants processing more than 1 million MasterCard transactions annually, this applies to any merchant classified as a Level 2 merchant from any other card brand. MasterCard defines that their Level 2 also includes "Any merchant meeting the Level 2 criteria of a competing payment brand." This means that if any other brand defines you as a Level 2 merchant, you are now subject to this requirement.

Posted by Branden Williams at 6:43 AM | Permalink | Comments (3)

Thanks to Smiley for the tip!

MasterCard has posted a change to their Site Data Protection program that requires Level 2 merchants to use a QSA and an on-site assessment. This is a dramatic change from the current, industry wide requirement of self-assessing for merchants processing less than six million transactions annually.

While this is definitely going to put a dent in Level 2 merchant budgets from this point on, I truly believe that this is a smart move by MasterCard. Level 2 merchants are extremely significant in size, many of which being household names. Unfortunately, PCI self-assessments are typically poorly handled simply due to the complexity of the standard and lack of training provided to those individuals performing the assessment. When our folks are contracted to review these, we typically find that a previously fully in-place Self Assessment Questionnaire is only about 70% accurate. Meaning, that 30% of the items answered "Yes" or "N/A" are actually "No."

So far, none of the other card brands have changed their status.

It's unclear if others will follow suit, but regardless, if you are defined as a Level 2 merchant with ANY card brand, you are automatically a Level 2 with MasterCard, and are now required to have an on-site assessment.

Posted by Branden Williams at 10:13 AM | Permalink | Comments (5)

I hate to be a cynic.

OK, fine. SOMETIMES I get secret enjoyment out of being a cynic. Kind of like the enjoyment of making fun of someone in a way that they don't know they are being made fun of. Or that satisfaction of eating candy from your kid's Halloween stash knowing they will never miss it (unless your kid is Ms. KJ... you know who you are, you little Halloween candy auditor you...).

The NRF and others "ganged up" on PCI yesterday by sending a letter demanding easier treatment under the standard. I understand the intent, and applaud them for sending the letter across. While there may be a valid point or two buried in there, I think this is a sad day for Merchants.

I have said many times before, PCI is NOT the scariest thing out there. Savvy merchants have figured out how to win within the rules as opposed to digging their heels in like my 4 year old son when it's time to go inside, running down the sidewalk screaming NOOOOOOOOOOOOOOO. Savvy merchants know that these rules, while a little bit broad reaching, can help them solve OTHER security issues, and help their company realize that security is much more than dealing with fraud & shrink.

These merchant associations only represent a vocal minority among their constituency. Most merchants I deal with really want to get security right, and have conceded that if it has to start with PCI, then that's where it has to start. There are those few that fight you tooth and nail on every single requirement, pushing for a ruling that gets them the easiest pass with the fewest amount of dollars spent. Unfortunately for QSAs, they are also the most likely to be breached, and the ones that will turn on you in an instant, throwing you under the bus.

As another industry expert said (I can't remember who to attribute it to), "It's a scary time to be a QSA!"

Luckily for our customers, we take a partnership approach versus an audit approach. Our customers love the collaborative process that our assessment takes, and understand the value and cost of information security.

If you are a member of these associations and are unhappy with the direction they are taking, I urge you to speak out! Breaches involving PII are much more costly and dangerous to the longevity of the business, and without PCI to raise the general information security flag, your business is next!

Posted by Branden Williams at 7:30 AM | Permalink | Comments (0)

The following is a guest post by David Navetta.

Before starting, I would like to thank Branden and VeriSign for allowing me to guest post on this blog. I think it is very important to foster dialogue between security professionals and attorneys as our worlds are colliding on an increasingly faster pace. At the same time both sides tend to speak different languages and have different concerns, even though we share a goal: reducing risk for the organizations we work for. As those concerns overlap both communities need to be able to translate each others' issues into a language that the other side can understand and act upon. Hopefully this blog post is helpful in that regard. One more item, if you want to read more blog information security and privacy law blog posts, please check out my blog: www.infoseccompliance.com Thanks.

As an attorney focusing on information security and privacy issues, I often get called in to assist companies to understand their legal liability risk around the PCI (self) regulatory system. One of the key areas I get involved in is service provider relationships, and in particular section 12.8 of PCI and service provider contracts. There are many aspects of 12.8 (and its subsections) that are potentially ambiguous and open to interpretation, but this particular article is not going to focus on those. This post concerns the "written agreement" referenced in 12.8.2, which provides in full:

12.8.2. Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess.

We could debate whether a "written agreement" is the same of as a "contract" as referenced in version PCI v. 1.1 (under the law there is not much difference between a "contract" and an "agreement"). However, rather than concentrating on mere PCI technical compliance, this blog post will discuss the contract terms merchants should consider in their service provider agreements to actually manage their security risk. Of course service provider agreements should address the PCI requirements, but for merchants concerned about truly mitigating their risk, much more is involved. Coincidentally, I am in the middle of writing a book on payment card contracting that will be released through the American Bar Association, this post summarizes some of the ideas/concepts that will be in that book.

Pre-Contracting Activities

In general, as most understand, organizations cannot "outsource" compliance with PCI. That is to say, while merchants work with service providers that do some or all of the merchant's storing, processing or transmission of cardholder data, interested parties will still attempt to hold the merchant responsible for the service provider's non-compliance with PCI, and the impact of a service provider's payment card security breaches. The service provider contract is one of the key places where this risk can and must be dealt with (the other mechanism for managing service provider risk is insurance, but that is another topic for another day).

The first step in the process is understanding what the merchant has legally obligated itself to. This requires an analysis of the merchant's "upstream" contracts: the various "merchant agreements" it has in place with payment processors and/or merchant banks. If a merchant deals with more than one card brand there could be multiple contracts. In essence, the goal here is to identify the merchant's upstream obligations and transfer those obligations down to any service providers utilized by the merchant. For example, if the merchant agreement requires the merchant to indemnify the payment processor for fines and penalties imposed by card brands, the service provider agreement should require the service provider to do the same. One thing to note. Most modern merchant agreements require merchants to adhere to the relevant payment card brands' operating regulations. As such, merchants should understand those obligations (e.g. Visa's Account Data Compromise Recovery process) as well in order to transfer risk to their service providers.

The second step is attempting to understand the risk posed by the particular service provider the merchant is dealing with. What is the transaction volume the service provider is handling? What controls does the service provider have in place or not have in place? Has the service provider's security been independently assessed (e.g. by a QSA)? What would happen to the merchant's business if the service provider went down (e.g. not all the risk is liability risk)? If the service provider suffers a breach, does it have an incident response plan to mitigate harm and provide notice to the merchant? In addition to general security requirements, depending on the nature of the transaction, this risk assessment may result in specific service provider contractual obligations.

Security Contract Terms

So what security-related terms should be in service provider contracts? This answer to this question will vary depending on many factors (e.g. the type/purpose of the transaction, the data at issue, the laws that apply, the upstream contractual obligations of the merchant, etc.), but the following should be considered:

(1) Definitions. The payment card world relies on particular definitions and terminology. To avoid confusion, where warranted, some definitions should be incorporated into the contract (e.g. PAN, sensitive authentication information, etc.). This can be achieved in part for some key terms by referencing the PCI standard and/or the PCI glossary.

(2) "Preventative" Contract Terms -- Compliance and Controls. The overall purpose of these terms is to contractually obligate the service provider to certain controls and practices with the hope of preventing non-compliance and/or a security breach (or at least to decrease the risk of those events). In these sections the service provider should be required to comply with the requirements of the PCI regulatory system. This includes, but goes beyond, the PCI standard itself. Other elements of the PCI regulatory system include card brand security programs, FAQs, Guidance papers and other documents issued by the PCI Council, and the card brand operating regulations themselves.

In addition, if there any specific controls or security measures that the merchant wants the service provider to implement and maintain, that should be indicated. Merchants can also draft other standards into the contact, such as ISO 27001, if desired. Last, regardless of the specifics, the service provider should have an obligation to maintain "reasonable security" to protect the sensitive data that is the subject of the agreement. By broadening the duty to "reasonable security" the hope is to avoid cases where technical compliance with PCI was achieved, but the service provider's systems were not actually secure. The reference to "reasonable" establishes an "objective" standard under the law that allows for scrutiny in a litigation context. Note that all duties in this section should be made ongoing and continuous (none of this PCI compliance only matters on the day the contract is signed), and the service provider should be required to comply with changes to the PCI Standard.

(3) Monitoring and Reporting. These contract terms should provide the merchant with the right to monitor and enforce compliance with the service provider agreement, the PCI standard, payment card company security programs, etc. There are many ways this can be achieved, including imposing reporting requirements on the service provider, providing the merchant with security assessment rights or actually requiring a periodic third party audit. With respect to PCI, the agreement should require the service provider to allow the merchant (or third parties selected by the merchant) to conduct quarterly network scans, as well as QSA assessments.

What are the consequences of non-compliance with the agreement or PCI? Monitoring is good, but if non-compliance is found the merchant must also have enforcement rights. Without enforcement mechanisms the service provider's promises may be hallow. Contractual penalties may be put into the contract, indemnification rights (discussed below), termination rights and other remedies may be considered. The key here is to have some leverage to get the service provider to actually comply instead of having to abandon the relationship and find a new service provider. .

(4) Security Incident Response. Service providers and outsourcers act as an extension of the merchant's operations. However, if their incident response procedures are out of sync it could be problematic. Merchants need to understand their service provider's internal incident response procedure and then build contractual obligations that allow the merchant's incident response procedure to seamlessly meld with the service provider's. This section may require service provider to identify a response coordinator to act as a liaison and cooperate fully with the merchant. In addition, it may require an investigation, remedial action, notice and reporting to the merchant and payment card network, collection of evidence, documenting incident response and access to service provider systems, logs and data.

One of the key considerations here is identifying the party responsible for complying with breach notice laws. Arguably, based on the statutes themselves, the primary duty would rest with the merchant, and the merchant would have to pass it on contractually to the service provider (note the primary duty would still reside with the merchant, so if the service provider refused, the statutes still require the merchant to comply).

(5) Rights, Remedies & Indemnification. These terms transfers risk of loss between the merchant and service provider and provide other rights for breach of the service agreement or in the event the service provider suffers a security breach. These terms are amongst the most important in the agreement, and are also the most contentious to negotiate. However, they are also the most important and truly establish the baseline for the merchant's liability in the event the service provider makes a mistake. The following should be considered.

Indemnification rights should require the service provider to pay for/reimburse the merchant for claims, attorney fees, lawsuits, fines, penalties and other costs associated with the service provider's non-compliance with the agreement and other requirements of the PCI regulatory system, as well as security breaches (whether compliant or not). If there is a limitation of liability clause, exceptions should be considered for security breaches, fines and penalties due to non-compliance and other issues. The same holds true for any consequential damages limitation clause that finds its way into the contract. Additionally, termination rights should be built into the contract based on service provider non-compliance or security breaches.

(6) Insurance Clause. An insurance clause requiring the service provide to purchase insurance covering security breach notice law compliance, liability arising out of security breaches and other professional errors or omissions should be considered (especially when utilizing smaller vendors). If possible, the merchant should be named as an additional insured on the policy so that it can tap directly into the policy proceeds. This clause should specify required limits and should require the insurance to be primary. In addition, the contract should note that insurance proceeds are not intended to limit the amount of the service provider's liability.

To implement these terms, what I often do is create a security schedule or exhibit that contains all/most of the security-related obligations of the contract. Oftentimes a merchant will be forced to work with the service provider's contract. If the security terms are in a pre-established exhibit, that exhibit can be incorporated into the contract (with some careful drafting of course). On a final note, please understand that while this post has focused on PCI, a framework similar to that described above could be used for other statutory or security requirements, including GLB, HIPAA, EU Data Protection Directive and others. In fact, for organizations with multiple security standards or laws to comply with, a security exhibit or schedule can be an efficient way for addressing all of the requirements at one time and in one place.

Conclusion

At this point in time when reliance on service providers and outsourcers to handle payment card information is high, while the legal liability risk associated with payment card security breaches is significantly growing, the security terms in a service provider contract have increasing importance.

In fact, I counsel my clients to raise some of the terms they want (especially indemnification) at the RFP phase instead of waiting until later. The key here is to create competition between potential service providers not only on price and scope of services, but also acceptance of risk and contract terms (those willing to accept more risk being potentially better candidates than those not so willing). Organizations that wait to request protective contract terms until after they have selected a vendor may find those terms watered down during negotiations, and may be stuck holding all the risk of a service provider mistake (and you know that for most service providers the default is contract terms that completely insulate them from risk - don't settle for that!). As it currently stands the focus of risk mitigation with respect to security are technical controls and other security measures, and the importance of the contract as a risk mitigating tool is overlooked. As litigation increases in this area, for risk-conscious organization, the protections (or lack of protections) in the service provider contracts are going to become very important.

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

Last week was interesting. First Dave Navetta published the court filing for Merrick Bank v. Savvis, originally filed in May of 2008. Dave points out that although the court filing is a year old, news agencies are just now reporting on it.

Chris Mark elaborated on the topic a short time later in The Aegenis Group blog. There are many valid points in Chris's explanation including the differences from the Cardholder Information Security Protection standard from Visa and the PCI DSS we have today, and how there were no QSAs or training at the point the assessment was going on. I started working on CISP in 2004 and was alarmed at some of the poor quality of work that I experienced early on.

My favorite point, however, is one that I love to poke at lawyers for. The second half of the article goes into an explanation of how QSAs are sued under the reasonableness standard. This one cracks me up.

Cracked-Up Brando says, "Dude, what you think is reasonable and what I think is reasonable may be two different things. Go ahead buddy, throw it in the contract. It's a meaningless word that I am confident I could maneuver around." Of course, Cracked-Up Brando sometimes needs to be reeled back in, but I've said those very words recently to an attorney.

Of course, the Yin to Cracked-Up Brando's Yang, Confused Brando says, "Wait, so you mean that now a customer can fight me tooth and nail on every single gap that I find, and then come back to sue me because I didn't point out OTHER gaps that may not be relevant to PCI?" Chris points out, "even if the CISP (PCI DSS) or any other standard says a QSA does not have to do something, as a security professional, they should, as a reasonable person, conduct themselves in a manner that any reasonable person would."

Hrm, how about a little more variance among the QSA community?!

Finally, the part that everyone hates to hear but cannot avoid, "This is going to continue to increase the costs of compliance for all companies and will continue to pose challenges for the industry."

Things are a little different today with QSAs and the PCI Security Standards Council, but not by too much.

Edit: See Martin McKeay's post that has some good reference articles as well.

Posted by Branden Williams at 6:07 AM | Permalink | Comments (1)

The QSA community at large received the May edition of the assessor update from the council on Friday. In it, Troy Leach is giving us hints on which requirements assessors are messing up the most. Keep in mind, he is speaking about this from the Quality Assurance process, and not from watching assessors conduct assessments. The reason I make this distinction is that your assessor COULD be evaluating the criteria mentioned and not documenting it properly in the ROC.

Here ya go, here's the top 8 (from the May 2009 Assessor Update) copied right from the update.

• Requirement 2.2.4 - "For a sample of components...", often there is no sampling defined or components listed
• Requirement 3.2 - Few if any of the bulleted items in subrequirements of system components are addressed
• Requirement 4.1.a - The 4-7 bullets of evidence are often neglected
• Requirement 5.2 - Automatic updates and periodic scans of the anti-virus solutions are not addressed
• Requirement 6.3.6 - The requirement to demonstrate custom accounts are removed before system is released is often not documented
• Requirement 11.2.a - QSA only documents the external ASV scan and internal scans are not addressed
• Requirement 11.3 - There is seldom documentation that the process of penetration test is in place.
• Requirement 11.4.b - There is seldom documentation that the QSA reviewed the IDS/IPS to verify the solution alerts personnel of suspected compromises

While some of these seem to expand beyond the scope of what the requirement is asking for (such as 11.3, unless I misunderstand what he is saying), but some of these are blaring examples of the gloss-over effect that an assessor might fall victim to if they do not do a thorough assessment. Of course all companies have A/V, right?

Posted by Branden Williams at 5:38 AM | Permalink | Comments (2)

CIO Australia recently posted an article suggesting that data breach notification laws drive compliance. Bob Russo is quoted quite a bit in the article, but there is a part that is missing. It's not Bob's fault, he is speaking from the Council's perspective. He hit the bullseye.

But what Bob does not say is what is really driving compliance.

I've been doing PCI/CISP compliance work since 2004, not quite two years AFTER the September 26, 2002 filing of California's SB 1386--the first State Data Breach Law. Unfortunately, many companies did not pay too much attention to it until several years later when other states started passing similar laws, especially when Minnesota passed the Plastic Card Security Act in 2007. Being in the trenches dealing with companies, I can definitely say that before 2007, the feeling in the PCI world was "We'll get to it... if we ever do." By 2007, I had a list of clients that had failed their annual assessment three or more years in a row, with little to no improvement year over year¹.

During 2007, however, we saw a dramatic uptick in the reported compliance rates of Merchants² of all levels. Let's think back to 2007. Is it data breach laws that caused this uptick? It could have, but that's a significant 4 year delay (allowing for some variance).

What else happened in 2007?

Visa announced their Compliance Acceleration Program! Remember that? The original plan was that fines would start if compliance was not reported by September 30, 2007. Visa later offered a three month rebate if compliance was met by December 31, 2007. Not to mention, if you were subject to Tiered Interchange, you did not qualify for the best available tier!

Holy crap, talk about lighting a fire!

One of our customers figured out that their cost of non-compliance was $40 million in lost rebates! WOW! That's a motivator if I've ever heard of one--especially if your compliance costs are under $80 million over 2 years! Presumably, your maintenance costs should be SIGNIFICANTLY lower (especially if you purchased VeriSign's PCI Program Management offering!). Shameful plug?

If anything has pushed compliance, fines (or a real threat of) seem to be the main motivating factor, not laws.

Now, one difference between the US and the rest of the world that could make a difference is that here in the US we are inundated by breach notices. For credit card breaches, the damage is pretty minimal (more than credit card such as SSN is definitely a MUCH bigger problem), and I think most of us ignore it and continue shopping. After spending a few days in the UK, there are some groups that believe required notification upon a breach will be a massive motivator, until THEIR citizens are inundated and then don't care anymore.

The moral of this post? My experience tells me that fines are a much bigger motivator to pushing compliance to a particular standard versus data breach laws. If you want to get companies to comply, affect their business. After all, security and compliance is a BUSINESS issue. Properly motivated, it will be addressed.

________________________________________
¹ Albeit, in the Merchant's defense, CISP had changed several times since 2001, and the original PCI Standard was released and amended by 2007 such that we were then working under version 1.1.
² Reported compliance is different from actual compliance.... remember that.

Posted by Branden Williams at 6:30 AM | Permalink | Comments (4)

Here's one of those areas where security and compliance stare at each other angrily across the table instead of skipping down the trail together singing, "Tra-la-la." I was speaking to a friend of mine at a birthday party about this because guys don't stay inside for the Hannah Montana makeover, we go outside and talk about beer, sports, and information security.

OK, SOME of us do that. So what if I like my toes painted?

Anyway, he was telling me that his company was taking the stance that private label cards, or those cards that have the company name on them instead of a Visa, MasterCard, American Express, Discover, or JCB logo on them, should be included in their PCI efforts. At first I misheard him and thought he said that his assessor was requiring those cards to be included. If that is the case, the assessor needs to go back to training. The only cards that are in scope for PCI are the ones that have one of the five founding members' logos on them (EDIT: Or ones that conform to valid PANs from those card brands that may still not have the logo on the front. Thanks to Todd A for pointing that out!).

This is part of that security versus compliance argument. When I learned that his company was requiring them to be included into their PCI efforts, I applauded them. Here's an example of a company that realizes that the only way to ensure their investment into the private label payment system will not be overcome by losses due to a breach is to include them in a PCI Assessment. Not only does that say something about the confidence in the assessment process, but it also says something about how much faith management has in the information security program.

There are, of course, many reasons why this may have happened. It could be as simple as management's realization that the security program is short on people and resources. Therefore, they have decided to offload some of the tasks to an assessor performing some required compliance assessments. There are darker reasons why this may happen, but those will be left to your imagination.

For the record, non -member branded payment cards are considered out of scope for PCI. But beware, If you are managing your own private label card system, you should treat it with the same level of security (if not more) than you do your member branded cards.

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

Do you remember debate or speech class? I remember having a professor assign me the counterpoint position on an issue in which I didn't agree. I always thought that the other guy had it easy if our beliefs were the same because he already believed what he was saying.

I recently read an article by Ariel Silverstone in CSO Magazine entitled "Where PCI DSS Still Falls Short (and How to Make it Better)" in which Ariel seems to have been put in a similar situation. Either she was asked to publish something (anything), or asked to specifically publish something on PCI; regardless, she should have spent a little bit more time on research than she did. After reading her positions, I'm pretty sure she didn't ask any QSAs (or anyone that have been in the industry for more than a few weeks) for assistance during her research phase.

After reading the article, I felt cheated. I picked up the text thinking that I would find some insightful points by a former consultant and current professional affected by PCI. Instead, I was subjected to an article that set up the shot but didn't follow through.

Her first points are definitely on-point, if not historical in nature. The first thing I have to take issue with is her comment on scoping and comparing PCI DSS to the SAS 70 Type II (note: not type I). While you can carve out specific scope for PCI and validate it like you would a SAS 70, that's not necessarily a bad thing. Sometimes that is required for a business to do depending on how they are set up. It's up to the enforcement entity that accepts the Report on Compliance (i.e., a card brand or bank) to decide if it meets their requirements. Companies that do IT hosting and management require this kind of flexibility, otherwise they would be forced to apply PCI to all of their customers.

Ariel suggests splitting up the requirements, but it is clear to me that she didn't read past Page 3 of the PCI DSS. While in some cases you could extract the top level requirements (particularly the short ones), it is unrealistic to simply group top level requirements together. For example, some elements of Requirement 11 can overlap with Requirement 6, and others should potentially be found elsewhere in the standard. Making blanket statements about the top level requirements is a dangerous game to play.

Next she talks about the concept of segmentation. PCI DSS does not require segmentation, but if you have a diverse network, it is highly recommended to reduce scope. She takes the concept of segmentation and applies it to requirement 6.1 (ok, I guess she did make it past page 3, I stand corrected), further questioning the rationale of thirty days vs any other number of days.

Part of making a standard is that you have to draw a line in the sand SOMEWHERE. Otherwise you will have people asking those kinds of questions versus actually progressing toward a goal. The point is to patch systems quickly, or to at least mitigate the risk such that the vulnerability could not be exploited (say by removing a .DLL file. Thank YOU .art vulnerability!).

The next one is a common mistake made by many professionals--including QSAs. The old One Function Per Server requirement (2.2.1). Proper virtualization can be used (including with mainframes) to allow multiple functions in the same piece of hardware while meeting the intent of the requirement. She says she was not aware of any research that proved this requirement reduced the risk associated with breaches. I've not looked for it, so I'll assume it doesn't exist. Regardless, any certified security professional will understand the concept of an enclave, and knows that proper access controls must be put in place to prevent a vulnerability in a DNS server leading to a dump of customer data. I've been calling that an "intrusion path" for years. It's the concept of many successful complex attacks. I compromise X on one server, which leads me to access Y on the same server, which then leads me to Z on another server, and so on.

It's just plain riskier.

The next suggestion (4 if you are keeping score), along with content in Suggestion 7, illustrates Ariel's lack of experience in the PCI world. Suggestion 4 discusses requirement 3.1 and the somewhat contradicting concept of keeping the storage of cardholder data to a minimum while using business, legal, and/or regulatory purposes to define what is stored and for how long.

One thing I've learned about people is that they are much less likely to stick with an off position if they are forced to write it down--especially in public companies where documentation like that could become part of legal discovery. Instead, we have conversations over the phone or in crowded coffee shops, confident that never writing it down will allow us to slip by undetected if something bad happens. I personally believe the intent of this requirement is to force businesses to write down their retention plans, see what they look like on paper, and adjust if necessary. I can't tell you how many times I've been told that data must be retained for ten years, only to have the same person come back to me in a week to deliver a scaled back version of the stance on paper.

Suggestion 7 screams "outsider with a lack of experience." I remember sitting in difficult meetings in 2004 getting yelled at by all kinds of executives because I was telling them how to run their business. You can't go from zero to eleven in a matter of minutes (unless you are Spinal Tap of course); you have to ease your way there. If the PCI Council saw fit to require internal encryption in the next version of the standard, I firmly believe there will be a revolt.

If you are not encrypting at least some internal communication of data you deem sensitive, you have a lot more faith in the security of your satellite offices than you probably should. Ever walked into a retail store only to see the system room door wide open? Do you think the corporate data center door is also wide open (hint: it's not, and usually surrounded by lots of security)? I'm not saying that we should encrypt everything, but that is one we should leave to the merchant or service provider to decide.

Oh, and I'm pretty sure that FTP or "automated tools" are not the same as "end-user messaging technologies." And no, it is not OK to send unencrypted data over the internet with FTP.

Skipping back a bit, Suggestions 5 and 6 are a little odd to me. Flexibility will allow for companies to deploy something that is best suited for their environment. The standard used to suggest TripleDES and AES as two encryption algorithms to be used, but there are plenty of other algorithms that are considered strong (if not stronger) that are acceptable. For example, Two-Fish is a fantastic algorithm (implemented correctly of course), and should be allowed on PCI related systems.

Final thought on that suggestion, the PCI Council should NOT be accepting legal risk for mandating particular encryption algorithms or key strengths. She points out why with the Zimmerman reference. Every company should do their own legal analysis to determine the best course of action for them.

I think you should read her article and form your own opinion, but I view it as a slightly embarrassing show peppered with valid points here and there. A prime example of why you should fully research a hot topic like PCI before publishing a "thought leadership" piece.

Posted by Branden Williams at 6:17 AM | Permalink | Comments (1)

David Navetta published a fantastic article in this month's ISSA Journal entitled, "Who is Minding the Legal Risk around PCI" that takes a deep dive into the legal ramifications of not complying with the standard. If you do not get the journal, first off, go join the ISSA! It comes free with your membership!

In the meantime, jump over to David's blog to read the article! Towards the latter part of the article, David lays out two very real risks that I have discussed many times in this blog such as QSA shopping, rubber stamping, and scoping.

Enjoy, and have a great weekend!

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

What are you doing at 2pm eastern today? If you have that annoying budget meeting, or maybe one of those late lunches with the group of folks that bug you, how about joining me for a webcast on PCI?

Click here to register, and I'll be on Twitter during the event if you guys want to interact!

Posted by Branden Williams at 7:41 AM | Permalink | Comments (0)

PCI is still a hotly debated topic nearly four and a half years after its initial release on December 15, 2004. You didn't have to visit too many after hours parties or exhibitors at RSA to see that.

Most of the criticism of PCI comes from people who really don't understand it, or understand how to use it to their advantage. And those people fall into two categories themselves; those who are green to PCI and are overwhelmed, and those who love their soap box.

Those in the former bucket just need time to get up to speed. PCI, like Rome, was not built overnight, and it requires weeks of study to fully grasp how it will affect your environment. There is training available from a couple of industry sources, though my personal preference is that any training on payment security should not stop at PCI. I have a solution for the card companies to address the latter group directly, but more importantly, address the industry at large to demonstrate that you really do focus on information security.

I propose that the founding members of the council (Visa, MasterCard, Amex, Discover, and JCB) consider two ways to demonstrate PCI Compliance. The first of which is to complete the PCI DSS just like they would do today. Nothing new there.

Here's the twist.

The second method should be met by demonstrating a mature ISO 27000 security program, potentially certified under BSI America. That serves two purposes. The first purpose is to accomplish the intent of PCI DSS, protecting the data. The second is to combat the nay-sayers who say things like "I can't wait until this PCI crap is over so I can get back to security¹." In reality, those nay-sayers were doing a poor job at security before by only focusing on problems that interested them, not ones that were in the best interest of the customers, shareholders, and employees of the company.

If the card brands gave merchants and service providers the option, I think you would see the majority choosing PCI DSS, and only the most savvy choosing the ISO route. The best thing is that the card brands could fight the fires on two fronts. They can continue to coddle the laggards, and improve corporate information security for those that wish it. Most security professional agree (four out of five dentists?) that PCI is not the scariest thing out there, by FAR. But if you use what you learn from PCI and improve upon its required baseline, you can use the ankle-biting nature of PCI to also subdue his bigger, more ornery cousins PII and the State Data Breach Laws².

_______________________________
¹ This is an ACTUAL QUOTE from one of my retail contacts!
² Sounds like a great name for a band!

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

See part 1 here, part 2 here, part 3 here, part 4 here, part 5 here.

Go Forth and Compensate!
What a pretty mural we have painted over the last several pages! Good compensating controls are the result of a marriage between art and science. We've discussed what compensating controls are, what they are not, some funny examples of how to go wrong, and three solid scenarios from which we created good controls.

Compensating controls are not the golden parachute of compliance initiatives. They require work to build effective ones that will pass the scrutiny of both a QSA and an Acquiring Bank (or card brand). Rarely do they yield lower cost and effort than simply meeting the original requirement. PCI DSS is based on many good (not best) standards of practice for security, and should be viewed as a baseline by which to operate, not a high water mark by which you aspire to be one day. Compensating controls may help you lower the bar of compliance in the short term, but remember, only you can prevent a security breach.

I hope you enjoyed this article on Compensating Controls! Look for links to download the entire articles in the next few days!

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

See part 1 here, part 2 here, part 3 here, part 4 here.

How to Create a Good Compensating Control
We've 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 mis-guided attempts to create them. Before we discuss the examples, please remember that these examples should be used for illustrative purposes only. I have over simplified the scenarios for brevity, and things are rarely as simple in the corporate world. Ultimately, compensating controls must be approved first by a QSA, or barring that, your Acquiring Bank. I know I don't like it when someone slaps some random article about PCI on me 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.

Here's a common compensating control that my team defines and implements at a customer. A Level 1 brick and mortar retailer with 2,500 stores has some systems in their stores that do not process cardholder data. These systems are a high risk to this customer's cardholder environment because they may access both the internet through a local firewall and the corporate intranet and webmail system, and users log-in to that machine with the default administrator account. Store managers and retail operations claim that the systems are required for day-to-day business because each store is empowered to customize their operations to better fit the local market. The corporation believes this drives innovation and helps them maintain a competitive edge over their peers.

What do you do? Do you crush the retailers aspirations to innovate by telling them they must deploy active directory to these machines, lock them down Department of Defense tight, and staff a call center? I suppose you could. But, if you made that recommendation you missed something important--understanding the business and limiting the impact that your compliance recommendations make. Instead, consider this compensating control.

Any number of network components could be used to create some segmentation in this environment. Let's say that we have a VLAN aware switch at the location that can have access lists (ACLs) tied to it. Why not create a new VLAN for just the POS network? Then create some ACLs around it to make it look like it is segmented behind a firewall. Now the threat of the in-store PC is effectively mitigated provided that the ACLs are appropriately secure.

Wait a second, ACLs? Those are not supposed to be used for compliance with PCI! They most certainly can be used for compliance. Requirement 1.3.6 only refers to external connections, not internal connections. Using ACLs internally is perfectly acceptable. If you want an extra boost in security, use a reflexive access list (RACL) which will basically look and feel like a stateful inspection firewall.

"But Branden," you say, "my store networks are different in every store! I can't just slap something in there like that and expect it to work globally!" If this is the case, I bet your store support group is overloaded with break-fix calls. Maybe this could be an opportunity to shore this up and get consistent footprints in each store?

Barring that, how about this twist?

Let's say that you are running a Windows XP variant as the operating system powering your POS. You are already required to put some kind of Anti-Virus and malware removal tools on there. Most of those come with software-based firewalls that could be administered remotely. Deploying firewall capabilities to the POS itself could be viewed as appropriate segmentation depending on the policy attached to that firewall. It is neither a transparent solution, nor is it very pretty, but it works.

The first solution above is really less of a compensating control and more of a way to reduce the scope of PCI. The best thing you can do for your company is reduce the scope of PCI (or any compliance initiative) to the bare minimum required, and then manage that subset of your infrastructure. The second truly is a compensating control. It meets the original intent and rigor of the original PCI requirements and provides a similar level of defense as the original requirements (reduce the vulnerability to payment systems), goes above and beyond the base requirements of PCI (firewalls are not required on devices that do not leave the premises), and it is most definitely commensurate with the additional risk imposed by not meeting the original requirement.

Take a closer look at those two suggestions. The first may be "free" to your company depending on what is already in place! You will need to adjust business process and prepare your IT community to deal with the change, but you may not need to spend any hard dollars rolling this solution out (unless your equipment cannot do this in the first place). The second suggestion, which is actually the compensating control, requires capital outlay for software licensing and training or consulting to build out the environment. Upon rollout, things will break that will result in potential losses to the business. I've seen retailers push changes like this to large environments, and every single one results in some kind of error.

Are you starting to get the hang of this thing? How about another example?

A Service Provider has a large mid-tier UNIX installation that runs critical areas of the payment process, including long-term data storage. For various reasons, encrypting the data is not an option on these machines. How do we make this service provider compliant with PCI Requirement 3.4?

This is a real world example that comes up frequently. Encryption implementations have come a long way since early in this decade. The words "my platform does not have a solution for encryption" is no longer valid for platforms that can comply with PCI. When I present the following control to customers, it is shocking how fast they find a way to encrypt their data.

Most mid-tier UNIX operating systems have the ability to switch from Discretionary Access Control (DAC) to Mandatory Access Control (MAC). MAC will cause that mid-tier UNIX machine to act like a mainframe using RACF/ACF2, and managing those controls is now a massive chore for whomever is charged with it. Converting the appropriate systems to MAC, and potentially adding some segmentation could effectively render cardholder data unreadable and meet PCI Requirement 3.4.

Things are never that easy. Security professionals inside companies love the idea of converting to MAC as it allows us to have more granular control over the systems and their data. Practical ones know that converting an existing system requires so much effort that the costs outweigh the benefits. This is a perfect example of how a compensating control might look good on paper (it's only three words when you use the acronym! 'Convert to MAC!'), but in reality would be much easier to just meet the implied requirement to encrypt that data.

One more example, and then it's time for you to get creative!

A medium sized retailer with less than 500 stores is struggling with requirement 10.2.1 to log 'all individual accesses to cardholder data.' All of their data is stored in a large DB2 database that runs on a mainframe. They run massive batch processes at regular intervals, and their space constraints prevent logging every single access to a row. Do you tell them to go back to their board for a CapEx request to buy lots and lots of drive space to store logs?

Before we proceed, consider the intent of the requirement. Reliable logs are valuable in investigating a breach quickly. Without them, it may take forensic examiners days, or even weeks, to determine the source of a breach. Once the source has been identified and analyzed, forensic companies must attempt to determine how many card numbers may have been exposed. If there are no logs, the assumption is that everything could be exposed, meaning that fines will add up pretty quickly.

The idea is not necessarily to make a log record that includes every single card number that is accessed, but to be able to identify which cards are accessed through the data contained in the logs. If we were to log the actual query performed against the database during a batch process, with knowledge of the date and time that the query was run and exactly what that query will do, we should then be able to determine, with reasonable certainty, which cards were accessed. Common batch processes run on a daily basis, usually using the data from the previous day to produce its output. If we must determine what could have been exposed from January 1 to January 8, we could look at the data that would have been accessed by that batch process during those days.

Logging the query, and all the other elements required by 10.3 about that action, would generate a reasonably accurate list of records that would use a fraction of the drive space required by creating an entry that has every single record exposed.

Look for the conclusion, part 6, on Wednesday!

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

See part 1 here, part 2 here.

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. I don't have to make this stuff up, I get paid to listen to it!

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 lifespan; 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 didn't have a fun story or two based on my experiences coaching companies or individuals to better security. No names will be used, and I'm 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.

Look for Part 4 on Wednesday!
_______________________________________
⁷ While it is not a requirement to segment your network, it does make compliance easier. Usually in this situation, I find a legacy system that cannot be patched or upgraded, but now becomes in scope. Then the conversation about compensating controls starts.
⁸ Remember, the requirements can change between versions of the standard.

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

See part 1 here.

What a Compensating Control Is
In the early years of PCI DSS (and even my experience under the CISP program), the term compensating control was used to describe everything from a legitimate work-around for a security challenge to something that Michael Phelps may have dreamed up while expanding his mind at approximately twenty minutes after four in the afternoon⁴.

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' being on vacation is not a legitimate constraint, and an armchair review of the gap and potential control is not a risk analysis. Qualified Security Assessors (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 is not thorough.

Every compensating control must meet four criteria before it can be considered for validity. The four items that every compensating control must do are: meet the intent and rigor of the original PCI DSS requirement, provide a similar level of defense as the original PCI DSS requirement, be "above and beyond" other PCI DSS requirements, and be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement⁵. If you think compensating controls are easy, please re-read the above statement.

The compensating control polygon has four specific points that must be met. For a compensating control to be valid, it must:

1. Meet the intent and rigor of the original PCI DSS requirement;
2. Provide a similar level of defense as the original PCI DSS requirement;
3. Be "above and beyond" other PCI DSS requirements (not simply in compliance with other PCI DSS requirements); and
4. Be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement.

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

Look for Part 3 on Monday!

_______________________________________
⁴ Aww... too soon?
⁵ As described in the PCI Security Standards Glossary: https://www.pcisecuritystandards.org/pdfs/pci_dss_glossary.pdf.
⁶ If you are reading this and saying, "HEY! We CAN just use shared passwords!" please grow up. Nearly every system has the ability to use something like sudo which is free, or a commercial variant.

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

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.

Sound familiar?

I wish I had a tape recorder at every meeting where I heard the phrase, "Don't worry, we'll just write up a compensating control for this." It may not be as great as the twenty-seven minute long video floating around of every single expletive uttered during The Soprano's legendary run on HBO¹, but I bet I could fill a few podcasts with the audio.

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)³.

Look for Part 2 on Wednesday!

_______________________________________
¹ How impressive is twenty-seven minutes? Seriously!
² Why? Because we are not provided a common risk model to use.
³ Please visit http://www.pcisecuritystandards.org/.

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

It's been a few days now, and the dust is still settling as they say. Anton Chuvakin posted some great thoughts on the hearing, including one that I TOTALLY missed.

In Mr. Jones's¹ defense, the site that has the XSS error in it MAY NOT be in scope for PCI depending on where code base lies, but regardless, the vulnerability is inexcusable from a guy talking to Congress about this stuff.

I fired the info around to some of our consultants and had a couple of responses of note.

James, a Consulting Manager in our group says (I am paraphrasing some of this):

The contention that PCI forces retailers to stray from their core competency of retail seems to be misleading. Small Level 4 merchants certainly do not have IT security backgrounds, let alone resources, but they also usually have small to nonexistent systems to protect. The core target of PCI, large Level 1 brick and mortars and prominent e-commerce portals, rely on IT excellence for operational efficiency and have long disenfranchised security efforts to the detriment of the consumer. The competency at maintaining systems securely should grow with the corporation and can be achieved without disrupting the "core competency.

James makes a good point here... From a sheer numbers game, level 4 retailers outpace any other group in the number of compromises. Of course, it's not hard when you have seven million counterparts in your group. But when you look at the number of records compromised, the big retailers are the ones that have exposed the most... probably! I just did a little quick math and that assumption requires big ticket breaches to continue to happen.

Regardless, James points out that security should exist as a partnership between technology, human resources, and the business to allow the enterprise to grow securely.

James also points out that "Mr. Lungren seems to have a lot of bad luck when paying for meals. Make sure you bring an extra credit card if dining with him."

One final thing that we in the industry deal with every day. James says:

I think Ms. Clarke may be jumping on the "PCI does not equal secure" bandwagon a tad bit late. We've all been in enough conference rooms where the "above and beyond the PCI standard" does not exist.

Frank, a Sr. Consulting Manager in our group says:

Main point: PCI is a baseline that prevents most breaches, and in all cases to-date, no compliant entity has ever been breached. Counterpoint: ambiguity in the standard and/or interpretation by a QSA leads to differing opinions on applying the standard. Folks, SQL injection vulnerability on an external website is a no-no, and should have been found at multiple checkpoints of the DSS, no matter what shade of rose is on your glasses.

shaZAM! Of course he's absolutely right. Setting the standard aside, vulnerabilities like that should be found and fixed using standard security practices.

He concludes his thoughts with this nugget:

End-end encryption is NOT a silver bullet. If hackers have full access to the internal PCI network, then they have the opportunity to attack the encryption methods as well. We all know that merchants extract information from the authorization process, and would need de-encryption mid-stream to maintain their data warehouse appetites.

As a marketing guy by training, I can tell you that there is value in certain types of data that might fly through the various flows that merchants use. What is going to happen if retailers adopt end-to-end encryption? Will the marketing guys get creative and find a way around the control? Maybe the newest reincarnation of the write-my-complex-password-down-on-a-postie-and-stick-it-under-my-desk-because-no-one-will-look-there workaround?

Time will tell!

Anyway, I hope you all enjoyed the briefing as much as I did!

OH! And we had a small "holiday" this week, April Fools Day! Here's a GREAT roundup of the most popular pranks. The Opera face gestures is exceptionally hilarious, and I can see lots of HR incidents getting started over innocently opening a speed dial.

__________________________________________
¹ CMS 7.18. Look it up.

Posted by Branden Williams at 11:13 AM | Permalink | Comments (0)

It's April, and what does that mean? It's time for ISSA's 2009 PCI issue! The feature article for that issue, is The Art of the Compensating Control. You can download this version from the website, even if you are not a member, at http://www.issa.org/Members/Journal.html for the rest of the month. If you are reading this after April 2009 and want a copy, let me know.

You readers of the blog are going to get a special treat! The original article was much more casual and entertaining than what we ended up publishing in the Journal. Thom reviewed the first final draft of the article and said that it was much too casual. He was absolutely right. I can't tell you what a joy it is to have a fantastic editor working on your behalf to make sure the best possible quality product is published.

Wait, something's missing. I said you are in for a special treat and all I did was gush over my editor... hrm... what was that treat....

OH YES! I will be posting the original, un-cut, un-censored article RIGHT HERE on the blog over the next few weeks! The original article will be broken into six individual posts that will be put on this blog every Monday and Wednesday for the next three weeks starting on April 6. By the end, I'll have a link to both versions of the article for your downloading pleasure!

I hope you enjoy reading it as much as I enjoyed writing it!

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

I got a few comments yesterday that made me think that some of you have the wrong idea. OK, I admit, the EDI/CIO comment I made yesterday morning was over the top, and as an act of contrition, I will tell you that yesterday I was told not to wear a shiny shirt, suit, or shoes to a particular customer because their CIO didn't like shiny consultants. My shirt was quite shiny. Something that would have been helpful to know before I packed. DOH.

Before I go any further, I do realize this is April Fools Day. What you are about to read is NOT an April Fools joke. To help illustrate that point, you won't see any backhanded complements here, just the front hand kind!

I love Dave Hogan, CIO of the National Retail Federation. Sure, I pick on him, and have published rants on several occasions here in this blog--dating back to my first reaction to the NRF's CIO from a 60 Minutes broadcast in November of 2007. It's not exactly like the playground love I felt when pushing down Lisa Duffy at recess. More like your beer buddy that only gives you a hard time when you spend all day complaining about guys that buy fast cars, drive them with the top down during winter just because they can, and then I go buy one and do the same thing, and James calls me on it while visiting a local watering hole in February. It's that kind of love. Beer buddy love? I may be on to something.

Let me clarify that I've never met Mr. Hogan. I once sat in a room with him in Brussels, but after the session ended, both of us had folks around us that wanted to chat and I lost him in the crowd. I wanted to meet him face to face, but didn't get the opportunity.

So why do I love Dave? Well for one, he has the testicular fortitude to stand up and voice his opinion against what many believe is a conspiracy against merchants. There are not too many others, including the competing retail organization, that take the same stance that he does in such a public fashion. The guy has cojones, and he should be celebrated for it.

I love Dave because he gives me something to write about. Agree or disagree, he plants a flag out in the PCI pasture and it's up you to to decide to run toward it, or plow over it. In a world of people who refuse to accept accountability for their actions, litigate their way out of trouble, play the blame game cause NOTHING is EVER their fault, and are publicly moderates even though they are privately extremists, how great is it that you know EXACTLY how Dave feels about the issues he talks about? If nothing else, he's consistent. The same message that prompted me to write that blog post late one Sunday evening after watching football was conveyed in the congressional hearing on PCI yesterday. Regardless if you agree with the points, he lays them out and lets you do with them what you will.

Finally, I love Dave because deep down, he really is looking out for the little guy. I've been a part of small companies. My first experience being the little guy was a two man company back in 1996. We were competing against the big guys--and winning. But as we grew, we quickly realized that the big guys had much more ability to react to us than we had to react to them. So we gracefully exited and sold two years later. So from one little guy to another, it is great to have someone standing up for you and trying to make things better.

Dave has good intentions. He is trying to make things better and he doesn't mind ruffling a few feathers in the process. One of these days, should we be in the same city, I would LOVE to chat about our differing viewpoints and offer as much help as I can to him and his constituents. After all, I'm not too unlike Dave in that I like to help people win, especially the little guy!

How about a round of applause for Dave!

Posted by Branden Williams at 6:40 AM | Permalink | Comments (4)

If you missed it, you can see a recording here! See what the Twitterverse had to say here by searching for #pcihearing. TONS of coverage on this.

First, I am very proud of our congress for putting this hearing together. It is clear how serious this situation is when listening to the prepared, pointed statements read in the beginning. I hope I don't make anyone upset, but I do giggle a little bit when non-techie folks trip up on techie terms. I certainly expect someone would giggle at me if I were reading a statement of detailed medical terms and missed the words. Regardless, huge props for taking the issue on.

In the next paragraphs, clicking on the individual's name will bring up their prepared, written transcript that is summarized in the briefing.

After the opening statements from Chairwoman Clarke and Chairman Thompson, Ms. Rita Glavin, Acting Assistant Attorney General, Criminal Division, Department of Justice spoke about her experience with card breaches and investigations. The committee had a few questions for her, but I don't see a written transcript for hers or any of the later testimony. I'm pretty sure they had someone taking the entire text down, but I don't see it posted.

Next, they welcomed up the next group of folks, starting with Bob Russo, General Manager of the PCI Security Standards Council. Bob did a good job of explaining what PCI is, and how the PCI DSS, PA-DSS, and PCI PED Standards work to protect cardholder data. He also re-iterated Visa's general statement from earlier this month that no breached entity has ever been found to be in full compliance with the PCI DSS.

Up next, W. Joseph Majka, Head of Fraud Control & Investigations. His statements touched items such as the VISA Compliance Acceleration Program that is fining merchants today, and how VISA cooperates with law enforcement to assist in the prosecution of the bad guys. He also discussed the removal of RBS Worldpay and Heartland Payment Systems from the CISP Compliant List of Service providers. Looking back on it, I wonder if that action was done knowing that this hearing was on the horizon.

Following Mr. Majka was Michael Jones, CIO of Michael's Stores. One of his statements was a little odd to me, the whole security policy question. I think that has been addressed by the council in the FAQ. If not, it has been discussed at length in various areas, and I believe he would have gotten a good answer from the Council if he submitted a question.

Mr. Jones also brought up the chargeback thing, and I'm really struggling with this. Unique approval IDs exist for every card brand as of last year, and we have been able to get EVERY one of our customers processing chargebacks from their banks WITHOUT storing the full PAN (yes, Hogan references this in his statement too... ugh). Next he makes an incorrect statement that PCI requires card data to be encrypted. PCI requires card data to be rendered unreadable, encryption being one of the many methods that can be implemented to accomplish this. His points on sending encrypted info to the bank is well taken, but again, he might need to push hard on his acquirer. Many acquirers or processors offer this. You can also protect card data in flight without dealing with acquirer specifics by using site to site VPNs or SSL tunnels.

Next, he insinuates that end to end encryption would have prevented several prominent breaches. I'm too close to those matters to say definitively on this blog; however, one point I will make is that end to end encryption only works if it is truly end to end. Internal network encryption that does not start at the PED has a great shot of being vulnerable to attack. How? We're seeing attacks where hackers upload debugging software to POS controllers, or even terminals, and scrape memory. This means that they can see the information before the encryption routine occurs. Uploading this type of software to a PED device is much more difficult (if not impossible) to do, that is why the encryption must happen there.

Next, Mr. Jones talks about how SOX covers PCI. Some cases, yes, but not in the way it was presented. He makes it seem like SOX & PCI are big duplicates.

His next point talks about how the merchant ends up holding the bag in a breach scenario. He is absolutely correct here. What he fails to mention is that the merchant MUST comply with other regulations, not just PCI, and that it is the merchant's choice to either 1) be responsible with the data they have, or 2) stop accepting credit cards. I know several merchants who have stopped accepting cards, or completely outsourced the processing of cards for this very reason. Sure it costs more, but think about it. That's the compliance cost right there. Now you are not holding the bag, especially since I believe there is little or no brand damage suffered by a retailer caught in a breach.

Retailers DO have the largest financial impact, especially from fines from ADCR (Visa) or other recovery methods. Wow, he called the card brands Card Monopolists!

Next, Mr. Dave Hogan, CIO of the National Retail Federation. Ahh, Dave, Dave, Dave... I had really high hopes for his statement after he started off with some fantastic points. Maybe he fired his old writer? I won't summarize everything, you can watch the video.

But then the propaganda started coming out. I disagree with his point about the standards constantly changing. They change on a set schedule of every two years, the last one actually relaxed several requirements from PCI DSS 1.1.

I want to point something out here... The "game is always changing" mode of thinking is ALL RELATIVE. I've seen merchants move mountains when it comes to reacting to the market, such as standing up stores in record time, moving products that are virtually guaranteed to sell to the front of the store, and slashing prices to compete with the down-the-street guy. Taking two (or more) years to implement a standard is certainly telling of where the focus is when you think about how quickly some companies react to market conditions.

It's all about the mindset.

Lots of finger pointing here for sure from the merchant side, but arguably they have the most to lose.

Will PINs solve Hogan's point number 2? No. The same systems are used for Credit & Debit, and companies will continue to expose the system's flaws by storing said PIN data and having it subsequently breached.

I'm not going to summarize the entire Q/A, you need to watch it. Suffice to say, GOOD stuff in here. A couple of highlights...

Mr Lujan did miss one point that Bob was trying to make. In the fire inspector example, Bob was revealing a potential issue that can occur in how companies become compliant, maintain compliance, and potentially suffer a breach. Mr. Lujan pointed to the QSA (he used the term regulator, which can definitely be a problem), while Bob seemed to point to the merchant (which can also be a problem).

Hogan also did his whole thing about merchants being required to store cardholder data. I've said it before, this is total hogwash and I still can't believe that he is spreading this nonsense. Every customer of ours has been able to address this with their acquirer such that they are not required to store this data.

Mr. Jones hits it right on the nose in this interchange. Merchants MUST work with their acquirer to accomplish this! If the acquirer is not doing their job properly, maybe it's time to change to an acquirer that will (WHO MOVED MY CHEESE!??)!

One thing that I'm really worried about... Let's say that the card brands "fix" the system, and make it hack proof. What will the bad guys attack at merchants next? If you want to look at the two competing problems here, problem one is that the payment system IS insecure. I don't think you will find anyone that will disagree with that. Problem two is so much worse... many corporations are ALSO insecure!

Mr. Hogan mentions that companies replaced good security programs with new programs to cover PCI. PCI is NOT a security program, and was never meant to be one. That said, I would challenge Mr. Hogan to show me a good security program, pre-PCI, that is better than what merchants and service providers have now, post-PCI. If the old program was good, but replaced because of PCI, the company doing the implementation missed the mark.

Bigtime.

Regardless of the outcome, this was an extremely productive session, and I hope to see more testimony and more written statements from the committee and witnesses on this subject. I think that all of the panelists (yes ALL.. every one of them) showed a great amount of courage today standing up in a session like this and discussing serious issues with payment security, and I only hope that this leads to a better understanding of data and payment security.

You can be a victim, or you can be the victor. The path is up to you.

Posted by Branden Williams at 5:45 PM | Permalink | Comments (6)

Last week I moderated a panel at a PCI focused dinner in Chicago. Big props to the folks that helped to plan this (Alex, Melissa, Ben, and Diana from VeriSign), the event was great! The panel participants were heavy hitters from the industry including Anton Chuvakin from Qualys, Davi Ottenheimer from Arcsite, and Bill Cook from Wildman Harrold.

Anton has a few great points from the event that he has posted on his blog here. We had a fantastic discussion, and there were even great discussions among the panelists that revealed conflicting opinions. We had so much discussion that we were unable to go through the entire list of questions I had prepared. I had thirteen, and we only were able to get through THREE in the seventy-five minutes we used!

Side note... the guy next to me on AA1882 to BOS is chuckling so hard at Madagascar 2 that he is shaking the whole row. WOW. Too bad I don't have my ratchet set, I could secure these seats a little better. And yes, I often do write at 30,000+ feet.

The audience and panelists focused on the word compliance and how it differs from the terms security and validation. It is obvious that the scrutiny on PCI is higher now than it was during its initial rollout. Merchants are crying foul saying that card brands are using this to protect their investment into outdated and insecure technology. Legal cases challenge both fines and statements made by Visa recently revealing that there has never been an instance of a compliant (remember the difference between compliance and validation) entity being breached. And everyone is disgusted with the vendor that claims to solve all of your PCI problems by buying his technology.

We're at a crossroads, methinks.

Today, Bob Russo and other industry pundits (one of which has absolutely no business being a part of the inquiry except to irresponsibly use his position promote his own incorrect and misleading propaganda thereby making retail CIOs look like old relics that cheer for this fancy, new thing called EDI... yes, you guessed who it is) will go before the House Homeland Security Committee to try and answer the question, "Do the Payment Card Industry Data Standards Reduce Cybercrime?"

Crossroads.

One thing that was clear from the panel is that everyone agreed PCI has pushed data security projects farther inside their companies than any other measure to date. If you are reading this out there and disagree, it may take a breach for your management to see the light and invest appropriately. We also all agreed that an amazing amount of money for security projects magically becomes available after a breach.

After listening to some of the stories about other QSAs that the audience brought, I think I might have stumbled upon something. We've all had someone explain a situation to us that does not appear to represent a compliant solution. Not only are we sometimes mislead by a lack of context, but I think something a little more ominous occurs.

The number of QSA firms is impressive, and merchants are free to choose any one. Let's say that as a QSA you are dealing with a prized or significant customer. While the QSA is on-site, the customer pushes back (as I explain in my upcoming article... more on this later) on findings in various areas to see if the QSA will bend. If two or three managers push back in key areas all at the same time, there is a significant chance that a non-compliant situation might occur if the controls are inter-dependent.

Is the QSA remiss for not standing its ground or pointing this out? Absolutely. But as we have seen, merchants and service providers sometimes forget that they are still ultimately responsible for their own PCI Compliance. Once they have that compliant ROC, sometimes they run around their campus triumphantly waving it in the air as they dodge cubes in Prairie Dog Land.

Sit back from a moment and think about all those situations where you have pushed back on assessors. Depending on the items they reversed their position on, you may be in one of those situations where a breach is going to sneak up on you. Is compliance with PCI a guarantee that you are immune to breaches? Most (including the panel and all of the audience members agree) that it will not. Instead, implementing PCI correctly and layering security on top will give you the best shot you can get.

Remember, if you are able to convince your management to take security seriously, and responsibly use your position as a security expert to recommend controls that are good, cost-effective, and relevant to the organization, you will have a much better shot at preventing that breach.

Posted by Branden Williams at 6:32 AM | Permalink | Comments (1)

The following is a guest post by Frank Castaneira. Frank is a Sr. Consulting Manager inside the Global Security Consulting practice at VeriSign.

Matt Hines recently wrote about the PCI Council discussions on applicability and adequacy of the PCI Standard given reported breaches of validated entities such as Hannaford and Heartland. Branden recently discussed the PCI Council conversation on March 6. Branden suggested greater visibility by the Council into the incident response process. This posting amplifies on that solution and provides other perspectives.

The discussions mentioned in Mr. Hines article focused on the QSA (Qualified Security Assessor) posture that an annual on-site assessment is relevant only for that point in time. Although, I recognize the issue (point in time), my experience tells me that the real case in these breaches is that the entity really wasn't "compliant". Yes, a QSA attested to that compliance, but I bet the breach exploited a vulnerability (or multiple vulnerabilities) covered by the standard, and should have been caught by the QSA.

Of course, one cannot exclude the following scenario as possible:

Administrator (insider) is seduced by someone with connections to overseas organized crime. During the encounter, Administrator removes the private key-encrypting-key from a company safe. Encryption scheme is then exploited and the ill-gotten data is sold or transferred to a crime ring.

The previous example is purely fictional and designed to illustrate a point. The PCI standard is not perfect, nor will it prevent all forms of cardholder fraud. It is; however, a solid security baseline when validated through the eyes of a good assessor with a competent and quality-minded program behind him. Adherence to all the requirements will significantly lessen your risk-footprint, and practically eliminate the statistic of breached compliant entities. Note that organized crime feasts on the easiest kill, and compliance with the DSS builds a fence that is unattractive in comparison with other targets in the wild.

If the source of recent compromises becomes part of public record, my wager is that obvious errors and omissions by the QSA will be revealed. Although, all QSAs are required to take annual training and must pass a certification test, only very few create robust assessor programs that include peer reviews, significant onsite interviews, and data collection, and collaborative forums to discuss grey areas.

It is also important to acknowledge the client's quandary as they followed the rules. Level 1 Merchants and all Service Providers must use an approved assessor from the QSA list. Aren't all assessors the same; at least in PCI Council's eyes? If client picks an assessor from the list using any of the following criteria such as existing relationships, geographic proximity, or best price, then what could be the downside?

So enough of my competitive pandering; here is what I propose as a potential solution to improving the reputation and significance of the DSS.

Access to Investigations
As identified by Branden, the PCI Council is not currently an active participant of the breach investigative process. The Brands, sponsor bank, compromised entity, law enforcement, and of course, the assessor (Qualified Incident Response Assessor) are the only parties typically involved. The final incident report must include a section on PCI compliance status. This is more than just a checkbox on whether someone previously attested to their compliance, but a rather cursory review by the QIRA of all twelve DSS requirements (mini on-site assessment). This section is particularly important to the Council in determining whether the original assessment was properly performed. However, the content of the report is not typically shared with the Council.

The Brands do have visibility and influence into the PCI Council, but the Council deserves an earlier warning of new threats that may influence the DSS, and immediate feedback on sub-standard assessments that may have prevented the fraud in the first place.

The Council already shares NDAs with the Brands, and as the QSA licensing body may leverage its authority to place one under remediation (same as with its QA program). If the errors on the assessment contributed to the actual compromise and it was more than a lapse in point in time, then the Council should enforce its charter and discipline the QSA as necessary. This may weed the field of uncommitted QSAs, but will definitely heighten the thoroughness of those who decide to offer their clients the expert risk protection they were sold. This will allow a footnote or parenthetical on any new statistic involving compliant breaches (attested by a QSA in remediation).

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

Last night, Visa, Inc. collected a list of dates for upcoming compliance and published them on their website as "Key Dates." If you ever wondered what dates you needed to hit for Visa, Inc., they are all listed right there!

Some of the dates are news to this blogger, so it's nice to see something official and published, not just things we hear through the grapevine or by talking to various pundits in the industry. The next deadline they list is on March 31, U.S. Level 1 and Level 2 Merchants Prohibited Data Retention Attestation Deadline (applies to newly identified Level 1 and Level 2 merchants late 2007 and early 2008).

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

I recently did an interview with Brian Contos, Chief Security Strategist for Imperva on key issues surrounding PCI. Go check it out!

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

Times are tough. Unless you are just now coming out of your winter hibernation, you are probably so beaten by that phrase that you are not far off from striking the next person that vomits it upon your day.

Listen up executives, this one is for you.

Breaches cost money. OK fine, I know that is not paradigm shattering knowledge I just dropped like it was hot. Still, executives miss the mark when trying to securely manage or grow their business. We know this because of the nearly daily additions to the breach list that PrivacyRights.org manages.

Executives have been failing at managing long term expectations for years. Any of us that work for a public company know that an executive's myopic management may not be able to focus past delivering the next financial report. If your executive is only managing the P&L, how do you expect her to understand that a long term investment in security is something that is both wise and necessary? She will have to explain the added costs and lower quarterly performance to her shareholders--never a pleasant discussion.

Heartland is the second public company to go through a major breach in the last few years that will have to disclose costs associated with the breach in their reports to the Street. In a weak economy with flat growth, shrinking margins, and weak performance, imagine what a multi-million dollar charge would do to the viability of your company. If you had $300 million in cash, and had to lose half of it in six months to cover a breach, would you be able to ride out the rest of the recession? Imagine if you had spent $50 million over one year instead to achieve the same outcome.

That's savings you can celebrate; but unfortunately, it can only be measured it in hindsight.

If you ask an executive that is dealing with a breach what they would have done differently, once they get through the stages (Denial & Isolation, Anger, Bargaining, Depression, and Acceptance), they will probably admit that they should have paid more attention to the risks associated with poor security practices. Big expenditures over time are ALWAYS preferred to massive expenditures in a short window.

THAT, my executive friends, is what should be keeping you up at night. Have you spent enough money to prevent something that could alter the lives of some, if not all of your employees, shareholders, and customers? As the top dog(s), you carry the weight of the world on your shoulders. Employees and their families depend on you to make rational decisions and position the company to outpace competitors. Shareholders depend on you to deliver return on their investment in the company. Customers depend on you to ensure that the company is stable, the products and services are of acceptable quality, and that you will exist.

Notice that ALL of those people that depend on you are focused on the long term!

As the not-so-new adage goes, you will pay for security now, or you will pay for it later!

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

Going through some email over here and looked through the recent edition of The Aegis from the Society of Payment Security Professionals, and found a great little snippet from Chris Mark entitled "Wear Your Seatbelt...and Maybe a Helmet." In it, he pulls a quote from the PCI SSC that seems directed at detractors of the PCI DSS. They state:

"The PCI SSC believes that the best way to protect cardholder data that is stored, transmitted, and processed is by implementing the PCI DSS and remaining in full compliance."

Chris points out that this seems to imply that PCI DSS is the high water mark, not the baseline from which you should build a program. It may just be that a technical writer may need to get in there (as a recent press release demonstrates) and add a few words, or it could be positioning on the part of the council. What Chris and many of us are trying to say is the quote should probably read something like this:

"The PCI SSC believes that the best way to protect cardholder data that is stored, transmitted, and processed is by implementing the PCI DSS, remaining in full compliance, and customizing additional security measures to build upon the base requirements of PCI as appropriate for their business."

Not all companies should consider end-to-end encryption for every single transaction they process, but then again, some should. Not all merchants should eliminate all paper records from their store locations, but then again, some should.

PCI is, and always will be, a baseline. It is based an good (note, NOT best) security practices, and is designed to be a catch-all for everything that touches cardholder data. There are obvious limitations to the catch-all, which is well addressed in the Self Assessment Questionnaire model that was released just over one year ago.

Just because we have not seen a fully compliant company breached doesn't mean that it is not possible. It just means that the bad guys don't need to poke holes in the standard yet because not all companies take it seriously.

Posted by Branden Williams at 1:30 PM | Permalink | Comments (0)

You've probably seen the story by now... it's out there. Here is one link, and you can likely find MANY others.

Here's my question. If they are taking them off the list versus leaving them under review, are they saying that they never should have been certified in the first place? And if they are saying that, doesn't this mean they are declaring shenanigans on the review by the QSA of record? Do I sense a trickle down effect here?

Posted by Branden Williams at 9:00 AM | Permalink | Comments (0)

I know, it seems rare when we find it. I would have been hauled off along time ago and locked in the loony bin if I had stopped down every insane security discussion I was having by screaming SERENITY NOW!

I spoke with a retailer this morning that started a conversation with "We do security in an unconventional way."

At this point, my finger is moving toward the giant eject button I carry with me for situations just like this. Think about the "Easy Button," but instead of easy, it says EJECT and flies me far, far away.

Then the individual surprises me and says, "We treat our network as compromised instead of trusted, and adjust our security practices and posture accordingly."

. . .

YES! FINALLY someone gets it! Retail networks should NOT be trusted. Remember the example I often use about how hard it is to get into the corporate headquarters, let alone the corporate data center, versus only needing a crowbar (sometimes not even that) to get into a retail store location. Why do people inherently trust networks that they manage, but obviously have little to no control over?

If you are retailer, you should hire a company to break into your store locations to see what all could walk out the door. Maybe even up to and including the whole breaking and entering part (sans bodily harm). The benefit of what you will learn about your environment would have to be worth the $40K for an assessment, and some money for repairs.

Thank goodness for some serenity this morning; I needed it.

Posted by Branden Williams at 7:06 AM | Permalink | Comments (0)

Uh oh, is he really going to go there?

No way... he can't go there!

YES! HE IS GOING THERE!

One thing that cracks me up about reading blogs on PCI is the massive amount of individuals who have no idea what they are talking about. Just like that vendor that you run into at RSA that says "I SOLVE ALL PCI PROBLEMS! I AM A SILVER BULLET," there are those out in the blogosphere that throw out claims without substance and pure drivel. Some even do it so well that the media will run with the claim. Like the so called "second processor breach" of last month. Actually, that makes me laugh more!

There have been people that argue that PCI is too strict and impossible to implement. Then you have those that argue that PCI is not strict enough, and encryption must be deployed everywhere. Then you have the folks that say that PCI is just plain wrong, and you should implement XYZ Standard or ABC Technology instead.

They are all wrong. PCI is neither too strict, nor too weak. It is not plain wrong, and it is probably better than XYZ Standard or ABC Technology when taken by itself.

The real problem with PCI is the lack of a feedback loop. Don't worry baby birds... I will feed you.

There are three public examples of companies validated as PCI Compliant by a QSA that have been subsequently breached. In two of the three cases, the timing suggests that the breach either occurred before or was happening while the assessors were on site!

The first thing we can do is blame the breached party. If you assume all PCI Assessments are equal and done according to the Council's standards (hint: they are not), then we assume that the only logical explanation is that the breached party changed something. QSAs should not have any blame if the company being assessed does something to change their compliance posture after an assessment. Assessments are essentially a rolling snapshot (for you camera buffs, think of it as a Vertical-travel Focal Plane Shutter operating at high speed... it's never fully open), and are only reliable past the initial review by a QSA if the controls are maintained.

But then you say, what about the QSA? We've been on record saying that we've never seen a PCI breach investigation that finds the entity compliant at the time of the breach. So if the entity was not compliant at the time of the breach, and the breach has either already happened, or happening while the QSA is on-site, why was it not found? Shouldn't the QSA be at fault?

Maybe. "But wait a tick Branden," you say, "if the QSA is at fault, why has the Council not taken action? Clearly QSAs are infallible since there has been no action by the Council!"

Here's where the feedback loop comes into play.

Investigations of breaches are handled by the card brands. Remember, there are three groups at the center of PCI. There is the PCI Council, charged with managing and interpreting the standard, training QSAs, and managing the QSA program; then we have the QSAs, charged with carrying out assessments; and finally the brands, charged with enforcement.

The brands deal with the investigation, work with law enforcement, and review the forensic report to determine how big the breach was, and how to assess fines to the breached entity. Notice I did not mention the Council in there. The Council never sees the forensic report! There is no feedback loop for the entity charged with training and administering the QSA program!

The Council can only rely on the sanitized ROC that is sent in by the QSA, which they may never receive as part of the normal Q/A process. It's then, and only then, where a potential action could come from the Council against the QSA. We've seen two QSAs put into remediation status so far this year, and neither of which were publicly associated with a company that was found to be compliant and then breached (to my knowledge).

In order for the Council to get a better picture of what happened after a breach, they must have access to the forensic examination, the original ROC, and the information used to generate that ROC. Short of sending someone to sit on-site during every assessment, I'm not sure of any other way to determine who went rogue--the QSA or the company being assessed. This is the real problem with PCI.

So, now that I have thrown that out to the masses, what are your thoughts out there in the tubes? Do you agree? Do you have another solution to the problem, or see it differently through your rose colored glasses? If you are one of the lucky ones to go to RSA this year, maybe this is one of the challenges that could be worked on at the Innovation Sandbox! We won't be able to solve the security breach problem, but maybe we can do something about the breach that isn't supposed to happen.

Posted by Branden Williams at 6:30 AM | Permalink | Comments (1)

Sometime over the last two days, the PCI Security Standards Council released their Prioritized Approach guideline for implementing PCI v1.2. Go download it and take a look.

This document is probably useful for a merchant who has never heard of PCI. It details the priority they believe merchants should assign to every PCI Requirement and places them in to one of six buckets. For those merchants and service providers that are currently working through their gaps, or are already compliant, this spreadsheet will probably not be useful.

The danger with this document is it makes sweeping assumptions that every organization is the same, and therefore should prioritize the same. The provided spreadsheet is locked, so if you want to customize it for your organization you must do a select all, copy, and paste into a new document.

Any tools that merchants or service providers use to assist in their remediation planning or execution must be customized to their organization. The tool has a nice framework, but you should not use it out of the box without modifying it to match your organization. It's missing the testing procedures that QSAs use to identify gaps, which is probably something that your teams will want to see to ensure their actions will result in a successful passing assessment.

Something like this should come out of a compliance readiness assessment and mention specific gaps that are found in the environment, with corresponding remediation activities and teams responsible for completing the actions. Regardless, it is worth a look to see if it is something that you can use to assist in your remediation efforts.

VeriSign provides something similar to this. If you are interested in this sheet and want a copy, please shoot me an email and I'll see if I can wrastle the documents out of Levinson & Springfield's hands to send your way!

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

Here's a line you have heard many times--"but wait, don't look at this in black and white. You have to take a risk-based approach." We hear it all the time as a QSA. Sometimes there is a legitimate reason to take a sane, risk-based approach. In fact, the Council tells QSAs that PCI must be applied using a risk-based approach. That allows for some latitude in some areas, but can create problems in others.

Wait... problems? Why problems?

We don't have a single, industry-wide risk model to measure risk. This means that each QSA is empowered to use their discretion on how to measure and accept risk, leading to variance in interpretation and opinion shopping by companies hiring a QSA.

Many companies that are subject to PCI Compliance choose to roll the dice on compliance. As a QSA, I have seen some companies neglect certain controls that ended up making the difference in a breach. Things like log management, intrusion detection, and even more basic controls like vulnerability and patch management. The reason for the neglect is usually lack of resources; be it time or money.

Corporate leaders claim to be risk averse and will tell the Street they manage risk religiously. The truth is, most corporate leaders don't understand how information security plays into the risk equation, therefore they cannot make informed decisions on how to manage risk in that light. In fact, it usually takes something like a breach for corporate leaders to get religion with respect to security.

By then it is too late.

Some QSAs do the exact same thing. If you are a level 1 merchant, and you have two bids for a PCI Assessment at 100K, and two bids at 35K, how are you to choose? Corporate pressures tell you that you need to choose the lowest cost for the service you need. Since there are two bids at the low price, it looks legitimate enough to take the plunge.

So you roll the dice.

Here's what you may not know. Your QSA may be rolling the dice as well! Multiple breaches have occurred in the last two years from companies that had been validated as compliant by a QSA. Again, without speaking directly to those breaches, there has NEVER been a case we investigated where a company was compliant at the time of a breach (with the exception of something like a smash and grab, but those didn't make the news).

If your QSA is phoning most of the assessment in and shows up on site for two to three days to do the entire thing, your QSA is rolling the dice in hopes that you (the assessed company) will do enough to avoid a breach. If you ever reflected upon an assessment and thought to yourself, "Wow, that was surprisingly easy," you might just be the next victim.

My theory on this is as follows: It is probably OK if one of the two parties involved in a PCI Assessment rolls the dice. If a company being assessed does not do a good job of maintaining their compliance, a good QSA review will reveal those gaps. If a merchant is doing all the right things around PCI and has a rock solid security posture, a QSA may dodge a bullet by rolling the dice and doing a half-assed job on the assessment.

Where companies get into trouble is when both the company being assessed, AND the QSA roll the dice at the same time. Depending on the roll, you might be lucky enough to let the risk ride.

In the case of recent breaches, the roll came up Snake Eyes.

Posted by Branden Williams at 6:52 AM | Permalink | Comments (2)

It's official, I was selected as Payment Security Professional of the Year by the Society of Payment Security Professionals!

The Society has gained a ton of momentum in the industry and launched their two excellent certifications, the Certified Payment-card Industry Security Manager (CPISM), and Certified Payment-card Industry Auditor (CPISA). If you are looking to get into this industry, or work for a company subject to PCI compliance and have responsibility for PCI, you should have these certifications.

This training is better than the training that we receive as QSAs for a few reasons, but mainly because it covers a much wider base than just PCI-DSS. Anyone that has heard me speak about the negatives associated with a breach and/or non-compliance has heard me say that PCI is not the scariest thing out there. The training covers those scarier items in addition to the basics of PCI.

Thank YOU to all that nominated me and thank YOU to the board for selecting me! I am extremely flattered to be selected for this award!

Posted by Branden Williams at 10:56 AM | Permalink | Comments (5)

Rick Moy and I sat down at the PCI Community Meeting in Orlando and discussed some of the trends that we see for PCI. While this video was created almost six months ago, the content is still relevant! The audio is a bit low, so you will need to get some headphones or just turn the volume up. There are no mean tricks like a scary zombie screaming or anything, so you should be safe. Just remember, all of your OTHER audio will be much louder too.

Just saying, don't spit out your coffee because Outlook reminded you of something.

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

The first challenge to securing your data (or meeting compliance) is understanding where your data lives. An alarming number of people I speak with in the industry have no idea how bad their problem is because they only know where half of the data lives and goes.

HALF! That is a BIG problem.

Engaging in data flow mapping exercises can be painful. So painful, that you might be forced to look outside your organization for help!

Yes, VeriSign has a service that does this... OK, shameless plug complete.

Where do you start? In an article that I published last year entitled, "Data Flows Made Easy," I detail an adaptation of the Design Structure Matrix that can be used to help map data flows in your organization. The first step you have to take is to interview your teams and figure out if the implementation teams that live in the real world of IT have implemented the same system that the designers that live in their perfectly architected world created.

The one drawback to relying only on interviews is that you are victim to the Garbage In, Garbage Out problem. If you have never gone through this type of exercise before, you can be sure that you will have some inaccuracies.

But, when you have gone through the process and have something like Figure 6 in the article, you should find one of the many DLP vendors that have a data discovery feature in their tool to validate that the diagram is complete. Or, you can engage someone like VeriSign to bring in partners and consultants to do this for you.

Trust, but verify.

If you use the data flow method that I have outlined in the article, you will find that your flows are much easier to maintain, and you will spend less time explaining complex Visio diagrams to auditors. Several top, global retailers have taken the concept and converted all of their data flows into this format. It's the first step in our PCI Program Management offering, but could easily be used in any security or compliance program. It's a two-dimensional matrix that is begging for someone to write a cool front end interface.

Oh, and to those of you that tried to download the latest Herding Cats and got a Forbidden message, I fixed that, and set the SGID bit on the directory so that should never happen again.

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

Evan Schuman of StorefrontBacktalk has a pretty shocking article today. Apparently, the Heartland malware hid in the unallocated file space.

Right on the heels of my last blog post too. Nuts.

Our forensic examiners at VeriSign look for this type of malware during every investigation because it is not a new trick. It surprises me that it was almost missed. Even still, I stand by my original premise which is that the standard (properly implemented) would prevent this. In order to get the malware on there, a software flaw or credential had to be exploited. Both of those vulnerabilities are addressed by PCI-DSS.

What is more troubling is the same noise that came out after the Hannaford breach last year. Bill Homa, their CIO at the time, first said that PCI was not hard enough (seriously?!? If it was harder, do you think there would be more adoption?), and that end to end encryption would have saved the day. On the surface, I disagree.

At this time, banks cannot process encrypted credit card data (PIN Debit may be the only exception). At some point during the many processes that occur in order for money to actually change hands as a result of a credit card transaction, the data must be decrypted. I'm not saying there are not opportunities to increase the security of payment data, or even take large areas of your network out of scope, but just saying that end-to-end encryption is the solution is irresponsible.

Let's take this example that is fictitious, but not so much so that I have not seen this in the field somewhere. Merchant A encrypts everything from the POS Controller to the back office processing. That leaves the POS Terminal to POS Controller link vulnerable, as well as the machine that does the processing to send transactions to the bank. You could not solely rely on encryption to protect you here, you would need to make sure the rest of the standard is properly enforced on those key machines.

Another example, where the POS Terminal to Controller link is encrypted, but nothing past that. It leaves the controller open to attack, especially if it has access to the internet (don't laugh... I have seen that on many occasions).

I understand minimizing the exposure of unencrypted card data, but even with malware combing through memory, that is not something that we should rely on (or that a developer should argue when you are conducting a PCI Assessment).

We should continue to pursue end-to-end encryption solutions because it will make life for Merchants a TON easier, and will boost the overall security inside the payment process. Remember though, if you take away one vulnerability, the bad guys will find another. I predict you will see an increase in the threats against the devices themselves. More skimming devices, and more fake ATMs/PEDs are coming. That's a management and training problem to fix (NOT a technology problem).

I stand by my original point. The standard, properly implemented, could have prevented a breach like this.

Posted by Branden Williams at 9:19 AM | Permalink | Comments (3)

We've got another one in the news. Heartland Payment Systems recently reported a breach that may have affected up to 100 million cards.

That's a lot.

Heartland joins another elite group of companies that suffered a breach, but was also validated as compliant by a QSA. I want to make something very clear in this next paragraph, but before I do, none of the comments here should be tied directly to any incident that has been in the news. We keep our customer lists private unless we get permission to use one as a reference.

There is a big misnomer out there that needs to be cleared up. I've even written about it before in this blog. In our investigations of PCI related breaches, we have NEVER concluded that an affected company was compliant at the time of a breach. PCI Assessments are point-in-time and many companies struggle with keeping it going every day.

Is there a problem with PCI? If there is one, the problem lies in the QSA community (or internal auditors that have not been through something like the CPISA training), not the standard itself. The new QA program aims to fix this, and time will tell if it hits the mark. The only snag I can see there is that virtually every question that is posed to the Council nowadays comes back with a standard answer that looks something like this:

The PCI Council empowers QSAs to make a determination if the stated controls meet the intent of the requirement. It's up to the QSA.

In some cases, this answer is warranted. I've heard of some of the questions they get. Things from "Does X technology meet Requirement 5 (usually from that technology vendor)" to questions that arguably look like free consulting. I do believe the Council has taken such a strong stance against making specific interpretation rulings that there will be room for a QSA to wiggle out of potential liability if they are remarkably good at paperwork.

So, to recap, our experience shows companies that suffer a breach are not compliant with the entire standard at the time of the breach. We should refrain from saying that another PCI Compliant company was breached because the facts show that it just is not true.

Posted by Branden Williams at 6:36 AM | Permalink | Comments (2)

James DeLuccia IV noticed that Discover has officially matched their merchant levels to Visa (sorta). While this is a big step for Discover, I think most will find that they become Level 1 merchants of Visa before they become Level 1 merchants of Discover.

There are exceptions. Some merchants are exclusively Discover. Those merchants will have to double check their levels (if Discover has not already told them they are a Level 1) to see if they have new compliance requirements.

Posted by Branden Williams at 3:42 PM | Permalink | Comments (0)

Greetings all! Join me for a Free Compliance Webcast put on by BrightTALK! I'm one of the featured speakers and will be discussing "Beating PCI in 2009!" You can review the agenda and register here: http://www.brighttalk.com/webcasts/2158/attend. You should also be able to look below this paragraph and log in and register there!

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

The following is a guest post by JD Smith. JD is a Sr. Consultant inside the PCI practice at VeriSign.

PCI DSS 1.2 has several sections that require a security application to be used to satisfy a requirement. Some of these areas are file integrity monitoring, firewalls, encryption, wireless scanners, intrusion detection/intrusion prevention and anti-virus.

All of these areas have several tools available to address the specific requirement. However, what if a merchant needs to keep the budget to a bare minimum? What if there is absolutely no way a merchant is able to purchase several of these solutions straight off the shelf and pay the licensing associated with them without severely impacting the business?

Open-source solutions exist for practically every requirement identified in the DSS. What is open-source? Generally speaking, open-source is considered to be a solution for something is maintained by a community and is typically royalty free.

For instance when it comes to intrusion detection systems, there are open-source tools such as Snort that has matured over time and is known as the gold-standard for IDS. Many front-end analysis tools exist that use the Snort engine (e.g. Squil and BASE).

For merchants that must secure their wireless environments, open-source wireless scanning tools such as NetStumbler, Airsnort, and Kismet have been in the security toolbox of pen-testers for quite a while now.

Merchants who are struggling to find a powerful firewall solution while staying true to open-source should take a look at NetFilter. It runs on a Linux operating system and is able to handle as much traffic as most other expensive solutions.

Another major component of PCI DSS 1.2 is encryption. For solutions around SSL, OpenSSL is the premiere SSL/TLS encryption library. Also, OpenVPN is an open-source VPN solution which is useful for site-to-site VPN creation without having to spend a lot of money on a Cisco or Juniper solution.

Included in encryption would be TrueCrypt for file, folder and disk encryption solutions. It's open source, very flexible and provides extremely robust encryption options for a merchant.

Among other useful tools that a merchant's network security team should use to test the strength of their network is Zenmap for port and host scanning, and Firewalk for checking ACL configurations. Password crackers are useful for the security team to verify that passwords are configured properly. Some useful password tools are Aircrack (for wireless scanning), John the Ripper, and Cain and Abel. A favorite network service password tester of mine is Brutus which tests services such as FTP, Telnet, IMAP, POP3 and others that are sometimes available on a network.

It's important to keep in mind if a merchant chooses to stick to an open-source approach to assist with PCI compliance, the majority of the open-source security tools available only run in a Linux and/or UNIX environment. Therefore, network security staff or consultants need to have familiarity with this kind of environment.

Lastly, all of these tools and many others are discussed conveniently in one place: http://sectools.org/.

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

The following is a guest post by Rob Harvey. Rob is a Consulting Manager inside the PCI practice at VeriSign.

'Tis the season!

Everyone is in the giving mode this time of the year and VISA is no different. VISA announced in the last month a change in the service provider validation levels and reporting. It is also the season for reflecting on the past year and one of the biggest questions we get from our clients is, "Am I a service provider and if so what level do I need to validate against?"

Beginning February 2009, VISA will use a modified two level approach for service providers which I hope will add clarity to the question. See the information on VISA's website.
(http://usa.visa.com/merchants/risk_management/cisp_service_providers.html)

"Am I a service provider?" By definition from VISA, service providers are organizations that process, store, or transmit Visa cardholder data on behalf of Visa clients, merchants, or other service providers. Some examples of service providers are transaction processors, payment gateways, Independent Sales Organizations (ISO) or External Sales Agents (ESA), credit reporting services, customer service functions, plastic card embossing, remittance processing, managed security service providers, and hosting providers.

This past week proved my point that organizations may not realize they are acting as a service provider in addition to their merchant obligations. Management for a L3 merchant (~750,000 annual ecommerce transactions) knew they needed to comply with the PCI DSS but only to submit a questionnaire and quarterly scanning to their acquirer for validation. After further review, they offer payment gateway services to their direct sales consultants (read: independent contractors / merchants).

So, I am a service provider, "What level am I?" VISA offers the following guidance:

• Level 1 - VisaNet processors or any service provider that stores, processes and/or transmits over 300,000 transactions per year
• Level 2 - Any service provider that stores, processes and/or transmits less than 300,000 transactions per year

VISA combined levels 1 and 2 in addition to lowering the amount transactions from million per year to 300,000. This change means that many service providers that could self assess are now elevated to Level 1 status, requiring a full on-site assessment.

If this is a revelation that you were not ready for, drop us a line! We can help!

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

The PCI Security Standards Council recently published translated versions of PCI version 1.2! The Standard is now available in Chinese (Simplified and Traditional), German, French, Italian, Japanese, Portuguese, and Spanish.

Posted by Branden Williams at 12:50 PM | Permalink | Comments (0)

Less than two months after its release, we've seen our first announcement from a company that has become compliant!

I think that companies will find 1.2 easier to comply with when they examine it in detail. Have you performed a gap analysis yet? If not, maybe the downtime around the holidays (as long as it does not impact holiday lockdown!) would be good to review your last ROC and see what changes you may need to make!

Posted by Branden Williams at 2:47 PM | Permalink | Comments (0)

After the year we had in 2007 with PCI related breaches, who would have thought that 2008 would give us more? I mean, after last year, who would have thought that we would see another major breach given the "lessons" we learned?

Um, I did. Fo-sho.

Why? Because early in my career I learned that most executives don't care about problems until they hit close to home. Like right under their nose.

We've seen two instances this year of companies that had validated compliance with a QSA, but were subsequently breached. Without specifically commenting on either of these cases, we have never conducted an investigation of a compromised entity and learned that they were compliant at the time of the breach. I've written about the quality of QSAs and the corporate responsibility, but as Will Smith so eloquently explained, parents just don't understand.

Many retailers are struggling right now. Guess what one of the first programs to get cut will be? YEP! The one that will prevent that breach from actually occuring.

One common theme I am seeing in many of my large retail customers is they seem to think that they will be able to transfer the liability of a breach to their QSA. I worry when I am sitting with a manager of the PCI program and he or she asks what is "passable" or something we can "cobble together for the QSA" knowing that it won't last past the QSA's flight out.

Don't laugh, this has happened multiple times this year. Or if you want to laugh, just giggle silently to yourself while making sure this won't happen to you.

If you are wondering what kind of liability a QSA carries, you can read the publicly available Validation Requirements for Qualified Security Assessors (QSA) v. 1.1. If you are at work and don't want to slip into a post-lunch coma by wading through this, here's the gist of it.

QSAs are liable for improperly performing the assessment, and willfully passing someone that should not be passed. We have to assemble a considerable amount of documentation when doing these assessments to justify our position. If there is ever a review, we have to show how we arrived at our conclusion. If we are unable to, there is where the liability can come into play.

If a merchant hides things and get's lucky because sampling did not find issues known by the merchant, the QSA may or may not have liability here. It depends on the circumstances, and more importantly, the lawyers. None of these clauses have been tested yet (to my knowledge) in a court, but that will change based on the events of 2008.

Regardless, as a merchant, you should not want to ever GET there. Brand damage aside (which I will argue may not be relevant in many cases), the fines that must be paid pale in comparison to the fees you will pay to lawyers and vendors to hastily assemble a compliant and secure solution.

Merchants must own and be responsible for compliance every day of the year. This means actually being compliant, expanding on compliance to become secure, and finally having a program in place to monitor and maintain that compliance 24x7.

Posted by Branden Williams at 7:51 AM | Permalink | Comments (0)

The transition of PABP to PA-DSS looks more complete every day. In the last 24 hours, the PCI Council has posted their validated application list. Many of these applications were grandfathered under various versions of PABP and will have to be reviewed under PA-DSS in the next one to two years.

As of today, 85 payment applications are listed from 55 vendors.

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

Yep, it's been a PCI heavy week. Want me to discuss other topics? T and suggest one!

Last week I sat through the Certified Payment-card Industry Security Manager training here in Dallas. The folks at Aegenis planned it at a hotel that happened to be about 10 minutes from my house, so getting there was easy. There were several bigwigs from the information security and PCI industry there with me in the sold out training, and the industry perspectives were valuable.

If you are not an employee of a QSAC and are looking for a GOOD source of training around PCI, data breach laws, and a detailed look into the payment industry, this training is for you. If you opt for all three days of training, you will be taken through the process first as an auditor, then as a manager. The tests are given on the final day.

For those merchants that have been begging for solid, industry-specific training around PCI, this is where you need to go.

Posted by Branden Williams at 7:37 AM | Permalink | Comments (0)

The PCI Security Standards Council released the new version of the Self Assessment Questionnaires yesterday, as well as a new Navigating PCI-DSS for version 1.2.

Enjoy!

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

The day has come! I can't tell you how many merchants have hounded me for compliance dates outside the US and Canada, and then looked at me like I just told them the sky was red when I could not provide them. Visa, Inc. has formally announced global compliance deadlines (thanks JKA!).

If you are a global retailer, or a retailer not based in the US or Canada, the pressure is now on to become compliant with the PCI Standard! Feel free to reach out to a VeriSign QSA if you need assistance!

Posted by Branden Williams at 11:31 AM | Permalink | Comments (0)

The PCI Security Standards Council posted a document on Data Storage Do's and Don'ts this week. This document does an excellent job breaking down the storage piece of PCI for merchants big and small, but especially for the smaller folks out there.

Now, for all of you out there, don't forget that PCI is NOT just a data storage initiative. Just because you don't store cardholder data does not exempt you from being compliant. That said, locating your data is step one in understanding how you measure up to the PCI Standard. Consequently, it is also step one in VeriSign's PCI Program Management methodology.

How healthy is your compliance program? If it needs work, drop us a line and we'll see how we can help!

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

One major change to PCI version 1.2 is the new requirements and testing procedures for Req. 12.8. 12.8 deals with how merchants and service providers should handle their third parties that can affect the security of cardholder data. The card brands have told us in the past that they would not expect a service provider to prevent a merchant from being compliant, but that the merchant must understand that they will carry the liability for a breach at their service provider's site.

We've seen 12.8 morph considerably from PCI version 1.0 to 1.2. The intent was to help merchants understand how service providers deal with their data, and make sure that they are protected if there is a breach at their service provider. I still believe that the intent is the same, but the language around the requirement and testing procedure has been relaxed slightly, but still points out the liability. This means that you may not have to alter that master services agreement that was originally inked in 1979, but that legal on both sides must be made aware of the stakes involved.

There are a couple of industries that have unique problems as it relates to PCI. One of those industries is the travel industry (shout out to Yvette!). The service providers that they rely on provide some infrastructure (such as common use terminals, or shared ticket counter or gate space) that is virtually unmaintained, and the airports have been unwilling to put any additional support into these systems. Thus, the contracts do not mention anything about data security or PCI, and would not be compliant under PCI 1.1.

Now with PCI 1.2, the travel industry has a way to deal with these common use areas in a manner that does not affect their compliance. Security is still definitely an issue, but this is another one of those issues where you don't want to totally rely on PCI Compliance to keep you breach free.

Posted by Branden Williams at 7:19 AM | Permalink | Comments (0)

Final round of questions from the field!

The first question from this session was "Are end of life operating systems able to be used?" The thing that really worries me about retail is that information security does not seem to be built into the price of goods on the shelf. When someone asks if they are expected to replace hundreds or thousands of devices for PCI Compliance because Microsoft will not support them anymore, I worry more about the overall security of the company. This seems like a reactive approach without any forward strategy, which is unfortunately fairly common.

I understand the business implications here. If your competitors are not doing this, you could face additional price pressures by trying to do the right thing. That said, I am a firm believer in doing the right thing for the best long term growth strategy.

Next couple of questions are arguments of semantics. It also seems that some of the attendees are not fully using the information provided by the Council. There is the Navigating PCI-DSS document that helps with intent, and the FAQ which answers some of the questions that were asked.

Next one was a compliance versus security question. The point made is valid, but with PCI-DSS being applicable to any merchant accepting credit cards regardless of size, you can't expect that the merchant with 100 cards per year is going to jump through the same hoops as a Fortune 500 retailer.

Also, it is a bad idea to spend ten minutes trying to show the Council how smart you are about security. They will remember you, and not necessarily in a good light.

Next question was an excellent point on a potential interpretation of 12.8 that will be giving QSAs a headache. I won't go into it here, but we have to think about intent and use a little common sense.

A question about dates was posed next, but that is answered in the lifecycle document. Also, don't forget, the card brands are the enforcement arm of PCI, not the Council.

Next couple of questions were just minor questions that any QSA should be able to answer.

Then came a merchant that put forth a story about the work he had to do to maintain his business. Again, folks, you've got to build security and compliance into the cost of your product. The one point of his that is valid is that he wants things more prescriptive to avoid variance in QSAs (with applause from a few people at the end). While this is not necessarily achievable, I do think VeriSign might have some solutions for you. If this was you, please email me. We can help you through this on a global scale.

And that concludes the Q/A session!

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

I always enjoy the Q/A sessions that the Council has at these events. I don't know how many sessions I will be able to blog about (we only want the interesting ones anyway), but here's the first bunch of Q/A from this session!

The first question was around segmentation and SANs. I'd never heard the question asked that way, but most SANs by nature are segmented from each other.

The more interesting point here is what constitutes segmentation? So many assessors only consider firewalls a method of segmentation. According to the documentation provided by the council, segmentation can be accomplished in multiple ways--not just by deploying firewalls. QSAs should be looking at the whole solution, not just fixating on a point solution (hey, sound familiar from a remediation perspective?).

Second question was on sampling... another issue that often comes up. The new version of the standard says to use a representative sample (they used to use the term selective sample), but since the samples are not statistically valid, it makes choosing a sample a bit of a gut feel. You will see variance between QSAs here as we all seem to have a different opinion on what constitutes a representative sample.

Then a question was posed on a move to use standardized solutions. The recent push with the standard is to remove specific products and technologies which is the right way to go (by the way, that is called being vendor neutral, not vendor agnostic). The point was really geared towards small companies that may be looking to buy pre-packaged solutions as opposed to designing their own. I feel their pain; vendors often pitch silver bullet solutions that do not work together very well.

The next question was a cleverly disguised sales pitch. Don't do that. Seriously.

Ahh, my nemesis just asked a question. Guess what question he asked? "Can you make a statement that says you don't have to store cardholder data?" It's in there bud, just take a look. I'll re-iterate for you in case you don't want to search:

Merchants are not required to store cardholder data. Every merchant we have worked with has been able to get their acquirers to accept truncated numbers for chargebacks (or other post-settlement operations). I know that people still believe that the associations require merchants to store data because I had a discussion with a CISO on this issue recently. It would be great if you could stop spreading mis-information.

On the other hand, you do make writing this blog interesting...

The next several questions are nothing that has not been answered before, mostly around scope creep issues.

Back to segmentation, and this one was a customer specific question from a QSA! The old "I have a client that..."

So there you have it! Lots of similar questions from the US PCI meeting.

Posted by Branden Williams at 2:23 AM | Permalink | Comments (0)

Greetings folks! Couple of updates in this post.

October's Herding Cats is up and ready for you to read! Pretty soon here I will be setting up a URL where you can download all the published versions of this column regardless of your membership status with the ISSA. Need a little time though baby birds. Until then, members of the ISSA can download the most recent version here. As you can tell, I have been reading a lot of James Patterson recently. Sorry about that.

Also, if you are going to be at the PCI Europe Community Meeting this week, look me up! I'll be wheels down in Brussels on Tuesday in time for the networking session. I am looking forward to meeting more of you this week.

I am transiting through London first, so if you are in London and want to grab a pint, drop me a line!

Posted by Branden Williams at 4:06 PM | Permalink | Comments (0)

Look out merchants, there is a sneaky omission to PCI v1.2 that does not seem to be making any headlines, and I'm wondering if this will just fly under the radar until someone like me stands up and points it out. All the discussion thus far has been around Anti-Virus, Network Segmentation (or lack of a requirement for), WEP, and firewall rules having a six month review (vs. quarterly). But, does anyone remember this little tidbit from the PCI v1.1 when trying to determine the scope of a PCI Assessment?

Any data repositories outside of the authorization and settlement environment where more than 500 thousand account numbers are stored [are in scope].

I've heard that this little loophole has saved many merchants from fines simply because they were able to take some non-compliant processes and get them under this threshold. Don't get me wrong, merchants would be liable for a breach if those non-compliant processes were linked to a breach, but anything below this threshold would technically not be material enough to show up in a Report on Compliance generated by a QSA.

Well, that whole provision is GONE from PCI v1.2. This means that merchants and service providers (small service providers could get hit hard with this) will have to do a better job of 1) defining where their data is, and 2) making those repositories compliant as they could be subject to the review of a QSA. Based on my interaction with customers, I think this is one of the more significant (if not the most significant) changes in the standard that people should worry about.

What do you think?

If you are worried about it, don't forget to ask a VeriSign consultant about our Data Discovery service that can help you map out all of this data (and other non-PCI data) across your enterprise.

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

One of the topics that I often get into discussions with customers is pulling data out of volatile memory (RAM). The argument that is usually made related to insecure RAM storage is, "Well, someone would have to get on the machine and know exactly where to look in memory and it would just not be feasible for someone to do."

My response to this argument is typically something along the lines of "Obscurity is NOT Security." Obscurity is a poor defense against security problems.

It now appears there is evidence of malware that can grab data in memory to the hacker's delight. It's not really rocket science folks; it is actually pretty simple. This technique has legitimate uses in programming, and now that less and less data is being written to disk, the bad guys have modified their techniques to take advantage of volatile memory.

They are doing it by using common debugging software to pull and/or monitor the contents of the running volatile memory. For many merchants, this means that full magnetic stripe data is there for the taking.

Keep in mind, there is not a ton you can do about the majority of POS applications out there. Unless it is receiving the data encrypted, it will probably be in memory un-encrypted or could at least be pieced together while a crypto routine runs. This to me us much more serious than the issue of data sitting in a pagefile. It seems that if you have the ability to distribute the malware, you will get realtime data on a regular basis and won't be looking through snapshots of a pagefile.

Of course, I suppose you could just as easily hook into the routines that write things to disk and capture it there.

Regardless, it looks like the malware is out there. Be sure you are patching your machines and doing solid egress filtering as most of the malware compromises a machine first, then sends data offsite.

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

Just like the rest of you, I couldn't sleep all night. I tossed and turned in anticipation for this glorious day. It was much like being a kid again and waiting for Christmas morning to hurry up and get here so I could open presents!

I jumped out of bed promptly when my alarm went off, got ready for my day and bounded up my stairs to my new office (I've moved my office so that the new kiddo can get the bigger room), plopped myself into my chair and furiously tried to wake up my PC. I unlocked it and browsed over and ...

*sigh* should have slept in. I've been hitting reload every ten seconds since (Grey's Anatomy style).

BUT it is NOW OUT! Yaay!

Click here to see Version 1.2 of the standard and the summary of changes.

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

I wandered over to the PCI-SSC site today and noticed that they have reposted the press release from August 18 reminding everyone that the new version of the standard will be announced TOMORROW.

Thanks for the reminder; I'm pretty sure we all have that date etched into our brains via green laser.

Tease....

Posted by Branden Williams at 11:38 AM | Permalink | Comments (0)

The US PCI Conference is now over, and what a quick two days. There are many changes coming for the new standard, and I'm very excited about talking to you all. We are putting together a webinar to discuss, in detail, the changes that you will be facing. Look for an announcement on that soon.

It was great talking with many of you about the issues that we all face every day. I look forward to talking again soon and helping you build creative solutions to these challenges.

Oh, and a quick tidbit for you all. If you get a business card from a processor, sometimes even when you put it in a blazing fire pit, it will not burn!

Posted by Branden Williams at 6:45 PM | Permalink | Comments (0)

OK, the questions have not been really earth shattering. I'm heading to a customer call in a few, so will not be live blogging the latter half. We do have coverage and I will post anything crazy here shortly.

Posted by Branden Williams at 11:21 AM | Permalink | Comments (0)

We're just reviewing these changes and before hundreds of people queued up at the microphone, the intent of the change is to prevent an "automatic exclusion" of Unix or Mainframe technologies. Looks like Anti-Virus is now a case-by-case basis for review.

My opinion is that ANY desktop computer with access to the internet should have A/V on it as it is at a higher risk for compromise. In some cases there can be exceptions, and technologies like Solidcore and/or Bit9 can be excellent compensating controls.

Posted by Branden Williams at 11:04 AM | Permalink | Comments (0)

Clarification that wireless technologies are defined as any point where you make a jump over air. That could include things like Satellite, Microwave, RFID, WiFi, GSM/GPRS, etc.

This may become problematic for some users as I believe some QSAs have only been focusing on WiFi and Cellular technologies. The only piece that is somewhat left open here is "carrier-based" technologies. Some network links provided by the Telco include jumps across microwave.

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

I'm sitting here in the back of the session where the 1.2 version of the standard is reviewed, and it looks like Network Segmentation is the stop down. After hearing many people state their case on segmentation, I really have to stand behind the Technical Working Group here. I'm not sure how much clearer it could be made. The standard states that:

Without adequate network segmentation (sometimes called a "flat network") the entire network is in scope of the PCI DSS assessment. Network segmentation can be achieved through internal network firewalls, routers with strong access control lists or other technology that restricts access to a particular segment of a network.

The TWG was asked to clarify further and the only comment that was made was "I guess we could tweak it a little."

Be strong TWG. Don't give into peer pressure. The definition is perfectly fine.

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

Are you here? If so, drop me a line! I am here with our PCI Assessment & Remediation Practice Lead, Steve Levinson, and one of our PCI Consulting Managers, Rob Harvey. We'll be manning the VeriSign booth during the networking hours, so please stop by!

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

While the official release does not happen until two weeks from today, many key stakeholders now have a copy of the pre-release version. What can you expect?

You can expect THIS blogger to honor his NDA!

Seriously though, are you ready? Version 1.1 has been around for over two years now (birthday was September 7, 2006), and by now you should have been able to validate as compliant to that version of the standard. If you are still struggling with 1.1, there is good news along with the bad.

The bad news is that in some cases your remediation targets may have shifted slightly in one direction. This will apply to you if you have been doing the absolute bare minimum to comply. VeriSign advises our customers to use PCI as a baseline, and pick certain areas to exceed in so that minor adjustments to the standard will not affect you. I'm pleased to say that our recommendations have been on track.

The good news is that some requirements have been altered to more closely match existing risk management procedures. The bad news here is there is some room for interpretation (as always), that may once again cause some QSAs consternation.

Sorry, I meant to say, cause some QSA's customers consternation.

For those of you heading to the PCI Community Meeting in Orlando next week, please stop by our booth! We'll have a few leaders in our PCI consulting practice available to chat with you!

Posted by Branden Williams at 2:49 PM | Permalink | Comments (0)

Is anyone else still just wondering what exactly this means for your business? The summary does definitely answer a few questions, but I am wondering if someone was pressuring the council to release something, ANYTHING, about the new revision.

One thing that concerns me as a QSA is the amount of variance that will be introduced in the interpretation of some of the clarifications. For example, right off the bat we see the opportunity for interpretation in the clarification under Requirement 1:

Added flexibility in the time frame for review of firewall rules, from quarterly to every 6 months, based on Participating Organization feedback. Now the control can be better customized to the organization's risk management policies.

I hear the caliber of those breach bullets is pretty high.

One of the bigger changes ones that is perfectly laid out is the sunset date for WEP. THANK GOODNESS! Yes, I realize that companies are STILL deploying new WEP installations, but they have no business in any environment where sensitive data exists—meaning storage and transmission of networks missing segmentation. There will now be a requirement to replace all of those devices by June 30, 2010.

Requirement 5 now seems to have more strength in it, but I'll wait to see the testing procedures. I don't believe the council will be requiring A/V on mainframes, but I do believe that other operating systems like Linux and Mac OS X could now come into scope. VeriSign's belief is if it is a desktop operating system with access to the internet (including indirectly through email), it should have some kind of A/V on it.

In Requirement 11, there are so many goodies there that we will just have to wait for the SAP. Internal Penetration Testing is a really fun one that I fear will cause many merchants to have a slight case of freakout (or death-panic as I like to call it). Also, are we getting closer to Wireless IPS in environments where cardholder data exists? I'm getting so excited! It feels like Christmas morning over here.

My favorite change is the one listed under Requirement 7: Clarified language around testing procedures. We'll just have to wait for the new SAP to be released before we can let out that deep breath we're all holding!

Posted by Branden Williams at 4:49 PM | Permalink | Comments (0)

First off, I want to apologize for the lack of posting. Travel across the date line is one of those things that looks like a productivity enhancer, at FIRST. Then the realization slowly sets in.

One of the articles I wanted to post on was Bill Homa (Edit: Sorry, got the spelling wrong!), the former CIO of Hannaford, who is changing his tune a little bit. Apparently, the PCI Standard is not his problem, but now he blames Microsoft for the breach that occurred on his watch.

I don't know if you are like me, but I can't wait for the lawsuits to start flying so that all of the speculation on this incident can end. Legal discovery can be a beautiful thing. As with most major breaches, there is not one giant big goof that you can point your finger to, there tends to be a series of events that lead to the breach.

Maybe Bill can hook up with Dave Hogan from the NRF and they can practice playing the blame game together? I imagine it would go something like this.

"I blame PCI! It's too hard to comply to!" (Dave)

"No, it's not strong enough! If they would have required internal encryption, things would be different!" (Bill)

"Wait, what? Dude, I'm going to have a lot of pissed off members if I say what you said." (Dave)

"Call me dude again, and see what happens!" (Bill)

"I blame PCI! It's not strict enough!" (Dave)

"That's more like it." (Bill)

"No one is listening to me anymore... you try." (Dave)

"I blame Microsoft!" (Bill)

"Ooo, nice one." (Dave)

Or maybe THEN the fun and games can start?

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

No, not my niece, but the great city in Australia! I've finally made it back state side. I'm a little tired, but more so when I start working through the email!

Thanks to everyone who joined our event in Sydney! I hope to talk to you all in the coming months.

Posted by Branden Williams at 1:44 PM | Permalink | Comments (0)

We've been true road warriors this week, and so far have done briefings in Brisbane and Melbourne, Australia! We are heading back to Sydney tonight to do our last PCI briefing of the trip tomorrow. Thanks for the hospitality Brisbane & Melbourne! I look forward to seeing you again soon!

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

I have to admit, I needed some coffee and cobweb remover to decode this message from the Council this morning. They posted their Lifecycle Statement on the standard yesterday. After reading it a few times (and having a cuppa), I believe what they are trying to say is that there will be a new version of the PCI-DSS every 24 months. If you see a major number incremented (say 2.0 from 1.X), it is considered a new version. If a minor number is incremented (say 1.1 to 1.2) it is a revision. Regardless, you still have to do it and you will have some amount of time to implement.

The next revision is due out on October 1, 2008 and will be version 1.2.

To whomever drafted this document, will you please read William Zinsser's On Writing Well, and Paula Larocque's The Book on Writing -- The Ultimate Guide to Writing Well. Seriously guys, simplify your writing. There are many non-native speakers trying to digest this stuff, and I guarantee the first sentence in that release has them so confused that many just tossed it aside.

Posted by Branden Williams at 7:17 AM | Permalink | Comments (0)

Thanks to everyone at EUCI and their great hospitality in Vail. I'm looking forward to working with some of you soon!

Posted by Branden Williams at 6:40 PM | Permalink | Comments (0)

The PCI landscape is pretty scary out there. If you are a merchant or service provider that is looking for assistance, there is a long line of companies that are ready to help. What should you expect from your QSA? What should your assessment look like to get the best results?

VeriSign reviewed our findings from our customers and wrote a white paper entitled, "Not All QSAs Are Created Equal: What You Should Know Before You Buy" that talk about what you should expect. This paper is a FREE download! Go check it out!

Posted by Branden Williams at 12:11 PM | Permalink | Comments (0)

About a month ago an audio guy showed up to my house and pinned a tiny microphone to my shirt for a podcast on PCI. It is a joint podcast with John Pescatore of Gartner. The theme is on managing PCI Compliance.

Go check it out!

Posted by Branden Williams at 7:46 AM | Permalink | Comments (0)

I was asked this question while sitting on a panel at RSA, and I think the answer depends on your perspective. I'll answer this from a security industry perspective.

If nothing else, you have to credit PCI with forcing the issue. Security among retail enterprises was generally limited to loss prevention and physical security until recently. Information security usually existed as a small and buried team within the Information Technology group, and did not have board level attention. If someone at the board was savvy enough to realize that security reporting to IT is an example of the fox guarding the hen house, then maybe they moved security into Internal Audit.

Now we are seeing a massive amount of development in security and compliance programs. Where companies had a staff of two or three to handle this, they now have large, global teams to deal with this. PCI forced the issue, then higher ups started asking questions about HIPAA, GLBA, and others.

Security teams now report into the office of the CFO, or Legal, and in many cases have their own seat on the board. Budgets are opening up, and money is being spent. Without fail, more issues are found while every stone is turned over to see what bugs lie beneath.

Poetic, don't you think?

The next test is to see if the strategy component has been handled such that you can sustain the support to the organization, and avoid bureaucratic bloat. PCI can't get you there, only good old security process will.

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

Your QSA may not be telling you the whole story.

No, I'm not talking about sloppy assessment work. What I'm referring to is a clause that is supposed to be in your contract with your QSA. The DSS Validation Requirements for Qualified Security Assessors requires that QSAs put a notification in their contracts with their customers telling them that the ROC and supporting materials can be disclosed (Section A.6.3 in the doc linked above). Why does that language need to be in the contract? Because the QSA agrees to send the ROC to certain parties per the operating agreement!

In a recent competitive bid situation, we were informed that two (of four) bidders DID NOT have such language in their contracts! This means that the QSA has a choice. They can either breach the agreement they have with the Council, thus quickly getting them delisted as a QSA. Or, they will breach YOUR contract and send the info along without your consent!

I am surprised that QSAs are doing this, and wondering what their intentions are. If nothing else, if you get a contract without that clause in there, what does that say for the quality of the assessment you will receive?

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

If you had any action on the Vegas odds for the release of the next DSS and what it might be called, time to cash in. I was speculating that it would occur around the time of the conference this year, and it would have been called 1.2 (vs 2.0).

Ahh, you win some, and you lose some.

The official release is here, and hints that there may be some new requirements coming down the pipe. They typically give 18-24 months to implement, so no need to panic now. But watch out for more controls around wireless!

Posted by Branden Williams at 2:10 PM | Permalink | Comments (0)

Well? Will you?

We're waiting!??

Hopefully your bank is not taking THAT approach to checking on your status, but I know many merchants are feeling the heat. Jaikumar Vijayan from Computer World writes that when this deadline passes, most people will not be in compliance. If you read the letter of the law, yes, I would agree. But based on the guidance released by the council, if you are compliant with the rest of the standard, there is a pretty good chance you are compliant with 6.6.

In this clarification, The Council declared the intent of the code review component to include "Manual web application security vulnerability assessment" and "Proper use of automated web application security vulnerability assessment (scanning) tools." So essentially if you are getting something like VeriSign's Premium Vulnerability Management Service, you meet this requirement. You could also count your penetration test as long as the application has not changed since that penetration test was performed, and it covers the entire application with manual interaction. VeriSign's Penetration Testing services DO cover this.

There will be some merchants that do not meet the requirement; but those merchants have likely been doing just the bare minimum, or "Managing Checkmarks," as opposed to building a sound security infrastructure and fitting compliance inside it. Merchants doing that are probably not fully compliant on any given day anyway.

Posted by Branden Williams at 7:52 AM | Permalink | Comments (0)

Do you wonder if the consultants that your QSAC sends on-site are actually QSAs? Well now you can check! For some reason, all of VeriSign's QSAs don't appear in this list, but we're diligently working to correct that. I can only imagine the large QSACs are probably flooding Cathy with email right now.

Posted by Branden Williams at 7:14 AM | Permalink | Comments (0)

One of the arguments for becoming PCI compliant is to keep this an industry regulated certification, versus having to deal with a federal mandate like Sarbanes-Oxley. People often ask me if I think PCI will become a federal mandate. I don't think it is possible.

Most federal mandates are designed to protect their citizens (I said MOST... ok?). The electronic payment system already has mandates to protect the citizens. For example, did you know that the Fair Credit Billing Act limits your liability to $50 for unauthorized charges? Personal experience says $0 liability if the physical card is still in your possession.

PCI is designed to minimize losses to issuers and the brands caused by a credit card breach and instill confidence in the payment system. As an important side effect, it promotes information security inside retailers and reduces the losses that would be associated with a breach of their systems (potential brand damage, fines, and consulting fees).

Since the citizens are already protected, and breaches do not directly affect the money system (they affect companies), I don't believe the federal government will get involved. We've seen a state governments pass legislation, but it is still untested in the courts and I have doubts on its ability to be enforced. Keep in mind, credit card fraud is not the same as identity theft, and I believe we will see much more legislation on that in the future.

Posted by Branden Williams at 12:33 PM | Permalink | Comments (0)

The PCI Security Standards Council released a statement yesterday defending the PCI-DSS against claims that the standard is not strict enough and will not protect against common attacks. This is the first real communication we've gotten from the council since the announcement of the Hannaford breach earlier this year.

This statement is the first to be released to try and counter the negative press from Hannaford telling the world that they were compliant with PCI. This was the first breach of a Level 1 merchant that had validated compliance through a QSA. After reading the statement from the council, vague as it is, merchants should feel better about their PCI programs.

The PCI DSS, if properly implemented on a merchant or service providers' network, provides the security controls necessary to prevent hackers from penetrating a payment environment and installing malicious software that would jeopardize the protection of card data as it is being processed.

So does that mean that PCI DSS was not properly implemented at Hannaford? If it was not properly implemented, how would they have passed a QSA's PCI assessment? Maybe the new Q/A program at the council will address something like this, but then again, maybe it is all up to interpretation?

Posted by Branden Williams at 11:29 AM | Permalink | Comments (0)

I'm going to aggregate several PCI related things here in one post as it has been a busy week in PCI Land! I have other things I want to write about, so stay tuned for more stuff later today and throughout the week.

First off, the Council has released the Payment Application Data Security Standard (PA-DSS). This replaces Visa's Payment Application Best Practices program, and your Point Of Sale application should comply by July 2010, or your customers may not be able to accept Visa cards! Nothing we did not already know, but it is now finally released.

Next, the Council also released clarifications on Requirements 6.6 and 11.3 (apparently a very hotly debated topic in a recent QSA Requalification class). There are two very important issues to pull out of the clarification.

On Requirement 11.3 (annual penetration test), the clarification makes mention that the penetration test should also include an on-site (or internal) penetration attempt. This will drive the cost of these assessments up a bit, but I think there is some room for innovation. Just depends how risk-averse a company really is.

The real doozy is on Requirement 6.6 (periodic code review or web application firewall on all web-facing apps). There really appears to be overlap here now. In lieu of a code review or web app firewall, the Council has elaborated on how the intent of a code review can be carried out. They say that a "Manual web application security vulnerability assessment and/or proper use of automated web application security vulnerability assessment (scanning) tools" can be used in lieu of an actual code review.

In a normal application penetration test that VeriSign performs, we already would perform the above. Does that mean if you get a Penetration Test by VeriSign that you automatically comply with both 11.3 and 6.6? If we take the guidance of the Council, it does.

I was disappointed by the 6.6 clarification as it does not seem to have legs any more. VeriSign typically recommends that a code review be performed as part of your PCI strategy. We believe that you should fix the problem at the source (pun intended) instead of trying to put another filter in-line. Passive web application firewalls have their place in any sound security strategy, but the fact remains that the most effective way to remove the threat of these vulnerabilities is to fix the problem in the code.

As an example, during a recent code review we performed, we found several vulnerabilities that could be exploited that would not be caught through an automated tool, and yet could be exploited remotely. When you are working with the code, you don't need to manage the mask of the interface.

In other news, Visa released a bulletin on packet sniffing cardholder data, no doubt in response to a recent breach. VeriSign has often recommended using encryption over the wire to help reduce insider threats. Visa echoes that strategy in the recommended mitigation section.

OK, enough PCI for today!

Posted by Branden Williams at 7:13 AM | Permalink | Comments (0)

Phillip Hallam-Baker commented recently on my post about the NRF, but specifically added to the chip and pin point. Thanks Phillip!

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

While others at VeriSign are headed to ETA, I took the opportunity to speak about PCI to the OpenTravel Advisory Forum in Atlanta today. A shout out to an excellent group of individuals that are in one of the more difficult industries with respect to PCI (the other being Fuel Dispensing). Thanks for the hospitality!

Posted by Branden Williams at 7:50 PM | Permalink | Comments (0)

It appears that the PCI-SSC has finally released the new Payment Application Data Security Standard! You can read all about it here.

Posted by Branden Williams at 5:25 PM | Permalink | Comments (0)

Clement James writes about a security expert that slams PCI, stating that the breach in the news "was almost certainly the work of hackers exploiting a single code flaw on internal systems." The expert goes on to say that "PCI takes a relaxed attitude towards internal machines."

While I agree that there is room for improvement on internal controls for PCI, remember, it's not designed to protect your entire enterprise. It is a basline, and you should layer security on top.

The challenge is this. Not until the end of last year did we see a compliance validation rate exceeding 60% among Level 1 merchants. If you make the standard too hard, you will have little or no adoption. You have to wait until you have enough momentum to add more security into it, but you will always have stragglers. The adoption rate would be easily less than 25% if there were more standards on internal encryption or device security.

Posted by Branden Williams at 1:13 PM | Permalink | Comments (0)

Uh oh, look out world, here comes some new fangled technology!

Well, not that new.

But VERY new for the PCI Industry! The PCI-SSC has put RSS on their website! They now have a feed for News & Events which can be picked up at https://www.pcisecuritystandards.org/pcissc_news.xml.

The card associations that make up the PCI-SSC should take note. Currently, the preferred method of communication for all five members is reviewing their security websites. Unfortunately, it is pretty hard to see what changes unless some kind of alert is posted (and one association actually changed the URL that is listed in the QSA training we receive without a forward). VeriSign suggested RSS a while back as a good way to keep people informed to changes in the program. Hopefully the power of RSS will be addicting, and all the associations will start pushing updates that way.

Go subscribe today!

Posted by Branden Williams at 11:08 AM | Permalink | Comments (0)

The PCI Security Standards Council looks as if they have released that FAQ they have been working on! I can tell you that this is a huge relief for everyone involved (merchants, service providers, QSAs, ASVs, etc.) as the volume of questions that the council was dealing with prevented them from turning around answers quickly.

Course, quickly is a relative term.

But consider their position. Here at VeriSign, we might submit 1 question every couple of months, but other QSAs may submit more. For every question that VeriSign (or any QSA) submits, they must get buy in on the answer from all 5 members before it can be turned around. You can see how this can easily take days or weeks to get answers turned around if you are getting any significant volume per day (say 10 questions per day).

So now that the common ones are up there, this should allow the more challenging interpretation requests to be processed quickly.

Posted by Branden Williams at 1:43 PM | Permalink | Comments (0)

The PCI Security Standards Council has released the long awaited version 1.1 of the Self Assessment Questionnaire (or should I say questionnaires). The key thing here is that the validation requirements are different depending on the type of merchant you are. There are now 4 versions of the questionnaire as opposed to 1, and they do map to the current PCI 1.1 standards.

I think I assume that the intent is to keep the SAQ mirrored to the current version of the standards from now on, so we should see them updated this year if the standards are updated as planned. In addition, during the webinar call we asked if PA-DSS is still on track, and the response was "Yes," it should still be released this quarter. We're looking forward to that!

Posted by Branden Williams at 12:42 AM | Permalink | Comments (0)

In Mike Dahn's PCI Answers blog, a post was made over the break about the Secure hashing of PANs

As this blogger has said on many occasions before, hashing is a double edged sword.

Theoretically, you could create a hash that is as secure as a CipherText from an encryption algorithm. If you used a 10 kilobit salt (effectively the Key) plus the PAN, you would have something quite secure and would not run into issues with collisions. The problem is that you cannot change your keys without retaining the original PAN. If you did change your key, new hashes of the same PAN would not match old hashes.

Perhaps the biggest issue, people treat hashes differently then they do CipherText. Hashes are seen as "non-real values that cannot be reversed." Unfortunately, you can subvert the complex math by building rainbow tables. Something we don't see is symmetric encrypted values thrown around an organization in the same manner. Why? Just attitudes on treating certain data in certain ways I think.

If you could solve the key change issue, plus keep hashed computations secure like you would CipherText, then maybe we can make an apples to apples comparison.

Posted by Branden Williams at 12:38 PM | Permalink | Comments (0)

Visa just released slides from a webinar on Automatic Fuel Dispensers (AFDs) as it relates to skimming. Looking at the pictures they included, this is something we all could easily be victims of as there do not appear to be any external signs that you are becoming a victim of foul play (thanks Shane!).

AFDs are notorious for having these kinds of issues simply because there is not someone watching over them like a cashier does at a traditional Point of Sale (POS). We've seen examples of this occurring in ATMs as well. Not only is this a call to duty for AFD manufacturers to become compliant with PED and PA-DSS standards, but it is a call for merchants using these devices to enhance training and field checks to prevent this type of fraud.

Posted by Branden Williams at 7:55 PM | Permalink | Comments (0)

Just got back from London (and I feel fantastic!), and they are really taking an interest in PCI. I found it very interesting that many of the Big 4 are still heavily involved in providing advice about PCI even though they are not Qualified Security Assessment Companies. The funny thing is that the UK seems to be where the US was about three years ago. Still in the discovery phase, and not a ton of C-level attention yet. Until Visa, Inc. puts something like the Compliance Acceleration Program in place over there, it will likely have a very slow adoption rate.

Hopefully Visa will give people at least 24 months notice, and the banks will over-communicate with their merchants so there is not a huge panic 6 months before the deadline.

Posted by Branden Williams at 4:09 PM | Permalink | Comments (0)

Yep, more PCI posts.

Visa has just released their new Payment Application Security Mandates which give a new timeline for merchants to use PABP (or now PA-DSS) validates payment applications. If you are using a third party application and it is not validated by July 1, 2010, you will likely be subject to fines by your acquirer.

There are other items leading up to that, but this is the big one for most merchants.

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

We've all heard speculation, and even speeches where we were told this was coming, but it is now finally one step closer to reality. Today, the PCI Security Standards Council announced the Payment Application Data Security Standard, and its intention to release the new standard by Q1 of 2008. Unfortunately, to my knowledge the PA-DSS is not quite out of draft form yet, and is still sitting with the Members. Once it is clear of that review process, I hope that QSAs will be given an advance copy like we were of the proposed questionnaire. While we are prohibited in sharing the documents with our customers, we can speak to their makeup and how it might affect our them.

Stay tune for more information as it is released!

Posted by Branden Williams at 7:19 AM | Permalink | Comments (0)

PCI-SSC has now announced Italian translations!

Posted by Branden Williams at 6:17 PM | Permalink | Comments (0)

A Visa informational release Friday revealed that 65% of Level 1 merchants have now validated their PCI compliance. This is really no big surprise based on the acceleration program (CAP) that was put into place in December of last year. The message to the remaining 35% is pretty clear.

You are now in the minority.

While I am sure those merchants affected by PCI are well aware of their compliance programs, this may be that final driver to get top level buy in so that projects are appropriately funded and tracked. Most companies we work with have plans, but no support.

Let's go to compliance!

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

The card associations are sternly scolding non-compliant merchants this year, and the attention around PCI related issues has never been greater. Why is it so hard to comply? Surely merchants have some level of security around their customer data, otherwise there would be a compromise every week. Is it technology? Is it cost? Or is it just a lack of motivation from the top down to wrap up these compliance projects?

This year, we released a paper that reviewed 60 Reports On Compliance from 50 of our customers over a 15 month period. What surprised us was that what we perceived as one of the easiest requirements to meet--PCI Req 11.2, perform quarterly scans internally & externally--was the TOP failure! Why would something that is such a relatively easy process cause the most failure among our customers?

This issue has a relatively simple fix in our minds, though we also validated common industry buzz on items that are not. Logging and encryption continue to cripple companies pushing towards PCI compliance. Both of these issues require well thought out strategies that must encompass the entire enterprise to fully implement. Point solutions rarely if ever work in the long term, and their nature tends to cause short term gains to turn into long term costs.

Inside this paper, we explore many of these issues, and provide free tips on how to make smart decisions on becoming compliant with the PCI Data Security Standards without breaking the bank. Any company that is affected by PCI can take this paper to their organization for practical ideas on how to reduce the impact PCI has on their business.

Download this paper here!

Posted by Branden Williams at 2:55 PM | Permalink | Comments (0)

In a website posting yesterday, Visa clarified on their Merchants page the requirements around quarterly network scans. From their site....

The Quarterly Network Security Scan is an automated tool that checks systems for vulnerabilities. It conducts a non-intrusive scan to remotely review networks and Web applications based in the externally-facing Internet Protocol (IP) address provided by the merchant. Acquirers are responsible for ensuring that the quarterly network security scans required of their levels 1, 2, and 3 merchants are performed by an Approved Scanning Vendor. The Quarterly Network Security Scan is applicable to merchants with externally-facing IP addresses as specified by their acquirer. Quarterly Network Security Scans are not required of merchants that do not have externally-facing IP addresses.

We've had some questions around quarterly scans recently, so thanks for the clarification!

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

Two weeks ago, we released our recent study on why companies are failing PCI. We based our report findings on 60 recent PCI assessments involving 50 different large companies. Since then, there have been multiple media outlets that have picked up and commented on the report. One in particular I'd like to review is an article by TechTarget (which interestingly enough, now has a new title).

When Keith Gosselin of the Biddeford Savings Bank in Maine was told that our report showed that nearly half of the companies are failing requirement 11.2 (quarterly scanning), he stated, "It surprises me how high that number is." I think this was a big shocker for us as well, but after letting the shock wear off, we created a couple of hypotheses around why this is failing.

1) Companies fail this because they are doing quarterly scanning, but are not scanning until they receive a clean scan (as required by PCI Requirement 11.2). Having an automated process run is pretty easy to do, but you also must remediate and rescan. Many of our customers did not close the loop.

2) Companies are not properly scanning internal systems. When we started this process many years ago, it was typically out of the IT or Security groups. Now we are working for the office of the CFO in most cases. Back then, most companies had at least 1 guy who could get a halfway consistent Nessus engine running. Today it seems priorities have changed, but someone forgot to set up an outsourced partner to do this. VeriSign currently partners with Qualys to perform this service (both internal and external scanning).

The other thing he mentioned was that he was shocked companies did not understand their data flows. Until recently, PCI has had a much more reactive and tactical effect on our customers. Now that some companies have seen the light and understand this type of compliance requires a programmatical approach, they are beginning to get to the root of the problem--the data. They know they have to find it, and then secure it. Surprisingly enough, it is a rarity that a payment system in a company is so simple that someone knows it from start to finish. I can think of a couple of examples out of the hundreds we have done. Knowing where your data lives is something I've discussed before, and will continue to be a struggle for companies as they grow.

My favorite comments in this article are from Roger Nebel, Director of Strategic Security for a consulting firm in DC. He states that the report doesn't always account for some critical differences and inter-relationships between a threat, a vulnerability, and an asset, all of which result in some level of risk.

Yep, you hit the nail on the head!

I do want to make a slight correction, however. The perceived problem is not with the report, but with the standard. In fact, there was a gentleman at the recent PCI Community Meeting with specific feedback for the council on creating a quantifiable method to calculate risk. While I seriously doubt that the council will want to create such policy around the standards, it is a valid point for those folks who are focused on doing the absolute minimum. The absolute minimum is sometimes a reality, but for those folks that complain that PCI is a moving target, I suggest they might want to strive for something north of the minimum so they are not continually chasing compliance like a cat chases a mouse.

Finally, Nebel took issue with our finding that clients who passed requirement 6 of PCI DSS still have applications at risk. My thoughts on this is that he was either mis-quoted, or he is not familiar with the PCI DSS. Specifically, if you look at the current version of PCI, requirement 6.5 lists the former OWASP Top 10. This year, OWASP released an updated version of the Top 10 which is still just a subset of the total number of application vulnerabilities that you might be able to find on any given day.

Granted, I think Nebel's point is that if you have a super-sexy Software Development Life-Cycle (SDLC), you should not have application vulnerabilities in the first place. PCI does not require, nor does it address fully, something like that. It just requires that security is baked into the SDLC, and it does not account for human error. After all, we are all people running this process. You can detail it all day, but that does not prevent someone from inserting some cryptic looking code that opens up a vulnerability.

PCI is trying to build a baseline, and baselines are good, but do not eliminate risk. Even if you take a conservative view on the standards, you still have risk in your applications if you fully meet requirement 6. Maybe that's another story for another time.

(Note, some sections of this post were taken from the TechTarget article to provide a common ground for comments. The full article for your reference is available at http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1273153,00.html.)

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

In an effort to continue to boost compliance, Visa USA is now publishing a report that details their merchant compliance by level. According to my contacts inside Visa USA, this list will be updated on a monthly basis. We are all expecting the numbers of compliant Level 1 & 2 merchants to increase as fine deadlines approach.

Posted by Branden Williams at 12:01 PM | Permalink | Comments (0)

The PCI-SSC announced today (ok, the date says Tuesday, but it was not posted until this morning) that they are adding PIN Entry Device (PED) security requirements into their domain of responsibility.

Posted by Branden Williams at 1:23 PM | Permalink | Comments (0)

Late last night (well for me in Central time), Visa posted a new brief on their CISP website regarding eliminating the storage of prohibited cardholder data. Essentially, this is just another data brief explaining how to look for and remove prohibited data. Prohibited data as defined by the PCI Data Security Standards, Requirement 3.2, includes such things as CVV/CVC Data (as found in the magnetic stripe of the card), CVV2/CVC2/CAV2/CID (3 or 4 digit code in the signature panel or front of the card), and the PIN or PIN Block. According to the brief, there has been a number of compromises recently where prohibited data was stored.

For more strategies on eliminating cardholder data, please read my paper entitled "More Strategies for Eliminiating Cardholder Data".

Posted by Branden Williams at 5:05 PM | Permalink | Comments (0)

I had a customer ask me if they had to make the Administrator account/password comply with Requirement 8 of the PCI Standards. Requirement 8 deals with assigning a unique ID to each person with computer access to those systems dealing with cardholder data. Specifically, no generic or shared accounts should be used--especially those that are administrators!

The answer is YES, they must comply with the requirements. What does that mean from an operational standpoint?

We see customers attack this from various angles. For those corporate systems, they are typically just disabling the Administrator account, and putting special alerting in place to see if it is ever used (as in something bad is happening, go deploy the calvary).

In the case that you have a non-directory setup, things become much more painful. You are essentially looking at deploying a password escrow type service where no one person knows the password, only the system does. Passwords would then be checked in and out, and either stored in a secured area (think like a vault) with appropriate logging. Essentially, if someone uses that account, you want to be able to prove which individual used it since the logs will just say "Administrator" or "root."

More than half of the customers we deal with have directory services deployed to all systems, albeit in many cases multiple directory services. In one case, a customer standardized completely on Active Directory and RACF. All Unix variants pointed back to LDAP via Active Directory.

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

For our VERY FIRST installment of "What Do Other Companies Do" (WDOCD), Randy Smith has asked the following:

"What specifications do other companies require for Secure Tape Destruction (especially for older tapes that could have pre-encryption account number data). To my understanding PCI does not provide a specification.

Do you feel that standard is OK to relax when all the account number data is encrypted?"

Excellent question Randy! Virtually every company we work with has some sort of destruction policy for media, and it varies from using a bulk eraser, to pulling out the DeWalt and drilling a hole right through it (yes, one company we have done work for does exactly this after a bulk erase), to enlisting a third party media destruction firm, to transferring the media back to the manufacturer for analysis and destruction. A quick search on YouTube will show you many more creative methods to destroy these devices (though not recommended by this humble security consultant).

Specific to PCI, the only destruction standards mentioned are ISO standards that have nothing to do with destruction at all. Slight oversight that we hope will be corrected soon.

What is actually required is some method to destroy the data or media such that the data cannot be recovered. Small tape strips are minor risk, but incineration or shredding seems to be the best method to ensure the data is not recoverable.

For tapes where the account number is encrypted, I do believe a relaxed method would be appropriate. In fact, if you filled a FedEx truck with tapes of encrypted data, and then left it in the open for people to take those tapes, you would not be required under state laws (today) to notify the affected individuals! The card associations might take a different view of this of course.

The answer: For unencrypted tapes, be sure you do a very thorough degaussing before taking them to your vendor for physical destruction. This will ensure that any leftover fragments will not have any data on them to recover. For encrypted tapes, shredding with 3 to 6" tape strips left over should be acceptable.

Thanks for the question Randy! For your time, keep your eyes open for a little gift from us!

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

Well they are finally done! The PCI Security Standards Council has released the Spanish and Portuguese versions of the PCI Standards and Security Auditing Procedures.

Visit https://www.pcisecuritystandards.org/tech/supporting_documents.htm for more info!

Posted by Branden Williams at 9:24 AM | Permalink | Comments (0)

Greetings folks. My new article entitles "More Strategies for Eliminating Cardholder Data" has now been published on the VeriSign website. This is an expansion of my previous article which primarily relied on Hashing. Based on clarifications from the card associations, hashing is not a silver bullet (do you know of any that are?) and hashed data is still considered cardholder data. The real risk is that rainbow tables can be created if someone knows how the hash is created. Since the keyspace is so small, the rainbow table creation is rapid.

This article expands that and takes a more holistic approach to data elimination and talks about many other strategies. It does not address the culture shift question that someone pointed out to me at an ISSA Meeting in Dallas yesterday, but that is for another time.

Posted by Branden Williams at 12:15 PM | Permalink | Comments (0)

eWeek is reporting that Visa has announced it is relaxing the fine and fee deadline of September 30th.

Essentially, what this means for non-compliant merchants is that the proposed interchange rate hikes are lessened to simply say that non-compliant merchants will not be eligible for the "best available" tiered interchange rates. However, non-compliant retailers are still facing costs potentially in the millions by not being able to qualify for lower rates during the ever important holiday shopping season.

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