McAfee M-1250 Network Protection - Page 22
About false positives and \, Incorrect identification
![]() |
View all McAfee M-1250 manuals
Add to My Manuals
Save this manual to your list of manuals |
Page 22 highlights
McAfee® Network Security Platform 6.0 Configure policies About false positives and "noise" The mere mention of false positives always causes concern in the mind of any security analyst. However, false positives may mean quite differently things to different people. In order to better manage the security risks using any IDS/IPS devices, it's very important to understand the exact meanings of different types of alerts so that appropriate response can be applied. With Network Security Platform, there are three types of alerts that are often taken as "false positives:" • Incorrectly identified events • Correctly identified events subject to interpretation by usage policy • Correctly identified events uninteresting to the user. Incorrect identification These alerts typically result from overly aggressive signature design, special characteristics of the user environment, or system bugs. For example, typical users will never use nested file folders with a path more than 256 characters long; however, a particular user may push the Windows' free-style naming to the extreme and create files with path names more than 1024 characters. Issues in this category are rare. They can be fixed by signature modifications or software bug fixes. Correct identification; significance subject to usage policy Events of this type include those alerting on activities associated with Instant Messaging (IM), Internet Relay chat (IRC), and Peer to Peer programs (P2P). Some security policies forbid such traffic on their network; for example, within a corporate common operation environment (COE); others may allow them to various degrees. Universities, for example, typically have a totally open policy for running these applications. Network Security Platform provides two means by which to tune out such events if your policies deem these events uninteresting. First, you can define a customized policy in which these events are disabled. In doing so, the Sensor will not even look for these events in the traffic stream to which the policy is applied. If these events are of interest for most of the hosts except a few, creating attack filters to suppress alerts for the few hosts is an alternative approach. Correct identification; significance subject to user sensitivity (also known as noise) There is another type of event that 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 14
![](/manual_guide/products/mcafee-m1250-network-protection-260e040/22.png)