This is the sixteenth 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 begins a new mini-series about a much misunderstood capability in SEP: how to keep SEP from scanning content that you don't want detected.
What's the Story?
For sake of illustration (pun intended) we take you now to the Windows computer of a small but talented outfit that is defended by Symantec Endpoint Protection 14. Johnny, the new security admin, is dismayed that one of the tools he has used for years at other companies is detected by SEP.
The detection of this highlighted item is not a False Positive: AngryIPScanner is one powerful tool. If it is on an organization's computers, perhaps brought there by someone who has compromised the network, SEP would be irresponsible not to raise a red flag.
(Note that as a Security Risk rather than a Threat, this detection is logged by default rather than quarantined or deleted. The pop-up is still an annoyance for Johnny... he thinks: perhaps there's a way to fix that....)
A clever professional, our security admin checks online articles and learns that he has the ability to use the Symantec Endpoint Protection Manager (SEPM) to create an exception against this detection....
Best Practice when Symantec Endpoint Protection is Detecting a File that is Believed to be Safe
Creating exceptions for Virus and Spyware scans
Who Should Have this Mighty Power?
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.
Rather than have every computer in the organization ignore that tool without so much as a pop-up or record entry added to the SEPM console, our admin Johnny creates a new SEP client group, just for his band of IT rock stars.
He adds the machines of his IT staff to the group... (full details on the procedure can be found from Managing groups of clients)
This is the group which will have their own Exceptions policy that allows IT tools. For the rest of the organization, settings will be hardened to block Security Assessment Tools, Potentially Unwanted Applications and other questionable content. More details on that can be found in:
All About Grayware
Here's the new Exception Policy, right after it was created. Note that by default it's not associated with any client group - the admin has to make that connection!
Now it's getting assigned:
Policy assigned! Now the exceptions configured in that policy will be applied to the computers in the associated client group.
How to Allow
From the SEPM console, Monitors, Logs, Risk, Johnny views the log of recent detections. Then he just places a check next to the detection, chooses an action like Add risk to Exceptions policy, and click Apply:
Be sure to choose the correct Exception policy! Then Save Changes.
Here's how the Exceptions Policy looks after that Known Security Risk is excluded:
Note that Johnny can choose what action takes place in the environment he manages: completely Ignore that security risk or Log it.
Be sure that the client machines connect to the SEPM and receive new policy settings and updates. Once those are communicated, the client computers will begin to exclude that risk.
Exceptions Get Tricky
All goes well for a while, and the IT client group are able to use the AngryIPScanner without detection. Then one of the staff comes looking for Johnny's head. Despite the exclusions, a new download of this tool is still detected and quarantined!
Johnny has done his reading and points out that the detection name is not AngryIPScanner, but WS.Reputation.1. That's a SEP detection for files with either a new/unknown or BAD reputation. He hits back with the truth that SEP is a whole suite of security technologies, and one component can convict a file that has slipped past another layer of defense.
SEP Times in the City: A Helpful Symantec Endpoint Protection Analogy
The same goes for exclusions. This particular AngryIPScanner tool, can be used for good or ill. That gives it its shady "This file is untrustworthy" reputation, and WS.Reputation.1 conviction.
"Well, what are you gonna do about it, Johnny?"
There were many options to select, when choosing how to exclude a detected application:
"Add Risk to Exceptions policy" will avoid the AntiVirus detection of a single classification, like AngryIPScanner. Any different unique files (different versions of the tool) will be covered, but only for that excluded risk determination.
There's another option to select, which will avoid detecting a particular application by any method, technology or name. "Allow Application" will avoid detection for that one unique file (one fingerprint, also known as SHA256 hash), not for every different version of the tool. Johnny quickly edits the client group's Exclusion policy so that SEP, in his environment, will not trigger on the file with the hash that his coworker encountered and a few other versions of the tool with unique hash fingerprints of their own....
Once the policy is saved and updated to all computers in the IT department client group, the detections cease. Johnny knows he's done the right thing, opening his environment up to as few specific files as possible, rather than any option that opened a potential door wider. Everyone gets back to work happily, until it's time to close up shop and head down to Dewey's for some hard-earned relaxation.
Many thanks for reading! I hope this article helps. One note: though the illustrations are from SEP 14, the same options and actions apply to the older SEP 12.1 product.
The next in the mini-series is now available, illustrating a few common situations. Please leave comments and feedback below.