More Observations from the PCI SSC North America Community Meeting

[Our good friend Joe Tinucci also attended the Community Meeting and shares with us his impressions of this year's program. –gaw]

I also was privileged to attend the PCI SSC Community Meeting in Vancouver. As with last year's meeting there were several trends that were apparent, both explicitly stated in the sessions and, equally important, discussed at the networking events and on the trade show floor.  Here is a summary of the major trends that I heard at the meeting:

Risk, Risk, Risk

The entire first day of the meeting was devoted to updates from the Council, virtually all of them focusing on risk and risk management.  This theme has carried over from last year, and I assume that it will carry forward to future years.  Using a risk management-based approach it becomes easier for merchants to prioritize what to do first and where to concentrate their scarce resources.  It also makes it easier to incorporate risk avoidance into ordinary business practices.

One major risk that came up repeatedly was third party service providers. It was noted that approximately 1/3 of retail breaches were due to third party vulnerabilities.  Remote access by vendors to merchant systems is particularly problematic; there are standard practices that should be in place to prevent vendors from accessing merchant systems any more often than is strictly necessary.

One excellent resource for managing third parties was the Responsibility Matrix found in the Council's Third-Party Assurance Information Supplement (https://www.pcisecuritystandards.org/documents/PCI_DSS_V3.0_Third_Party_Security_Assurance.pdf).  Not only does this document provide a framework for assessing the risks of third parties, but also a framework for negotiating the legal responsibilities of each party.  I highly recommend that you download and use this document to help provide the structure for your third party management program.

Collaboration

Another theme was collaboration.  I think it indicates an interest on the part of the Council to expand their purview so as to bring in additional revenues and resources, and to also work with other associations, interest groups, governmental agencies, and rule-making bodies to cooperatively secure payments. Sharing of information, whether officially sanctioned through ISACs or other mechanisms, is one of the few ways that the good guys can stay current with what the bad guys are doing.

Incident Response

There was a lot of discussion of incident response.  The Council recently issued a supplemental guide, Responding to a Data Breach (https://www.pcisecuritystandards.org/documents/PCI_SSC_PFI_Guidance.pdf) that can serve as a checklist or guide to building your incident response program.  The guide's theme of "Preparing for the Worst is the Best Defense" was repeated in multiple presentations.  Prepare now to see more requirements surrounding this area in future versions of the standard.  And, if you haven't yet done so, you should consider holding a "tabletop" incident response exercise just to make sure that you have identified the key players that need to be part of your IR team and that they play well together.

Segmentation

Another recurring theme was segmentation – of your cardholder data environment, of course, but also as applied to other environments.  Segmentation is a major scope-reduction tool for PCI DSS compliance.  The newest version of the DSS has an increased emphasis on this topic, particularly validation that your segmentation is working as intended – both from inside and outside the network segment.  There was discussion of assurance for your segmentation efforts – internal and external vulnerability scans as well as penetration testing to assure that portions of the network that are supposed to be isolated from the rest of the network / Internet truly are isolated and remain that way.  This is one area that will receive even more attention going forward; if not through more requirements then from your QSA / ISAs.

Being Compliant Does NOT Equal Being Secure

Over and over and over, just about every speaker repeated the mantra that being compliant does not mean that you are actually secure.  This is partly to guard against the checklist mentality of compliance, where you do stuff only in order to be able to check the box against the compliance checklist.  But it was also to remind people that we aren't infallible – we might be compliant at this particular instant in time but the opportunity to get out of compliance presents itself with the next AV update, new machine added to the network, or vendor software upgrade.  Most of the breached merchants in the last few years considered themselves compliant – but apparently not secure.  Hence, the continuing emphasis in the DSS on "Compliance as Business as Usual".  Look for there to be a new direction in future versions of the standard around the associated processes that keep a merchant compliant – change management, software upgrades, log creation and review, equipment inspection, and so forth.

P2PE

It appears that we are finally seeing the emergence of Point-to-Point Encryption (P2PE) solutions for merchants.  This can be another effective way to reduce the scope of your CDE, particularly when used with tokenization.  There are two routes for a vendor to follow when creating a P2PE solution for merchants: validated or unvalidated.  In a validated solution, the vendor integrates validated P2PE applications as components in their larger system, has their solution validated by a QSA specializing in P2PE, and then pays the Council to be listed on the validated solutions website.  (Similarly for validated applications.)  With the upgrade of the P2PE standard to version 2, validated components can now be used by merchants to "roll their own" solution.  One benefit of using a validated P2PE solution, or creating your own system from validated components, is that it makes the merchant independent of their acquiring bank; that is, they can move their merchant account to a different acquirer without junking their P2PE system.

Many acquiring banks have a P2PE solution available to their merchants that may not be listed by the Council as validated, but which is equally well vetted by a P2PE QSA.  The advantage to the acquirer of this route is that their merchants are more closely tied to them and less able to switch acquirers without starting over with another P2PE solution.  The advantage to the merchant is that – assuming they do their due diligence with their acquirer to ensure that the offered solution is properly secure and meets their needs – the recommended solution may cost less than a validated one and may be more closely integrated with the acquirer.

As noted in Mike's posting, I also was enamored with Vancouver – what a lovely city!  Even the weather cooperated to produce picture-perfect days.  The only thing that marred the stay was that I often found myself apologizing (mostly to taxi drivers and waitresses) for being from such a backward country that didn't issue credit cards with chips...  (More on that topic in another posting.)

---

Joseph D. Tinucci recently moved from the University of Colorado Treasury to Coalfire Systems, Inc., a Colorado-based IT Security Audit and Consulting firm.  At CU Joe managed the PCI DSS compliance program for over 175 merchants across four campuses.  Now he is helping clients manage their compliance programs from the other side of the desk; he notes that it is a refreshing change of pace and duties to be on the "illuminating side"...

Joe can be reached by email to joseph.tinucci@coalfire.com

The 2015 PCI SSC North America Community Meeting

[Mike Leach sent in this terrific summary of his time at the PCI Security Standards Council's North America Community Meeting, held last week in Vancouver, British Columbia, Canada. I wasn't able to attend this year, so thanks Mike! --gaw]

We wrapped up the PCI SSC North American Community Meeting in Vancouver, BC last week. Before I review a few key points of the meeting I want to highlight our host city: Vancouver, BC is a fantastic city! The streets are pedestrian friendly and clean, the people are friendly, the downtown is alive and vibrant after 5. I even stumbled into a shooting set for Minority Report on an evening walk. Then the waterfront and harbor called to us every day, making it hard to go back into meeting sessions. I recommend Vancouver as a vacation destination. I will be back.

This year Indiana University, Michigan State, North Carolina State, Oklahoma State, Penn State and University of the Pacific were represented as well as the British contingent: University of Surrey, University of Manchester and the University of Leicester. If I overlooked any Higher Ed schools I'm sorry we missed you at the meeting.

The theme this year was Educate, Empower, Protect. As a between-standards year much of the content was review and reinforcement of known topics. Building on PCI as Business as Usual the Council reiterated its focus on providing guidance and content for Small and Medium Businesses (Hey, that's us!).

To do that they are using a 4 pronged approach:

1. Establishing a SMB task force
2. Highlighting the QIR program
3. Encouraging us to develop Acquirer relationships
4. (The Council) Deepening relationships with Merchant Associations

There will also be a refreshed website with a preview offered here: http://communitypreview.pcisecuritystandards.org/

Another sub-theme was collaboration. We know the bad guys are sharing info and learning as a community. We need to do the same. As IU's Ruth Harpool reminded General Manager for the PCI Security Standards Council, Stephen Orfei, Higher Ed knows collaboration. This is one of our strengths we need to continue to leverage so none of us are left behind. When schools write to the PCI listserv with questions, please offer up your answers or experience. If you don't feel comfortable discussing with the larger group reply privately. Continue to ask and share.

Keynote speaker John Nance related his experiences in aviation and healthcare to information security. Humans are the weakest link. By admitting we will fail we can plan for failure and be ready to respond to failures.  John also supports the call for collaboration. Collaboration without a common goal is just disparate groups trying to cooperate.

Several presentations covered the importance of P2PE and Tokenization. We are starting to see more validated solutions listed. These two services provide real card data security and scope reduction. However in speaking with merchants who have started down this path some acquirers are trying to squeeze all merchants into a category that doesn't fit well. A complete implementation will take some time and planning so start now. Caesars Entertainment reviewed their 3 year project to implement P2PE at all 37 properties in 14 states.

Keynote Brian Krebs highlighted some of his adventures in learning and writing about card markets and ATM skimmers. His prediction for US EMV adoption is that we will see growth in new card/account fraud because so much of our US personal data is out there, unlike other countries with more strict privacy laws or less electronic personal data available. http://krebsonsecurity.com/

Those are just some of the highlights. Please see the Council's meeting blog site for more meeting coverage: http://events.pcisecuritystandards.org/2015/blog

Next year's North American meeting will be September 20-22 at the Mirage, Las Vegas, Nevada.
Thank you,
Mike Leach

---

Mike Leach is a System and Network Security Analyst in the Office of Information Systems at The Pennsylvania State University. As a primary function of that job he has been managing the PCI compliance program for nine years. PSU has successfully bridged the IT-Finance/Treasury gap and in cooperation with the Office of Corporate Controller Mike oversees 55 merchant areas using some 150 merchant IDs across 24 campus locations.

Mike Leach can be reached by using the Contact Form in this site’s sidebar.