Change Management is blind. It is a key IT Service Management process and, undeniably, it's beneficial to plan and schedule changes. But Change Management’s ‘dirty little secret’ is that, despite the comfort blanket of documentation and approvals, you never know what’s really going on.
You have no idea what was actually changed, either during the Change Window or at any other time.
Why does that matter? First, you don’t know if the changes you wanted were correctly implemented, in spite of all that planning. And from a security standpoint, you have no way of distinguishing between legitimate IT activity and a stealthy cyber-attack. This is why, according to the 2020 Cost of a Data Breach Report by IBM, the average time to identify and contain a data breach is 280 days.
It’s a key illustration of the differences between the priorities of ITSM and Security. ITSM relies on an accurate CMDB, assembled using built-in capabilities like the ServiceNow MID Server. A CMDB is an inventory of devices, with details of the hardware make-up and software installed. The focus is on the physical asset and its headline configuration attributes: For example, Windows 7 or 10? Office 2013 or 365?.
But this level of detail falls well short of the security best practice of system integrity monitoring. The aim is to detect indicators of compromise, but these can be subtle. They end up masked by the torrents of regular everyday activity. Change Management may be a foundational security best practice, but the demands of cybersecurity mean we need an upgrade on the typical ITIL approach.
At the heart of the issue is that the ITSM and Security teams don’t go to lunch together. Not only do they eat separately, they continue to operate their own siloed solutions for integrity monitoring and inventory management. This leaves us with a major missed opportunity. If Change Management could instead be operated as Change Control then the benefits for security and IT operations would be valuable.
Change Control differs from Change Management because it affords complete visibility of all changes, right down to a forensic level. Any edit to a config file is exposed, equally, a modified registry value or file attribute will be reported. If the goal is security, the need to control vulnerable configuration settings and detect hacker activity makes this level of scrutiny unavoidable. The challenge then shifts from not knowing what is going on, to dealing with the resulting information generated. No wonder the terms of ‘change noise’ and ‘alert fatigue’ go hand in hand with traditional FIM approaches: If you turn up the volume to max, you will need some good noise reduction. Once you cut out the background hiss and pop of regular, everyday changes, the occasional note of breach activity - if and when they appear - will be crystal clear.
By shifting our thinking so that the objective is not to just manage change, but control it, then this new hybrid discipline of SecureOps (short for Secure Operations) would begin to solve the problem of security.
If SecureOps is going to make it, we are going to need innovations in a number of areas, such as:
- Integration of ITSM and Security functions: The flow of Change Requests into appropriately focused system integrity monitoring should be seamless, with unplanned change activity fed to the ITSM platform as Incidents.
- Automate analysis and reconciliation of actual changes detected with Change Requests: By adopting a deep, microscopic level of tracking, this needs to be matched in equal measures by improved capabilities in automated analysis. Harnessing file whitelisting services provides a useful ‘second opinion’ to anti-virus systems and reduces the number of incidents requiring the Security Analyst team to investigate.
- Cut-out Change Noise: Self-learning capabilities that recognize the difference between known-good patterns of change and unexpected behavior are a key innovation. By automatically recognizing and de-emphasizing on-going ‘business as usual activity’, such as patching, this puts the remaining, and potentially malicious, changes right in the spotlight.
SecureOps really is the next logical evolution for ITSM. As IT systems become more reliable and easier to maintain, the emphasis is shifting onto the growth areas of security. By making security as embedded and as well understood as other IT best practices, we will eventually be able to operate services which are not only secure, but reliable too.
When it comes to security and change management, one thing is clear – no more dirty little secrets.
Share this post