Endpoint Protection

We are using Bit9 to do application whitelisting.  We've discovered that there is contention between the Bit9 client and the Symantec client that causes Bit9 to be unable to finish analyzing the file, causing it to be blocked.

Their support folks say this is a known issue with Symantec and to change the auto-protect policy from "on access and on modification" to "on modification".

I'm trying to figure out what the security implications will be for that change.  I find myself wondering if Symantec would catch an infected PDF or Word doc when it's opened if the policy is set only to scan "on modification".  If the malware in an infected file writes anything to the file system, Bit9 will catch it.  But I'm concerned about what would happen if the malware writes directly to memory.

If someone could explain the differences between those settings and what might get missed if the policy is set only to "on modification", I'd appreciate it.

Thx.

Craig

Disabling on-access... 

To do so, you will need to go into the advanced features of AV/AS protection.  Than configure the settings for Proactive Threat Protection.

Next you will need to remove (uncheck):

- Scan for Trojans and Worms check box.

- Scan for Keyloggers check box.

Click "OK." On-access file scanning is now disabled.

 

Jason,

Thanks for the quick reply.  My issue isn't so much that I don't know how to disable on access scanning, I'm trying to figure out what threats Symantec will miss because on access scanning is disabled.

C

When on-access is disbaled, the SEP client will not scan for trojans, worms and keyloggers.

Nowadays, the term "virus" is seldomly used.  Or is rather used as a generic term. 

A virus per-say, as defined, will automatically "replicate itself" thus modifying a file or folder.  It is inherant in it's nature and by definition is it's signature, differentiating it from Trojans, Worms and Keyloggers.

* * * * * * * *

By removing on-access, SEP will not scan a word document, excel document for example, for malicious code hidden in Macros.  These will generally be used to exploit vulnerabilities in the OS, allowing an attacker to gain control of or part of the system and spread.  Worms and trojans. 

Again, these types of files replicate across network and modify files/folders. 

On modification will trip the "alarm" and SEP will suppress the threat it knows about to the best of it's capabilities, once the threat tries to compromise the system.

What will actually be missed?  To answer the original question, is very little or nothing.

The danger in removing "on-access" is that you are becomig "Reactive" as opposed to being "Proactive". 

The advantage is lower overhead when accessing system and network ressources... 

Thanks, Jason!  Take the example of an Excel spreadsheet infected with a malicious macro.  The user opens the file from a network drive.  With "on access" disabled, Symantec wouldn't scan the file before it's opened.  But, if the file is saved as a temp file somewhere on the file system, Symantec would scan that because writing that temp file is a "modification" event?

If Symantec recognizes the harmful macro, it'll block it and alert.  If Symantec doesn't have a signature for that macro, does disabling the "on access" part of the policy stop Symantec from doing heuristic analysis that would catch the malicious behavior?

If a user opens a file from a network drive that doesn't cause a temp file to be created, will Symantec be able to catch it without "on access" enabled if it attempts to load a keylogger or trojan into memory?

Hi

You should only change the setting to "on modified" on file or application servers that are under heavy load.

Changes this on a client will cause a big security risk.

For example if you get a zero day threat that on that day there is no signature for when the malware is written to the filesystem. The malware has then already been written to disk and will not be detected when run later even if a signature is released.

If you had on access actived the malware would have been detected as soon as the signature was released.

I believe that to solve this with Bit9 problem you should be able to work around this by excluding the bit9 process from "tamper protection".

Torb