0 Results Found
            Back To Results

              New PCI Compliance Rules Require Defined Process to Identify and Risk Rank Vulnerabilities

              As of June 30, 2012, the Payment Card Industry Data Security Standards (PCI DSS) require merchants to have a process in place to identify and risk rank newly-discovered vulnerabilities in order to be PCI compliant. As a best practice introduced in PCI DSS v2.0, proactive organizations should have already begun the process of implementing this requirement.

              If you're just beginning to implement PCI requirements, it is the perfect time to review how your business identifies threats and put in place a framework that allows all of those various sources of threat data to be consolidated and normalized in a vulnerability risk ranking framework that fits your business. If you have an established PCI compliance program, it affords an opportunity to review what you have in place now, and determine whether or not it meets the updated guidelines.

              The evolving vulnerability management requirement is a bit like a new driver learning to look down the road ahead and pre-empt hazards, rather than staring at the bumper of the car just in front and hoping to react fast enough to the brake lights. The intent is to ensure that businesses pro-actively seek information on new vulnerabilities that might affect their systems, and not simply wait for vendor updates and patch announcements that could come weeks, months or even years after vulnerabilities are discovered.

              Threat and vulnerability data can be collected from a multitude of sources, many of them free. For example, you can monitor relevant forums and newsgroups, create Google Alerts, subscribe to security-related RSS feeds and vulnerability disclosure mailing lists, and purchase commercial threat intelligence services as well as internal vulnerability identification and reporting processes such as pen testing, software code review and so forth.

              The risk ranking framework should be able to take all of this information and produce an easy-to-understand output (i.e., high, medium, low) that gives a clear indication of the level of risk a vulnerability poses to your PCI DSS data assets and your business. You must also factor in that per PCI DSS v2.0 requirement 6.5.6, secure application development processes must include mitigation techniques for all relevant vulnerabilities identified as falling into the "high" category.

              Recommended foundations for this risk ranking framework include the CVSS 2.0 model and NIST SP 800-30. Ensure that when documenting your risk ranking process you state which industry best practices and standards you are building upon, as you'll need to show this to your QSA.

              Related Content