Introduction
This is the seventeenth in my Security Series of Connect articles. For more information on how to keep your enterprise environment secure using often-overlooked capabilities of Symantec Endpoint Protection (and the OS upon which it functions), see Mick's Greatest Hits: Index of Helpful Connect Security Articles. This article was last updated in December 2017.
This article continues a new mini-series about a much misunderstood capability in SEP: how to keep SEP from scanning content that you don't want detected. For the basics, please be sure to read Exceptions, Illustrated: Part One
| Important note: be very careful with exclusions! Every exception made opens a hole in the organization's defenses. Introduce them as precisely as possible, to as few computers as possible. |
Fine Tuning the Terminator
Johnny, new security administrator for a small but talented organization, starts every day by taking a good look at his logs. He has successfully created exclusions which let his band of IT gurus use powerful but potentially dangerous network auditing and admin tools that are denied to the rest of the company. He wonders, though, what one of his staff is doing using an ancient version of the AngryIPScanner tool. That 2.2.1 version was designed for Windows 98.
Happily, the Symantec Endpoint Protection Manager allows Johnny to tweak the settings in use in his environment. It's possible to allow newer versions of the tool while blocking or terminating attempts to run that old one. In the correct Exceptions policy, he just changes the action for that fingerprint / hash to Terminate.....
Important note: be very careful with exclusions. Every exception made opens a hole in the organization's defenses. Introduce them as precisely as possible, to as few computers as possible.
(Yes, I know I said that already. I'm going to keep saying it until the message sinks in!) (And as soon as you are done reading this article, go harden your environment! Back important data up! And check your logs!)
After that, when an attempt is made to launch that old version, Windows throws a "cannot access the specified device, path, or file" error message and SEP logs an Administrator Defined Exception, Process Terminated, User-defined Risk.
Johnny later learns that it is also possible to block the old application from running though SEP's Application and Device Control (ADC), but he is happy with the way he has accomplished his goal.
Block Software By Fingerprint
https://www.symantec.com/connect/articles/block-software-fingerprint
The Official Word
Here are two Technical Support articles that have additional details on how to learn and react to applications in the network....
Creating Centralized Exceptions Policies in the manager
http://www.symantec.com/docs/TECH183201
How to create an application exception in the Symantec Endpoint Protection Manager
http://www.symantec.com/docs/HOWTO61213
Applications that Change Frequently, Part One
Constant calls come in on the IT helpline about WS.Reputation.1 False Positive detections on a tool that the company needs. This internal tool is tweaked and recompiled at least daily, then posted to a shared network location that everyone in the company has mapped as their H Drive. The tool is called 1939im.exe and it is the organization's number one source of complaints and IT tickets.
Creating an exclusion against the fingerprint/hash of the file will not work, or at least work for long. That fingerprint changes every time the tool is rebuilt, which is often. Management is so frustrated that they have asked that SEP's Download Insight be disabled entirely. Johnny, though a newbie to SEP 14, already understands what a powerful defense Download Insight is. It may be helpful to adjust the sensitivity of Download Insight and uncheck some options in order to avoid some detections, but he does not want to disable it altogether.
Luckily, with a bit of research, Johnny is able to see a perfect solution. Thanks to the shared drive and folder structure, the filename and path is always H:\Hllblls\1939im.exe on every computer. An exception can be created to ignore any file of that name in that location:
(One note: this exception is made in the policy that is applied to the company's many end-user client groups, not to the exceptions policy that is for the IT only client group!)
Johnny then uses his Windows permissions to make sure that the development team, responsible for the creation and posting of that tool, are the only user accounts with write access to that shared folder. Other users may read and run the executable, but no unauthorized user account can replace that 1939im.exe file with malware of the same name!
| Don't rely on exclusions alone! There are additional measures for developers to take to reduce the risk of False Positives. The Insight Deployment Best Practices, for example offer advice such as digitally signing executable files. It may also be best to take part in Symantec's whitelisting program for files that will ultimately be made available to a wide public audience. |
Applications that Change Frequently, Part Two
Another pain point is that many trusted, legitimate files downloaded from a certain domain are constantly being detected. These necessary files, which the company requires to do its business, are frequently detected as WS.Reputation.1 and other signature names.
Again, SEP's built-in exclusions save the day: it is possible to proactively allow downloads that come from a specified website or address.
Should those files be malicious, of course, they will be detected once they are on the computer's disk and acting evil. The scan that takes place during download, though, will give them a pass.
Conclusion
Many thanks for reading! Part three in the mini-series, illustrating some really poorly thought out exclusions, is under development now!
Please leave comments and feedback below.