Viruscope is a very powerful technology which provides CIS with the ability to monitor the actions of system processes, and reverse them if they are judged to be malware. CIS judges whether something is malware by recognising malware-like behavior (ie through dynamic heuristics). Users can judge by examining detailed process activity logs. It is thus potentially a very valuable addition to CIS.
But Viruscope is not yet mature, so misjudgements by CIS could lead to the reversal of processes which are not malware. Viruscope’s immaturity also means that IMO the user is not guided as well as they could be, so inappropriate reversals could happen due to user misjudgements, too. Such misjudgements can result in undesirable consequences such as the loss of saved data files and other intentional changes. The risk is small, but in my opinion still significant.
Accordingly I thought it would be helpful to give some guidance on whether or not to use Viruscope, as the current point in its evolution, and if you do decide to use it, how to manage the risks.
Users who are not technically knowledgeable
Should in my opinion leave Viruscope switched off, as it currently delivers few or no benefits to average users with default CIS setting settings. For example if the Behavior Blocker is on Viriscope will not give alerts with the current set of recognisers. The implications for such users of using non-default settings may be inappropriate - for example using HIPS instead of the behavior-blocker will result in too many alerts. Also the implications of using Viruscope will be difficult to fully understand.
Users who are technically knowledgeable
Should make sure they fully understand the risks and limitations outlined below, and, if they do, make up their own mind based on the balance of those risks and the benefits of additional protection from malware. If they don’t fully understand the risks and limitations they should probably, in my opinion, leave Viruscope switched off. (Viruscope is off in the default IS config unless you chose to change this, but on in the alternative Proactive config).
The main benefits may be listed as follows. Viruscope:
- Provides another means of detecting and alerting users to possible malware activity, even when the malware has not been previously encountered by CIS. (Adds dynamic to static heuristics).
- Allows users to clean detected malware from the system, even when that malware has not previously been encountered by CIS.
- Helps improve the quality of decisions made on pre-existing alerts by providing a list of the activities carried out by the process (eg Firewall, AV and HIPS alerts).
The main limitations are:
- As yet few malware-like behaviors are recognised and all those recognised are blocked by the Behavior Blocker (BB), meaning you get no Viruscope Alerts if the BB is on. So to use Viruscope you really need to use HIPS instead of the BB. (This will improve as more recognisers are installed via frequent updates).
- Many process actions can be reversed, but not all can be (eg file deletes cannot be reversed), so reversals may be incomplete.
- A longer list of process actions can be monitored, but not all can be.
- Reversal is limited to the current process run session, so damage done by undetected malware in a previous process run session cannot be reversed.
The main risks may be analyzed as follows:
[ol]- A false detection of an unknown process as malware by the CIS Viruscope module will result, if the alert is left to time out, or if you set Viruscope in silent mode, in the automatic reversal of the process without further confirmation being required. Although such events should be rare, experience with other AV processes suggests they will happen from time to time.
- A mistaken user decision to clean a detected unknown process will result in reversal of the process without without further confirmation being required, or an (IMO) sufficiently explicit explanation of the consequences of reversal being given. [1]
- A mistaken user decision to terminate and reverse an unknown or trusted process in Killswitch will, as the options name implies, result in the reversal of the process. Although in this case confirmation is required, the confirmation dialog is not explicit about the risks.
- All three will also result in the reversal of further processes, whether trusted or unknown, run from the detected process, directly or indirectly.
- Reversal of processes means the permanent loss of most changes made by them in the current process run session. So, in the case of false detections, it can lead to loss of data files, partially reversed installations and so on.
- The risk of damage from reversals initiated from Viruscope alerts is considerably reduced by the fact that only unknown processes can be detected. Users record less data in unknown than trusted processes. However please note that point 4. above means that trusted sub-processes of detected processes will be reversed.
- Very much a worst case scenario, but needs to be mentioned for completeness, in the unlikely event you or CIS reverse a Windows shell substitute program by mistake you could lose all the changes you have made to your system in unknown or trusted programs in the current log-on session. Reversing a Windows explorer (but non-shell) substitute program used to run unknown or trusted applications could also have extensive though less severe effects.[/ol]
Managing the risks, if you choose to use Viruscope.
- Keep Viruscope silent mode switched off - ie use it with ‘Do not show pop-up alerts’ under Behavior Blocker settings unticked
- Make sure your machine is frequently and fully backed up, and you keep several backups versions. Just general good practice really, but it also will mitigate most Viruscope risks.
I’ve found it difficult to make many suggestions about managing risks as there are as yet not many Viruscope settings which can be adjusted. Maybe you have some ideas?
Viruscope is evolving
I expect Viruscope to evolve quickly during the 7.x series, reducing the risks and limitations and enhancing the benefits. The mechanism used to deploy new recognisers (I think they are pushed with AV updates) suggests this area may change particularly quickly. So this advice may change rapidly. I will update this advice presuming I am informed about such changes.
Footnotes
[1] A complete list of the activities undertaken by the process and its sub-processes is given, but it very detailed, including non-persistent as well as persistent changes, and cannot be filtered in any way. Also you are not guided to consult it.
[i]Please help me improve this FAQ by posting suggestions below. This topic is not locked, but will be moderated to ensure posts are relevant and helpful to users.
This FAQ has been prepared by a volunteer moderator. It has been produced on a best endeavors basis - it will be added to and corrected as we find out more. Please note that I am not a member of staff and therefore cannot speak on behalf of Comodo. Any opinions expressed are my personal opinions, and may not be shared by other mods.[/i]
Updated: 9 March 2014, to reflect changes up to CIS version 7.0 Build 4115. Facts which cannot easily be determined by experiment (eg recogniser scope) may be based on earlier versions - I believe these have not changed, as I understand they were not intended to change, but this has not been confirmed by the issue of an updated specification. Further significant updates will be posted in blue.