 |
|
|
Proventia integrated security appliances combine ISS’ well-established Intrusion Prevention technology with Firewall, Anti Virus, VPN, Web Filtering and Anti Spam technology. The Proventia product line is designed for a range of deployment scenarios, protecting anything from 50 to 2,500 nodes. At the top end of that range, the Proventia M50 tested here protects up to 2,500 nodes from a number of Internet threats, blocking malicious code and blended attacks like MS Blaster, Sasser and SQL Slammer - attacks that can bypass traditional firewall and anti virus solutions. In addition, the M50 protects against spam, phishing and malware (i.e. spyware and adware), and unwanted Web browsing to non-business sites like online gambling, shopping and pornography. The M50 is based on a 2U rack mount Intel platform featuring eight 10/100/1000Mbps copper Ethernet ports, six drive bays (supporting a redundant drive array) and dual redundant power supplies. Security effectiveness of the M50 was excellent, whilst performance was adequate under most traffic loads in most of the tests - SMTP performance was on the low side through the Anti Spam module. The SiteProtector management system has been well designed to handle management and configuration of large numbers of sensors across the enterprise. Alert handling is powerful and flexible. The Internet Security Systems appliance-based IPS offering consists of the following components: The Proventia UTM appliance is currently offered in three flavours:
All of them are capable of being managed stand-alone via the Web-based Local Management Interface (LMI) or as part of a corporate solution with three-tier management via SiteProtector. The Proventia M50 appliance submitted for testing is a 2U rack mount server chassis based on a standard Intel platform. Details of the processor and memory configuration are not available, but they are designed to protect up to 2,500 nodes. Note that in common with most vendors in this space, ISS does not claim a specific throughput for this device, since it will depend entirely on the modules enabled and the type of traffic. The device includes redundant internal cooling fans (not hot-swappable), dual redundant hot-swappable power supplies, and a redundant hard drive array (six drive bays are provided, though only one is occupied in the standard configuration). There are eight built-in copper 10/100/1000Mbps ports on the rear panel (two built in ports supplemented by three 2-port cards), one used as the management interface, and the remainder for internal/external firewall ports. The Proventia M50 is Linux-based, running integrated software for Firewall, VPN, IPS, Anti Virus, Anti Spam and Web Category Filtering. Only AV functionality is licensed from a third party (Sophos), and the rest of the software has been written in house or acquired. The system is hardened and locked down so that the only way it can be accessed is from the LMI, SiteProtector or SSH (or directly at the appliance via keyboard and monitor). 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. It is also possible to configure network settings for the management interface, set date and time, admin password, and reboot or shut down the appliance via this menu. All other day-to-day administrative tasks, such as policy changes, can be accomplished via the external management options installed nearby or at a remote location. 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 pulls data from sensors and stores the data in the database. Typically only one Event Collector is installed on a SiteProtector Site (on the same host as SiteProtector itself), but up to five Event Collectors can be installed per Site when required for performance reasons. Recent releases have added failover capability between Event Collectors, such that if one fails another will assume its role. SiteProtector SecurityFusion Module The SiteProtector SecurityFusion module is an optional (extra-cost) module that correlates data from multiple 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 implemented. 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. One of the biggest advantages of the Java-based approach rather than the C++ code of the old Workgroup Manager 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. Local Management Interface (LMI) Each Proventia appliance includes an integrated Web server allowing it to be managed directly via a standard Web browser. When the device is registered with SiteProtector it is possible only to view configuration details and alerts via LMI, but when the device is not registered with SiteProtector, LMI provides complete management and configuration capabilities for a single device.
LMI provides a complete single-device management solution out of the box without the need to install the more complex three-tier management solution demanded by SiteProtector. Unfortunately, despite the promise of “write once, run anywhere” offered by Java, LMI is severely restricted in terms of OS and browser platforms supported, and performance is poor on even the most powerful hardware. The Proventia M appliance offers active-passive high availability (HA) in routing mode by using virtual IPs shared between primary and secondary appliances linked together as a “cluster”. The two appliances connect using a dedicated link between the primary and secondary. The secondary appliance waits in passive mode ready to operate as the primary should the designated primary appliance fail. If no heartbeat is received from the primary appliance for a predetermined period of time, the device is considered to have failed. When this occurs the secondary device takes over all of the virtual IPs for all interfaces and becomes the primary. The aim of this section is to verify that the device is capable of operating under normal network conditions whilst effectively detecting and handling a range of virus infections, inappropriate content and spam traffic mixed with normal traffic. With a capacity of approximately 12,500 TCP connections per second, 6,500 SMTP sessions per second, and an effective bandwidth of 800Mbps, the basic firewall would perform well in a sub-Gigabit environment. 150,000 concurrent TCP connections are supported. Latency is in the region of 353-427�s with 512 byte packets (with some packet loss at 800Mbps), which is acceptable for a device designed for the network perimeter. The Content Filtering module demonstrated a significant drop in performance once bad traffic was introduced, compared with 100 per cent clean traffic in the same module. As you would expect, performance is at its worst once all modules are enabled. With all modules enabled, maximum TCP connections per second were around 823, and effective bandwidth was 178Mbps. Around 311 concurrent TCP connections were supported and SMTP performance was 37 SMTP sessions per second. We consider this to be acceptable for a device of this type if it is restricted to a 100-200Mbps environment and the incidence of blocked traffic is relatively low. Please refer to the Testing Methodology section for full details of the methodology used and detailed performance results of the individual security modules. The aim of this section is to verify that the device is capable of effectively applying a firewall policy, as well as detecting live virus traffic, inappropriate URLs, inappropriate Web and mail content, and spam e-mail. All inappropriate/infected traffic should be handled properly according to the protocol and applied security policy (blocked, rejected, replaced, etc.). The basic firewall was secure, with no obvious means of circumventing the applied policy. IPS capabilities are excellent, demonstrating wide coverage (100% of our basic exploit test cases were detected) and good resistance to common evasion techniques. URL category filtering was excellent, with 100% of our “bad” URLs being detected and no overblocking evident during our tests. Categorisation seemed to be reasonably accurate. HTTP and SMTP content filtering and file blocking capabilities are not included in the current release. All of the WildList virus samples in our test suite were detected and blocked successfully with accurate signatures, whilst 85 per cent of the zoo virus samples were detected successfully, also using signatures (heuristic scanning is not included in the current release). This is excellent. Both the detect & alert and the quarantine functions worked flawlessly - there is no disinfect capability. 98 per cent of the live spam samples in our test suite were detected and blocked successfully, via a mixture of lexical analysis and detection of URL links within the messages (amongst other techniques). This is an excellent score. Both the detect & flag and the reject message functions worked flawlessly - there are no quarantine or accept & discard message capabilities. However, the device did actually allow a small percentage (1.6 per cent) of spam messages through once it was under load with all spam or mixed traffic - a worrying “feature”, although obviously not as detrimental to network security as leaking virus-infected files. Please refer to the Testing Methodology section for full details of the methodology used and detailed performance results of the individual security modules. 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. 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 M50 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, allow or disallow SiteProtector access, reboot and shutdown the appliance, and so on. 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 is generally excellent for the Proventia range. 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 good, 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. The Proventia M50 can be managed via the device-centric Local Management Interface (LMI) or the three-tier SiteProtector management system - this review will concentrate on SiteProtector. 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, forcing policies to be deployed automatically each time they are amended. 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 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. 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. When it comes to configuring individual appliances (or groups), different options are provided for each type of appliance - the Proventia M50, for example, has different configuration options to an A604. What is nice about SiteProtector is that it is possible to configure a range of different protection mechanisms from a single interface. Key database management tasks can also be performed via the Console. Automated backups can be configured in the user interface by right clicking on the database, 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. Device-centric backups and snapshots of current settings can be performed via the LMI. Automatic updates are available for firmware, system software and the various “signature” databases covering AV, IPS, Anti Spam and Web Category Filtering. The update process can be scheduled to run at regular intervals, and updates can be downloaded and installed automatically, or downloaded and stored for manual deployment. It is also possible to make the entire update find, download and install operation a manual process if required. Policy configuration for the M50 is extremely straightforward, due mainly to the fact that the developers have tried to remove as much of the extraneous clutter as possible, eliminating most of the detailed parameters and selections normally found in individual products such as IPS or Anti Spam. Where more flexibility is required, however, advanced parameters can be entered for each security module to override the default settings. This is a good compromise between simplicity (given the target market for many of these devices) and flexibility.
The Common Policy Editor format ensures that as much of the standard SiteProtector look-and-feel is maintained when configuring the M50. A hierarchical menu tree lists sites, groups, and individual sensors, and check boxes at the higher menu levels allow the administrator to enforce configuration at those levels, with settings inherited by groups and/or devices at lower levels in the tree. This is very powerful, yet very intuitive to use, and allows critical policy to be enforced by one administrator, with certain non-critical settings overridden at lower levels by other administrators as required. Configuration settings for individual modules (branches of the tree) can be exported to other groups or to the file system for re-import later. This makes copying existing module settings straightforward. Another useful feature is the use of dynamic addresses in firewall policies. This allows the administrator to create “generic” rules such as “allow all HTTP traffic from CORPORATE-NET to DMZ” and a single corporate-wide firewall policy. The actual IP address values for CORPORATE-NET and DMZ are then filled in by administrators as individual firewalls are deployed throughout the organisation. The M50 can be deployed in either transparent mode (where the device acts as a bridge, with no IP addresses assigned to interfaces) or routing mode (where the device acts as a router, with different IP addresses assigned to each interface and support for Network Address Translation). The latter is how a typical gateway firewall device would be deployed, and this is how we tested the M50 in our labs. Note that alerts will be stored on the appliance and can be viewed via the LMI. For most modules, they can also be sent via e-mail, SNMP trap or direct to SiteProtector, and some modules (such as Web Filtering and AV) offer the option for an e-mail summary of alerts once a day. Firewall alerts are always stored locally on the appliance to avoid overwhelming SiteProtector. Firewall This is the most complicated module to configure, since it is obviously necessary to create individual rules to support the desired security policy. ISS has tried to make it as simple as possible by including a set of default rules to support basic management and configuration, and it is not difficult to have the device up and running in a short period of time. Beware of deleting any of the default rules, however - with no dedicated management interface and management access controlled entirely by the firewall policy, it is possible to lock yourself out of the firewall completely by deleting the wrong rule, as we found to our cost.
Application Level Gateways (ALG - also known as “proxies”) are available for HTTP, SMTP, FTP and POP3. In addition, a low-level packet filtering firewall is also available, allowing the administrator to create rules which will allow or deny packets based on information in the packet IP headers. This packet information includes:
Individual firewall rules can be enabled or disabled, and can be re-ordered within the policy to alter the order in which they are processed. Logging can be enabled or disabled for each rule. Rules also exists for each of the ALGs. Initially, these are set to process all traffic for each of the relevant protocols, but it is also possible to specify source and destination IP addresses to enable or disable ALGs for specific networks or hosts, or for inbound/outbound traffic only. NAT/PAT rules can be created for inbound and outbound traffic, and both static and dynamic NAT are supported. The ability to define and name network objects and create dynamic addresses makes it straightforward for an administrator to create complex firewall policies which are relatively easy to move from network to network in a large distributed deployment. VPN A VPN connection is initiated when traffic is accepted by a VPN rule which matches the traffic in terms of source and destination addresses. Both remote client and site-to-site VPNs are supported.
Proventia M units support the following protocols to authenticate and encrypt traffic:
DES, Triple DES (3DES) and AES (128, 192 or 256 bit keys) are all supported for encryption, and MD5 and SHA1 are supported for authentication. Both pre-shared keys and certificates can be used with IKE policies, and both main and aggressive modes are available. IPSec policies can make use of either manual or automatic key exchange. To simplify creation of multiple VPN policies, Proventia uses Security Gateways to define a group of VPN settings. A Security Gateway is a network object that can be re-used when configuring VPNs, and there are four types of Security Gateways available:
VPN wizards simplify the task of creating VPNs between M Series appliance and various VPN clients. The wizard uses the information provided by the administrator to automatically create required firewall rules and other settings. The wizards contain default settings that are optimised for most networks, and we found it very straightforward to set up simple VPN connections as well as more complex mesh networks. IPS Configuring IPS is just about as simple as you could possibly make it on the M50. A check box for Enable/Disable is all that is required to activate it, and another check box determines whether it is enabled in blocking mode (for the signatures where ISS has determined blocking should be enabled) or detect and alert only.
There is no need to configure individual signatures or groups of signatures - all of the current 100+ protocols and over 1000 of the 2500+ signatures available in the stand-alone IPS product line are enabled in the M50. When the X-Force Protection Responses box is checked, over 800 of those signatures are enabled in blocking mode. This is real plug ‘n’ play IPS! For those who really feel the need to tweak the system, the Advanced Parameters screen allows manual entry of IPS settings. However, most will manage just fine by tuning out false positive events via the Event Filters. Once a filter is in place, the IPS will ignore events for certain hosts or types of traffic. Quarantine rules are dynamically generated in response to detected intruder events, designed to prevent worms from spreading and deny access to systems that are infected with backdoors or Trojans. Quarantine rules specify the packets to block and the length of time to block them, and the rules can be viewed, removed and copied only via the LMI in the current release. Summary IPS module statistics are also available via the LMI and (in a slightly different format) via SiteProtector. Content Filtering The ISS Web Filter and Anti Spam Database contains the classification information that ISS gathers about Web sites. ISS uses fully automated Web crawlers to inspect millions of new and updated Web sites every day. The information gathered is then analysed and classified into 58 categories using ISS’ own content analysis technology. The M50 uses the information in the database to enforce Web filters and identify spam e-mail, and the appliance comes with a local database already installed. Automatic update settings choose how often the appliance downloads updates from the ISS database server to the database on the appliance.
When the Web Filter Module is enabled, the M Series appliance blocks or allows access to Web sites based on criteria selected by the administrator. It is possible to:
When a computer in the protected network attempts to access a Web site, the appliance references the Web Filter and Anti Spam Database, enforces the Web Filters for selected categories, and displays statistics about Web Filter data. One element of the implementation which caused us problems is that it is currently necessary to have an active Internet connection before enabling the Web Filter module. If the Web Filter or Anti Spam Modules are activated without a connection, the database cannot authenticate and the Web Filter and Anti Spam Modules are prevented from starting. This “token authentication” scheme is a relic of the product prior to the ISS acquisition, and needs to be removed - it can cause problems in test environments such as ours, or test networks used by customers prior to live deployment. As with IPS, enabling the Web Filter is simply a matter of checking a couple of boxes on the settings screen. If Web Filtering is enabled but Web Blocking is disabled, the appliance logs requests for access to any URL, domain, or IP address in the Web Filter categories selected, but does not block the requests. This can be used to monitor Web activity without inhibiting browsing in any way.
Web Filter Categories in the are organised into 19 major groups in the Web Filter tree in the SiteProtector GUI. The Web Filter tree appears in the left pane of the Web Filter Categories page and the administrator can click any node on the Web Filter tree to expand it. Check boxes at each level of the tree allow the administrator to select the entire list of category groups, any of the 19 major category groups, or any of the individual categories. When a Web filter Category is selected, the appliance blocks all requests from the network for any URL, domain, or IP address that ISS includes in that Category. White lists and black lists are available to override URLs, domains or IP addresses to always block, or always allow access. When a user requests a prohibited URL, a page is returned (with a 403 error code) informing them why the URL has been blocked. This page is stored on the appliance, and is customisable (though not via the GUI). A hyperlink allows the user to submit the URL to ISS for re-classification if he believes it to have been classified incorrectly. Anti Virus The Anti Virus software on the M50 uses a signature engine from Sophos, and the database is updated automatically on a regular (often daily) basis. The AV software provides protection against the threat of e-mail-borne viruses over POP3 and SMTP protocols, as well as protecting against viruses downloaded via the HTTP and FTP protocols. The AV software does not scan encrypted or password-protected files. A single check box enables or disabled AV scanning in the appliance, and a separate set of check boxes allow the administrator to select which protocols will be scanned (HTTP, SMTP, FTP and POP3).
In an attempt to improve the browsing experience for users, the AV software excludes image files with specific extensions on the HTTP protocol from scanning. These extensions are listed in the File Extensions Excluded from HTTP Antivirus list on the Anti Virus Protection Settings page. The default list includes common file types such as images, music files, and so on, and the administrator can add, edit, or remove file extensions from the list. The AV cache daemon is enabled when the Anti Virus software is enabled, and this runs in the background to improve file scanning speed. The AV quarantine daemon also runs in the background and periodically removes files from the quarantine directory. There are two areas designed to support the quarantine of files and the rules for quarantine intrusion management, generated for intruder prevention. Access is provided via the LMI to the following areas:
Quarantine can only be managed via the LMI - there is no provision within SiteProtector for this at present, which can be inconvenient. Anti Spam Anti Spam software prevents undesired advertisement or offensive e-mails from entering the network undetected. The Anti Spam software analyses text, URLs, and attachments in all e-mail traffic passing through the M50, and is capable of either labelling the e-mail as spam by adding [SPAM] or [SPAM+] to the subject line, or deleting the e-mail completely. The Proventia Anti Spam software uses a variety of analysis techniques to identify spam without blocking legitimate e-mail. The Anti Spam software uses the following technologies to scan e-mail traffic passing through the M50:
Spam is often linked with senders or domains that ISS has included in the Web Filter and Anti Spam Database, and thus URLs in e-mail traffic can be compared against URLs in that database, providing a very high degree of accuracy. The other techniques employed are also very strong, and we found that when, during testing, we had inadvertently disabled the Web Filter and Anti Spam Database, the Anti Spam module still scored in excess of 90 per cent in our spam coverage tests.
Spam tagging sensitivity settings determine how the appliance treats spam e-mail, based on the amount of spam content. When the appliance identifies an e-mail as spam, the appliance assigns a numerical value to the e-mail based on the amount of perceived spam content - a higher value causes the mail to rate higher on the Delete Threshold. The Delete Threshold slider then allows the administrator to set the level of spam content that the appliance uses as the baseline to tag or delete spam mail - mail can be tagged as [SPAM] or [SPAM+] in the subject line, or can be deleted altogether. If the administrator wishes to delete all e-mail that might be spam, even if some e-mail might be legitimate, then the slider can be set to the minimum Delete Threshold. If it is required to delete only the e-mail with high spam content, the slider can be set to the maximum Delete Threshold. During testing, we had the slider set to “Moderate”, which gave a good balance between detecting genuine spam and allowing legitimate e-mail to pass. In Learning Mode, the appliance tags spam e-mails according to the Delete Threshold level selected, but does not delete messages. In Delete Mode, the appliance deletes spam e-mails according to the Delete Threshold level. The E-mail Sender Whitelist and E-mail Sender Blacklist can be used to control which domains or e-mail addresses the appliance always identifies as spam, or never checks for spam. Wildcards can be used in these lists. Per-user WBL are not available in the current release. Once a sensor is up and running with a policy applied, alerts are logged locally on the sensor (where they can be viewed via the LMI, if required) and then forwarded 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. Alerts remain viewable via the LMI even after they have been forwarded to SiteProtector.
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 caused the alert, virus detected, and so on. Naturally, with the M50 the alert content changes depending on the security module raising it (AV, spam, IPS, 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. Where possible - with IPS alerts, for example - extended context information is provided as part of the event. This information is collected for every stateful session being tracked by the sensor, and is collated and made available to the Event Collector whenever a new alert is raised. 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. 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 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. 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. 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 SecurityFusion 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 e-mail 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 IPS 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 from the IPS module in particular, 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 its correlation capability - 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/virus traffic 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. Naturally, when operating inline it still remains within the administrators control whether to block the individual events or to alert only. The alert-handling capabilities of SiteProtector are excellent, and this is one of the better security management consoles we have seen in our labs. ISS has provided an almost infinitely customisable analysis tool in the shape of the Sensor Analysis tab that we discussed in the Alert Handling section. A number of very useful basic views are provided out of the box, including Attacker, Details, Event name, Incidents, Sensor, and Target. However, 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. 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, and query performance has been improved significantly in the latest release. In addition to the analysis views, SiteProtector also provides the Enterprise Dashboard. This allows the administrator to:
The Metrics and Trends pane enables the administrator 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 selected in the Filters pane. This displays information on the following tabs:
Various built-in text-based and graphical management reports are provided by an extra-cost option based on the ubiquitous Crystal Reports product. 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, Attack Incidents, Attack Trends, and so on. There are also a number of templates that rely on information produced by other modules besides the M50 on test here, including numerous assessment (from Internet Scanner) and desktop protection reports. They will certainly be of interest to those who require to monitor trends in the type and severity of exploits detected, or in their effectiveness at handling security incidents, and are thus aimed more at manager-level. This is one area that was omitted from the early Site Protector releases, and this module plugs a gap for those who require more than straight event analysis capabilities.
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. Performance With a capacity of approximately 12,500 TCP connections per second, 6,500 SMTP sessions per second, and an effective bandwidth of 800Mbps, the basic firewall would perform well in a sub-Gigabit environment. Latency is in the region of 353-427�s with 512 byte packets, which is acceptable for a device designed for the network perimeter. As you would expect, performance is at its worst once all modules are enabled. However, we consider performance to be acceptable for a device of this type if it is restricted to a 100-200Mbps environment and the incidence of blocked traffic is relatively low. Security Effectiveness The basic firewall was reasonably straightforward to configure, though with management access to the device also controlled by the main firewall module, we did manage to lock ourselves out of the system on more than one occasion when testing. Firewall configuration via the LMI is particularly painful, though the experience is improved when using SiteProtector. IPS capabilities are excellent, demonstrating wide coverage and good resistance to common evasion techniques. URL category filtering was excellent, with 100% of our “bad” URLs being detected and no overblocking evident during our tests. Categorisation seemed to be reasonably accurate. HTTP and SMTP content filtering and file blocking capabilities are not included in the current release, which is a shame. Virus scanning was excellent. All of the WildList virus samples in our test suite were detected and blocked successfully with accurate signatures, and most of the zoo virus samples were also detected successfully. Spam filtering was excellent, with a wide range of techniques employed “under the hood” but with configuration kept as simple as possible. 98 per cent of the live spam samples in our test suite were detected and blocked successfully - an excellent score. However, the device did actually allow a small percentage (1.6 per cent) of spam messages through once it was under load with all spam or mixed traffic. This is a worrying “feature”, although obviously not as detrimental to network security as leaking virus-infected files, and ISS informs us that it is fixed in the 3.2 firmware release. Usability Those who are deploying a single device may well prefer to rely on the LMI rather than deploy a multi-tier management system. However, although the LMI does cover everything in a reasonably intuitive Web-based GUI, we found the Java interface to be painfully slow and too heavily reliant on a single platform and browser. It was impossible, for example, to use the LMI from our Macintosh platforms or via any browser other than Internet Explorer 6. ISS has promised the removal of the Java component, and this cannot happen too quickly. On the other hand, with SiteProtector, ISS has produced one of the best consoles we have seen in our labs to date. SiteProtector is also included in the price of the sensor (though it requires a dedicated server on which to run, unlike LMI), whilst the SecurityFusion and new Management Reporting modules remain extra-cost options. One downside at the moment is that not every feature of the LMI has made its way into SiteProtector, the most notable being quarantine handling. Overall, however, sensor and policy management via SiteProtector 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 (manually or via automated “subscription”) 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. Infinitely customisable views provide the means to drill down into the event data from almost any angle via the Sensor 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 Dashboard provides high level graphical summaries. It is nice to see a company producing a genuine advance in reporting and analysis tools rather than relying purely on Crystal Reports and a few basic pre-defined templates. Having said that, the latter is now used to flesh out the reporting capabilities by providing a number of pre-defined management reports as an extra-cost option, thus covering all possible reporting angles. Company
name: Internet
Security Systems, Inc Click here to return to the UTM Index Section |
Security Testing |
Send mail to webmaster
with questions or
|
