 |
|
|
Internet Security Systems Proventia Network Intrusion Prevention System GX4004 (Firmware v1.3) Proventia Network Intrusion Prevention Systems (IPS) are dedicated devices designed to operate in either in-line IPS or passive IDS mode.� The Proventia GX4004 is the first custom-designed hardware product to appear from Internet Security Systems (ISS), featuring a standard Intel platform with integrated custom packet processing hardware, and a front panel LCD and button array for ease of configuration. The detection engine is built upon the proven Proventia code base. � The Proventia GX4004 features two copper 10/100/1000Mbps ports for management, and four copper 10/100/1000Mbps network cards which are capable of operating in pass-through mode when power is not applied to the appliance. This provides the ability to monitor and protect two in-line (IPS) network segments or four passive mode (IDS) network segments. Proventia appliances can operate in three modes: Active (inline, blocking), Passive (not inline, no blocking), and Simulation (inline, no blocking). � Security effectiveness was impressive, with good coverage of the most critical vulnerabilities, and extremely strong resistance to typical evasion techniques.� The Proventia GX4004 is designed for 200Mbps throughput and offers outstanding performance coupled with extremely low latency under all traffic conditions. Thanks to the new custom hardware, the Proventia GX4004 is impressively over-engineered for its rated 200Mbps, and should be capable of handling well beyond that level of traffic in a typical network. We also found the Proventia GX4004 to be to be very stable and reliable, coping with our extensive reliability tests with ease. � The SiteProtector management system has been well designed to handle management and configuration of large numbers of IPS and IDS sensors across the enterprise. Alert handling is powerful and flexible, especially when combined with the optional SiteProtector SecurityFusion module. � The latest release has added some impressive new features, and has significantly enhanced usability.� The ISS appliance-based IPS offering consists of the following components:� The Proventia GX4004 appliance is a dedicated 1U rack mount server chassis based on a standard Intel platform with some custom hardware for packet processing. Details of the processor and memory configuration are not available, but they are designed to accommodate the rated bandwidth of the appliance (200Mbps in this case). The Proventia GX4004 includes no redundant components (though these are available on other models in the Proventia range). There are six built-in copper 10/100/1000Mbps ports on the front panel, two dedicated to management functions, and the others dedicated to in-line or passive monitoring.� With this configuration, up to two segments can be monitored in in-line mode, or four in passive mode. When there is no power applied to the device, the in-line interfaces feature an automatic bypass, ensuring that traffic is passed normally when the device is otherwise unavailable. Note that this is not configurable within the device, and thus it is not possible to have the sensor fail closed. A pseudo “fail-closed” mode can be achieved by using crossover cables, however.� The Proventia GX4004 uses the Linux-based Proventia operating system together with ISS’ IPS software and custom drivers specially built for Proventia Network IPS hardware. The system is hardened and completely locked down so that the only way it can be accessed is from SiteProtector, the Web-based Local Management Interface (LMI) or via a command-line session (SSH or local serial connection). � Sitting in front of the detection engine in terms of the logical path taken by the traffic being analysed is a dynamic packet filtering firewall (it is actually fully integrated with the engine). This is a very simple firewall which can have rules created for it by the administrator within SiteProtector as well automatically by the detection engine whenever dynamic blocking is enabled. The idea is to provide a “fast path” for certain traffic - if rules are matched by the firewall first (either to permit traffic or to block it) then the packets can be passed directly to the internal interface or dropped instantly without ever having to be passed through the inspection logic.� All initial configuration functions - such as IP address assignment,�management console assignment, and password change - can be achieved via a simple text-based local interface to which the administrator is restricted following login.�It is also possible to switch monitoring modes, examine and clear the dynamic blocking table, and reboot or shut down the appliance via this menu. � Other useful -� more advanced - options, include the ability to specify whether the driver maintains the link and forwards traffic, maintains the link and drops traffic, or does not maintain the link at all whenever the detection engine becomes unresponsive, when the network becomes congested, or during an update. � Alternatively, the device can be configured to communicate on the network via the front-panel LCD array, after which configuration can be finalised remotely. All other day-to-day administrative tasks, such as policy changes,�can be accomplished via SiteProtector, or via the LMI.� Although the Proventia range does provide High Availability options, they are not available for the Proventia GX4004, which is positioned as a lower end device.� 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 Event Collector (a SiteProtector component) pulls data from sensors and stores the data in the SiteProtector 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. There is a failover capability between Event Collectors, such that if one fails another will assume its role.� 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.� SiteProtector SecurityFusion Module The SiteProtector SecurityFusion module is an optional (extra-cost) module that correlates data from multiple sources, including intrusion prevention data from Proventia, RealSecure Network and�Server agents, and vulnerability assessment data from ISS’ 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, and is implemented as a Java plug-in to Internet Explorer. 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.� Local Management Interface (LMI) The LMI� - also known as Proventia Manager - provides a direct management option for the administrator via a browser-based console. � This option allows the administrator to manage a single Proventia device without having to install the SiteProtector three-tier management system. However, although most of the SiteProtector features are available via the LMI, the restrictions of the browser interface mean that management via SiteProtector is far more effective. This is especially true once more than one appliance is being managed from a single location, at which point the centralised administration, alerting and reporting capabilities of SiteProtector come into their own.� Should communications between the sensor and the SiteProtector management server be interrupted for any length of time, the LMI also provides a useful interim means for the administrator to amend policy, view alerts, and so on.� The following local functions must be managed directly on the appliance via the LMI, even when the appliance is registered with SiteProtector: �
We installed one sensor with the latest X-Press Update (XPU), and used the default protection policy as provided by ISS (with blocking enabled). Note that ISS only enables those signatures for which it is confident enough to recommend blocking. This is a strange default policy, in our opinion, since there are hundreds of additional attack signatures which could provide valuable information if they were enabled in non-blocking mode.� In the most important suite of tests - the Critical/High Severity exploits which provide administrator/root access to widely deployed servers - the Proventia GX4004 performed extremely well, missing only one test case. In addition, all of the detected exploits were blocked out of the box.� For the remaining exploits, the best results were achieved by enabling all attack signatures, not just the ones recommended by ISS. Coverage of the Medium Severity exploits was very good once this had been done, missing just three test cases. � Low Severity exploits are those which may have serious consequences, but which are against applications which are typically less widely deployed. Here, the Proventia GX4004 did not fare quite as well, detecting less than 50 per cent. This possibly indicates that X-Force devotes most of its research to the mainstream OS and applications (typically Microsoft, of course) and the more high-profile exploits (not an unreasonable allocation of resources). It should be pointed out, however, that ISS has committed to create signatures for all of the missed exploits.� After enabling key audit signatures, the Proventia GX4004 did exceptionally well in the Audit and Reconnaissance test suites, detecting all of the Audit cases and missing only two of the Reconnaissance. This highlights ISS’ roots in the IDS market place, and also demonstrates that ISS - unlike some other vendors - does not deem it necessary to “prune” older signatures from its database to improve performance.� DOS and P2P traffic was well covered, and performance in the very difficult Server-to-Client (S2C) test suite was very good. The only suite not tested was Spyware/Adware, since, for now, ISS recommends the use of its host-based products to provide the most complete protection against such threats. This is likely to change over the next 12 months, however. We noted a minimum of “noise”, with very 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 good out of the box, and there is every indication that the majority of signatures are written for the underlying vulnerability rather than specific exploits. Specific exploit signatures are also included where appropriate, however, to provide more forensic information for the administrator. � A major concern in deploying an IPS is the blocking of legitimate traffic. Performance in our extensive false positive tests was outstanding, with only a single test case creating a true false positive alert. All in all, the Proventia continues to be one of the most consistently accurate IDS/IPS systems we have tested.� Resistance to known evasion techniques was excellent, with the Proventia GX4004 achieving a clean sweep across the board in all our evasion tests. IP fragmentation, TCP stream segmentation, RPC fragmentation, URL obfuscation, FTP evasion, and even HTML obfuscation of S2C exploits all failed to trick Proventia into ignoring valid attacks. Not only were the fragmented and obfuscated attacks blocked successfully, but all of them were decoded accurately as well. � Our rigorous test suite did uncover one bug which initially affected three of the TCP segmentation test cases, but this was fixed and distributed to the field within 48 hours, and the device was re-tested to ensure the fix was effective.� Default operation of the device is to pass traffic without inspection when resources (such as state table memory) are low, or when traffic loads exceed the device capacity. We reconfigured the appliance for maximum security rather than minimum interference with legitimate traffic. To do this, we altered the settings to drop unanalysed packets, and to drop packets when resources are exhausted. � In this state, the Proventia GX4004 will drop new connections when the state tables are full or resources are low, meaning it will block legitimate traffic, but will maintain state on the oldest connections (preventing evasion). This is also configurable, however, allowing the administrator to ensure that legitimate connections are always allowed, at the risk of possible evasion via attack traffic from aged-out connections.� The fact is that there is no right or wrong way to do this - all IPS devices have to make the choice whether to risk denying legitimate traffic or allowing malicious traffic once they run low on resources. ISS has done extremely well here in allowing the administrator to choose for himself which of these risks he would prefer to take. It is important for potential users to determine which is most important to them - security or transparency - and configure the device accordingly. ISS is one of only a handful of vendors who make it possible for the administrator to configure the device to this level.� Once configured, the Proventia GX4004 handled 280,000 open connections whilst maintaining state - ISS claims a maximum of 200,000 (no tuning is possible). Stateless “exploits” are not alerted upon (this is correct behaviour in order to be resistant to Stick and Snot tools) and mid-flows are not blocked by default. As you might expect, it is possible to configure the device to block mid-flows if required.� Please refer to the Test Results section for full details of the methodology used and performance results. 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 Proventia GX4004 was tested up to 200Mbps, the rated speed of the appliance. Performance at all levels of our load tests was impeccable, with 100 per cent of all attacks being detected and blocked under the most extreme load conditions. In fact, the new hardware platform is impressively over-engineered for a device at this end of the market, and we would have no hesitation in rating the Proventia GX4004 as a true 200Mbps device as claimed by ISS. In many typical network deployments it would prove capable of far more.� Basic latency figures were excellent for a device of this type at all traffic loads and with all packet sizes, ranging from 98�s with 50Mbps of 128 byte packets, to 135�s with 200Mbps of 1024 byte packets. Behaviour throughout the tests with no background traffic was very predictable, with minimal increases in latency as traffic levels increased from 50Mbps to 200Mbps across each packet size.� Placing the device under an increasing load of HTTP traffic (from 50Mbps to 200Mbps) had no effect on latency through the device, and all results remained well below the “magic figure” of 300 microseconds, our limit for deploying in-line devices in the core of the network. HTTP response times were also excellent.� 20Mbps of SYN flood traffic had no effect on the Proventia GX4004 at all. Latency increased by only a couple of microseconds across all packet sizes, and HTTP response times were almost completely unaffected. The SYN Flood was mitigated almost completely, and the device remained responsive and able to pass all our legitimate traffic throughout and following the attack.� The Proventia GX4004 performed consistently and completely 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 100 per cent of legitimate traffic. � Exposing the sensor and management interfaces to ISIC-generated traffic had no adverse effect, and the device continued to detect and block all other exploits throughout and following the ISIC attacks. No attacks are detected against the management interface.� There was minimal interruption in processing normal traffic during a policy push to the sensor. With a constant background load of 100Mbps of HTTP traffic, a small number (less than 0.4 per cent) of TCP connections failed, and the average HTTP response time increased from 201ms to 204ms during the test. � The device also failed open successfully following a power fail. Once again, with a constant 100Mbps background load there were a small number of connection failures (around 2 per cent) immediately following loss of power, and the average HTTP response time increased over the duration of the test from 201ms to 223ms� Please refer to the Test Results section for full details of the methodology used and performance results. This part of the test procedure consists of a qualitative evaluation of the features and capabilities of the product, and covers installation, configuration, policy management, alert handling, and reporting and analysis.� 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 via the LCD module or a serial connection, with a simple configuration menu being presented automatically when logging in to the admin account via the latter. � Once configured, the Proventia appliance can only be accessed directly via a serial cable, or remotely using SSH, the LMI (HTTPS) or SiteProtector.�
Subsequent registration of the sensor with the central SiteProtector server is straightforward and secure.� Documentation is generally excellent for the Proventia range. It is provided as PDF files or hard copy, and includes a User Guide for each of the components. The level of detail is good, and we found coverage of all the main features to be reasonably comprehensive and very clear. SiteProtector provides scalable, centralised security management and data analysis capabilities for all Proventia appliances, RealSecure Network, Server, and Desktop agents, and ISS’ scanning applications. � 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. � The Groups can be nested within Sites and within other Groups, and the result is a hierarchical menu structure which appears in the left hand pane of the Console. This menu can be designed to mirror any logical or physical collection of security devices required by the administrator. When it comes to applying security settings, the lower Groups can inherit settings from Sites or Groups higher up the tree structure, or the administrator can override inheritance to apply individual settings local to each node in the tree.�
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, operating system type, and so on). � Since policies can be applied at Group/Site level, it is possible to install a sensor, have that sensor register itself, assign it to a Group and apply a policy without any direct action being required from the administrator. This is a nice feature.� 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. 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 role-based user management is very comprehensive in this latest release. Active Directory is supported, allowing the administrator to add new users simply by selecting them from those already defined to the operating system. Once a new user is added, View/Modify/Control permissions can be specified for each management functional, allowing extremely fine-grained management control on a per-administrator basis.�
Operators with viewing privileges, for example, cannot perform command and control functions, but may view the aggregated security information contained within a SiteProtector environment. � Unfortunately, this fine-grained control only extends as far as the Console functions, and not to the hardware/asset level. Thus, it is still not possible to restrict access to a specific port, sensor, or even Group, making it unsuitable for some Managed Service Provider (MSP) deployments.� Key database management tasks can also be performed via the Console. Automated backups can be configured, as well as sophisticated automated purging by event categorisation type. This latter feature enables the administrator to set a time interval for keeping exceptions, incidents and un-categorised events, and to set granular filters on specific events to define exceptions to the automated purging regime.� Automated signature update tasks can be configured at Site, Group or Sensor level (or all three), allowing complete control over the update process. Updates can be downloaded for manual install, or can be installed automatically as required. Firmware updates can be configured in the same way.� Usability of the Console is enhanced in this release by the use of multiple tabs which run along the top of the screen. New tabs are spawned automatically each time the administrator right-clicks on a node in the hierarchical menu to configure parameters, or tabs can be created manually to contain Agent, Analysis, Asset, Policy, Report, Summary or Trouble Ticket details. Multiple tabs can be opened for each of these, allowing the administrator to have multiple analysis views open at the same time, for example, and flick quickly back and forth between them. Tab control is very intuitive.� Each Proventia GX4004 operates in true transparent bridge mode, meaning the mission interfaces have no IP address visible on the network. Each in-line port pair can operate in one of three modes: in-line protection (blocking), monitoring (non-blocking), or simulation (alerts are raised as if in blocking mode, but no blocking is performed). The simulation mode is ideal for initial deployments where the administrator wants to see the exact effects of a policy without the risk of blocking any traffic. Policy management has changed significantly since NSS last reviewed a Proventia Network IPS, and is much improved.� Strangely, there is no way to create and save multiple policies, per se, but the introduction of Protection Domains allows a similar effect to be achieved. The Security Events menu option is where the administrator can specify the type and volume of security events that an agent detects, the priority of security events that the agent detects, and the agent’s response to security events. � ISS provides a “default policy” of recommended settings which has all of the signatures for which X-Force recommends to be enabled in blocking mode. All other signatures are disabled. Most administrators would probably want to enable all attack signatures (as distinct from audit signatures, which should only be enabled in specific cases), at least in logging mode. � Custom signatures can be added via the Trons module, if required. Global exceptions to the main policy can be created via the Firewall settings - for example, the administrator could specify that FTP traffic between two networks should never be blocked, or that all HTTP requests to a specific server should be blocked regardless. Proventia’s Connection Events also provides the means to block all connections events of a particular protocol, as well as the ability to alert on those events, or to log evidence for the entire session.� Making changes to policies is extremely flexible and very intuitive, thanks to the excellent bulk editing capabilities in SiteProtector. When viewing policy data, the administrator can add/remove columns of data, group data by specific columns, and apply extensive filters and search criteria to the policy data to drill down to a specific group of signatures. Once a group has been isolated, editing operations can be applied to all the signatures at once - for example, to enable or disable the signatures, to enable or disable blocking mode, to modify the severity setting, and so on. With this release, SiteProtector is offering one of the best policy editors we have seen in our labs.� The default policy is active at the global Site level, which means it is automatically applied to all sensors in the site unless instructed otherwise. The administrator can override this at the Group or individual sensor level, if required. Protection Domains are the means by which ISS has introduced virtualisation to the product, and any number of Domains can be created to cover specific ports on the sensor, VLANs, or IP address ranges. By default, there is a single Protection Domain active, called Global, which basically covers all sensors and all networks. � Once a Protection Domain has been created, the administrator can cut and paste Security Settings between the Global Domain and the new one. These settings can then be modified to accommodate the requirements for that particular Domain - for example, it would be possible to restrict the WEBSERVER Domain to the VLAN or IP address range containing the corporate Web server farm, and then enable only Web-related signatures for that Domain as required.�
This allows fine-grained control over the policies applied at different locations throughout the corporate network, and is very flexible. Protection Domains can be activated at the Site, Group or Sensor level, and the Global Domain acts as a “catch all” policy - i.e. wherever a custom Domain is not in force, the Global Domain is used.� Whenever changes are made to policies, they are deployed automatically wherever they are needed throughout the organisation as soon as the changes are saved. Note that it is also possible for the administrator to specify the organisational node from which any of the Security Settings are to be inherited, thus preventing access and changes at lower levels. This way, the highest level administrator can maintain control over certain settings at the Site level, whilst allowing lower-level administrators to change other settings at Group or sensor level.� All changes to policies are logged, although the current release does not track policy versions or allow roll-back. However, there is a manual export/import facility, allowing current settings to be exported to the central Repository (SiteProtector database) or the local file system, and imported at a later date should system settings be corrupted. Once a sensor is up and running with a policy applied, alerts are logged locally on the sensor (if required) and then forwarded to the designated Event Collector, from where they are stored in the database. Aggregation is performed to ensure that flooding attacks are reported in summarised form only. � The maximum size of the local log file can be configured by the administrator, and if filled (following an extended interruption in communications between sensor and Event Collector, for example), the device can be configured to either “wrap” the entries (overwriting the oldest) or stop processing traffic.� For each event there are also a number of responses available, including:�
The Quarantine option (also known as dynamic blocking) enables the administrator to determine that all subsequent traffic from the offending source IP or to the target IP is blocked automatically and immediately. This facility needs to be used carefully since it has the potential to cause a DOS condition if any of the addresses in the attack packet are spoofed. However, it does provide the means to effectively mitigate heavy attacks from one particular source or targeted at one particular server, as well as potentially isolating Worms and Trojans.� Each signature has default response settings which have been carefully selected by the X-Force team, but these can be overridden individually or in bulk via the policy editor. In addition, the default behaviour of each response (i.e. what actually happens when the administrator selects the Quarantine Intruder option) can be altered by applying different settings at sensor, Group or Site level. � At user-defined intervals, the SiteProtector Console retrieves new events and displays them in the Analysis pane in a “spreadsheet” format. Multiple views can be applied to the event data to display in various formats - summarised by event type, detailed individual alerts, and so on - and these can be selected from a drop down menu. In addition, it is a simple matter to view alerts for a specific Group or Sensor, or for the entire site by selecting the appropriate node in the hierarchical tree in the left-hand pane. Each row of the Details view 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. � It is also possible to call up the detailed X-Force information on that alert. When in one of the summary views, right clicking a row calls up a new window containing full details of the first of the alerts, and the administrator can step forwards and backwards through them. In this window, it is possible to view detailed packet contents as well as any extended context information collected as part of the event. This information includes data specific to the actual alert - such as the offending URL or buffer contents in the case of an HTTP overflow - as well as pertinent data collected from packets leading up to the exploit - such as user name and password used to log in to the server in the case of an FTP session. In most cases this is of much more use than detailed packet contents, since the data leading up to the packet which triggered the exploit is often of equal importance to the contents of the trigger packet itself.� 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 achieved by providing a number of plain English “questions” in the menu, such as “What are the event details?”, “What events were generated by 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. Filter settings and column layouts can be saved at any point to be re-used in the future as custom analysis views (or reports).� 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. 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 useful if there was 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, enhancing the potential to “find the needle in the haystack”. � In order to assign responsibility for an event or group of events and track progress on resolving the issues which caused them, the administrator can create a Ticket. Every time a ticket is updated to reflect progress on resolving the issues to which it relates, a new version is recorded, and the complete version history is always available for review. � Tickets can be tracked within SiteProtector alone, or can be exported to third party trouble-ticket products such as Remedy Action Request System.� SecurityFusion is an extra-cost module which 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. The SecurityFusion correlation capability provides the ability to analyse and group alerts into Incidents automatically, and because alerts within Incidents are removed from the normal analysis review, the result is a much smaller number if unclassified events to deal with. � The reliance on Internet Scanner for the vulnerability assessment may not suit everyone given the potential extra network traffic generated by an active scanner, but it worked well in our tests. 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. � ISS has provided an almost infinitely customisable analysis tool in the shape of the Analysis tab that was discussed in the Alert Handling section. � A number of very standard views are provided out of the box, but the real power of the system lies in the fact that it is possible to create a limitless supply of customised views by specifying column layouts and filters. In addition to the ability to save these for later recall, as discussed, they 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, and it is a simple matter to report on all events or select only those events for a specific sensor, Group or Site as required.� In addition to the analysis views, SiteProtector also provides the Summary tab, which allows the administrator to view high level graphical summaries of various metrics such as event history by day, today’s events by source IP, today’s events by target IP, system health, and so on. Individual graphs can be selected from a drop down menu for display, or deleted from the Summary tab, thus allowing the administrator to customise the view as required.� An extra-cost reporting module, based on the ubiquitous Crystal Reports product, provides basic text-based and graphical management reports. There is not much within this module that will interest the forensic analyst, since these are aimed more at producing higher-level summary reports, providing pre-defined templates for Top Attacks, Top Attack Targets, Top Attack Source, Attacks by Group, Ticket Activity Summary and Ticket Time Tracking. There are also a number of templates that rely on information produced by other modules besides the Network IPS module, including numerous assessment (from Internet Scanner), desktop protection, and virus reports.� In selecting a report template, the user is presented with a screen which enables him to name the report, select a report period, and a report format. The report period settings provide an excellent range of pre-defined date ranges, as well as the ability to specify your own down to the nearest minute - we suspect that most users will opt for the “current week” or “previous month” settings at the click of a mouse, and wish that all vendors would allow date ranges to be specified in this way.� The formatting options are fairly basic, usually limited to selecting a sort order, number of records to be displayed, and whether or not to show a graph. The output of the reports is thus fairly fixed, but it is tidy, well-presented and easy to read.� Security Effectiveness Security effectiveness was impressive, with good coverage of the most critical vulnerabilities out of the box, and all enabled signatures set to block mode. Coverage for medium severity exploits was also good, though it is apparent that ISS focuses most strongly on the most widely deployed systems in terms of signature coverage - not an unreasonable stance. Coverage for older exploits and low-level reconnaissance techniques is excellent.� Resistance to common evasion techniques is complete, with all of the exploits being decoded accurately whatever type of evasion is used.� Alerts were kept to a minimum and appeared to be very accurate, making the analyst’s job as straightforward as possible. Resistance to false positives also appeared to be very good, and all in all, the Proventia continues to be one of the most consistently accurate IDS/IPS systems we have tested. When deploying in-line protection devices it is important for potential users to determine which is most important to them - security or transparency - and configure the device accordingly. ISS is one of only a handful of vendors who make it possible for the administrator to configure the device extensively at this level. � Advanced settings allow him to choose whether to reject new connections or age out old ones when the state tables are full, whether to pass or drop packets when it is not possible to analyse then, pass or drop packets when resources are exhausted, pass or drop mid-flows, and so on. Performance Clearly a lot of effort has been put into designing the new Proventia hardware to cope with the bandwidth claimed (200Mbps on the Proventia GX4004) and many users will be comforted by the vendor finally having more control over the hardware platform used. � The result in this case is an impressively over-engineered product which is clearly capable of handling far more than the rated 200Mbps. The Proventia GX4004 offers outstanding performance coupled with extremely low latency under all traffic conditions, and latency is virtually unaffected no matter how much background traffic is passing through the device. � The sensor remained remarkably unaffected by high levels of DDOS attack too, offering complete protection for the servers behind it, whilst continuing to pass legitimate traffic through the device with extremely low latency.� We also found the Proventia GX4004 to be to be very stable and reliable throughout all our tests. Usability The SiteProtector management system has been well designed to handle management and configuration of large numbers of IPS and IDS sensors across the enterprise. 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 multiple policies can be applied to a single sensor via the use of Protection Domains. The use of rules to auto-group assets together with the ability to apply policies at Site, Group or individual sensor 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 is powerful and flexible, especially when combined with the optional SiteProtector SecurityFusion module to provide automatic correlation. The Console offers excellent analysis capabilities, the ability to create exceptions and incidents to restrict the number of alerts on view, and a trouble ticket capability to track incidents and actions taken to resolve them. � Infinitely customisable views provide the means to drill down into the event data from almost any angle via the Analysis tab in the Console. The resulting views can be saved and recalled on demand or run at regular intervals via a scheduler, and the Summary tab provides high level graphical summaries. � Crystal Reports is used to flesh out the reporting capabilities by providing a small number of pre-defined - and rather basic - management reports as an extra-cost option, thus covering all possible reporting angles.� SiteProtector continues to improve with each version, and the alert-handling capabilities make it one of the better centralised security management consoles we have seen in our labs. Policy management is hugely improved in the current version, though the ability to define multiple distinct policies and apply these to sensors, ports, IP ranges and VLANs via firewall-like rules would simplify the current Protection Domain model, which is not particularly intuitive. Our biggest criticism would be that the heavy reliance on Java makes Site Protector extremely resource-hungry. As a result, even on a hardware platform provided by ISS that was supposedly adequately specified for the job, we considered it very slow, and quickly tired of its constant complaints about running low on resources which forced us to shut down and restart the Console on a regular basis. It would be nice to see ISS produce a SiteProtector appliance to ensure that hardware resources are closely matched to software requirements.� That said, the latest release has added some impressive new features, and has significantly enhanced usability. With this latest release of SiteProtector, ISS has produced one of the best consoles we have seen in our labs to date. � Overall Due to the high levels of performance and security effectiveness, coupled with the excellent centralised management capabilities, the Proventia GX4004 has been awarded NSS Approved at the IPS + Branch Office level. This is one level above the IPS (Basic) level.� It should be noted that both the Security Effectiveness and Performance ratings were actually at the Enterprise level, and the only criteria under which the Proventia GX4004 failed to obtain the Enterprise award were the lack of High Availability functions, coupled with relatively low port density.� Should the potential user consider these features to be unimportant, this device would be more than capable of operating in an enterprise deployment.�
Company name: Internet Security
Systems, Inc.� Click here to return to the IPS Index Section |
Send mail to webmaster
with questions or�
|