It seems a few infosec bloggers here, here  here (read the comments, too), and here have lately been putting the security cart before the GRC horse and then yelping that horses don't work and we should all get back to pulling the cart ourselves towards town.

This conceptual condemnation of GRC is worth addressing for two reasons. Firstly, while GRC is much more than just information security, separating the two makes both somewhat pointless. Secondly, understanding the bigger scope and interrelationships of governance, risk management, and compliance can actually help relieve some of the meta-pains of audit scoping and compliance costs that plague both IT and information security folk. [More...]

As a disclaimer, I'll admit I like the term GRC, despite its slick acronimity and marketing smack. It's a rare acronym that means more than the sum of its interrelated parts. Take out any component and the other two are degraded. Risk management and compliance provide focus for governance. Governance and risk management provide relevance for compliance. Compliance and governance provide oversight for risk management. Three great things that go great together—or should, anyway.

What do these components entail? Governance is the whole of oversight structures and activities that shape business (and IT) activities. Risk management is a subset of governance that weights and prioritizes business activities according to their impact or value in marginalizing negative contingencies, per their relationship to defined business goals. Compliance should be a subset of governance efforts that meet specific criteria of regulations, policies, and laws.[1]  Naturally, compliance and risk management overlap (and both overlap governance); however, risk management generally addresses a broader scope of business and IT efforts than mere compliance requires.

At least one of Brightfly's members likes to tack an S for security onto GRC. His logic is that security is at least as big an issue as compliance, so it deserves equal strategic consideration. While I see his point, I feel it's like saying the earth has eight continents—seven land, plus one water, No doubt, security is a massive concern, but its nature is pervasive, not inclusive.

Moreover, and to the fallacy that security is equivalent to compliance, information security is pervasive in just one aspect of governance, risk management, and compliance. Information is, after all, only one type of business asset that GRC should address (note that COSO and the SOX audit standards imply security only obliquely, via information integrity requirements). Even under the lesser umbrella of information GRC, many concerns—such as technology investment management, communications, e-discovery and content management, and business intelligence—only tangentially consider security goals.[2]

Understanding how security fits in the big picture, but is not itself the big picture, is critical to successful enterprise security management. Security should be everywhere—explicit in every new project plan; inherent in the concept of every business process; integral to every risk consideration, and implicit in every governance realm. But to get the executive and managerial support that business integration requires, we must give up the notion of security as its own goal and champion it in terms of (can you guess?) business governance, risk management, and compliance.

Tying security to the business had benefits beyond propagation, however. From a conventional security perspective, risk management is seen as an output of security programs: more security equals less risk.

By contrast, the business perspective defines risk as an input: risk thresholds define control efforts and audit scope.

If you've read the blog threads cited above, you've seen references to the embittered notion that compliance actually impedes "real" security by forcing security managers to focus on hitting audit targets instead of setting their own priorities. Audits, however, should adhere to business risk.

SOX auditors, for example, care about security because it ensures confidentiality, integrity, and of financial information. But the scope of SOX audits is defined—even limited—by what the business defines as material. Security audits, insofar as they're implied by SOX, should be subject to the same scoping.

The PCAOB's Audit Standard 5 (AS-5) is fairly explicit on this matter. Management, not auditors, defines risk and materiality, and auditors are advised to trust managerial judgment. AS-5 is actually largely a regulatory response to managerial complaints that external auditors were auditing too much (and charging too much) to review controls that had no material impact.

Managers, including security managers, can use AS-5's risk management principles to give pushback to both internal and external auditors on audit scope. Since SOX defines materiality as component of compliance, compliance priorities should never force security managers to favor irrelevant efforts. 

Of course, SOX is just one fairly prescriptive law, although the same risk management scoping can general apply to any prescriptive guidance, as well as IT frameworks and standards like the ISO 27000 series, CobiT, and/or the US government's NIST 800-series. Meanwhile, as you're probably painfully aware, banking, health insurance managers, retail, government agencies, and other industries are also subject to more descriptive rules and standards, such as PCI, HIPAA, FISMA, and FFIEC.[3] Understanding the bigger GRC picture can also help reduce the burden of these efforts, particularly when a company is covered by multiple security regulations.

More on this tomorrow.

--- 

Footnotes 

1. Compliance pursued blindly isn't a defensible priority of risk management.
   
   
2. Or not. An increasing focus on process-oriented IT—technology defined and valuated only in terms of the business processes it supports—is causing some of us to reevaluate whether information security should always be managed only as as a component of other processes. If you've seen recent articles or blog chatter about the "death of infosec" (a concept understandably abhorrent to many infosec practitioners) that argument reflects this shifting concept of what security is: an attribute of processes or a process unto itself.
   
   This is part of why it's so important not to define GRC as information security. The chaos and gappiness of, security as we know it today, is a transient, reactionary response to companies' frenzied realization that they should have been protecting information all along. Most efforts in dedicated security practices now focus on remediation: instilling security in existing legacy applications, systems, and processes that lacked them before. We have a long way to go; however, the foreseeable evolution of security practices is less catch up and better integration. Not so much killing security, but rather bringing it back from Coventry.
   
   
3. Of course, some of these are nearly the same thing. HIPAA, FISMA, and FFIEC requirements all refer to the NIST information security guidelines. In terms of information security, the technical requirements for all are similar, although the regulations cover different types of information. The new NIST Special Publication 800-66 (PDF) handily parses and compares the provisions of HIPAA, FISMA, and NIST publications.
   
   The PCI Data Security Standard (PCI DSS) is effectively a subset of the ISO 27002 standard; which, while less specific than NIST in terms of technical requirements, sticks to common security concepts.
   
   

Recommend this article...

Comment

Only registered users can write comments.
Please login or register.