 |
|
Cisco IDS-4235 V4.0
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)
IDS Sensors are supplied as hardware only.� The IDS 4235 that was submitted for
this test has a 1.3 GHz processor , 1 GB RAM, 18 GB HD 10/100/1000 TX only
CiscoWorks VPN/Security Management Solution (VMS) is the principal management product and is delivered as software only. CiscoWorks Security Information Management Solution (SIMS) provides additional scalability for monitoring �and is delivered both as an appliance and as a software only solution for flexibility. The SIMS appliance is based on a server with dual Intel Pentium IV Xeon CPU�s,� 4GB memory,� 146GB disk.
What is the maximum speed/network load (Mbps) claimed with zero
packet loss?
IDS-4235:� 200 Mbps with 4.0 Sensor Software. The test was performed using 4.0
sensor software. (The 4235 is rated at 250 Mbps with v 4.1 sensor software).
At the maximum load, what is the maximum TCP connection rate
(connections per second) claimed?
For the 4235 running 4.0 Sensor Software: 2000 connections/sec, 2000 http
transactions/sec, with 100,000 total flows
Product architecture (2-tier/3-tier management? Brief
description)
Cisco IDS architecture comprises of two components: IDS Sensor &
IDS Management:
IDS Network Sensor: These are in the form of standalone turnkey appliances (IDS 4215, 4235, 4250, 4250-XL), a module for the Cisco Catalyst 6K switch (IDSM � IDS Module), or a Network Module for the Cisco Access Routers. Sensors monitor traffic by directly �tapping� the line via a shared-media hub or by receiving copies of the traffic by the use of SPAN (Switched Port Analyzer) on a switch. There are two types interfaces on the appliance sensors: the sniffing interfaces and the command and control interface. The sniffing interfaces perform packet capture. The Cisco IDS appliance line of sensors support up to 5 sniffing interfaces. The command and control interface sends alarms to the management console and receives configuration information from the management console.�
IDS Management:� Cisco offers the standalone web based IDM and IEV management tools for the smaller sensor deployment.� For larger deployments we provide the CiscoWorks VMS. This web based software is used to configure the sensors, manage signatures and perform event viewing and reporting of the IDS alarms.
For security monitoring of even larger deployments or monitoring of multi-vendor networks we also provide CiscoWorks SIMS. This is a solution that collects, analyzes, and correlates security event data from across the enterprise, and is based on technology from netForensics
What are the minimum/recommended sensor OS and hardware
requirements? Is a dedicated machine required/recommended?
The Cisco IDS sensors are hardware based turn key solutions that comprise of the
sensor software, the underlying OS, and the sensing hardware. The underlying
sensor OS is RedHat Linux that has been �hardened�.
What are the minimum/recommended console OS and hardware
requirements? Is a dedicated machine required/recommended?
We provide browser based access to the management server software.� The
platforms supported for the client browser include Windows and Solaris.�
VMS Client Browser
VMS Client Hardware
The CiscoWorks SIMS� client is JRE based. It can run on any platform that supports JRE, including Windows, UNIX/Linux, MacOs.
What are the minimum/recommended management server OS and hardware requirements (if applicable)? Is a dedicated machine required/recommended?
The VMS Management Server software is supported with Windows 2000 Professional, Server, and Advanced Server. We also support a Solaris 2.8 server.�
VMS Server Hardware:
The Cisco Works SIMS can run on LINUX or Solaris OS. It runs on RedHat AS 2.1 or Solaris 2.8. The hardware requirement is based on the number of messages that are processed for a given period of time. SIMS is a distributed architecture. The three layers can run on the same box with as little as 1 gig of RAM, single Pentium III cpu and 30 gigs of hard drive. On the other end of the spectrum, the individual tiers can be run on a box by themselves.� A good starting point is a Pentium IV box with 2 gigs of RAM and at least 40 gigs of Disk space. The CiscoWorks SIMS is also available as an appliance for easy setup and is based on a server with dual Intel Pentium IV Xeon CPU�s,� 4GB memory,� 146GB disk. �
List required open ports on sensor and their use
SSH port 22.�
List required open ports on management server (if applicable) and
their use
Depending on what components are installed from VMS the following lists
potentially open ports:
Cisco Common Services Port 443,� 52514, 9652, 1272,� 10033
Security Monitor �Syslog� - UDP/514,� Postoffice service - default UDP/45000
CiscoWorks SIMS requires ports 80 and 9002 to be open on the management box. This is assuming that all the components are on the same box. If a distributed model is deployed, then ports 9000 and 9001, as well as 1521 should be opened as well.
List required open ports on GUI/management console and their use
Browser: �1741 and 1742 for HTTP and HTTPS�
Communication protocol between sensor and management server
The Cisco IDS uses the Remote Data Exchange Protocol (RDEP) for
communication between an IDS sensor and IDS Management Station. The event
messages used for alarming are in an Extensible Markup Language (XML) format.
Communication protocol between management server and GUI/console
HTTP and HTTPS�
Encryption between sensor and management server
HTTPS, SSL and TLS�
Encryption between management server and GUI/console
HTTPS�
Once deployed and configured, can sensors be managed from a
central console?
Yes. Both configuration and event monitoring for the sensors can be performed
from a central console.�
Capacity of the system? How many endpoints can be monitored?
Ratio of endpoints to management servers/consoles, etc.
In terms of monitoring, the ratio of sensor to VMS monitoring console is highly
dependant upon the degree to which the sensors are tuned. Numerous well tuned
sensors generate the same alarm volume as a single poorly tuned sensor. The
actual event volume will determine how many sensors can be monitored from a
single console.���� �
With CiscoWorks SIMS, Agents are configured to store and stash anything that can not be forwarded. Therefore guaranteeing that events will reach their end destination eventually.�
In terms of configuration, VMS has been rigorously tested for deployment to several hundred sensors from a single server.��
What anti-flooding methods are employed (sensor to management
server, and management server to console)?
RDEP protocol can poll and control the event rate.
Maximum insertion rate into alerts database
VMS supports 500 events/sec burst mode for 5 mins.�
Maximum size of database
In VMS there is no defined maximum database size.� Its limited by the size of
the disk.�
Maximum number of alerts stored
There is no defined maximum.�
What happens to alerts in main alert database once capacity
limits exceeded (deleted/archived/etc)
We have automatic scripts to delete or archive the database when a user defined
threshold is reached.�
What is maximum recommended size of alerts database to maintain
acceptable query performance?
We recommend 2 million events.�
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)
Archived events can be imported again. Reports will include the imported
events.�
Which database product is used for alert storage? Is schema open?
Sybase. Schema is not open.
CiscoWorks SIMS is Oracle based.�
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?
CiscoWorks SIMS can be architected in a distributed fashion. In
this scenario agents would be installed close to the sensors, perhaps on the
same subnet with minimal possibility of interruption in the flow of data. Agents
in turn, are smart enough to realise when they have lost the connection to the
engines. In this case, events are stores in the local machine automatically
until the connection is restored.�
Secure logon for policy management?
Authentication to the management console is achieved using
username/password with support for certificate authority.
Integration with AAA servers is also supported for additional authentication and authorisation.�
Granular access (i.e. read only/read-write/etc) granted on a
per-user basis? What levels of granularity are supported?
Up to 5 user roles are provided in the box with additional roles
provided by integration with the Cisco ACS server (AAA server).�
Is it possible to define multiple policies for the sole purpose
of distributing to multiple sensors with different functions?
Yes, we support customised config policies for individual sensors
or groups.
�
How are policies distributed to sensors?
It is a push model. A great deal of granularity is provided to
the user in terms of their ability to tune signatures, add notifications,
configure device management capabilities with the blocking feature, etc. This
allows users to create customised management templates that can be grouped� and
deployed simultaneously to sensors within the defined groups.
�
Can policies be deployed on a per-sensor or per-group basis, or
globally only?
Policies can be deployed per sensor or per-group.� Individual
sensors can inherit settings from a parent group or override parent group
settings if the operator has the authorisation.
�
How are policy changes handled? Will the central console detect
which agents are using a changed policy and redeploy automatically, or does the
administrator have to do this manually?
The management console will detect the presence of a change that
was made to a sensor but there is currently no mechanism to display the
difference between the initial configuration that was pushed to a particular
sensor versus what it currently contains. �
Can policy deployment be scheduled?
Yes, the data and time can be specified.�
Does the sensor remain able to detect alerts at all times during
policy/signature updates? Explain how this is achieved.
No.�
Can the administrator define custom attack signatures?
The management console provides a mechanism to tune existing
signatures and to create new signatures based on customised parameters
pertaining to IP header information. In addition, custom packet payload
information can be specified and configured as a regular signature. For example,
the string �etc/shadow� can be monitored bi-directionally to determine if an
attacker is attempting to access a password file on a Unix box.
�
Regex supported when creating custom signatures?
Yes�
How are new vendor attack signatures obtained and deployed?
There are a number of mechanisms by which signatures can be transferred to the
sensors.
Frequency of signature updates?
Biweekly. However, Cisco IDS also supports Emergency Updates. For
example, for widespread worms like Code Red, Cisco IDS sends the entire Cisco
IDS user community (via IDS Active Update Notifications) a custom signature to
detect/mitigate such threats. These Emergency Updates can be applied to the
sensor and provide immediate protection within 24 hrs. of the emergence of such
attacks.�
What infrastructure does the vendor have behind the signature
update process (i.e. dedicated team of engineers? How many? Does it have a
name?)
Cisco IDS has a dedicated team of engineers for this purpose. They are known as
the C-CRT team�
Can one signature update file be downloaded to the local network
and used to update all IDS engines 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 signature update file can be downloaded to a local
network FTP site. Each of the sensors deployed can then pull the signature
update from this local network location. This can be configured using the IDM
tool.�
With VMS a signature file can be downloaded onto the management server and then the operator can update multiple sensors concurrently.�
Can signature updates be scheduled and fully automated?
Yes. The schedules can be based on a time frequency or on a specific date/time.
The update process is fully automated.
Which network types are supported by the sensor?
IP networks�
What network protocols are analysed?
The protocols analysed include, but are not limited to: IP, TCP, UDP, ICMP, ARP,
RARP.
What application-level protocols are analysed?
HTTP, HTTPS, FTP, SNMP, Telnet, SMTP, DNS, RPC, SMB, SSH, Ident,
NTP, etc�
Can the product perform protocol decodes?
Yes�
Can the product perform protocol anomaly detection?
Yes
Is the detection engine �stateful�? If so, please explain how
this works.
TCP Stream Reassembly allows the sensor to track the state of TCP
connections to determine what packets are part of a valid stream and whether the
destination accepts the packet as valid.� This is done to help eliminate false
positives resulting from either attackers sending copies of crafted packets to
flood an IDS console with alerts, or from an attacker starting a TCP session and
then sending packets that will not be accepted by the destination (such as ones
with bad checksums). �
We keep full session state on both endpoints of TCP.�
We also keep full state on many protocols. For example during HTTP we know which part is the request, and then further divide the request into method, uri. And then further divide uri into host, arguments, etc.�
We also take care of protocol reassembly� for things like RPC where the protocol allows fragmentation on top of the fragmentation provided by IP and TCP.�
If stateful - how many open connections can be tracked? Is this
value configurable?
2000 connections/sec, 2000 http transactions/sec, with 100000
total flows.�
If stateful - for how long are partially opened connections
tracked? Is this configurable?
Partially open can be configured from 3-300 seconds with a default of 15
seconds.�
If stateful - for how long are fully opened connections tracked
if not used? Is this configurable?
Open and established sessions can be configured from 15 to 3600 seconds with a
default of 900 seconds. We are looking into changing this so that you will only
expire the flows on an as needed basis.�
If stateful � explain the behaviour of the system when the state
tables are filled
When state tables are filled, older state information is automatically aged
out.�
Will the detection engine 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)?
Both. The IDs can be tuned to alert on ALL suspicious traffic. In addition, with
CTR (Cisco Threat Response), the user has the capability of viewing alerts only
when they are made against vulnerable servers.� Threat Response works through a
just-in-time investigation of the target system to determine if it is vulnerable
to the attack, and if so, then determines if the attack succeeded or failed.�
Successful attacks are quickly escalated to critical and brought to the
attention of the security admin.� False alarms and failed attacks are
downgraded; the events are still available for review and historical analysis.�
The result is that security staff are able to focus on those events that are
critical and require immediate attention.� Customers have experienced a decrease
in alarm load by as much as 95% while using Cisco Threat Response. This is
achieved through a OS fingerprinting, server patch level analysis, and
inspection of web logs and registry files.�
Are server responses monitored and alerted upon?
Server responses are monitored.�
Ability to monitor user-defined connections (i.e. report on an
FTP connection to a specific server?)
Yes. Connection based signatures are also supported. �
Detect network-level packet based attacks?
Yes. Custom packet payload information can be specified and configured as a
regular signature. For example, the string �etc/shadow� can be monitored
bi-directionally to determine if an attacker is attempting to access a password
file on a Unix box.�
Detect all types of port scans (full connect, SYN stealth, FIN
stealth, UDP)?
Yes.�
Detect SYN floods? Manual or automatic thresholds? Configurable?
Yes, this feature is fully automated and can be very granularly configured by
the user.�
Perform packet/stream reassembly?
Yes.
Perform deobfuscation?
Yes.
List all �prevention� features available (TCP reset, ICMP
unreachable, firewall reconfiguration, drop packets (in-line only))
Packet drops with the IOS-IDS in their routers and the Firewall Sensors;� Call
interception with the CSA (Cisco Security Agent) for desktops and servers. TCP
resets & ACL modifications on firewalls, switches and routers using IDS
sensors.�
Packet capture capabilities? Only the trigger packet, or before
and after? How are packet captures stored/viewed?
IP session logging is supported and can be configured on a per signature basis.
When a particular signature triggers for which IP Session Logging is configured,
a session log is immediately generated that records all the keystrokes
originating to and from the offending source IP address. These logs are in the
TCP Dump format and can be viewed using freeware such as Ethereal. Other
applications such as TCP Replay can be used to replay the entire session log for
forensic//post-mortem analysis.�
IDS v 4.1 also delivers the fully decoded contents of the trigger packets in the alarm that is displayed at the monitoring console.�
Option to record entire sessions for �forensic� investigation?
Where is this data stored? How is it secured from tampering?
IP session logging is supported and can be configured on a per signature basis.
When a particular signature triggers for which IP Session Logging is configured,
a session log is immediately generated that records all the keystrokes
originating to and from the offending source IP address. These logs are in the
TCP Dump format and can be viewed using freeware such as Ethereal. Other tolls
such as TCP Replay can be used to replay the entire session log for
forensic//post-mortem analysis. These logs are stored on the hard drive and
hence files cannot be edited/changed.�
Reporting from sensor to console - range of alert response
options (detail these, i.e. log, alert, e-mail, pager, packet capture, etc)
We support email, email based paging, logging and packet capture using
functionality on the sensor and the VMS mgmt server.
CiscoWorks SIMS has even more response options.�
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)?
Mixture of all three.�
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?
Yes. With VMS, filtering can be done very easily by simply dragging and dropping
the column headers of the tabular event viewer to the left portion of the screen
and sorting the data by a variety of attributes including source IP address,
sensor name, destination IP address, alarm type, severity level, etc.�
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)?
Yes with VMS and CiscoWorks SIMS.�
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)?
Yes. With VMS rules can be specified that will correlate the occurrence of
events across multiple sensors. When the rule set is met, an action can be
automatically triggered. For example, if a certain signature fires 3 times on
two different network sensors and a host based agent, then execute a customised
script, or send a notification.�� The operator can define the rules with the web
based GUI. The event rules can help to detect emerging attacks which may not be
apparent from a single event or single device source. For example we provide
correlation between events from Network IDS, Host IDS, IDS on Cisco Routers and
IDS implemented on the Cisco PIX firewall.� The operator can see the bigger
security picture because all these events are available for viewing and
reporting.�
Can alerts be correlated manually by the administrator - grouped
together in the database as a single event for further investigation?
No with VMS�
Can alerts/events be annotated and tracked for investigation by
multiple administrators/investigators?
Yes annotations for the alert can be made in the associated NSDB (Network
Security Data Base) entry for each alert . The NSDB provides granular
descriptions for each alert/event, provides information on benign triggers and
recommended severity ratings, lists associated CVE entry #s, and describes
exploit tools that could be used to exploit the vulnerability.�
Does the software offer advice on preventative action to ensure
the attack does not happen again?
Yes. The NSDB (Network Security Database) can be accessed from the management
console. The NSDB provides a technician instant access to specific information
about the attack, hotlinks, potential countermeasures, and related
vulnerabilities.� Because the NSDB is an HTML database, it can be personalized
for each user to include operation-specific information such as response and
escalation procedures for specific attacks.
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?
Cisco�s has developed a communications protocol called RDEP (Remote Data
Exchange Protocol).� This protocol uses XML based and is similar to existing
industry protocols that are in development. Cisco has and continues be involved
in the development of industry standards for IDS communications infrastructure.
Which third party event correlation systems are supported and in
what way?
Various third party products can take events directly from the sensor such as
netForensics, Tivoli, Intellitactics, Micromuse, Arcsight, etc�
Integration with other scanning/IDS products?
Cisco�s Network-based IDS products events can be aggregated with CSA (Cisco
Security Agent) events from web servers/desktops.�
CTR (Cisco Threat Response) integrates with the Cisco IDS sensors to deliver unique adaptive scanning technology to investigate target systems and determine the success of the attacks.�
Log file maintenance � automatic rotation, archiving, reporting
from archived logs, etc.
Event logs are generated and stored on both the sensors and management
consoles.� The logs that are stored on the sensor are automatically aged out
when the sensor approaches its capacity. There are tools provided in the
management console that allow the user to archive events from the database
routinely. Events that have been archived at the management console can be
imported into the event viewer for analysis. Reports can also be generated on
events that are imported. �
Management reporting � range of reports/custom reports/how easy
is it to filter and extract detail? Different reports for technicians and
management/end users?
With VMS the user can get both summary and detailed reports using a web based
reporting wizard that provides many filtering options.� Reports include:�
1.� Security Alarm Source Report
2.� Security Alarm Detailed Report
3.� IDS Top Sources Report
4.� IDS Top Source/Destination Pairs Report
5.� IDS Top Destinations Report
6.� IDS Top Alarms Report
7.� IDS Summary Report
8.� IDS Alarms By Sensor Report
9.� IDS Alarms By Hour Report
10.� IDS Alarms By Day Report�
VMS also provides reporting on Firewall events.�
CiscoWorks SIMS provides roughly 250 reports. These reports are grouped by functionality as well as by device vendors. All reports have the same user interface and it is very easy to define your own filters. There are reports that are aimed at technicians as well as management.�
Are trend/comparison reports available?
Yes with CiscoWorks SIMS�
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?
With VMS, reports can be filtered by event level, signature type,
source/destination address, time or day, specific IDS device, destination
direction, event count, etc.�
Report management � can they be scheduled for automatic
production? Can they be e-mailed to administrators or published straight to a
Web site?
With VMS, reports can be scheduled for a later time and a URL can be emailed to
a recipient for viewing.�
What are the limitations and restrictions on enterprise-wide
alerting and reporting? Can reports consolidate output from every 1) server, 2)
detector
With VMS, reports can include alarm information from all IDS
detectors (e.g. Network IDS, Host IDS, IDS on Routers and IDS implemented on
Firewalls). Event correlation and notification options can be set for alarms
from all these sources. CiscoWorks SIMS has even more options.�
Ability to define custom reports?
Yes�
Provide brief description of any management software included in the base price of the product.� �
CTR:
Cisco Threat Response is included with Cisco's IDS sensors.� The Threat Response solution works in collaboration with the Cisco IDS sensors to determine which threats are real and which are false or failed attacks. Threat Response works through a just-in-time investigation of the target system to determine if it is vulnerable to the attack, and if so, then determines if the attack succeeded or failed.� Successful attacks are quickly escalated to critical and brought to the attention of the security admin.� False alarms and failed attacks are downgraded; the events are still available for review and historical analysis.� The result is that security staff are able to focus on those events that are critical and require immediate attention.� Customers have experienced a decrease in alarm load by as much as 95% while using Cisco Threat Response.� (Note: the second level of investigation that determines if attack failed or succeeded is free during a trial period, after which the customer must purchase a license for that portion of the product. The vulnerability level of investigation is always provided free of charge.)�
Embedded Management:
IDM (IDS Device Manager), IEV (IDS Event Viewer) and CLI is included in the base price of the product.� �
1. Cisco IDM is a web-base device manager that enables the easy configuration of a Cisco IDS Sensor without requiring CLI knowledge. The IDM user interface supports wizard-based IDS command sets and a point-and-click design that allows ease of configuration in just a few steps, resulting in reduced deployment time. IDM provides secure communications by utilizing the Secure Sockets Layer (SSL) protocol to provide encryption for configuration of the sensor. The embedded design of IDM also enables management from any desktop using a Web browser.
Cisco IEV is the component of Cisco IDS Sensor software that delivers centralized event monitoring functionality for Cisco IDS sensors. The Cisco IEV is a Java-based application that enables users to view and manage/sort alarms from up to three sensors.�
2. Cisco IDS also delivers a CLI that enables user to perform sensor configuration.�
Provide brief description of any additional management products
available as extra cost options.�
For higher scalability and enhanced features we recommend CiscoWorks VPN/Security
Management Solution (VMS).� VMS is an integral part of the Cisco SAFE blueprint
and combines web-based functionality for configuring, monitoring and
troubleshooting:� �
���� Virtual Private Networks (VPN)
���� Firewalls
���� Network Intrusion Detection Systems� (IDS)
���� Host-based IDS. �
For even higher scalability we recommend CiscoWorks Security Information Management Solution (SIMS) for monitoring. This incorporates unique and powerful features for gathering and analyzing the overwhelming amount of security event data that companies are confronted with. The award winning netForensics v3.1 software is the primary component of this solution.�
Documentation provided
CiscoWorks VMS and CiscoWorks SIMS is delivered with documentation on both the
CD and for online viewing.�
How is the product licensed? How is the license enforced?
Cisco IDS Network based sensors are not licensed.�
The optional VMS management solution� and CiscoWorks SIMS operates for 90 days without a license key for evaluation.� To extend beyond 90 days requires registration on the Cisco web site to receive a license key.��
End user pricing information
The IDS 4235 that was tested:
IDS 4235 (250 Mbps) : ������������� $12,500�
Pricing information on rest of sensing product line:
IDS 4215 (80 Mbps) : ��������������� $7,295
IDS 4250 (500 Mbps) : ������������� $25,000
IDS 4250-XL (1 Gbps): ������������� $40,000�
IDS Network Module for Cisco Access Routers (45 Mbps) : $4,950�
IDS Switch Module for Catalyst 6K Switch (600 Mbps): $29,995 �
The� VMS management solution is priced at $7995 for 20 devices and $19,995 for the unrestricted license.
The CiscoWorks SIMS starter kit is priced at $40,000 for 30 devices. �
Ongoing cost of maintenance/updates
Cisco SmartNet and SAS service contracts cover the cost for maintenance/updates.
Click here to return to
the Cisco Secure IDS Review
Click here to return to the Cisco Secure IDS
results
Click here to return to the IDS Index Section
Send mail to webmaster
with questions or�
|