Thursday, May 22, 2014

New framework for IT Risk Management and Analysis

I've always been fascinated with risk management, it just seems that it is critical to everything we do, crossing the street, driving a car, or securing an enterprise.  All decisions we make seem to benefit from having the right information on-hand to balance out the pros and cons.  The more that people depend on those decisions (or are impacted by the consequences), the more valuable it is to make the right one.

Thus, about 10 years ago this year, I began the discovery process that felt more like I was uncovering a fundamental principle of risk management that was hidden or obscured.  The model that I developed has been very helpful for me, it gave me a mental context to leverage when designing security controls and helped to ensure that the right types of controls were present and established in the best order.  It represents the cumulative experience of my perspectives from Information Security, IT Governance, Security Compliance and IT Risk Management positions.

I applied my model in each of those roles continuing to improve it, and it has always benefitted those departments, services and functional processes.  I wanted to share it with others, so I presented it first in 2007 at an ISACA Silicon Valley Spring Conference where it was well received. One remark I received was, "This makes [risk management] so much easier to understand! Why don't they teach us this stuff?"

This is the Framework of Risk Management and Analysis (FoRMA):

It has 4 quadrants that represent the Risk Mitigation Cycle and 4 rings that represent the balance of Risk (Threat & Vulnerability) and Control (Technology and Process).

The primary idea is that as you go clockwise in each quadrant from Awareness though to Assurance, you pause to analyze the residual risk remaining and determine if you need to go further, spend the money and mitigate until the risk is within your comfort zone (i.e. the appetite the business has for risk vs. the business impact the risk would have).

You can use this model quickly in discussions to help consider security controls that are necessary in an architecture, an application, or system security.

There are many other possible uses for it as well outside of Information Security.  If you find a new way to use this, please let me know!

For more information, take a look at this presentation.