Working in the information security industry for a number of years has allowed me the opportunity to see a lot of eye opening and far more interesting things I otherwise would never have known about, or in some cases, wished to have not known about. One in particular that comes to mind is past visits to 3rd party hosting companies that offer “security” on their web sites, but being the guy who is allowed into the server room, you see something far from what is communicated back to the public. It is through visits like these that I know it is not a question of if my credit card will eventually be used fraudulently, but more the case of when.

I thought it would be a good time to take the 12 control objectives listed in version 1.1. of PCI DSS and compare this with the most obvious flaws I have seen across this group. (Please note that the below information is not gospel and the issues discussed may be spread across multiple organisations or could have been condensed to a single entity).

Taking the definition from Wikipedia, Payment Card Industry (PCI) Data Security Standard (DSS) was developed by the major credit card companies as a guideline to help organisations that process card payments to prevent credit card fraud, hacking and various other security issues. A company processing, storing, or transmitting credit card numbers must be PCI DSS compliant or they risk losing the ability to process credit card payments.

Let’s begin shall we?…

Build and Maintain a Secure Network

• Requirement 1: Install and maintain a firewall configuration to protect cardholder data

If we are talking about network layer firewalls, then when separating the Internet from the organisation there is normally a firewall present. It’s the segregation of the other components, such as web server from database server, company X from company Y, or VPN tunnels which is normally the problem.

Application level firewalls are still more of a nicety than a necessity which is unfortunate.

• Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Mostly find default passwords on network hardware such as switches and routers. Phenoelit’s default password list is very helpful in these circumstances. For large networks, THC’s Hydra in combination with the above will mostly always find you a hit and then some.

As far as security parameters go, it has been the vendors who have gotten better in this space and not necessarily the system administrators. As an example, compare Windows NT with Window 2003 or Red Hat 4.x with Red Hat Enterprise 1.x.

Protect Cardholder Data

• Requirement 3: Protect stored cardholder data

Still finding that some merchants think they need to store cardholder data even though they could pass it straight on to the payment gateway. This is a paradigm shift that fundamentally is a procedural issue than an IT issue.

If data does need to be stored, then the practice of only storing what is absolutely necessary, encrypting sensitive data that has to be stored and masking certain digits is give or take.

• Requirement 4: Encrypt transmission of cardholder data across open, public networks.

Most organisations are using SSL certificates to encrypt sensitive data using HTTPS. As it only says public networks then I shouldn’t comment on what happens to it after it hits the web server…

Maintain a Vulnerability Management Program

• Requirement 5: Use and regularly update anti-virus software

Most organisations are pretty aware of this one and have it as part of their policy or the software is installed in set and forget mode.

• Requirement 6: Develop and maintain secure systems and applications

You could really argue two points here…1. If developers were really on top of this one then why is the demand for web application penetration testing and source code review so high? 2. The fact the demand is high shows that organisations are trying to maintain secure systems and applications.

Implement Strong Access Control Measures

• Requirement 7: Restrict access to cardholder data by business need-to-know

I touched on this in requirement 3…

• Requirement 8: Assign a unique ID to each person with computer access

Although operating systems have had this capability built in for quite a long period of time, generic IDs still rears its ugly head.

• Requirement 9: Restrict physical access to cardholder data

Most 3rd parties are pretty good with the physical security components as this is what the client mostly sees when they walk around the silo. Physically secure implies the network must be secure, right?

Regularly Monitor and Test Networks

• Requirement 10: Track and monitor all access to network resources and cardholder data

If logging is actually enabled then you could be assured that it’s not being monitored.

• Requirement 11: Regularly test security systems and processes

There are two types in this category: Those who love to test cause they see the benefits and those who don’t and will fight tooth and nail not to. When you pen test the first type you normally have to be an insider to get to the data. When you pen test the latter, you could be anyone, anytime and normally have more than one avenue to exploit in order to compromise the data.

Maintain an Information Security Policy

• Requirement 12: Maintain a policy that addresses information security

Most places are not big enough to have a dedicated security group. If there is a policy available, it is a rarity and normally is present because one of the system administrators has a passion for security on the side.

I do find it interesting that although I have only stuck with the 12 high level controls, I did manage get an issue for nearly each item.

In addition, stepping back and looking holistically at the problem, even though there is a risk for merchants and 3rd parties to lose the ability to process credit cards, what else is the driving factor to have the majority compliant with this standard? After all, aren’t we just talking about a guideline…