False Positives
False positives are events where the sensor reacts or responds to traffic that is not malicious. This would represent an error in the network environment the sensor is in. For two different networks, the attack might be a false positive in one and correct in the other. It depends on what type of traffic is permitted or acceptable on each network. A false positive can be caused by signatures that are too general in their attack-matching criteria and fire off on both malicious and nonmalicious traffic.
False Negatives
False negatives are events where the sensor doesn’t fire off any alerts, or produce any actions, even when the sensor has seen malicious traffic. One network’s malicious traffic can be a different network’s acceptable traffic. This would represent an error from an IPS perspective and can be caused by a signature that is too specific in its matching criteria. This could also be caused by evasion techniques the attacker is using or by signatures being disabled that might have been able to identify the attack. Table 13-2 shows some examples of false positives.
Reduce false positives Cisco best pratice
■ Select the signature set and rules that will be used with a specific sensor.
■ Remove all default aggressive actions from all signatures. Use the event action filters, and subtract all aggressive action. This is faster than modifying individual signatures and removing all aggressive actions.
■ Add verbose alerts (which capture the first packet that triggered the alert) using event action overrides.
■ Add logging packets between the attacker and the victim, using event action overrides. Having the subsequent capture of packets can assist the analyst in better understanding the traffic that triggered and immediately followed the attack.
■ Allow the sensor to analyze traffic, and then observe the alerts generated to see whether they are false positives or valid alerts; then tune the signatures as needed.
■ After the signatures are tuned, remove the event action filters that removed the aggressive actions, and remove the event action overrides that produced the verbose alerts.
■ Periodically, revisit the sensor to tune as needed. Realistically, new false positives showing up will alert you to the need for tuning.
Selecting and Verifying Signatures and Rules in Place
Removing All Aggressive Actions
Tuning the Sensor to Reduce False Negatives
The primary reasons for false negatives include the following:
■ The signature-matching criteria are too specific and do not match the malicious traffic.
■ There is no signature for the particular malicious traffic.
■ The sensor is not monitoring the portion of the network where the malicious traffic ishappening.
■ The attacker is using tools that are evasive enough in nature to not trigger the sensor.
False positives are events where the sensor reacts or responds to traffic that is not malicious. This would represent an error in the network environment the sensor is in. For two different networks, the attack might be a false positive in one and correct in the other. It depends on what type of traffic is permitted or acceptable on each network. A false positive can be caused by signatures that are too general in their attack-matching criteria and fire off on both malicious and nonmalicious traffic.
False Negatives
False negatives are events where the sensor doesn’t fire off any alerts, or produce any actions, even when the sensor has seen malicious traffic. One network’s malicious traffic can be a different network’s acceptable traffic. This would represent an error from an IPS perspective and can be caused by a signature that is too specific in its matching criteria. This could also be caused by evasion techniques the attacker is using or by signatures being disabled that might have been able to identify the attack. Table 13-2 shows some examples of false positives.
| ICMP Network Sweep w/Echo | ICMP reconnaissance | Network mapping tools being run by management host |
| Failed Login | Brute-force attack or password guessing | Valid user forgot password and was making several attempts |
| UDP Flood | UDP DoS attack | Video or voice calls, using lots of UDP |
Reduce false positives Cisco best pratice
■ Select the signature set and rules that will be used with a specific sensor.
■ Remove all default aggressive actions from all signatures. Use the event action filters, and subtract all aggressive action. This is faster than modifying individual signatures and removing all aggressive actions.
■ Add verbose alerts (which capture the first packet that triggered the alert) using event action overrides.
■ Add logging packets between the attacker and the victim, using event action overrides. Having the subsequent capture of packets can assist the analyst in better understanding the traffic that triggered and immediately followed the attack.
■ Allow the sensor to analyze traffic, and then observe the alerts generated to see whether they are false positives or valid alerts; then tune the signatures as needed.
■ After the signatures are tuned, remove the event action filters that removed the aggressive actions, and remove the event action overrides that produced the verbose alerts.
■ Periodically, revisit the sensor to tune as needed. Realistically, new false positives showing up will alert you to the need for tuning.
Selecting and Verifying Signatures and Rules in Place
Removing All Aggressive Actions
Tuning the Sensor to Reduce False Negatives
The primary reasons for false negatives include the following:
■ The signature-matching criteria are too specific and do not match the malicious traffic.
■ There is no signature for the particular malicious traffic.
■ The sensor is not monitoring the portion of the network where the malicious traffic ishappening.
■ The attacker is using tools that are evasive enough in nature to not trigger the sensor.
Комментариев нет:
Отправить комментарий