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 can face hefty fines for failure to meet the standard. This article discusses a new Release 3.2 to the standard, which has significant implications for card providers and their service providers.
The Standard
The standard was created in 2004 to increase controls around cardholder data and 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[1] and intended to be a global open body formed to develop, enhance, disseminate and assist with the understanding of security standards for payment account security, being separate and independent of the card companies. 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 PCI SSC has more than 760 global participating organisations.[2]
The standard consists of 12 broad principles:
1. Install and maintain a firewall configuration to protect cardholder data;
2. Do not use vendor-supplied defaults for system passwords and other security parameters;
3. Protect stored cardholder data;
4. Encrypt transmission of cardholder data across open, public networks;
5. Use and regularly update anti-virus software on all systems commonly affected by malware;
6. Develop and maintain secure systems and applications;
7. Restrict access to cardholder data by business need-to-know;
8. Assign a unique ID to each person with computer access;
9. Restrict physical access to cardholder data;
10. Track and monitor all access to network resources and cardholder data;
11. Regularly test security systems and processes; and
12. 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..[3]
Standard Revisions
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 sub-release, Release 3.2, introduces five new sub-requirements which while ostensibly minor, may have significant 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 31 October 2016, when the prior standard Release, version 3.1, will no longer be valid. However, the new PCI DSS gives organisations a little leeway by stating that these new standards should be considered only ‘best practice’ until 31 January 2018, after which they will be obligatory.
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 was an early large-scale retail and 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’.[4]
Rule 8.3 – Access to the PCI Segment
The most notable change is the new r 8.3. Previously r 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 multi-factor authentication (for example, by a password and encrypted key fob or biometric data).
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 multi-factor authentication (which differs from two-factor authentication, as two or more factors may be used) to access the PCI segment of a network regardless of how the access occurs. Therefore, all ‘non-console’ administrative access, even when accessed by an employee from the company’s internal network, must employ multi-factor authentication. What this says is that if you have credit card information on your network you must either operate multi-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 multi-factor authentication. The only condition where multi-factor authentication is not required is where a user accesses a computer on the PCI segment directly over a console, ie using its own keyboard, monitor and mouse (‘console access’).
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 r 10.8 was a rather high-level 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 statements of requirements they traditionally saw as sufficient and move to more detailed statements of requirements.
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”.[5]
The new r 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, r 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.
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 article.
Other New Rules Deriving from US Data Breaches
A new r 11.3.4.1, 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.[6] For example, in the case of the Target breach, the US Senate Report notes that ‘less security at the perimeter of Target’s network may have contributed to the attackers’ success in breaching the most sensitive area of Target’s network containing cardholder data‘.[7] This new rule appears to be a response to this. The requirement to carry out penetration tests to validate that the PCI segments are 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 aimed at card service providers. It requires 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’.[8] Readers will note that PCI DSS compliance closely pre-dated the hack which emphasises the point that PCI DSS compliance is not of itself an information security silver bullet. 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. The area of security as a corporate risk management issue is likely to be developed in future Releases. This new corporate risk management emphasis in r 12.4.1, together with the related r 12.11.1 (discussed below) is probably the most important provision in Release 3.2 from a legal and commercial risk management perspective.
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.
A related requirement, r 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 r 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 do not seem to have been reviewed nor alerts followed up. Like r 11.3.4.1, 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 potential legal proceedings.
Rule 6.4.6 provides that organisations must have a process for ensuring PCI DSS compliance whenever there is a ‘significant change’ in the cardholder data environment. This new requirement seeks to address compliance gaps that can arise when networks or systems are added or changed.
Finally, Release 3.2 introduces some new appendices, including appendix 2, which specifies that entities must have ceased using Secure Sockets Layer (SSL) and early Transport Layer Security (TLS) by 30 June 2018. Further, any entities that continue to use these now outdated encryption methods prior to 30 June 2018 must have a formal Risk Mitigation and Migration Plan in place.
Additional Provisions
A number of additional changes to the standards appear to be unrelated to the major US breaches. These include r 3.3, which requires 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 article.
Sanctions for Non-Compliance
PCI DSS is not a legally binding standard. Compliance with the standards is a contractual requirement imposed on all acquiring banks by the card issuers. The acquiring banks in turn impose the requirements on merchants that store, process or transmit cardholder data.
Although compliance with PCI DSS is not a legal requirement, there is still the potential to incur quite serious penalties for non-compliance. For example, the card companies can impose penalties on merchants which can be very significant (many millions) and can be accompanied by a withdrawal of card acceptance facilities. Withdrawal is the ultimate sanction and is effectively unimaginable for merchants. The specific scope of fines depends on the merchant’s contracts with Visa, MasterCard, etc.
Further, aside from financial risks, there are also the following related risks associated with non-compliance with PCI DSS:
· Reputational Risk: PCI DSS are regarded as industry standards and in the event of a compromise of card data, the party responsible may suffer reputational damage for not adhering to the published standards. Target suffered severe reputation damage as a result of its data breach and it had (as mentioned) been certified as PCI DSS compliant. An organisation that fails to implement PCI DSS is likely to come under even more severe criticism in the event of a data breach due to its failure to take steps to prevent the breach;
· Fraud Risk: In the event that unauthorised access occurs to credit card data which is held for seven years in an encrypted vault of recordings; and
· Investigation by the local Data Protection Authority: Although the DPAs do not have any role in generating PCI DSS, they may consider PCI DSS compliance in circumstances where there has been a data breach. The Irish DPA has issued Enforcement Notices (for example, against Loyaltybuild[9]) where compliance with PCI DSS was a specific requirement. Further, the UK DPA considers a breach of PCI DSS to be an aggravating factor. Last year, the UK DPA imposed a fine of £175,000 on Staysure.co.uk Limited for a data breach where, among other issues, CVV numbers had been wrongly stored, contrary to PCI DSS.[10
Conclusion
Release 3.2 follows-on to a large extent, 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. Corporate and compliance risk management is effectively legal risk management. 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 practices discovered, in particular, on review of recent large US hacks. While it has administrative, cost and risk management implications for card processors, it should overall be welcomed in attempting to assist the organisations in protecting themselves and their card holders.
Pearse Ryan is a Partner in the Technology & Innovation Group in Arthur Cox, Dublin.
Anne O’Donovan is a Trainee in the Technology & Innovation group in Arthur Cox, Dublin.
Andrew Harbison is Director-Head of Litigation Technology in Grant Thornton, Dublin.
[1] American Express, Discover Financial Services, JCB International, MasterCard and Visa Inc. as founding member payment brands, together with ‘strategic members’
[2] As of date of writing there were 765 participating organisations. See: https://www.pcisecuritystandards.org/get_involved/participating_organizations
[3] Recent versions of the standard can be downloaded from https://www.pcisecuritystandards.org/document_library
[4] See: https://www.commerce.senate.gov/public/_cache/files/24d3c229-4f2f-405d-b8db-a3a67f183883/23E30AA955B5C00FE57CFD709621592C.2014-0325-target-kill-chain-analysis.pdf
[5] US Senate Committee report p 3
[6] US Senate report p 9: “it is unclear exactly how the attacker could have escalated its access from the Ariba external billing system to deeper layers of Targets internal network, But given the installation of the BlackPOS malware on Targets POS terminals the compromise of 70 million records of non-financial data, and the compromise of internal Target servers used to gather stolen data, it appears that the attackers succeeded in moving through various key Target systems”.
[7] US Senate report p 8.
[8] US Senate report p 7
[9] See: Case Studies 2013, Case Study 14: Data Security Breach at Loyaltybuild Ltd. at https://www.dataprotection.ie/docs/CASE-STUDIES-2013/1441.htm
[10] See: https://ico.org.uk/media/action-weve-taken/mpns/1043368/staysure-monetary-penalty-notice.pdf and http://www.out-law.com/en/articles/2015/february/breach-of-payment-card-data-security-standard-leads-to-175000-ico-fine-for-insurer/
