Security Threat Manager 3.0 costly and complex but worth the investment

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.

  • Register to attend Burton Group analyst Diana Kelley's webcast on the

    Requires Free Membership to View

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 are many individual source idiosyncrasies that need to be resolved to make STM work.

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.

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.

This was first published in April 2005

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.