Configuration Management - Intelligent Change Control
No more guesswork - Identify exactly what changed, where, when and by whom. Changes are automatically reconciled with Planned Change details so you even know the 'why'.
Every single change evaluated automatically, every suspicious change exposed
Gaining visibility of system configuration changes is the only way to operate secure change control. But full-visibility without automated analysis intelligence just leads to noise with unapproved changes left hiding in plain sight.
If you don't have Closed-Loop Intelligent Change Control, you are making Configuration Management unworkable.
Streamline operations from RFC to QA Testing – close the loop with seamless automation
Don't invest in formal change control procedures and IT Service Management technology just to shut your eyes to what actually happens during the implementation phase.
You only get Closed-Loop, Intelligent Change Control with NNT Change Tracker.
We cover it all, for all platforms, in a scalable, enterprise solution.
Change Control FAQs
Breach activity gets obscured by patching 'noise' - How does Closed-Loop Intelligent Change Control deal with patches in a secure environment?
Traditionally the requirement for change control has been to specify a time-window within which changes are known to be made. By limiting changes to a specific period of time, any changes then detected outside of the Planned Change period are assumed to be breach activity and treated as Security Incidents. Of course, in reality, 99% of the time these changes are either
- emergency changes made without recourse to the planned change procedure
- delayed patch deployment, due to waiting for a server re-boot
- and any other change activity that happened to bypass the Planned Change procedure, because support staff are human and Change Control sometimes gets in the way
With Closed-Loop Intelligent Change Control, changes can be promoted to the baseline so that other occurrences of the same change – even past changes - are pre-approved and not flagged as security incidents. This means that changes can be automatically reviewed and approved across an estate, even for thousands of changes and devices. Pre-Approved patches can be deployed over a prolonged period of time and still recognized automatically as 'know good' changes.
All this means that change control is much easier to administer, but also much more precise, therefore making it a far more effective breach detection process.
How do you ensure configuration changes don't affect security or impact compliance?
There is a natural cycle of assessing systems for vulnerabilities and compliance, mitigation and remediation action taken to minimize the attack surface, then exercise change control to ensure only pre-approved changes are made after undergoing a security impact analysis, then re-scanning systems to assess compliance again.
Traditional vulnerability scanners tend to be used sparingly to avoid exerting too much load on the network and host systems so there can often be a 'security status unknown' period between changes implemented and the next scheduled scan, potentially leaving systems vulnerable to attack. Then there are the changes that you don't even know have been made. Emergency changes needed urgently, or changes that are made and bypass change control for expediency, and of course, this includes cyberattack activity, be it from an insider or external hacker.
These changes all need to be made visible and reviewed as soon as possible – malware could be stealing data or damaging systems without anyone being aware – but a vulnerability scan wont help since traditional scanners are completely blind to breach activity, zero day malware and APT infections.
The only solution is to operate a system-wide file integrity monitoring function. Not only will this detect and report all changes made, but in real-time, seconds after a change has been made. Changes detected can then be assessed automatically to assist with compliance, vulnerability management and change control. Was the change a known pre-approved Planned Change? How does it impact compliance and the system's attack surface? If the change is not recognized as a planned change, escalate for review - should it be remediated?
Change control gets in the way of operating IT for our business: Can security best practices and business-as-usual IT operations co-exist?
Nearly all organizations, regardless of size, struggle to some extent with configuration management and change control. The need to review changes in advance of making them, to formulate impact analysis, testing procedures and contingency plans all serves to slow things down. No wonder so many IT Professionals acknowledge the potential benefits of Change Control while outlining reasons why it just doesn't work for them.
Formal IT operational frameworks such as COBIT and ITIL strongly advocate the need for change control but it can easily become an overwhelmingly bureaucratic strait jacket that impairs the organizations' ability to use IT as an agile, on-demand support service.
At least it used to be like that, but not any more.
Closed-Loop Intelligent Change Control ensures that change control is made to work for you. By wrapping around your existing processes and using intelligent and highly automated technology, change control benefits can be delivered without the red-tape and stifling resource requirements.
Closed-Loop means that changes made are made visible and reconciled automatically with your RFC (Request For Change), Incident management and Service desk systems. This closed-loop approach works either for pre-planned RFCs recorded in advance of changes being made, or retrospectively after changes have been implemented. The system simply fits your way of working.
Intelligent Change Control means that changes are detected as they are made and reviewed automatically. If the change matches any pre-defined Planned Change patterns then it can be reconciled automatically with the relevant RFC details, even for estates with thousands of devices and even more changes happening.
If an unplanned change is recorded, this is then highlighted for review – because all the known, expected and pre-approved changes are taken care of automatically, more time is freed up to investigate changes that may be security incidents.
And, when a change has been investigated and identified as OK – maybe it was an emergency change that hadn't been assigned to an RFC – this can now be reconciled with an approved Planned Change record and also promoted to the Approved Baseline. This way, other occurrences of the same change will now be classified as 'known good' meaning that any similar past changes or future instances can be instantly assigned a Planned Change status.
Contact us for a no-strings, no-sales pressure trial and see the coolest breach detection solution in action for yourself
Need more information? Compliance – System Hardening - Change Control – Breach Detection