The requirements cover the six basic goals found in version 1.1, including building and maintaining a secure network; protection of cardholder data; maintaining a vulnerability program; implementation of strong access control measures; monitoring and testing of company networks, and the creation and maintaining of an information security policy. Within the six basic goals are 12 requirements that must be met in order to earn PCI DSS compliance.
There are a number of changes that financial institutions need to review in version 1.2 to determine the impact to their organization. Since the PCI SSC has established a life cycle process that will ensure the standard is revised on a two-year cycle, it is important to learn the differences early so the appropriate changes can be made in a timely manner. The items below cover the differences between 1.1 and 1.2 that will have the greatest impact to financial institutions.
Initially, it is important to note some of the key dates that are outlined in 1.2 and what they mean to financial institutions:
Oct. 1, 2008: 1.2 release date and effective date (all new assessments after this date will use version 1.2)
Dec. 31, 2008: 1.1 sunset date (all 1.1 assessments should be completed before this date)
March 31, 2009: New Wired Equivalent Privacy (WEP) implementations are not allowed after this date
June 30, 2010: All WEP implementations must be discontinued as of this date
If a company is in the process of an assessment, utilizing version 1.1 of PCI DSS, then it is allowed to continue using version 1.1. However, the assessments that fall into this category should be completed before the end of this year.
Additionally, the changes listed below are some of the modifications that financial institutions will want to review.
Version 1.2 has much stricter language with regards to compensating controls. For example, compensating control must be reviewed, documented and validated by an assessor annually. In addition, a compensating control worksheet must be completed for each compensating control. These changes emphasize the council's intent to make it more difficult for merchants to use compensating controls rather than meeting the requirements of the DSS. Auditors must evaluate and validate their compensating controls and maintenance behind securing the environment on an ongoing basis.
WEP encryption for wireless networks is prohibited for new networks after March 31, 2009. In addition, wireless networks currently using WEP encryption must migrate to industry best practices (e.g., IEEE 802.11i) by June 30, 2010. Financial institutions needs to be aware of these dates as they roll out new wireless networks or plan to upgrade current wireless networks in their enterprise. The emphasis is now on using strong encryption technologies for both authentication and transmission vs. specifying the type of technology to use.
The requirement of antivirus software having to be installed on all systems commonly affected by malicious software is stated by both versions 1.1 and 1.2. However, in version 1.2, the language stating that viruses typically do not affect Unix-based systems and mainframes has been removed. Financial institutions will need to interpret how the removal of this statement will impact the antivirus coverage in their enterprise. The change may indicate that all systems should be reviewed to determine if the threat of malicious software could now affect systems including Unix-based systems and mainframes. Although the reference to UNIX is removed, it does state that companies should deploy on such systems "if applicable antivirus technology exists." The definition of malicious software has been clarified to include viruses, worms, Trojans and rootkits.
Version 1.2 provides greater flexibility in the patch installation process. In version 1.1, the requirement specified that security patches must be applied to systems within a month of its release. Version 1.2 allows for financial institutions to apply their own risk-based approach. Patches still need to be applied, but companies can now prioritize the release of a security patch in their organization based on their exposure and their existing patch management process. This can allow financial institutions to apply patches to critical systems first and less critical ones later.
Version 1.1 required the use of video cameras to monitor sensitive areas. The new version provides the possibility of using other access control mechanisms to monitor access to sensitive areas. This can potentially include card keys or biometric access controls that would provide a date and time stamp upon access to sensitive areas. It is important to note that standard keys and keypads would not meet the new requirements, as they do not traditionally provide the ability to monitor access to sensitive areas. In addition, the clarification in version 1.2 expands the scope of video monitoring into areas that contain paper files. Many companies contain warehouses full of paper files, which now may require video monitoring as well.
Version 1.2 provides more detailed requirements when dealing with service providers (including shared hosting providers) that have access to cardholder data. Financial firms must maintain a list of all cardholder service providers and ensure that the service providers are PCI DSS compliant. This includes monitoring their compliance, maintaining a written contract with the service provider stating that they are responsible for the cardholder data, and establishing a vendor review process when selecting service providers to perform due diligence. These requirements force financial institutions to work closely with their service providers and be aware of their service providers' PCI DSS compliance status.
Scoping and selecting samples during reviews
Clarifications have been made in defining the scope and sample selections process during a PCI audit or review. Version 1.2 provides a flowchart that will assist an auditor in determining the appropriate scope for a PCI audit, thereby dictating the cost associated with the final product. It is important for financial institutions to review the flowchart and to implement the appropriate network segmentation to reduce the cost of the audit and at the same time, to increase the security of the cardholder data environment.
The changes listed above are only some of the highlights in the 1.2 standards document. Financial institutions should review all of the changes to understand what will be required by the next audit cycle, but overall the changes are unlikely to cause any major new compliance challenges. Most of the changes are incremental in nature and actually ease some of the mandates set by the previous version 1.1, allowing financial institutions to apply a risk-based approach and incorporate security throughout their existing business processes.
About the author:
Rick Lawhorn, CISSP, CISA, has over 18 years of experience in information technology which includes an extensive security, compliance, privacy and legal background. Rick has served as the Chief Information Security Officer (CISO) for GE Financial Assurance, Chief Information Security Officer (CISO) for Genworth Financial and served in information technology leadership roles within Hunton & Williams law firm and the National White Collar Crime Center. He has been published in numerous international and domestic security magazines and currently serves on several advisory boards for new, innovative security products. He can be reached at firstname.lastname@example.org.
This was first published in December 2008