An Acquirer s view: Payment security best practice and PCI DSS compliance. PCI London 23 January 2014

Transcription

1 An Acquirer s view: Payment security best practice and PCI DSS compliance PCI London 23 January 2014 Looking back over the years that the Barclaycard Payment Security team has presented at the PCI London events, we can reflect on the gradual maturation of the card payment industry s attitudes and awareness towards the importance of payment security, and the risks and measures that could, and in many cases must, be taken to mitigate these. Initially we looked at the fraud landscape, discussed best practice for call centres and ecommerce, and the issues and impact of (the then) emerging technologies such as tokenisation and encryption on payment security and compliance. We ve focussed on cloud computing and how to maintain a secure payments environment. We ve also looked at incident preparedness, third party risk management, social media, mobile payment acceptance, and most recently we examined the importance of setting and working towards an effective compliance strategy. Phew! So much has taken place, and we ve come a long way, but if there s one lesson to be learned it s that there s never any time for complacency. What has been accomplished to date is in no small measure thanks to the efforts, effectiveness and contribution that events such as this, and from across the industry in general, have made towards the education, awareness and training of all those involved in the business of accepting card payments as a merchant, issuer, acquirer, PSP or any other part of the huge chain that helps card payments take place and keeps the economy working. As an acquirer we are perhaps uniquely placed to see to the risks, issues, and difficulties faced in particular by merchants and their third parties as they strive to mitigate their exposure to a data security breach, to prioritise their risks and the measures they need to put in place and to comply with the PCI DSS - all while juggling with the practical reality of budget constraints. We thought it would be useful therefore to outline some of the most common issues that we still come across on a regular basis:

2 Incident response - have you got a plan? As the old saying goes The road to hell is paved with good intentions. While compliance with the PCI DSS must be considered a corner stone of payment security, one of the key areas all too often overlooked in our experience is the importance of an effective incident response plan. This is quite surprising as this does not necessarily require huge expense or vast technical expertise to accomplish, yet all too often is put on the to do list, along with all our other many good intentions. In view of the fact that it takes 62% of merchants 3 to 8 months on average to discover they have been breached 1, what better New Year s resolution than to have an effective Incident Response Plan in place? Infosec incident response has undeniably become a prominent part of any of our endeavours as the focus is now increasingly moving from How do I prevent a breach? to What do I do when I get breached? The National Institute of Standards and Technology (NIST) has published the final version of its guide for managing computer security incidents. Based on best practices from government, academic and business organisations, the NIST report is a great help in providing guidelines on responding to incidents effectively and efficiently. They include the following steps: Creating an incident response policy and plan Developing procedures for performing incident handling and reporting Setting guidelines for communicating with outside parties regarding incidents Selecting a team structure and staffing model Establishing relationships and lines of communication between the incident response team and other groups, both internal (e.g., legal department) and external (e.g., law enforcement agencies) Determining what services the incident response team should provide Staffing and training the incident response team. It is not surprising given that the substantial brand and reputational damage that ensues after a data breach that a whole section of the report is dedicated to responding to outside parties. The following diagram explains it well, however it should be noted that currently within Europe we don t have mandatory breach notification, so our advice would always to be to consult with your acquirer and wait for the PFI/PFILite to both close the breach and accurately report the numbers of cards at risk before making public announcements. 1 Source: Verizon 2013 Data Breach Investigation Report

3 Make sure you have one person nominated to deal with the media this person should have had the relevant media training. It s really important that everyone else in your organisation knows to pass on enquiries from the media and other parties to the one nominated contact because it is really hard to manage the after-effects of an incident if there are lots of competing, and perhaps contradictory stories, in the media. It is also important to respond quickly, and consistently, to social media such as comments on twitter and Facebook. Again there needs to be someone in the company who knows they will be in charge of this aspect of communications, and they should have prepared how to handle social media during and after an incident. The incident response process has several phases which should be followed: preparation detection and analysis containment eradication and recovery post-incident activity Finally, don t forget to include your acquiring bank or processor in your security incident plan.

4 Incident Response Life Cycle The full report can be found at How an effective incident response plan really can help In 2013 the Barclaycard payment security team received a call from a merchant reporting a data breach. The impact of the breach had been significantly mitigated by the security measures mandated by the PCI DSS, which had facilitated detection of the breach within 48hrs of incursion and minimised the opportunity for card data exfiltration. By having an effective incident response plan in place the merchant was aware of the need to alert their acquiring bank and the card schemes which they accomplished within 48hrs of the initial breach. Negative publicity surrounding the breach was minimised, as well as the potential card scheme fines faced by the merchant as they had self-detected and reported the breach, and taken all necessary action in a timely manner. Not one of our breached customers really believed it would happen to them. The customer above was subject to a zero-day attack 2 and it was because of the PCI DSS defence in depth controls which enabled this merchant to detect, contain and manage the breach which saved them from further exposure. Unfortunately it seems like a matter of when a breach occurs rather than if, so be prepared. Are you really PCI DSS compliant? This really is the million dollar question, and has been brought particularly to the fore this year by the changes to the MasterCard scheme mandate which now requires Level 2 merchants to either self-attest using an Internal Security Assessor (ISA) or engage a PCI SSC-approved Qualified Security Assessor (QSA) for an onsite assessment instead of performing a self-assessment. 2 an attack that exploits a previously unknown vulnerability in a computer application

5 We have seen several instances of L2s previously self-attesting to their full compliance, now woefully short of compliance after using the services of a QSA or ISA. Blissful ignorance is just another way of leaving the door open to your worst nightmares. If your organisation is self-attesting make sure you fully understand your card data environment and all your process and systems, and if in doubt use the services of a QSA or ISA. E-Commerce Silent Order POST It has come to our attention that merchants are looking to Silent Order POST mechanisms as a way to reduce the scope of their PCI DSS compliance. Version 2.0 of PCI DSS states The cardholder data environment (CDE) is comprised of people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data. The generation of the web page which collects the cardholder data is an intrinsic part of the process so it is part of the CDE and PCI DSS applies. Version 3.0 of PCI DSS is more explicit and specifically brings in to scope systems that..may impact the security of (for example, name resolution or web redirection servers) the CDE. Under either version of the standard, Barclaycard considers the use of Silent Order POST mechanisms as bringing the merchant s e-commerce environment in scope of PCI DSS. Our advice is to act now if you are relying on Silent Order POST mechanisms to reduce the scope of your e-commerce environment. Re-validation All too often we see organisations falling out of compliance unnecessarily at re-validation. PCI DSS compliance activities should always be implemented into business-as-usual as part of an entity s overall security. Version 3.0 of the PCI Data Security Standard outlines the best practices which should be followed to help ensure security controls continue to be properly implemented year-round. Regular reviews should be undertaken to verify that appropriate evidence is being maintained for example, audit logs, vulnerability scan reports, firewall reviews, etc. to assist in preparation for compliance assessments. Barclaycard can help The award winning Barclaycard Payment Security team are leading experts in merchant payment security and PCI DSS compliance management. For further help and advice or to switch your card acquiring to Barclaycard please contact us on (lines open Mon-Fri 8.30am 6pm) or visit or us at PCI.Taskforce@barclaycard.co.uk