HIPS Ask rules auto-allowing actions after timeout

[Parsh 0]

Hello, I've configured some HIPS rules to 'Ask' when some apps are started/ their states modified/ they launch other applications.

Eg 1. I have set an 'Ask' rule (among other browser rules) when any app tries to modify the state of browsers. So when I launch Yandex browser from Taskbar, I'm alerted that svchost.exe is trying to modify browser.exe (run inside Sandboxie). If I do not answer the Allow/Deny call within ~1 minute, it automatically allows the action 1️⃣.

Eg 2. Same is the case when I restrict apps (Ask rule again) from modifying certain folders to protect them from modification/deletion. 

I referred to the Help section of ESET IS ...

Quote

... If the default action for a rule is set to Ask every time, a dialog window will be displayed each time that the rule is triggered. You can choose to Deny or Allow the operation. If you do not choose an action in the given time, a new action is selected based on the rules.

My queries w.r.t. the 'Ask' alerts are

1. Does ESET HIPS always auto-allow if the Popup alert is not answered within a minute? OR
2. Does it decide action based on the source app reputation? OR
3. Does it decide based on the rules (as quoted above)? If yes, could you please elaborate?

I find this behavior 1️⃣ not desirable or intuitive at all. If some user is choosing to 'Ask' for a use case, he/she really wants to be alerted and manually address the scenario. 

I would not want that HIPS allows some suspicious action (for which I've set an 'Ask' rule already) automatically when I've been for a nap or a coffee break!

Thank you.

Edited February 29, 2020 by Parsh
formatting and details

[Marcos 5,070]

The behavior is to prevent the system from becoming unresponsive, e.g. if an interactive window cannot be displayed and HIPS is waiting for the user to select an action. Currently it's not possible to change it. However, it's possible that in the future we will allow the user to take the risk and define the behavior. If no response can be provided to HIPS and the system will become unresponsive because of this, the user will need to boot to safe mode and delete a file with HIPS rules there.

[Parsh 0]

21 minutes ago, Marcos said:

The behavior is to prevent the system from becoming unresponsive, e.g. if an interactive window cannot be displayed and HIPS is waiting for the user to select an action. Currently it's not possible to change it. However, it's possible that in the future we will allow the user to take the risk and define the behavior. If no response can be provided to HIPS and the system will become unresponsive because of this, the user will need to boot to safe mode and delete a file with HIPS rules there.

So I can infer that it doesn't take any rules into account, but auto-allows the action.

The purpose of blocking VS asking about some operation may differ. However, the risk you're mentioning will lead to something equivalent to a 'block' action that would have been set for that action (instead of 'Ask'). Rarely would someone make an 'Ask' rule for something he/she considers to be safe. So, when there's a less likely failure of an 'Ask' alert, blocking will more likely not be disastrous, but for good. 

The user can brick the system with a bad 'block' rule too. 

At least, there could be an option in HIPS settings where the user can select whether ESET should auto-allow / auto-block / keep the popup (ie. action is blocked until alert is answered) giving a finer and desired control to the user, and he'll be responsible, for good. And the default option can be set to what it is currently --> auto-allow (to prevent any mishap).

Could you please forward this suggestion to the ESET Technical Team for consideration? 

The current behavior almost defeats what the option name stands for, Ask.

[Marcos 5,070]

1 minute ago, Parsh said:

Could you please forward this suggestion to the ESET Technical Team for consideration?

I've actually already answered this:
However, it's possible that in the future we will allow the user to take the risk and define the behavior.

[itman 1,659]

To this I will add that the HIPS has hidden Eset rules that take precedence over any like user rule governing select process execution. If HIPS advanced logging is enabled, these hidden rules will be exposed. Note: HIPS advanced logging should be only enabled for very brief intervals since hundreds of event log entries will be created in a very short interval.

Again, the logic employed by Eset is to prevent the user from overriding critical Eset protection and system operational processes. Bottom line - the Eset HIPS is not a full feature HIPS of old such as the defunct Outpost HIPS. Even Comodo's HIPS currently automates and hides much of the granularity past versions had.

[Parsh 0]

ESET sure has hidden rules constituting integral and critical rules w.r.t. the OS. That would be for every well-built HIPS.

However, as Macros generalized and indicated, the action is to simply Allow in such use cases. No idea about relation with pre-defined rules.

Very true about Comodo. HIPS alerts in Comodo vary by mode, however, the USP of Comodo is its auto-containment. While many contextually educated ESET users tend to rely heavily on HIPS as that's the only and highly configurable dynamic component.

 

[itman 1,659]

On 3/2/2020 at 8:01 AM, Parsh said:

No idea about relation with pre-defined rules.

Pre-defined rules override any like user rules in regards to a specific action. With advanced HIPS logging enabled, one will observe wording in regards to user rules such as "partially allowed/blocked." This would be indicative of an Eset pre-defined rule taking precedence.

Bottom line - one really does not know if a user HIPS rule is working fully working as intended.

Edited March 3, 2020 by itman