(Continued from here.) The same risk management principles that help management hone and scope SOX audits general also apply to other prescriptive guidance, as well as IT frameworks and standards like the ISO 27000 series, CobiT, and NIST 800-series guides.

As for more descriptive rules and standards (PCI, HIPAA, FISMA, FFIEC, etc.), understanding how compliance and information security fit together and within the bigger GRC picture can help you reduce the compliance burden—particularly if your company is covered by multiple overlapping regulations.

Consider two scenarios:

1. Because many compliance implementations are project oriented and deadline driven, security managers focused on meeting one regulation or framework fail to see the overlap between their project and other security efforts.
    
2. PCI and HIPAA pains are compounded when covered information is not compartmentalized and security managers attempt to apply stringent control requirements to complex and distributed systems.
   

Enterprise information protection is fundamentally a risk management challenge. Regulations like PCI, etc., are not comprehensive in this regard since they cover limited types of information with fairly specific requirements that are, truth be told, reactive to threats and vulnerabilities identified in specific (past) security incidents. A risk management approach to security should be more comprehensive in both regards.

That said, compliance provides a handy excuse to codify sound security management processes in a limited way—test projects of a sort. In fact, limiting the initial implementation scope[1] can have several benefits beyond that of meeting compliance deadlines.

Executives like compliance. They fund compliance—often under less scrutiny than plain ole IT projects. I know of at least one IT manager who got an entire SAP implementation funded under SOX compliance. While most of us can't expect to get such largesse, wrapping an ISO 27001/27002 pilot project in a PCI banner (for example) might be more readily attainable.

This approach would benefit the PCI efforts, since ISO 27001 is the sort of security management framework that PCI could really use. Meanwhile, implementation of the 27002 control standard would hit the PCI requirements and more. The project itself would produce demonstrable results useful for supporting budgetary requests for standardized control roll-outs to systems beyond PCI's scope. And leveraging the managerial and technical lessons learned during the PCI implementation should provide a compelling argument for efficiency in scope expansion. 

This is just one example. Any robust framework for security management and control (ISO, CobiT, NIST/FIPS) coupled with any security mandate (PCI, HIPAA, FFIEC, GLB) could effectively follow the same model.

Zooming up a conceptual level, what we're really talking about here is standardizing and simplifying information security practices at an enterprise level—a GRC argument, sparked a compliance mandate. Security risk abatement is just one part of the picture.

I mentioned earlier that compliance is an incomplete approach to security, but various security rules overlap and all of them can be mapped [2] as subsets of ISO 2700x, CobiT, or NIST frameworks—collectively comprising a more adequate security approach.

Once you begin measuring other project-driven security projects against a proven, robust management and control standard, you'll almost certainly discover gaps and inefficiencies that weren't apparent in those projects' siloed environments. That's a risk management benefit. The governance angle is cost savings, consistent compliance, and reduction of redundancy and inconsistency. These go beyond IT controls to include audit processes, security management, and software investments.

ISO, CobiT, etc. can also be (and have been) mapped to enterprise risk management frameworks, maturity models, and project management best practices. Or, anyway, CobiT has. But since ISO is mapped to CobiT and CobiT is mapped to OCTAVE, CMMI, the PMBOK, etc., you can map the maps, do a bit of double checking by the source documents, and generate an ISO-to-OCTAVE map of your own.

Finally, if you want to get really ambitious (or possibly make enemies in high places), you can tie the whole enchilada to an IT investment management framework, like the one published (PDF) by the GAO. Your tax dollars at work.

Now, you might be feeling that very little of this has anything to do with why the bloggers (Remember the bloggers? This is about the bloggers.) are criticizing GRC. And that brings us to the subjects of vendors, software, and marketing.

The security bloggers' argument against GRC is really an argument against a relatively small spectrum of GRC that has shined on their work through the vendor marketing prism. But writing off the useful concepts of GRC because it's misrepresented by overzealous vendors is like hating the sun because it won't light your cigarette. ...Actually, it's more like hating the sun because you mistakenly think it exists to light your cigarette, but doesn't.

GRC is not a tool. That said, Christopher Hoff's observation that "GRC appears to be a way to sell more products and services under a fancy new name to address problems rather than evaluate and potentially change the way in which we solve them" has some merit.

From the vendor perspective, GRC represents a great new way to sell solution offerings to senior management having to make much of a development investment. Seldom in the annals of business software sales have vendors been able to tap such rich aquifer of fear, uncertainty, doubt. You bet they're going for it.

But GRC didn't start with the vendors and it doesn't end there, either.  The vendor reflection of GRC is simply a reflection. A more accurate reflection lives in regulations and standards. However, GRC itself is the business of running a business, and we should always be wary of letting vendors define that for us.

Recommend this article...

Comment

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