[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE] [IMAGE] Security Threat Manager 3.0 [IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE]
[IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE]
[IMAGE]

Gleaning security intelligence from disparate sources means slogging through endless logs from firewalls, IDSes, routers, switches and other devices in numerous formats for nuggets of critical information. OpenService's Security Threat Manager (STM) 3.0 distills this mass of raw data into actionable threat information in real time.

STM gathers and normalizes data, correlates the various inputs, and ranks the criticality of security events. It assembles a table with accumulated behavior data across the entire range of sources and "builds the case" for elevation to event criticality, spawning a predetermined action, such as an e-mail alert, or triggering a script for automated response.

We were impressed with STM's functionality, but don't expect out-of-the-box results. This is a complex product and needs to be configured for specific enterprise environments and corporate security policies.

The STM engine requires significant tuning, and OpenService requires that installations are done by field engineers. Integrating the diversity of devices and data collection methods that STM supports requires a deft hand and lots of experience. There ...

That being said, it wasn't long before our multiplatform test network started producing data, which was then analyzed for signal/noise quality. This step is a semiautomated process, owing to the incredibly diverse number of inputs STM can manage.

Large and multisite networks can have logs/data source traffic added automatically via VPN, VLAN, etc., but STM doesn't import LDAP, Active Directory, NetInfo or other host information files.

We tested the Red Hat Linux version (Windows 2000 and Server 2003, and Solaris 2.8 are supported) on a Hewlett-Packard DL380 (twin Xeons and six GB of DRAM). Many kinds of input sources can be used, ranging from SNMP traffic to Cisco Systems' PIX output; we used Secure Computing's Sidewinder G2 firewall, as well as Snort, syslog, SNMPv3 messaging and iptables.

[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE] [IMAGE] Exec Summary [IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE]
[IMAGE] [IMAGE] [IMAGE] Highly scalable
[IMAGE]
[IMAGE] [IMAGE] [IMAGE] Broad device support
[IMAGE]
[IMAGE] [IMAGE] [IMAGE] Actionable alerts
[IMAGE]
[IMAGE] [IMAGE] [IMAGE] Complex, requires vendor installation
[IMAGE]
[IMAGE] [IMAGE] [IMAGE] High TCO

[IMAGE]

Snort took a long time to correctly configure with syslog because we chose a complex installation to emulate a remote sniffer, but iptables and Secure Computing's logs integrated in a few clicks. STM fired rapid alerts on infected machines, based on data correlated from Snort and Sidewinder, and found exploits on our internal Windows Server 2003 platforms.

The console allows a security manager to refer immediately to an alert's source. Alerts are divided into logical groups by such classifications as geography and threat importance.

STM is expensive, but its wide device support and robust delivery of intelligence will give enterprises full value for their security investment.

--Tom Henderson