NetScreen-IDP 500  V 2.1

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 sensor is an appliance, with the management server delivered as software and the interface as an application. The IDP 500 hardware specification inlcudes a P4 processor with 4GB of RAM 

What is the maximum speed/network load (Mbps) claimed with zero packet loss?
NetScreen has three different products to accommodate the performance requirements for different network segments. The NetScreen-IDP 10 provides 20Mbps nominal throughput and is designed for small, low-speed network segments.  The NetScreen-IDP 100 offers 200Mb maximum throughput (1500 byte packets) and is designed for a regional office  or medium central site. The NetScreen-IDP 500 provides 500Mb maximum throughput (1500 byte packets) and is generally placed in large central sites.

At the maximum load, what is the maximum TCP connection rate (connections per second) claimed?
All IDP Platforms can handle approximately 12,000 TCP sessions per second under normal conditions.  At the maximum advertised load, the IDP platforms can handle approximately 2,000 TCP sessions per second, depending upon which types of signatures are loaded (i.e. if a lot of packet-based signatures, which look for attack pattern matches in all of traffic, have been imported and enabled performance can be affected).

Product architecture (2-tier/3-tier management? Brief description)
NetScreen-IDP has a true three-tier management architecture comprised of a detection and enforcement tier (sensor), a management tier (server) and an application tier (user interface).

The NetScreen-IDP Sensors are based on a network appliance platform running a derivative of a Linux based kernel.  Sensors can operate either as a traditional passive based IDS product or as an in-line product. 

The NetScreen-IDP Management Server is a software component running on either Intel-based RedHat Linux 7.2 or a SPARC system running Sun Solaris 7/8.  The NetScreen-IDP Management Server stores all log and policy information for all NetScreen-IDP units in an enterprise. The centralised management server reports to multiple user interface consoles for alerts. It also sends e-mail alerts to all security administrators and/or sends syslog messages / SNMP traps to multiple managers. The notification is configured on a per rule basis.

The NetScreen-IDP User Interface is available for either Linux or Windows platforms. Multiple user interfaces can connect to a single management server to perform all management operations.

What are the minimum/recommended sensor OS and hardware requirements? Is a dedicated machine required/recommended?
Dedicated appliance

What are the minimum/recommended console OS and hardware requirements? Is a dedicated machine required/recommended?
The NetScreen-IDP UI can be loaded onto any Windows 2000/XP or RedHat 7.2 machine.  NetScreen recommends that you have a minimum of 512Mb of RAM on the IDP UI system and a Pentium III or greater for best performance.

What are the minimum/recommended management server OS and hardware requirements (if applicable)? Is a dedicated machine required/recommended?
The NetScreen-IDP Management System requires an enterprise class server running Sun Solaris 7/8 (SPARC) or Linux RedHat 7.2 (Intel).  400Mhz SPARC/1GHz Intel, 512 MB Memory, RAID. 2GB memory is recommended for larger deployments.

List required open ports on sensor and their use

There are two open ports required on the sensor:

�          IDP�s sciod uses port 7101 (Used to configure sensor and push policy from management server)

�          IDP�s sessionFetcher uses port 7102 (Used to fetch session data)

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

There are three open ports required on the management server:

�          IDP�s statusReceiver uses port 7201 (Used to receive status information from sensor)

�          IDP�s logReceiver uses port 7202 (Used to receive log from sensor)

�          IDP�s pingerTracer usesport 7204

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

There is one open port required on the GUI console:

�          IDP�s guiDaemon uses port 7203 (Used to communicate between management server and GUI console)

Communication protocol between sensor and management server
All communication between the different tiers of NetScreen-IDP solution are authenticated and encrypted, using RSA, Blowfish, SHA-1. Connection messages are validated using RSA and the payload messages are validated using HMAC'ed SHA1 in CBC mode with an IV.

Communication protocol between management server and GUI/console
All messages are validated using HMAC'ed SHA1 in CBC mode with an IV.

Encryption between sensor and management server

The encryption between the sensor and the management server are 1024 bit RSA keys (created at device initialization) and a 128 bit Blowfish key.

Encryption between management server and GUI/console
The encryption between the management server and the GUI are 256 bit dynamically-generated (per-connection) RSA keys and a 128 bit Blowfish key.

Once deployed and configured, can sensors be managed from a central console?
Yes, the NetScreen-IDP system uses a centralised, rule-based management approach that enables customers to control the security of their network through a single, enterprise-wide policy.

The concept of a centralized, Security Policy also allows the application of the same Security Policy to as many enforcement points as required. Deviation from one device to another does not require a new Security Policy; it is simply accomplished by specifying to which sensor each of the individual rules within the Security Policy applies. As a result, the system can be configured to only look for attacks relevant to the potential vulnerabilities of that portion of the network, such as IIS attacks against the IIS servers. One policy can be applied to an entire network with different rules pertaining to different sensors, or multiple policies can be created and deployed to sensors individually.

Capacity of the system? How many endpoints can be monitored? Ratio of endpoints to management servers/consoles, etc.
The NetScreen-IDP system is designed so that hundreds of sensors may be managed from a central server. Management server resources, such as network interface speeds, processor speeds, available memory, amount of log data, and available disk space dictate the practical limit.  That said, on a normal 100 megabit enterprise network, it is possible to manage 100 sensors from one management station with the following management server configurations:

�          Solaris 7/8 server running a 400MHz processor, 1 GB RAM, 18GB disk.

�          RedHat Linux 7.2 server running a 1GHz Pentium-IV processor, 1 GB RAM, 18GB disk.

What anti-flooding methods are employed (sensor to management server, and management server to console)?
When logs overload the system, there are multiple actions taken by the NetScreen-IDP system to prevent overloading the management server. If the server does not acknowledge receiving logs, the sensor will retransmit the logs and keep them saved locally until the management server is ready to accept more logs. One of the architectural reasons for designing a proprietary database for NetScreen-IDP was to increase the speed at which logs could be collected at the management server. Typical commercial databases are significantly slower than the NetScreen-IDP database for collecting logs. 

Maximum insertion rate into alerts database?
Approximately 50,000 logs per second can be inserted into the alerts database for an IDP-500 with a dedicated interface to the Management Server.

Maximum size of database?
The size of the database is limited only by available disk space on the IDP Management Server.

Maximum number of alerts stored on the Sensor?
If communications are disrupted, the IDP Sensor will cache logs locally (in a first-in, first-out basis). The sensor has 10 Gigabytes of storage dedicated to log storage and packet log storage. 

What happens to alerts in main alert database once capacity limits exceeded (deleted/archived/etc)?
If capacity in the database is exceeded, the oldest day�s alerts that are stored will be purged (deleted) automatically.

What is maximum recommended size of alerts database to maintain acceptable query performance?
Less than 200Mb is the recommended database size for the most optimal results. 

When alerts are removed from the main alert database, are they still available for reporting directly (i.e. can reporting tools merge current and archived alerts)?
NetScreen-IDP logs can be manually stored offline to clear room in the alerts database for new logs. Stored logs can be moved back later, if the customer wants to do additional reporting or analysis with NetScreen-IDP�s log viewer and reporting tools.

Which database product is used for alert storage? Is schema open?
NetScreen uses a proprietary database, however, logs can be exported to CSV file or a Posgress SQL Database.

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 communications are disrupted, the IDP Sensor will cache logs locally (in a first-in first-out basis). The Sensor has 10 Gigabytes of storage dedicated to log storage and packet storage.  This is stored on an EXT3 type file-system with UNIX-style permissions. If the disk is full the oldest packet captures will be purged first, then oldest log files.  When communication is resumed, Log messages will be sent to the Management Server. 

Secure logon for policy management?
Yes, NetScreen-IDP provides secure login for policy management. The encryption between the management server and the GUI is 256 bit dynamically generated (per-connection) RSA keys and a 128 bit Blowfish key.  This is used to protect an administrator�s authentication credentials.

Granular access (i.e. read only/read-write/etc) granted on a per-user basis? What levels of granularity are supported?
Yes, NetScreen can provide granular access granted on a per-user basis. Unlimited administrators may be defined on each IDP Management Server, and each administrator will have either full (read/write) access or limited (read-only) access.  Only the Super-user Administrator has access to add and delete other Administrators.

Is it possible to define multiple policies for the sole purpose of distributing to multiple sensors with different functions?
Yes. The security policy is made up of rules that dictate what traffic the device should look at, what attacks in that traffic to look for, what to do when those attacks are detected and to which sensors that rule applies. As a result, from a single enterprise-wide policy, rules can be distributed to multiple sensors to ensure they are detecting and preventing completely different things. These rules can be for individual sensors or groups of sensors, making it easy to create a policy that adequately protects different areas of the network. In addition, this flexibility enables the creation of rules that look for different things in the same traffic and treat that traffic differently.

How are policies distributed to sensors?
Policies are configured by the Administrator through the IDP GUI and compiled by the IDP Management Server prior to being installed on appropriate Sensors through the secure communications channel.  The encryption between the sensor and the management server are 1024 bit RSA keys (created at device initialization) and a128 bit Blowfish key.  The IDP Administrator may push policies to individual sensors or all sensors.

Can policies be deployed on a per-sensor or per-group basis, or globally only?
Policies can be distributed globally, on a per-sensor basis, a per-group basis, or any combination of those choices. This is because when the policy is created the administrator defines exactly how the policy rules should be distributed. For example, an administrator may create a few rules that apply to all of the sensors, a few others that apply to different groups of sensors, and a few that only apply to an individual sensor.

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?
Once changes are made to a policy and that policy is pushed live, the system will automatically identify what has been changed in the policy and make those changes at the relevant sensors. Because rules can be defined on a per-sensor basis, a single policy will be pushed to the relevant sensors automatically.

Can policy deployment be scheduled?
No, policy updated musts be performed by the IDP Administrator.

Does the sensor remain able to detect alerts at all times during policy/signature updates? Explain how this is achieved.
Yes, the sensor is able to detect alerts at all times during policy/signature updates. While the policy updates are downloaded to the IDP Sensor it continues to process traffic and alert or block attacks based on the previous policy.  At the moment the new policy is loaded current connections are not disrupted.

Can the administrator define custom attack signatures?
NetScreen-IDP uses an open signature format, so it is possible to create custom signatures to meet an organization�s specific security needs. Plus, NetScreen enables customers to create their own Stateful signatures. Using the signature editor, customers can significantly narrow down the pattern match to the service field of the protocol to reduce the chance for irrelevant pattern matching.

Regex supported when creating custom signatures?
Yes, NetScreen supports Regular Expression pattern matching and provides regular expressions in a drop down menu (next to the pattern field) within the signature editor to make it easer for a user to write effective Stateful signatures.

How are new vendor attack signatures obtained and deployed?
Registered customers under an IDP support contract will be notified of and have access to regular signature updates. Regular signature updates can include updated and new signatures, detailed descriptions and a migration, allowing customers the ability to decide how best to merge the new signatures with the existing signatures. The NetScreen-IDP signature update process is as easy as a virus update system. Updating signatures for all devices located anywhere on the network is very simple, since the signatures can be downloaded using the User Interface to the central management server and distributed to all sensors with one click. If you so desire, the system also provides granular control so you can decide which NetScreen signatures should be downloaded and which should not. In addition, if you modify a NetScreen provided signature, the system is intelligent enough to ask you which signature should be kept and which should be overwritten.  

Frequency of signature updates?
NetScreen provides signature updates on a regular basis, approximately once a week, but also releases emergency signature updates, if necessary, for critical threats soon after they are discovered.

What infrastructure does the vendor have behind the signature update process (i.e. dedicated team of engineers? How many? Does it have a name?)
NetScreen has a dedicated team of engineers, whose purpose is to identify and research vulnerabilities and develop attack signatures to combat them.

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?
The IDP Signature update can be loaded in as a file, if the administrator does not wish to use automatic (live) network updates.

Can signature updates be scheduled and fully automated?
No, NetScreen sends alerts to notify administrators when new signatures, attack updates, are available. The update process, which is described above, is fairly automated, giving administrators the ability to do a complete update in a matter of minutes. But NetScreen also offers the flexibility to allow administrators to pick and choose the updates they want to meet the specific needs of the organisation, as well as containing automatic checks in it to make sure that custom signatures are not overridden without the administrator�s confirmation. As a result, the signature updates are easy to do, yet remain in the control of the administrator to ensure the system is always behaving as the organisation dictates.

Which network types are supported by the sensor?
�          The NetScreen-IDP 10 supports 10/100 Fast Ethernet networks

�          The NetScreen-IDP 100 supports 10/100 Fast Ethernet networks, optional Gigabit Fibre Ethernet cards and comes with a 1000-SX GBIC.

�          The NetScreen-IDP 500 supports both 10/100 Fast Ethernet and Gigabit Fibre Ethernet standard and comes with a 1000-SX GBIC.

What network protocols are analysed?
NetScreen supports more than 50 protocols. Please see the table below:

What application-level protocols are analysed?
See the above table.

Can the product perform protocol decodes?
For every protocol that NetScreen-IDP supports, it performs full protocol decode.

Can the product perform protocol anomaly detection?
Yes, protocol anomaly detection is one of NetScreen-IDP�s eight detection mechanisms. Protocol anomaly detection, sometimes referred to as protocol analysis, is the ability to analyse packet flows (the uni-directional communication between two systems) to identify irregularities in the generally accepted Internet rules of communication. These rules are defined by open-protocols and published standards (RFC�s), as well as vendor-defined specifications for communication between networked devices. The objective is to implement an intrusion detection mechanism that identifies traffic that doesn�t meet specifications or violates the relevant standards. Once an irregularity is identified, it can be used to make network security decisions. This is very effective in detecting suspicious activity, such as a buffer-overflow attack.

Is the detection engine �stateful�? If so, please explain how this works.
Yes it is stateful. NetScreen-IDP�s Stateful Signatures identify attack patterns by utilising both Stateful Inspection and protocol analysis, which is performed as part of protocol anomaly detection. As a result, Stateful Signatures understand the context of each data byte and the state of the client and server at the time of transmission.  Stateful Signatures are compared to only relevant data bytes, according to the communication state to which each signature is relevant. In other words, Stateful Signatures only look for an attack in the state of the communication where that attack can cause damage, significantly improving performance and reducing false positives.

If Stateful - how many open connections can be tracked? Is this value configurable?
The maximum number of sessions (combination UDP, TCP, ICMP) that NetScreen-IDP can support varies by solution: 

�          The NetScreen-IDP 10 supports a maximum of 10,000 Sessions

�          The NetScreen-IDP 100 supports a maximum of 50,000 sessions

�          The NetScreen-IDP 500 supports a maximum of 200,000 sessions. 

While these values can be modified by the Administrator on a per-sensor basis, the above is the default and represents the maximum recommended number of sessions for each solution.

If stateful - for how long are partially opened connections tracked? Is this configurable?
If the ACK response to the SYN-ACK is not received from the initiator within 30 seconds, the session is discarded.  We also allow the user to discard TCP sessions not setup by the proper 3-way handshake (SYN, SYN-ACK, ACK)

If stateful - for how long are fully opened connections tracked if not used? Is this configurable?
Established TCP sessions are maintained state for up to 1 hour of no traffic and then discarded. This is configurable in the policy under the Sensor Settings tab.

If stateful - explain the behaviour of the system when the state tables are filled
New sessions are discarded when the session table is full. We don't actively go through the session table and purge entries when the session limit is exceeded.    

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)?
Alerts on all suspicious activity as defined in the rule base. If required, per-seonsr rules allow the administrator to look for only IIS attacks against their IIS servers, so that they are not getting alerts on Apache attacks against their IIS servers that cannot do any damage.

Are server responses monitored and alerted upon?
Yes. NetScreen-IDP tracks both sides of the connection and we have signatures that trigger based on the servers response

(NSS COMMENT: enabling server-to-client response signatures has a significant impact on performance - NetScreen recommends these signatures are disabled in heavily-loaded networks, and they were turned off for our testing).

Ability to monitor user-defined connections (i.e. report on an FTP connection to a specific server?)
Yes, NetScreen-IDP can monitor user-defined connections. The policy-based approach to IDP Management allows the administrator to setup a specific policy for specific source/destination pairs, with administrator-controlled actions.

Detect network-level packet based attacks?
Yes, NetScreen-IDP detects network-level packet-based attacks. Both IP Spoofing and Layer 2 (ARP) spoofing without any special configuration.

Detect all types of port scans (full connect, SYN stealth, FIN stealth, UDP)?
Yes, NetScreen IDP�s Traffic Anomaly Detection mechanism is designed to look for attacks over multiple connections, such as port scans and network scans.  It supports identifying and blocking excessive CONNECT, SYN Stealth Scans, FIN Stealth Scans and UDP Scans.

Detect SYN floods? Manual or automatic thresholds? Configurable?
NetScreen IDP uses its SYN-Protector to detect and prevent SYN-Floods. The connection rate thresholds for SYN-Flood detection are configurable in the Sensor Settings tab in the IDP GUI.  SYN-Flood Protector actually mimics the server�s SYN-ACK response until it is validated. As soon as it is determined that the connection is not a SYN-Flood the real connection to the server will be opened to the client. This eliminates any impact a SYN-Flood may have on servers protected with IDP.

Does the system perform packet/stream reassembly?
NetScreen-IDP performs reassembly, which reconstructs streams to interpret data exactly as the destination machine would interpret it. It also normalises the traffic, removing extraneous characters and alternate representations of data to ensure there is no ambiguity about what the packets contain. This can include packet de-fragmentation, removing overlapping packets, reordering packets for correct interpretation, etc. 

Perform deobfuscation?
Yes, see above.

List all �prevention� features available (TCP reset, ICMP unreachable, firewall reconfiguration, drop packets (in-line only))
NetScreen-IDP is capable of operating in-line if required to deliver true prevention, by dropping the malicious packet or connection during the attack detection process to stop attacks from ever reaching the target system. The administrator defines in the rulebase which attacks warrant a drop packet or drop connection action, preventing the attack from ever reaching its destination. Where passive detection is preferred, NetScreen can send TCP Resets in an attempt to tear down a connection.

Packet capture capabilities? Only the trigger packet, or before and after? How are packet captures stored/viewed?
Packet capture is configurable and defined in the rulebase. Customers can turn on logging and set how many packets before and after an attack they would like the system to capture. The packets are stored on the Sensor and accessed by the management server

Option to record entire sessions for �forensic� investigation? Where is this data stored? How is it secured from tampering?
No means to record an entire session automatically. Packet Captures are stored in a standard PCAP format on the IDP Sensor on an EXT3 file-system with standard UNIX permissions. They can be easily exported through the IDP GUI and viewed with any packet capture program, such as Ethereal, that can open PCAP files.  Packet captures are not cryptographically time stamped or authenticated.

Reporting from sensor to console - range of alert response options (detail these, i.e. log, alert, e-mail, pager, packet capture, etc)
NetScreen-IDP provides multiple methods for alerting of events. The standard alerting method includes alert icons on the user interface console (alarm), SNMP Trap messages, e-mail, and Syslog messages. In addition, custom script and programs may be invoked using the run script interface. This interface can be used to invoke paging programs or other custom notification programs, enabling the NetScreen-IDP to interface with many notification systems. Packet logging can be turned on and the administrator can define how many packets before and after that attack they would like to capture for forensic purposes. In the NetScreen-IDP Security Policy, each rule may have its own set of alerting mechanisms enabled

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)?
The alert response options are defined in the rule base at individual rule level. (NSS COMMENT: There is no provision to define responses at a group or global policy level)

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 reported to the central console�s log viewer in real time, without the use of third party software. It can be used to immediately identify alerts, and it contains the ability to filter the data on any of the data-columns such as time, severity, attack type, source, and destination, etc� simply by right-clicking on the log viewer and selecting your filters.

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)?
NetScreen-IDP�s management automatically aggregates all logs/alerts from all of the Sensors and presents them in single log viewer.

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)?
NetScreen aggregates the information from all of the sensors and correlates it to identify overall trends. It then presents this information in a summary, dashboard view, to help organizations immediately see what is being attacked, who is attacking and what they are using. As a result, organisations can drill into the incidents that are of interest to them and quickly get to the specific logs associated with the event to understand what is going on and make swift security decisions to close out the incident. 

(NSS COMMENT: This is an aggregate and summarise capability only - there is no automatic correlation in the current version)

Can alerts be correlated manually by the administrator - grouped together in the database as a single event for further investigation?
This capability is not currently available in NetScreen-IDP.

Can alerts/events be annotated and tracked for investigation by multiple administrators/investigators?
Yes, the logs can be annotated and tracked for investigation by multiple users in several ways. There is a notes column that an administrator can write in to instruct, inform, update, etc. on an incident. There are configurable flags that the customer can define as they wish, for example, to identify different owners of incidents, criticalities, status, etc.

Does the software offer advice on preventative action to ensure the attack does not happen again?
For each alert, NetScreen provides links to standard external sources of reference information (CVE, etc)

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?
NetScreen-IDP currently does not support this functionality.

Which third party event correlation systems are supported and in what way?
NetScreen-IDP currently does not support this functionality.

Integration with other scanning/IDS products?
NetScreen-IDP currently does not support this functionality.

Log file maintenance - automatic rotation, archiving, reporting from archived logs, etc.
Log files can be manually archived from the IDP Management Server.  A log file is created for each day and is automatically rotated.  Reporting can be performed on archived data by copying the archived data back to the IDP Management Server and executing a report.  Additionally NetScreen enables customers to export the IDP Logs into CSV format or Postgress SQL database for integration with their existing reporting systems.

Management reporting - range of reports/custom reports/how easy is it to filter and extract detail? Different reports for technicians and management/end users?
NetScreen-IDP provides nine different types of Executive Reports:

These reports can be customized for the range of log data to be graphed, data origin (the sensor which the data was taken from), the interface on which the data was received on (internal or external), the top X number to be graphed, and the graph type (pie or bar).  Following is an example of the Top Attacks Report.

The NetScreen-IDP also provides Investigative Reports for forensic analysis.  NetScreen�s Log Investigator provides the ability to see enterprise security at a high level and then drill down to specific threats and view them from various standpoints.  Customers can correlate the attacker and the victim against the types of attacks used against them, so the impact of attacks is immediately evident. The two axis of the report can be configured for different data.  In all, there are 15 permutations of the following axis:

From this top report, the user is able to drill down on any subset of data contained in the report, i.e. the 3^rd axis of the report.  Also, it is possible to view the data in the log viewer.  In this case, a log view is automatically generated with the appropriate filters to show only the data selected in the Investigative Report.  Following is an example of the Investigative Report:

The customer can zoom in to see the details surrounding an individual cell, row or column to better understand your network threats.

Are trend/comparison reports available?
This capability is not currently available in NetScreen-IDP.

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?
The logs can be filtered to show the administrator the information they are looking for, so they could filter the logs to show traffic coming from a specific source address, going to a specific network resource on a specific date.

Report management - can they be scheduled for automatic production? Can they be e-mailed to administrators or published straight to a Web site?
The management reports are canned reports that can be generated real time and then exported into HTML to be e-mailed or used outside of the system.

What are the limitations and restrictions on enterprise-wide alerting and reporting? Can reports consolidate output from every 1) server, 2) detector
Reports are currently generated with information from all IDP Sensors managed by a certain IDP Management Server. 

Ability to define custom reports?
This capability is not currently available in NetScreen-IDP. However one could export log information to CSV or a Posgres SQL Database for use with third-party reporting systems.

Provide brief description of any management software included in the base price of the product. 
NetScreen-IDP�s management server, with all of the features and benefits previously described, is included in the price of the solution, up to 10 sensors.

Provide brief description of any additional management products available as extra cost options. 
A nominal licensing fee is charged for NetScreen-IDP�s management to manage more than 10 sensors. The fees are based on 11-25 sensors, 25-100 sensors and more than a 100 sensors.

Documentation provided

NetScreen provides hard and soft copy documentation of the following: 

�          NetScreen-IDP Concepts & Examples Guide (Hard Copy Book / PDF)

�          NetScreen-IDP Users Guide (Hard Copy Book / PDF)

�          NetScreen-IDP Quick Start Guide (Hard Copy  Pamphlet / PDF)

�          Release Notes (Hard Copy  Pamphlet / PDF)

�          Upgrade Notes - if applicable (Hard Copy Pamphlet / PDF)

�          NetScreen-IDP Hardware Guide (Hard Copy Pamphlet / PDF)

�          IDP FAQ  - Web site (Online / PDF Archives) 

How is the product licensed? How is the license enforced?
NetScreen-IDP is licensed per Sensor.  Three models of IDP Sensors are available depending on bandwidth and session capacities.  The management server is also licensed per Sensor; however it is included free of charge for up to 10 Sensors.

End user pricing information

NetScreen-IDP 10 US List Price $7,995

NetScreen-IDP 100 US List Price $16,495

NetScreen-IDP 500 US List Price $34,995

Ongoing cost of maintenance/updates

NetScreen-IDP 10 HW Maintenance/SW Subscription/Support US List Price $400/$1200/$800

NetScreen-IDP 100 HW Maintenance/SW Subscription/Support US List Price $825/2500/$1650

NetScreen-IDP 500 HW Maintenance/SW Subscription/Support US List Price $1750/$5250/$3500

Click here to return to the NetScreen Review
Click here to return to the IDS Index Section