Option to change monitoring level manually

Hy guys !

I am sure most of you are familiar with Webroot's famous Monitor / Rollback feature.

Something you might not know is that there are more levels of monitoring, and the used level is depend on the heuristic determination of the actual process.

There are multiple levels, because fully monitoring an apllication can create a database file several gigabytes in size, and have a significant performance impact on the system while running the program.

In practise, it means the following:

If a program is likely ok, but unknown in the cloud a limited form of monitoring for system changes, and functions will be initialized, however, it should not have any significant impact on either storage space, or system performance. However, if an application is for any number of reasons 'suspicious' then an increased alertness state will result in more data being gathered.


I think an option to change the monitoring level for applications would be very useful for the advanced users, and it would make the unique and powerful rollback feature of Webroot even more powerful. (Right now you can set an application to "monitor", but you can't decide the level of monitoring applied.)

And if this option is hidden somewhere, for ex. in the advanced settings, it would not confuse the not-so-advanced users.

What do you guys think?

Joe, what do you think, would it be hard to implement this ?

I created a "new idea" in the ideas exchange, if you like it please give kudos to get it more attention Here is the link: https://community.webroot.com/t5/Ideas-Exchange/Option-to-change-monitoring-level-manually/idi-p/60955

 

There was never an Option to regulate the Monitoring in WSA, as far as I heard WSA self cleans the Data stored in the WRData Folder for it not to get so large but I will let Joe give the more Details on how it does this!

TH

 

It's difficult to ascertain just how suspicious a new program is - for example, it could start off doing absolutely nothing (waiting around for a few hours/days/etc.) but then suddenly start erasing files. Therefore, until it is marked as known good, it is monitored completely. The most effective way of avoiding this is to mark software you trust as Allow and contacting our support/threat research team to let them know that they should whitelist the files.

 

Yes I know, and I completely understand and agree, but here is an example : I have an application that i am sure is safe, but it is so rare, webroot haven't seen it yet, so it will get some level of monitoring. Or another example: webroot determines the process as probably good, so it will not get full level of monitoring, but some changes will be monitored. But what if I think the process is suspicious, and I would like a full monitor?

I completely trust Webroot's decision in these scenarios. But still, it would be great if I would have option for manual control, if I want.

 

What you describe still can be manually determined... Keep a good file on monitoring, allow a component even if not determined as good. Probably you mean been able to allow/block internet connections?

 

No, you misunderstood me. I know you can set a file to monitor or allow. But you can't choose the level of monitoring, when you set something to monitor. As I said in first post :
,Right now you can set an application to "monitor", but you can't decide the level of monitoring applied"

 

I see, thanks... but it looks a bit out of scope... a sort of linear HIPS control.

The problem is that end points taken into account by WSA for determination (good/bad) seems far more complex and non linear + you need to factor-in the variable "time". A peace of malware does not necessarily need to alter registry to do its job or necessarily access the system folder... or unloading a driver may not necessarily be an indication of malware action... and so on.

So, the determination of what is good or bad and what to monitor depends on far more than 5 or 6 variables to act upon. Transparency of the logic behind determination of good and bad will never be disclosed. Its the strength of WSA.

Therefore, going manually you will end up with suboptimal protection. I am afraid the amount of users interested in this will be rather limited...

 

I think the root of the problem here is a misunderstanding about the "levels of monitoring" and how they apply to journalling and rollback. I suspect that you saw the log lines that say "monitored at level X".

Journalling is the same amount of data regardless of the "level" of monitoring. The level just describes what kind of data is going into the monitoring information.

Those levels described are descriptive of what item occurred that was looked at. One level describes an HTTP request through Windows APIs, while another level describes raw network activity. Other levels describe registry reading activity, writing activity, and disk reading or writing activity.

It doesn't decide to, for example, ignore five files that were written before and then suddenly track five more files that are written because it "goes to a new level of monitoring". Before the first five files are written, there is no "File writing" level being done, because no files are written. When they are written, it indicates that level in the logs and records the data. So there are no files written that are ignored (and thus reduce monitoring data) because it's at a lower level.

Hopefully this makes sense and addresses the concern, since I'm literally making an educated guess at what your logic is.