 |
|
|
ISS Proventia A201 Intrusion Protection Appliance Internet Security Systems was the first to produce a commercial Network Intrusion Detection System and RealSecure still tends to be the standard by which other software-based NIDS products are measured. The company has now branched out into the appliance market, Built upon the RealSecure code base and modified for specific appliance hardware configurations, The Pro0ventia appliances are pre-installed network agents on varying hardware platforms. The Proventia A201 is the first example of the new product line, designed to support up to 200Mbps bandwidth. Additional offerings include the A604 (600Mbps), A1204 (1200Mbps copper Gigabit), and the A1204F (1200Mbps fibre Gigabit), each of which support port aggregation for load balanced networks, and native full-duplex operation The Internet Security Systems appliance-based IDS offering consists of the following components: Intrusion Protection Appliance The Proventia A201 appliance is a 1U rack mount server chassis with a 1.8 GHz Xeon processor, 20GB hard drive, 1 GB of RAM, one 10/100/1000 copper interface for monitoring and one 10/100/1000 copper interface for management. The Proventia A201 uses a Linux version of RealSecure together with a custom driver specially built for Proventia hardware rather than the standard OS driver used by RealSecure on Linux. The system is hardened and completely locked down so that the only way it can be accessed is from SiteProtector or SSH (or directly at the appliance via keyboard and monitor). Workgroup Manager is not supported with Proventia. The system is designed to provide all initial configuration functions - such as IP address assignment, management console assignment, and password change - via a simple text-based local interface to which the administrator is restricted following login. All day-to-day administrative tasks, such as policy changes, can be accomplished via the SiteProtector manager installed nearby or at a remote location. The Proventia Linux-based sensor software (which ISS refers to as an Agent) runs on the Proventia hardware in order to monitor a network segment, analyse the traffic flow and look for intrusions and signs of network abuse. When an intrusion is detected, Proventia can respond in a number of ways, including:
Proventia understands nearly 100 network and application layer protocols such as HTTP, FTP, SMTP, SNMP, RPC, SMB, NetBIOS as well as many Trojan communication protocols. Proventia�s protocol analysis capabilities do not rely on merely checking for textbook (RFC) compliance since anomalies are difficult (and sometimes impossible) to define due to RFC ambiguities and differences in interpretation of the standards. Instead, Proventia focuses on analysing protocols to recognise context and then employs pattern matching techniques where appropriate to positively identify malicious content. In addition, Proventia can also perform full IP packet de-fragmentation, as well as TCP and HTTP session reassembly (tracking five hundred thousand simultaneous sessions out of the box - more if tuned appropriately), and is largely immune to evasion techniques such as polymorphic shell code mutation, Unicode URL encoding, packet overlapping and RPC record fragging. Event consolidation logic helps to reduce the total number of unique events that the sensor generates by logically combining large numbers of identical events into a single alert. Proventia listens to both the transmitting and receiving data streams which allows it to capture server responses for many attacks, such as HTTP, FTP, RPC and DNS events. The ability to report return codes and other server-side responses to the alert console helps guide security operators to quickly recognise the outcome of an attack, and is thus an important tool for prioritising incident response. Proventia has very strong signature coverage, the result of combining both the BlackICE and RealSecure signature libraries. In addition to the Proventia protocol analysis module, now referred to as the Protection Engine, Proventia, like RealSecure, has the ability to import most of the published rules from Snort, via the aptly named Trons module. The aim of this is not to replace Snort, nor is it to enable sites to include the entire Snort signature set (which would seriously impact the performance of Proventia), but to allow users to write their own custom signatures using a relatively simple rules definition language that is familiar to many in the security industry. TCP reassembly is not supported via Trons, and neither are the standard Snort plug-ins and pre-processors (such as the Back Orifice and port scan processors). The latter, at least, should not be a problem, given the capabilities of the main Proventia engine. Trons should support most all of the rules that are currently shipped with Snort, and there is a command-line program called �tronstester� that can be used to test-compile the signatures and provide warnings of syntax problems. It should be noted that architecturally, Trons is an almost completely independent subsystem from the main Protection Engine, making the whole system more like two IDS� in one (hence the potential performance impact). In BlackICE, they were completely independent, whereas Proventia does use the PAM module for reassembly of IP datagrams, URIcontent pre-processing, and some RPC pre-processing. In future versions of Proventia, PAM and Trons will be fully integrated providing full TCP reassembly capabilities for both sets of signatures as well as the elimination of the current overhead of having to parse the IP headers twice. Leaving Trons out of the equation, Internet Security Systems claims very high performance levels for Proventia, and this was borne out in our lab tests � hardly surprising since the BlackICE and BlackICE/RealSecure integrated sensor performance has always been impressive. Now, the same performance levels hold true for the new Proventia appliance. To help with performance, Internet Security Systems has written custom high-performance interface drivers for the Proventia A201 network card. The optimised packet capture driver has been designed to interface the protocol analysis engine directly with the network card, thus completely bypassing the host operating system and its inefficiencies. SiteProtector provides a central console geared towards large scale enterprise management and event correlation across multiple network, server, desktop, and assessment agents. Features include:
The Deployment Manager can be used to install all of the SiteProtector components from a centralised computer anywhere on the network. Once the Deployment Manager has been installed on one PC, the CD is no longer required to install either SiteProtector itself, or any of the other components of a Proventia system. Instead, a simple Web-based installation capability is provided which can be accessed from any host on the network. The Deployment Manager can be used to install the Basic or Custom SiteProtector installation, in addition to the following components:
The Application Server enables communication between the SiteProtector Console and the Proventia Site database. The Sensor Controller sends commands to the sensors, such as the command to start or stop collecting events. The Sensor Controller and the Application Server are installed on the same host. The Proventia Site database stores the data that the Event Collector collects from sensors. This is based on Microsoft SQL Server for large deployments, or MSDE for smaller installations. The Event Collector pulls data from sensors and stores the data in the database. Typically only one Event Collector is installed on a SiteProtector Site, but up to five Event Collectors can be installed per Site when required for performance reasons. The Security Fusion module is an optional (extra-cost) module that correlates data from multiple sources, sources, including Proventia, RealSecure Network and Server agents, and Internet Scanner or System Scanner instances. This automated correlation escalates critical attacks and reduces false alarms. The Console is the graphical user interface (GUI) for the SiteProtector installation. With the Console, the administrator can perform a variety of activities, such as monitoring events and scheduling scans. The specific tasks that can be performed using the SiteProtector Console depends on role assigned to the administrator. The new Console is Java-based rather than the C++ code of the old Workgroup Manager, and one of the big advantages of that is the ability to spawn multiple windows within the same Console, each performing a different task. So while that large report is loading, it is still possible to be defining and deploying a new policy.
As you would expect from an appliance that is designed to be as close to �plug and play� as possible, installation is very straightforward. Initial configuration is performed at the appliance, the simple configuration menu being presented automatically when logging in to the admin account. The admin interface on the Proventia A201 is designed to disallow any OS modifications, and the Root account should never be used - ISS will not support any configurations that are not accomplished from the admin account. The simple, text-based menu enables the administrator to configure network settings, date and time, admin password, manually restart the Agent software, set up Key Administrators, reboot and shutdown the appliance. A recovery CD provides the means to completely re-install the appliance software should that prove necessary (following disk corruption, for example). Once configured, the Proventia appliance can only be accessed via a serial cable using a communications application such as Hyperterminal, keyboard and monitor, SSH, or SiteProtector. Documentation has improved considerably since the previous release. It is provided as PDF files or hard copy, and includes an Installation Guide and User Guide for each of the components. The level of detail is much better in the current release, and we found coverage of all the main features to be reasonably comprehensive and very clear. The SiteProtector Strategy Guide is an extremely useful additional manual which provides best practice guidelines and suggestions for securing a network, offering a guide to deployment and use in a range of organisation sizes and complexities. SiteProtector provides scalable, centralised security management and data analysis capabilities for all Proventia appliances, RealSecure Network, Server, and Desktop agents, and ISS' scanning applications. SiteProtector simplifies Proventia deployments through unified command, control and monitoring, the aim being to reduce security management demands on network traffic, staff or other operational resources.
The first goal of SiteProtector is to provide the administrator with a more logical view of the security boundaries under his control. Thus, rather than view individual sensors by machine name or IP address, they can be grouped together logically into departments or physical sites. This makes it much more meaningful when viewing alerts or applying security policies. Security assets can belong to more than one group for maintenance and reporting purposes, but can be �subscribed� to a single group for policy application (it is also possible to override this and apply policies on a per-sensor basis). This has been very well thought out, and provides one of the most flexible policy deployment capabilities we have seen. Administrators can manage a wide range of sensors � both network and server-based � across the corporate network from a single Console if required. It is also possible, of course, to provide multiple Consoles to different administrators, and each one can be assigned different roles. For example, an administrator may control, configure and maintain the SiteProtector system and its components at the same time that localised security analysts perform command and control over the sensor infrastructure.
However, these analysts remain restricted from configuring the SiteProtector system itself. Operators with viewing privileges cannot perform command and control functions, but may view the aggregated security information contained within a SiteProtector environment. As with previous versions of the software, users are designated by assigning Windows users to specially created groups, which designate Administrator, Operator or Analyst. Within SiteProtector, these users can then be permitted or denied access to individual resources - groups or sensors - within the Site. Users can also be permitted global access to all Sites with a single login, or be forced to authenticate to each site individually as they drill down when performing analysis. As new sensors are installed they can be registered manually or automatically (via a scanning operation) with the SiteProtector Console. As new assets (hosts or sensors) are registered, it is possible to auto-group them according to pre-defined rules (such as domain name, IP address range, and so on). Since default policies can be applied at group level, it is possible to install software on a sensor (via the Deployment Manager), have that sensor register itself, assign it to a group and apply a policy without any direct action being required from the administrator. Command and control of a group of sensors can be achieved with a single click by selecting multiple sensors and right-clicking, or by applying management operations at group or site level, in which case all sensors beneath are affected simultaneously. Context-sensitive menus appear following a right click to provide the option to start and stop sensors, apply policies, apply global responses, apply updates, remove updates, or run vulnerability scans (if Internet Scanner is installed). Whenever a command and control operation is selected, the option is provided to run once or to schedule multiple repeated operations.
This would allow the administrator to have different security policies applied across a range of sensors on weekdays to those applied at weekends, for example. The potential time savings for large-scale deployments are enormous, and the ability to organise assets by multiple nested groups within multiple sites and apply management operations at any level of the hierarchy make the system extremely scalable. The most important configuration task, of course, is to assign a security policy, and around a dozen default � and fixed � policies are provided with the system (additional policies become available if you are also managing OS and Server sensors from the same Console). Each policy includes a subset of signatures designed to perform a specific task � for example one policy is for DMZ traffic, one is for Web traffic, and so on. Most of these have now been renamed with a suffix of �6.5� indicating that they are there as a �comfort factor� for ex-RealSecure 6.5 users. This approach of having multiple policies running different signature sets on different sensors was required with previous versions of RealSecure which had performance issues when monitoring too many signatures on heavily loaded networks. Since the integration of the BlackICE technology this is no longer a problem. Even if a signature is turned off in a policy with Proventia, it is ignored for alerting purposes only, but is still included in the attack detection phase. Thus the Proventia effectively always runs with all signatures enabled. Four new policies have been introduced in the latest release:
Policy definition has always been a strong point of RealSecure, but the Policy Editor still used in RealSecure and carried over to Proventia is the one remaining legacy of the old Workgroup Manager, and is beginning to look a little �tired�. It is also showing signs of straining to accommodate the BlackICE integration. It is certainly easy enough to create new policies, however - simply select one of the existing policies and click on �Derive New Policy�, give it a name, and you are free to create your own policy using that as a template. There are five tabs on the policy definition screen:
The Security Events tab lists all the available attacks in the signature database, and these can be enabled or disabled by clicking on a check box next to each one. The available signatures are split into two categories in version 7 � Attacks and Audits. Attacks are those events which are deemed serious enough to warrant an alert (DOS attacks, Trojans, Web exploits, etc) on any network, whereas Audits are events which may be considered suspicious but may be prone to false positives if enabled on certain networks. For example, one Audit signature monitors all SNMP activity, which is only of use if you do not run SNMP on your network. Other Audit signatures monitor �reconnaissance� events such as FTP SYST, SMTP EHLO, or Bind Version requests. Most companies would begin with the Evaluation policy, which includes all the serious attack signatures and some key audit signatures. This can then be tuned to remove any false alarms and add in any Audit events which may be useful on a particular network. The Attacks and Audits policy would provide the most complete coverage out of the box, but would provide far too many false alarms and superfluous data on most networks. Selecting an individual attack brings up a detailed description of the attack (including its effect and how to counteract it) and a configuration screen. There is a wide range of attacks available, and new ones are added at regular intervals through the efforts of the Internet Security Systems X-Force team. The Web-based update procedure is very straightforward and easy to use, and allows the administrator to download new signature files (known as X-Press Updates (XPU)) to the network and update individual Proventia installations from those, all of which can be accomplished from the Console.
Unfortunately, new signatures are only included on the XPU tab, and not in the main Security Events tab, which makes them very difficult to find unless you know exactly where they are. This problem should be eliminated by the use of the Search function, but for some reason this never searches beyond the first occurrence of the search string entered. Policy definition can thus be more difficult than it should be. It would be nice to see the Search function extended to produce search results consisting of multiple signatures, and also allow searching on additional criteria. The attack priority sets the priority flag which can be used for filtering and reporting, and this can be escalated automatically by the Fusion module if it determines that an attack was successful. For each event there are also a number of responses available, including:
Kill connection resets the IP connection to terminate the attack immediately, whilst the OPSEC option allows Proventia to automatically reconfigure any OPSEC-compliant firewall to prevent further attacks. Response settings become the defaults for individual signatures, but these can be overridden in bulk by applying different response settings at sensor, Group or Site level.
There is also an Advanced properties screen that theoretically provides the means to edit any additional parameters that might apply to a specific attack signature, as well as define how multiple events should be handled and propagated from sensor to Console. Both the Event propagation control � the means by which rapidly occurring attacks can be consolidated into a single alert to prevent network floods � and tuning parameters for individual signatures tend not to be found here any more, however, since following the integration of the BlackICE technology they are now made available via a set of parameters that are applied at the sensor level. No doubt this dialogue box will disappear in future releases once the new common policy editor is released and customers have migrated from the 6.5 sensors. Event coalescing worked extremely well in our tests, with each alert generated containing a repeat count to show how many attacks of that type were actually detected. This count remains accurate until the sensor is under extreme loads, at which point a �pre-coalescer� cuts in to drop a percentage of identical packets before they are passed to the parsing engine. Proventia can be used to monitor more than just security problems by using the Connection Events. These are generic events such as HTTP, FTP or SMTP activities, and can be filtered by source or destinations address, source or destination port, or protocol. One possible example of how this could be used would be if company policy forbids the use of Telnet. Proventia could be configured to monitor for TCP port 23 and log the source and destination addresses of the perpetrators, perhaps killing the process too.
User-defined signatures allow the administrator to apply regular expression string matching on certain fields within a packet (login name, URL data, e-mail subject, etc.) to determine suspicious content. This could be used as a �quick and dirty� virus checker by creating a signature that raises an alert every time it detects a packet with a specific string in the e-mail subject field, or to monitor and alert on attempts to login as Root. User-defined signatures containing regular expressions can be a performance drain, and ISS turned off RegExp parsing of custom signatures in the test system in order to achieve Gigabit speeds when under heavy loads of HTTP traffic. Note that this is the limit of signature customisation via the Console interface � neither RealSecure nor BlackICE have ever been particularly flexible when it comes to signature customisation (especially of the built in signatures, which remain virtually untouchable in this latest release). However, Proventia does include the Trons module which provides the means to add completely custom rules using the Snort rules definition syntax. Although neither TCP reassembly nor any of the standard Snort plug-ins and pre-processors are supported, Trons does allow the administrator to add brand new signatures using a familiar �language� that is reasonably easy to learn and simple to use. And, of course, there is an entire library of signatures ready made on the Snort Web site, though Internet Security Systems does not recommend you add them all. Apart from a significant overlap in functionality between the Snort and built-in signatures, there would be a heavy performance impact. Because the Trons module is currently completely separate from the Proventia PAM (this will not always be the case in future releases), the signature parsing path is not exactly optimised, and thus Trons signatures should be kept to a minimum. We found it very straightforward to add Snort signatures to our Proventia sensor, and the resulting alerts are displayed in the SiteProtector Console alongside all the built-in alerts, but including Snort-specific data in the Event Inspector window, such as the Snort SID, external reference, version number, and so on.
Finally, if there are genuine events which are raising false alarms via Proventia, the Packet Filter tab allows the administrator to define which packets should be ignored for alerting purposes, based on protocol, port or IP address. All packets matching one of the defined packet filters are rejected before being processed by the parsing engine. Where it is still required to disregard specific events that have been detected by the sensor � perhaps because they are known to be false positives when coming from a particular host � then the Event Filters can be used. Here, the administrator can specify an event name, together with source and destination IP address and port, and any event detected by the sensor matching these criteria is simply ignored. Once policies have been defined they are applied to individual sensors, Groups or Sites via the SiteProtector Console. Multiple policies can be defined for different functions (i.e. DMZ or internal network) and applied to a range of sensors via the asset hierarchy. Policy application can be performed as a one-off process or scheduled for regular runs, thus allowing administrators to apply different policies at different times (days and nights, weekdays and weekends, and so on). If the administrator makes a change to an existing policy, SiteProtector will determine which sensors are using that policy and provide a list to the administrator allowing him to deploy the policy to all sensors in one go, or just a selection of them (by deselecting checkboxes).
The existing Policy Editor in SiteProtector 2.0 is actually one of the few remaining legacies from the old Workgroup Manager Console. This will be replaced in the near future by a new Java-based Common Policy Editor that will provide a single interface for all types of security policies to be applied via SiteProtector. Once a sensor is up and running with a policy applied, alerts are logged locally on the sensor (if required) and transmitted in real time to the designated Event Collector, from where they are stored in the database. At user-defined intervals, the SiteProtector Console retrieves new events and displays them in the Analysis pane in a �spreadsheet� format.
Each row of the spreadsheet displays the complete alert details, including date and time, source and destination IP address, source and destination port, severity, status, URL/command that cause the alert, and so on. Right clicking on an alert provides the ability to view all alert details in a single window, which makes it more readable. It is also possible to call up the detailed X-Force information on that alert, but the ability to view detailed packet contents is missing. A number of other options on the right-click menu guide the administrator through the process of �drilling down� through the data to get to the most important and relevant information. This is done by providing a number of plain English �questions� such as �What are the event details?�, �What events were generated from this attacker?� and �What attacks were against this target?�. A number of filter options are provided along the top of the screen, allowing the administrator to home in on the data that is of interest by specifying source and target IP addresses (or ranges), ports, date and time stamps, and so on. One extremely useful feature is the ability to create �baselines�. At any given point in time, the current analysis view can be �frozen�, which maintains the totals and counts (such as event count, target count, and so on) on screen. Any increases or decreases in those totals are then shown in red as plus or minus figures from the baseline, making it easy to spot trends during an investigation. The baseline enables the administrator to determine, at a glance, how events have changed in an analysis view. If, for example, he notes that one IP address or tag name is associated with an unusually high increase in the number of events, he can investigate it to determine whether it represents a threat.
Different analysis views can be loaded directly from a drop-down menu, each one providing a different data layout (a different �report format� if you will), and these are almost infinitely customisable via the ability to define column layouts and filters to be applied to the underlying data. Once the administrator has fine-tuned the analysis to his satisfaction it can be saved for subsequent recall. Events that are deemed unimportant can be designated as �Exceptions� and they will subsequently not appear in analysis views. This does not prevent them from being detected in the first place, merely from being displayed for analysis - it would be nice if there were a right-click option to enable the signature that caused the alert to be disabled in the policy. Should the administrator determine that a group of events are related (perhaps a port scan, followed by a buffer overflow, followed by attacks launched from the compromised machine) they can be groups together as an �Incident�. These events are then removed from the normal analysis display and are shown only in the Incident analysis views. This allows the administrator successively to reduce the data displayed, resulting in the ability to �find the needle in the haystack�. Incidents are tracked as a unit from that point on, and the incident can be annotated with actions taken to resolve it. This is an extremely useful feature, and would be even more useful if it were possible to flag each incident with a status (pending, resolved, under investigation, etc) and an owner. SiteProtector�s modular format enables plug-in enhancements for a wide range of security management needs, and the Security Fusion module is the first plug-in module for SiteProtector. This extra-cost module uses data correlation and analysis to rapidly and automatically derive the likelihood of a successful attack from aggregated vulnerability assessment information. Visual cues in the SiteProtector Console indicate attacks with a high probability of success, with automatic escalation criteria for critical security events. For example, the module can escalate important events by generating additional responses outside the Console (such as email or SMTP). Alternatively, it can de-emphasise less important events by reducing alert priority or by selectively preventing an event from being displayed or logged. All escalation and de-escalation options are fully customisable. During testing, we noted that a specific alert � a DNS Zone Transfer � was escalated from the normal event priority of medium to high because Internet Scanner had previously determined that the particular host against which the transfer was made was potentially vulnerable to spurious zone transfer requests. On the other hand, it would be possible to �downgrade� an alert from high to medium or low if the attempted attack � say an FTP exploit � was against a host with no vulnerable FTP service running. This approach can help to reduce false alarms, and can certainly reduce the load on the administrator since it would be possible to record all suspicious events for trend reporting and forensic analysis, whilst only alerting on events where there is a real chance of an exploit targeting a vulnerable host.
The potential downside, of course, is the necessity to run Internet Scanner at sufficiently regular intervals to make the data correlation effective, but SiteProtector makes it easy to schedule Scanner runs in order to achieve this. In addition to the escalation and downgrading of alerts, Fusion also records its assessment of the alert (failure, likely to have succeeded, etc.) in the alert details, making it available in analysis views and reports. The most valuable feature of Fusion, however, is the ability to analyse and group alerts into Incidents. If Fusion detects a pattern of events similar to the one we mentioned earlier - a port scan to a particular host, followed by a potentially successful exploit, followed by further port scans and exploits launched from that host (indicating that it had probably been compromised) - then it would group all of these alerts together into a single Incident. Because alerts within Incidents are removed from the normal analysis review, the result is a much smaller number if unclassified events to deal with. And by focussing on the Incident analysis first, of course, the administrator can be sure of spending his time dealing with genuine problems. The alert-handling capabilities of SiteProtector 2.0 are a huge improvement over previous RealSecure management consoles, and although there were still one or two rough edges and minor bugs to be smoothed out in the version we tested, it is one of the better IDS consoles we have seen in our labs. ISS has eliminated the very basic, fixed reports that were available in Workgroup Manager and provided instead the almost infinitely customisable analysis tool that we discussed at length in the Alert Handling section.
Although a number of very useful basic views are provided out of the box (Attacker, Details, Event name, Incidents, Sensor, and Target), the real power of the system lies in the fact that it is possible to create a limitless supply of customised views by specifying your own column layouts and filters (and not a Crystal Report in sight!). These custom views can be saved for later recall, and can also be saved as reports in PDF, HTML or CSV format. When saving HTML files, an index is automatically created of all reports saved, making it easy to publish management reports to a Web site if required. All reports can also be scheduled to run at regular intervals. In addition to the analysis views and text-based reports, SiteProtector also provides the Enterprise Dashboard. The Enterprise Dashboard allows the administrator to:
The Metrics and Trends pane enables you to view security results for specific assets, sensors, and sites, and to create reports that display trends. The information in the Metrics and Trends pane is based on the filters you select in the Filters pane. This displays information on the following tabs:
Even though the detailed packet contents are not stored as part of the Proventia database, it is possible to store detailed packet logs of all traffic seen by the sensor (packet logging) or just packets associated with specific signatures (evidence logging). When packet logging is enabled, Proventia records all system traffic into log files, the size of the files and rotation characteristics controlled via the Advanced Properties tab for each sensor. It is important to note that packet logging keeps track of all system traffic, not just intrusions, which can result in some large files and would obviously have quite an impact on performance.
If it is required to be more selective in what is recorded, evidence files can be used. These are controlled via the global or per-signature settings in the policy files. Whenever a particular attack is detected that is flagged as �Log Evidence�, Proventia captures network traffic specific to the attack in progress and stores that information in an evidence file. Both Packet and Evidence Logs are encoded as Sniffer or tcpdump trace files, and will require a decoding application (which is not included) to view the contents. Unfortunately, these log files must be retrieved manually from each sensor (although they can be retrieved centrally via the Console) and there is nothing to tie the individual alerts in the database to specific evidence files, making forensic analysis more difficult than it should be. With the removal of the aged Workgroup Manager Console and its replacement with the more scalable and flexible SiteProtector, Proventia has taken a huge leap forward. It now combines an excellent user interface with one of the best � both in terms of performance and accuracy � sensor engines on the market. The only significant portion of �legacy� code remaining in the user interface is the Policy Editor, which is certainly showing signs of the strain involved in making two quite different technologies - BlackICE and RealSecure - work together as seamlessly as possible. This should be replaced in the not too distant future with the new Java-based Common Policy Editor which, as its name implies, will provide a common policy management interface across the entire Proventia range. Clearly a lot of effort has been put into designing the Proventia hardware to cope with the bandwidth claimed (although we only verified performance to 100Mbps) and in producing custom drivers for the built in network cards. This care allowed Proventia to achieve virtually 100 per cent detection rates across the board in our 100Mbps tests. Performance has proved to be one of the strong points of the RealSecure Network sensor range since the integration of the BlackICE product, and the Proventia appliance proved itself to be an excellent performer too. The only slight deviation was a 99 per cent detection rate at 100Mbps of 64 byte packets. In all other tests - including our HTTP stress tests, the appliance showed a clean bill of health. This should certainly allow it to handle any current real-world 100Mbps environments. Signature recognition is excellent too, with the product performing extremely well out of the box, and the company responding very rapidly to release an updated XPU which provided 100 per cent signature recognition with our test cases - this was made available to ourselves and ISS customers within 24 hours. Resistance to false positives and all evasion techniques was excellent, and we noted a much reduced incidence of noise (multiple alerts for a single exploit) in this release from previous versions. The old Workgroup Manager Console was one of the most comprehensive and easy to use out of the box and for a long time was the benchmark against which all other IDS consoles were measured. With SiteProtector, ISS has done it again, producing one of the best consoles we have seen in our labs to date. It is worth pointing out that this is no longer an extra cost option, but is included in the price of the sensor (Security Fusion remains an extra-cost option, however). Sensor and policy management are amongst the most straightforward and scalable that we have seen to date. Policies can be applied to multiple sensors at the click of a mouse, and the use of rules to auto-group assets together with the ability to apply policies at site or group levels means it is very easy to install and activate sensors with little or no administrator intervention. Currently, Proventia is probably one of the easiest products to deploy across a large, distributed network that we have seen. Alert handling, too, is excellent, with SiteProtector attempting to simplify the life of the administrator via automatic impact analysis and event correlation across vulnerability assessment tools and network sensors. The result should be the ability to reduce the number of critical alerts appearing at the Console to a more manageable level in even the largest installations by grouping them together and tracking them as �incidents�. The ability to report and annotate at an incident level is useful, as is the ability to manually correlate multiple events into a single incident if required. The only significant shortcoming we noted was the inability to view packet contents during incident investigation - the separate packet logging capabilities just do not cut it, and make it harder to perform forensic analysis than it needs to be in some cases. We are told that this issue will finally be addressed in a forthcoming release (packet viewing at the console is already available in SiteProtector service pack 2 using the Proventia A604 code base and above). Built in reports have given way to infinitely customisable views which provide the means to drill down into the event data from almost any angle. The resulting views can be saved and recalled on demand or run at regular intervals via a scheduler, and the Dashboard provides high level graphical summaries. It is nice to see a company producing a genuine advance in reporting and analysis tools rather than simply relying on Crystal Reports and a few basic pre-defined templates. Performance is not everything when it comes to Intrusion Detection, but since the integration of the BlackICE technology RealSecure has never had a problem with performance. Proventia is no exception. Where the latest Proventia offering scores, however, is with the bundling of a ready-to-run appliance with latest release of SiteProtector 2.0 and the advances it brings to sensor management and event analysis. This one is going to be hard to beat. Company
name: Internet
Security Systems Click here
to return to the ISS questionnaire |
Security Testing |
Send mail to webmaster
with questions or
|