Payment Card Security & IT Controls Explained

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

I woke up this morning and was encouraged to see the FTC continue on its efforts to monitor the technology safeguards of companies in at least a consistent and security-risk minded approach. Now, while I am not a fan of unnecessary regulations and always feel a healthy bit of regular evaluation and expiration is necessary, it is suitable for companies that clearly do not abide by best practices are more closely supervised. This ruling by the FTC is consistent with that which was ruled for ChoicePoint in Georgia.

An interesting point is the scope of the required audit (physical safeguards through digital) and basic controls referenced under PCI. Specifically the FTC charged that TJX:

• “Created an unnecessary risk to personal information by storing it on, and transmitting it between and within, its various computer networks in clear text;
• Did not use readily available security measures to limit wireless access to its networks, thereby allowing an intruder to connect wirelessly to its networks without authorization;
• Did not require network administrators and others to use strong passwords or to use different passwords to access different programs, computers, and networks;
• Failed to use readily available security measures, such as firewalls, to limit access among its computers and the Internet; and
• Failed to employ sufficient measures to detect and prevent unauthorized access to computer networks or to conduct security investigations, such as patching or updating anti-virus software.” Press Release by FTC

The additional news, and expected given PCI DSS policies, on the release was that the company would undergo regular future audits separate from the government audit that will extend for 20 years.

Catch the full press release here, the Choicepoint ruling here, and the WSJ article here.
Please post any other articles that expand on this… or your thoughts if the FTC is the right body to do this type of monitoring, as it has been a twist on their established authority.

Best regards,

James DeLuccia