Intoto IntruPro V3.0

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)
IntruPro is a software product which was supplied on reference hardware. The hardware appliance had Dual Xeon 3.06 GHz, 2 GB RAM with 2 Copper GigE, 2 Fiber GigE and one 100 Mbps management port. 

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?
In-line mode only 

What is the maximum number of in-line connections (port pairs) that can be monitored by a single sensor?
1 

What type (copper/fibre) and speed of network connection are supported by the sensor (include default configuration plus any options)?
IntruPro is OS and hardware agnostic and can be configured to work with different type of hardware. 

What High Availability (HA) features are built in to the product by default?
High Availability is a system level feature and can be added by the OEM. IntruPro is delivered as a software component in the system. 

What High Availability (HA) features are available as extra cost options?

N/A 

What is the maximum speed/network load (Mbps) claimed with zero packet loss and without blocking legitimate traffic?
100 Mbps on the reference hardware 

At the maximum load, what is the maximum TCP connection rate through the device (connections per second) claimed?
1700 connections 

What is the average latency claimed through the device (and at what load)?
200 micro seconds approx 

Management architecture (2-tier/3-tier management? Brief description)
IntruPro manager is three tier management architecture. IntruPro manager is a simple graphical user interface consisting of console, log listener and a database. The java based console is used to configure the sensor and to analyze and receive log messages from the sensor. OEM vendors can change the look and feel of the interface or can also integrate their existing management software or web based interface using APIs provided by the sensor.  

What are the minimum/recommended sensor OS and hardware requirements? Is a dedicated machine required/recommended?
IntruPro is operating system and hardware agnostic. A dedicated hardware with at least two network interfaces is required to install the sensor software. 

What are the minimum/recommended console OS and hardware requirements? Is a dedicated machine required/recommended?
Windows 9x / Me or Windows NT family (Windows NT, 2000, and XP), 512 MB RAM (system memory) - 1GB or greater recommended, Pentium III or faster CPU, MySQL database server or PostGreSQL database server, Java Run-time Environment (JRE) 1.4. A dedicated machine is not required.  

What are the minimum/recommended management server OS and hardware requirements (if applicable)? Is a dedicated machine required/recommended?
Windows 9x / Me or Windows NT family (Windows NT, 2000, and XP), 512 MB RAM (system memory) - 1GB or greater recommended, Pentium III or faster CPU, MySQL database server or PostGreSQL database server, Java Run-time Environment (JRE) 1.4. A dedicated machine is required.  

List required open ports on sensor and their use
Port 2009 is used for communication between the sensor and the management components. 

List required open ports on management server (if applicable) and their use
Port 2011 is used for sending the log generated by the sensor to the Management server 

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

Communication protocol between sensor and management server
Intoto proprietary protocol is used for communication between the sensor and the manager. 

Communication protocol between management server and GUI/console
Intoto proprietary protocol is used for communication between the server and GUI.  

Encryption between sensor and management server
The communication is secured using a pre-shared secret based encryption. 

Encryption between management server and GUI/console
The communication is secured using a pre-shared secret.  

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

Capacity of the system? How many endpoints can be monitored? Ratio of endpoints to management servers/consoles, etc.
Maximum of 16 sensors can be managed with a single management interface.  

How many management consoles can be actively logged in to the management server at the same time?
In the current release only one console can actively log on to the server.  

What anti-flooding methods are employed (sensor to management server, and management server to console)?
Bandwidth reservation in the sensor ensures communication between the two. 

Maximum insertion rate into alerts database
1000 logs per second 

Maximum size of database
The size of the database is restricted by the hard disk capacity of the server it is installed on.

Maximum number of alerts stored
Alerts can be scheduled for a periodic backup. The limit of maximum number is determined by the disk capacity.  

What happens to alerts in main alert database once capacity limits exceeded (deleted/archived/etc)
Automatic back up can be scheduled and the oldest logs are deleted.  

What is maximum recommended size of alerts database to maintain acceptable query performance?
500,000 

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)
A separate tool called log viewer can look at the archived log messages.  

Which database product is used for alert storage? Is schema open?
MySQL and Postgresql are the supported databases. Schema is Intoto proprietary.  

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?
The sensor stores messages in the event connection is lost to the management server. The older logs get deleted if the connection is not restored. However, the size of the buffer that stores the remnant logs is configurable and can be increased if the hardware allows.  

Secure logon for policy management?
Yes. Password requires 8 alphanumeric characters.  

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.)?
Role based management is not available in the current version.  

Is it possible to define multiple policies for the sole purpose of distributing to multiple sensors with different functions?
No 

How are policies distributed to sensors?
The policies have to be applied by the management console. Management console allows enable/disable of signatures on per sensor basis which can be uploaded to sensors or can be uploaded through the CLI.  

Can policies be deployed on a per-port, per-sensor or per-group basis, or globally only?
Policies are not used - configuration is directly on Sensor, and is per-Sensor only.  

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?
Manual distribution available only.  

Can policy deployment be scheduled?
No 

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?
The sensor removes all the signatures and uploads new signatures. The action to drop or pass traffic during this time is configurable option that can be decided by the OEM vendor. The inactivity time is in fraction of second but could be longer if the device is under a data flood attack. 

Can the administrator define custom attack signatures?
Yes.  

Regex supported when creating custom signatures?
Regular expression is supported for custom signature. 

How are new vendor attack signatures obtained and deployed?
Signature is written for newly published vulnerabilities or exploits and updated on the centralized signature update server. Intrupro Management console can connect to the signature server and get the update.

Frequency of signature updates?
1 week 

What infrastructure does the vendor have behind the signature update process (i.e. dedicated team of engineers? How many? Does it have a name?)
Intoto has a dedicated team of signature writers to analyse and keep track of new vulnerabilities.  

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?
Yes the file can be downloaded to a local network and used to update all sensors from a central location. It does not need live connection to the Internet.  

Can signature updates be scheduled and fully automated? Is automated download AND deployment to sensors supported, or just download (or neither)?
No  

What network protocols are analysed?
IP, TCP, UDP, ICMP, HTTP, SMTP, POP, SNMP, FTP, IMAP, RPC, DNS, NNTP, IMAP, NetBIOS and SMB. 

What application-level protocols are analysed?
IP, TCP, UDP, ICMP, HTTP, SMTP, POP, SNMP, FTP, IMAP, RPC, DNS, NNTP, IMAP, NetBIOS and SMB. 

Can the product perform protocol decodes?
Yes 

Can the product perform protocol anomaly detection?
Yes 

Can sensor support both normal and asymmetric network configurations?
Normal only 

Is the detection engine “stateful”? If so, please explain how this works.
Yes. The detection engine keeps state of the connection and also in case of supported protocols, it keeps protocol information.

If stateful - how many open connections can be tracked? Is this value configurable?
45000. This value is configurable and dependent on the system configuration. 

If stateful - for how long are partially opened connections tracked? Is this configurable?
Default value is 30 sec. This value is configurable.  

If stateful - for how long are fully opened connections tracked if not used? Is this configurable?
Default value is 600 sec.  This value is configurable.  

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?
Block new connection. 

What is the default action when power fails or the system is powered down - block or permit all traffic? Is this default action configurable?
Block. The system is inline and will not process packets if powered down.  

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?
During signature update the traffic is permitted to go through.   

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)?
The engine will alert on all the suspicious activity.  

Are server responses monitored and alerted/blocked? Does this have an impact on performance?
The server response processing can be enabled or disabled. It does have impact on performance.  

Ability to monitor user-defined connections (i.e. report on an FTP connection to a specific server?)
Yes. The port map record allows creation of user-defined rules. 

Detect/block network-level packet based attacks?
Yes. 

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

Detect/block SYN floods? Manual or automatic thresholds? Configurable? How is SYN flood protection implemented?
Yes. Manual threshold can be configured through SYN flood filter. This filter tracks the number of partially open connections to detect the SYN flood. SYN flood protection is implemented using SYN cookies method. After the SYN flood is detected, the device receives SYN connections from the client and sends proxy SYN-ACK on behalf of the server. Until an ACK is received from the client, the connection is not processed. The sensor acts as a proxy. This behaviour is triggered only if the SYN flood attack is detected. In the normal course of traffic, all the packets are processed without any proxying.  

Perform packet/stream reassembly?
Yes. 

Perform deobfuscation?
Yes. 

Is all traffic scrubbed/normalised/reordered as it passes through the sensor?
Yes. 

How is fragmented traffic handled by the sensor?
Packets are re-assembled before sending to the IPS module.  

List all prevention features available (alert only, drop packets, block TCP session)
Ignore, report only, drop packet and drop connection are four methods supported. 

List any other security features available (bandwidth shaping, rate limiting, etc.)
IntruPro can be integrated with any of Intoto’s security product such as the iGateway Firewall, iGateway VPN, iGateway SSL VPN and iGateway AV/AS. 

Packet capture capabilities? Only the trigger packet, or before and after? How are packet captures stored/viewed?
No. Only trigger Packet data is available in the log message. .For some application traffic, buffered application data is sent in the log message. 

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?
We do show context data. For example, if there is any vulnerability detected in HTTP flow, we show the URL and current packet contents. In case of FTP, we do show quite a bit of context data, but not the user name and password. 

Option to record entire sessions for “forensic” investigation? Where is this data stored? How is it secured from tampering?
Sessions are not recorded. 

Reporting from sensor to console - range of alert response options (detail these, i.e. log, alert, e-mail, pager, packet capture, etc)
Logs generated by sensor are sent to the management console which can be emailed to the administrator. The log messages have packet capture data as well as attack information. 

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)?
Mixture of the three.  

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. Individual events can be filtered based on different log fields.  

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 alerts/logs can be received on the single console interface. 

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?
The central console can correlate the alerts based on the same Source IP address, Rule ID, time of the attack etc. This is a standard feature at no extra cost.

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?
No. 

Does the software offer advice on preventative action to ensure the attack does not happen again?
No. 

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?
None. 

Which third party event correlation systems are supported and in what way?
None at this time. 

Integration with other scanning/IDS/prevention products?
None. 

Log file maintenance - automatic rotation, archiving, reporting from archived logs, etc.
Automatic backup of the database file.  

Management reporting - range of reports/custom reports/how easy is it to filter and extract detail? Different reports for technicians and management/end users?
Report fields are configurable to have information related to specific sensor or specific attack type. 

Are trend/comparison reports available?
No. 

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?
No 

Report management - can they be scheduled for automatic production? Can they be e-mailed to administrators or published straight to a Web site?
The report can be emailed to the administrator but automatic generation is not possible. 

List the output formats supported for reports (HTML, text, PDF, etc)
HTML reports. 

What are the limitations and restrictions on enterprise-wide alerting and reporting? Can reports consolidate output from every 1) server, 2) detector
Yes. Reports from several sensors can be consolidated.  

Ability to define custom reports?
Yes. 

Provide brief description of any management software included in the base price of the product. 
IntruPro Manager 

Provide brief description of any additional management products available as extra cost options. 
None. 

Documentation provided (Hard copies available? Extra cost?)
Management administration guide in electronic format is provided at no extra cost. 

How is the product licensed? How is the license enforced?
Per sensor 

End user pricing information for product provided for test (include all sensor, management server and console costs for both hardware AND software). Include options/configurations other than those tested - ALL PRICES AS LIST PRICE ONLY!
N/A - for sale to OEM partners only 

Ongoing cost of maintenance/updates
N/A - for sale to OEM partners only

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