Building a Case for Payment Card Security Compliance

The Payment Card Industry Data Security Standard (PCI DSS) is about making the credit, debit and charge cards that we carry more secure for all. We cannot sustain the level of fraud and compromise at its current rate of growth, so we must all do what we can to protect card data.

PCI DSS started out in 1999-2001 as a Cardholder Information Security Program (CISP) in Visa and a Site Data Protection Program (SDP) in MasterCard to ensure card safety rules were followed for e-commerce transactions. But with the exponential rise in card fraud across the globe, the card schemes decided that they needed to follow a singular approach and, in 2006, launched the Payment Card Industry Council (PCISSC) to create common card industry security requirements.

In simple terms, PCI DSS is aiming to protect cardholder data so that stored cardholder data cannot be used fraudulently to pay for goods and services. Within the standard, Requirement 3 (protecting cardholder data) is the primary objective and the other 11 requirements help us to do that.

But the problem is that PCI DSS is perceived by many as a card payments compliance requirement and therefore it makes it difficult to cost justify it and build a business case for it around solely card payments. But it should not be limited to such a small scope.

The PCI DSS is a security standard that is just a bit more prescriptive in places than what is required for other security standards, such as ISO 27001, COBIT and INFOSEC. However, if one adheres strictly to any one of these security standards, then one will ensure compliance with most of the elements of PCI DSS.

The first and foremost consideration has to be one’s own security programme. That must always come first, with compliance aligned to it. This is not always easy and often requires a delicate balance. But remember compliance and security are not the same thing, so every organisation must place security squarely in the forefront.

Creating an Information Security Programme

It is important to take into account one’s own internal security programme and requirements, which includes the many security compliance standards and regulations that one already needs to comply with. With the PCI DSS, if cards are accepted as a payment method, the sensible way forward is to establish a security framework that covers the basics. ISO 27001 is one such security framework, which provides an excellent guide to benchmark a company’s information security programme. Once a framework is in place, one can then implement the more prescriptive pieces of PCI DSS and any other prescriptive elements of other internal or external security requirements a company has to cater for to do business and trade safely and securely.

Ensuring that cards are transmitted, processed and stored in a secure environment is critical, but instead of demanding we follow a ‘new’ standard, the card schemes should have required compliance with the ISO 27001 security standard. Then they could have highlighted the specific ‘additional’ security required around card data in particular. In this way companies would have been able to allocate the cost to implement the security that is incumbent upon every business within the business itself and would only have to justify the specific protection required for card data against the card business. Then businesses can develop a business case for just the additional, more prescriptive and specific security requirements around cards. This makes it easier to build the PCI DSS business case.

For example, take Requirement 10: “Track and monitor all access to network resources and cardholder data.” There are seven subsections to the requirement, including:

• 10.1 requires us to link access to system components to each individual user. This is unique to PCI and often creates challenges for the merchant, although user identification and authentication is also part of the ISO 27001 standards Clause 11.5.2. But the granularity of this PCI requirement may warrant inclusion in a PCI business case.
• The subsections in 10.2 specify the events that need to be logged. However, the events described are precisely the same events as required by the ISO standard to allow re-construction of certain events. Access, authentication and authorisation (AAA), change management, suspicious activity and system availability are also required by SOX and COBIT.
• But in 10.3 the PCI standard again requests more and is more prescriptive in that it requires that specific fields and values for each event be logged, but the level of detail required helps us to both deter and identify insider compromise, to any data, not just cardholder data.
• 10.4 just requires that all clocks are synchronised, as all logging requires, and is not unique to PCI.
• 10.5 requires that the logs be protected. Here again assuring log confidentiality, integrity and availability is not unique to PCI.
• 10.6 requires that the logs be reviewed and suggests that tools should be used to harvest and parse the logs – again not a unique PCI requirement.
• While the ISO standard requires that organisational records are protected, PCI in 10.7 specifically requires that we ‘retain the audit trail history for at least one year’, which is a cost that needs to be part of a PCI business case and one that could be costly depending on the size of the organisation. But a cost that can be reduced if one cleans and tidies the cardholder data in the organisation as a whole to reduce the size of the environment that needs to be protected.

That is one of the most important aspects of preparing for and managing the security around card data and indeed all data in an organisation.

Reducing Card Data Within an Organisation

Traditionally card data has been spread like spilt milk right across an organisation. The primary benefit of PCI, if we aim to comply with the standards in a manageable and cost effective manner, is that we have to get rid of most of the data. So we need to reduce the data, and where and how card data is used, across the whole organisation.

The key is to eliminate sensitive data, eliminate any unnecessary card data in the environment and protect what is left. If it is not there, it does not need to be protected. If it is there but only in small quantities, encrypted in designated secure areas and in a format not easily readable or visible, the fraudsters will walk on by.

So by reducing the size of the cardholder environment, by segregating the data that needs to be kept and by sanitising the data required for analysis and MI, one reduces the scope of the PCI audit and thus the cost of becoming and staying compliant.

In the UK and Europe, there is already a legal obligation to protect valuable business information. We are required under law to protect, names, addresses, phone numbers and bank (credit) card details from inappropriate visibility, and we are required to control access to this information by the UK Data Protection Act of 1998, which is an even more prescriptive and stronger act than the European Parliament Directive.

The UK Data Protection Act 1998 extends the European Union Directive on Data Protection (Directive 95/46/EC) and places further statutory obligations on the holders of personal, private or sensitive data. In order to comply with this, organisations need to have a robust internal security programme and therefore will possibly be already using something like the ISO 27001 standard. Consequently, one should only need to add the prescriptive pieces of PCI to whatever framework is already in place to manage the companies overall security and compliance with the Act of 1998.

Taking a broader view of what we have to do in terms of security in our businesses overall makes it easier to cost justify and implement PCI DSS in a business. Certainly one customer I work with in the UK has a very mature ISO 27001 framework that is very strictly adhered to. This has helped enormously in streamlining the effort required to become PCI DSS compliant. But more importantly, incorporating PCI DSS into the whole ISO 27001 security programme, which is part of the well managed and strictly enforced information and physical security programme within the organisation, is helping to maintain PCI DSS compliance within a single security cost base for the organisation.

Conclusion

PCI DSS is not a one off programme: it is a process that will continue to evolve as the security threats that threaten our businesses also evolve. As such, it is not a destination but a continuous journey that can be made easier if it is part of an overall security programme, rather than a standalone project that, on its own, is difficult to cost justify, achieve and manage. As part of the overall security programme, our client has found that PCI DSS has brought many benefits. Its Incident Response Plan (IRP) was recently commended by the external ISO 27001 auditor as best practice for the whole organisation. The PCI DSS project had taken the existing IRP and had ‘PCI’d’ it to meet the particular requirements of PCI DSS and fed the changes back up into the overall plan. Likewise with the information security policies, they have amended them to include the more prescriptive elements of PCI, and it is now felt that the overall policy is better for the company.

PCI DSS is not easy – it takes hard work, a lot of negotiation and attention to detail to get the Record of Compliance (ROC). But it is not all bad, and certainly the experience of this particular client and others that I know have achieved compliance is that through PCI, the existing mature and strictly adhered to security programme is better and stronger for it.