Given the presence of yet another very high-profile data breach from a supposedly PCI-compliant organization, many have begun to question the purpose and usefulness of PCI DSS and other similar regulations. There is a valid argument here, but let’s consider the purpose for these regulations.

PCI and all others are meant to be a baseline set of due diligence operations taken by organizations to ensure the safety, security and privacy of their users, clients and consumers. No compliance standard ever written is good enough, as it is intended to ensure that companies who haphazardly and dangerously risk the identities, credit and livelihoods of consumers can be punished.

As a baseline these regulations can never adequately protect organizations from malicious individuals who -in most cases- are smarter than those they are attacking. Used as a primary measure for security operations, relying on PCI DSS alone simply will not prevent data breaches and is not a recommended approach to security.

Some organizations that I have talked with recently have taken this to the extreme of ignoring PCI altogether, citing that the needs of their business are more important than the need for compliance. Let’s face it, depending on the organization and the level of compliance mandated, the certification process can be costly in terms of dollars and focus, so I understand the concern here. I do not endorse or recommend this course of action, but I applaud the organizations’ understanding that PCI compliance does not equal security.

If we must live with PCI, let’s live with it for what it is for–a baseline framework to oversee minimum due care. If we truly care about security and protecting our data from breaches, compliance must be a part of our overall security plan, or even completely separate if possible. There simply will never be any governing body anywhere that can write a standard that adequately addresses the security requirements for all organizations.

For anyone interested in tracking data breaches, visit www.privacyrights.org. You’ll be surprised just how many data breaches have occurred this year already, and many from PCI-certified shops.

There has been a lot of press, effort and money focused on Web Application Security over the past year–and rightly so. The attack footprint for many publicly-facing web applications has been growing as new web and browser-based vulnerabilities are being discovered at a scary pace. The PCI DSS push has helped primarily with the escalation of the press given, but we really haven’t crossed the bridge of minimizing the impact yet, and many security experts don’t yet see the light at the end of the tunnel.

What I want to discuss in this article is the trend observed over the past year, taken from data collected from hundreds of Pen Tests performed by myself and my peers. The results are indeed interesting.

Although web services take the cake, it’s not the web application vulnerabilities we hear about so much (such as XSS, SQL Injection and CSRF) that tops the list. In fact, the Top 8 of the Top 10 (although may contribute in some cases to things like XSS) are configuration and deployment errors.

The List (Organized by Number of Occurrences):

1. Weak, Insecure and Deprecated SSL Ciphers
2. TRACE Debugging Method Enabled on Web Server
3. Private IP Address of Web Server Leaked Through Headers (IIS)
4. Form Credentials and Confidential Information Transmitted over Clear Text (no SSL)
5. Default, Vendor Supplied Directories and Files (Mainly Apache/Tomcat Installations)
6. Poorly Configured Apache Servers, Including Directory Indexing and User Home Directories
7. Default ASP.NET Errors on IIS Installations
8. Unpatched IIS Installations Vulnerable to Remote Exploit
9. Presence of phpinfo() pages on Apache/PHP Installations
10. Cross-Site Scripting (XSS) Vulnerabilities

So at least one of the media-worthy vulnerabilities hits the list (XSS), but what is surprising to me is that common configuration errors and poor judgment calls by far takes the cake. In fact, when looking at the following graph, it is apparent just how bad this situation is.

This data is taken from raw pen testing data, is not specific to web servers and web applications only, and does not in any way correlate to things such as the OWASP Top 10 and the CWE Top 25 Programming Errors lists.

Food for thought: has the focus on web application security completely blinded us to the standard level of due care that should be exhibited in activities such as server deployment and patch management?

As a PHP coder myself, I know that it can be difficult for new programmers to build secure code. Aside from the Apache server config and the PHP config directives, writing secure code in PHP often is an afterthought — and it’s really easy to write insecure code with PHP.

Where many of the difficulties lay are in the use of Database connectivity, flashy AJAX and powerful Javascript to make a highly functional, good looking site. When coding these applications, many developers will pull pieces of code from other sites and integrate them into their own, often times not aware of input validation flaws, overflows and use of insecure PHP functions.

Where PHP often fails as a language is that it’s just that–a language. In and of itself, there are no input validation classes, no XSS or SQL Injection class to use, and no re-usable security mechanisms that can be used out of the gate.

In searching for frameworks that can be utilized by programmers to assist them in writing more secure PHP code, I ran across CakePHP. CakePHP is a PHP Framework that allows for the rapid coding of new applications using a Model, View, Controller (MVC) architecture. Aside from enabling the rapid development of new data-driven applications, CakePHP has some really good input validation classes that are extremely simple to use.

One of the main drawbacks with coding your own input validation with PHP is that many programmers aren’t familiar enough with regular expression syntax matching to make effective input validation routines–CakePHP simplifies this with pre-built functions for CC validation, SSNs, email addresses, password complexity and more.

Aside from its input validation classes, CakePHP allows developers to easily generate AJAX-enabled views, RSS feeds, XML and more without heavy modification of code or 3rd party downloaded scripts. Having been running through CakePHP for the past few weeks, I’m really impressed. I was really dumbfounded when I realized that CakePHP has been around for a really long time, has a corporate-sponsored team of developers and a very large base of programmers using it.

Any organization that utilizes PHP for writing public-facing web applications should look into (and require) a PHP development framework like CakePHP to ensure consistency and provide a baseline for common security features.