« February 2009 | Main | April 2009 »

March 31, 2009

Review of PCI Congressional Hearing

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.

How a Little Push can put you into a Freefall

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.

March 30, 2009

Guest Post: Compliant Compromise

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

March 26, 2009

Hello Chicago!!

I'm sitting in the Starbucks (a.k.a., my mobile office with thousands of locations world wide) on Ohio and State in Chicago preparing for our event this evening. I am moderating a round table discussion with some prominent industry experts around PCI, one of which is the venerable security pundit Anton Chuvakin. If you have a minute, please go read his recent post from his panel in Denver last night. He posed a very interesting question that I think we will be posing to our audience tonight!

Check it out!

March 25, 2009

Don't forget to Vote!

The Bloggers at RSA are doing awards this year! The Social Security Awards need your nominations. Your nominations are due by March 31, so go vote now!

As a reminder, what you need to do to vote is as follows. Go to the link above, then click Next. Under the Most Entertaining Security Blog, put my name, the url (http://blogs.verisign.com/securityconvergence/) and that you think I'm WACKY!

NEWS FLASH: Visa Lists Dates

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

March 23, 2009

May have to pick up a new hobby...

From the greatness of xkcd.com.


RSA Scholarship!

Were you planning on returning to RSA this year but were caught in a RIF? RSA wants to help!

They recently announced a scholarship opportunity targeting unemployed security practitioners that have recently attended the RSA conference. In order to receive this scholarship, you must:

  • Be an information security professional (practitioner, security architect or similar role);
  • Have attended the 2007 or 2008 RSA Conference as a full conference delegate;
  • Complete a 1000 character explanation on "Why I need to attend RSA Conference 2009"; and
  • Complete a 750 character biography

Thankfully, no video submissions are required.

For more info, go here: http://www.rsaconference.com/2009/us/scholarship.htm.

March 20, 2009

Check out my interview on the Imperva Podcast!

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

March 19, 2009

What SHOULD Keep You Up At Night

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!

March 17, 2009

Companies need PCI++ (not just PCI) to be safe!

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.

March 16, 2009

PCI Validated, But Not Secure: Real-Life Stories of a PCI QSA

Did you miss the webcast? No worries, the good folks at Imperva now have an archived copy to review! You can check it out here.

March 13, 2009

NEWS FLASH: RBS WorldPay and Heartland Dropped from CISP Compliant List

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?

March 12, 2009

Sanity DOES Exist!

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.

March 10, 2009

Time to get caught up!

I've been lazy lately. Well, not lazy, just busy. I forgot to put up links to the Feb edition of Herding Cats! This one is entitled, Cloud Computing is Heavy, where I throw a little spin on the security of Cloud Computing. Fun stuff.

Also, look for an upcoming surprise in the next issue of the ISSA Journal!

March 6, 2009

The Problem with PCI

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.

March 4, 2009

PCI Council releases Prioritized Approach for v1.2

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!

March 2, 2009

Funny how??!

I'm too tall to even come close to pulling off Joe Pesci. So just think about the scene in Goodfellas where Tommy DeVito is pulling Henry Hill's leg in the restaurant.

How am I funny?!

Anyway, if you are looking at my blog and you see a little badge on the upper right with a link to the Social Security Award and are wondering what that funny business is, I'll tell ya! The Security Blogger Meet-Up at RSA is coming soon, and they are going to have some awards this year! There are five awards that will be given out. They are:

  • Best Security Podcast - Who is the voice you listen to week after week?
  • Best Technical Security Blog - Who is digging deeper than anyone else?
  • Best Corporate Security Blog - Which vendor's contributing the most to the blogosphere?
  • Best Non-Technical Security Blog - Who's got the best 30,000 view?
  • Most Entertaining Security Blog - Who keeps you riveted? Or who makes you laugh?

So, if you think I am funny, follow the directions at http://www.socialsecurityawards.com/ and tell them! Or if you think I am totally un-funny, tell them that too! You don't have to vote for every category, but if you have the time and can think of a blogger to put in every one, consider throwing that blogger a virtual bone by voting for him or her!