Payment Card Security & IT Controls Explained

The payment card industry security standards council released a publication today providing paths for organizations to take to satisfy the PCI DSS v1.1 Requirement 6.6. As has been consistent, the council has recognized that confusion existed and parties were addressing this mandate in an inefficient and in some cases ineffective manner. The council provides several options for addressing the risks defined in the standard. These options include:

• Application Code Reviews - (not necessarily MANUAL all the time), and can be achieved through any of these approaches:
  • Manual reviews (granted not possible on proprietary systems)
  • Automated Source Code Scanners
  • Manual Web Application Vulnerability Assessment
  • Automated Web App Scanners
  • Independence and qualification of individuals performing effort (internal or external) remains necessary
  • Integration of these controls should occur and are nicely described in the clarification document (Page 3)
  • Highlighted in the “Additional Considerations” section on Page 6 and 7 there is an important note that not all alerts are cause for non-compliance and some deployments of web applications (use of cookies, unusual headers, etc..) may require an experienced individual to ascertain which are threats and which are not to the organization.
• Application Firewalls (WAF) - defined as a technology that inspects that packets and hence inputs crossing from an untrusted to trusted environment. In the PCI SSC own words:
  • “…designed to inspect, evaluate, and react to the parts of an Internet Protocol (IP) message (packet) consumed by web applications, and therefore public applications frequently receive uninspected input.” (Page 4)

• The council is not advocating extra or redundant controls, but is ensuring that the packets are inspected. To this point they have highlighted that OTHER means of accomplishing and mitigating this risk are available such that “IT packet content adequately inspected (i.e., providing equivalent protection) by network firewalls, proxies, and other components do not have to be RE-INSPECTED by a WAF”.
• Page 5 has a few nice succinct bullets to describe the necessary functionality and inspection protocols highlighted (but certainly not forever set in stone) that must be included in Option 2 WAF.

A great document with lots of specifics to clear the air. Far superior than the information that was available after the ETA conference. There are some nice “Sources of Information” without links, so I have provided those to accelerate your efforts and research:

• OWASP Top Ten
• OWASP Countermeasures Reference
• OWASP Application Security FAQ
• Build Security In (Dept. of Homeland Security, National Cyber Security Division)
• Web Application Vulnerability Scanners (National Institute of Standards and Technology)
• Web Application Firewall Evaluation Criteria (Web Application Security Consortium)

As always - add comments to enhance and improve our community and the controls under discussion.

Best,

James DeLuccia

Additional References:

• IT Compliance and Controls - specific best practices that focus on these risks (my most recent publication)
• NIST SP800-64 Revision 1 - Security considerations in an SDLC
• FFIEC Workbook - SDLC

Those seeking to satisfy section 11.3 of the PCI DSS 1.1 have been provided new information on this requirement.  The publication is in line with other existing best practices and keeps the line of reasonableness and security firmly in place.  All organizations should review this important update.  It is a short 4 pages.  As is my style, a bit of highlights and analysis below.

A few key points:

• Any internal or external party may conduct these evaluations - with a few reasonable qualifiers:
  • The individuals have experience conducting these engagements
  • The parties are independent (organizationally or from an external vendor).  This is dead in line with the much praised IIA Professional Standards guidance on independence.
• Prudence in how these engagements are conducted is expected - i.e. conduct these pentests against the important systems, during approved time frames, and provide sufficient information to the pentester to ensure that the intent of the effort is satisfied (black vs. white testing)
• The Scope of the pentest should include, “All locations of cardholder
• data, all key applications that store, process, or transmit cardholder data, all key network
• connections, and all key access points should be included.”
• The frequency of these engagements should be at least annually (minimal requirement), and should be conducted with greater regularity based on the changes in the environment - i.e. switching from a hardware based network to a virtual network would be considered significant and require a penetration test)

As always, consider best practices, understand the intent, and apply appropriate controls for your own organization.

Best,

James DeLuccia

UPDATE:  New Article on OFFICIAL Documents released by PCI SSC 4/22/08

This week was a banner week in PCI DSS clarifications, interpreted confusion by third parties, and varied levels of agreement and discontent. At this time the clarification that was distributed at this year’s ETA conference (which is a very good conference for those seeking a full understanding of the payment process industry), but has not been published by the PCI SSC. That did not prevent nCircle from providing us a snippet. Please check here to read their full post. Instead of simply repeating what they have posted, or promote the update and create more noise let me provide a few business impacts on how this affects your business today.

The update provides, as has been the case in other parts of the standard, many forms of controls that may be embraced to satisfy the control. What should be noted is that the clarification reinforces the need to meet the intent outlined in the standard, and a simple least practice mentality is insufficient. Businesses should consider a rotation of controls defined by the PCI SSC. Meaning that organizations should consider a SDLC that embraces the following process:

1. Develop a common code base library - ala, develop chunks of code and get them manually tested against development best practices. Then certify these (internally) and lock the code. Re-use this code wherever appropriate. I have seen this practice embraced by many firms and achieve 80% reductions in roll-outs of new products (they developed online payment sites), and lowered their error-detection rate (any vulnerability identified during application level testing at or above a medium threat level)
2. Identify and contract a third party for manual evaluations - Third parties provide fresh eyes to any project, and can bring to bear many resources (humans, experience, and applications) to any engagement. Depending on the development rate of “new” systems I would advise having these done once a year with medium development efforts and greater as development efforts increase.
3. Automation - Invest in an automated tool that is best for the type of evaluations and have these occur regularly (weekly on critical systems; monthly on medium risk). These applications cannot replace the capabilities and attacks evaluated by a manual engagement, but they can provide an excellent stop gap to prevent excessive deterioration in risk management.

As in any update, read the official release and realize the intent. These mandates are in place to prevent fraud and bolster confidence in the credit transactions.

Thank you to those who have posted on this subject, and please add to the conversation!

James DeLuccia IV

Back in Atlanta after a week in San Francisco for RSA’s annual conference on security.  This being my first year in attendance I have no comparison from prior years, but have heard that the crowds were a bit lighter than usual.  I spent a great deal of time enjoying the sessions, speaking privately with the incredible roster of speakers in the “speakers lounge”, and engaging the vendors in the expo.  Overall I would definitely say it was worth the time and expense.  Anyone looking at shortlisting their conference list should include RSA next year.  Of course, you make your own conference - I actively sought and engaged experts in areas, and methodically evaluated each solution offered by the vendors.  As in any good project I attended with several objectives and action items that proved extremely valuable:

• First, I vetted the speakers and the sessions prior to arriving.  This is key to determine the type of presenter and their prior experience (i.e.  I prefer to avoid “sales” people giving presentations on areas where their product “happens” to address).  I prefer to seek out either the founders (engineers) of companies who play in a space, in-field practitioners, or those who have such a broad range of experience they can speak on a specific topic.
• Second, I set three objectives for attending - any more and you are stretching yourself to thin and won’t enjoy the experience.  Mine for RSA this year were to:
  • Identify and map each vendor solution into a solutions matrix based on architecture and core controls for the top 50 regulation / standards.
  • Seek out practitioners who have successfully established frameworks or governance structures in global corporations
  • Identify trends from the strategic perspective.

My takeaways from the conference were a disproportionate focus of vendors on DLP, a lack of comfort in practitioners dealing with multiple regulations, and a steady and unexpected level of confusion in addressing PCI.

This year RSA is posting the recordings of the sessions online for post-conference viewing.  Now other conferences in the past year have made these available for the public and hopefully they will follow suit.  In any case, be sure to watch for detailed postings on research and notes from the speakers (if you could not attend or are unable to view the archived recordings), and personal / company recaps.

Bottom line - I enjoyed tremendously being an invited speaker on a topic that engaged a capacity room and required the organizers to drag us out of our room to continue it in the halls.  My post takeaway is that I have not sufficiently communicated my research, and I hope over the coming months I can provide greater value to the industry at large.

Kind regards,

James DeLuccia

The new book is HERE!!!

Here are two quick shots taken while opening up the first shipment of books! Below the pictures I briefly sum up the intent of the book. Of course, the major book sellers present it better, and you can read the entire back covers and inside flaps here.

A brief overview:
Over the past year and a half I have been putting together a book with the magnificent crew at John Wiley & Sons Publishing (a company that is over 200 years old - a point that makes sense if you skim my final closing chapter). I have had a tremendous amount of help from friends, colleagues, companies, and numerous industry and government enforcement groups. My family was especially kind while I put together the book - allowing me to lock myself in my office while I sought to simplify the book to ultimately become:

A global synthesizing of how society and business has progressed over the past 100 years to integrate information technology, and their relative importance to business. The work is based on an analysis of over 140 separate public frameworks, laws, audit reports, and numerous guidance documents plus personal experience auditing and assessing over a million systems around the world. This effort resulted in an identification of key principles that represent the best practices that globally competitive organizations must adopt to balance the risks and rewards of operating in the 21st century. An action plan is designed to enable businesses to evaluate their important controls and consider the next 100 years.

A great deal of time is spent exploring PCI DSS, NERC, SOX, FFIEC, and their related controls. Plus some interesting challenges related to virtualization, grid computing, and the implied reliability of the Internet backbone. Thank you for taking the time to visit and contribute to this forum, and your feedback and future comments on this site.

Kind regards,

James DeLuccia