Ed Bellis – ClearText

This is part 1 of a multi-part series on the effectiveness of PCI compliance on addressing security externalities.

A purely economical definition of an externaility is “a cost or a benefit arising from an activity that affects people other than those who decide the scale of the activity“. In computing, there are often unintended security costs that affect those that are not involved in the decision making progress. A good example of an externality in application security would be the shrinking of time it takes to go from prototype to production in recent web application development. Programming languages used to force developers to think about things like input validation and defining what is legal input. As 4GL languages and later web application development came about, the languages no longer required programmers to define input up-front. This (albeit minor) along with many other enhancements shrunk development time dramatically. The obvious externality here is a lack of security born by the users of the application built.

Within information security, there have traditionally been two ways of offsetting externalities – regulation and liability. In this series I will try and cover the PCI DSS, and in my very humble opinion, how effective it is in dealing with security externalities.

PCI DSS (Payment Card Industry Data Security Standard) is regulated by the various credit card associations and is meant to protect card holder data. It is made up of 12 high level objectives within 6 different areas of security.

Section 1: Build and Maintain a Secure Network

This section is made up of 2 high level objectives around network security and access. Given that network security is probably the most mature space within electronic security, this section is likely the least controversial. That being said, the devil remains in the details. One consistent issue with most security regulations is a tendency in getting to deep into the implementation of controls. Given broad diverse audiences, this is not an effective approach. I have often said the best regulations will state objectives that must be met and let the participating organizations define how they meet those objections. It is then up to an ‘independent’ third party arbitrator to determine if indeed those objectives are being met.

While part 1 is primarily a no-brainer, the PCI council still murks the waters a bit by adding redundant requirements and attempting to dictate control activities at times. Take the following 2 requirements:

1.1.6 Justification and documentation for any available protocols besides hypertext transfer protocol (HTTP), and secure sockets layer (SSL), secure shell (SSH), and virtual private network (VPN)

1.1.7 Justification and documentation for any risky protocols allowed (for example, file transfer protocol (FTP), which includes reason for use of protocol and security features implemented

Is there a difference between these? It appears the second requirement asks for security features implemented presumably to mitigate the issues with the risky protocol, but who defines risky protocol? I have to believe FTP isn’t the only one. And why don’t I have to justify HTTP, SSL, SSH and VPN? If there is no business need for those to be open, why shouldn’t I close them on the firewall?

Here’s another redundancy:

1.3.5 Restricting inbound and outbound traffic to that which is necessary for the cardholder data environment

1.3.7 Denying all other inbound and outbound traffic not specifically allowed

OK, so technically we’re now discussing the cardholder data environment, but shouldn’t this be the case for any and all environments?

Next up:

1.3.9 Installing personal firewall software on any mobile and employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), which are used to access the organization’s network.

Not a bad rule, too bad it doesn’t mean anything. A simple requirement to install software does not buy us any extra security. This requirement would be better off to stick with allowing justified protocols that were covered in excess in earlier requirements. If a personal firewall is installed on a laptop but is configured to allow all, we’re not addressing the risk (but we are technically compliant with PCI).

Overall, nothing terribly controversial in section 1. Most organizations have been doing this stuff for a long time. To be clear, I think regulation is a good way to address externalities and it’s impossible to please everyone; I am just hoping we continue to refine this standard so it makes sense for all merchants and service providers. Stick to the objectives and avoid conflicts of interest.

Up next: Section 2