 |
|
|
Cisco offers a family of appliances for passive IDS and in-line IPS deployments, designed to detect and prevent attacks across multiple network segments at up to 500Mbps in-line. The Cisco IPS-4240 under test here is currently the low-end IPS offering - a dedicated 1U appliance designed to monitor and protect multiple network segments at speeds up to 250Mbps in-line. The device sports four copper 10/100/1000Mbps ports which can be configured in various combinations of in-line and passive modes. An additional copper 10/100Mbps port is used for dedicated management. Overall, the performance of the IPS-4240 was excellent, easily handling the rated 250Mbps of traffic under all network conditions. Attack recognition and blocking ability were also excellent out of the box, and improved to a perfect 100 per cent following an update, whilst resistance to all common evasion techniques tested was perfect. Latency was excellent for the rated throughput, allowing the IPS-4240 to be deployed anywhere in the network - either at the perimeter or in the core. Latency increased significantly under load, however. We found the IPS-4240 to be very stable and reliable under extended attack, with minimal blocking of legitimate traffic, and the handling of high-levels of DOS/DDOS attacks (such as SYN floods) was excellent, although such attacks are not currently mitigated for the target host. A range of management options are offered out of the box, from an extensive Command Line Interface (CLI), which will be familiar to anyone who has ever managed Cisco networking or security devices, to a comprehensive centralised management system capable of handling multiple devices deployed throughout a large enterprise. All of these are included in the base price of the product (although the high-end CiscoWorks VMS is restricted to a small number of devices), which is nice. Policy management and deployment capabilities are second to none, and alert handling is capable. In the past, Cisco IDS/IPS products have been lacking in reporting tools, but with the acquisition of Protego Networks this gap has been plugged. Between the CLI, IDM, MC and now MARS, Cisco offers a broad range of management, monitoring and reporting options that will suit most administrators. Cisco provides a range of IPS appliances and management solutions which can be deployed in either a basic two-tier or more advanced three-tier management architecture. The main components of the Cisco solution are as follows: Cisco IPS 4200 Series sensor appliances These deliver intrusion prevention via dedicated, purpose-built devices that protect multiple network segments through the use of up to eight interfaces (via optional four port modules), and support dual operation simultaneously, in both promiscuous and prevention modes. Cisco IDS/IPS appliances provide a range of performance as follows:
In addition, IDS/IPS modules are available for Cisco Catalyst 6500 Series switches. Each appliance runs a heavily modified version of Red Hat Linux, hardened and complete with a familiar Cisco Command Line Interface (CLI) and customised packet drivers and packet capture libraries written to cope with extreme traffic loads. The device under test was the Cisco IPS-4240, a 1U rack-mount appliance designed for up to 250Mbps in-line. The 4240 sports four copper 10/100/1000Mbps ports which can be configured in various combinations of in-line and passive modes - two in-line pairs, one in-line pair and two passive mode IDS, or four passive mode IDS. An additional copper 10/100Mbps port is used for dedicated management. A software bypass capability is built in to the sensor allowing it to fail open or closed, as required by the administrator, should the sensor application fail or resources become exhausted. Optional modules provide hardware bypass capabilities, allowing the entire device to fail open under power loss or hardware failure. There is a single power supply, and neither power supply nor fans are hot-swappable. No other High Availability (HA) features are available. Meta Event Generator (MEG) Cisco IPS 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 contain worm and virus injection vectors, as well as worm propagation. This is accomplished through the following techniques:
Nimda is a prime example of a worm that exploited multiple vulnerabilities during its propagation across networks. Typically, the various alarms that pertain to each of these exploits will trigger within a short time interval. Using MEG, the user can specify logic that will consolidate all events pertaining to a certain worm into a single meta event, called "Nimda", for example (see below).
In doing so, the user can also specify a time interval during which these disparate events must be detected in order for the correlation algorithm to trigger the actual meta event. Through the use of similar logical parameters, MEG can also be customised to deliver protection from environment-specific threats that may not be related to a universally known worm activity. Although the user-defined nature of this feature makes it very flexible and powerful, Cisco recognises that the knowledge to create such meta events is lacking in may organisations. Thus, signature updates delivered by Cisco that pertain to multifaceted worms such as Nimda will also deliver the associated meta event. Along with this meta event, the user will be given information that indicates the individual signatures that form the meta event. Historical trend analyses performed to characterise the lifecycle of worms often reveal a certain sequence of actions that are detected just prior to penetration. These actions occur in the “probing phase”, when a chain of reconnaissance activities is performed against the target network. MEG allows the user to define the precursors to worm penetration by specifying a logical algorithm that triggers when a particular sequence of events occur. For example, if a certain number of hosts are pinged, followed by port scans on a defined set of ports, followed by a buffer overflow targeting hosts on a particular range of IP addresses, then trigger a single meta event “X”. In this case, the resulting meta event will attain a higher fidelity rating by virtue of the correlation that was performed. Additionally, this meta event can be assigned an automated response action that will stop the worm that has been detected. As worms propagate through the network, they typically generate multiple IPS events of varying degrees of severity. When there is no relationship established between such disparate events they could be assigned low severity ratings since, by themselves, they do not pose a significant threat. However, when these events are considered in the context of a sequence of related events, they could collectively indicate worm or virus activity. Cisco's Meta-Event Generator links these seemingly unrelated lower severity alarms into a high severity, high risk event, enabling the administrator more confidently to drop the associated packets (see below).
Lastly, MEG can be used to correlate events that are generated through the use of the hybrid detection techniques available in Cisco IPS sensor software. For example, if a denial of service (DoS) activity is detected through the triggering of a traffic anomaly algorithm and a classical “flood” type of signature, MEG can be used to corroborate one event with the other, thereby delivering a single meta event that indicates a higher likelihood that the DoS activity has actually occurred. As always, the most appropriate response actions could then be configured to mitigate the DoS condition. The effectiveness of the IPS is enhanced when such correlation algorithms are embedded into the sensor, as opposed to performing them purely at the monitoring console. When event correlation is performed at the sensor level, the sensor can take automated response actions that are based on the correlated incident rather than the individual - possibly low-level - events. A full-featured Cisco IOS Software-like CLI that provides device configuration over a Secure Shell (SSH) connection or via direct keyboard/video connection to the sensor. The IPS Device Manager is a web-based Java application that resides on the sensor and is accessed via a secure, encrypted TLS link. Standard Netscape and Internet Explorer Web browsers are used to connect directly to the sensor to perform various management and monitoring tasks. IDM is designed to manage a single device at a time in a two-tier management configuration, and it includes basic alert monitoring capabilities. A multi-device configuration and alarm management tool offering a unified, view of all security events across the enterprise. With the CiscoWorks VMS solution, events from all types of security devices, including firewalls, VPNs, and IPS, can be viewed from a single console in a browser-based GUI. Multiple security devices can be configured and managed, making it easier to manage security across the enterprise.
CiscoWorks VMS is designed as a three-tier management system and requires a dedicated management server. It provides advanced policy management and deployment capabilities, role-based access, Security Monitor for alert handling, basic correlation capabilities via user-defined alert rules, basic reporting, and automated updates. The aim of this section is to verify that the sensor is capable of detecting and blocking exploits when subjected to increasing loads of background traffic up to the maximum bandwidth supported as claimed by the vendor. For each type of background traffic, we also determine the maximum load the IPS can sustain before it begins to drop packets/miss alerts. It is worth noting that devices which demonstrate 100 per cent blocking but less than 100 per cent detection in these tests will be prone to blocking legitimate traffic under similar loads. The Cisco IPS-4240 was tested up to 250Mbps, the rated throughput of the device. Performance at all levels of our load tests was excellent, with 100 per cent of all attacks being detected and blocked under all load conditions. We would happily confirm Cisco’s 250Mbps rating for this device under all network conditions. Basic latency figures were excellent for a device of this type at most traffic loads and packet sizes, ranging from 119�s with 62.5Mbps of 256 byte packets, to 201�s with 250Mbps of 1000 byte packets. Behaviour throughout all of the tests with no background traffic was very predictable, with relatively small increases in latency as traffic levels increased from 62.5Mbps to 250Mbps across each packet size. Placing the device under a half load of 125Mbps of HTTP traffic we noted significant increases of 170 per cent with 256 byte packets (119�s to 322�s), 116 per cent with 550 byte packets (137�s to 296�s), and 77 per cent with 1000 byte packets (184�s to 327�s). However, we would still consider these results to be very good for a 250Mbps device. HTTP response times were excellent, and we believe the IPS-4240 could be situated anywhere on a network with no more than 250Mbps of traffic, either internally or at the perimeter. SYN Flood protection is implemented for the sensor, and 25Mbps of SYN flood traffic had no significant effect on the IPS-4240. Latency increased by only a few microseconds across all packet sizes and HTTP response times were barely affected. Note, however, that the SYN Flood was not mitigated at all for the target server (this feature is planned for a future release) although appropriate alerts were raised. The IPS-4240 performed consistently and reliably throughout our tests. Under eight hours of extended attack (comprising millions of exploits mixed with genuine traffic) it continued to block 100 per cent of attack traffic, whilst passing 99.5 per cent of legitimate traffic. Exposing the sensor interface to ISIC-generated traffic had no adverse effect, and the device continued to detect and block all other exploits throughout and following the ISIC attack. Please refer to the Testing Methodology section for full details of the methodology used and performance results. We installed one sensor with the latest signature pack, and configured it with all attack signatures enabled, plus some key audit/information-only signatures. All “retired” signatures were un-retired and enabled. Out of the box, blocking performance was excellent at 89 per cent, and was improved to a perfect 100 per cent following the application of a signature update after 48 hours. Detection/recognition rate was slightly lower (95 per cent following update) due to the fact that some protocol anomalies (i.e. overlapping fragments, invalid TCP options, etc.) are always blocked without alerting by the normaliser engine. It is possible to configure normaliser signatures to produce alerts if required. We noted a minimum of “noise”, with few test cases raising multiple alerts for a single exploit, and the accuracy of the exploit descriptions was high. Performance in our “false negative” tests was very good out of the box, and there is every indication that, wherever possible, signatures are written for the underlying vulnerability rather than specific exploits. A major concern in deploying an IPS is the blocking of legitimate traffic, and the IPS-4240 did block two of our false positive test cases out of the box. This was rectified following the signature update, but we continued to note numerous port-based backdoor alerts during our FTP tests. The Cisco IPS arrives with a sensible default policy with PASS and BLOCK actions set for appropriate signatures (i.e. where the confidence level of a signature is high then the action will generally be set to BLOCK). It should be possible to deploy this product successfully using the default settings in most organisations. Resistance to known evasion techniques was excellent, with the IPS-4240 achieving a clean sweep across the board in all our evasion tests. Fragroute, Whisker, ADMmutate and even RPC record fragging all failed to trick the IPS-4240 into ignoring valid attacks. Not only were the fragmented and obfuscated attacks blocked successfully, but all but two of them were decoded accurately as well when not blocking. Once blocking was enabled, certain of the more complex fragmentation and segmentation evasion techniques raised alerts from the normaliser only. Out of the box, the IPS-4240 handled 250,000 open connections (the claimed maximum) and no tuning parameters are available to the administrator to adjust this. Default operation of the device is to age out old connections when the state tables are full or resources are low, and this behaviour is not configurable. Stateless “exploits” are not alerted upon (this is correct behaviour in order to be resistant to Stick and Snot tools) and mid-flows are blocked by default. It is possible to configure the device to allow mid-flows if required. Please refer to the Testing Methodology section for full details of the methodology used and performance results. This part of the test procedure consists of a subjective evaluation of the features and capabilities of the product, and covers installation, configuration, policy editing, alert handling, and reporting and analysis. Installation tasks are minimal thanks to the turnkey appliance approach. All that is required is to log in at the sensor console and work through a text-based installation routine in order to set up the initial communication parameters of the sensor to allow it to communicate with the management console. Cisco has done a good job of implementing a complete Cisco CLI on the sensor platform so that the sensor has a familiar look and feel to anyone with Cisco experience. Whichever management console is being used - Cisco IPS Device Manager (IDM) or CiscoWorks VMS - then all that is required is to define the communication parameters for each sensor to begin managing and monitoring via the GUI. All documentation is supplied on CD-ROM and is also available on-line. The quality of the documentation is very good. For remote management functions, Cisco bundles the IPS Device Manager (IDM) with the sensor for basic management and monitoring. In addition, Cisco diehards will be pleased to learn that there is a full-featured Cisco CLI environment available when logging into the sensor locally - everything that can be configured via the GUI utilities can also be configured via the command line. However, for enterprise deployments with more than a couple of sensors, the recommended management solution is CiscoWorks VMS. This is a Java-based “umbrella” management system for a range of Cisco devices such as firewalls, VPN and, of course, IDS/IPS sensors. For those organisations which find the included IDM to be too limited, then CiscoWorks provides enterprise-level IPS management, monitoring and alerting capabilities, and it will be the focus of this evaluation.
Login to the CiscoWorks console is controlled by a user name and password combination. User accounts are created within CiscoWorks (or can be managed by ACS) and each account can have different levels of access to the system, providing granularity of administrative function. When using ACS, it is also possible to control authorisation on a per-device or per-group basis. Once logged on, a hierarchical menu down the left of the screen provides access to CiscoWorks’ administrative functions (security settings, logging options, server configuration, user account maintenance, and so on), and the Management and Monitoring Centre. A number of diverse modules can be added to this section to enable the administrator to manage a wide range of devices - such as firewalls, IPS, IDS, routers, etc. - from a single point. The system provided for evaluation contained a Management Centre for IDS Sensors plug-in for the Management Centre, and a Security Monitor plug-in for the Monitoring Centre. These provide similar functionality to IDM, but offer more flexibility in some of the configuration functions, together with the ability to manage multiple sensors across the corporate network. They also handle configuration and monitoring tasks for both IDS and IPS devices. The layout of the Management Centre (MC) is very straightforward, consisting of a number of tabs along the top of the screen providing access to Devices, Configuration, Deployment, Reports and Admin functions. Selecting any of these will bring up additional tabs below for access to different functions, and a very useful “you are here” indicator provides constant notification of which options have been selected to get to the screen currently displayed. Sensors can be logically grouped together - perhaps according to location or function - and a sliding Object Selector tab to the left of the screen allows the administrator to select either an individual sensor or an entire group, to which all subsequent administrative operations will be applied. This can slide out of the way to reclaim screen real-estate, and the current scope is always shown on subsequent configuration screens. Many parameters can be set globally, or at group level, and can be made mandatory at either of those levels, thus preventing them from being overridden on the individual sensors. Where the configuration is not enforced in this way, the administrator can specify settings at the global level which can then be overridden as required at lower levels in the device hierarchy. Clearly, not all admin functions are available at global or group level, since some are tied closely to the operation of the individual sensor. At the top right of the MC GUI is a small Actions & Notifications toolbar, containing buttons to generate and deploy new configurations, save pending changes, undo pending changes, view current background operations (useful for monitoring deployment tasks), and configure automatic signature updates. The key to policy management in VMS is the ability to create groups and subgroups below the global root node in the Management Centre (MC)device tree. Groups can be created to mirror any policy structure which could, for example, be based on location (i.e. country or department) or function (i.e. Web server, FTP server, private or public-facing). All, or some, settings can be inherited from the nodes above the one being edited, and settings applied to any node in the tree are automatically applied to all sensors within that node during the deployment operation. Changing the policy applied to any sensor is simply a matter of dragging and dropping it between nodes in the device hierarchy. This is a very flexible and intuitive method of policy management, and it works well in this implementation. A “policy” is made up of a number of configuration parameters (accessed via the tree menu to the left of the screen once the scope has been selected) and, of course, a number of signatures.
By default, all built-in signatures are displayed in a single huge list when the GUI is first accessed. A drop-down menu provides access to several ways of grouping the signatures:
Selecting any one of these from the first drop-down menu populates a second drop-down menu allowing further granular selection of related groups of signatures. For example, if Engine is selected in the first menu, the administrator can select on which engine (roughly equivalent to a protocol decoder in most cases) to focus on in the second menu (Normaliser, HTTP, RPC, SQL, SMB, and so on). If OS is selected in the first menu, the administrator gets to select from a list of available operating systems for which signatures are available in the second menu. Signatures can be edited, allowing the administrator to change the active flag, retired flag (retired signatures are removed completely from the sensor reducing the memory footprint), severity level, fidelity rating, actions, mandatory flag and override flag. The following actions are available:
Rather than opt for a fixed “block or allow” methodology, Cisco IPS uses dynamic Risk Ratings that are assigned to alerts generated from IPS sensors. The intent of this Risk Rating is to provide the user with an indication of the relative risk of the traffic or offending host continuing to access the user's network.
This rating can be used either to illuminate the events that require immediate administrator attention in the classic IDS promiscuous mode. It can also provide a means for developing risk-oriented event action policies when the sensor is deployed in the in-line IPS mode. The Risk Rating is presented 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:
One of the most powerful features of the Cisco IPS system is the Event Action Override which allows the administrator to override default actions based on the calculated Risk Rating. The TVR in particular can have a significant effect on the overall Risk Rating based on the perceived (administrator-defined) value of the servers being protected. The effect could be a raising or lowering of the default Risk Rating as calculate by Cisco IPS. Rather than be forced to make mass alterations to the default signature action settings, however, the administrator can apply global overrides on a per-action basis, based on the source of the event (individual sensors, sensor groups or sub-groups) and the Risk Rating (which can be expressed as a single value or a range). Thus, for example, the administrator could decide that all events with a calculated risk rating of greater than 90 should be blocked, no matter what default action has been configured. Conversely, he could decide that all those events with Risk Rating below 10 are not even worthy of an alert.
This is an extremely powerful and flexible system - the nice thing about Cisco’s implementation is that it does not rely purely on its Signature Fidelity Ratings and calculated Risk Ratings, but also allows the administrator to have input by specifying TVRs for critical servers. Groups of signatures can be edited be clicking on the check boxes alongside each one, or by checking the “select all” box. Search criteria can also be used to search for specific groups of signatures within the current focus making it possible to search for all signatures whose description contains the phrase “Back Orifice”, or all signatures that have a severity setting of “High”. These too can be edited individually or en masse if required. All in all, the signature search, selection and editing capabilities are very powerful and very easy to use. Signatures can also be tuned, which goes further than the basic edit capability, providing the means to access and modify all of the detailed signature parameters if required. Most of the signatures written by Cisco are open for inspection and modification, and they can be cloned to provide the starting point for custom signatures. In addition, custom signatures can be created from scratch using the Signature Wizard, which will walk the administrator through this sometimes complicated process. All of the capabilities of all the protocol decoders are available for custom signatures, in addition to basic pattern matching and regular expression functions. Whenever changes are made to a sensor configuration, the details are stored on the Pending tab awaiting deployment. The old two-stage process of generating configuration files and then deploying them is still available for those who want complete control, but the process has now been simplified, requiring only a click of the Generate & Deploy button on the main screen. Changes are deployed to all applicable sensors automatically (i.e. all those sensors in the group or sub-group to which the changes have been applied). Pending changes can be discarded using the Discard button or by deleting them from the Pending tab - this is a feature which we consider essential, but which is often missing from competing products. A full change history is recorded, with every configuration file that has ever been applied saved as an audit trail. It is also possible to roll back a change to a previous configuration if required. Change management and policy deployment features in VMS are second to none. Alert Handling within CiscoWorks VMS is handled by the Security Monitor plug-in, which is capable enough as a basic day-to-day alerting tool and which can handle events from multiple devices.
Once the devices to be monitored have been defined to the Security Monitor in the Device tab, the Monitor tab can be used to monitor both the status of each device, and the events that are raised. When launching the Event Viewer, the administrator is presented with an initial screen of options allowing him to select the Event Type to view (Event Viewer can handle alerts from more than just IPS devices), the Column Set (the column layout: By Victim, By Attacker, By Signature, All, Default or Last Saved), event start and stop times, and the Filter to apply. Filters can be created based on a wide range of criteria contained within the event (such as source IP, destination IP, severity, and so on) and these can be redefined and applied on the fly during a monitoring session. In common with the Column Set, the current criteria can be saved to re-use as the “Last Saved” set next time the viewer is launched. It would be nice if it were possible to save multiple named Column Sets and Filters, but for now only the last one of each saved is available for re-use.
The default Column Set is comprehensive, including the date and time, signature name, ID, severity, source IP/port, destination IP/port, sensor ID, and a separate pane on the right of the screen providing complete event details for any selected alert (including context data where applicable). Additional columns can be added (or existing columns deleted) as required. Multiple Event Monitors can be launched simultaneously, each providing a different view of current events, and it is possible to drag and drop columns of data to re-order and resort the entries. For example, dragging Source IP to the left of the screen sorts and groups (and counts) by source IP. Dragging Severity to the left of the screen creates a new view sorted and grouped by the severity code. The entire contents of the database can be expanded or collapsed using menu options to the left of the screen, providing a quick way to switch between detail and summary views. It is possible to view the full context buffer for an alert, and the viewer is capable of showing context data for an entire group of alerts in the same window. On selecting any of the alerts, menu options provide the capability to view the trigger packet in an Ethereal-like display, block the host that perpetrated the exploit, or block the entire network from which it came. It is not possible, however, to annotate events, or mark them as resolved or for further investigation. Although it may appear simple at first glance, and although it is sometimes not the most intuitive interface when it comes to resorting, expanding and collapsing the entries, the Event Viewer is actually a very flexible and powerful tool. One final option worth mentioning is the Event Rule capability. Event Rules allow the administrator to specify related criteria, thresholds and actions in order to provide some very basic correlation. For example, a rule could be created to watch for a particular type of port scan from three sensors. If the scan is detected on all three sensors within a given time frame then an alert is generated, an e-mail is sent to the administrator and a script is run to reconfigure the firewall. Whilst the Security Monitor is a perfectly capable tool for monitoring and investigating events in real-time, the customisation, filtering, correlation and forensic analysis capabilities are basic. With the acquisition of Protego Networks, Cisco can now offer another tool which can take alert handling to a higher level - Cisco Security Monitoring, Analysis & Response System (Cisco Security MARS).
Intended mainly as an in-depth reporting, analysis and correlation system, its main features will be described in the following section. However, it is worth mentioning at this point that the myriad custom reports that can be defined within MARS can be configured to run in real-time, thus providing alert monitoring capabilities. In addition, there are a number of excellent graphical summary displays that provide good drill-down capabilities. Although MARS can provide additional detail, and more flexible ways of drilling down to that detail, than Security Monitor, Security Monitor has a more lightweight feel to it. Some administrators might prefer Security Monitor for the basic, rapid-fire, day-to-day stuff, and MARS for the more in-depth analysis after the fact. However, it should also be pointed out that MARS’ ability to infer connections between multiple events and raise a single incident as a result can actually result in less information for the administrator to process, thus making him more efficient in tracking down and eliminating the most serious problems.
Incidents are displayed in real-time in the Incidents display, with each entry in the display containing the incident name, the rule matched, the action taken, and the date and time. Hyperlinks are provided on almost every data item, allowing the administrator quickly to:
We found the correlation capabilities to be very impressive, and the mix of real-time graphical displays with rapid-fire hyperlinked queries to be very usable and powerful. Security Monitor provides a number of basic summary reports:
None of these is customisable in any way. On choosing a report, the administrator is presented with an extensive set of filtering options including severity, date, source, destination, signature and category. The report can then be scheduled to run immediately or at a later time. If scheduled for a later time it can also be made to repeat at regular intervals, and the finished report can be e-mailed to one or more recipients. The completed report is viewed on-screen in a browser window and can be printed out using the standard browser print function. No other print or export options are offered.
The summary reporting is adequate, but is very high level and not suitable for forensic analysis. More detailed forensic reporting and correlation across multiple devices (both Cisco and third party, and not restricted to IDS/IPS) is offered via the aforementioned MARS system. This is provided as a turnkey appliance, and a range of appliances is available depending on size of operation and amount of data to be analysed. MARS is first and foremost a data correlation system. At the heart of the product is a huge database of rules which describe events and conditions that must occur in order for incidents to be created. Devices are configured within MARS, following which MARS will poll those devices at regular intervals for raw event data, storing that data in its own local database. This data - which can be from IPS/IDS sensors, firewalls, routers, switches and other devices (both Cisco and third party) - is then matched against the rules database which is capable of inferring connections between events occurring on different devices and in different time-frames. MARS offers over 80 pre-defined reports, all of which can be modified via the flexible and intuitive report generator. Not all of these are IDS/IPS related, of course - many of them will relate to other devices and some are designed to satisfy operational requirements and assist in regulatory compliance efforts including Sarbox, GLBA, HIPPA, FISMA, and Basel II. The report generator can modify any of the standard reports or can be used to generate new reports for action and remediation plans, incident and network activity, security posture and audit, and departmental reports - all in data, trend and chart formats. Selection criteria are extensive, including source and destination IP, service, device, event type, users, keywords, rules and actions. Any number of criteria can be combined with Boolean operators to create extremely complex reports, and reports can be based on either high-level correlated incidents or the low-level individual raw events. The system also provides for batch and e-mail reporting. In addition to the query/reporting capability, MARS also provides a high-level summary screen showing the most recent events in a list at the top of the screen (with the same rapid hyperlink access to drill-down data mentioned in the Alert Handling section), followed by a graphical attack view (shows the known network topology overlaid with attacks), and graphs of top destinations, top events and sessions, and top events and netflows. In past evaluations of Cisco software we have bemoaned the lack of reporting capabilities. It is nice to see that gap plugged so effectively in this latest release - MARS is an extremely powerful and useful product. Performance The Cisco IPS-4255 was tested up to 500Mbps, the rated throughput of the device. Performance at almost all levels of our load tests was good, with 100 per cent of attacks being detected and blocked under all but the most extreme (10,000 connections per second) load conditions. Even when pushed beyond its limits (8,000cps), the IPS-4255 continued to block all malicious traffic successfully. We would happily confirm Cisco’s 500Mbps rating for this device under normal network conditions. Basic latency figures were very good with no traffic, and still within acceptable limits for a device of this type with a half load of 250Mbps of HTTP traffic. HTTP response times were also good, and in most deployments the IPS-4255 could be situated anywhere on a network with no more than 500Mbps of traffic, either internally or at the perimeter. SYN Flood protection is implemented for the sensor, and 50Mbps of SYN flood traffic had no significant effect on the IPS-4255. Latency increased by only a few microseconds across all packet sizes and HTTP response times were barely affected. Unfortunately, the SYN Flood was not mitigated at all for the target server (this feature is planned for a future release) although appropriate alerts were raised. The IPS-4255 performed consistently and completely reliably throughout our tests, blocking 100 per cent of attack traffic whilst passing 100 per cent of legitimate traffic. Exposing the sensor interface to ISIC-generated traffic had no adverse effect. Security Effectiveness Out of the box, blocking performance was excellent at 89 per cent, and was improved to a perfect 100 per cent following the application of a signature update after 48 hours. Detection/recognition rate was slightly lower (95 per cent following update) due to the fact that some protocol anomalies are always blocked without alerting by the normaliser engine, but this is not important for an in-line IPS device. We noted a minimum of “noise”, with few test cases raising multiple alerts for a single exploit, and the accuracy of the exploit descriptions was high. Performance in our “false negative” tests was very good out of the box, and there is every indication that, wherever possible, signatures are written for the underlying vulnerability rather than specific exploits. A major concern in deploying an IPS is the blocking of legitimate traffic, and the IPS-4255 did block two of our false positive test cases out of the box. This was rectified following the signature update, but we continued to note numerous port-based backdoor alerts during our FTP tests, which we considered poor (these can easily be disabled, of course). The Meta Event Generator (MEG) appeared to work well in correlating low-level attacks to infer a connection and raise higher-level alerts for worm activity, etc. This is a very useful feature, though it will be interesting to see how MARS handles custom meta events when it attempts to apply its own correlation rules. It was also good to see entire categories of signatures for new threats such as Spyware/Adware, Voice Over IP (VOIP), covert channel activity, and even viruses (via a new partnership with Trend Microsystems). Resistance to known evasion techniques was excellent, with the IPS-4255 achieving a clean sweep across the board in all our evasion tests. Fragroute, Whisker, ADMmutate and even RPC record fragging all failed to trick the IPS-4255 into ignoring valid attacks. Not only were the fragmented and obfuscated attacks blocked successfully, but all but two of them were decoded accurately when not blocking. Out of the box, the IPS-4255 handled 500,000 open connections (the claimed maximum) and no tuning parameters are available to the administrator to adjust this. Default operation of the device is to age out old connections when the state tables are full or resources are low, and this behaviour is not configurable. It would be nice to see a choice offered to the administrator of whether to age out old connections or block new ones. Usability The Cisco product offers a range of management options from an extensive Command Line Interface (CLI), which will be familiar to anyone who has ever managed Cisco networking or security devices, to a comprehensive centralised management system capable of handling multiple devices deployed throughout a large enterprise. All of these are included in the base price of the product (although the high-end CiscoWorks VMS is restricted to a small number of devices), which is nice. IDM is the direct device management software produced by the sensor team which is designed to allow the administrator to manage a single device at a time (or a small number of devices). This provides a basic, two-tier management infrastructure which does not require a separate management server. IDM provides everything needed to deploy and manage small numbers of sensors, including a very basic alert monitoring capability. Its biggest advantage is that it provides a very simple, straightforward means to manage a single device, and is often more up to date than VMS, which is produced by a separate development team and sometimes lags behind sensor development. CiscoWorks VMS is where it steps up a gear into true centralised management and monitoring for multiple sensors, though this requires a separate management server host to implement the three-tier architecture. Signature editing, tuning and creation are well catered for, and the interface makes it simple to search for and make changes to large groups of signatures in one hit. Management of policies/groups and deployment across multiple sensors is made as straightforward as possible - the “scope” selection tool makes it possible to select single sensors, groups of sensors, or all sensors in order to make bulk changes. VMS also includes a basic event monitoring tool (Security Monitor) which is perfect for day-to-day monitoring tasks. Data can be grouped and sorted in a variety of ways by simply dragging and dropping columns, though this is the limit of its analysis capabilities. In order to go further, Cisco now offers its latest acquisition from Protego Networks - Cisco Security Monitoring, Analysis & Response System (Cisco Security MARS) - as an extra cost option. Provided as a range of turnkey appliances, this is an extremely comprehensive correlation, monitoring and reporting tool that pulls together alerts from a wide range of Cisco and third party security and networking devices, stores them in a central database, and correlates them into incidents. On top of this is a very powerful custom report generator which enables the administrator to create real-time and historical reports on the data, presented in almost any way imaginable. In the past, Cisco IDS/IPS products have been lacking in reporting tools - with the acquisition of Protego Networks, however this gap has been plugged. Between the CLI, IDM, MC and now MARS, Cisco offers a broad range of management, monitoring and reporting options that will suit most administrators. The CLI provides a very rapid means of single-device configuration without having to handle relatively sluggish Java GUIs. The IDM also provides a relatively rapid means of configuring single devices without having to deploy a complex three-tier management infrastructure. For those who have many sensors to manage, CiscoWorks VMS provides a comprehensive three-tier management system, and the built-in Security Monitor is perfect for basic, day-to-day monitoring tasks. Finally, MARS offers comprehensive monitoring and reporting capabilities across not just every IPS device in the organisation, but every other networking and security device too. There is, however, one fly in the ointment. Although VMS has seen considerable improvements since we first looked at Cisco products in our labs, and now appears to be a very flexible and powerful product, it continues to suffer from the fact that its development lags behind that of the sensor and its associated IDM. This means that users who are committed to VMS are often left with no choice but to use IDM immediately following a new sensor release whilst they wait for the VMS developers to incorporate new sensor features. In addition, in this particular test, although the sensor release was on its third iteration - and both it and IDM seemed very stable - the VMS release was brand new and showed signs of a hurried QA process. There were several cosmetic and functional bugs which manifested themselves during testing, but which should be fixed by the time this report is released. Luckily, none of these was enough to prevent the product from performing its allotted task as an IPS device, since it is perfectly possible to deploy and manage it via the IDM. Company
name: Cisco
Systems, Inc.. Click
here
to return to the Cisco questionnaire |
Send mail to webmaster
with questions or
|