This New Year not only your resolutions, but your PCI Requirements also needs to be updated

Payment Card Industry Data Security Standards (PCI DSS) guidelines- Often seen as just another mandatory list to be check marked, PCI 3.0 is here to make that change. A significant step has been taken by the PCI Security Standards Council (PCI SSC) to make security and compliance an integral part of one’s organization and business.  PCI SSC had released version 3.0 of PCI 3.0 and Payment Application Data Security Standard (PA DSS), which marked the start of the latest, three-year compliance cycle for everyone dealing with card data-vendors as well as payment processors.

About PCI 3.0

PCI DSS was formed with the intention of providing an extra layer of protection for the card holder’s data. The motive was to ensure that the merchants dealing in customer card data in any form- whether storing, processing or transmitting it, followed some minimum level of security. On 15^th December 2004, the first version of PCI DSS, 1.0, was released.

In this blog, we will be discussing the latest version of PCI DSS 3.0, which was released in November 2013, had a transition period of one year and is now active from January 2015, with some exceptions.

With the new version, PCI compliance has become much more rigorous. In all, there are almost 100 total changes and out of these only 20 regulations are brand new. These numerous and significant changes make the transition from PCI 2.0 to 3.0, much more difficult and complicated than the one from 1.2.1 to 2.0 was.

We bring to you the major changes that will affect merchants and payment processors dealing with card data:

1. Penetration Testing – This was already a crucial requirement from PCI earlier, but the new version has added more emphasis to Penetration Testing. Requirements 11.3 and 11.4 mandate that if segmentation is used to isolate the cardholder data environment (CDE) from other networks, then penetration testing must also be performed on this segmented area to verify that is working effectively. Req. 11.2: This requirement mandates quarterly internal and external vulnerability scans and rescans as needed until all “high-risk” vulnerabilities (as identified in Requirement 6.1) are resolved and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).Req. 11.3: This requirement mandates internal and external penetration testing at least once a year and after any significant infrastructure or application upgrade or modification (e.g., OS upgrade, new sub-network or web server). These penetration tests must include both network-layer and application-layer penetration tests. Exploitable vulnerabilities found during penetration testing should be corrected and testing should be repeated to verify the corrections. Also, the penetration testing (internal and external) should now follow an “industry-accepted penetration testing methodology,” for example- the specifically referenced NIST SP 800-115, Technical Guide to Information Security Testing and Assessment. Therefore merchants must be extra careful about the security vendor they chose for penetration testing as this requires specialists who understand the rapid changes that come in the security industry constantly and are adept to handle them with finesse.
2. Secure System and applications: Requirement 6.1 and 6.2 respectively demand to identify and risk ranking new vulnerabilities and fixing critical vulnerabilities.Requirement 6.5 talks about updating developer training to lay emphasis on avoiding common coding vulnerability mistakes.Requirement 6.6: This requirement mandates that for public-facing web applications, new threats and vulnerabilities should be addressed on an ongoing basis and ensure that these applications are protected against known attacks by either of the following methods:

   a) Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes.
   b)  Installing an automated technical solution that detects and prevents web-based attacks (for example, a web application firewall) in front of public-facing web applications, to continually check all traffic.

3. Antimalware– PCI requirement 5.1.2 mandates merchants to “evaluate evolving malware threats for any systems not considered to be commonly affected by malicious software.” Thereafter the merchants should ensure that you have a process in place that will continue to keep these ‘systems’ safe, in case any malware emerges. Requirement 5.3 directs that “anti-virus solutions are actively running (formerly in 5.2),” and there should be specific authorization from authorized management to disable or alter anti-virus operation and this also can only be time-bound, not permanent. This requirement requires advanced technical planning and should be handled by only experts.
4. Physical access- Requirement 9.3 mandates merchants to control physical access to the sensitive areas for onsite personnel. This should also include a process to authorize access based on the job function, and the ability to revoke access immediately upon termination. Requirement 9.9 requires that the merchants should “protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution.”

Summary of PCI 3.0

Apart from these, we are sharing with you the summary* of the significant ‘evolving requirements’ that have to be implemented to comply with PCI 3.0:

a)      6.5.10: For coding practices to protect against broken authentication and session management.

b)      6.6: It mandates that it is no longer enough to just put a WAF or Source code review. Putting WAF in detect mode is no longer enough to meet the PCI criteria. It is important to ensure that all identified issues are fixed and again tested for, to confirm that they are fixed.

c)       8.2.3: Combined minimum password complexity and strength requirements into a single requirement and increased flexibility for alternatives that meet the equivalent complexity and strength.

d)      8.5.1: For service providers with remote access to customer premises, to use unique authentication credentials for each customer.

e)      8.6: Other authentication mechanisms are used (for e.g., physical or logical security tokens, smart cards, certificates, etc.) that the mechanisms must be linked to an individual account and ensure only the intended user can gain access with that mechanism.

f)       11.5.1: Implement a process to respond to any alerts generated by the change-detection mechanism.

g)      12.2: Moved from an annual risk assessment process and clarified that the risk assessment should be performed at least annually and after significant changes to the environment.

h)      12.8.5: Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.

i)      12.9: Service providers to provide the written agreement/acknowledgment to their customers as specified at requirement 12.8 ( which states- Clarified intent to implement and maintain policies and procedures to manage service providers with which cardholder data is shared or that could affect the security of cardholder data.

Conclusion

As per Avivah Litan, VP and distinguished analyst with Gartner, PCI DSS 3.0 is about 27% larger than its predecessor, meaning enterprises will be forced to implement more security controls.

These security controls have raised the bar against penetration testing and vulnerability assessment, and without a doubt, the challenges of specifically meeting Requirement 11 is huge. But with a carefully chosen vendor, these changes can be easily adhered to, and they will greatly enhance the security of your data. With 2014 turning out to be the year of breaches, security should be your prime concern for 2015, and PCI 3.0, no matter how complex, will only help you in getting there.

*Source: Summary of changes from PCI DSS version 2.0 to 3.0

Stay tuned for more relevant and interesting security articles. Follow Indusface on Facebook, Twitter, and LinkedIn.