The Payment Card Industry Security Standards Council supplies organizations that process cardholder data with regulations to keep that data secure. Last November, the council released version 3.0 of the Payment Card Industry Data Security Standard (PCI DSS). Over the course of the next several months, organizations took steps to update their IT infrastructures to meet the new standard revisions, with the compliance deadline occurring this month. With harsh penalties for noncompliance, it’s no wonder that businesses are taking extra care to ensure that every single requirement is met seamlessly.
The Security Standards Council seems to be taking a slightly different approach with 3.0, emphasizing less the importance of compliance and more the importance of establishing a complete IT infrastructure capable of effortlessly protecting cardholder data across all stages of processing. To that end, the majority of changes made in the 3.0 update are clarifications to aid organizations in getting the most out of their data security systems, with the added benefits of guidelines and best practices. This shift of emphasis is a refreshingly forward movement, balancing the push toward innovation in data security with the necessity of still enforcing basic requirements that must be fulfilled.
So what are some of the 3.0 requirements that have been added or enhanced? Let’s break down the highlights:
PCI DSS 5.1.2 Requirement: Systems that are not usually compromised by malicious software now must be evaluated periodically to verify that no anti-virus mechanisms are required.
PCI DSS 5.3 Requirement: With limited exceptions, anti-virus mechanisms must always be actively running, with no alteration by users.
PCI DSS 6.5.10 Requirement: Coding practices, such as incorporating time-outs and flagging cookies, must now be in place to ensure authentication and session management stay secure.
PCI DSS 8.2.3 Requirement: Passwords strength and complexity must be increased, now requiring at least seven characters and both numbers and letters.
PCI DSS 8.6 Requirement: Each authentication mechanisms can only be used by one individual account, with physical and/or logical controls to ensure access can only occur via the intended account.
PCI DSS 10.2.5-6 Requirement: Changes made to identification and authentication mechanisms, user privileges, or accounts must now be logged, and any instance of audit logs being initialized, stopped, or paused must be logged.
PCI DSS 12.2 Requirement: Risk assessment processes should be performed after the environment has changed, in addition to an annual risk assessment.
With the rapid pace at which IT systems are advancing, organizations should not stop at simply meeting the minimum requirements. Rather, now is the time to move beyond 3.0 compliance to further the robust security measures already in place. In the face of these new additions, the question organizations need to be asking themselves is “how can we use these requirements as a springboard to further strengthen our data security infrastructure?” Hackers are not going to sit back in defeat just because an organization is PCI DSS compliant. They are continually researching ways to get around the current defenses, and organizations cannot afford to be any less vigilant than their malicious counterparts. The important thing for data security providers to remember is that the requirements established by PCI DSS represent the minimum necessary to be considered secure. Innovative security measures are what separate the organizations who are content with the bare minimum from organizations who understand the full importance of maintaining absolute security of sensitive data.
