Detected Changes are Incidents
As we cover in Visible Ops, the use of a detective change control can really reinforce the adoption of Change Management and then be used to report all changes thus allowing for tighter control of operations, an improved security posture, and so on. In Visible Ops, one of the catalytic changes is empowering the Incident Management team with detected changes so they can answer the golden question of “What Changed?” One thing to consider though is how to handle the detected changes to make this possible.
From an ITIL perspective, alerts from automated tools are considered Incidents. In ITIL, an Incident is essentially anything that is not part of the normal operation of a service, and that causes, or may cause, a disruption in service, or a reduction in the quality of the service.
By handling the detected changes as an Incident, the Configuration Management Database (CMDB) tool can then be used to appropriate log, assign the Incident and track progress. Then, when new Incidents are logged, matching can be performed and the person responding can immediately see related change detection data.
Furthermore, the CMDB can then be utilized to relate the detected change activity to services, impacts can be assessed and the necessary stakeholders notified – ideally all within the CMDB, which will allow for automated workflows to be leveraged, proper audit trails to be established and so on. The more activity and data we can track and relate in the CMDB, the better. Note, with that said, a CMDB can be the federation of several systems into one logical model so the data may actually reside in more than one database.
By capturing detected changes and ensuring the data is either in the CMDB, or properly related and accessible to the CMDB, we can then empower ITIL process areas to make use of the data for appropriate decision making.