While enterprises loaded up on security-related technologies from anti-virus to IDS (intrusion detection system) solutions during the past few years, a new problem was brewing: how to aggregate the streams of information coming from the various security devices throughout a network and correlate that data to help IT prioritize and respond to threats?
Making sense of data from a patchwork of point security solutions is a major goal, and a bevy of vendors is stepping forward to meet the challenge. However, so-called "security event management" products -- including software, appliances, and managed services from Guardent Inc., Network Intelligence Inc., Symantec Corp., Internet Security Systems Inc., ArcSight Inc., NetForensics Inc., and e-Security Inc. -- face an array of technology challenges, ranging from data management and integration to scalability and analytics to making the data actionable.
Data management, integration, and scalabilityThe basic concept behind security event management is to tap and correlate data from a variety of devices on the network in real time, enabling a 360-degree view of potential threats. Data sources include security-layer devices such as firewalls, VPNs, anti-virus and IDS; network-layer devices such as routers, hubs, and switches; host systems and their OS audit trails; and storage systems.
Many of these devices perform some security reporting and analysis on their own, but that data must be pulled together, normalized, and put into a common format. The challenge can be compounded by both the volume and variety of the data: a Cisco router, for example, can have more than 6,000 message types (event signatures); a Windows host server can have over 7,000. In the absence of industry standards, mapping related messages from different vendors' products requires a superset taxonomy constructed by each event management vendor.
"It's not rocket science," says Matt Stevens, vice president of technology at Network Intelligence in Walpole, Mass. "It's just a lot of hard work."
Although efforts are under way to standardize a dictionary that would make it easy to normalize security event data, industry squabbling seems to be impeding progress. "In the late '90s and early 2000s, most sensor vendors wanted to be at the top of that stack," says Jerry Brady, CTO of Waltham, Mass.-based Guardent. "That led to the development of very proprietary protocols and data models, different event representations. It's hard to link that data together."
Efforts are under way to develop standardized security-event representations, including the CVE (Common Vulnerabilities and Exposures) project and those under way at the Computer Emergency Response Team (CERT) Coordination Center. Internet Emergency Task Force (IETF) groups have been working on both IDXP (Intrusion Detection Exchange Protocol), a standard protocol for intrusion detection systems, and IDMEF (Intrusion Detection Message Exchange Format), but both are focused on signature-based IDSes and may not cover data from VPNs, firewalls, and other key devices. Some vendors are pushing their own protocols, such as Symantec with its SESA (Symantec Enterprise Security Architecture). Others are trying to tie into the work of the Distributed Management Task Force (DMTF) for logging, alerting, and reporting.
The data management challenge is made all the more intense by the sheer volume of data that security event management systems must process and store in real time -- up to tens of thousands of events per second.
"These things really turn out to be ERP-or CRM-size [applications] as opposed to typical security applications," Guardent's Brady says. A typical firewall alone can generate 200 events per second, and combined with other devices' data, the flow can equate to 4GB per hour of data -- and many companies want to store 90 days' worth of data."
"At that rate you're talking about filling an EMC array every 11 days," Network Intelligence's Stevens notes.
Correlation and analysis
As does technology for predicting earthquakes, security event management applies an impressive variety of sophisticated sounding techniques but is still a bit of an unproven black art. Each vendor has a slightly different approach to correlation, the process of identifying threats by piecing together clues and tidbits from different devices throughout the network.
Most vendors use some combination of scenario-type or rules-based correlations -- if X and Y are happening, it probably means Z -- and statistical correlations, which examine large volumes of incidents to flag inconsistencies and patterns such as an unusual number of events keying in on the same port number. This combination of methods is necessary because black hat hackers go out of their way to avoid leaving easily correlated footprints -- using different machines for reconnaissance and attack, for example.
Event management correlation techniques serve primarily to provide a reality check or corroboration of what the IDS is reporting by leveraging a wider set of data. Typical attackers who get control of a machine, for example, will erase audit logs to cover their tracks, copy a root kit and hacker tools onto the machine, and then use that machine to attack or recon other sites. A rules-based correlation would watch for a buffer overflow followed by a box-service restart and an outgoing FTP event by piecing together data from the firewall and application and host OS log files.
"The reason a product like ours exists is because the IDS systems themselves are notorious for false positives," says Netforensics CTO Kevin Hanrahan.
Key challenges for correlation include continuously building the rules knowledge base, combining rules with statistical-anomaly oriented algorithms, establishing normalized baseline threat and vulnerability levels based on contextual data, and running correlations in real time rather than after the fact. "It's classic computer science kinds of problems," Guardent's Brady says. "No one is going to come up with an easy answer. ... It's a lot of circumstantial data."
Several vendors are working to combine vulnerability assessment data, including data from live scanners such as Nessus, Qualus, and ISS, with asset domain knowledge or contextual profile information about specific assets, to better predict in real time the likelihood an attack might succeed and how damaging that attack might be.
"All vendors need to include vulnerability assessment data in the correlation engines," Network Intelligence's Stevens says. "A good management system should understand what type of [asset] is being run, to know whether to send the 'all hands on deck' signal or not."
Making the data actionable
The final challenge for security event management vendors is figuring out how to operationalize the data and support appropriate responses. Some are straightforward: pre-emptively launching a fresh tripwire scan, for example, or moving from pager notification to proactively disabling an account, which itself carries the risk of enabling a DoS (denial of service) attack.
Some vendors want to be able to change policies on key devices on the fly, but this can require costly reverse-engineering if the device makers aren't cooperative. "They do not want to publicize any APIs that let you replace their management consoles," explains Hugh Njemanze, CTO of ArcSight in Sunnyvale, Calif.
Rob Clyde, CTO of Cupertino, Calif.-based Symantec, says many existing management systems already have tools for sorting, filtering, thresholding, and aggregating security data. "But [IT] still wonders, Do I care?" Clyde explains. Another key issue involves taking the analysis burden off the operators' shoulders and tying into existing case management and incident handling systems to facilitate an active response.
How bright is the future of security event management? ArcSight's Njemanze says, "There are more and more Big Brother kinds of monitoring that are being contemplated and being expected to be fed into a system like ours." He cites the example of packet sniffers that watch for elicit e-mail and monitor employee usage down to individual keystrokes. "It's actually pretty scary if you stop and think about it."