Determining A False Positive Versus Noise - McAfee M4050 - Network Security Platform Troubleshooting Manual

Troubleshooting guide
Hide thumbs Also See for M4050 - Network Security Platform:
Table of Contents

Advertisement

McAfee® Network Security Platform 6.0
Correct identification; significance subject to user sensitivity (also known
as noise)
There is another type of event which you may not be interested in, due to the perceived
severity of the event. For example, Network Security Platform will detect a UDP-based
host sweep when a given host sends UDP packets to a certain number of distinct
destinations within a given time interval. Although you can tune this detection by
configuring the threshold and the interval according to their sensitivity, it's still possible that
some or all of the host IPs being scanned are actually not live. Some users will consider
these alerts as noise, others will take notice because it indicates possible reconnaissance
activity. Another example of noise would be if someone attempted an IIS-based attack
against your Apache Web server. This is a hostile act, but it will not actually harm anything
except wasting some network bandwidth. Again, a would-be attacker learns something he
can use against your network: Relevance analysis involves the analysis of the vulnerability
relevance of real-time alerts, using the vulnerability data imported to Manager database.
The imported vulnerability data can be from Vulnerability Manager or other supported
vulnerability scanners such as Nessus.The fact that the attack failed can help in zero in on
the type of Web server you use. Users can also better manage this type of events through
policy customization or installing attack filters.
The noise-to-incorrect-identification ratio can be fairly high, particularly in the following
conditions:
Users can effectively manage the noise level by defining appropriate VIDS and customize
the policy accordingly. For dealing with exceptional hosts, such as a dedicated pentest
machine, alert filters can also be used.

Determining a false positive versus noise

Some troubleshooting tips for gathering the proper data to determine whether you are
dealing with a false positive or uninteresting event;
If you intend to work with McAfee Technical Support on the issue, we ask that you provide
the following information to assist in troubleshooting:
the configured policy includes a lot of Informational alerts, or scan alerts which are
based on request activities (such as the All Inclusive policy)
deployment links where there is a lot of hostile traffic, such as in front of a firewall
overly coarse traffic VIDS definition that contains very disparate applications, for
example, a highly aggregated link in dedicated interface mode
What did you expect to see? What is the vulnerability, if applicable, that the attack
indicated by the alert is supposed to exploit?
Ensure that you capture valid traffic dumps that are captured from the attack attempt
(for example, have packet logging enabled and can view the resulting packet log)
Determine whether any applications are suspected of triggering the alert—which
ones, which versions, and in what specific configurations.
If this occurred in a lab using testing tools rather than live traffic, please provide
detailed information of the attack/test tool used, including its name, version,
configuration and where the traffic originated.
If this is a testing environment using a traffic dump relay, make sure that the traffic
dumps are valid, TCP traffic follows a proper 3-way handshake, and so on
Also, please provide detailed information of the test configuration in the form of a
network diagram.
36
Determining False Positives

Advertisement

Table of Contents
loading

This manual is also suitable for:

Network security platform 6.0

Table of Contents