NetSPI Imformation Security Consulting
NetSPI Blog

Posts Tagged ‘PCI Community Meeting’

What’s New in PCI DSS 2.0 – No Surprise That There Are No Surprises

| Friday, September 24th, 2010

Some of the team from NetSPI spent the week in sunny Orlando at the 2010 PCI North American Community Meeting.  As most are aware, this year’s meeting was particularly significant as a new version of the Data Security Standard, 2.0, which has now been released and effective as of 1/2011. The new standard is so advanced that it went from 1.2.1 to 2.0, incorporating a 0.7.9′s worth of changes in a single revision(!).

The last few days’ sessions were a great opportunity to review the changes with the SSC and card brand representatives, catch up with others in the industry, and dispel rumors about the new DSS version (there will be no Requirement 13 mandating the use of ninjas to protect cardholder data, and Ouija boards cannot be used for wireless access point discovery).   It should also be noted (if my wife is reading this), there was absolutely no beer consumed at Kook’s Sports Bar and all discussions were reasoned, civil discourses that ended promptly at 9:00 PM to allow for a full night’s sleep.

As far as the changes to the DSS, it should come as no surprise that there were not many surprises to be found.  As was pointed out several times throughout the course of our sessions, the DSS is a mature framework with a rising adoption rate throughout the world; major changes could have serious financial and operational repercussions on merchants and service providers who have already incorporated the DSS into their environments.  Keeping that in mind, the intent of v2.0 is to provide additional guidance and clarification based on the (apparently) thousands of communications that the SSC received in response to their request for feedback, and my first impression is that it succeeds in that respect.  Below are some of the highlights I picked up on from the meeting and SSC-supplied docs, in no particular order: 

  • Clarification that PAN is the primary element for applicability of the DSS to a merchant/service provider environment and is the definition of ‘cardholder data’
  • Sampling requirements will be more detailed, and will require more justification as to why the sampling methodology used for an assessment is considered sufficient
  • There are clarifications for issuers that have a business need to store sensitive authentication data (SAD), which should provide more specific guidelines for retention and protection of SAD
  • Additional requirements to secure PAN if hashing and truncation are used in the same environment, to reduce the possibility of malicious users reconstructing full account numbers
  • At this point, an automated or DLP-type solution is NOT required for data discovery and scoping of the cardholder data environment, though tools of this nature can/should be used where appropriate
  • “System components” now includes virtual systems in the definition
  • Requirement 6 has been overhauled to merge internal and web applications, and “industry best practices” no longer means just “OWASP”, and includes SANS, CIRT, CWE, etc.
  • News flash- two passwords are not considered “2-factor”. Glad we got that one clarified.
  • Requirement 11 allows for physical site inspection for rogue AP discovery if appropriate. I can’t see this working well in a large physical environment, but may work for mom-and-pop retailers who can see every wire on their router. I can’t wait for my first opportunity to write a comment for 11.1 that includes “Bob, the IT guy, climbs through air ducts and drop ceilings on a quarterly basis to identify potential rogue APs”
  • IDS/IPS must be included at the perimeter of the cardholder data environment and ‘key points’, as opposed to monitoring all traffic in an environment
  • There was some discussion around a new SAQ C that would be applicable to ‘virtual terminal’ environments. This is a work in progress, and I didn’t hear an official release date

There are many other tweaks not included above, but no real game-changers in my opinion. I know not everyone will be happy with all of the revisions, but the DSS is by its nature a compromise between global applicability for all types of environments and nuts-and-bolts implementation.  There will still be requirements that have QSAs and clients scratching their heads, but my impressions are that many of the clarifications are long overdue and should make many of the requirements easier to interpret, test, and enforce.  Ninjas will just have to wait for version 3; be sure to get your feedback in early.

Permalink | Email the Author | No Comments

Maturity and Convergence at the PCI-SSC Community Meeting

| Monday, September 28th, 2009

I attended the PCI-SSC community meeting this past week (September 22-24). There were three key issues discussed that showed that the PCI program is maturing and that a number of standards and regulations are converging (both in and outside the PCI world).

The first issue signaled that the council’s view of IT risk is maturing. Bob Russo made it very clear in a couple of his presentations that organizations need to focus on security as opposed to just compliance, although there wasn’t a lot of detail offered on how to do this. The presentations mainly focused on ensuring that complying with the PCI standard is a year-round activity/program and not something just done for the audit. I’d argue that moving from compliance to security is a philosophical shift that occurs when organizations mature in how they deal with IT and business risk. Generally, the financial services organizations within the PCI community get this. It’s interesting to note that the driver for the council’s new views appears to be the very public breaches that have occurred within PCI-covered organizations over the past 18 months. So, the council has felt the impact. The key question is how the council will help the greater PCI community understand and mature their approach to IT and business risk.

The second, closely related topic was the focus on moving to more of a risk-based approach to implementing the PCI DSS. The council was only lukewarm to this idea, and I agree with their hesitation. Managing a risk-based approach may be something that is incorporated over time, but it adds too much subjectivity to the current PCI program. I think that until more organizations fully and truly implement PCI, such an approach will only muddy the waters. That said, incorporating risk as a consideration is important to an organization’s compliance efforts. As I mentioned above, I think the most pertinent issue is to get PCI-covered organizations to understand IT risk and how it translates into risk to their business. While assessors and many of the banks understand this, some merchants are still a ways off in getting to this level of maturity.

The final and much broader issue related to general standards. The council has always relied on NIST as a guideline, but this year there was much more discussion surrounding NIST, FISMA, and future regulations that will impact PCI. In the keynote, former Congressman Tom Davis discussed the process of passing FISMA. His prediction was that any new information security legislation was not going to happen in the near term. Nonetheless, there appears to be a converging consensus on the value of the existing FISMA and NIST standards. The nuclear power industry, NERC, and a number of the ISACs are strongly considering moves and potentially longer-term mandates that use these federal standards as their direct basis. Ultimately, I think it is very likely that many organizations will use significant portions of these federal standards as their basis. This could be both good and bad and is much easier said than done, but simplification and consistency should help all industries and information security in general.

Overall, the conference was a good barometer on the maturity of the PCI community and I think that, although there have been issues, the program is moving in the right direction.

Permalink | Email the Author | No Comments