Security and compliance are often used synonymously, even by techies. You can ensure compliance by remaining secure; but mere compliance with certain rules and regulations does not necessarily mean your network is ‘absolutely’ secure.

Many organizations, including some of the world’s prominent enterprises have faced IT security breaches and compromises despite remaining fully compliant with numerous regulations. As organizations embrace new technologies, new threats emerge as well. So, it’s obvious that security is an ongoing activity that requires constant attention.


Among the various compliance regulations the Payment Card Industry (PCI) Data Security Standard (DSS), popularly known as PCI-DSS, is one of the most widely adopted regulations across the globe. Any organization that stores, processes or transmits payment cardholder data is required to comply with PCI-DSS. Given the high volume of online payment transactions, PCI-DSS is easily the most popular compliance regulation worldwide.

Coming back to the security – compliance debate, PCI Security Standards Council, the organization that governs PCI-DSS, has rightly recognized the fact that the focus should be on security and NOT compliance. The council, which was founded in 2004 by five major card brands, released the first version of the PCI-DSS regulations the same year and the regulations are being updated periodically.

The current regulation – PCI-DSS 2.0, which was released during 2010, is now being updated. PCI-DSS 3.0, which is scheduled to come into effect on January 1, 2014 focuses on bolstering security and protecting cardholder data keeping in mind the present day threat landscape and advancements in technology, especially the proliferation of mobile devices.

The council has stated that the changes planned for Version 3.0 are designed to help organizations take a proactive approach to protect cardholder data that focuses on security, not compliance, and makes PCI DSS a business-as-usual practice.

The council has already released the highlights of the changes and will publish the version 3.0 on November 7, 2013. As the countdown has already begun for complying with the new set of regulations, it is crucial for all stakeholders to analyze the changes to assess current capabilities and plan well ahead to comply.

What is new in 3.0?

PCI DSS aims at six goals, structured into 12 requirements. The core 12 security areas of PCI DSS 2.0 remain the same in 3.0, but the updates will include several new sub-requirements that did not previously exist.

The new requirements mainly stress proactive security processes, including key management, password management, vulnerability assessment, log reviews etc.

Here’s a brief overview of a few of the important aspects:

Requirement 2:

  • Maintain an inventory of system components in scope for PCI DSS to support effective scoping practices.
  • Changing default passwords is required for application/service accounts as well as user accounts.

Requirement 3: Flexibility with more options for secure storage of cryptographic keys, and clarified principles of split knowledge and dual control.

Requirement 5: Evaluate evolving malware threats for systems not commonly affected by malware to promote ongoing awareness and to protect systems from malware.

Requirement 6: Update lists of common vulnerabilities in alignment with OWASP, NIST, SANS and other security organizations to secure coding practices and keep current with emerging threats.

Requirement 8:

  • Implement security considerations for authentication mechanisms such as physical security tokens, smart cards and certificates, to address requirements for securing authentication methods other than passwords.
  • Increased flexibility in password strength and complexity to allow for variations that are equivalent. Revised password policies to include guidance for users on choosing strong passwords, protecting their credentials, and changing passwords upon suspicion of compromise.

Requirement 9: Protect POS terminals and devices from being tampering with to address physical security of payment terminals.

Requirement 10: Clarifies the intent and scope of daily log reviews.

Requirement 11: Implement a methodology for penetration testing, and perform penetration tests to verify that the segmentation methods are operational and effective.

(Source: )

Overall the changes have been designed to give organizations a strong but flexible security architecture with principles that can be applied to their unique technology, payment, and business environments. While it is clear that the new set of requirements mandate a proactive approach to security and thereby achieve compliance as part of ‘business-as-usual’ practices, it is important to have a deep understanding on the broad expectations out of some of these requirements. We’ll discuss that in the next few posts. Stay tuned!

ManageEngine IT Security Solutions | Password Manager Pro – Quick Video Free Trial Download White Papers Success Stories