The Payment Card Industry Digital Security Standard (PCI DSS) is an information security standard for organisations that handle credit and debit cards from the major card companies, including Visa, MasterCard and American Express. Organisations that take payments from, process or store, card details are obliged to meet the security standard. Those who fail to observe the standard can find themselves excluded from receiving credit card payments and those who lose credit card numbers, or have them stolen from them, can face hefty fines for failure to meet the standard. This note discusses a new Release 3.2 to the standard, which has significant implications for card providers and their service providers.
The standard was created in 2004 to increase controls around cardholder data and to reduce credit card fraud. It is administered by the Payment Card Industry Security Standards Council (PCI SSC), a body set up by the card companies, intended as being separate and independent of them. The standards are therefore seen as existing independently of and separately to the needs of specific card companies and reflective of general security issues affecting all issuers of credit and debit cards.
The standard consists of twelve broad principles:
- Install and maintain a firewall configuration to protect cardholder data;
- Do not use vendor-supplied defaults for system passwords and other security parameters;
- Protect stored cardholder data;
- Encrypt transmission of cardholder data across open, public networks;
- Use and regularly update anti-virus software on all systems commonly affected by malware;
- Develop and maintain secure systems and applications;
- Restrict access to cardholder data by business need-to-know;
- Assign a unique ID to each person with computer access;
- Restrict physical access to cardholder data;
- Track and monitor all access to network resources and cardholder data;
- Regularly test security systems and processes; and
- Maintain a policy that addresses information security.
The standard document describes the processes, policies and settings required to conform to these principles in quite granular detail.1
Since its release in 2004 only two major releases or revisions have been made to the standard. Version 2.0 was released in November 2010 and Version 3.0 in October 2013. A new Version 4.0 is expected in early 2017. However, a number of `sub-releases', containing revisions and clarifications, have been made between the three major releases. The most recent, Release 3.2, contains a number of significant changes which while ostensibly minor, may have significantly implications and costs for organisations required to conform to the standard. According to the PCI SSC, these new standards must be implemented by organisations before 31st October 2016, when the prior standard Release, version 3.1, will no longer be valid.
Of the changes required by the new PCI DSS Release 3.2 a number appear to arise directly from the lessons learned from the large recent hacking incidents in the US, including the Target, Home Depot, Sally Beauty, Kmart and other attacks. Of these, the Target hack, which occurred over September December 2013, as well as being an early in time large scale retail and thus credit-card processor hack, has been well documented and commented upon, including by way of analysis and reporting by the US Senate Committee on Commerce, Science, and Transportation. The Senate Committee issued a quite detailed report in March 2014, entitled `A "Kill Chain" Analysis of the 2013 Target Data Breach".2
RULE 8.3 ACCESS TO THE PCI SEGMENT
The most notable change is the new Rule 8.3. Previously Rule 8.3 was a relatively short rule requiring that remote access to the PCI segment of a network - the part of the network which collected, stored, managed or has direct access to credit card information - be controlled by twofactor authentication (for example, by a password and encrypted key fob).
The problem with this old standard was that many of the major data breaches in the US, most notably Target, involved the hackers breaking into the network by means of compromising single factor access to non-PCI segments of the network for example, the parts of the network handling administrative and operational matters then working their way across the internal network, using administration passwords stolen or intercepted on the way, into the PCI segment. As a consequence credit cards were compromised on these networks because hackers gained access to them, in effect, over a single factor remote connection.
The new Rule is far more detailed, and in particular requires two factor authentication to access the PCI segment of a network regardless of how the access occurs. What this says is that if you have credit card information on your network you must either have two factor remote access for all individuals accessing the network, or the credit card data must be segregated into a subnet which can only be accessed, internally and externally, using two factor authentication. The only condition where two factor authentication is not required is where a user accesses a computer on the PCI segment directly over a console, i.e. using its own keyboard, monitor and mouse.
RULE 10.8 SECURITY MONITORING
Rule 10.8 is another Rule that has been heavily beefed-up as a consequence of the large US credit card breaches. The old Rule 10.8 was a rather highlevel requirement that organisations should "ensure that security policies and operational procedures for monitoring all access to network resources and cardholder data are documented, in use, and known to all affected parties." As a general information security and risk management observation, we are seeing regulatory type bodies, across a number of industries and sectors, recognise the limitations of the broad-type statements of requirement they traditionally saw as sufficient and move to more detailed statements of requirement.
In a number of the major US card breaches it is understood that, even though (some) logs were being retained and monitoring systems were in place, nobody was actually reviewing the logs on a regular basis, and this was not the least of the security failings. In the case of the Target breach, it is understood that an intrusion detection system detected the hack and raised multiple alarms but was picked up neither by Target's own staff or their external security providers. The central problem is that even if alarm systems are in place and logging is enabled, someone has to have the responsibility of responding to the alarms and reading the logs. In many of the companies hit by large data breaches this appears not to have been the case. To quote from the US Senate report "according to a Bloomberg Businessweek report, Targets FireEye malware intrusion detection system triggered urgent alerts with each installation of the data allowing exfiltration malware. However, Targets security team neither reacted to the alarms nor allowed the FireEye software to automatically delete the malware in question. Targets Symantec antivirus software also detected malicious behaviour around November 28, implicating the same server flagged by FireEye's software".3
The new Rule 10.8 is expressly aimed at card service providers and requires that they implement a process for the timely detection and reporting of failures of critical security control systems, setting out a sizeable list of devices over which such reporting is required. An additional Rule, Rule 10.8.1, goes on to expand this requirement, again for service providers, requiring them to respond to failures in these systems in a timely manner, setting out in some detail what actions such responses should include.
The new PCI DSS gives organisations a little leeway by stating that these new rules should be considered only `best practice' until 31st January 2018, after which they will be obligatory. These new requirements, whilst arguably documenting best-practice, will have significant risk-management implications for in-scope organisations as well as cost implications, the assumption being that service providers will seek additional payment for additional service requirements. Dealing with service providers in a PCI compliance environment is a topic outside of this note.
OTHER NEW RULES BROUGHT ABOUT AS A CONSEQUENCE OF US DATA BREACHES
A new Rule 22.214.171.124, again aimed at card service providers, requires that penetration tests be run on networks every six months to ensure that the PCI segment is effectively isolated from the rest of the network. In many of the US data breaches hackers were able to move from the non-PCI to the PCI segments of the affected networks without it would appear material difficulty.4 This new Rule appears to be a response to this. The requirement to carry out penetration tests to validate that the PCI segments is correctly separated from the rest of the network is likely to lead to substantial additional costs for many organisations.
Rule 12.4.1 is another new Rule, again aimed at card service providers, and requires that that a named member of the executive management is responsible and accountable for the maintenance of PCI DSS compliance. It requires that a charter be established, setting out what information must be provided by those directly responsible for PCI compliance to the executive with direct authority. This appears to be an attempt by the PCI DSS to ensure that, in the event of future major data breaches, in particular those with a potential degree of contributory deficiency on the part of the organisation hacked, that senior management's heads will be on the block as a consequence. The intention would seem to be that this requirement will focus the minds of directors and executives on the issue of data security. We are seeing here a likely transition from security as a traditionally largely technical issue to one of overall corporate risk management. As pointed out in the US Senate report "Target had been certified in September 2013 as compliant with [PCI DSS], which credit card companies require before allowing merchants to process credit and debit card payments. These steps were obviously not sufficient to prevent the breach".5 Based on the understood Target hack timeline, the compromise of the third party suppliers IT systems, which formed the bridgehead to the Target direct attack, occurred in September, with the Target network being breached in November, data exfiltration commencing in early December and ending in mid December. It is likely that the area of security as a corporate risk management issue will be developed in future Releases.
As a legal risk management observation, the availability of the charter and related documentation including internal, service provider (as discussed above) and third party professional service provider, reporting, as evidence in any potential legal proceedings to which the organisation is subject resulting from a data breach, will be of concern to organisations.
Finally, a related requirement, Rule 12.11.1, requires organisations to perform reviews at least quarterly to confirm personnel are following security policies and operational procedures and to correctly document such reviews. The operational procedures which should be reviewed include daily log reviews. This, like Rule 10.8, is, we believe, a direct reaction to the poor practices at Target and other US firms prior to major data breaches, where logs were not we believe reviewed and alerts not followed up. Like Rule 126.96.36.199, this new Rule is likely to result in substantially increased costs for affected companies. Again, organisations will have concerns in relation to use of documentation produced in this area in legal proceedings.
A number of additional changes to the standards appear to be unrelated to the major US breaches. These include Rule 3.3, which require that card numbers be partially masked when displayed (either the first 6 numbers or the last 4 can be displayed). Others deal with documentation of compliance and cryptographic procedures, but are outside the scope of this note.
Release 3.2 follows on, we believe, from the factual matrix discovered to exist in a number of recent high profile US hacking incidents. The Release tightens already tight regulations and requirements from a technical perspective, together with the additional requirements in terms of executive management responsibility and accountability. Thus the Release contains a mixture of technical provisions and effectively corporate risk and compliance type provisions. The Release is likely to substantially increase the effort and cost associated with PCI DSS compliance, very much focusing on compliance as an ongoing requirement, together with the corporate governance aspects of compliance. The Release is to be welcomed by cardholders if it cures some of the unwelcome practises discovered on review of the recent large US hacks. While it has administrative, cost and risk management implications for card processors, it should be overall welcomed in attempting to assist the organisations in protecting themselves and their card holders.