Wednesday, December 29, 2010

Selecting a Coding Standard for PCI DSS

In “What About the Confused Deputy” I point out that PCI DSS requires industry best practices, information security, code reviews and secure coding practices be incorporated into an organization’s Software Development Life Cycle (SDLC). PCI DSS suggests using OWASP for web applications but it does not provide guidance for addressing custom applications.

What industry best practices and standards are appropriate for the development of custom applications? For secure coding practices, the first place I looked was the CERT Secure Coding Initiatives. CERT defines secure coding standards for several commonly used programming languages.

Sunday, December 19, 2010

What About the Confused Deputy?

In Spoofing Google search history with CSRF, Jeremiah Grossman shows how to create a CSRF (Cross Site Request Forgery) using the Google Web Service. Fortunately, his example is educational rather than destructive. An analysis of the blog entry’s source code reveals a single HTML statement as the primary culprit for delivering the CSRF. CSRF is so prevalent that PCI DSS includes explicit requirements to address it.

In PCI DSS, Requirement 6.5.5 states that all web applications must be developed using secure coding practices that prevent CSRF. The testing procedure for this requirement seeks to ensure that web applications do not reply on authorization credentials and tokens automatically submitted by browsers.

Sunday, December 12, 2010

Using a Framework to Control the Scope of PCI DSS Assessment

In A Framework for Introducing PCI DSS Requirements, I describe how a having a framework provides value by enabling a consistent and reasoned approach to changing existing workflows and that a framework is easy to explain to stakeholders. However, a framework’s true value lies in its ability to help understand the business and process needs for cardholder data. This understanding can directly affect the scope of assessment.

PCI DSS permits the scope of assessment to be reduced if there is a clear understanding of the business needs and processes related to the storage, processing or transmission of cardholder data. The scope is refined further in Appendix F, where the assessor is permitted to select the smallest sample size for assessment if there are centralized standards that all entities must follow.

Tuesday, December 7, 2010

PT. Daya Cipta Mandiri Solusi: Five+ tips to ensure PCI DSS compliance

In PT. Daya Cipta Mandiri Solusi: Five+ tips to ensure PCI DSS compliance, Fanky Christian stresses the benefit and importance of using a consultant if you are new to PCI DSS. I couldn't agree more.

I'll add that the only consultant you want is one that can introduce compliance in a way that is sustainable. They have help create an on-going process.

Sunday, December 5, 2010

A Framework for Introducing PCI DSS Requirements

In Adventures in PCI DSS Compliance, I noted that the relationships between policies, processes, procedures and configuration standards need to be managed to create a meaningful set of documentation. Approaching compliance from this perspective creates a framework that is both consistent and easily explained to stakeholders.

Friday, December 3, 2010

BSDCan 2011 (Call for Papers)

One of my favourite conferences, BSDCan just announced a call for papers for the 2011 conference.

The conference is being held at the University of Ottawa, May 13 and 14. It is preceded by two days of tutorials.

Sunday, November 28, 2010

Adventures in PCI DSS Compliance

I've been reviewing the Payment Card Industry Data Security Standard (PCI DSS) for purposes of obtaining compliance. The standard includes 12 requirements for any business that stores, processes or transmits payment cardholder data.

One of the first things I looked at was the documentation requirements placed upon an organization. What I found is both interesting and likely a source of confusion for many organizations.