NFR Sentivist Smart Sensor V1.3

Is the product supplied as software only or as a hardware appliance? If supplied as an appliance, please provide the hardware specification (CPU, memory, network cards, etc)
Sentivist is available as an appliance and also in SW-only form for those customers who choose to source their own hardware. For the NSS test, Sentivist Smart Sensor 100C was supplied as an appliance.  The HW specification for the Smart Sensor 100C is as follows: 

-           1 x Intel SR1300 1U Server Chassis

-           1 x Intel SR1300 SCSI Backplane

-           1 x Intel SE7501WV2 Motherboard (SCSI variant)

-           1 x Intel Xeon Processor

-           2 x 1 Gbyte registered ECC DDR266 compliant low profile DIMM (2 Gbytes Total Memory)

-           1 x 36 Gbyte Seagate Cheetah 15k RPM SCSI Disk

-           1 x Interface Masters Niagara 2261 Dual Copper NIC with Integrated Bypass Capabilities

-           1 x Intel SR1300 CDROM/Floppy Drive Combo Module

-           1 x SR1300 Bracket Mounting Kit 

Does sensor work in-line only, or can it support passive monitoring of switch SPAN port too? If passive monitoring is supported, what is the maximum number of ports that can be monitored by a single sensor?
Sentivist Smart Sensors can be deployed any one of three ways.  First, they can be deployed in standard intrusion detection mode off a SPAN port or TAP in pure monitoring mode.  Second, in inline passive mode, also called “learning mode” whereby all suspicious traffic is alerted and traffic that would have been prevented in full inline mode, is flagged to the Sentivist Alert Console.  Third, Smart Sensors can be deployed in full inline intrusion prevention mode whereby attack traffic is blocked inline.  This multi-mode deployment gives users tremendous flexibility in deploying network security according to profile of their network and the priorities of their business. 

What is the maximum number of in-line connections (port pairs) that can be monitored by a single sensor?
Sentivist Smart Sensor 100C monitors a single network. 

What type (copper/fibre) and speed of network connection are supported by the sensor (include default configuration plus any options)?
Sentivist Smart Sensor 100C default configuration includes 4 10/100 copper interfaces. 

What High Availability (HA) features are built in to the product by default?
Sentivist Smart Sensors are designed to be able to fail over to a secondary Sentivist Server.  Specifically, at configuration time, Sentivist Smart Sensors report to a primary Sentivist Server which houses the Alert database.  Should that Sentivist Server go down for some reason, the Sentivist Smart Sensor will automatically failover and begin reporting to a secondary Sentivist Server thus real time alerting and reporting functionality continues un-interrupted. 

Further, Sentivist Servers are run on Highly Available hardware with recommended configurations that include RAID 10 and redundant power supplies. 

What High Availability (HA) features are available as extra cost options?
The high-end of the Sentivist sensor family, the Smart Sensor 500C which is an inline data rate of 500Mbps, Smart Sensor 1000C which is an inline data rate of 1G and the Smart Sensor 2000 which is an inline data rate of 2G all possess HA features.  These Smart Sensors are due to be delivered in Q32005 and possess dual power supplies, disk drives, interface cards as well as a redundancy option with A/A and A/S failover modes.    

What is the maximum speed/network load (Mbps) claimed with zero packet loss and without blocking legitimate traffic?
Sentivist Smart Sensor 100C delivers guaranteed 100Mbps of intrusion prevention data rates.  Internal tests with real world mixed traffic delivered data rates as high as 180Mbps. 

At the maximum load, what is the maximum TCP connection rate through the device (connections per second) claimed?
In a network with low-intensity traffic, Sentivist Smart Sensor 100C can handle approximately 500,000 simultaneous resident connections.  A network with a more typical traffic load, Sentivist Smart Sensor 100C can handle 5,000 - 10,000 connections per second before beginning to impact latency. 

What is the average latency claimed through the device (and at what load)?
The average latency for Sentivist Smart Sensor 100C conducting deep packet inspection and signature-based packet processing is typically between 40us and 1 ms. 

Additionally, Sentivist Smart Sensors allow Security Managers to configure a maximum acceptable latency.  When that threshold is surpassed, the sensor handles traffic according to the security policy defined by the Security Manager. 

Management architecture (2-tier/3-tier management? Brief description)
The Sentivist architecture supports small deployments and easily scales to support large enterprise deployments with centralized management and a unified view of data.  The two-tier architecture of the Sentivist client (formal name Sentivist Protection Center) and the Sentivist Server support small deployments and the three-tier architecture of the Sentivist client, Sentivist Enterprise Server and Sentivist Server provide the scaling and centralized data to support large enterprise deployments. 

What are the minimum/recommended sensor OS and hardware requirements? Is a dedicated machine required/recommended?
The Sentivist Smart Sensor OS is proprietary and since Smart Sensors are available as hardened appliances, customers are not required to maintain the OSs on each of their sensors. NFR’s Smart Sensor hw is a single 2.8Ghz processor with 2GB RAM.  All performance tests are based on this product spec.   

What are the minimum/recommended console OS and hardware requirements? Is a dedicated machine required/recommended?
The Sentivist Protection Center (client) can be installed on a typical office desktop or laptop computer running Windows, RedHat Linux or Sun Solaris. 

What are the minimum/recommended management server OS and hardware requirements (if applicable)? Is a dedicated machine required/recommended?
Sentivist Enterprise Server and Sentivist Server HW and OS recommended requirements: 

OS Requirements

�          Redhat 9 or Enterprise Linux 3 (ES/AS)

�          Solaris 8 or 9

 HW Requirements

�          X86 configuration

o          2 x 3 Ghz or faster Intel Xeon processor

o          4Gbytes RAM

o          Minimum of four SCSI drives in a hardware RAID 0+1, 1+0 or 10 configuration (minimum 80   
       Gbytes usable)

o          10/100/1000 Ethernet network interface 

�          Sun SPARC configuration

o          2 x 600 Mhz or faster SPARC processors

o          8 Gbytes of RAM

o          Minimum of four SCSI drives in a hardware RAID 0+1, 1+0 or 10 configuration (minimum 80Gbytes
       usable)

o          10/100/1000 Ethernet network interface 

Yes, a dedicated machine is recommended. 

List required open ports on sensor and their use
Sentivist Smart Sensors require port TCP/1968 for communications from the Sentivist Server. 

List required open ports on management server (if applicable) and their use
Sentivist Server requires the following ports:

�          TCP/1968 for communications from Sentivist Smart Sensors

�          TCP/2010 for communication from the Sentivist client (Protection Center)

�          TCP/45678 for communication from the Sentivist Enterprise Server 

Sentivist Enterprise Server requires the following ports:

�          TCP/5432 for DB/PostgreSQL access (default database)

�          TCP/2848 for DB/Oracle access or 

List required open ports on GUI/management console and their use
The Sentivist Protection Center (client) does not require open ports.  The Protection Center communicates to the server via 2848 or 5432, depending on database choice. 

Communication protocol between sensor and management server
A proprietary, NFR Security developed protocol is used. 

Communication protocol between management server and GUI/console
A proprietary, NFR Security developed protocol is used. 

Encryption between sensor and management server
AES, CFB Mode, 128 bit keys 

Encryption between management server and GUI/console
Encryption between the Sentivist client and the Sentivist Enterprise Server is SSL encryption (128 by default). 

Once deployed and configured, can sensors be managed from a central console?
Scalability and centralized management is a key strength of Sentivist.  The Sentivist architecture is designed specifically to support centralized management and a single unified view of data for any size network deployment.  An entire enterprise deployment can be managed from a single Sentivist laptop client to define and push policy to all Smart Sensors, receive alerts and generate reports.   

Capacity of the system? How many endpoints can be monitored? Ratio of endpoints to management servers/consoles, etc.
Sentivist can manage large scale enterprise deployments with an unlimited number of endpoints.  The number of Smart Sensors the Sentivist Server can manage is dependent on the network traffic load and traffic type.  The standard ratio for a high-use, mixed traffic network is ten Smart Sensors per Sentivist Server, but varies from deployment to deployment. 

Thus Smart Sensors in groups of ten report to Sentivist Servers which report to the Sentivist Enterprise Server.  The Enterprise Server provides the central management point and unified view of data for centralized management and single point of control.  

                                                     Sentivist Client

                                                                /

                                         Sentivist Enterprise Server

                                                     /                       /

                                                     /                       /

                             Sentivist Server-1……Sentivist Server-N

                             /                       /                       /                       /

                             /                       /                       /                       /

     Smart Sensor-1…………SS-N           SS-1………….SS-N

How many management consoles can be actively logged in to the management server at the same time?
Sentivist supports multiple, concurrent management sessions and does not have a fixed limit to the number of Sentivist clients that can be logged in concurrently.  There is no default timeout. 

What anti-flooding methods are employed (sensor to management server, and management server to console)?
Sentivist Smart Sensors utilize Alert Flood Suppression to consolidate like alerts into a single alert notification to the Sentivist Server.  Alert counts are maintained and communicated forward to ultimately be displayed on the Sentivist Alert Console.  So for example, if a Smart Sensor were to suddenly see a flood of anomalous traffic, triggering the “nonsense” alert, once the number of “nonsense” alerts hit a user-definable threshold (default being 200 in 5 minutes ) the sensor would stop sending the flood of  “nonsense” alerts.  It would instead, count the “nonsense” alerts, and then send a single alert, telling the end user that they had nnn “nonsense” alerts in the last n minutes.  When the flood was over, a final alert would be generated, informing the end user of the total alert count from the flood. 

An additional anti-flood system is called Alert Consolidation.  On the Sentivist client, when duplicate alerts, from/to the same IP addresses appear in a 3 minute moving window, those alerts are not displayed separately.  Instead, a counter is incremented next to the original alert.  The end user can then drill down into that alert to see all the consolidated alerts.  This helps display more information on the end users screen at a given point in time. 

Maximum insertion rate into alerts database
Maximum database insertion rate at the Sentivist Enterprise Server is 1000 alerts per minute.  This number can be increased by using faster hardware, but this number was achieved using the standard recommended server hardware configuration. 

Maximum size of database
Though there is no set maximum, NFR Security’s recommended maximum is 40GB using postgreSQL.

Maximum number of alerts stored
With an average Alert record size of 1k, the maximum number of Alerts is approx 40 million. 

What happens to alerts in main alert database once capacity limits exceeded (deleted/archived/etc)
On the Sentivist Server, the oldest events are purged first.  Security Manager’s can specify a preference to retain certain types of records longer than others, and the purging process honors these preferences, unless more space is required to operate. 

What is maximum recommended size of alerts database to maintain acceptable query performance?
As per the second prior question, approx 40 million. 

When alerts are removed from main alert database, are they still available for reporting directly (i.e. can reporting tools merge current and archived alerts)
On the Sentivist Enterprise Server, Security Managers can export their alert data for long-term storage and data mining, trending and reporting. 

Which database product is used for alert storage? Is schema open?
On the Sentivist Enterprise Console Server, postgreSQL is used, with an open schema. 

What happens when communications between sensor and management server/console are interrupted? Local logging on sensor? Maximum capacity? What happens when local sensor logs are full? Is the local repository secure?
When communications between the Sentivist Server and Sentivist Smart Sensors is severed, data will accumulate until disk space is exhausted at which time new data will be dropped.  There is also an option to purge old data on the Smart Sensor.  The current hard drive shipped with the Sensor is a 36GB drive.  Theoretically, this could be months worth of data (millions of records).  The data is on a local subsystem with no UNIX services or shell.  Somebody would need to physically remove the hard drive and mount it on a separate machine, then figure out our hashing algorhythm to read the data. 

Secure logon for policy management?
Yes.  Policy is defined, deployed and managed through the Sentivist client which requires password protected logon access.  Further, traffic between components is encrypted. 

Granular access (i.e. read only/read-write/etc) granted on a per-user basis? What levels of granularity are supported (i.e. is it possible to restrict user access to specific parts of the management console, to specific appliances, etc.)?
Yes, Sentivist supports granular access controls.  Users can be given Admin access (which is the ability to view and configure everything), or they can be restricted to various alert views.  For example, Joe SOC person can only view alerts;  Jane web admin, can only view alerts from the sensor in the web DMZ, etc. 

Is it possible to define multiple policies for the sole purpose of distributing to multiple sensors with different functions?
Yes.  Sentivist Smart Sensors can be grouped together and then managed by that group.  You can create subgroups as well.  For example, you might put all your DMZ sensors in the DMZ group.  You might put your internal userland sensors in the USERLAND group.  You might create a location group called US, and another called EU, and then create subgroups under each of those called DMZ and USERLAND, and then places sensors in those groups.  Sensors can be told to inherit policy settings from groups above them, or they can override a group setting.  A change can be made to a policy at the top, and that policy (or a portion of that policy) can be pushed down to every group/subgroup/sensor in the policy tree.   Policy definition and deployment is very hierarchical. 

How are policies distributed to sensors?
Sentivist policy distribution is very simple.  The user defines the policy via the Policy Manager function of the Sentivist client software.  After the user makes all the wanted changes, they click OK, and the policy is pushed to the Smart Sensors and the Smart Sensors respond with a message confirming the policy has been received and implemented. 

Can policies be deployed on a per-port, per-sensor or per-group basis, or globally only?
Policies can be deployed globally, per-group, or per-sensor.  They can not be deployed on a per-port basis.  The current Sentivist Smart Sensor 100 and 500 support a single port pair.  Sentivist MG Smart Sensors, planned to be available in Q32005, will have multiple port pairs per sensor, and per-port policies should be available at that point. 

How are policy changes handled? Will the central console detect which sensors are using a changed policy and redeploy automatically, or does the administrator have to do this manually?
Sentivist handles policy centrally and top down.  Sentivist allows policy definition and deployment by sensor group, thus Sentivist will not automatically redeploy policy to ensure policy consistency across all Smart Sensors. 

Can policy deployment be scheduled?
Not at this time. 

Does the sensor remain able to detect alerts at all times during policy/signature updates? If so, explain how this is achieved. If not, for how long is it inactive, and does the sensor block all or pass all traffic whilst inactive?
Yes.  Upon receiving policy updates, Sentivist Smart Sensors continue to operate while preparing the new policy for deployment.  When Smart Sensors deploy new policy, pause and queue incoming traffic until the deployment update is complete and then the Smart Sensor resumes traffic analysis.  The Smart Sensor is never inactive but rather paused for a split second. 

Can the administrator define custom attack signatures?
Yes.  Creating a new signature is point and click.  Users can enter strings into user definable variables to create new signatures for various protocols.  For example, to alert on the word “hackers” in an SMTP subject line is as simple as adding that string to the subject line variable in the SMTP package.   

For protocols not monitored by Sentivist, customers can create their own protocol decoders to fully decode that protocol.  Using Sentivist’s custom signature language, N-code, Security Managers can write their own signatures as well as modify signatures produced by NFR Security.  N-Code is an open language similar to perl.  The N-Code development environment is distributed for free and includes a test compiler and a light-weight virtual machine.  This allows customers to develop and test custom signatures against real traffic without having to purchase another Sentivist solely for this purpose.   NFR teaches a two-day class on N-Code and at the end of the class, they write a protocol decoder to monitor the “Chess Rally 2” game and alert on checkmates and bad words used in the chatrooms. 

Regex supported when creating custom signatures?
Yes.  A customer can do anything with NFR Security’s N-Code signature language, including regex.  In the user defined “point and click” variables, this is not an option currently. 

How are new vendor attack signatures obtained and deployed?
NFR Security signatures are available on the NFR Security Package Server and the NFR Security Support Web Site.  Both sites are updated daily with the latest signatures and protection information.  Customers who configure their Enterprise Console Client to have direct Internet connectivity can connect to the NFR Security Package Server to access the latest signatures.

Otherwise, via their web browser, customers can access the latest signatures from the NFR Security Support Web Site.  Also, signatures can be delivered on a CD as some of our customers occasionally request. 

Once received, signatures (and other updates) can be distributed and deployed to Smart Sensors worldwide from the Sentivist Enterprise Console (single, central console).

Frequency of signature updates?
NFR Security signatures are updated immediately upon the creation of new signatures, which is usually daily.  Other signatures, such as protection for emerging applications like Instant Messaging (IM) and VoIP are added to the product line as they are developed. 

What infrastructure does the vendor have behind the signature update process (i.e. dedicated team of engineers? How many? Does it have a name?)
NFR Security has a dedicated signature team called the Rapid Response Team that is comprised of a team of engineers with an average of 20 years experience in network security.  The team is constantly monitoring multiple mediums worldwide for clues and evidence of new threats and produces new signatures, vulnerability signatures and other services to protect NFR Security’s customers against these rising exploits. 

Can one signature update file be downloaded to the local network and used to update all sensors from a central location, or is it necessary to initiate a live connection to the Internet download server for each sensor/management server?
A key strength of Sentivist is its powerful centralized management functions.  All management and control functions are available via the Sentivist client, including the ability to manage signature updates and deployments. 

Can signature updates be scheduled and fully automated? Is automated download AND deployment to sensors supported, or just download (or neither)?
Not with current release. With the delivery of Sentivist 5.0 in Q32005, customers can configure Sentivist to automatically download new signatures immediately upon their availability.  Automation of the update can not be scheduled in the current release.   

What network protocols are analysed?
Sentivist analyses the following protocols:

DHCP
DNS
Finger
FTP
HTTP(S)
ICMP
IMAP
IP
IRC
LPD
MS-RPC
MSSQL
NNTP
ORACLE
POP
RADIUS
RLOGIN
RPC
RSH
SIP
SMB
SMTP
SNMP
TCP
Telnet
TFTP
UDP
WINS
Various P2P & IM 

What application-level protocols are analysed?
See above. 

Can the product perform protocol decodes?
Yes.  Everything listed above is a decoded (analyzed) protocol. 

Can the product perform protocol anomaly detection?
Yes, all protocol engines contain anomaly detection. 

Can sensor support both normal and asymmetric network configurations?
Sentivist Smart Sensors in inlne IPS mode must see symmetric traffic to function correctly.  It is a stateful device.   Smart Sensors in IDS mode can aggregate several feeds to create symmetry, but the IPS device requires state to be present on a single line. 

Is the detection engine “stateful”? If so, please explain how this works.
Yes.  All analysis is done on fully reassembled connections.  The Smart Sensor can deduce state in the case of a cold-start with connections that existed before the sensor was booted.  The sensor can also resynchronize its internal state when routes flap and some packets took a different route to the end host than through the sensor. 

If stateful - how many open connections can be tracked? Is this value configurable?
Sentivist does not have a hard limit.  It is dependent on the amount of memory in the box.  On a typical network, the Sentivist Smart Sensor 100 will sustain between 5000-10,000 connections per second.   When it runs out of memory, connections are randomly discarded. 

If stateful - for how long are partially opened connections tracked? Is this configurable?
Sentivist Smart Sensors will track partially open connections until the sensor runs low on memory.  When memory does runs low, it drops partially open connections. 

If stateful - for how long are fully opened connections tracked if not used? Is this configurable?
When Smart Sensors run out of memory, connections are randomly discarded. 

What is the default action when system resources run low or state tables are filled - block or permit all new connections? Is this default action configurable?
The Security Manager can define the Smart Sensor’s default action to either permit or block all new connections.  

What is the default action when power fails or the system is powered down - block or permit all traffic? Is this default action configurable?
Sentivist Smart Sensors have an inherent network bypass capability that allows users to select the failure mode that fits their security policy.  The configurable options are for the device to fail unsevered (open) or severed (closed). 

What is the default action when the sensor is unavailable for any length of time (i.e. during policy download or software update - block or permit all traffic? Is this default action configurable?
Sentivist Smart Sensors default action corresponds to the default failure configuration as described in the prior question.

Will the detection engine block/alert on ALL suspicious activity, or only when an attack is made against a vulnerable server? If so, please explain in detail how this works. Can this behaviour be modified (i.e. to alert on ALL attacks if required)?
Sentivist offers multiple levels of protection and enforcement.  By default, Smart Sensors will alert on all suspicious activity and Sentivist’s patent-pending Confidence Indexing allows security mangers to define what types of suspicious traffic will be blocked at each location on the network.  The confidence index of a detected event is the system’s level of confidence that the event in question is an attack.  This allows Security Managers to implement prevention policy according to the business value of the service being protected.  For example, on a public information segment, the Security Manager may choose to block all suspicious traffic that have a confidence level of 90% or greater while a segment housing critical business information requires a more stringent level of prevention and thus the Security Manager would block all suspicious traffic with a confidence level of 75% or greater. 

Are server responses monitored and alerted/blocked? Does this have an impact on performance?
Yes.  This is required to catch various client side exploits, such as the GDI exploits against windows clients browsing the web. There is an impact on performance. 

Ability to monitor user-defined connections (i.e. report on an FTP connection to a specific server?)
Yes.  For example, by default Sentivist monitors all FTP connections, but if the user only wants to monitor a particular server or set of servers, that is also possible.   

Detect/block network-level packet based attacks?
Yes.  Sentivist will detect and block network-level packet based attacks. 

Detect/block all types of port scans (full connect, SYN stealth, FIN stealth, UDP)?
Yes.  Sentivist will detect all types of port scans.  Most scans can be blocked after an initial scan period. 

Detect/block SYN floods? Manual or automatic thresholds? Configurable? How is SYN flood protection implemented?
Yes.  Sentivist will detect SYN floods with default thresholds that are configurable by the user. No mitigation/protection, however. 

Perform packet/stream reassembly?
Yes. 

Perform deobfuscation?
Yes, Smart Sensors do a dehex and deutf8 on all files (such as a url). 

Is all traffic scrubbed/normalised/reordered as it passes through the sensor?
Yes.  Sentivist Smart Sensors normalize and scrub all TCP segmentation and IP fragmentation traffic. 

How is fragmented traffic handled by the sensor?
Fragmented traffic is buffered (but not beyond the configured max latency, default of 15 milliseconds) and re-assembled based on the fingerprinted OS of the destination IP address.  NFR Security’s Sentivist is still the only IPS/IDS product to use dynamic real-time OS Fingerprinting to properly re-assemble fragmented packets. 

List all prevention features available (alert only, drop packets, block TCP session)
Sentivist and Sentivist Smart Sensors use the following techniques:

o          Drop only

o          Pass and Track

o          Pass and Alert

o          Alert only

o          Drop packets

o          Block TCP sessions

o          Blacklisting 

List any other security features available (bandwidth shaping, rate limiting, etc.)
Sentivist offers: 

o          Meta Alert Correlation is a higher level of attack intelligence by correlating topologically discrete events that are otherwise similar, such as the Source IP address, and flags the alert set as a single higher severity Correlated Alert on the Sentivist Alert Console. 

o          Sentivist Dynamic Worm Mitigation utilizes statistical alert behaviour to identify and automatically quarantine rapidly, self-propagating 0-Day worms.  The ability to recognize these harmful 0-Day threats is critical to halting their rapid and damaging proliferation with the network. 

Packet capture capabilities? Only the trigger packet, or before and after? How are packet captures stored/viewed?
Yes.  Sentivist captures the triggering packet as well as subsequent packets (to a user-configurable threshold).  Packets are stored in the database, and viewed via ethereal. 

Do you track and display context data as part of each alert (i.e. for an FTP overflow, do you show which user name/password combination was used to login to the FTP server, etc?). If so, how much context data is available?
Yes, in some cases.  Not all alerts will have contextual data.  For the example in the question, Sentivist will record the username/password, and store it in a separate table for retrieval upon request. 

Option to record entire sessions for “forensic” investigation? Where is this data stored? How is it secured from tampering?
Yes.  If the user-configurable threshold is set to a high number of packets, Sentivist will store the entire session.   

Reporting from sensor to console - range of alert response options (detail these, i.e. log, alert, e-mail, pager, packet capture, etc)
Yes, Sentivist supports a variety of notification methods including:

o          Log

o          Email

o          Packet capture

o          Pager

o          SEMs including ArcSite, Intellitactics, NetForensics, among others.

o          SNMP

o          Syslog

o          anything that the Security Administrator can think of via the generic alerting mechanism. 

Can alert response options be set only at a global policy level, only at individual signature level, or to groups of signatures (or a mixture of all three)?
Sentivist alert responses can be global, by signature group, or per individual signature.

Can alerts be reported to the central console in real time without the use of third party software? How easy is it to filter and extract individual events?
Yes.  All alert and prevention activity from Smart Sensors are reported to the Sentivist centralized console, the Sentivist Protection Center.  The console displays three types of alerts, basic alert, correlated alerts and prevented alerts.  Security Managers can define filters to further customize the information that is displayed on the console and with simple point and click can isolate and drill down to the details of a particular alert.   

Can alerts from all sensors be viewed at a single console at the same time (i.e. without having to connect to separate sensors from the console)?
Yes.  Sentivist delivers centralized management, including a single a unified view of data from the smallest to the largest enterprise deployments of hundreds of Smart Sensors.  

Can the central console correlate alerts from multiple sensors (i.e. not just display alerts from multiple sensors, but attempt to infer a connection between different alerts on different sensors)? IS this offered as standard or extra-cost option?
Yes.  Sentivist includes Meta-Alert Correlation whereby Sentivist correlates topologically discrete but otherwise similar events and displays them on the Alert Console as higher severity Correlated Alerts.  This function gives Security Managers real-time insight into exploit attempts across their network that would otherwise take extensive log research to discover.   

Sentivist 5.0 which will be released in Q3 2005, further leverages Meta-Alert Correlation intelligence to Dynamically Shield against continued random exploit attempts from the same source IP address.  

Can alerts be correlated manually by the administrator - grouped together in the database as a single event for further investigation?
Yes.  Sentivist management console enables Security Managers to organize, sort and group alerts to manually investigate attack trends and activity. 

Can alerts/events be annotated and tracked for investigation by multiple administrators/investigators?
Yes. 

Does the software offer advice on preventative action to ensure the attack does not happen again?
Yes.  Sentivist Alert Details describe the alert, the impact of the alert impact, the vulnerability, and preventative action the customer can take to ensure the attack does not re-occur.  

What industry standards are supported - Intrusion Detection Exchange Format working group (IDWG), Intrusion Alert Protocol (IAP), Intrusion Detection Message Exchange Format (IDMEF), IDXP - and in what way?
Sentivist is CVE compliant. 

Which third party event correlation systems are supported and in what way?
Sentivist integrates with a number of third party event correlation products.  Sentivist alert information can be received by CA UniCenter, HP OpenView, IBM Tivoli, ArcSite, Intellitactics, NetForensics, Tenable and Symantec’s Universal Event Collector. 

Integration with other scanning/IDS/prevention products?
Sentivist 5.0 planned for delivery in Q32005 will receive the scan output file from Nessus, an open source network scanner sponsored by Tenable Security.  Sentivist will use this data to build network intelligence to offer Security Managers network service information, vulnerability information and correlated asset-vulnerability-attack information.  Further, Sentivist Dynamic Shielding will utilize the network intelligence to shield against new vulnerabilities introduced by network change and generic vulnerabilities in the network. 

Log file maintenance - automatic rotation, archiving, reporting from archived logs, etc.
The Sentivist log database will auto-purge itself when it approaches the maximum size threshold by deleting the oldest records first, to bring the database size down to an acceptable level. 

Management reporting - range of reports/custom reports/how easy is it to filter and extract detail? Different reports for technicians and management/end users?
Sentivist includes over 40 completely customizable Crystal Report Templates.  These include:

�          Top/Bottom Alerts

�          Top/Bottom Source/Dest IPs

�          Top/Bottom Source/Dest Ports

�          Top/Bottom Services

�          Top/Bottom Sensors 

All Sentivist reports can be customized to analyze a subset of the data.  For example, the “Top N Alerts” could actually be “Top 10 Alerts, against port 80, against my DMZ range of IP addresses, from the China netblock, for the last 30 days”.  In addition, Sentivist contains a point and click management that highlights from all the Tops, as well as a general risk distribution. 

Are trend/comparison reports available?
Yes.  Sentivist includes a set of trending/comparison charts in the form of fully customizable Crystal Report Templates.  These include:

�          Alerts by Date

�          Alerts by Day of Week

�          Alerts by Time of Day

�          Alerts by Month

�          Alerts by Service

�          Alerts by Priority

�          Among others 

As an example, “Alerts by Day of Week”, can be run for the most recent six month period.  This information would tell the Security Manager which days of the week his network is attacked the most. 

All Sentivist reports can be customized.  

Does reporting allow customised filtering down to the level of reporting all activity on a specific network resource/object by a specific user/machine on a specific date?
Yes. 

Report management - can they be scheduled for automatic production? Can they be e-mailed to administrators or published straight to a Web site?
Yes, with the Crystal Reports Enterprise Edition. 

List the output formats supported for reports (HTML, text, PDF, etc)
PDF, HTML, text, Excel, Word, XML, CSV 

What are the limitations and restrictions on enterprise-wide alerting and reporting? Can reports consolidate output from every 1) server, 2) detector
There are no limitations or restrictions.  Sentivist centralized management delivers a single a unified view of data from which enterprise-wide reports can be generated.

Ability to define custom reports?
Yes.  Sentivist utilizes Crystal Reports thus Security Managers have the ability to create their own reports. 

Provide brief description of any management software included in the base price of the product. 
The Sentivist management platform is priced separately. 

Provide brief description of any additional management products available as extra cost options. 
As mentioned above, the Sentivist management platform is priced separately and the pricing structure is available in the end user pricing information.  End users must also purchase a licensed copy of Crystal Reports.  (est. retail $500). 

Documentation provided (Hard copies available? Extra cost?)
Sentivist documentation is provided electronically free of charge.  Hard copy documentation is available for a nominal charge. 

How is the product licensed? How is the license enforced?
Licensing is centrally controlled, and is enforced based on the MAC address of the management NIC card of the Smart Sensor. 

End user pricing information for product provided for test (include all sensor, management server and console costs for both hardware AND software). Include options/configurations other than those tested - ALL PRICES AS LIST PRICE ONLY!
Pricing for the Sentivist product family is as follows: 

Management Platform

�          Sentivist Office Management Platform (supports 1-3 Smart Sensors)                                   $10,000

�          Sentivist Professional Management Platform (supports 4-10 Smart Sensors                           $18,000

�          Sentivist Enterprise Management Platform (supports 11-30 Smart Sesnors)                           $30,000

�          Sentivist Management Platform Increment (supports additional 10 Smart Sensors)                 $10,000 

Sentivist Smart Sensors

�          Sentivist Smart Sensor
      100C                                                                                                                        $13,000

�          Sentivist Smart Sensor
      500C                                                                                                                        $22,000

�          Sentivist Smart Sensor
      500F                                                                                                                       $23,000 

Below is the pricing for the Sentivist system that was used at NSS: 

�          Sentivist Office Management Platform (supports 1-3 Smart Sensors)                                   $10,000

�          Sentivist Smart Sensor
      100C                                                                                                                        $13,000

Ongoing cost of maintenance/updates
NFR Security Signatures, Support and Maintenance costs are as follows: 

�          Standard Signatures, Support and Maintenance is 20%

o          Includes NFR Security Rapid Response Team signature support.

o          Standard level customer support is available 9AM-6PM EST, M-F, excluding holidays.

o          Includes HW warranty of one year with advanced replacement.

o          Includes product maintenance. 

�          Premium Signatures, Support and Maintenance is 23%

o          Includes NFR Security Rapid Response Team signature support.

o          Premium level customer support is available 24/7/365 with a twenty minute response time.

o          Includes a HW warranty of one year with advanced replacement, out years depot work, next
       day or bench repair.

o          Includes product maintenance.

Click here to return to vendor questionnaire index
Click here to return to the NFR Review
Click here to return to the IPS Index Section