Payment Card Security & IT Controls Explained

There are simply too many great conferences in the world to attend each, and keep the lights on at the home office. In April HITB Sec Conference 2008 in Dubai had a few excellent presentations surrounding current issues for PCI DSS corporations (application security), and several insights into other areas of concern for global security. The full presentation files are available here. A few of the presentations I would recommend in your review are listed below: (Title, Summary, and Author are pulled from Conference agenda as the downloads are only referenced by speaker name):

Shreeraj Shah (Director, BlueInfy)
Presentation Title: Securing Next Generation Applications – Scan, Detect and Mitigate
Presentation Details:

McKinsey’s recent global survey suggested that 80% of companies are investing in Web 2.0 technologies. Web 2.0 technologies are no longer restricted to social networking site but forming backend to enterprise level applications. This evolution is giving rise to next generation application hacking and attack vectors. It is imperative to understand these new attacks and scanning methods to detect vulnerabilities. This presentation is going to cover following important aspects of next
generation application security.

- Footprinting, Scanning and Crawling of Web 2.0 applications.
- Ajax and Flash based XSS for Web 2.0 application.
- One-Way and Two-Way Cross Site Request Forgery for XML and JSON streams.
- Threat Model 2.0 for Web 2.0 applications.
- Hacking and Securing Service Oriented Architecture (SOAP, XML-RPC and REST based applications)
- Strategic security controls by leveraging Source code scanning and application layer filtering.

This presentation will be full of real life cases, live demonstrations, new tools and techniques along in-depth coverage on the latest concepts and methodologies.

Raoul Chiesa (Board of Directors Member @Mediaservice.net, ISECOM Group & TSTF)
Presentation Title: Penetration Testing SCADA and National Critical Infrastructure: Real-Life Experiences and Case Studies
Presentation Details:

SCADA acronym stand for “Supervisory Control And Data Acquisition”, and it’s related to industrial automation inside critical infrastructures. This talk will introduce the audience to SCADA environments and its totally different security approaches, outlining the main key differences with typical IT Security best practices.

We will analyze a real world case study related to industry. We will describe the most common security mistakes and some of the direct consequences of such mistakes to a production environment. In addition, attendees will be shown a video of real SCADA machines reacting to these attacks in the most “interesting” of ways!

Petko D. Petkov [pdp] (GNUCITIZEN)
Presentation Title: For My Next Trick… Client-Side Hacking
Presentation Details:

This paper describes numerous techniques for attacking Clients-side technologies. The content of the paper is based the research that has been conducted over the past year by the GNUCITIZEN Ethical Hacker Outfit.

The slides on the new vectors of attack in the Web 2.0 arena (which represents at least one instance where every piece of our data is accessed, managed, and manipulated) are interesting and educational.

Of course, as much fun as the slides are the presenters are really the show, so I do encourage everyone to contact and contribute to the community where you are able.
Client-side software generally refers to a class of computer programs that are executed on the client, by the user’s supporting environment, instead of the server. Both, clients and servers are in constant interaction. In a Web environment, the client is represented by the user’s web browser, while the server is the remote computer which serves dynamic content. In a much broader context, the client-server relationships can be represented by a network client connected to a WiFi network.
All the best,

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

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