Published: 01 Jan 2002
High above the battleground, airplanes called AWACS (airborne warning and control system) serve as flying centers for surveillance, command and control, giving military commanders real-time information about what's happening in their theater of operations.
In the business enterprise, the IT/security manager is the commander, and the theater of operation encompasses every node, every subnet and every enforcement point across the network. In this battlefield, the front lines extend throughout the enterprise, protected in multiple layers by firewalls, intrusion detection systems and access control lists. The stakes are high: Those who fail to see the complete theater of operations risk costly exploits and exposures of protected data.
The mission is clear-cut: centrally manage security data from disparate access points; analyze and understand attack patterns across the network; respond to emerging threats in real time; and update remote devices when new threats and vulnerabilities emerge. However, the means of achieving these ends remain elusive.
The concept of centralized network and system management isn't new. Network management suites from companies such as Tivoli, Micromuse, Hewlett-Packard, Computer Associates and BMC have long allowed users to manage heterogeneous systems and network gear across the enterprise. At the same time, most security vendors offer some type of centralized management capability for their own (and, at times, their partners') software and hardware.
While network- and vendor-specific security management tools play an important role in many IT infrastructures, they're not engineered to centrally monitor and control heterogeneous third-party security devices -- that is, different types and brands of security tools that perform different functions, run on different OSes and use different formats and protocols for reporting alerts and receiving updates. The market for these so-called security information management (SIM) products is relatively immature, and no two SIM solutions are exactly alike. However, all SIM suites can be categorized within a "Command, Contain, Control" spectrum, performing one or more of these three critical security functions:
Most SIM products perform a Command function by creating a central repository for events generated by different security devices. They deploy agents to "normalize" and retrieve data generated by devices in a variety of formats. Once the events are collected in a central database, they can be examined for patterns. This process is generically known as "event aggregation and correlation": the ability to sort through multiple events and present the root cause, discarding the noise of secondary events through data reduction.
Some SIM tools also have the ability to Contain, to not only evaluate threats but automatically respond to them. Containment allows machine intelligence to dynamically enforce security policies in the face of an emerging threat.
The ultimate objective is Control. Some SIM suites provide the ability to centrally deploy security policies and/or device configurations across the enterprise. Control means that you cannot only observe what is occurring across the enterprise, but execute company policies consistently and uniformly.
New SIM products fulfilling one or more of these functions include:
- e-Sentinel from e-Security
- ActiveEnvoy from netForensics
- SystemWatch from Open Service
- Solsoft NP from Solsoft
- NS Control from Ponte
While several similar enterprise security management (ESM) products are available on the market today, these five suites represent the full range of capabilities within the SIM command, contain and control model.
E-Security's e-Sentinel 3.1
The recently renamed e-Sentinel suite of applications excels at the "command" part of the SIM model. The e-Sentinel suite is a series of applications that correlate security events from across the enterprise into a single, cohesive console view. In a nutshell, e-Sentinel agents gather event data from distributed security devices via SNMP traps. The Solaris-based e-Sentinel Platform polls SNMP-compliant devices for their status and centralizes gathered data in an Oracle database, which also stores information such as configuration parameters and historical logs from monitored devices.
e-Sentinel supports a variety of third-party security products, including firewalls from Check Point, Cisco, Network Associates, Symantec and WatchGuard; IDSes from Cisco, Enterasys, ISS, Network Associates, NFR and Tripwire; AV software from McAfee, Symantec and Trend Micro; and other security sources such as operating systems, databases, badge readers and even telecom equipment. While the list of supported products isn't as extensive as that of other SIM suites, e-Sentinel does interface with most market-leading security products.
For devices with native SNMP support, e-Sentinel can automatically configure agents that will capture and transmit SNMP traps. For devices without native SNMP support, e-Security's e-Wizard application, essentially an agent-creation tool, provides a user interface for creating and configuring SNMP proxy agents via PERL, Tcl or other scripting language. While this won't be a problem for most Unix users, Windows-only users may find this scripting work daunting. Once created, an agent can be duplicated and used to support other point products of the same type.
Save it for later
Download the security information management products and vendors and security management software vendors and products charts for later use
The e-Sentinel Network Monitoring Console is functional, but somewhat busy. Administrators can design graphical representations of the network and its security components and run reports in the database to reveal potential vulnerabilities and attack patterns. As alerting and status information is received, different colored icons (green, yellow and red) representing each security resource are updated to reflect their current status.
The GUI in version 3.1 is an improvement over previous versions. Released last October, the latest version includes a new graphics library and support for 59 default Crystal Reports. This allows users to tailor reports for different purposes or audiences (e.g., executive summary reports, security analyst reports, operational reports and so on).
Another component of the suite, the e-Security Management Desk, essentially acts as a policy and procedures manual when events trigger a security alert. The Management Desk provides admins with workflow procedures used to respond to different types of intrusions. Such procedures include personnel notifications, escalation guidelines, security trouble tickets and analysis of service-level agreements.
e-Sentinel lives and dies by SNMP, which may represent a problem for some environments. Most network devices only support SNMP version 2, which lacks robust authentication, transmission encryption and access control filters. While e-Sentinel's default is to use SNMP version 3 -- an add-on security spec to version 2 that provides for these security requirements -- networks relying on SNMP v2 traps will remain susceptible to eavesdropping and man-in-the-middle attacks.
Furthermore, by default SNMP runs on ports 161 and 162, which may require reconfiguration of internal firewall rules and/or router tables. However, if an event source is located on the other side of a firewall from e-Sentinel, and firewall policies restrict SNMP traffic, admins can use the e-Security Proxy as a TCP tunneling mechanism for secure agent communication.
If your shop is comfortable using SNMP -- and confident that SNMP traps provide an adequate level of detail on remote device status and configuration -- e-Sentinel is worth a look.
Now in version 3.1, the product has rev'd enough times to work out the bugs. The company itself has solid financial backing from the Allen Systems Group and a cadre of established customers, including DuPont, the U.S. Justice Department and DynCorp.
netForensics ActiveEnvoy 2.3
Like e-Sentinel, the ActiveEnvoy suite is primarily a "command" SIM product. Its architecture is similar to e-Sentinel's: a database collects a large number of events from agents and correlates them using a central engine. The primary difference between the two suites is that ActiveEnvoy agents don't use SNMP traps, but rather XML and log data read directly off the devices.
In the version we examined, 2.3, ActiveEnvoy agents use XML over TCP, which (like SNMP v.2) lacks authentication and encryption properties. However, NetForensics says it will provide a native SSL encryption mechanism in version 3.0, scheduled for release this quarter.
ActiveEnvoy's use of the XML format allows event data to be stored in a common format in a central Oracle database. As with e-Sentinel, ActiveEnvoy allows administrators to see correlated event data in real time, in this case using Java-based communication channels to the Web-based interfaces. Console views can apply filters to events so that only those deemed relevant are displayed. Using drop-down boxes, administrators can choose the signature information, IP address, port and device filter parameters to focus on specific types of events or attacks.
To its credit, netForensics includes out-of-the-box support for 18 firewalls (e-Security supports seven) and 10 network-based and 10 host-based intrusion detection systems (e-Security supports six and four, respectively). Included in this list are such notables as Check Point FireWall-1; Cisco PIX, Secure IDS and VPNs; Cisco IOS routers, IOS firewall and IDS; Entercept HostIDS; and ISS RealSecure. ActiveEnvoy also includes agents for Unix syslog and Windows events.
As part of setup, devices can be entered manually or added using an auto-discovery tool. With other SIM packages, the user is expected to be conversant with PERL, Tcl or some other scripting language to create or modify device agents. netForensics' XML-based foundation makes this process easier, since XML is very readable-similar to reading HTML tags. More importantly, XML is an emerging common data exchange standard, allowing the collected data to be integrated into a growing number of database suites. In time, XML should allow all devices to speak a common language and provide unprecedented device integration.
Administration is role-based, so admins can configure or alter the ActiveEnvoy policies that affect security event logging, retention, notification and report scheduling. General-privilege users can perform real-time event analysis and use the report interface to modify security filters or perform forensic analysis.
ActiveEnvoy's reporting features are solid, allowing admins to drill down within numerous categories, including administrative, security, system status and utilization. Admins can manage applications, alarms, accounts, devices, data and events. Report types include system status, network firewall usage and security (covering network security, access, firewalls and intrusion detection).
For example, the Critical System Command Report lists the users who have tried critical system commands like rlogin, regedit, regedt32, rpcss, rsh, rcp and ftp. The Security reporting module includes more than 50 reports, covering firewalls, host- and network-based IDSes and VPNs. Want to know about your IPSec session details and then move right on to DoS attacks like Ascend kill, Finger Bomb and UDP Bomb? If so, this may be the tool for you.
Spun off as a separate company in 2000, the privately held, New Jersey-based netForensics hasn't been around as long as e-Security. However, investor backing is solid, including Storm Ventures and Cisco Systems (which partially explains Active-Envoy's broad support of Cisco security gear). Customers include JP Morgan Chase, Merrill Lynch, Bear Stearns, the U.S. Department of Veterans Affairs and Cleveland Clinic.
Open Service's SystemWatch 2.63
Like the e-Security and netForensics products, SystemWatch uses agents to correlate security data from distributed security devices, providing timely alerting and extensive reporting capabilities. In this sense, SystemWatch is a "command" type of SIM product. But unlike e-Sentinel or ActiveEnvoy agents, SystemWatch agents have a built-in intelligence mechanism that allows them to make "judgments" about alerts and adjust alert priority levels over time, depending on administrator response and new attack activity. Alerts can also automatically trigger response actions. In this sense, SystemWatch also has a "contain" function.
The SystemWatch Open Management Console (OMC) sits at the center of the SystemWatch Open environment, collecting data from the SystemWatch Agents. Security administrators use the SystemWatch Console to create security policies, manage alerts and send action directives to monitored security devices, such as firewalls, VPNs and IDSes. Compared to e-Sentinel and ActiveEnvoy, current device support is sparse: three firewalls (Check Point FW-1, Cisco PIX and Symantec Raptor) and one VPN (Nortel's Contivity). The company says it has plans to support other devices in 2002 (most prominently, NetScreen and WatchGuard firewalls; Check Point VPN-1; ISS, Tripwire and NFR IDSes; and Trend Micro and McAfee AV).
Clearly, the architectural highlight and main distinguishing element of this software is the intelligence of the agents, which have been designed to reside on Windows NT, Sun Solaris, Linux or an appliance (such as a Nokia/Check Point firewall). Like e-Security's platform, SystemWatch's agents reside where much of the active security management occurs. Agents have enough intelligence to provide data normalization locally before sending back data for correlation. One benefit of the product's Check Point interface is that certain agents are OPSEC-compliant, meaning they can take advantage of Check Point APIs with other vendors. This allows agents to run native, even on Nokia/FW-1 appliances.
SystemWatch claims its agents have enough intelligence to extract the information determined to be most "meaningful." Marketing-speak aside, this means that there's enough flexibility in the rule parameters that a large number of alerts can be parsed, so that only those alerts that represent a high level of threat will be passed along. Agents come with three preset security policy groups that can be adjusted to fit specific security needs and technologies.
Based on these rulesets, agents divide events into five alert levels: FYI, Notify, Problem, Critical and Failure. Corresponding alerts are then sent to the Open Management Console. Hence, administrators can determine, based on network policies, if a given event should reported only once, raised in criticality or kick off an automated event. Since only correlated alarms and information are sent on to the SystemWatch Console (OMC) for display, this vastly reduces the amount of "noise" from repeated events, helping to draw attention only to the important "signals" your network security devices are trying to send you.
When SystemWatch agents receive multiple alerts from a given piece of equipment, the agents sift through the information to create a single alert of the highest priority. In addition to priority, the security manager can determine what parameters should be weighted as most important, further tuning the logic that determines which alerts should bubble up to the top. Of course, this doesn't happen by magic. It requires that the security policy be translated into effective rules. Open Service provides tools for helping to translate these policies; additionally, default rules can be run with little modification.
Event correlation has three levels: Type I (Basic Correlation) looks at various events within a single device, such as multiple login attempts to a single firewall using different services. Type II (Intermediate Correlation) looks at event data from different services, only on distributed firewalls. Type III (Advanced Correlation) looks at multiple events from multiple security products running on multiple servers. An example of Type III correlation would be to look for Telnet failures on one firewall server, TCP failures on an IDS server and HTTPS failures over a VPN server. Unfortunately, I wasn't able to directly test this level of complexity in event correlation. But if it works as advertised, it would be something of a Holy Grail for event correlation.
SystemWatch is unique among the SIM solutions examined in this article in that can automatically initiate an action or set of actions based on a particular type or level of alert. The SystemWatch software includes predefined actions used to control security devices and appliances. For example, a daemon process could be set to shut down automatically in response to an alert escalation.
Of course, poorly designed rules can also create an environment in which devices are shut down, tricking poorly thought-out security rules into become inadvertent denial-of-service issues. On the other hand, if well thoughtout rules restrict the automatic response to off hours, a hacker might find himself very surprised when the hacked device stops communicating.
Last November, Open Service became the first of the SIM vendors to complement its security management offering with an in-house network-monitoring solution when it acquired the NerveCenterT suite from Veritas Software. At the same time, the privately held company received a second round of equity financing ($6 million), led by Zesiger Capital Group and 1to1 Venture Partners. Customers for the 7-year-old, Westborough, Mass., company include BellSouth, Bear Stearns, AOL Time Warner and FirstUSA.
Controlling Security Devices
The next two products, by Solsoft and Ponte, represent a departure from the previous three suites. Where e-Sentinel, Active-Envoy and SystemWatch are tilted toward providing up-to-the-minute alerting and event aggregation and correlation, Solsoft NP and Ponte nsControl are geared toward providing absolute control over the edge security devices. This isn't to imply that the aforementioned "command" suites don't provide utilities for translating security polices into agents, or that Solsoft and Ponte lack command-type reporting features. But the emphasis for the latter two products is on how enforcement points are to be managed consistently through automation.
When a network is built, security policies are usually designed and implemented for each given enforcement point: ACLs are created for routers, rulesets are created for firewalls, policies are created for VPNs, etc. However, policies for various devices are not usually correlated across the enterprise. When the network grows, these default security policies may no longer be adequate, and piecemeal additions may introduce vulnerabilities and interoperability problems.
The key concept here is consistency. "Control" products like Solsoft NP and nsControl attempt to address this patchwork of device configurations, introducing a mechanism to ensure consistency across the enterprise from a central location.
Solsoft's Solsoft NP 4.3
Solsoft NP attempts to solve the problem of inconsistent policy propagation by coordinating the security policy on routers, firewalls and VPNs with the actual control mechanisms on each device (e.g., ACL, ruleset, policy).
The product first uses visual tools to design a consistent network security policy. Once the policy has been defined, the product creates and deploys code native to the enforcement point devices. The actual functioning and behavior of all enforcement points are then synchronized with the enterprise's security policy.
All of the above sounds great...in theory. But making this process work in practice relies on several assumptions. First, the policy being developed through the Solsoft Policy Definition Tool operates under the assumption that all services are denied on distributed enforcement point devices until specific permission is given. This is actually a good policy, because it forces users of the tool to explicitly open enforcement points to access by authorized users while denying access to unauthorized activities. But ensuring that this policy is actually in place on distributed devices may require significant work on a user's part before the Policy Definition Tool can be used effectively.
Second, the utility of Solsoft NP depends on its ability to control multiple third-party devices down to the ACL or ruleset -- in other words, in the device's native control language. In this sense, device support may be Solsoft's Achilles heel. The product provides firewall support for PIX and Check Point on multiple platforms (including Nokia), but at press time doesn't support FW-1 version 4.1 SP4, SP5 or NG. As for VPNs, only Cisco PIX and the Cisco IOS routers are supported. Solsoft provides better support for non-VPN routers, including 3COM, Cisco, Ericsson, IBM and Nortel. Even so, it doesn't support some other widely deployed routers from vendors such as Foundry, Intel, Cabletron/Enterasys, Lucent and Riverstone.
After users create device policy or rulesets with the Solsoft Policy Definition Tool, a compiler called the Network Policy Engine generates the native code for the enforcement point devices. Solsoft NP then uploads the command code to the devices (SSH can be used for those devices that support it). A fail-safe and rollback feature reports if the policy was uploaded successfully. If not, the device is returned to its original state. However, rollback suffers from the same lack of device support, working only on Cisco IOS, Cisco PIX and NetFilter.
New to Solsoft NP 4.3 is the VPN module, which allows administrators to configure and provision IPSec tunnels to create VPNs using consistent tunnel policies across devices that supports IPSec. This VPN module is promising, since many devices claim to support IPSec, yet a number of vendors still implement IPSec differently. Still, as noted above, only the Cisco PIX and IOS have VPN modules provided by Solsoft.
Solsoft is a French startup with relocated headquarters in Silicon Valley. Customers for the privately held firm include US Cellular and Thomson-CSF Detexis, a defense electronics contractor.
Ponte's NS Control
Like Solsoft, Ponte's Solaris-based nsControl platform automates the translation of policies into device-specific code. Its centralized Control Server is capable of deploying device configurations, firmware and passwords to network devices. But while Solsoft is restricted to a few third-party devices, nsControl can perform this function regardless of vendor or device type. It does this by communicating with each device using its native command language, rather than requiring agent software on the devices.
nsControl uses decentralized Network Control Points (NCPs) to deploy the actual network security changes. The NCP itself can be a generic x86 PC (or 1U rack mounted PIII). Once the install script is run, this box is essentially turned into a NetBSD appliance, the same secure foundation used by Nokia's box. This works particularly well with older legacy devices for which there's no native SSH support.
Ponte initially provides vendor-specific drivers for the devices that are most popular. As of this writing, supported devices include Cisco PIX 4.x-5.x, Cisco IOS routers 11.x-12.x, Cisco Catalyst switches, Efficient Flowpoint routers, Efficient Speed-Stream routers and F-Secure's VPN. However, organizations that have devices for which there's no template can create their own (or hire Ponte to create them). nsControl, in this sense, requires more know-how and elbow grease than Solsoft NP. Creating a custom driver requires familiarity with Tcl scripting and a working knowledge of the device's native command set (usually provided as part of the technical documentation that comes with a device). Network engineers may need to invest significant time and effort into the driver creation process.
After a policy has been created, nsControl performs three essential functions:
- Transformation. In this stage, security and network administrators specify the policy that describes their corporate rules, which will ultimately define how the network behaves. The transformation component of nsControl transforms this written security policy into one or more device profiles, which describe a device's behavior in a vendor-independent format. Programmers may think of the output as a sort of process definition language (PDL).
- Assembly. The assembly component takes the vendor-independent device profiles associated with each device and combines them into a template that contains the formatting for each type of configuration. This results in a vendor-specific configuration for each device. At this point, the policy-level descriptions become device-level descriptions in a vendor-specific format.
- Delivery. The third phase combines actual firmware and passwords to create a direct configuration set for a particular device. Changes are then logged to a central console, and should anything not go as planned, a rollback to the previous state can be performed automatically. Rollback also allows administrators to test changes, providing a safety net.
The brains behind the operation is the nsControl Control Server, which sits atop the MySQL Network Knowledge Store database and speaks to the distributed NCPs. The Control Server manages all information about security policy and the network devices controlled by the platform. It also schedules, coordinates, tracks and logs the progress of all requested changes. Within the database are the device profiles, now resident in a common format, containing all the attributes of a given device-IP address, firmware version number, management passwords and other configuration settings. The Control Server is reportedly scalable, supporting up to 2,500 NCPs, each of which can control a few thousand devices.
Ponte seems to have taken security issues to heart in nsControl. NCPs are secured against attacks: there are no visible services on it, and it appears as if it were listening on any TCP port. Communications with the Control Server are encrypted via SSL using a 2040-bit handshake and a 128-bit session key. This means that administrators may place NCPs wherever they are needed in the network, even in hostile environments or across the public 'Net. This provides a high level of authentication assurance while minimizing communications overhead during actual pushes.
While the Web interface is somewhat limited, Unix administrators will appreciate the command line interface, which allows for a good deal of scripting, using popular packages such as Tkl or PERL. But there's no GUI to speak of, something Windows users won't like. Ponte promises a browser-based GUI in version 1.1, scheduled to ship in Q1 2002.
Like the other SIM vendors, Ponte is a startup, incorporated in 1998 with about $10 million in venture funding. Though nsControl is a promising technology, it's first-version software that hasn't withstood the test of time or the rigors of day-to-day use. Moreover, Ponte won't publicly disclose the names of any of its customers, which usually indicates that there aren't many yet.
"Set Things In Order"
The rationale for spending money to bring all your events to one location goes beyond the convenience of central reporting. However, while the security benefits may be obvious to those in the trenches, it's hard to justify the expenditure until something really bad has already happened.
Management, of course, will be interested in the ROI provided by such systems. In other words, do SIM products prove that more work can be done better while requiring fewer people to do it? As a manager, I've had to work out how many heads I would need per number of devices. As the number grew it turned out that headcount requirements weren't linear because the devices are not "set and forget." Instead, additional devices created exponentially more work and generate more "noise," threatening to drown out any useful "signal" I get from the security events.
Eventually, security automation becomes a mandate and not a choice. The more devices, the more coordination required. The more exposure, the more events generated, and thus the more likely an administrator is to miss something really important. Thus, a corollary is that the more processes that can be automated, the more likely an enterprise will be ready to handle things that arise when the inevitable occurs.
As the great Chinese master Lao Tzu once said, "Trouble is easily overcome before it starts. A tree as great as a man's embrace springs from a small shoot; deal with it before it happens. Set things in order before there is confusion."
Policy management tools like Solsoft NP and Ponte nsControl have a close cousin in so-called "configuration management" products. Where Solsoft's and Ponte's software centrally manage policy and ruleset enforcement on distributed security products, configuration management tools from companies such as Configuresoft, Patchlink, Bindview and even Microsoft allow administrators to track, modify or restore configuration settings and update distributed systems with patches and service packs from a central location.
In next month's issue of Information Security , we'll explore how some of these products work and discuss their pros and cons in helping administrators manage an extended enterprise network.
About the author:
Scott Sidel is a technical editor for Information Security and a senior principal engineer with Computer Sciences Corp.