Juniper Networks IDP 600F V3.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 IDP 600 is supplied as a network security appliance and comes in two fixed configurations.

�          IDP 600C comes with 12 interfaces: 10 copper 10/100/1000 traffic interfaces), as well as a dedicated
      HA interface and a dedicated management interface

�          IDP 600F comes with 12 interfaces: 8 Fibre SX Fibre Interfaces plus 2 copper 10/100/1000 interfaces as
      well as a dedicated HA interface and a dedicated management interface

�          Intel Xeon 3.2Ghz Processor

�          800 MHz bus

�          4 GB Memory

�          Redundant Power 

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?
The IDP can be used both in an in-line and a sniffer (passive) mode. To take full advantage of the complete IDP feature set, the recommended mode of operation is an in-line deployment, at any critical point within a network. In an in-line mode, IDP can detect and prevent attacks before they reach their victim, dropping the packet or connection containing the malicious attack as soon as it is detected.  There are four in-line deployment options: Bridge, Transparent, Proxy-ARP and router, which are outlined below: 

�    Transparent and Bridge Modes: An in-line operating mode of the IDP system. In this mode, IDP automatically learns the network topology and forwards packets to their correct destination. In Bridge and Transparent modes, the IDP is transparent and no reconfiguration needs to be done to let the hosts know that it is there. Moreover, the hosts are not aware that the IDP is even on the network.  For the IDP system, the transparent mode is the easiest to deploy and is the recommended mode of operation.  Using third party load balancing solutions, IDP can be installed in a High Availability configuration in Bridge and Transparent mode.

�    Proxy-ARP Mode: An in-line operating mode of the IDP system. In this mode, IDP automatically learns the network topology and forwards packets to their correct destination, just like it does in Bridge/Transparent Modes.  However, unlike Bridge/Transparent Modes, the host machines are aware that the IDP is on the network in Proxy-ARP Mode. IDP automatically reconfigures the host machines to send it all packets that need to be forwarded. Proxy-ARP mode typically has higher throughput performance than Bridge/Transparent Modes, but only works with networks where all traffic is routed through a single router. The IDP can be installed in Standalone High Availability configuration in Proxy-ARP mode.

�    Router Mode: An in-line operating mode of the IDP system. In Router mode, IDP acts as a router. This means it uses a routing table to determine where the packets need to be sent and then forwards the packets to the correct destination.  All of the hosts that are attached to IDP, when it is in Router Mode, need to be configured to forward their packets to IDP, otherwise the hosts will not be able to send any traffic.  Router mode is traditionally associated with older security devices, such as Firewalls, and is only offered in IDP for compatibility. The IDP can be installed in a High Availability configuration using third party load balancing solutions or in a standalone HA configuration in Router mode. 

The IDP 600 can be deployed in sniffer mode and as such, will utilize all the detection and analysis capabilities inherent in IDP.  When deployed as a sniffer, IDP will act as an IDS, detecting malicious traffic as it traverses the network as opposed to detecting AND preventing it (IPS). 

What is the maximum number of in-line connections (port pairs) that can be monitored by a single sensor?
IDP 600C - 10 10/100/1000 Copper ports (5 pairs)

IDP 600F - 8 Fibre SX ports + 2 10/100/1000 Copper ports (5 pairs) 

What type (copper/fibre) and speed of network connection are supported by the sensor (include default configuration plus any options)?
IDP 600C - 10 10/100/1000 Copper ports default, no options

IDP 600F - 8 Fibre SX ports + 2 10/100/1000 Copper ports default, no options 

What High Availability (HA) features are built in to the product by default?
When operating in-line, it is essential that the traffic is not interrupted by device failures.  It is therefore possible to deploy the IDP system in a high availability (HA) configuration to provide failure protection, either in a standalone configuration or using third-party hardware.  A high availability configuration consists of two to sixteen Sensors joined together in a HA cluster that provides failure protection and/or load balancing.  In load balancing mode, all Sensors in the cluster share network traffic equally, and if a Sensor fails, network traffic is redirected to the other Sensors in the cluster. With hot standby, a primary Sensor handles all network traffic while a secondary Sensor stands by.  If the primary Sensor fails, network traffic is redirected to the secondary Sensor.  

State information is shared between Sensors in the cluster using state-sync interfaces, which are dedicated for HA communication. High availability configurations are available for transparent, bridge, router, and proxy-ARP deployment modes.

Also available when operating in bridge mode (Copper Ethernet Ports only) is internal bypass - the ability to fail-open, if traffic flow through the IDP appliance is disrupted.   

What High Availability (HA) features are available as extra cost options?
All HA features are included in the base product.   

What is the maximum speed/network load (Mbps) claimed with zero packet loss and without blocking legitimate traffic?
The maximum throughput is 500Mbps 

At the maximum load, what is the maximum TCP connection rate through the device (connections per second) claimed?
At maximum load, the TCP connection rate is 10,000 connections per second (NSS note: Whilst this may be possible with connections with very small response sizes, a limit of approximately 8,000 connections per second was observed in testing with more “real world” traffic) 

What is the average latency claimed through the device (and at what load)?
The average latency through the device is 100 microseconds at 9% load 

Management architecture (2-tier/3-tier management? Brief description)
IDP uses a three-tier architecture that consists of the IDP sensor, IDP Manager Server, and the IDP User Interface.

�    IDP Sensor - Monitors the network on which the IDP system is installed. The sensor is a hardware appliance that runs the Linux based IDP Sensor Software.

�    IDP Management Server - stores and manages all of Attack Objects (including attack signatures and protocol anomalies), log information, rulebases, and Security Policies.  Multiple Sensors can be managed by a single Management Server

�    User Interface (UI) - graphical interface for interacting with the IDP system.  The UI is used to access remotely and manipulate the information stored on the Management Server. 

What are the minimum/recommended sensor OS and hardware requirements? Is a dedicated machine required/recommended?
No dedicated machine or OS is required.  The IDP sensor is a fully self-contained network security appliance that is preconfigured with all necessary software and hardware components  

What are the minimum/recommended console OS and hardware requirements? Is a dedicated machine required/recommended?
The IDP UI can be loaded onto any Windows 2000/XP or RedHat 7.2, 8 or RHEL 3.0 machine.  Juniper Networks 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 IDP Management System requires an enterprise class server running Sun Solaris 8/9 (SPARC) or Linux RedHat 7.2, 8 or RHEL 3.0 (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
The following ports are used for communication between the Management Server and the Sensors:

�          UDP 7201

�          UDP 7202 

List required open ports on management server (if applicable) and their use
The following ports are used for communication between the Management Server and the Sensors:

�          UDP 7201

�          UDP 7202 

List required open ports on GUI/management console and their use
The following port is used for communication between the Management Server and the GUI/management console:

�          UDP 7203 

Communication protocol between sensor and management server
The communication protocols between the Sensor and Management Server is proprietary and unique to Juniper IDP.   

Communication protocol between management server and GUI/console
The communication protocols between the Management Server and GUI/console is proprietary and unique to Juniper IDP.   

Encryption between sensor and management server
Management Server communication with the other two tiers of the IDP system (the Sensor and User Interface) is AES 256bit encrypted and SHA-1 authenticated to provide an additional level of security. 

Encryption between management server and GUI/console
Management Server communication with the other two tiers of the IDP system (the Sensor and User Interface) is AES 256bit encrypted and SHA-1 authenticated to provide an additional level of security. 

Once deployed and configured, can sensors be managed from a central console?
The Management Server centralizes the logging, reporting, data, and Security Policy management for the IDP system. All objects, Security Policies, and log records are stored on the Management Server and are administered using the User Interface.  

Capacity of the system? How many endpoints can be monitored? Ratio of endpoints to management servers/consoles, etc.
The total number of sensors is dependent on the size of the Management Server and the mean number of traffic flowing through them.  Juniper recommends using one Management Server for every five Sensors. Currently, the largest deployment of IDP sensors has been recorded at 79 sensors to a single management server. 

How many management consoles can be actively logged in to the management server at the same time?
Although the UI supports multiple users, only one user at a time can take control of the Management Server; this eliminates concerns about synchronization or data loss.  

What anti-flooding methods are employed (sensor to management server, and management server to console)?
Juniper’s IDP platform suppresses the same alert if repeated in fewer than 10 seconds.  This option is fully configurable. 

Maximum insertion rate into alerts database
The maximum insertion rate into the alerts database is 20,000/events second 

Maximum size of database
The database is designed in a manner so the total number of events a Management Server can store is limited by the disk space and not the method of indexing utilized on the database.  For example, a report on the top 10 largest sources from the past week will finish processing in only a few seconds.  

Maximum number of alerts stored
The maximum number of alerts stored is limited by system size.  Juniper has tested systems with more than 320,000,000 events on a single management console.  Operations (queries) that involve accessing all 320M events were very time consuming (2 minutes or more) while the most recent 1M events were accessible in close to real time.   

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?
200Mb or less is the recommended database size for the most optimal results.   

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)
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 IDP’s log viewer and reporting tools. 

Which database product is used for alert storage? Is schema open?
The database used is proprietary to Juniper; however, logs can be exported to CSV file or a PostgreSQL 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. 

In the event of communication failure between the sensor and the management server, all alerts (log events) are queued until the communication link between the sensor and the management server is restored.  Since there are10 Gigabytes of disk space available on the sensor to queue alerts, and each alert is about 130 bytes in length on average, even with heavy logging, and a “noisy” security policy (one which logs most events), there is plenty of queue space for at least several days of logs 

Secure logon for policy management?
Yes, secure logon for policy management is provided. 

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.)?
IDP Manager allows enterprise IT departments to delegate appropriate levels of administrative access to specific users ranging between read-only or full read/write capabilities. 

Is it possible to define multiple policies for the sole purpose of distributing to multiple sensors with different functions?
Yes, multiple policies can be defined and assign to specific sensors as needed 

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-port, per-sensor or per-group basis, or globally only?
The organization of the policies allows them to be distributed globally, on a per sensor basis, per group basis, or any combination of the preceding schemes.  For example, an organization 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. This flexibility ensures that the device is protecting the network to the organization’s exact demands. 

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?
Yes, The IDP automatically implements any edits to an existing Attack Object in a Dynamic Attack Object group or Security Policy. IDP also automatically implements any additions, edits, or deletions to Attack Objects that comprise Dynamic Attack Object groups. 

Can policy deployment be scheduled?
Policy deployment can be scheduled (updates and downloading), but this is an undocumented feature, scheduled to be supported later this year 

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, 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. Once the new policy is loaded, all new sessions are processed against the new policy.  After the sessions timeout, the old policy is removed from memory.   

Can the administrator define custom attack signatures?
IDP utilizes an open signature format, which exposes how the signature and attack interact, allowing administrators to modify the signature to better suit their needs.  Access to over 500 contexts (protocol service fields) as well as a Signature Editor is provided to aide in the creation of custom attack signatures.  You can view, create, edit, or delete signature Attack Objects using the Signature Editor Dialog box in the User Interface.  The open signature format also accelerates attack investigation by providing greater visibility into what pattern the administrators should look for.  Another example is the vulnerability database- we have taken a leveraged, open approach to providing a broad set of vulnerability data from both internal and external sources so that users can get the data in a way that is most appropriate for them.   

With the customization capabilities, an administrator can view, edit, and create signature Attack Objects. All Attack Objects, including the ones created by an administrator, are stored in the Attack Object database.  Most alternative offerings provide little or no visibility into their signatures thereby limiting the customer flexibility. 

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

How are new vendor attack signatures obtained and deployed?
To update your Attack Object database, an automated Attack Update Client is provided which searches the existing Attack Object database and automatically downloads new or modified Attack Objects. The Attack Update Client is easily accessed from the Tools menu of the console UI. You can also set a Preferences option so that the IDP UI automatically checks for new updates every time you start it. 

Frequency of signature updates?
Juniper Networks is the only IPS vendor that provides signatures updates on a daily basis.  In addition to the daily signature updates, urgent notifications are sent to customers if an emergency update becomes available, and weekly summary updates are also provided.  

What infrastructure does the vendor have behind the signature update process (i.e. dedicated team of engineers? How many? Does it have a name?)
Juniper's IPS group has a dedicated SABRE (Security Audits, Blueprints and Response Engineering) team whose sole mission is to provide oversight and ensure Juniper's products including its IPS platform is itself secure. SABRE does design reviews with Engineering, pro-active security audits of the IDP products, and handles security vulnerabilities discovered by customers and other third parties, such as Trusecure and CERT.  This provides a conduit between the IPS team and Juniper's SIRT (overall company wide Security Incident Response Team). 54 employees are dedicated to the signature creation, testing and updating process.  These employees have long track records in the security and research industry and are active in open source initiatives. 

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?
The updated attack objects can be downloaded from the internet and updated to the management server even if the management server doesn’t have a direct connection to the Internet.  The GUI still installs it on the management server, but it can be configured to load from a local file instead of the Internet.  The GUI also supports downloading via a HTTP proxy if that is the architecture in place.   

Can signature updates be scheduled and fully automated? Is automated download AND deployment to sensors supported, or just download (or neither)?
Signature update on a schedule can be automated with the tools available today, though it is not a supported feature until later this year

What network protocols are analysed?
IDP supports attack prevention for the following network-level protocols:

�          ICMP

�          ARP

�          IP 

What application-level protocols are analysed?
IDP supports attack prevention for the following application-level protocols:

�          AIM

�          DHCP

�          IDENT

�          RUSERS

�          TFTP

�          FINGER

�          CHARGEN

�          IMAP

�          Gnutella

�          RLOGIN

�          FTP

�          DISCARD

�          Gopher

�          RPC

�          HTTP

�          DNS

�          POP3

�          IRC

�          RSH

�          ICMP

�          BOOTP

�          ECHO

�          ISAKMP

�          LDAP

�          REXEC

�          MSN

�          RTSP

�          LPR

�          NFS

�          VNC

�          NNTP

�          SNMP

�          SMTP

�          SMB

�          SNMP TRAP

�          YMSG

�          TCP segment

�          SYSLOG

�          SSH

�          TELNET

�          SIP

�          NetBIOS

�          IKE 

Can the product perform protocol decodes?
Yes, protocol decodes are done to detect abnormal or ambiguous messages within a connection according to a set of default rules. The IDP system includes several hundred protocol anomaly Attack Objects to detect unknown attacks.  

Can the product perform protocol anomaly detection?
Yes, includes Protocol anomaly Attack Objects designed to detect unknown attacks, and identify unusual activity on your network. IDP uses protocol anomaly detection (also called protocol analysis) to determine illegal or ambiguous packets that can constitute security threats by checking them against the protocol RFCs or the definitions imposed by the network administrator. IDP includes all known protocol anomalies as protocol anomaly Attack Objects in the Attack Object database. 

Can sensor support both normal and asymmetric network configurations?
Yes, a sensor can support both normal and asymmetric configurations.  Asymmetric configurations are supported only when done on a single device 

Is the detection engine “stateful”? If so, please explain how this works.
Yes, the IDP appliance has a Stateful detection engine.  Stateful Signatures provides pattern matching by extracting the application message from the traffic to only look for the attack in the appropriate portion of the traffic where the attack can appear. Unlike a pure bit pattern search or a content offset search into the header or payload, Stateful signatures leverages the ability to interpret the traffic to discern and extract the application message states. A Stateful signature is able to deduce the application message state from the individual packet to tell the difference between whether or not the session is in the control portion of the application message, or the difference between a client to server vs. server to client communication.

If stateful - how many open connections can be tracked? Is this value configurable?
The number of sessions (combination UDP, TCP, ICMP) that NetScreen-IDP 600 supports is a maximum of 220,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 session states are maintained for up to 1 hour if no traffic is sent and then discarded. This is configurable in the policy under the Sensor Settings tab. 

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 default option is block traffic and it is not configurable.  IDP will never permit traffic through the system unanalyzed unless it is not running. (NSS note: It is not necessary to allow traffic through the device unanalysed when resources are exhausted - another approach is to age out old connections and thus permit new connections whilst continuing to analyse. Increasingly, vendors are offering a choice between these two approaches, leaving it to the administrator to decide) 

What is the default action when power fails or the system is powered down - block or permit all traffic? Is this default action configurable?
The default option is block traffic and it is not configurable. 

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?
IDP does not stop inspecting traffic due to a policy push. The default option is to block traffic based on the loaded policy and it is not configurable.  

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)?
In IDP’s rule-base, the customer can define exactly how they want the system to respond when attacks are detected, so an administrator can a set the policy to alert only on the suspicious activity in which they are interested. Unlike systems that force a customer to either look for an attack or not, IDP gives administrators the flexibility to look for attacks in the areas in the network where they are vulnerable. For example, an administrator can 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/blocked? Does this have an impact on performance?
Yes. IDP tracks both sides of the connection and has signatures that trigger based on the servers response. (NSS note: There is a significant performance impact when using HTTP server-to-client signatures (other protocols have less effect), and Juniper has now provided a sensor setting to disable all HTTP server-to-client processing where maximum performance is paramount in a purely internal (i.e. non-perimeter) deployment) 

Ability to monitor user-defined connections (i.e. report on an FTP connection to a specific server?)
Yes, 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/block network-level packet based attacks?
Yes, the sensor can block network level attacks such as ICMP attacks or network sweeps. 

Detect/block all types of port scans (full connect, SYN stealth, FIN stealth, UDP)?
Yes, the IDP’s Traffic anomaly detection rulebase identifies and can block intrusions that occur in traffic spanning multiple sessions, such as port and network scans.  For these types of attacks, the IDP recognizes patterns detected within the overall traffic flow and sends alerts based on frequency and threshold triggers. 

Detect/block SYN floods? Manual or automatic thresholds? Configurable? How is SYN flood protection implemented?
IDP can detect and block SYN Floods. Because IDP is a Stateful system, which means that it tracks the state of each connection, it can determine if the 3-way TCP handshake has been completed for all TCP connections. IDP can detect SYN Flood attacks and drop these sessions.  The IDP appliance has both automatic and manual thresholds that are fully configurable. 

Perform packet/stream reassembly?
Yes.  IDP performs reassembly, which reconstructs streams to interpret data exactly as the destination machine would interpret it. It also normalizes 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. The device also supports regular expression to perform logical pattern matching for greater flexibility and control over how signatures are defined.  

Perform deobfuscation?
Yes, the IDP appliance performs deobfuscation by normalizing traffic. 

Is all traffic scrubbed/normalised/reordered as it passes through the sensor?
The sensor performs normalization, the removal of extraneous characters and alternate representations of data to ensure there is no confusion as to what the packets contain. This enables the sensor to use one signature where multiple signatures may have previously been required. For example, for the HTTP protocol, the IDP sensor normalizes the URL portion of the packet to decode hex encoding of characters and conversion of the URL path into canonical form. 

How is fragmented traffic handled by the sensor?
The sensor does accurate reconstruction of streams to interpret the data exactly as the destination machine would interpret it. 

List all prevention features available (alert only, drop packets, block TCP session)
The following eight prevention features are available on the IDP appliance:

1.         Drop Connection

2.         Close Connection

3.         Close Server

4.         Close Client

5.         Close Client and Server

6.         Drop Packet

7.         Ignore

8.         None 

The following Administrative options are supported also:

1.         Session Packet Log

2.         Session Summary

3.         Email

4.         SNMP

5.         SYSLOG

6.         Scripting (execute a script)  

List any other security features available (bandwidth shaping, rate limiting, etc.)
The following other security features are supported:

�          Spyware Attack Coverage - Blocks spyware (including adware, keyloggers, etc) on clients and servers from “causing” damage by preventing them from phoning home

�          VOIP Attack Coverage - IDP decodes anomalies in SIP VoIP protocol

o    Decode contains over 10 anomalies which will serve to flag potential attacks and allow us to block this traffic or send alerts

�          Buffer Overflow Emulator - IDP appliance can detect if there is any shell code within network traffic

o   Full support for Linux, Solaris, BSD and Windows

o   Gives IDP a second-level of “>99.x% accuracy” to detect if there is truly malicious traffic within buffer overflows that are detected by IDP 

Packet capture capabilities? Only the trigger packet, or before and after? How are packet captures stored/viewed?

Yes, to facilitate attack investigation and forensics, IDP offers packet capture, with the ability to save in a libpcap format, on a per-rule basis. Packets can be captured before, during and after an attack to see exactly what the attacker was attempting to do on the network. The packet captures can be tailored for each individual rule and length of packets captured per session is user configurable. Packet captures can be displayed using the IDP built-in packet viewer or with 3rd party tools like Ethereal from within the IDP User Interface. The packet captures can also by replayed using any 3rd party tool supporting the libpcap format.

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?
The primary means for viewing context is via Enterprise Security Profiler (ESP), an IDP feature that passively collects real-time network and application data to provide an on-demand view of the traffic that is actually traversing your network.  Using built-in correlation tools within IDP, you can translate that data into security policies that can accelerate the deployment of inline prevention.   

Today, the primary means of viewing ESP data is via the dashboard using filters (IP address, host name, attacker, etc) to quickly drill down into the data stream to gain more visibility into the network activity.  A more graphical means is via Security Explorer which allows users to explore the ESP data using a relational model, allowing the user to see and navigate through the IP-to-Protocol-to-message-to-message value relationships.  A visual representation allows the user to break free from the 2-dimensional representation and linkage of information, providing a more free form way of performing forensic analysis, and a better way of correlating data, especially between the client to message to server relationship that is so important to understanding how an attack occurs.  Security Explorer is accessed from the log viewer and provides a graphical representation of endpoint to endpoint communication, including application layer information, such as username and application type and or version level 

Option to record entire sessions for “forensic” investigation? Where is this data stored? How is it secured from tampering?
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)
IDP provides 5 different 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. 

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 set in the rulebase, so within each rule, the customer tells the system what traffic to look at, what attacks in that traffic to look for, what to do when that attack is identified - including how to alert and who to notify, and where in the network to apply that rule.  

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)?
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)? IS this offered as standard or extra-cost option?
IDP’s management automatically aggregates all logs/alerts from all of the Sensors and presents them in single log viewer. There is no additional cost for this functionality 

Can alerts be correlated manually by the administrator - grouped together in the database as a single event for further investigation?
No.  

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?
The software offers remediation information for attacks found, including which patches to implement to prevent future attacks.

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?
The IDP appliance does not support any of the listed formats.  However, logs can be forwarded to any syslog or SNMP trap listener for archiving, reporting and manipulation, using external software tools.  

Which third party event correlation systems are supported and in what way?
NetForensics, Network Intelligence, ArcSight, GuardedNet, Protego and Micromuse all have support for our products. Through the Juniper Alliance program, these partners proactively support FW/VPN/IDP product releases. 

Integration with other scanning/IDS/prevention products?
The IDP 600C/F is not currently integrated with any other products.  The ISG 2000 FW/VPN platform does support all of the IDP functionality as well as the Stateful FW, DoS and IPSec VPN functionality.  

Log file maintenance - automatic rotation, archiving, reporting from archived logs, etc.
In addition to capturing the logs in the management system, the logs can also be forwarded to any syslog or SNMP trap listener for archiving and reporting. 

Management reporting - range of reports/custom reports/how easy is it to filter and extract detail? Different reports for technicians and management/end users?
IDP provides 15 pre-defined types of Executive Reports (below) and the ability to display a custom created report.

�          Top Attacks

�          Port Scams

�          Top Scan Targets

�          Top Scan Sources

�          Top Rules

�          Top Source IPs

�          Top Attackers

�          Top Attackers (Action: Drop/Close)

�          Attacks over Time

�          Top Targets (Action: None)

�          Top Attackers

�          Critical Severity Attacks

�          Top Targets

�          Top Targets (Actions: Drop/Close

�          Logs by User-set Flag

�          Attacks by Severity

Are trend/comparison reports available?
Yes, trend and comparison reports are available with the 15 predefined reports. 

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, reports generated 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).   

Report management - can they be scheduled for automatic production? Can they be e-mailed to administrators or published straight to a Web site?
Yes, reports can be scheduled and exported in HTML (August release) 

List the output formats supported for reports (HTML, text, PDF, etc)
Reports can be exported in both HTML and PDF format 

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.  The IDP can consolidate output from every sensor for reporting. 

Ability to define custom reports?
Yes, the IDP Manager offers the ability to create custom reports to provide the specific reporting information on log records that the network security environment requires. IDP provides the choice of selecting the type of report and report filters. 

Provide brief description of any management software included in the base price of the product. 
The Management Server centralizes the logging, reporting, data, and Security Policy management for the IDP system. All objects, Security Policies, and log records are stored in databases on the Management Server and are administered using the User Interface. Management Server communication with the other two tiers of the IDP system (the Sensor and User Interface) is encrypted and authenticated to provide an additional level of security. 

The Management Server provides the following functionality:

�          Centralizes management of enterprise Security Policies

�          Consolidates logs from different Sensors in a single repository

�          Simplifies signature and protocol anomaly Attack Object management

�          Enables multiple users to interact with the Sensors

�          Manages multiple Sensors 

The Management Server gathers log records for security events using a proprietary communication mechanism and stores them in a database.  

Provide brief description of any additional management products available as extra cost options. 
All management software is provided at no additional cost. 

Documentation provided (Hard copies available? Extra cost?)

CD ROM-based quick-start guide, concepts and examples guide, IDP Fundamentals, hardware guide, high-availability quick-start guide, RAID Mirroring, upgrade guide (where applicable) 

How is the product licensed? How is the license enforced?
Each Sensor is purchased with a product licence.  Each license is tied to the MAC address of the first Ethernet interface as an enforcement measure 

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!
The list price of the IDP-600 is $48,000 US dollars 

Ongoing cost of maintenance/updates
$7680 (support and maintenance cost 16% of list price, on average)

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