Cisco Systems IPS-4240 V5.0(3) & IPS-4255 V5.0(3)

Is the product supplied as software only or as a hardware appliance? If supplied as an appliance, please provide the hardware specification (CPU, memory, network cards, etc)
Hardware appliance

4240 - CPU P4 2.0 GHz, 2 GB memory, 4 10/100/1000Base-TX monitoring ports, 1 10/100 Mgmt port. 512 MB Compact Flash

4255 - CPU P4 3.2 GHz, 4 GB memory, 4 10/100/1000Base-TX monitoring port, 1 10/100/ Mgmt port. 512 MB Compact Flash

Does sensor work in-line only, or can it support passive monitoring of switch SPAN port too? If passive monitoring is supported, what is the maximum number of ports that can be monitored by a single sensor?
The Cisco IPS can be deployed in: 1. passive "IDS" mode  2. Inline "IPS" mode  3. "Hybrid" mode that allows "IDS" and IPS" services to run concurrently on a single device. 

The maximum number of monitoring interfaces supported on a sensor is 5. The Cisco IPS sensor can utilize the ports in a variety of configurations, depending on how the type of service (“IDS” or “IPS”) desired and the number network subnets that must be monitored. All inline IPS configurations require a pair of interfaces for each segment to be monitored (“IN” and “OUT” port pairs). All IDS configurations need a single interface for passive IDS services. So for example, with a total of 5 interfaces, the user could configure a pair for inline IPS and the 3 remaining interfaces for performing IDS services on 3 network segments. 

What is the maximum number of in-line connections (port pairs) that can be monitored by a single sensor?
2 in-line pairs. 

What type (copper/fibre) and speed of network connection are supported by the sensor (include default configuration plus any options)?
4240 - 4 10/100/1000Base-TX monitoring ports, 1 10/100 Mgmt port

4255- 4 10/100/1000Base-TX monitoring ports, 1 10/100 Mgmt port 

What High Availability (HA) features are built in to the product by default?
Software Bypass is a software feature that allows traffic to continue to pass across the in-line interface pair in the event the sensor application or main application stops working. It can be configured in “auto” mode to allow un-inspected traffic to pass due to a failure, “on” mode for troubleshooting, or “off” mode if un-inspected is not allowed though. High availability can also be built into the network using multiple sensors and standard Layer 2/3 failover or spanning tree. (NSS note: - state is lost with this type of “HA” deployment)   

What High Availability (HA) features are available as extra cost options?
3^rd party Shore Micro external copper and fiber bypass devices. 

What is the maximum speed/network load (Mbps) claimed with zero packet loss and without blocking legitimate traffic?
4240 - 250 Mbps, both in-line and passive

4255 - 600 Mbps, passive and 500 in-line 

At the maximum load, what is the maximum TCP connection rate through the device (connections per second) claimed?
4240 - 2500 (450 byte packets)

4255 - 6000 passive, 5000 in-line (450 byte packets) 

What is the average latency claimed through the device (and at what load)?
4240 - 750 microsecs at 70% load

4250 - 750 microsecs at 70% load 

Management architecture (2-tier/3-tier management? Brief description)
Cisco offers three solutions for the management of the sensors 1) CLI (Command Line Interface) delivers simple IOS-like commands to easy bootstrap the sensor and perform signature tuning over a secure (SSH) communication channel 2) Cisco IPS Device Manager is a browser based application that allows the configuration of a single device over an SSL connection to the sensor.  IPS DM delivers wizard based utilities that simplify the task of configuring a sensor   3) CiscoWorks VMS is a software based solution servicing the needs of large Enterprise and Service Provider customers by delivering the ability to push sensor configurations to large sensor deployments in an automated manner. CiscoWorks VMS also delivers automated mechanisms to ensure that the sensor maintains the latest IPS signature updates. 

Cisco offers three solutions for monitoring. 1) Cisco Security Monitoring, Analysis, and Response System (MARS) that is an appliance based solution. This solution is a turn-key solution for consolidating security events from IPS, firewall, host security, OS logs, etc. and  other sources like Netflow and performing sophisticated analytics like correlation, attack trace back, auto-mitigation. 2) Cisco VMS Security Monitor is a software solution for doing basic event monitoring and reporting for FW, IPS, and host security devices.  3) CiscoWorks SIMS is a software based solution servicing the needs of large Enterprise and Service Provider customers providing highly-scalable reporting and analysis. 

What are the minimum/recommended sensor OS and hardware requirements? Is a dedicated machine required/recommended?
Appliance based sensors with a Cisco custom built Linux OS. No need to obtain an OS or hardware. See hardware specifications above.  

What are the minimum/recommended console OS and hardware requirements? Is a dedicated machine required/recommended?
Dedicated machine is NOT required 

Windows 2000 or Windows XP

Pentium 3 450 MHz or faster, 256 MB minimum, 512 MB or more strongly recommended

Internet Explorer 6.0 with Java Plug-in 1.4.2 or 1.5 or Netscape 7.1 with Java Plug-in 1.4.2 or 1.5

1024 x 768 resolution and 256 colors (minimum)

Sun SPARC Solaris

Sun Solaris 2.8 or 2.9

Mozilla 1.7

256 MB minimum, 512 MB or more strongly recommended

1024 x 768 resolution and 256 colors (minimum)  

Linux

Red Hat Linux 9.0 or Red Hat Enterprise Linux WS, Version 3 running GNOME or KDE

Mozilla 1.7

256 MB minimum, 512 MB or more strongly recommended

1024 x 768 resolution and 256 colors (minimum)  

What are the minimum/recommended management server OS and hardware requirements (if applicable)? Is a dedicated machine required/recommended?
Dedicated machine is strongly recommended. 

Windows 2000 Professional, Server, and Advanced Server (Service Pack 4)

Pentium 3 1 GHz or faster, 1 GB memory (minimum) 2 GB virtual memory (minimum)

1024 x 768 resolution and 16 bit colors (minimum)

9 GB of free disk space (minimum)  

Sun Solaris 2.8 with these patches:

108528-13, 108827-15, 108528-13, 108827-15, 111626-01, 111327-02, 110945-02, 110934-01 110898-02, 110700-01, 109326-05, 108827-30, 108652-51, 108528-18, 108921-14, 108940-24, 110951-01, 110662-02, 110615-01, 110286-02, 109324-02, 111085-02, 108964-06

Sun UltraSPARC 60 MP with 440 MHz or faster processor or

Sun UltraSPARC III (Sun Blade 2000 Workstation or Sun Fire 280R Workgroup Server)

1 GB memory (minimum) 2 GB virtual memory (minimum)

1024 x 768 resolution and 16 bit colors (minimum)

9 GB of free disk space (minimum)  

List required open ports on sensor and their use
443 (HTTPS) - Configuration and event reporting

22 (SSH) - CLI configuration 

List required open ports on management server (if applicable) and their use
443 (HTTPS)

1741 - Management Web port 

List required open ports on GUI/management console and their use
N/A 

Communication protocol between sensor and management server
Security Device Event Exchange (SDEE) is a communications protocol utilizing XML format and HTTPS as transport.  

Communication protocol between management server and GUI/console
SSL for the GUI interface and SSH for the CLI console. 

Encryption between sensor and management server
SSL and SSH 

Encryption between management server and GUI/console
SSL 

Once deployed and configured, can sensors be managed from a central console?
Yes, Cisco Works VMS includes the IPS Management Center (IPSMC) for configuration management and Security Monitor (SECMON) for event and alarm monitoring. Cisco Security Monitoring, Analysis and Response System (CS-MARS) can also be used for central monitoring. 

Capacity of the system? How many endpoints can be monitored? Ratio of endpoints to management servers/consoles, etc.
Configuration Management - 250 endpoints

Monitoring - Measured purely by the total aggregate rate of messages per second. 

How many management consoles can be actively logged in to the management server at the same time?
Default is 300 but is limited to the apache.conf file for connections. 

What anti-flooding methods are employed (sensor to management server, and management server to console)?
Anti-Flooding is employed by the sensor within its signature configuration to eliminate flooding. Management communication to sensor is initiated by user when applying configuration.  SECMON Monitoring uses active throttling to balance event rate per sensor. 

Some examples of how signature configurations can be used to eliminate flooding are as follows:  Rate based engines, such as "Flood Net" deliver rate based capabilities to prevent event flooding. Also, the sensor supports an Event Counter feature.The Event Counter performs tasks relating to the behavior of alarm triggers. An example of a parameter that specifies ways in which an alarm must be generated is the “MinHits” variable. MinHits specifies a minimum number of signature fires before the alarm is sent. MinHits is used is a user wants a signature to fire only after the offending traffic is seen several times. So for example, the user can choose to fire only a single alarm for a port scan after the sensor has seen 50 port scans over a certain time period.      

Finally and most important is the Event Summarizer. The Event Summarizer executes alarm throttling commands configured by the user. This allows the user to summarize alarms through a variety of techniques. The end result is the ability for the user to minimize the alarm bandwidth of flood attacks. Examples of techniques used to limit alarm firings are as follows:

• ”Fire All”: Always sends alarms when the signature alarm condition is met.

• ”FireOnce”; Sends only the first alarm and then does not send anymore alarms on a particular address set.

• ”Summarize”: This is where the user defines a throttle interval. The sensor sends the first alarm that starts a summary. Subsequent alarms are counted until the end of the pre-specified throttle interval, when a summary alarm is sent. An example of a summary alarm is a single alarm that appears at the monitoring console but notifies that user that 300 alarms were consolidated to from that single alarm. 

Maximum insertion rate into alerts database
SecMon - 100 events per second  

CS-MARS rate is relative to the appliance installed:

CS-MARS20 500 events per second

CS-MARS50 1000 events per second

CS-MARS100e 3000 events per second

CS-MARS100 5000 events per second

CS-MARS200 10000 events per second

Maximum size of database
SecMon - 4 millions events or 4 GB in size 

CS-MARS DB size  is relative to the appliance installed:

CS-MARS20 120 GB

CS-MARS50 240 GB

CS-MARS100e 750 GB

CS-MARS100 750 GB

CS-MARS200 1 TB 

Maximum number of alerts stored
SecMon - 4 million events.

CS-MARS variable depending on model. 

What happens to alerts in main alert database once capacity limits exceeded (deleted/archived/etc)
SecMon -  Alerts are automatically pruned on fifo basis. Streamed pruning.  

CS-MARS - Alerts are automatically pruned on FIFO basis.  Customer may choose to archive.  Archiving is automatic just point CS-MARS to mount point for archival. 

What is maximum recommended size of alerts database to maintain acceptable query performance?
Sec-Mon - 2 million events. 

CS-MARS - Full DB capacity no performance impact. 

When alerts are removed from main alert database, are they still available for reporting directly (i.e. can reporting tools merge current and archived alerts)
Sec-Mon - No 

CS- MARS - Yes, but real-time analysis is not possible while building reports off of the archive. 

Which database product is used for alert storage? Is schema open?
Sec-Mon - Sybase SQL. Schema is not open 

CS-MARS - Oracle.  Schema is not open. 

What happens when communications between sensor and management server/console are interrupted? Local logging on sensor? Maximum capacity? What happens when local sensor logs are full? Is the local repository secure?
If communications are interrupted, the sensor will continue to put events into the local event store. The event store is 30 MB. The event store can handle 270,000+ events before the older events are overwritten in the circular buffer. Upon reconnection of monitoring platform, all events not collected will be pulled back into the monitor. The local event store is not currently protected by encryption but requires privileged rights to access. 

Secure logon for policy management?
Yes 

Granular access (i.e. read only/read-write/etc) granted on a per-user basis? What levels of granularity are supported (i.e. is it possible to restrict user access to specific parts of the management console, to specific appliances, etc.)?
6 roles are supported on the Management Center and are based on a per-user basis. The roles are Approver, Network Operator, Network Administrator, System Administrator, Developer, and Export Data. You can restrict user’s views and functionality. 

Sensors support 4 roles, Administrator, Operator, Viewer, and Service. 

CS-MARS has only one account level.   

Is it possible to define multiple policies for the sole purpose of distributing to multiple sensors with different functions?
Yes 

How are policies distributed to sensors?
Policies are distributed through the management console using SDEE to the sensor 

Can policies be deployed on a per-port, per-sensor or per-group basis, or globally only?
Policies can be deployed on a Per Sensor, Per Sensor Group, and Global basis only 

How are policy changes handled? Will the central console detect which sensors are using a changed policy and redeploy automatically, or does the administrator have to do this manually?
Policy changes are manually controlled. When the user sends an update to the sensor that is different from current configuration on the MC, MC will notify user if he wants to overwrite or abort changes 

Can policy deployment be scheduled?
Yes, policy deployment can be scheduled for immediate delivery or by date and time. 

Does the sensor remain able to detect alerts at all times during policy/signature updates? If so, explain how this is achieved. If not, for how long is it inactive, and does the sensor block all or pass all traffic whilst inactive?
Yes, during policy changes, the ability to detect events is fully supported.

During signature updates network connectivity may be maintained but inspection will be disabled for approximately 1 to 2 minutes. 

Can the administrator define custom attack signatures?
Yes. A custom signature wizard is built into the product as well as the ability to add, copy/modify existing signature engines 

Regex supported when creating custom signatures?Yes, full Regex capability is supported.  Additionally full signature development using any of the built in engines is available. 

How are new vendor attack signatures obtained and deployed?
Signatures can be downloaded via Cisco.com with a valid maintenance contact. Automated signature downloads from Cisco.com to the Management Center is possible. Updates need to be pushed manually to the sensors. Customer who subscribe to the Active Update will automatically be notified when updates are available.  

Frequency of signature updates?
Guaranteed bi-weekly at a minimum, however, updates are routinely coming out once a week and have been for the last 6-8 months.

What infrastructure does the vendor have behind the signature update process (i.e. dedicated team of engineers? How many? Does it have a name?)
Two Teams of dedicated Engineers. The IPS software development team and the Customer Advocacy team both have full time signature developers. The CA team is staff 24x7 around the world and handles the majority of late breaking signatures.   

Can one signature update file be downloaded to the local network and used to update all sensors from a central location, or is it necessary to initiate a live connection to the Internet download server for each sensor/management server?
A single MC can download the update once and push updates to all sensors it manages.  If you have more than one MC, each MC must download the update or be manually copied from another MC. No live Internet connection is required for the sensors, just the MC.  Optionally you may schedule your sensors to automatically update themselves from a central FTP server. 

Can signature updates be scheduled and fully automated? Is automated download AND deployment to sensors supported, or just download (or neither)?
Downloading updates from Cisco.com can be scheduled and full automated. Updates can then be manually deployed to each sensor or group of sensors from the MC.  Optionally you may schedule your sensors to automatically update themselves from a central FTP server. 

What network protocols are analysed?
Including but not limited to:  IP, TCP, UDP, ICMP,  NETBIOS/SMB, MPLS, ARP, 801.1q, IPv6 encapulated IPv4, IGMP,IP-in-IP, GRE. 

What application-level protocols are analysed?
Application inspection control of HTTP, port 80 misuse/application tunneling, FTP, and mime type filtering. , DHCP, DNS, FTP, File Sharing (peer-to-peer), Finger, HTTP, HTTPS, IMAP,  IDENT, LPR,NNTP,  NTP, POP, R-Services, RPC,  MSRPC, SMTP,   SNMP, SOCKS, SQL, SSH, TELNET, TFTP,, H323, H225, SSH, WINS, MSSQL, IRC, LDAP 

Can the product perform protocol decodes?
Yes, Cisco’s  Protocol decode-based signatures are in many ways intelligent extensions to stateful pattern matches. This class of signature is implemented by decoding the various elements in the same manner as the client or server in the conversation would. When the elements of the protocol are identified, the IDS applies rules defined by the RFCs to look for violations. 

Can the product perform protocol anomaly detection?
Yes, Cisco’s Anomaly-based signatures are geared to looking for network traffic that deviates from what is seen "normally." Another type of anomaly-based detection is protocol-based anomaly detection. Finally statistical anomalies may also be identified on the network either through learning or teaching of the statistical norms for certain types of traffic, such as traffic floods (UDP, TCP, or ICMP floods).  

Can sensor support both normal and asymmetric network configurations?
The sensors support both configurations as long as in the asymmetrical configuration the sensor has visibility into both sides of the connection by utilizing a second interface plugged into the second path on the same sensor. 

Is the detection engine “stateful”? If so, please explain how this works.
Yes, The Cisco IPS tracks state in a number of ways including:

* TCP/IP flow normalization: packets in a flow are properly ordered before inspection.

* Protocol Decode State is maintained in protocols that span packets in a flow. For example HTTP pipelining, RPC record marking, pattern matching, etc. 

If stateful - how many open connections can be tracked? Is this value configurable?
4240 - 250,000

4255 - 500,000

Can be adjusted with support.  Not generally available to the customer base at large. 

If stateful - for how long are partially opened connections tracked? Is this configurable?
After 15 seconds of inactivity (by default), the connections will be purged from the table. Configurable. 

If stateful - for how long are fully opened connections tracked if not used? Is this configurable?
After 3600 seconds of inactivity (by default), the connections will be purged from the table. Configurable 

What is the default action when system resources run low or state tables are filled - block or permit all new connections? Is this default action configurable?
When state tables start to run low, the sensor will automatically begin to age out the oldest inactive connections, thus never having to block new connections.  This will result in older established connections that may have been idle but not for the full idle timeout to be closed earlier than expected. 

What is the default action when power fails or the system is powered down - block or permit all traffic? Is this default action configurable?
When using a single sensor in in-line mode, all traffic is blocked on a power fail/down. However, a second sensor can be deployed in standby mode and when the primary sensor is powered down/fail, the network will re-route the traffic to the secondary sensor using standard Layer 2/3 network redundancy features (NSS note: state is lost with this type of “HA” deployment). The sensor also has a built in software by-pass mechanism to permit traffic to flow should one of the applications on the sensor stop working. This is configurable. External hardware by-pass devices from a 3^rd party can also be deployed.  

What is the default action when the sensor is unavailable for any length of time (i.e. during policy download or software update - block or permit all traffic? Is this default action configurable?
Default action is to permit all traffic and is user configurable. 

Will the detection engine block/alert on ALL suspicious activity, or only when an attack is made against a vulnerable server? If so, please explain in detail how this works. Can this behaviour be modified (i.e. to alert on ALL attacks if required)?
If the attack payload delivery is attempted, the sensor will alert and block (if configured to do so). The server may or may not actually be vulnerable to the attack. The user can configure what actions should be taken including whether or not to produce an alert. 

Are server responses monitored and alerted/blocked? Does this have an impact on performance?
Yes, server responses are monitored.  Performance is affected  when the Application Inspection Policy engine is employed.  This engine is disabled by default. 

Ability to monitor user-defined connections (i.e. report on an FTP connection to a specific server?)
Yes, using a custom signature 

Detect/block network-level packet based attacks?
Yes, both detect and block 

Detect/block all types of port scans (full connect, SYN stealth, FIN stealth, UDP)?
Yes, the sensor will alert after the 5th (By default this is the threshold.  It is user configurable.) packet and can block using the deny-attacker action

Detect/block SYN floods? Manual or automatic thresholds? Configurable? How is SYN flood protection implemented?
Yes, the sensor can detect SYN floods. Thresholds are manual and configurable. The sensor currently detects SYN floods. In 5.0 SYN flood protection for the IPS device was added.   The protection provided is for the sensor and does not apply to the targets. 

Perform packet/stream reassembly?
The TCP normalizer engine performs full stream reassembly and was designed to handle all known evasion techniques. For a better description of some of these attacks refer to Insertion, Evasion and Denial of Service: Eluding Network Intrusion Detection (1998) by Ptacek and Newsham. 

Perform deobfuscation?
Yes, UTF-8 encoding, Microsoft’s custom Unicode %Uxxxx encoding, Double Encoding, Un-Encoded octets mixed with encoded octets in a UTF8 sequence, Ambiguous bits, Microsoft base-36, Alternate code pages, Multiple directory delimiters.  

Is all traffic scrubbed/normalised/reordered as it passes through the sensor?
TCP/IP Normalizer Engine performs this task and addresses many types of IPS evasion techniques:                                                                               

1. The sensor contains a Layer 3 Fragmentation Normalizer, that maintains a datagram table to store fragments of packets until all fragments within the stream have been collected, after which these fragments are reassembled and sent on for further signature processing. The Layer 3 Fragmentation Normalizer also scrubs the fragmented stream of overlaps and drops any fragmented traffic that contains an overwrite condition.                                                                                              

2.  The sensor also contains a Layer 4 Stream Normalizer also has the ability to deal with many IPS evasion techniques.  As an example let’s take the case of an evasion technique that deals with TTL (time to live) modifications. When a router receives a packet, the TTL value of the packet is decremented. This is done at every hop through which the packet traverses.  If a router or host receives a packet with a TTL of “0”, the packet is automatically dropped. Attackers can manipulate packet TTLs is an attempt to take advantage of the fact that the IPS sensor does not have a concept of how many hops there are between itself and the endpoint to which the packet is destined. In this case, the attacker will craft bogus packets that have TTL values in a range that allows the IPS sensor to see them, but the crafted TTL will not cross an upper threshold that is required for it to reach the endpoint or the target. The sensor sees this bogus packet, analyzes it and forwards it on. As designed by the attacker, this packet will eventually reach a value of “0” and the router between the IPS and the endpoint will now drop the packet. The result is that the bogus packet did not reach the endpoint, as planned by the attacker. The attacker can then send another malicious packet with a longer TTL that is guaranteed to reach the endpoint. Traditional IPS sensors will view this malicious packet with the longer TTL as a duplicate or re-transmit that also be erroneously forwarded. This malicious packet now reaches the endpoint and can cause damage. The IPS v5 sensor removes the ambiguity from the TTL and insures that only valid TCP sessions will pass on to the end point.   

3. The Layer 4 TCP Stream Normalizer also assures the only valid TCP sessions are inspected.  It handles all of the typical reordering and stateful inspection of the TCP stream before pasiing on the reordered packets for inspection.                                                                                                                                                              

4. The sensor has the ability to deobfuscate attacks that use unicode message transformations to evade traditional IPSs. 

How is fragmented traffic handled by the sensor?
Fragmented IP packets are ordered and assembled prior to inspection 

List all prevention features available (alert only, drop packets, block TCP session)
The sensor Performs Response Actions on all signatures that have response actions configured for them. IPS v5 has incorporated a number of new response actions that primarily pertain to inline packet drops. Cisco IPS delivers a variety of inline drop actions that that can be applied:  the ability to drop single malicious packets, all packets within a flow that contains multiple malicious packets, and all packets from the attacker's IP address. These inline response actions complement existing response actions such as connection resets and access control list (ACL) modifications on switches, routers, and firewalls, to ensure that the attack is not only at the point where the IPS is deployed, but also at key policy enforcement points throughout the network. 

The following response actions may be configured on the IPS v5 sensor on a per signature basis:

• Produce Alert

• Produce Verbose Alert

• Request SNMP Trap

• Log Pair Packets

• Log Victim Packets

• Log Attacker Packets

• Reset TCP Connection

• Request Block Connection

• Request Block Host

• Deny Attacker Inline

• Deny Connection Inline

• Deny Packet Inline 

List any other security features available (bandwidth shaping, rate limiting, etc.)
Risk Rating - The risk rating is realized as an integer value in the range from 0 to 100. The higher the value, the greater the security risk of the trigger event for the associated alert. The risk rating is a calculated number that has four primary components-Alert Severity Rating (ASR), Signature Fidelity Rating (SFR), Attack Relevancy Rating (ARR), and Target Value Rating (TVR). 

The ASR is a user-modifiable weighted value that characterizes the damage potential of the suspect traffic. It is presented to the user in familiar, descriptive text tags-informational, low, medium, and high. 

• An informational alert is based on commonly seen network traffic and has no particular security relevance when seen on most networks. It may be a violation of a policy on some networks, but it generally poses no immediate threat to network security. 

• A low alert is also based on relatively benign network traffic, but is somewhat unusual on most networks. Also categorized as low would be overt scans, such as those commonly seen by network management devices. Although this type of scan could be a precursor to an attack, it is uncommon for an overt scan to be used for this purpose. 

• A medium alert is based on traffic that generally should not be seen on the network. It is usually assigned to midlevel reconnaissance traffic, denial of service (DoS) attacks on self-healing services, and remote access of unexpected information or programs. This type of behavior warrants investigation or preventive actions, sometimes requiring policy decisions from the user. 

• A high alert is based on traffic that is indicative of an active attack or an obvious precursor to an attack. This traffic should never be seen in a normal network. This rating is reserved for attacks that could result in serious compromise of the target, or for specific network traffic that is only seen in covert reconnaissance traffic. 

The SFR is a user-modifiable weighted value that characterizes the fidelity of the signature that has detected the suspect activity. Several factors affect the fidelity of a signature. First, many vulnerabilities are only relevant for a particular OS, service, application, or even patch level.

Without this information, particularly in the classic IDS mode, the sensor may identify attempts that will ultimately fail as actual attacks, leading to wasted effort on the part of the security administrator investigating the alleged attack. Another issue that can cloud the fidelity of a signature is a legitimate application that produces traffic that mimics the behavior of an exploitation of a network vulnerability. The signature developer takes these factors into consideration when assigning the SFR for a particular signature. 

The ARR is an internal weighted value that characterizes any additional knowledge that the sensor may have about the target of the event. This information is used to clarify some of the uncertainties related to signature fidelity. As the sensor builds a more definitive picture of the target host, the risk associated with the event can be better defined.

Finally, the TVR is a user-defined value that represents the user's perceived value of the target host. This allows the user to increase the risk of an event associated with a critical system and to de-emphasize the risk of an event on a low-value target. 

MEG - Meta Event Generator Cisco IPS Sensor Software Version 5.0 incorporates sensor-level event correlation that gives security administrators an automated method for enhancing the confidence level of the classification of malicious activity detected by the sensor. This provides a mechanism that allows for corresponding actions to deliver networkwide containment of worm and virus injection vectors, as well as worm propagation. This is accomplished through the following techniques: 

• Correlation of alarms pertaining to worms that exploit multiple vulnerabilities

• Meta event generation for sequences of actions leading up to worm infestation

• Automated elevation of severity ratings when groups of events signify worm/virus activity

• Enhancement of alarm fidelity through simultaneous triggers based on hybrid detection algorithms 

Packet capture capabilities? Only the trigger packet, or before and after? How are packet captures stored/viewed?
Full IP session logging by attacker, pair, or victim packets is supported as well as the trigger packet only capture. IP Logs are stored on the sensor and can be pulled using the MC. IP Logs can be viewed using Ethereal. 

Do you track and display context data as part of each alert (i.e. for an FTP overflow, do you show which user name/password combination was used to login to the FTP server, etc?). If so, how much context data is available?
Trigger packet can be optionally sent with each alert.  Additionally all stream based engines will maintain 256 bytes of session context in each direction which will be reported at alert time.  We do not maintain login success or failure information. 

Option to record entire sessions for “forensic” investigation? Where is this data stored? How is it secured from tampering?
IP Session Logging can be used to record entire sessions. The data is stored in log files on the sensor or can be retrieved via the management console for viewer. The logs are secured by logon rights and access control.   

Reporting from sensor to console - range of alert response options (detail these, i.e. log, alert, e-mail, pager, packet capture, etc)
SEC-Mon -  The following are available: log, alert via email or epage, display packet capture and iplogs from sensor. 

CS-MARS - The following are available: log, alert via syslog, email, pager, or SNMP.  Currently CS-MARS does not support display of ip-logs or trigger packet from the IPS. 

Can alert response options be set only at a global policy level, only at individual signature level, or to groups of signatures (or a mixture of all three)?
Alert response options may be set with any of the three methods mentioned.  

Can alerts be reported to the central console in real time without the use of third party software? How easy is it to filter and extract individual events?
Sec-Mon - Yes, in “near” real-time. Easy by defining filters. 

CS-MARS - Yes, in “near” real-time.  Easy and extensive rule based querying. 

Can alerts from all sensors be viewed at a single console at the same time (i.e. without having to connect to separate sensors from the console)?
Sec-Mon/CS-MARS - Yes, all sensors being monitored can be displayed in a single window at the same time. 

Can the central console correlate alerts from multiple sensors (i.e. not just display alerts from multiple sensors, but attempt to infer a connection between different alerts on different sensors)? Is this offered as standard or extra-cost option?
Yes, VMS SECMON monitors all of the sensors in the device list with aggregation, rules, viewing and reports. Standard with 1-5 devices, extra cost applies after 5 devices. 

Our best solution for correlation is the CS-MARS platform.  This platform will also allow for correlation of FW, Router, Net-flow, and imported events from third party sources. (Extra cost) 

Can alerts be correlated manually by the administrator - grouped together in the database as a single event for further investigation?
Yes, with the event viewer and rules.

Alternatively this is the standard method of display with the CS-MARS device. 

Can alerts/events be annotated and tracked for investigation by multiple administrators/investigators?
No. 

Does the software offer advice on preventative action to ensure the attack does not happen again?
Yes - the Cisco MARS product does (extra cost) 

What industry standards are supported - Intrusion Detection Exchange Format working group (IDWG), Intrusion Alert Protocol (IAP), Intrusion Detection Message Exchange Format (IDMEF), IDXP - and in what way?
RDEP and SDEE 

Which third party event correlation systems are supported and in what way?
netForensics, nCircle, Arbor Networks, ArchSight, and others.  Through exposure of the SDEE event reporting schema and the RDEP service. 

Integration with other scanning/IDS/prevention products?
SDEE is an open communication and formatting protocol that allows for a common event reporting structure between different systems. Several vendors have adopted this standard, which allows them to interoperate.  

Log file maintenance - automatic rotation, archiving, reporting from archived logs, etc.
Archiving.  Disk File Watcher feature shows sizes of log files that are not archived. 

Management reporting - range of reports/custom reports/how easy is it to filter and extract detail? Different reports for technicians and management/end users?
CS-MARS - Provides highly customizable reporting (at extra cost).  The reporting schemes available on CS-MARS are extremely flexible and simple to use.  Many canned reports are available as well as support for the aforementioned custom report rules.   Reports appropriate for both the technician and management are provided.

• GUI supports numerous default queries and customized queries

• Over 80 popular reports: management, operational, and regulatory

• Report generation yields unlimited customized reports

• Data, chart, and trend formats support HTML and CSV export

• Live, batch, template, and email forwarding reporting system 

Are trend/comparison reports available?
Trend / comparison reports are available for both events generated from the devices and configuration comparisons across devices. 

On the monitoring side, trend / comparison reports and charts allow the user to discern historical trends based on event profiles. This allows the user to proactively take actions on the IPS sensor when the initial pattern of the trend is observed. 

On the configuration side, the Configuration Comparison Tool, provides four types of configuration comparisons:

• Between the current configuration in the database and generated configuration files.

• Between two generated configuration files.

• Between any configuration file and the factory default configuration.

• Between any configuration file and the configuration running on a particular device.  

Does reporting allow customised filtering down to the level of reporting all activity on a specific network resource/object by a specific user/machine on a specific date?
CS-MARS - Yes 

Report management - can they be scheduled for automatic production? Can they be e-mailed to administrators or published straight to a Web site?
CS-MARS - Yes, reports can be scheduled for automatic production and can be emailed or sent to a pager.  Publishing to web site would require scripting to publish the e-mailed report. 

List the output formats supported for reports (HTML, text, PDF, etc)
CS-MARS - HTML, CSV 

What are the limitations and restrictions on enterprise-wide alerting and reporting? Can reports consolidate output from every 1) server, 2) detector
CS-MARS - Full consolidation from all reporting devices. 

Ability to define custom reports?
CS-MARS - Yes. An extremely flexible rules based report creation tool is provided.  The user may customize reports to his or her specific needs.  

Provide brief description of any management software included in the base price of the product. 
VMS Basic which includes MC and SecMon 

Provide brief description of any additional management products available as extra cost options. 
VMS Restricted and Unrestricted.  Cisco Security Monitoring, Analysis and Response System (CS-MARS) 

Documentation provided (Hard copies available? Extra cost?)
Full documentation is posted on Cisco.com and available on CD with each new appliance. No hard copies are available. 

How is the product licensed? How is the license enforced?
Licensing is enforced for signature updates. The license is tied to a maintenance contract (Cisco Services for IP) 

End user pricing information for product provided for test (include all sensor, management server and console costs for both hardware AND software). Include options/configurations other than those tested - ALL PRICES AS LIST PRICE ONLY!
4240 - $11,995.00

4255 - $24,995.00 

VMS Management Software - $19,995.00 for Unrestricted and $7,995.00 for 20 device restricted. 

CS-MARS20 $15,000.00

CS-MARS50  $27,000.00

CS-MARS100E $55,000.00

CS-MARS100  $95,000.00

CS-MARS200  $125,000.00 

Ongoing cost of maintenance/updates
For the sensor device support including signature updates, bug fixes, service packs, and software upgrades is 18% of list price. 

VMS support is included in the sensor support cost when using the 0-5 sensor VMS “lite” license included out of the box. Where other license levels are selected, the following support costs apply:  

VMS 2.3 unrestricted device license - $3,999

VMS 2.3 restricted (20) device license$1,599

Software Application Support plus Upgrades for VMS 2.3 unrestricted device license - $5,199

Software Application Support plus Upgrades for VMS 2.3 restricted (20) device license - $2,079 

MARS support is 20% of list price of appliance ($3000 as tested)

Click here to return to vendor questionnaire index
Click here to return to the Cisco 4240 Review
Click here to return to the Cisco 4255 Review
Click here to return to the IPS Index Section