Information Security Kaizen
“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:
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.
SecureComputer is a blog about the pursuit of continuous improvement.
2 Responses to A CMDB of risk?
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.
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.