Open Letter to the Payment Card Industry Security Standards Council (PCI SSC)

I intend to send the below letter to the PCI SSC outlining some (hopefully constructive) criticism of the PCI Data Security Standards. For those not familiar with them, in simple terms they are a set of rules that anybody dealing with credit card data has to follow and comply with (there’s a lot more detail to it with different tiers depending on how many transactions you process etc etc).

As a disclaimer, the contents are purely my personal views, and do not represent the views of any company I operate or have done work for.

Dear Sir/Madam,

I have recently had cause to work with a number of small businesses who have been working their way towards compliance with the Payment Card Industry Data Security Standards (PCI DSS). This open letter is to provide you some feedback regarding these standards, and in particular their applicability to small businesses, in the hope that it may help improve future versions of the standards.

I would like to start by making clear that I am very supportive of the principal of having data security standards that should be applied to entities storing / transmitting / processing cardholder data, and anything that drives organisations to consider data security, however I have serious concerns about the current PCI DSS implementation.

My comments are split in to three main areas – the first is regarding poor / confusing wording in the standards themselves…

We begin with requirement 1.3 (“Prohibit direct public access between the Internet and any system component in the cardholder data environment”) – while I realise the intention behind this requirement is to ensure placement of servers that interact with the public into a DMZ, technically any component in the DMZ is a part of the cardholder data environment (CDE), and as such it is actually impossible to meet this requirement and still accept credit card payments over the internet.

This problem is further reinforced with requirement 1.3.3 (“Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment”) – again it is impossible to comply with a literal reading of this requirement – an interpretation has to be made that ‘cardholder data environment’ does not include the DMZ.

Requirement 1 unfortunately does not get any better, with 1.3.6 stating “Implement stateful inspection, also known as dynamic packet filtering. (That is, only established connections are allowed into the network.)” – if I only accept established connections in to the network, how do any new users connect to establish a connection in the first place!

Looking further through the requirements, we come across 9.3, regarding handling of visitors, of which 9.3.1 states they must be “Authorized before entering areas where cardholder data is processed or maintained.” – taking a card payment using e.g. a chip and PIN terminal is processing cardholder data, so a literal interpretation of the requirement would suggest that members of the public need to be authorized (and be issued ID badges etc) before payments can be taken from them!

My second area of comment is regarding areas where the requirements are overly prescriptive, and therefore while reasonable for a larger organisation that needs to co-ordinate activities across many teams and departments, impose a large (and in my opinion mostly unnecessary) burden onto smaller businesses, to the extent that I imagine the majority of small businesses will not / cannot be entirely compliant, even if they have ticked the ‘Yes’ box on their self assessment questionnaire. To illustrate my point, I will use a (made up) example of a small retailer, supplying goods both over the counter (using chip and PIN), and via telephone orders (entered in to a web virtual terminal), accepting card payments in both cases. This example retailer has 5 employees, 2 of which purely handle the stock, the remaining 3 alternate between the counter and the telephone.

Assuming this example retailer has been asked to prove their compliance by their acquiring bank, they would I believe have to complete SAQ D – if they solely had the web virtual terminal, they would only need to use SAQ C-VT, and if they solely used the standalone chip and PIN terminals they would only need to use SAQ B, however as it is they do not meet the requirements for either of those SAQs, and as such the full SAQ D is the only option available.

If we go through SAQ D, I have identified that this 5 employee business would be required to produce approximately 10 policy documents, and likely even more procedures – most (if not all) of which are likely to never be read again until the next PCI DSS assessment, therefore these requirements are a waste of time and money, and do not add anything to the security of this merchant.

In addition, despite their sole use of the internet in relation to cardholder data being for their virtual terminal, they still require a documented rule set for their firewall, despite essentially all SOHO firewalls having a sufficient (no inbound connections allowed) rule set by default.

They are also supposed to develop configuration standards for their firewall and PCs – something that is not practical with a business of this size.

Requirement 6.2 states “Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities” – this is something that a business of this size simply cannot do, as they don’t have sufficient expertise. In this scenario, simply ensuring they install (for example) critical Windows Updates, and responding to any notifications from their payment service provider (PSP) should be sufficient. Following on from this 6.4.5 requires “Change control procedures for the implementation of security patches and software modifications” – again this is simply not practical for a business of this size, whose update procedures will simply be to configure automated updates, and not put every update through a change control procedure!

I would like to make clear the above are just examples, there are many other aspects of the requirements that are simply impractical (and in my opinion not beneficial from a security point of view) in a scenario such as this example – the end result of which is that I suspect a large number of self certifying businesses simply ‘tick the box’ and claim to be compliant when in reality they are not, thus defeating the point of the standards.

My final area of comment is regarding requirements which can introduce more risk than they mitigate. The specific example I have (though there were a number I could have chosen) is requirement 11.2.1 (“Perform quarterly internal vulnerability scans”) – the vast majority of companies will achieve compliance with this requirement by outsourcing the scanning (while the requirements do state it can be done by a qualified internal resource, it is unlikely that many businesses will have a suitably qualified resource, especially as organisational independence is required).

The way this internal testing appears to be achieved, is by the use of a ‘black box’ – a device that can be attached to the organisations network, which ‘phones home’ to the outsourcing company, and allows them to conduct the scans. As the scan is required to be carried out quarterly, this box is often left in place permanently. Unfortunately, the result of this is that a device has been installed within the cardholder data environment, which could (due to malicious users within the outsourced vendor, or even due to simple vulnerabilities) be exploited, at which stage it has already bypassed most of the protections put in place to secure the system (as it would be inside the firewall, and likely beyond the DMZ).

My personal view is that this testing should be required on an annual basis only, at which stage it can be carried out once, and then the ‘black box’ removed to avoid any problems it may cause.

Yours faithfully,
Alex Brett