It is not surprising therefore, that the E-commerce sector faces numerous challenges in order to protect itself from the growing threats from malicious individuals and organised crime looking to identify and exploit weaknesses in the payment process. The 6 leading worldwide major payment card brands established the Payment Card Industry Data Security Standards (PCI DSS) as a standard to protect cardholder data from such attacks.
The PCI DSS contain 12 requirements that are grouped within 6 core principles. If an organisation processes, stores or transmits cardholder data they will be in scope for PCI DSS. All E-commerce systems will need to be considered. In many circumstances, business owners in this industry do not have the resources or the technical knowledge to help reduce the risk of a data breach. Nevertheless, even large E-commerce merchants with skilled personnel also suffer breaches, one merchant was responsible for the loss of over 50 million card numbers.
PCI DSS compliance in practice
The first part of any PCI DSS compliance assessment is scoping. Without a thorough analysis of cardholder data flows (physical or electronic), a PCI project could miss vital areas, for example legacy systems, or over-engineer systems upgrades because the process wasn’t fully understood. The following are some critical areas that are typical for E-commerce environments, but could be overlooked:
- Log Files: Many E-commerce systems conduct online authorisations, with the full PAN being stored once the transaction has been completed. PCI DSS requires that PAN must be made unreadable (truncation, hashing, tokenised or by using strong encryption). Places that potentially could store this type of data, but are often overlooked include transaction files, debug files, back-up files, history files or application logs.
- Software Development: Companies who have developed their own web applications should
employ a developer who has experience in secure coding practices. It is essential that the coding is secure, as a line of insecure code could facilitate an entry point for a malicious user. An often overlooked area is the use of third party tools/libraries/scripts. Vulnerabilities in third party code may open a backdoor to E-commerce systems to drop malicious files or provide an entry point for an unauthorised user to steal database information containing cardholder data and/or other sensitive information. - Off-the-shelf packages: Organisations using third party payment applications are reliant on the security of these applications. Smaller retailers may purchase E-commerce systems which are in fact open source websites with minor modifications. These packages are often attacked as the underlying source code is publicly available and provides information on the security mechanism (or lack of) used. This may open holes within the E-commerce system to plant viruses, trojans or even worse, provide a malicious user with an opportunity to directly query databases that may contain a collection of cardholder and other sensitive customer information.
- Third Parties: A merchant is responsible for any agent they engage on their behalf. If an organisation relies on a third party to collect cardholder data, the third party must undergo a PCI DSS assessment, and if the third party is not PCI DSS compliant then the merchant is not compliant either.
- Post-authorisation: Storing sensitive authentication data (CVV/CV2) post-authorisation is strictly prohibited by PCI DSS. Indirectly Connected Devices: Any machines not involved in cardholder data processes but are logically connected to devices that do process, store or transmit cardholder data will be in scope. situation and their business. Although PCI DSS seems a long and daunting process with good planning and a clear road map, supported by an experienced and pragmatic QSA partner, compliance can be achieved. This will also put the business in a stronger position as there will be a greater understanding of how
systems work within the organisation, and also the identified potential risk areas. Business should also consider that the financial and reputational costs of a data breach could be far higher than the implementation of a PCI project.
‘PCI DSS is achievable with guidance and an effective roadmap’
Achieving PCI DSS
Some companies may first conduct a gap analysis and then remediate the problems. Sysnet recommends an initial scoping exercise is undertaken - this will review all systems, which will shape the extent of the PCI DSS project. It will also highlight areas of current risk that potentially could be removed with replacement systems or secure enhancements.
A scoping exercise offers options to manage to the size of the project by offering ‘as is’ and ‘what if’ scenarios to clearly demonstrate how change to the process impacts the scope. The organisation then has the opportunity to choose the option they feel is most appropriate to their
‘A commitment to protecting customer’s cardholder data 24/7 365 days a year’
Maintaining PCI DSS compliance Once the people, processes and technology are in place, re-assessment should become far easier. Many businesses use PCI DSS as an opportunity to introduce new hardware and operating systems, and merge disparate business processes – it is therefore essential that a full scoping review is undertaken
prior to engaging in any major project development. A commitment to PCI DSS is a commitment to protecting
customer’s cardholder data 24/7, 365 days a year.
How can Sysnet help?
Sysnet’s QSA consultants have significant experience with helping organisations attain and remain compliant with the PCI DSS. We have worked closely with many high profile organisations and have a wealth of experience in dealing with a varied range of payment applications that are currently being used.
For further information on our PCI compliance services, please contact one of our Sales representatives by calling +353 (0)1 495 1300 or by completing our Online Enquiry Form or Request a Call Back Form.