Payment Card Security & IT Controls Explained

I am a strong believer in group “live” training experiences where I am in a room with individuals who have different perspectives, challenges, and questions.  Unfortunately, the real world keeps spinning and constant training is not always possible, so the web (yes… that which gives and takes) has online training.  For those unaware there are several very good online free training seminars for PCI DSS.  In fact, the one I am highlighting is “sponsored” by MasterCard.

After free registration - the simplest I have yet to see, you are provided with a list of sessions to listen to or you can download the PDFs!  You can find nearly currently a dozen sessions here.  They cover the following topics:

• Maximize Internal Preparation for PCI DSS New!, by Mathieu Gorge – CEO Vigitrust
• Network Segmentation New!, Mark Lippman – Senior Partner, Arsenal Security Group
• Data Encryption: Understanding Encryption and PCI DSS New!, by Gerard Onorato and Jeffrey Foresman
• An Introduction to the PCI Security Standards Council, by Bob Russo – General Manager, PCI Security Standards Council
• A Detailed Look at PCI DSS Requirements, by Andrew Henwood - Director of Operations, One-SEC/Trustwave
• A look into the new Self Assessment Questionnaire, by Jennifer Mack – Vice President, MasterCard Worldwide
• A Merchant’s Journey towards PCI Compliance, by Alexander Grant, General Manager British Airways
• Understanding Account Data Compromise, by A. Bryan Sartin - Vice President Investigative Response, Verizon Business
• Preparing for a Successful PCI Assessment, Lessons from the Field, by Michael Walter – Senior Partner, Arsenal Security Group
• Reducing Your Risk: A Look Into PCI Vulnerability Scanning, by John Bartholomew – Vice President, Security Metrics
• Security and the Payments Systems, By John Verdeschi – Vice President, MasterCard Worldwide and Jeremy King – Vice President, MasterCard Worldwide
• Compliance Validation & Beyond, by Sally Ramadan - MasterCardWorldwide

I have gone through several thus far, and my comments on a few are as follows:

• Maximize Internal Preparation - Helpful.  Core Message:  Setup a diverse team with senior management, and leverage your QSA’s experience
• Understanding Account Data Compromise - Educational.  Great walk through!  Check out Michael Dahn’s excellent ongoing articles on the carder market

Check out the online webinars here.   I am sure there are many others, so please add them below in the comments to help everyone!
Best,

James DeLuccia

Establishing an IT control environment that is agile and appropriate to an organization is a primary objective of IT Compliance and Controls, a recent book I released based on a global effort.  The Institute of Internal Auditors this month in their regular publication, “Internal Auditor“, has a great article “The Right Fit: Auditing ERM Frameworks” by Alexandra Psca defining how auditors within an organization can evaluation an in progress and mature Enterprise Risk Management (ERM) Program.
What is refreshing about this article is the author’s ability to communicate the reality that a full ERM program is unlikely to fully exist in every organization, and the presence of a program may come in different styles and colors.  When implementing and managing the enterprise risks of an organization it is prudent it recognize the following:

• ERM is designed to help the organization maximize risks in the daily course of business, and not a roadblock.  Focus on enhancing the risk environment
• Organizations have organic controls that are established through the natural placement by internal teams, and these work products make up the full Control environment.  Therefore, be sure to be perceptive when forming an ERM, and diligent on leveraging these already present accomplishments.

ERM is designed to reflect on the organization’s operations and risk - therefore one size won’t fit all.
For greater analysis I encourage you to pick up a copy of this periodical from your local Internal Audit department.  As the concerns of PCI DSS, GLBA, FISMA, FFIEC, and EU Directives highlight these program’s importance, managers and executives must be sure to manage the growth and adoption of these programs to achieve the enterprise goals.

Alexandra’s article is republished here too.
Best regards,

James DeLuccia

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

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