Some of the SAFE White Papers have some of this information, but most of it is not specific to IDS sensors.
Here are some links to look at:
http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns128/networking_solutions_white_papers_list.html
The product documentation usually has some of this information.
For the IDS sensor:
http://www.cisco.com/univercd/cc/td/doc/product/iaabu/csids/csids10/index.htm
For VMS:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/cw2000_b/vpnman/vms_2_2/index.htm
There is also a Cisco IDS course as well as a certification test that you can take:
http://www.cisco.com/en/US/partner/learning/le3/le2/le41/le58/learning_certification_type_home.html
Here are some of my usual suggestions:
I generally recommend monitoring the internal connections of the Firewall. This way you won't spend time filtering through alarms for packets that were already stopped by the Firewall. Some advanced users will place an IDS outside of the Firewall to give them more information about what attacks are coming in from the internet that are being blocked by the Firewall, but I would only do this if you have the extra time for analysis.
Also just like your switches, routers, and firewall; you want an IDS sensor rated higher than what your normal traffic rate is. This way the IDS sensor can keep up with usage spikes in the network.
Keep in mind that the sensor needs to see both directions of traffic to function properly. When monitoring TCP connections the sensor must see both the client packets as well as the server packets. This is because the sensor will track the TCP session state to determine whether or not the packets were legitimate. If you connect the sensor to a hub between the firewall and the inside network, then this is fairly easy to achieve. But if the firewall is connected to a switch, then you will need to use a span session to copy the packets to the sensor. When you setup the span session you will need to ensure that traffic in both directions is sent to the sensor. This usually accomplished by setting up a "both" span session for the firewall port of the switch. This way both the "tx" and "rx" packets for the firewall port are sent to the sensor. A side note to keep in mind is that some switches may require extra parameters on the span port to allow TCP Reset packets from the sensor to come in on the span port.
Some users prefer to use network taps to send traffic to the sensor. When using taps keep in mind that the tap has 2 outputs. One output is for traffic to the firewall, and the second output is for traffic from the firewall. Both outputs must be sent to the sensor, so you will need a sensor with 2 sniffing ports to connect to these 2 outputs. Additionally keep in mind that using taps will generally prevent you from being able to do TCP Resets since taps do not allow packets coming in from the sensor.
The sensor has 2 or more interfaces. One of these interfaces is the command and control interface, and the other interfaces are the sniffing interfaces. The command and control interface will have an IP assigned while the sniffing interfaces will not. It is generaly recommended that the command and control interface be connected to either a specific network for configuring and managing your security devices (often known as the out of band secure management network), or at a minumum to a vlan that is used only for managing your security devices. If you are using a vlan, then the command and control of your sensor, an interface of your VMS box, and an interface of your firewall and other security devices would be placed in this vlan. You could then route to other vlans in your network through your firewall to further protect this vlan. Connections to and from your security devices should be over encrypted connections. The Cisco IDS comes loaded and running with SSH for CLI access, and TLS/SSL for access to it's web server.
Cisco IDS sensors have a feature reffered to as blocking (also known as shunning). When the sensor is configured to block the source address of an attack, it will connect to a Cisco router, Cat 6500 switch, or Pix firewall. It will either create a Router ACL, a Vlan ACL, or in the case of the Pix execute the shun command to block the ip address. When deciding where to put the sensor you will need to keep in mind the other devices on the network segment. You will need to configure the sensor to use one of those devices for blocking, and configure the device to allow the sensor to telnet or ssh to the device. You will need to ensure ip connectivity between the sensor's command and control interface and the networking device.
From the management standpoint, with only a single sensor you are probably fine loading both the IDS MC and Security Monitor on the same box.
NOTE: IDS MC and Security Monitor are both part of VMS.
if you were going to deploy a larger number of sensors, then I generally recommend installing IDS MC on one machine and the Security Monitor on a second machine.
When putting together the hardware for your VMS machine, I generally recommend giving yourself a little bit of growing room.
Read the minimum requirements for running VMS. Boxes with less than the minimum often have problems. But also keep in mind that these are minimums and in most cases you will want something.
Pick a machine where you can put in as much memory as you think you need, but still have slots available for adding more memory in the future.
A faster CPU and larger harddrive are also beneficial.
I also recommend dedicating a machine to VMS. VMS has limitations which prevent it from running on machines where you may have installed other programs (VMS has it's own web server so you won't be able to run another web server; VMS also has it's own database so running other databases on the same machine is not recommended)
Another good thing would be to secure the VMS machine with Cisco's Security Agent (CSA). CSA is Cisco's host based IDS software. Many users will also purchase CSA to run on other major servers on their network. Cisco network IDS and host based IDS technologies when used together provide a more secure network.
And connect the VMS machine to the same secure network or vlan as the command and control port of your sensor.
If the VMS machine has to be installed on another network or vlan (usually because of geographical locations), then you will need to ensure that the network devices between the management machine and the sensor will allow certain traffic between the 2 machines. The IDS MC will need to SSH to the sensor. Security Monitor will need to connect to port 443 of the sensor over a HTTPS (TLS/SSL) connection to retrieve alarms. The sensor will need to connect back to port 443 of the IDS MC to pull down updates.
The VMS machine runs a database for storing alarms. You will need to come up with a schedule for archiving and/or deleting these alarms to keep from filling your database. Additionally the more alarms stored in the database the longer it will take your viewer to load the alarms for viewing.
For more information on archiving the alarms refer to this link:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/mon_sec/secmon12/technote.htm
The signatures on the Cisco sensor will come with preset severity levels.
A general rule of thumb is to begin by using the default severities and see what alarms are detected on your network.
Begin by looking at the High level alarms and determine what the cause might be.
The NSDB (Network Security DataBase) is a good reference for more information about an alarm.
The NSDB is installed on the sensors and the VMS machine as part of the signature update process.
If you see alarms that upon analysis are determined to be normal traffic then you will need to either filter the alarms for the particular address set or lower the severity of the alarm, or even disable the alarm. Filtering or disabling the alarms will prevent you from having to spend time on these alarms in the future.
If an alarm is legitimate then you will need to determine if your system is vulnerable (refer to the NSDB for informaiton on vulnerable machines). If the machine is not vulnerable then consider filtering this alarm as well. If the machine is vulnerable then you will need to see if the system has been compromised and take appropriate steps.
SIDE NOTES: Cisco Security Agent (CSA) can also be run on some of these machines and the logs between the network sensor and host sensor can be compared. You might seen an alarm from the network IDS and a corresponding alarm from CSA showing that CSA was able to prevent the attack.
You might also consider deploying Cisco Threat Response. Threat Response can be configured to do the OS verification for you to determine whether or not the end system was vulnerable. If the end system was not vulnerable it can automatically downgrade the alarm. If the end system was vunlerable it can login to the end system and grab logs that may contain traces for analyzing what happened in the attack.
Once the High severity alarms have been analyzed then determine whether or not you want any automatic actions to occur for these alarms in the future.
Available action include TCP Resetting the TCP connection, blocking the source ip address, or logging the packets to and from the source address of the alarm.
Once you've gone through the High alarms, then attempt to go through the Medium severity alarms doing the same thing.
Most users will then just continue to monitor the High and Medium alarms and even disable Low and Information alarms.
