PCI DSS for E-commerce & M-commerce: Definition, Challenges and Remediations

• Public facing environment / Open for attack:
  E-commerce has public facing environment which means it has a larger risk surface for external attacks. E-commerce sites are lure points for Hackers, as it has money as well as other personal data

• Behind the firewall: A secure Network Architecture with adequate security configuration is not only a must to secure e-commerce, but also for PCI DSS compliance
• 3-Tier Architecture: Though PCI DSS does not mandate separating Web and Application components is advisable to have three tier architecture
• WAF (Web Application Firewall): As for e-commerce environment, application is the most important and critical component. A layer of Web Application Firewall can do a lot, especially if you have application where doing Application security Test after ‘every change’ is not practically possible. PCI DSS Requirement: 6.6 has given option between Application security Testing and WAF
• Layered Security approach: Creating security at each layer; Network, operating System and Application is base rule to secure Account data
• External VA and PT: All External interfaces must be scanned and tested at least every quarter (Penetration test is required annually). What is here is more important is not to perform scans and test, but to mitigate the identified vulnerabilities more aggressively and doing rescans/and tests

• CHD as well as SAD present in environment:
  It has to be noted here that if data in transit is intercepted / compromised it will give access to not only to cardholder data but to Sensitive Authentication data also which means all information is there to do ‘easy’ fraudulent transactions

• Communication Security: Protect the account data while in transmission by through encrypting the channels or data itself. PCI DSS requirement 4.1 talks about protecting card holder data over open public network. It does not mean that there are no controls required while sending cardholder data over internal Network. Requirement 6.5 needs to be referred here; we have to ensure account data is secured if communicated through email, chat or voice channels
• Do Not Store SAD post Authorization: Base Rule of PCI – ‘Do Not store SAD after Authorization’. Merchants need to know that SAD cannot be stored even if for recurrent transactions / returning customers

• Data storage:
  Cardholder data at storage can be single point of compromise for bulk data. Stored data need to be protected from external as well as Internal Threats

• Only store if your business need it: Before you start storing the cardholder data, the need of storage should be formally documented (business/legal). There are risk and overhead costs like encryption, key management etc. involved when cardholder data is being stored. Elements of cardholder data need to be identified which are required to be stored
• Know your storage, scan the systems: It is very critical to know that where the Account data is getting captured knowingly and unknowingly. A deep analysis of data flow, traffic and cardholder data scan can help in this
• Retention and disposal: Retention period must be defined based on the business need , identify all systems which are storing cardholder data like file servers and databases for persistent cardholder data storage and systems which are getting card number during operational activity like file upload or data conversion, but not supposed to store cardholder data. For both locations cardholder data must be securely deleted with the help of system utilities or software
• Chose requirement 3.4 control to protect CHD as per Business Need: Requirement 3.4 gives four methods of protecting PAN (mentioned below), before implementing the same, the answer of ”why it is being stored” needs to be identified

1. Hashing- When card number are being stored for comparison purposes like comparing entered card number from blacklisted cards

2. Encryption- when clear text card numbers are required to perform an operation like ‘express checkout’ service

3. Truncation-  When full card numbers is not required and first 6 and last 4 digits of PAN with other parameters are sufficient to identify particular entry like MIS reporting

4. Tokenization-  when applications and systems can perform the operations with tokens instead of actual card

• Application Risk:
  Even after so many years known application vulnerabilities, still application level attacks are easier target for the attackers.

• Segregate Payment Application from Merchant Application: It is very helpful in reducing scope as well as in risk reduction by separating payment systems from rest of the merchant environment
• Secure Coding Practice: A secure coding practice can eliminate lot of risks at the first level itself. It has to be ensured that security should be considered in all phases not just limited to testing phase. OWASP and CERT secure coding guideline can be referred for the same
• WAF: Though PCI DSS Requirement 6.6 gives option between web application security scan and Web Application Firewall, doing web application security scan after every change is not practically possible in an environment where changes are frequent. Web Application Firewall can be used instead, to secure e-commerce environment
• Application Security Testing: Identifying security vulnerabilities in the application has been an Achilles’ heel for e-commerce security.  An in-depth application security test can help to address these
• Memory Scrapping Attack prevention: It was assumed that memory parsing and scrapping is targeted at POS systems, but e-commerce is also vulnerable to Memory Scrapping Attack which can be prevented by protecting data in volatile memory

• Service provider’s-Third party data center / cloud hosted environment and Payment gateways:
  Integrating with non PCI DSS compliant entity not only impacts the merchants PCI DSS compliance effort and cost but also increases the risk too.

• Select PCI DSS compliant Service provider: Before integrating with any data center provider or payment gateway it’s compliance status need to be validated by reviewing Attestation of Compliance (AOC)
• Monitor Compliance Regularly: Service provider’s compliance  must be validated every year by asking service provider to submit Attestation of compliance (AOC) and Report of Compliance (ROC)
• Know your part of responsibility: There must not be any grey area in terms of addressing any security and PCI DSS responsibility. For each PCI DSS control area, the responsible party should be identified and documented.By integrating with a PCI compliant Payment gateway does not eliminate the PCI DSS requirements for the merchants. But it can help you in reducing your scope for PCI Compliance

• Other payment channels may be included:
  Though we are talking about ecommerce, most of the ecommerce companies are facilitating other payment channels like swiping the card on POS machine provided by delivery boys. There may be other ways through which cardholder data may be coming into the environment, like though calls for chargeback or dispute resolution.

• Cash on delivery/mPOS, Call center, Mobile channels: While assessing flow of cardholder data consider all channels and cardholder data scan need to be performed in complete environment to ensure no payment channels handling cardholder data is being missed out

• Security Beyond compliance:
  At the end of the day we need to remember that PCI DSS is a compliance standard not specifically designed for ecommerce. Even a hacker knows that what area will not be addressed by PCI DSS compliance standard. For example; PCI DSS allows installing security related patch in one month of its release, but this may be leaving some loopholes.

• Risk Based Approach: To address specific risk, a risk based approach need to be taken specific to Cardholder Data environment. Account Data has to be considered as a primary asset and related threats and vulnerability including people, process and technology need to be included. Risk Assessment has to be performed based on formal Risk Assessment methodologies like OCTAVE, ISO 27001 , NIST SP 800-30 etc.
• Training and Awareness: Even if you have all other controls in place, people can be a weak link if they are not aware of the risks. Formal security awareness training should be part of any PCI DSS compliance program