 |
|
|
NFR Sentivist Smart Sensor 100C V1.3 NFR offers a range of Sentivist appliances for different deployment scenarios, and the IPS sensors can be deployed in in-line passive (learning mode, with no blocking), passive IDS, in-line IPS (fail closed) and in-line IPS (fail open) modes. The Smart Sensor 100C tested is a 1U rack mount appliance with four copper Gigabit ports which can be used to monitor three segments (3 ports) in passive IDS mode, or a single segment (2 ports) in in-line IPS mode. NFR rates this device at 100Mbps Blocking rates were good out of the box, and improved to 92 per cent following an update, and resistance to most evasion techniques was excellent. Throughput and latency were excellent under all network loads and across all packet sizes up to the rated 100Mbps, and under normal network conditions we would expect the device to handle beyond this level of traffic. We also found the Smart Sensor 100C to be very stable and reliable under extended attack, although resistance to high-levels of certain types of DOS/DDOS attacks was poor. We would recommend deploying this device behind an additional layer of protection, such as an attack mitigator or firewall with DOS/DDOS mitigation capabilities. Management and configuration of multiple Sentivist devices is made simple via the scalable, three-tiered architecture of the Sentivist Enterprise Console. Although policy definition can be daunting for those new to the idea of NFR’s Backends and Packages, the system is actually extremely flexible and powerful. The use of Policy Groups and sub-Groups and the concept of inheritance from higher-level groups down to lower-levels, and even down to individual Sensors, makes the task of deploying policies across large organisations very straightforward. Alert handling and reporting are very comprehensive, typical of a company with such a strong IDS pedigree. Multiple Alert Browser windows can be created, each one with customised column layouts and data filters, and these can be saved for subsequent re-use, each restricted to a different administrator if required. Accessing alert data can be performed in a variety of ways, and the unique Timeline view and useful event correlation capabilities make it easy for administrators to focus on the most important events. Overall, both policy management and alert handling capabilities are amongst the best we have seen in our labs. NFR Sentivist systems are based on a three-tier architecture only - there is no direct Sensor management capability in the current version. Although this clearly provides reliability and scalability, it does mean that a separate, dedicated host is always required for the management server component, possibly making it a less attractive (and more expensive) proposition for those who require only one or two sensors. Each Sentivist system includes the following components:
Sentivist Server receives, processes, and manages alert and event data generated by Sentivist Sensors. It also provides a centralised facility for Sentivist Sensor management and for viewing captured data. Key functions of Sentivist Server are:
All communications between the Sentivist Server, Sensors, Administration Interface and Enterprise Console are performed over AES encrypted channels. Enterprise Console (EC) is the management component of the Sentivist System. Through Enterprise Console, the administrator can monitor alerts generated throughout the entire system and perform high-level analysis. Enterprise Console also allows configuration and management of all Sentivist Servers and Sentivist Sensors deployed across the corporate network from a central point. Enterprise Console has two components:
Sentivist EC can be installed on the same host as the Sentivist Server component if required, and this is typical in most small deployments. In larger deployments, however, it is possible to improve scalability by installing EC on a dedicated server communicating with one or more Sentivist Servers. The Administration Interface (AI) is the original Windows-based management application, which can be installed on any Windows 2000/XP host on the network. This is being superseded by the EC, but is still distributed as part of the current system. The NFR AI provides administrator access for querying data, viewing alerts, and configuring the Sensor. Multiple Sensors can be managed from a single AI, which communicates directly with the Sentivist Server over an encrypted channel. Each Sentivist system will have one or more Sentivist Sensors, each of which is capable of operating in passive IDS, in-line passive (learning only, no blocking) or in-line IPS (full blocking, fail-open or fail-closed) modes. Configurable response mechanisms determine what action to take when Sentivist Sensor detects an intrusion, including alert generation, data recording, resetting of the TCP session, and changing of firewall rules. Sentivist Sensor is normally delivered as a pre-configured appliance consisting of the appropriate hardware and software combination for each Sensor model. A software-only version is also available. A range of models are available for different deployment scenarios - the model provided for testing was the 100Mbps Sentivist Smart Sensor 100C. This is a 1U rack mount appliance based on standard Intel hardware with a single Xeon processor and 2GB RAM. A large hard disk is used to store the operating system and IPS code (this is no longer stored on CD-ROM during operation as with previous models) and also for local logging of alerts. The device sports a total of four copper Gigabit ports, one of which is dedicated to management. The remaining three ports can be used to monitor a single segment in in-line mode, or three segments in passive IDS mode. It is not possible to configure a mixed mode, with two ports operating in-line and one in passive IDS. The ports provide a hardware bypass capability allowing the Smart Sensor 100C to operate in a fail-closed or fail-open mode when in-line. One feature which is not common amongst the competition is the ability to specify a user-defined maximum latency figure, beyond which the device will cease inspection. Although the device will still not pass packets in fail-closed mode, in conjunction with the fail-open mode of operation this allows the Smart Sensor 100C to temporarily “step out of the way” when overwhelmed by network traffic, thus preventing it from becoming a point of failure in the network (although obviously at the expense of security protection, at the administrator’s choice). There are no additional fault tolerant/High Availability options available at the Sensor level in the current release (although Sensors can fail over to a second Sentivist Server should the first fail, providing resilience at the management level). Sentivist Sensors monitor a particular network for suspicious activity and attacks. These incidents are detected by the Packages and Backends installed and enabled on each Sensor. A Package targets a particular area of concern (for example, Web traffic). Backends are variations within a Package - they target specific types of incidents (for example, attacks against Apache Web servers, attacks against ColdFusion servers, and so on). Some Backends also have Variables that can be customised (for example, the time period used to buffer ColdFusion attacks). When a Sensor detects a possible incident, it generates an alert signature, which includes the name of the Package and Backend (for example, www_coldfusion:buffered_alert) and an alert ID number. At the Sentivist Server level, the alert signature is mapped to an alert type (for example, “Buffered ColdFusion alerts”). The alert type has a corresponding name, priority, and description (known collectively as the alert definition). The alert type also has one or more corresponding alert rules, which tell the Server what action or actions to take. Typically, the alert type has a rule that records the alert to the networklist, one of three default locations in the database (the others are the systemlist, for alerts related to routine system activity, and the auditlist, for alerts related to internal security). Additional alert rules can be used to generate e-mails, display the alert in a pop-up window, send the alert to an external program, and so forth. For ease of administration, similar alert types are organised into alert groups. Through alert groups, alert rules can be associated with multiple alert types at one time. Alerts that are recorded to the networklist can be viewed through an alert browser window. Alerts are viewed through the Sentivist Administration Interface at the Sentivist Server level, or the Enterprise Console at the enterprise level. The Enterprise Server receives alerts from all Sentivist Servers in the system. At this level, a different type of rule (known as a correlator) goes into effect. A correlator tells the Enterprise Server to take action if it detects alerts that fit a specified pattern (for example, 1000 alerts with the same Source IP within two minutes). Two types of correlators are available. Boolean correlators detect alerts that contain specified values (for example, alerts with the Source IP of 10.34.56.8). Cluster correlators detect alerts with the same value in specified fields, regardless of the actual value (for example, alerts with the same destination port). Cluster correlators can be used in conjunction with alert groups (for example, alerts related to Web traffic and protocols). Another dimension that appears at the enterprise level is the site. The site field is typically used to identify Sentivist Servers that are in the same physical location (such as a city and state). It is possible, therefore, to detect alerts that were generated from the same physical location. In addition, site filters can be used to identify and ignore benign traffic from a particular site. All system settings can be configured at the Enterprise level, including Packages and Backends, Variables, alert signature mappings, alert definitions, alert rules, and alert groups. For ease of management, Package, Backend, and Variable settings can be copied from one machine to another. These settings are known collectively as a policy. Furthermore, system components are organised into Policy Groups. Through these Groups, configuration settings can be applied quickly and uniformly throughout the entire system. Backends A Backend is one of the basic components of a Sentivist Sensor, controlling the type of data that is written and how it is recorded. For example, different Backends included gather information about TCP and UDP traffic. Each Backend consists of several components: a Filter, configuration files, and a Recorder.
Note that because security events are defined using N-Code routines, it is possible for end users and administrators to modify the built in “signatures” where required. New signatures can also be written from scratch, and the entire NFR signature library is open to inspection and modification. This makes NFR Sentivist one of the most extensible and flexible IDS/IPS systems on the market. N-Code is compiled on the sensor as packages are deployed from the Sentivist Server in order to make it more efficient. Backends are stored in logical groups called Packages. For example, the Denial of Service Detection Package included with the Sensor includes a variety of Backends that watch for various methods of denying network services. Backends can also share N-Code, which is helpful when there are several Backends that need to process the same data, thus helping to eliminate redundant processing. A large library of signatures is available, and is being enhanced constantly by NFR's Rapid Response Team (RRT). New signatures are placed on a secure NFR support site as soon as they are available and customers are emailed with details of the attack they address and other pertinent information. A secure download process enables administrators to quickly acquire and distribute the new signatures to all Sensors in the organisation via the Sentivist Server and EC. One point worth noting here is that NFR does not wrap all its Backends and Packages in to a single monolithic signature set, and there is no facility to download and install all new and updated signatures in a single operation. Instead, it is up to the administrator to select, download and install each individual Package. Although this can often be a laborious process, NFR maintains that it prefers to allow the administrator to make the final decision on exactly which packages should be downloaded and installed on his system (i.e. why bother downloading the latest batch of IIS signatures if you only use Apache?) - certainly a valid approach, but somewhat contrary to the current “click and forget” philosophy adopted by some vendors in the IPS space. 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 NFR Sentivist Smart Sensor 100C was tested up to 100Mbps, the rated speed of the device, and performance at all levels of our load tests was impeccable, with 100 per cent of all attacks being detected and blocked under all load conditions. We would happily confirm NFR’s 100Mbps rating for this device, and would deem it conservative in most normal networks. The basic latency figures of the NFR Smart Sensor 100C were excellent for a 100Mbps device across the board under all traffic loads. They ranged from 136�s with 25Mbps of 256 byte packets, to 198�s with 100Mbps of 1000 byte packets. Behaviour throughout the tests with no background traffic was consistent and predictable, with small increases as additional network load was applied from 25Mbps to 100Mbps. Placing the device under a half load of 50Mbps of HTTP traffic increased latency slightly, rising from 136�s to 160�s with 256 byte packets, from 155�s to 217�s with 550 byte packets, and from 195�s to 217�s with 1000 byte packets. Given such low latencies, HTTP response times were unusually high with an average of 246ms with 50Mbps of HTTP traffic. The device also had significant problems with our DDOS test, and would perform best when situated behind an attack mitigation device or a firewall with DDOS mitigation capabilities. Latency when under 10Mbps (14800 packets per second) of SYN flood traffic was excessive, although UDP packet loss was minimal. The overall effect on HTTP traffic, however, was an increase in response times and a high number of failed transactions. This is an issue which NFR recognises and is working on at the time of writing. It may be possible to configure the Smart Sensor to perform better in these situations by disabling all notice session-based filters (there were four of these enabled during the test) though we did not verify this and are not sure of the resulting effect on overall protection as a result. Apart from the DDOS issue, the Smart Sensor 100C 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 interface to ISIC-generated traffic had no long-term adverse effect on the device, although communications between the management console and the management server/sensor were intermittent during the attack. Please refer to the Testing Methodology section for full details of the methodology used and complete performance results. We installed one sensor with the latest updates, and enabled all attack/exploit signatures (recorders, audit and policy enforcement signatures were disabled, along with four packages which NFR recommends to be disabled in high performance environments). Out of the box, signature recognition was good at 83 per cent, and was improved to 92 per cent following the application of a signature update after 48 hours. Blocking performance was identical following the update. Performance in our “false negative” tests was adequate out of the box, and improved slightly following the signature update. However, there were still three misses out of the 14 test cases following the signature update, which was unusual given that NFR has a good track record for writing signatures for vulnerabilities rather than exploits. The product also did very well at detecting most of the variants that we include alongside our basic test cases. A major concern in deploying an IPS is the blocking of legitimate traffic. The device failed two test cases in our false positive test suite, and this was reduced to one (fake FireWall-1 RDP traffic) following the signature update. No other false positives were noted during stress testing with either Avalanche traffic or real-world traffic mixes, however. Resistance to known evasion techniques was excellent, with the Smart Sensor 100C achieving a clean sweep across the board in most of our evasion tests. Fragroute and Whisker both failed to deceive the device into ignoring valid attacks, and all of the attempts were decoded accurately. Of the miscellaneous evasion techniques, changing ports on backdoors, inserting spaces into FTP commands and non-text Telnet opcodes in FTP data streams all proved troublesome, but the rest (including extensive RPC record fragging) were handled well. NFR does not provide definitive open connection figures due to the workings of the “pressure system” architecture (see Testing Methodology section for further details) which will see the maximum figure vary depending on current network load. During testing, we verified the Smart Sensor 100C’s ability to handle up to 140,000 simultaneously open connections whilst successfully maintaining state on our half-open exploits. During testing, the default operation of the device was to reject new connections when the state tables were full or resources were low, and this meant that once we exceeded the connection limit the device continued to maintain state on existing connections (thus detecting our half-open exploits), but inevitably, as a consequence, began to block legitimate traffic. This behaviour is not configurable. Unusually, stateless “exploits” are alerted upon by default, and blocked. We do not believe that this is correct behaviour, since it leaves the device vulnerable to Stick and Snot tools (although the traffic would be blocked, of course). It is possible to configure the device to suppress alerts and pass the mid-flow traffic, but our preferred configuration - suppress alerts and block mid-flows - is not possible. Please refer to the Testing Methodology section for full details of the methodology used and complete performance results. This part of the test procedure consists of a subjective evaluation of the features and capabilities of the product, and covers installation, configuration, policy editing, alert handling, and reporting and analysis. Installation of the complete Sentivist system is in several stages, given the number of components to install, but is straightforward. Individual Sensor deployment is very quick and easy. The Sensor is normally provided as an appliance, and a command-line configuration script provides the means to enter initial parameters such as IP address, address of Sentivist Server which will manage the Sensor, pre-shared key for Server communication, time zone, date and time, NTP details, operating mode (passive IDS, inline fail-severed, inline fail-passthrough or inline bridge (where packets are inspected and alerts raised, but no packets are dropped)), and which interfaces are used for monitoring and management. These settings can all be saved to a floppy disk (or created manually in a text editor on floppy) to be used to reinstall the sensor at a later date in “unattended” mode. This also provides the means for administrators to create configuration floppies to be shipped to remote sites for “lights out” installations. Once the Sensor is operational, a real-time monitoring screen is displayed on the console which shows CPU utilisation, packet capture statistics, memory usage, disk usage, and total number of Packages and Backends installed. We would like to see this extended to show current open connections, details of the most recent alerts to be logged locally, and number of alerts currently queued for transmission to the Sentivist Server, all of which could be invaluable in troubleshooting situations. A password-protected screen on the console provides access to a text-based menu allowing modification of all the Sensor parameters set during installation, plus the ability to restart or halt the Sensor. The Sentivist Server and Enterprise Console software are both installed via straightforward scripts from CD onto any RedHat (V9 or Enterprise V3.0) or Solaris (V8 or V9) server which meets the recommended system requirements. The underlying database software is installed automatically if required - MySQL is used for the Server and PostGreSQL for the EC, although the EC will be moved to MySQL also in the near future (an Oracle option is also available). The Enterprise Client is a pure Java-based application which can be installed on any Windows (2000/XP), RedHat (V9 or Enterprise V3.0) or Solaris (V8 or V9) host. Documentation is provided as both hard and soft copy versions, and consists of a Getting Started Guide, Sentivist User Guide and Enterprise Console User Guide. All of the documentation is well written and extremely thorough. On firing up the Enterprise Console (EC) Client, the administrator is presented initially with the Alert Browser window. All of the main management and configuration functions, however, are available from the Management menu option (there is a toolbar and menu bar along the top of the screen). A user name and password is required to log in to the EC, and policy settings control what a particular user can see and do within the Console after successfully logging in. The Enterprise Console displays only the functions and devices that each individual administrator is authorised to use based on the user credentials supplied. Each new user can be created as a Normal user or Administrator. Normal users can view alerts and create views, and if a normal user has permission to restart one or more Sentivist Sensors, that user will also be able to view (but not modify) policy groups. Administrators have complete access to all functions. Check boxes are used to specify if a user is allowed to restart Sensors or interrogate audit information for any Sensor to which he has access. A hierarchical tree display at the bottom of the screen lists all Sites, Servers and Sensors, and check boxes at each level can be used to determine those Sensors to which the user will have access. By selecting a Server, the user is given access to all Sensors reporting to that Server (and any Sensors which are added to that Server in the future). Otherwise, access can be provided to individual Sensors as required.
Enterprise Console has more than 100 built-in alert types related specifically to the security of the Sentivist system. Security-related events are recorded to a special auditlist, which can be displayed if the user has the audit view permission enabled. These events include unauthorised attempts to:
At least one Sentivist Server must be added to the system, and this provides automatic access to all those Sensors which have already been configured to report to that Server. Further granularity of management is provided by the Site, which is used at the EC level to identify Sentivist Servers that are in the same physical location. This allows the administrator to sort alerts by location as well as by Server, and it is possible to create Site Filters to identify and ignore benign traffic from a particular Site. The Package Updater tool is used to check for and import Package updates, which appear regularly on the NFR Package Server. If corporate security policy prohibits direct access to the NFR Package Server, updates can be downloaded separately and applied directly from local files. After updated Packages have been imported, they (and their Backends) can be reviewed and applied or ignored as required. Whenever an update is applied to an installed Package or Backend, the policies for those Sentivist Servers and Sensors on which it is installed will also be updated automatically. Managing database space is accomplished via the Space Management tool, which can be configured to delete automatically the oldest data from all or specific Backends as required. Surprisingly, the concept of Policy has only been introduced to NFR IDS and IPS products with the recent introduction of the EC. However, taking its time in introducing this feature has allowed NFR to observe the competition and create an impressive Policy management system.
NFR has put some thought into making Policy definition as straightforward as possible. It needs to be, since Sentivist is a very complex and flexible system, and the way its signatures are arranged into Packages and Backends, with functionality modified as required by numerous, often cryptic, Variables, means that Policy creation from scratch is not as intuitive as with many other products. A Sentivist Sensor monitors for network exploits based on the Packages and Backends it runs, and these contain the actual code (known as N-Code) that filters and processes events. Each Package monitors the network for a specific category of exploit - the WWW Package, for example, filters Web server traffic. A Package also comprises one or more Backends that monitor the network for specific exploits. WWW Package, for example, has one Backend that watches for attacks against Apache Web servers, and a separate one that watches for attacks against IIS Web servers. A hierarchical tree display lists the Packages at the highest level, followed by the individual Backends, and finally the associated Variables. Selecting any element in the tree brings up a multi-tabbed display on the right where the administrator can choose to use the inherited value (more on inheritance later) or override with a value of his own. Also in the tabbed display are tabs showing the various low-level configuration/description files for the Package or Backend in question, detailed information on what is covered by the Package/Backend, and even the exact N-Code, making this one of the most open systems available (the EC only allows the user to view N-Code, not modify it - N-Code may be added or modified via a separate text editor).
Entire Packages or individual Backends can be enabled/disabled, or installed to/uninstalled from the Sensor, using check boxes within the menu tree. Note also that all alert names, exploit descriptions and severity levels are “soft”, allowing the administrator to rename or redefine them as required. Where the system departs intuitively from other IPS products is that individual “signatures” do not exist as such - in fact, each signature is made up of a snippet of N-Code, and multiple related signatures are rolled into a single Backend. Package and Backend behaviour is then affected by certain Variables that can be modified for each Sentivist Sensor. Variables include IP addresses to ignore (whitelists) or always deny (blacklists), time periods to use for certain processes, maximum lengths of certain usernames, passwords, and commands, and so forth. In some Backends, Variables can also be used to enable or disable individual “signatures” where this is deemed advantageous by the NFR code-writers. Thus, if you wished to disable the “Nimda Scan” signature, it may not be possible to do this via the enabling/disabling of Packages or Backends, or by modifying individual Variables. For this reason, there is no search facility within the Policy editor - there would be no point to it. The power and flexibility to Sentivist Policies is provided by Confidence Modifiers and Inhibit Rules. Every alert raised by Sentivist has a Confidence Level associated with it. This is generated within the N-Code for each signature and is based on the confidence the signature writers have that the alert is accurate and immune to false positives. As the code progresses, what started out as a relatively low Confidence Level may be increased as new factors are determined from the traffic flow (a form of built-in low-level correlation mechanism). A Variable in the Attack/Prevention Backend called IPS Attacks determines which alerts will be blocked when the appliance is in prevention mode based on the Confidence Level. Whole groups of signatures can have blocking enabled or disabled en masse by simply specifying the Confidence Level above which prevention (i.e. blocking the attack) should be enforced. Below the specified levels, an alert is still raised but the attack is no longer blocked.
This feature also allows administrators to set - again at a granular level or en masse - whether a particular type of attack will be mitigated via dropping the session or resetting the connection, and whether that type of attack will result in a temporary black-listing of the source IP. Using the Confidence Modifier Variable, the administrator can override the levels set by the signature writers on a per-signature, per-Backend or per-Package basis, raising or lowering by a set amount as required. Inhibit Rules can then be used to enable or disable recording, alerting and packet capturing (captures can be the trigger packet only, or a set number of packets from the same flow), also on a per-signature, per-Backend or per-Package basis. Each Sentivist Sensor is therefore controlled by the following configuration settings:
These configuration settings are known collectively as a “policy”, and Enterprise Console allows these settings to be copied from one Sensor to another. Furthermore, policies can be applied to multiple Sensors at the same time, through the use of Policy Groups.
A Policy Group is simply a collection of Sentivist Sensors, created for the purpose of applying policies. The group structure determines how the policies are applied, and EC automatically creates two levels of Policy Groups by default:
Depending on requirements, many organisations may be able to manage policies using the default Groups. However, it is possible to create additional sub-Groups under any Server Group. A typical use for this would be to create separate policies for DMZ servers, for Web servers, for critical internal servers, and so on. Once Policy Groups have been created and separate policies defined for each Group, it is simply a matter of cutting and pasting Sensors into the appropriate Policy Group in order to apply the policy to one or more Sensors in a single operation. If at a later date a new policy needs to be applied to an individual Sensor, the Sensor need only be moved to the new Group for that to happen. If the policy needs to be amended for all DMZ sensors, however, all that is necessary is to amend the policy at the DMZ Policy Group level, and it will automatically be rolled out to all Sensors within that Group. It is also possible to cut and paste policies between different Sensors and Policy Groups, if required. Even at the point of policy application, the EC provides a list of all Servers and Sensors which will be affected, allowing the administrator to deselect any of them individually if he does not wish the new policy to be rolled out to specific Sensors. This is all very simple, and very effective - but it gets better. By default, a “child” Policy Group automatically inherits values from its “parent”. A Sentivist Server Policy Group, for example, inherits values from the All Group, and an individual Sensor inherits values from the Server Group (or Server sub-Group) to which it belongs. This is the mechanism by which the administrator can pass down the same configuration settings to multiple Sensors. However, it is also possible to override these inherited configuration values by modifying the policy at a lower level - directly at the Sensor, for example. Where custom values have been defined at lower levels, they can subsequently be overridden again (effectively re-applying an upper-level policy configuration) by selecting a Server Group and clicking on the Pass Down option (which will re-apply the Server Group policy to all Sensors within that Group), or selecting an individual Sensor and clicking on the Inherit option (which will pull down the Group policy to that Sensor only). This system makes policy deployment a snip in even the largest installations. We mentioned earlier in this section that Policy definition can be less than intuitive because of the complex nature of Sentivist. Whilst this may be true to some extent, the default settings provided by NFR are a good place to start, and will probably be adequate for most organisations. The real trick is in getting to grips with which Package/Backend does what, and how the default behaviour can be modified, inhibited or overridden by clever use of the Variables. Once that has been mastered, and coupled with the hierarchical Policy Group and inheritance system, Sentivist offers one of the most powerful and flexible Policy management capabilities on the market today. The Alert Browser is the window that appears the first time the Enterprise Console is opened, and consists of four main areas:
NFR has clearly put some thought into how the Alerts are configured out of the box, and the default configuration should suffice for most needs. Where changes are necessary, they are made easier by the use of Alert Groups.
The behaviour of each alert type is dictated by the alert rules associated with it. The most simple alert rules tell Sentivist Server to record the alert to a list or display the alert in a pop-up window. For ease of management, similar alert types are organised into groups, and through these groups, the administrator can add alert rules to a set of alerts at one time, changing the way that all alerts in the group are processed. Thus, the administrator could decide that all FTP-related alerts should be recorded only in the Recorder, whereas all DOS attacks should be recorded and appear in the EC Alert Browser window. If he subsequently decides that DOS attacks should also send an e-mail, it is a simple matter to add an e-mail rule to the DOS attacks Alert Group, and that action is effected for all alerts in that group immediately. Sentivist Sensors provide the following response options:
Sentivist also boasts Dynamic Worm Mitigation, utilising statistical alert behaviour to identify and automatically quarantine rapidly, self-propagating worms. Applying Rules at group level makes sense in most circumstances, but NFR also allows the administrator to override the Alert Rules on a per-alert basis, if required. Configuration of alert responses has been well implemented in this system. In the Alerts panel, alerts are displayed by Alert ID, with the most recent alerts at the top. By right-clicking on the column headings the administrator can choose the list of columns to display from all the data items stored against each alert in the database:
Once the columns have been selected, they can be reordered by dragging them around the screen, and clicking on any column heading will re-sort the alerts by that column.
If the system receives multiple duplicate alerts at nearly the same time, it automatically combines them into a single alert - this can happen if multiple Sentivist Sensors detect the same incident all at once.) In this case, the number of combined alerts is shown in the Count column. If the main alert pane is scrolling too fast, a Cancel Load button will pause the display to allow further analysis. Alerts can also be dragged into the Held Alerts pane where they can be saved until the end of the current session and analysed at leisure without scrolling. Once an alert or group of alerts has been dealt with or dismissed, they can be marked as read, causing them to disappear from the alert pane (although they naturally remain in the database for subsequent analysis and reporting). Another toolbar button presents the current alert data in five separate panels, one for each priority level. The administrator can scroll through each panel individually. By default, EC displays all alerts received by the Enterprise Server. However, the two filter trees on the left-hand side of the Alert Browser window can be used alone or together to display only the alerts required. The top filter tree (“show only these alerts”) is used to display only those alerts which meet the specified criteria. For example, the administrator could specify that he only wishes to see alerts from one particular site, or only wants to see Web-based alerts.
The bottom filter tree (“alerts to filter out”) is used to specify those alerts that should be hidden or ignored. For example, the administrator could specify that he does not want to see alerts that have already been marked as read, or does not want to see alerts from the DMZ. The system will display all other alerts. In either filter tree, right-clicking on an alert criteria brings up a pop-up dialogue box allowing the criteria to be entered by hand. A quicker way, however, is to right-click on any cell in the main alert pane and select the “filter in” or “filter out” menu option. For example, right-clicking on a particular IP address would allow the administrator to view only alerts from that address, or exclude all alerts from that address. Multiple criteria can be set before clicking the Apply button, and once the administrator is happy with the view it can be saved - this saves all the column settings, layout and filter settings for subsequent recall. When recalling a previously-saved Alert Browser view, each one is opened in a fresh window, and thus as many different views can be open at one time as the administrator can handle (individual views can also be restricted to individual administrators if required). All the set criteria are shown as part of the filter tree, each with a check box against it. Thus it is a simple matter for the administrator to select and deselect individual criteria and observe the effect on the alert display. The filtering capabilities are very simple to use, yet very powerful and useful. Double-clicking on any alert brings up a dialogue box containing all of the alert details (as listed previously) including context data if available (such as the URI which caused the alert), a full description, and detailed help and reference information for the exploit (including impact, possible false positive conditions, CVE/Bugtraq references and remediation information). If packet capture was enabled for the Backend, raw packet data can be viewed within Ethereal by clicking on the Show Raw Packets button. Demonstrating its pedigree in the IDS market place, Sentivist allows the administrator to annotate individual alerts (or groups of alerts), adding related alert IDs, reason for annotation, person responsible, and current status (under investigation, pending, closed, etc.). It is unfortunate that a built-in report is not provided to list outstanding/closed events. The system can also consolidate alerts automatically using correlators. A correlator is an enterprise-level rule that combines multiple alerts that meet certain criteria, and is designed to help the administrator detect patterns among the alerts received.
For example, Enterprise Console can be configured to send itself an additional alert if it receives fifty alerts from the same Source IP within two minutes. Two types of correlators are available:
Annotation and correlation are the types of features which most “new” IPS vendors do not include, since the thinking is that once an alert has been blocked it is no longer necessary to investigate it, and correlation is irrelevant. Given that these devices can also be used in alert-only or passive IDS mode, however, we think these are features worth having. In addition to the Alert Browser window, Enterprise Console provides the ability to view the Alert History (alerts which appeared within a user-specified time period), a Timeline window and three different types of real-time graphs:
It is possible to print, save, and modify all of these graphs. In the very useful Timeline display, alerts are plotted graphically on a moving “time line”, each represented by the corresponding priority colour. Scroll buttons at the top of the window can be used to move backward and forwards along the timeline, and the Resolution drop-down list can be used to set the time intervals, providing either a high-level view of the recent days/hours of activity, or a more focussed view on the last minute or ten seconds.
When a larger period of time is being viewed, it is useful to be able to cluster the alerts, which replaces the confusing bunching of dots representing individual alerts with more readable miniature pie-charts, each section of the pie representing totals of alerts grouped by priority. Double clicking on any of the individual or clustered alerts launches a new Alert Browser window with the appropriate time filter in place to show just those alerts. If only a single line of all alerts was available, this feature would be nothing more than a graphical gimmick. However, the administrator can create as many additional time lines as required, and a separate include/exclude filter can be applied to each line. Thus, it is possible to create a comprehensive real-time display of all alerts for specific groups of servers, for specific alerts, for inbound traffic only, for outbound traffic only, for Web traffic only, and so on. When configured to monitor the most critical servers for the most serious alerts, the constantly scrolling graphical nature of this eye-catching display makes it incredibly useful as a high-level immediate insight into what is happening on the network. Most analysis will be performed using the wide range of alert handling tools described in the previous section. For those who wish to dig deeper into the alert data stored in the SQL repository, the schema is fully open. In addition to the simple text-based SQL Query tool provided as part of EC, Sentivist provides a number of reports that can be generated through Crystal Reports from Business Objects (a separate Crystal Reports license must be purchased in order to do this, however). Sentivist includes over 40 completely customisable Crystal Report Templates, including:
A number of trending/comparison charts are also provided in the form of fully customisable Crystal Report Templates. These include:
Naturally, any number of completely custom reports can also be created via Crystal Reports. Performance The NFR Sentivist Smart Sensor 100C was tested up to 100Mbps, the rated speed of the device, and performance at all levels of our load tests was impeccable, with 100 per cent of all attacks being detected and blocked under all load conditions. We would happily confirm NFR’s 100Mbps rating for this device, and would deem it conservative in most normal networks. The basic latency figures of the NFR Smart Sensor 100C were excellent for a 100Mbps device across the board under all traffic loads. Behaviour throughout the tests with no background traffic was consistent and predictable, with small increases as additional network load was applied from 25Mbps to 100Mbps. HTTP response times were unusually high, however. The device also had significant problems with our DDOS test, and would perform best when situated behind an attack mitigation device or a firewall with DDOS mitigation capabilities. The Smart Sensor 100C performed consistently and completely reliably throughout our tests, blocking 100 per cent of attack traffic whilst passing 100 per cent of legitimate traffic, and exposing the sensor interface to ISIC-generated traffic had no long-term adverse effect on the device. Security Effectiveness Out of the box, signature recognition was good at 83 per cent, and was improved to 92 per cent following the application of a signature update after 48 hours. Blocking performance was identical following the update. Of course, the real advantage of Sentivist is the fact that if there is a signature lacking, or one that does not work quite as you would expect, you can modify existing signatures or create custom ones using the N-Code programming language. As with any programming language, N-Code requires time and effort to master, but as a “cross” between C++ and Perl it will feel instantly familiar to exponents of either, and anyone with any programming aptitude at all should be able to get to grips with it in a reasonable amount of time (training is available from NFR). Whilst mastering N-Code is by no means essential to successful operation of the Sentivist system, it does make it one of the most customisable and extensible of all the products we have reviewed. Beware, however - such power can come at a price, since a poorly written piece of N-Code could significantly impact the performance of the sensor. Performance in our “false negative” tests was adequate out of the box, and improved slightly following the signature update. The product also did very well at detecting most of the variants that we include alongside our basic test cases. The device failed two test cases in our false positive test suite, and this was reduced to one (fake FireWall-1 RDP traffic) following the signature update. However, no other false positives were noted during stress testing with either Avalanche traffic or real-world traffic mixes. Resistance to known evasion techniques was excellent, with the Smart Sensor 100C achieving a clean sweep across the board in most of our evasion tests. Fragroute and Whisker both failed to deceive the device into ignoring valid attacks, and all of the attempts were decoded accurately. Most of the miscellaneous evasion techniques (including extensive RPC record fragging) were handled well. During testing, we verified the Smart Sensor 100C’s ability to handle up to 140,000 simultaneously open connections whilst successfully maintaining state on our half-open exploits. Unusually, stateless “exploits” are alerted upon by default, and blocked. This is configurable, although our preferred configuration - suppress alerts and block mid-flows - was not possible (NFR state that it could be achieved via the use of additional N-Code and a filter, however). Usability Our main criticism of the management system comes down to cost. Since no management software is included at all with any Sensor, the minimum cost to be added to the Sensor price is $10,000 for the entry-level management license. On top of this, it is necessary to purchase a Crystal Reports license. We would prefer to see some form of direct, single-sensor management capability included out of the box, and then an additional charge for managing multiple Sensors via a central console. It should also be possible to run at least some basic reports without having to purchase a full-blown Crystal Reports license. Given the extremely attractive prices of the Sensors themselves, this approach would offer a much more realistic entry-level cost for a basic system. Having said that, there is not much left to criticise as far as management and usability goes. The three-tier management system is extremely powerful and scalable, and built-in management failover is provided via the ability to specify multiple Sentivist Servers for each Sensor to report to. The user roles are granular enough to suit most organisations, making the system very secure, and the Sensor can be deployed in passive IDS or in-line IPS (fail-open or fail-closed) modes. Policy management has been extremely well thought out, with the ability to define multiple Policy Groups and drag and drop Sensors between those groups to apply policies. Additional flexibility is provided by the concept of inheritance, which allows certain parameters to be designed at a corporate or group level, whilst others are overridden on an individual Sensor basis. Whilst policy definition may seem daunting initially, the use of Variables, Alert Groups, Confidence Levels and “modifiers” to override those Confidence Levels on a per-Package, per-Backend and per-Signature level makes this one of the most flexible and powerful policy definition systems we have seen. An added advantage for some organisations will undoubtedly be the use of N-Code for writing signatures, the ability to write your own Packages/Backends using that same language, and the fact the entire NFR library of Packages and Backends is completely open to inspection and modification. Alert handling is similarly well-specified and well-implemented. The ability to launch multiple Alert Browser windows each with unique include/exclude filters, and to save them along with customised column layout, is very useful. Plenty of detail is available with each alert, including context information (where applicable) and raw packet captures. Filtering is fast and easy to do (either long hand or via right clicking on individual data items in the Alert Browser window), and the only feature missing at the moment is the ability to “roll up” groups of alerts into summary lines with totals - a feature which is planned for V5.0. Reporting is well catered for too via numerous Crystal Reports templates, and the database schemas are completely open for those who wish to construct their own reports or feed them into third party event management/analysis systems. All in all, both alert handling and reporting are extremely well-specified and well-implemented. Company
name: NFR Security, Inc.. Click
here
to return to the NFR questionnaire |
Send mail to webmaster
with questions or
|