About Endpoint Protection Audit Signatures
search cancel

About Endpoint Protection Audit Signatures


Article ID: 176042


Updated On:


Endpoint Protection


Information is needed about the Intrusion Prevention System's Audit Signature in Symantec Endpoint Protection.  These signatures detect, but do not block traffic.  Is that expected?

An example:

[SID: 30226] Audit: Nessus Vulnerability Scanner Activity 2 attack detected but not blocked. Application path: SYSTEM



SEP's Audit Signatures are intended to raise awareness of potentially unwanted traffic in the network. By default, they do not block. Administrators reviewing the logs of IPS events in their network can note these Audit events and decide whether or not to configure the corresponding Audit Signatures to block the traffic. 



Of SEP's more than 6000 IPS signatures, approximately two hundred are Audit Signatures. These are intended to raise awareness of traffic that may or may not be wanted in the environment. Signatures are triggered by the use of Instant Messengers, Peer-to-Peer sharing, torrent downloads, coin mining, vulnerability scans and similar programs. If this traffic is considered normal and expected, no action is necessary. If this traffic is unwanted in the environment, administrators can change the action for that Audit Signatures to Block.  

Changes are configured in the Exceptions section of the Intrusion Prevention Policy. It is of course possible to create several different IPS policies, allowing or blocking different types of traffic, for assignment to different SEP client groups.

An Illustration

A security-conscious network administrator wishes to perform a vulnerability scan on the endpoints in the network. However, when the scan is run there is a pop-up seen on the endpoint running the scanner:

Pop-up warning of Audit Signature

SEP client logs confirm that the traffic was detected but not blocked:

SEP Client Security Log showing audit signature traffic detected but not blocked.

There are similar detections on the clients being scanned.  (In this case, the port scans of the vulnerabilty tool even cause Active Response, blocking all communication with the IP of the scanner! Active Response should be temporarily disabled during such vulnerability scans.  For more recommendations please see Best Practices for network vulnerability scans with Endpoint Protection clients.) As this traffic is desired at this time, the admin creates an IPS policy that allows and does not log the Nessus traffic. This policy is applied to the SEP Client Group that is being scanned.

IPS Policy with exceptions to allow and not log

The vulnerability scan is completed successfully and no scan is scheduled until a known future date.  The administrator decides to change the behavior of the policy to Block and Log on those signatures.  If anyone else is on the network, hunting for known vulnerabilities, it is definitely wise to raise awareness and block it!

Once that "Block and Log" policy is saved and applied, the same Nessus scans will trigger different actions on those clients:

When configured to do so, Audit signatures can block