I'm no expert in this field. But you will have to analyze the alerts to figure out if they are false positive or not. most of these depend on your specific environment. But a few good guidelines would be as follows (feel free to correct me if I am wrong)
- Remove all the noise such as p2p alerts,IM alerts and stuff (you can block/allow them based on your environment but it would be a good idea to defineatly stop the alerting on them since they make up a large part of your alerts.)
- Once the noise is removed you can be more focused on the real issues. For tuning futher you need to consider the source and destinations of the attacks. once you do that you also have to figure out if they are relevent to that particular victim (Server/PC). for examples expolits relevent for Apache would not have any effect on IIS servers.
- if you are using McAfee default inline IPS it only blocks the attacks which are in the RFSB (Recomended for Smart Blocking) list. these are a group of alerts who have a high confidence level and a very low false positive rate.
Hope the this will be helpful
- Create your own IPS Policy. I usually copy either the Default Inline IDS or IPS depending on if the device is inline or not. Remember you can still use an IPS policy and put the device in SIMULATION mode to keep it from blocking until you are sure you are ready for IPS functionality (to make a device do block simulation go to Devices, Device, Policy, Protection Profile > Enable Simulated Blocking)
- Ensure the ports on your sensor have proper settings applied. Under devices, select the sensor. IPS Interfaces -> Protection Profile. I usually add the following Outbound Options (Advanced Botnet Detection, HTTP Response Scanning, IP Reputation and Layer 7 Data Collection) and Inbound (IP Reputation). This is an easy thing to miss. You probably DON'T want to assign IPS policies or Firewall Policies at this level though, as that is usually best to do at the sensor level, not the interface level (depending on your needs, of course).
- Create a firewall policy for your sensor and apply it at the sensor level, even if if the policy doesn't have anything in it except ANY-ANY > SCAN. This way you can easily add things to it later. I usually put some global exceptions in the firewall policy such as vulnerability scanners.
- Name your IPS Sensor interfaces. This is helpful when researching alerts as you can add the interface column to the Real Time threat analyzer. (Do this under Devices, Device, IPS Interfaces, Properties, Edit)
This is completely up to you and your environment. Here are some tips though.
When you find a signature in RTTA that you don't think you need, you can do a couple things.
Right click on the alert, Edit Attack Settings, Baseline Policy.
1) Lower the severity to "Low". The default configuration auto acknowledges Low severity alerts. This way the alerts are still in your system, but you won't have to see them unless you want to (like in your SEM, or by opening the historical analyzer).
2) Turn the signature off.
3) Tell the signature not to send a message to the manager (probably least preferable as the sensor will still be doing the work, but just not alerting on it)
You can also create an exception by right clicking the alert and chosing "Create Exception". This exception will be specific to the signature and source/dest IP.
Hope this helps.
gene33 and rukmalf made some very good suggestions already. In addition you can have a look at the NSP_8_0_Best_Practices_revC_en-us.pdf which included information for policy tuning, response management, firewall policies and more. You can find it in the Knowledge Center at mysupport.mcafee.com