Four steps to meeting your PCI compliance goals

Are you struggling to meet your PCI compliance goals? If so, then the latest study from broadband and communications services provider Verizon may be able to help.
Verizon’s recent annual Payment Card Industry Compliance Report showed that only 21 percent of respondents were fully compliant during their initial audit and that organisations particularly struggle to comply with PCI requirements 3 (protect stored cardholder data); 10 (track and monitor access); 11 (regularly test systems and processes) and 12 (maintain security policies). If your company struggles to comply, you may find the following recommendations useful:

• Treat compliance as an everyday, ongoing process. Compliance requires continuous adherence to the standard. This means a daily log review, weekly file-integrity monitoring, quarterly vulnerability scanning and annual penetration testing. To achieve this, Verizon recommends that an internal PCI “champion” ensures that compliance becomes part of daily business activities.
  
  
• Self-validate very carefully—or not at all. Level 1 and 2 merchants—which process the highest volumes of cardholder transactions—are allowed to assess themselves against the standard. Due to the numerous issues and conflicts of interest this can cause, Verizon highly recommends that an objective third-party validates the scope of the assessment or perform the testing.
  
  
• Be consistent with your interpretation/implementation of penetration testing and vulnerability scanning. The requirement for penetration testing has been around for more than three years, but many clients do not yet understand it or its implications. The requirement states that penetration testing must take place at least once annually or after any significant network or system change, including upgrades to the operating system or code changes for web applications. However, many companies still neglect to follow these directives. For instance, a company may remember to do the test annually but forget to do so again after a change. Or, more typically, it performs the test but does not validate the scope of the testing; consequently, it is required to perform the test again on in-scope systems, resulting in a loss of time and money. But perhaps the most frequent problem is that an organisation will procrastinate and perform the test or scan at the last possible minute of an assessment. Invariably, the result is that are some 100 to 200 findings to remediate and no hope of getting them all done in time. This will cause the report of compliance (ROC) to be delayed and the compliance deadline missed.Prepare to have the bar raised. In October 2010, the PCI Security Standards Council announced PCI DSS version 2.0. This version requires a more stringent executive summary and validation of methodology for scope definition. Organisations, many of which are having severe issues complying with the existing standards, need to quickly get ready for the new version.
  
  
• Beware, or at least prepare, for PCI DSS version 2.0. In October 2010, the PCI Security Standards Council announced PCI DSS version 2.0. This version requires a more stringent executive summary and validation of methodology for scope definition. Assertions that would have previously been accepted at face value will now require documented and detailed evidence as proof. In brief, the bar will be raised considerably with the new version and the wise IT and security director will begin to get his ducks in a row now rather than maintain the status quo.
  

Related articles:

• Safe and secure--what you need to know about PCI DSS 2.0
  
  
• PCI compliance and emerging technologies--reducing the scope of PCI compliance