Comodo has so called CurrentControlSet and that shows , for instance, printer drivers or so. Of what I know d+ will give an alert that sometime is trying to create new HKEY or registry keys. What important does HKEY have when a malware is deleted but that managed to create new HKEY?
In the registry itself, ControlSet001, ControlSet002 and CurrentControlSet are independent sub-arborescences.
There is no reason for the ControlSet??? string to control CurrentControlSet if the ControlSet switches only refer, as i believe, to any number (e.g. 001, 002,…).
There is no reason either to write a specific group of “Important Keys” if CIS protects every registry key: it would be a nonsense.
A probable intermediate reason is that, outside of course of the fact that one can write whatever registry group of his choice, CIS might apply the contents of some group or another to a specific action.
Maybe CIS actually protects CurrentControlSet, but none of the evocated mechanisms advocate for it.
I was unable to find any access right registry rule for it in Defense+, but the said section concerns hardware, and altough my usb printer appears in this registry section, there was no corresponding permission asked by CIS.
But, true enough, my CIS 5.3 partition is mostly used for testing purposes (and thus free of most software and hardware); one of you fully working with CIS 5.X should look, if he has appropriate customized Defense+ rules, if there actually are CIS Defense+ access rights refering to CurrentControlSet.
ControlSet001 may be the last control set you booted with, while ControlSet002 could be what is known as the last known good control set, or the control set that last successfully booted Windows NT. The CurrentControlSet subkey is really a pointer to one of the ControlSetXXX keys.