This is Windows 10 version 1709 (build 16299.19) with CIS 10.0.1.6294 - yes, I’m still waiting for the latest update package. HIPS is on paranoid mode.
Running dismhost.exe is part of update and maintenance processes in Windows that are triggered in the background. Unfortunately, they do not run the dismhost.exe executable located in a known Windows folder, they copy this (and a few DLLs) to a temporary directory and run it from there. After the Fall Creators Update of Windows, this seems to occur more frequently now.
The problem is that every time dismhost.exe is run that way, I get a number of popups because it wants to write to C:\Windows\Logs\DISM\dism.log, which is a protected file.
With the “protected files and folders” definition in place, dismhost (being run from a temporary location) does not have general permission to write to that file. In consequence, I get a pop-up message to confirm.
I have not yet found a way to exclude log files under C:\Windows\Logs from checking, i.e., specify %windir% as protected, but exclude %window%\Logs.
I do not want to have dismhost.exe copies scanned and rated in the cloud as this would also permit a number of other Windows processes which I do not want to run freely.
It seems to me, there is no configuration option in the current CIS to handle this case of watching “everything here except…”. In that case, my posting should probably go to the new feature request section. However, it also seems a general issue with CIS under Windows 10 with these kinds of programs that are simply temporary copies of allowed programs (i.e., have the same signature as an already allowed program).
You can either edit the all applications HIPS rule and add the log folder path to the allow exclusions of protected files/folder access right. Or you can create a new file group with the wildcard path of dismhost such as *\dismhost.exe and then add this file group to the HIPS rules and have protected files/folder set to allow.
Well, excluding C:\Windows\Logs* in the “all applications” rule seemed a bit overkill to me, but your second suggestion looks perfect. I did not know I could provide suffix wildcard patterns in rules. I’ll try that. :-TU