McAfee M4050 Troubleshooting Guide - Page 44

About false positives and “noise”, Incorrect identification

Page 44 highlights

McAfee® Network Security Platform 6.0 Determining False Positives  Take steps to reduce false positives and noise from the start. If you allow a large number of "noisy" alerts to continue to sound on a very busy network, parsing and pruning the database can quickly become cumbersome tasks. It is preferable to all parties involved to put energy into preventing false positives than into working around them.Attack filters are also an option where you can have custom rule sets specific to his environment. You can disable all alerts that are obviously not applicable to the hosts that you protect. For example, if you use only Apache Web servers, you can disable IIS-related attacks. 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 which 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. 35

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95

McAfee® Network Security Platform 6.0
Determining False Positives
35
Take steps to reduce false positives and noise from the start. If you allow a large
number of “noisy” alerts to continue to sound on a very busy network, parsing and
pruning the database can quickly become cumbersome tasks. It is preferable to all
parties involved to put energy into preventing false positives than into working around
them.Attack filters are also an option where you can have custom rule sets specific to
his environment. You can disable all alerts that are obviously not applicable to the
hosts that you protect. For example, if you use only Apache Web servers, you can
disable IIS-related attacks.
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 which 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.