The Technology Side of GRC

Your compliance efforts should be risk-based, rather than merely security-focused. Understanding your enterprise’s risk profile and prioritizing compliance and remediation efforts based on risk has been a growing industry trend since Agiliance was founded five years ago, and the evolution of the PCI standard reflects that.

The PCI Security Standards Council recently offered a preview of the PCI DSS 2.0 and PA-DSS 2.0, to be released at the end of October. The new standard includes clarifications, additional guidance, and evolving requirements—but no dramatic new requirements. The most significant change, especially in terms of your compliance budget, is the tilt toward a risk-based process. Responding to stakeholder feedback, section 6.2 will now “allow vulnerabilities to be ranked and prioritized according to risk” as part of an effort to “align with changes in industry best practices.” This is an approach that Agiliance has been encouraging for some time.

Risks That Matter

The new PCI standard will formally recognize an organization’s need to identify the risks that matter most to their business and to focus finite remediation resources on their top priorities. In embracing a risk-based approach, PCI is following industry standards such as ISO 27001.

Enterprise executives have complained that they are spending a ton on compliance and security, but can’t get enough visibility, and are not seeing much benefit from their investment. What they are really saying is that compliance efforts are not focused on the risks that matter to their specific business.

Many merchants have chosen only partial PCI compliance, according to Computerworld blogger Eric Ogren, due to the “prohibitive costs…and people to administer it all.” By allowing companies to assess vulnerabilliities based on risk, an enterprise can now be fully PCI compliant while only paying to remediate the exposures that really matter. Your organization evaluates its risk posture in the context of its risk tolerance, and other unique factors, and pulling this integrated view together can be effectively automated.

Risk and the accountability for risk acceptance are, and should be, owned by the businesses that are creating and managing those risks. Tools can automate effective risk management processes, but the results delivered by these tools will be only as good as the underlying frameworks, processes and data structures. Risk managers should develop enterprise-specific definitions of risk, as well as an organizational structure that eliminates conflicts and overlaps in responsibilities among all risk-related specialists.

PCI Security Standards Council General Manager Bob Russo mentioned that the new rules mean that “you can talk about a vulnerability with a Qualified Security Assessor (QSA) and economize for risk tolerance within your business circumstances to make it more flexible.”

Using an IT risk management tool to assess and categorize your risk profile across the enterprise helps identify those remediation efforts with the biggest impact.

Focus on the Big Picture

When you are prioritizing vulnerabilities, you need to consider the big picture, the whole enterprise.  The top priority in a small department of your organization might not be important relative to the overall situation.

Security products often bring a narrow, tactical perspective that can create data silos and distract from the strategic view. Gartner Research, in response to the PCI 2.0 preview, recommends “Continue to avoid working with assessors or vendors that push their own remediation services or software.”

The rumors (started by security vendors) that the PCI 2.0 standard would mandate specific tools such as Data Leak Prevention applications turned out to be unfounded.  The new standard seems to require a formal process or methodology, not necessary a product, that locates and documents all sensitive data in an enterprise, which has been a practice that IT-GRC products like Agiliance have promoted for years.

Some of the security products can lead to “audit-fatigue” by producing false-positives in thousands or millions. The output of such products needs to be analyzed with a risk-based lens.

Security tools generally produce low-level information, rather than risk-based analysis that is actionable by business users, auditors, or high-level business governance and policy decision makers. As the diagram below illustrates, the Risk Management function supports prioritized remediation, for example, unlike security tools alone.

In contrast with a tactical, security approach, a risk-based assessment of the entire enterprise can take remediation efforts to the next level. By pulling all the issues into a central repository for analysis, the enterprise gains visibility, eliminates silos, and can cut down on manual or repetitive tasks.

All compliance expenditures should be driven by a risk profile. Each item—vulnerabilities, compensating controls, findings, exceptions, or other elements—should be presented in an IT Risk Management tool in a risk context.

When selecting an IT Risk Management tool, make sure that it automates data collection and offers regular synchronization with your assets and patch management tools. Some products start with a one-time import and grow outdated over time. Others require manual effort to link vulnerabilities to your enterprise IT. A tool that receives automated feeds from your environment and automatically correlates the data for analysis, not only reduces manual effort, but also gives you continuous visibility of risk across your enterprise. The new PCI standards encourage you to prioritize risk management based on this holistic view.

PCI DSS 2.0 and PA-DSS 2.0

PCI has been a rapidly changing standard, but in response to feedback received, the standard will begin a new three-year lifecycle from now on.  While this may not be great news for vendors who tout their gadgets for addressing upcoming PCI standards, we see this as good for companies that comply with the standard. However, it puts more responsibility on individual companies to follow a proper process to identify and manage their risks.

Besides emphasizing a risk-based approach and switching to a three-year update cycle, other notable highlights are a new scoping methodology, coverage of virtualization, and a PA-DSS requirement for centralized logging.  The new standard does not seem to require any new security tools.  Although Visa published a separate best practices for Tokenization, even it did not make the cut for this PCI revision. The new PCI standards will be released October 28 and will be effective January 1, 2011. Agiliance will release revised PCI content within days of the standard’s availability.

Specific Recommendations

1. Use risk-based techniques for prioritizing compliance efforts. Expect some savings in compliance costs in 2011 from this change alone.
2. Defer unnecessary security products sold as PCI requirements, in favor of an enterprise-wide understanding of your risk exposure and your organization’s prioritized risk.  Invest in IT risk management systems and processes to cut compliance cost.
3. With the new three-year lifecycle, plan for the next evolution of the PCI standard (v3.0) no sooner than end of 2013.  There may be minor updates with clarification and guidance, but new requirements are not anticipated until PCI 3.0, which would be effective Jan 2014. This would provide stability and significant cost savings.

The PCI standard released at the end of October may not exactly match this month’s preview, but changes this late in the standards process usually amount to fine tuning. I’ll discuss other PCI 2.0 changes in more detail in future articles.