Saturday, September 29, 2012

Some Good Advice for Merchants

Visa released some interesting documents this week.  You might want to have a look at one or all of them:


  • Here is a link to merchant training Visa offers.  The current session is for franchises, but there may be some good information there for others, too.  Visa usually posts the slides from these sessions online, so you can always check back later to see what you missed.
  • The Security Tips for Retailers is valuable for understanding what is cardholder data and how to avoid storing sensitive authentication data like the security codes.  It reinforces the maxim: if you don't need it, don't keep it.  Good advice.
  • Perhaps the most valuable is Visa's ecommerce tips and best practices for small merchants.  The PCI Council's ecommerce Special Interest Group (SIG) has completed its work, and that report should be available later this fall.  In the meantime, have a look at this document.  


Lastly, there is a good article featuring Branden Williams (there is a link to his blog on the right) that is worth reading.  He addresses particular practices for card-present or brick-and-mortar merchants.  You can read it here.


Friday, September 7, 2012

PCI Council on Mobile, EMV, ecommerce, and Listening

There is a very good interview at BankinfoSecurity where Bob Russo (PCI Council General Manager) and Mike Mitchell (PCI Council Chairman) address initiatives and objectives for the Council and the standards in the coming year.

Many of you have heard Bob Russo speak at PCI Workshops or other public forums.  I got to meet Mike Mitchell earlier this year when we sat down to talk at RSA.  With the PCI Community Meeting coming up next week, the interview tells me several things.  First, mobile payment solutions rank high on the Council's agenda.  This is no surprise, and with the speed of merchant adoption across the merchant spectrum (including many of your campuses, whether you wanted it or not!) it is welcome news.  They also cite Point-to-Point Encryption (P2PE), which is my personal favorite technology that can reshape completely the merchant compliance framework.

Next week is what I call the "feedback" meeting.  The Special Interest Groups (SIGs) will report on their recommendations.  I will pay a lot of attention to the Cloud SIG in particular.  The ecommerce SIG will report its findings, too (and yes, that'll be me up there for my 15 minutes of PCI fame).  I feel our final report, which should be ready this fall, will be valuable for higher ed institutions.

For it to be successful, the feedback meeting has to also be the listening meeting.  Everyone should be encouraged by the detail the PCI Council provided on each individual piece of feedback they received.  Really: the report was 66 pages long!  Participating Organizations got to see every comment, and they got to see the Council's decision: e.g., whether it was accepted for current consideration, not accepted, or postponed for later consideration.  Every person may not have agreed with every decision, but at least everyone who commented knows they were heard.  It doesn't get much better than that.

Speaking of listening, I'm looking forward to the Associations breakout session.  That is where associations like NACUBO that represent industry segments get together with PCI Council staff and the card brands.  The rules of the game are that much of the content of the Council meetings and deliberations (including the Association meeting) are confidential...what goes on in Orlando stays in Orlando, I guess.  Therefore a lot of the discussions are not fair game for posting in blogs like this.  To the extent there are things to report, I'll be writing more from Orlando.

Meanwhile, surf over to the interview with Bob and Mike.

Thursday, September 6, 2012

Feedback on PCI DSS and PA-DSS v2

The PCI Council issued a press release summarizing the feedback on the current versions of PCI DSS and PA-DSS.   Recall that PCI follows a three-year lifecycle, and we are in the middle of the feedback period, Period 6.  The Council will cover the feedback at next week's Community Meeting, which I will attend.

Here are some of the highlights based on my perspective:

  • The vast majority of feedback pertained to PCI DSS vs. PA-DSS.  Feedback came from a range of Participating Organizations (POs), QSAs and ASVs.  Quite a lot of the feedback seemed to come, not surprisingly, from assessors.
  • Based on the press release some of the main areas for comment are
    • Revising the Self-Assessment Questionnaires (SAQs).  Some commented they are too complicated (I assume they mean the qualifying criteria), but others pointed out additional requirements that may be needed.
    • Clarifying who is a Service Provider under PCI DSS Requirement 12.8.  Huh!?!  What is it about "you can affect the security of the transaction" that you don't understand?  
    • Scoping.  Let's all agree this is one of my hobby horses.  I most recently wrote about it here and here.  Hopefully there will a good discussion of this topic next week.  Based on the feedback, more guidance is still needed.
    • Cleaning up the password requirements in PCI DSS Requirement 8.5.  I really agree with this one meriting a fresh look since the level of detail seems too much for many organizations.  We'll see what happens.
    • Determining what constitutes a "significant change" that triggers the need for a re-scan or even a new penetration test (PCI DSS Requirement 11.2).  Anytime we use imprecise terms like "significant," it is a double-edged sword: it offers flexibility, but it can be abused.  
For another take, have a look at Branden Williams' blog post on this same topic.

I noted that this feedback is Phase 6.  The next two phases involve drafting proposed revisions to the two standards (Phase 7), and then the final review (Phase 8).

Thanks to all who forwarded your feedback to Tom Davis and me.  We'll report back to you after -- and likely during -- next weeks Community Meeting...aka, PCI Woodstock...

Wednesday, September 5, 2012

Preparing for Your First Security Breach

I recommend you take a few minutes to read this post about preparing for your first security breach by Conrad Constantine at Alien Vault.  He offers some good, personal advice that probably is not in your Incident Response Plan (you do have an IR plan, right???).

Some of my favorite recommendations he makes are:
Before anything else, no matter what field you work in during times of crisis you will see everyone's true colors brought forth - not least of which - your own. You will know more about yourself and your co-workers after the event than you ever did before.
[Senior executives] are going to require fast and decisive answers from you - welcome to their world - you will be asked to make quick assessments of the information you have available and be held accountable for them afterwards. 
Your first responsibility will be to create a complete and detailed timeline. [Note: I completely agree with this recommendation!]
Things are going to get a little crazy, requests become orders and niceties fall to the wayside.
 And maybe my favorite line:
In this day and age, it is an accepted truth that all organizations will be breached at some point - what is important is how you handle it.  
I am not a data breach expert, but I have been involved in a couple of breach or suspected breach situations.  The thing to remember are that nobody is going to be able to think clearly, so have a good plan.  Then develop your detailed timeline, document it, and maintain your sanity as best as you can.  Even if you are only on the periphery, events and people can get strange.

Read the article and maybe put a copy with your IR plan -- you are likely to need both at the same time.
  
  

PCI DSS Scoping Toolkit is Released

One of the most difficult and important tasks in any PCI DSS compliance assessment or gap analysis is determining your PCI scope.  That is, identifying which processes, networks, and systems are in scope for PCI compliance.  If you underestimate your scope and miss things, you put your institution at risk for a damaging and expensive data breach.  If you overestimate your scope, you may consume unnecessary amounts of money and resources.

Recognizing the importance of properly determining PCI scope, the PCI Council established a Scoping SIG in 2009.  Full disclosure: I was a member of that SIG although I played only a minor part.  While that SIG never issued its final report, the participants did a lot of good work.  Some of the SIG's insights I've shared with clients on occasion, but the report was never released.

Some of the members of the SIG have now released what they are calling the Open PCI Scoping Toolkit.  The Open Scoping Framework Group states:
The Toolkit includes a set of principles, a structured thinking process and tools to generate defensible and consistent scoping conclusions, regardless of who is performing the PCI evaluation or assessment. In the absence of such a tool, or unambiguous guidance released by the PCI Security Standards Council, questionable scoping decisions will continue to be made.
In the future, we will be expand upon the Toolkit, and present its application to some of the toughest PCI scoping scenarios, along with our suggested scoping conclusions. These include hotel front desk networks that include POS systems and guest PCs, order entry systems running on thin clients in retail stores, virtualized servers processing cardholder data, and ActiveDirectory systems providing authentication to systems processing cardholder data.
We expect that practitioners will use the Toolkit to make scoping decisions, with a level of consistency and precision that has eluded the community to date. We believe the Toolkit to be consistent with the spirit and intent of the PCI DSS.
You can also check out my StorefrontBacktalk column this week for a personal take on the toolkit.  I'll let you surf over there (no registration required) rather than repeat myself here.

Please know this Scoping Toolkit is not endorsed by the PCI Council.  However, whether you agree or disagree with the approach, I suggest you consider it as you assess your institution's own PCI scope.