A CMDB of risk?

In: Governance|Visible Ops Security

8 Aug 2010

“A different language is a different vision of life.” – Frederico Fellini

The heart of ITIL is the CMDB, where we centrally inventory all of the things that we care about.   ITIL and the CMDB allow a variety of groups to plan and work with common information and a common vernacular.   Why doesn’t the risk community extend the CMDB to measure risk?   Is it not equally desirable to have a central store of risk information that provides unified risk assessments and unified risk language?   There is tremendous leverage to be gained if our information security staff, compliance staff, business continuity staff, auditors, risk managers, privacy officers, legal staff, and others could agree on a single set of criteria for measuring the inherent risk associated with our systems.   Without a CMDB of risk, we:

  • Create the possibility that all of these groups assess risk independently and differently.
  • Allow duplicate and possibly inconsistent risk assessments within the same organization.
  • May miss critical dependencies.   For example, if I have a mission critical activity subject to the highest levels of regulatory scrutiny, then all data feeds through this system may need to be elevated to the same level of importance.

If your organization’s CMDB reflects business processes, then it should be simple to extend the CMDB’s schema to include such information as: inherent risk ratings, regulatory impacts, and the data of the last risk assessment.   Even if this requires some rework to accomplish, it strikes me that the payback would more than justify the risk through simplified, consistent, and repeatable risk management.

2 Responses to A CMDB of risk?

Avatar

The IT Skeptic

August 8th, 2010 at 9:30 pm

“The heart of ITIL is the CMDB”? No it isn’t. Not unless you are looking at ITIL from underneath.

the heart of ITIL is the service catalogue.

The catalogue makes a fabulous platform on which to base risk analysis. You will want to use the CMDB to drill down into the composite CIs to analyse risk further, if you are one of the very few sites who actually have a working CMDB with true relationship mapping from services to other CIs.

otherwise you will start from the catalogue and work the bill-of-materials out on the fly analytically like 98% of the world does.

Avatar

Hubert

August 18th, 2010 at 7:21 pm

AJ – great point. Would be glad to have access to that sort of data. On the other hand, I’m not sure I’d want to see it in the CMDB.

I agree that this would be a valuable extension to the CMDB. However, it would not qualify as a comprehensive “risk language”. Not all risk factors are system driven, and many are not technical in nature. The CMDB doesn’t capture how the organization uses a particular technology (except in the most technical sense), it provides only a fairly superficial link to business processes, and it does not cover factors such as user training and employee loyalty (key risk factors).
I see more value in linking CMDB structures with GRC data, where risk information can be more holistically maintained.

About this blog

SecureComputer is a blog about the pursuit of continuous improvement.

  • Hubert: AJ - great point. Would be glad to have access to that sort of data. On the other hand, I'm not sure [...]
  • The IT Skeptic: "The heart of ITIL is the CMDB"? No it isn't. Not unless you are looking at ITIL from underneath [...]
  • A.J.: Robert, Thank you for the feedback. Paul and I (along with co-authors George Spafford and Jim Re [...]
  • Robert E. Davis, MBA, CISA, CICA: Excerpt from [...]
  • A.J.: Hubert, Thank you for the comment. My intention was only to indicate that outsourcing may [...]