ISS Proventia A201 Intrusion Protection Appliance

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)
The Proventia A201 appliance is a 1U rack mount server chassis with a 1.8 GHz Xeon processor, 20 gb hard drive, 1 gb RAM, 1 x 10/100/1000 Ethernet interface for monitoring and 1 x 10/100/1000 Ethernet interface for management.  The Proventia A201 is the first model in the series of new ISS dynamic protection appliances. 

What is the maximum speed/network load (Mbps) claimed with zero packet loss?
The Proventia A201 can monitor up to 200 mbps with zero packet loss in real-world environments. 

At the maximum load, what is the maximum TCP connection rate (connections per second) claimed?
Maximum connections per second has not yet been determined on the Proventia A201.  However, field testing has validated that the performance of this model is more than adequate on fully saturated 100 mbps real-world segments. 

Product architecture (2-tier/3-tier management? Brief description)
Proventia�s three-tiered architecture includes Agents, Event Collectors, and Managers for scalable, geographically dispersed deployments on high-speed networks.  The manager includes the Asset Database, Enterprise Database, Event Collector, Deployment Manager, and Console.  The components can all be installed on the same system or on separate systems in various combinations for performance considerations.

What are the minimum/recommended sensor OS and hardware requirements? Is a dedicated machine required/recommended?
Proventia ships as a pre-configured appliance.

What are the minimum/recommended console OS and hardware requirements? Is a dedicated machine required/recommended?
Yes, a dedicated machine is required.  SiteProtector is the recommended management platform for Proventia. The SiteProtector components consist of the Application Server, Enterprise Database, Deployment Manager, Console, and Event Collector.  The Security Fusion module is an optional component that also requires a dedicated machine.  All components can be deployed on a single machine or on separate machines, depending on the number of agents being deployed and managed by one SiteProtector instance.  Hardware recommendations for basic (single unit) and custom (multi-unit) installations can be found at

http://documents.iss.net/literature/siteProtector/SiteProtectorSystemsRequirements.pdf

What are the minimum/recommended management server OS and hardware requirements (if applicable)? Is a dedicated machine required/recommended?
See above. 

List required open ports on sensor and their use

*Depending on the SQL configuration. 

List required open ports on management server (if applicable) and their use
See above.

List required open ports on GUI/management console and their use
See above.

Communication protocol between sensor and management server
Microsoft or Certicom encryption is used between components.  See below.

Communication protocol between management server and GUI/console
SSL is used between SiteProtector components and the SiteProtector console.   

Encryption between sensor and management server
Yes, all data between Agents and Event Collectors and between Event Collectors and Managers is strongly authenticated and strongly encrypted using public key asymmetric cryptography.  Proventia ships with Certicom�s elliptic curve encryption module which generates 239-bit private/public keys.  Additionally, Windows agents may also use encryption algorithms supported by Microsoft�s cryptographic API.  Microsoft�s default CSP uses RSA technology and provides 40-bit, 128-bit, or 168-bit 3DES symmetric encryption keys and 512-bit or 1024-bit public encryption keys. 1536-bit high strength RSA encryption is also supported.

Encryption between management server and GUI/console
See above. 

Once deployed and configured, can sensors be managed from a central console?
Yes,  Proventia can be configured and updated from the central SiteProtector console. 

Capacity of the system? How many endpoints can be monitored? Ratio of endpoints to management servers/consoles, etc.
A single SiteProtector console has been known to monitor several hundred agents (a mixture of RealSecure Network, RealSecure Gigabit Network, Proventia,  RealSecure Server, RealSecure Desktop, and Internet Scanner agents).  The actual limits of SiteProtector are unknown, as it has not yet been scaled to its maximum potential in the field. However, a relatively small, two server configuration (each with 800 MHz PIII) has been noted in customer environments to manage over 15,000 heterogeneous agents, many of which were desktop and server agents, collecting over 22 million events per day.  From this information, it is presumed that more powerful servers can manage more agents depending on the event load, number of events being generated by each agent, and the number and type of agent (network, server, or desktop). 

What anti-flooding methods are employed (sensor to management server, and management server to console)?
Proventia coalesces similar events, drastically cutting down on storage during floods. Each sensor's queue can be configured to wrap-around and overwrite older events, if flooding persists for a long period of time.  

Maximum insertion rate into alerts database
There is no definitive maximum as this number is based on the hardware used and database configuration.  In the field, the database has been noted to store 250 events per second.   

Maximum size of database
This is dependent on the hardware.  The backend database is SQL Server 2000, which can support terabyte-sized databases. Using the SiteProtector Enterprise Dashboard to manage multiple SiteProtector sites, multiple databases are supported.  

Maximum number of alerts stored
This is dependent on the hardware.  The maximum number of events is dependant on the size of the disk space allocated to SQL Server.  As a guide, one gb of disk space can hold approximately 750,000 events.   

What happens to alerts in main alert database once capacity limits exceeded (deleted/archived/etc)
There is a data purging mechanism which can be scheduled to occur periodically.  This not only provides the ability to delete records if capacity has been reached, but it also provides the ability to keep the database at a manageable level. 

What is maximum recommended size of alerts database to maintain acceptable query performance?
The maximum size is dependent upon the hardware used to maintain the database.  Analysis is designed to be able to view millions of events at a high level and query a focused set of data easily.  This architecture allows for maximizing the size of the alert database without adversely affecting the analysis query performance.   

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)
Yes, events that are cleared from the SiteProtector console can still be accessed for reporting purposes. The reports created through SiteProtector require the events to be present in the database when the reports are generated. The data stored in the database has rollup levels. Long term rollups take up little space, so long term trending is very easy. Medium term analysis is possible without complete access to all of the event details for a longer period of time. Since detail data takes up the most space, it should be retained for the shortest period of time. Bearing this in mind, archived data can be restored for inclusion in detailed reports. 

Which database product is used for alert storage? Is schema open?
SQL Server 2000 is used.  Yes, the schema is available to customers. 

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?
If connectivity between the sensor and the event collector is disrupted, the event data is stored locally on the sensor until connection is re-established.  If connectivity between the event collector and the console is disrupted, the events are stored locally on the event collector until the connectivity is restored to the console at which time the events will appear on the console as determined by the security policy in effect.  The console does not need to be operational in order for the events to be stored.  When connectivity to any RealSecure or Proventia component is lost (other than the console itself), a sensor warning alert is sent to the console.  In short, the system fully recovers from these outages automatically.  The only way to lose data is for the connection to go down for so long that the sensor storage limits are exceeded (configurable up to disk limits).   

Secure logon for policy management?
Yes, Windows authentication is used to limit access to the RealSecure components.   

Granular access (i.e. read only/read-write/etc) granted on a per-user basis? What levels of granularity are supported?
SiteProtector has granular user control in that  multiple roles can be created under different user accounts to prohibit certain administrative functions.  For example, one user account may only be able to view events while another is able to view events and modify policy while yet another is able to do both plus start, stop, and deploy sensors.   

Is it possible to define multiple policies for the sole purpose of distributing to multiple sensors with different functions?
Yes, users may create custom policies and push them out to various sensors.  For example, a DMZ policy can be created and pushed out to the DMZ segments while an External Net policy can be created and pushed out to segments beyond the DMZs and/or segments not firewalled at all to cover all points of entry into the network from the internet. 

How are policies distributed to sensors?
Policies are distributed to sensors from the SiteProtector central console. 

Can policies be deployed on a per-sensor or per-group basis, or globally only?
Yes.  Policies can be deployed in all three of these ways. 

How are policy changes handled? Will the central console detect which agents are using a changed policy and redeploy automatically, or does the administrator have to do this manually?
Proventia policies are highly configurable. Individual signatures can be enabled and responses set optimally for a customer�s environment.  Policy is centrally managed and is controlled by user roles. Users can only change policy if they are authorized to do so. The sensors send notification when a new policy is applied.  If a policy is inadvertently applied to a sensor or group of sensors by an authorized user, that active policy is displayed at the console, and the original policy can be easily redeployed to that sensor or group of sensors. The Console will notify the administrator which Sensors are using the changed Policy and provide the option to deploy to all Sensors in a single operation. 

Can policy deployment be scheduled?
Yes, policy deployments can be scheduled through SiteProtector. 

Does the sensor remain able to detect alerts at all times during policy/signature updates? Explain how this is achieved. The sensor goes offline briefly, but this can be scheduled to occur at a low risk time of day.  For policy updates, it takes less than five seconds and for signature updates, it takes less than 20 seconds.   

Can the administrator define custom attack signatures?
Yes, custom signatures can be created using the TRONS module which accepts open-source (Snort) syntax rules  These rules are created using the console GUI and a validation tool verifies the syntax before the rule is applied to a policy.  

Regex supported when creating custom signatures?
Yes, regular expressions are supported. 

How are new vendor attack signatures obtained and deployed?
New signatures are added using the X-Press Update (XPU) technology built into each ISS product by selecting the appropriate X-Press Update option from the SiteProtector console.  SiteProtector then accesses the ISS web site, downloads any new updates, and applies them to the sensor policies as specified.  The updated policies are then pushed out to the sensors all at once, by groups, or by individual sensor.  Updates can also be downloaded to another system and manually copied to the SiteProtector console machine should the console not have internet access. 

Frequency of signature updates?
Because of the protocol analysis module built-in to the sensor, a signature update is not necessarily required for every new threat that is discovered.  Many previously unknown threats that RealSecure detected before they were given a specific name include:  .printer overflow, rpc.statd format-string attack, DNS TSIG overflow, Telnet buffer overflow, UTF8 (used by Nimda), .ida overflow (used by Code Red), BSD-based telnet overflow, SysV telnet overflow, several SNMP vulnerabilities, Jolt and Jolt2, SQL Slammer, and many others.   Beyond the standard HTTP, SMTP, FTP, Telnet, SNMP, ICMP, etc. protocol analysis intelligently monitors TFTP, IMAP4, POP3, MIME, DHCP, SOCKS, bootparam, rusers,ypupdate, finger, NetMeeting, Rsh, cmsd, Gopher, ssh, rlogin, ICQ, statd, nfs, portmapper, and unknown buffer overflow attacks.   X-Press Updates are still developed on a monthly basis, either to add more decodes or as service releases based on customer feedback through our technical support channel.  Emergency updates are also developed for those new threats not already covered.

What infrastructure does the vendor have behind the signature update process (i.e. dedicated team of engineers? How many? Does it have a name?)
X-Force, a team of approximately 150 security engineers, is responsible for the security content and update process and prioritization across all ISS products and services.   

Can one signature update file be downloaded to the local network and used to update all IDS engines from a central location, or is it necessary to initiate a live connection to the Internet download server for each sensor/management server?
Yes, a live internet connection is not necessary as there is also a manual process available.  One update can be applied to all sensors simultaneously. 

Can signature updates be scheduled and fully automated?
Yes, signature updates can be initiated by the user or can be scheduled using SiteProtector.   

Which network types are supported by the sensor?
Proventia A201 supports 10/100/1000 Ethernet.  It can be deployed on a 10, 100, or 1000 mbps network and is able to process 100% of packets on a 20% utilized gigabit network in real-world environments.  It can also process 100% of packets on a fully saturated 100 mbps real-world segment.  

What network protocols are analysed?
Proventia fully analyzes and decodes the following network and application protocols:  802.1q, 802.2, 802.3, 802.3u, 802.3z, 802.5, aolim, arp, automount, backorifice, bgp, bo2k, bootp, bootparam, cmsd, dhcp, dns, email, fddi, finger, fsp, ftp, gnutella, h245, http, icecap, icmp, ident, igmp, imap4, ip, ipv6, irc, java, lanman, ldap, lpr, mime, mms, mountd, mpls, ms_messenger, msrpc, napster, netbios, nfs, nis, nntp, pcanywhere, pcnfsd, pop3, portmapper, pppoe, pptp, q931, quake, radius, rexec, rfb, rip, rlogin, rsh, rtsp, selnsvc, sgifam, smb, smtp, snmp, snmpxdmid, sntp, socks, sql_server, ssh, ssl, statd, subseven, sunadmind, sunrpc, syslog, talk, tcp, telnet, tftp, tooltalk, udp, url, virus, xdmcp, xfs, xml, yahoo_messenger, ypbind, yppasswdd, and ypupdated. 

What application-level protocols are analysed?
See above. 

Can the product perform protocol decodes?
Yes, ISS uses a common Protection Engine across its network, server, and desktop agents to detect, prevent, and respond to known and unknown threats.  One component of this engine is the protocol analysis module which performs 7-layer, state-based protocol decoding, validation, and anomaly detection.  Using packet captures, the entire decode is made available to the user.  Also, it can create many decode files and save them separately based upon the configured response to certain events.  This protocol decoding is especially effective for detecting previously unknown threats since it focuses on the underlying vulnerability rather than a specific exploit of the vulnerability.  An example of this is the detection of the underlying vulnerability that was exploited by SQL Slammer.  Without requiring a signature update, RealSecure detected this as SQL_SSRP_StackBo which indicated that the underlying stack buffer overflow vulnerability of SQL Server was being exploited.  Less than a few hours later, this exploit was named �SQL Slammer�.  RealSecure was then updated to include a decode name for that specific exploit.  Should another new attack attempt to exploit the same SQL vulnerability, the SQL_SSRP_StackBo event would once again be triggered and the attack stopped depending on the pre-defined configured response.  This illustrates the advantage of protocol decoding over pure pattern-match signatures which are written for specific exploits rather than the underlying vulnerability.    

Can the product perform protocol anomaly detection?
Yes, the protocol analysis module within the Protection Engine does protocol anomaly detection by performing protocol validation and RFC compliance checking.  However, since some protocol anomalies do not necessarily constitute an attack, RealSecure is able to distinguish between a non-compliance and an actual intrusion attempt or malicious activity.  Since many protocol anomalies are benign, RealSecure focuses its anomaly detection on those areas that are most likely to indicate an attack so as to avoid false alarms yet trigger on previously unknown threats. 

Is the detection engine �stateful�? If so, please explain how this works.
Yes, the Protection Engine performs state-based packet inspection, protocol analysis, protocol anomaly detection, pattern-matching, decoding of backdoor communications/protocols, multi-format Unicode URL decoding, port-independent protocol detection and decoding, attack verification using target host responses, TCP reassembly, and IP defragmentation.  Stateful packet inspection technology means that the sensor doesn�t just match patterns to a single packet but rather stores the data stream in a state table on a packet-to-packet basis.  For example, it can determine the success or failure of HTTP attacks using stateful inspection.  

If stateful - how many open connections can be tracked? Is this value configurable?
The default limit is 500,000 connections.  This is configurable to over a million which would likely require a higher-end Proventia appliance.  Using the Security Fusion module with SiteProtector, the views can be configured to display only attacks made against a vulnerable target while suppressing those made against non-vulnerable targets.  Yes, this behavior is completely configurable and can be modified to alert on all attacks if desired, regardless of the vulnerability state of the target. 

If stateful - for how long are partially opened connections tracked? Is this configurable?
These are not tracked or counted separately, but there are safeguards, such as the coelescer and noise threshold parameters, to prevent resource exhaustion from syn attacks or other flood-type denial of service attempts or network anomalies. 

If stateful - for how long are fully opened connections tracked if not used? Is this configurable?
The default timeout is 5 minutes assuming the connection is not closed gracefully.  This is configurable. 

If stateful � explain the behaviour of the system when the state tables are filled
In the general case, new connections are dropped.  In the case of IP defragmentation and TCP reassembly, an event is reported and the reassembly pool is flushed. 

Will the detection engine 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)?
Using the optional Security Fusion module with SiteProtector, the views can be configured to display only attacks made against a vulnerable target while suppressing those made against non-vulnerable targets.  Yes, this behavior is completely configurable and can be modified to alert on all attacks if desired, regardless of the state of the target.  There are also parameters in that can be set for each signature to adjust noise thresholds so that an event is displayed only once to the console under certain conditions in order to minimize the number of events the user has to process.  These advanced tuning parameters have several adjustable fields to filter or display events to and/or from a specific host or IP address/range.                                              

Are server responses monitored and alerted upon?
Yes.  This is referred to as �attack verification.�  

Ability to monitor user-defined connections (i.e. report on an FTP connection to a specific server?)
Yes. 

Detect network-level packet based attacks?
Yes. 

Detect all types of port scans (full connect, SYN stealth, FIN stealth, UDP)?
Yes. 

Detect SYN floods? Manual or automatic thresholds? Configurable?
Yes. 

Perform packet/stream reassembly?
Yes. 

Perform deobfuscation?
Yes, evasion techniques that obfuscate malicious traffic are not successful against Proventia.  This is configurable.  In some cases, an evasion technique is taken so far that the receiving host can no longer piece it together as an attack.  This is something that is tunable in Proventia.  Examples are favoring new or old TCP data in an overlap connection.  Or, Proventia can deal with the overlap, small frames, and time delay, but if there are too many small, overlapped frames with too much time in between, the receiving host will drop it since it no longer constitutes an attack.   

List all �prevention� features available (TCP reset, ICMP unreachable, firewall reconfiguration, drop packets (in-line only))
Proventia can terminate sessions via a TCP RST sent to both hosts in the conversation.  It can also dynamically reconfigure a Check Point FW-1 via the OPSEC response.  This will add a rule to the firewall policy for a configurable about of time to terminate the existing session and drop packets from the attacking source for a pre-defined period of time or for an indefinite period of time.  RealSecure can also communicate with other infrastructure devices via a user-defined response.  An example is that it can modify the ACL on a router using EXPECT scripts to block connections based on protocol, service, and/or IP address/range.  

Packet capture capabilities? Only the trigger packet, or before and after? How are packet captures stored/viewed?
RealSecure has two options for capturing packets:  Evidence Logging and Packet Logging.  The Evidence Logging response stores the exact packet that triggered the event in a file by itself at the sensor.   

Option to record entire sessions for �forensic� investigation? Where is this data stored? How is it secured from tampering?
Packet Logging stores all packets surrounding an event in a circular queue of files stored at the sensor.  Storage limits are configurable.  It�s secured by standard OS authentication to that system.
 

Reporting from sensor to console - range of alert response options (detail these, i.e. log, alert, e-mail, pager, packet capture, etc)
There are several actions that can be configured in the security policy on a per event basis.  Responses to events include: RSKill (TCP RST response), sending an alert to the console or to multiple consoles, sending an SNMP trap to a 3rd party trap handler, reconfiguring a Check Point FW-1 rule base, logging a summary of the event in the database (with or without raw), email notification to one or more mail addresses or distribution lists, and executing a user-defined program. 

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)?
Responses are configurable on a per event basis.  They can also be globally applied to many sensors at once, but not to just a group of signatures at once.  

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, alerts are sent to the SiteProtector console in real-time without any third-party software.  It is easy to filter and extract individual events and drilldown to specific incidents using on attack pattern recognition and impact analysis features.     

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, all events are transmitted to SiteProtector in real-time from the Event Collectors of all managed sensors after logic, analysis, and correlation are applied.  These events are all stored in the Enterprise Database for historic and real-time viewing. 

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)?
Yes, SiteProtector with the Security Fusion module offers attack pattern recognition which correlates events from multiple sensors to discover relationships between events and determine whether a coordinated attack is occurring. 

Can alerts be correlated manually by the administrator - grouped together in the database as a single event for further investigation?
Yes, events can be correlated manually or using the built-in logic that is available with the Security Fusion module.  There is also native drilldown capability from within SiteProtector.  Events can be correlated on many fields, such as source IP, destination IP, type event type, time, date, etc.  Many events can be filtered down to just a few actionable incidents automatically so that the administrator is able to quickly respond to high priority incidents rather than trying to sift through thousands of events. 

Can alerts/events be annotated and tracked for investigation by multiple administrators/investigators?
Yes, using the incidents functionality users can track events and add notations describing any actions taken to resolve the incident.   Viewing events is done through a console whose access is managed through group membership which also provides for roles- based permissions within the management/analysis console. 

Does the software offer advice on preventative action to ensure the attack does not happen again?
Yes, all events are thoroughly detailed by X-Force and searchable in the online help along with what OSes are effected, the severity of the event, any known false positive or false alarm conditions, the corrective action recommended, and links to CERT advisories, CVE-correlations,  OS vendors, and other related information.  

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?
ISS X-Force are founding members of the IDMEF working group.  However, this standard has not yet been adopted by the industry. 

Which third party event correlation systems are supported and in what way?
There are several third party vendors that receive events from RealSecure Network such as netForensics, Symantec ManHunt, Arcsight, Guardednet NeuSecure, as well as many others.   

Integration with other scanning/IDS products?
Yes, RealSecure is able to import open-source (Snort) signatures via the TRONS utility.  It is also integrated with Internet Scanner via the Security Fusion module to reveal whether an attack was successful based on the vulnerability state of the target. This required an in-depth analysis and mapping of the implementation of an Internet Scanner vulnerability check and it�s relationship to the directionality, port, etc. of the IDS signature.  Currently, the Security Fusion module is able to correlate nearly 800 RealSecure events with Internet Scanner vulnerability checks.  Other types of correlations include events from RealSecure Server and System Scanner agents.  RealSecure Network and Gigabit Network are also integrated with RealSecure Desktop via the SiteProtector management platform.   

Log file maintenance � automatic rotation, archiving, reporting from archived logs, etc.
Data archival is possible through the use of SQL server backup and restore options, however there is not a a built-in mechanism within SiteProtector for archiving and recovering data. 

Management reporting � range of reports/custom reports/how easy is it to filter and extract detail? Different reports for technicians and management/end users?
Yes, this is quite simple as all data is transmitted from the Event Collector to the SQL or MSDE Database.  Granular, specialized reports can be easily created directly from the database, a free utility called FastReports, and /or Crystal Reports.  SiteProtector data views can be exported to CSV files for specialized reports creation.  There are also several built-in reports that can be exported to other formats as of version 2.0. 

Are trend/comparison reports available?
Yes, trend analysis and comparison reports are built-in. 

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, all views are fully customizable as are several types of reports.  Extensive drilldown capability quickly reveals attack patterns, coordinated attacks, vulnerable targets, etc.   

Report management � can they be scheduled for automatic production? Can they be e-mailed to administrators or published straight to a Web site?
SiteProtector provides the ability to schedule reports to be pushed to a web site.  Additional scripting would be required to automatically email the reports. 

What are the limitations and restrictions on enterprise-wide alerting and reporting? Can reports consolidate output from every 1) server, 2) detector
Yes, events from multiple sensors can be filtered, aggregated, consolidated, and correlated into various real-time and historic views which can then be exported to CSV files.  SiteProtector also offers event and vulnerability information from network and host vulnerability assessment and desktop firewall/intrusion detection components. 

Ability to define custom reports?
Yes, reports can be created and/or customized by the user.  This is in addition to the default reports that ship with the product.   Console views can be stored as formatted reports and generated immediately  or on a scheduled basis.   

Provide brief description of any management software included in the base price of the product. 
SiteProtector is a centralized management platform that integrates network, server, and desktop protection agents for dynamic detection, prevention, and response to known and unknown threats across a geographically dispersed, heterogeneous digital  environment.    

Provide brief description of any additional management products available as extra cost options. 
SiteProtector works with the Security Fusion module, which is an add-on option but not a requirement.  It enables IDS/VA/OS correlation into a single, asset-oriented context thus minimizing the number of events displayed to the user.  It  checks incoming IDS events against vulnerabilities and operating systems discovered to immediately estimate the impact (success or failure) of attacks.  It can automatically escalate these important events, by increasing event priority and/or by responding with additional actions (such as email or paging).   

Security Fusion 2.0 provides attack pattern analysis on nearly 800 security checks.  It ships with attack pattern signatures that will automatically escalate critical patterns of attacks to create actionable incidents. 

Documentation provided
Proventia ships with a Quick Start Guide.  RealSecure Network documentation that is available to customers includes the following, either hardcopy, online, or both:  RealSecure Network & Gigabit Network Installation Guide (not all sections of this guide are applicable to the Proventia appliances), Policy Guide, Migration Guide, and FAQ.  Additionally, SiteProtector includes the following documentation, either hardcopy, online, or both:  Installation and Configuration Guide, Reference Guide, Strategy Guide, Troubleshooting Guide, Upgrading to SiteProtector 2.0 Guide, and Product Spec Sheet.  If the Security Fusion module is purchased, additional documentation includes:  Security Fusion Module FAQ, Datasheet, Reference Guide, and System Requirements.   

How is the product licensed? How is the license enforced?
Each license key contains fields for the components purchased and is not restricted in any way by  IP address, network, or host name.  Instead, the key restricts functionality based on the number and type of sensors, number and type of managers, and number of assets correlated by the Security Fusion module.  The license key resides on the SiteProtector console. 

End user pricing information
The Proventia appliance is priced at $9,995, which includes the cost of management.  The first year of technical support, service, and advanced exchange is $1000.  Product updates and security content updates for the first year is $1400.  The Security Fusion module is priced at  $145 per managed asset.   

Ongoing cost of maintenance/updates
Proventia�s ongoing cost is variable, depending on what type of support, service, and security content provisions the user decides upon.

Click here to return to the ISS Proventia A201 Review
Click here to return to the ISS Proventia A201 results
Click here to return to the IDS Index Section