Slashdot Mirror
Patrolling Networks For Insecurities
Mojo Jojo writes "There's a story on developerWorks about DARPA-funded work being done at Stanford Research Institute (aka SRI International) to develop soemthing called Event Monitoring Enabling Responses to Anomalous Live Disturbances (EMERALD) -- software components that are capable of providing anomaly and misuse detection for networks. EMERALD components monitor local activity, then work in conjunction with analysis engines for visualization, response, correlation, and
data logging to provide a global picture of what's occurring throughout the network. Sort of like having beat cops and police call boxes throughout your network (or something)."
EMERALD is not an evil government plot, nor is it interesting new technology that will change anyone's life. It's simply another research intrusion detection system, and it's been around for years. The people working on it are smart (I met and talked to Philip Porras at a Common Intrusion Detection Format meeting), but the project itself is less far-reaching than any of the commercial systems already on the market.
EMERALD is interesting primarily as a framework for building intrusion detection systems. It's component-based and designed to allow different "event generators" to be combined for analysis. This is a goal of a large number of research projects. The reason EMERALD comes up alot is that it has a relatively well-defined and powerful rule-based analysis engine to process events.
This framework differs from commercial systems like ISS RealSecure in that the sensors, which collect information from the network (or logs, or whatever) don't do the bulk of the analysis work. Unlike RealSecure, in which the raw network sniffing code is also responsible for knowing about almost every vulnerability the system detects, EMERALD allows the sniffer system to forward low-level "events" to an analysis engine that can detect attacks.
The two basic advantages to this approach is that you can more scaleably detect simple attacks and you can detect a wider range of intrusion scenarios. The system scales better because it splits the load of event generation (sniffing) and analysis (attack detection) into two components, instead of coupling them into one component like RealSecure. The system can detect more interesting attacks because it offloads analysis into a rule-based engine (basically, an "intrusion detection programming language"), so it can flexibly do things like statefully correlate different events from different event generators.
This is all nice and good, but the fact is that EMERALD is (at least, until recently) a research project with very little real-world usage. It's a nicer architecture than RealSecure, but in terms of real-world impact, RealSecure is more important; RealSecure has a fairly mature "sniffing" engine, a large database of attack signatures, and an interface that makes it easy for network operators to violate your privacy.
Anyone (the NSA, your ISP, your mother) can buy RealSecure if they have the cash. It's been available for years and years. You can deploy a RealSecure system to do everything EMERALD can currently do. And most of the interesting new capabilities EMERALD promise IMPROVE the privacy aspects of the system. You can't get a whole lot more intrusive than the "snoop every packet" semantics RealSecure already has.
So, what's the news here?
1. Place multiple hosts into a single collision domain for monitoring of unicast traffic. This has serious performance ramifications.
2. Use an inline monitor in each collision domain where you want to monitor unicast frames.
This can be very expensive, and would get cumbersome to maintain if you have a dozen or more servers to watch.
3. Use Tap ports (available on some switches) to direct all unicast frames to a designated switch monitoring port.
This also has issues, as the tap ports are generally a low priority process in the swithcing engine, and often a simple DOS can cause the switching engine to drop packets rather than forward them to the tap port. I have also done some testing and have found that many (most) tap port services on switches are broken or selective in what traffic they forward to the tap. I can't speak for them all, but I have tested several top vendor products. I ahve a multi-homed (8) interface box that I have designed and abandoned in developing (no time) which runs linux. It's basically an 8 interface sniffer so that I can sniff up to 8 segments at a time. Even this sort of approach is really limited. Maybe they should look at a way to piggy-back patch panels in the comms room, and run a split back to an agregator so they can sniff 'everything at once' without having to deploy many, many monitors. Hey, that's a cool idea.
...but with a little better spin. Surely, I'm not the first paranoid to realize that government controlled or funded monitoring utilities, be they hardware-based like Carnivore, or software based like this guy, are a little scary.
EMERALD (They must have *really* worked to put this acronym together) seems on the surface to be quite a bit less scary than Carnivore. It monitors your network and reports back to you, but the project *is* DARPA funded, and ultimately serves the DOD's (and therefore the FBI and NSA's) best interests. This is the line that has me really concerned:
Plus, with resolver, an additional EMERALD software component, alerts are consolidated across multiple network domains within a single reporting console.
Does this mean that there are ways built into the software to monitor one firewalled network from another? They had better release the source for all components for reveiw, or I ain't touchin' it with a ten-foot pole. If there are backdoors in Windows, then it's just too-too easy to put a DOD or NSA back-door into something like this.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
Emerald fits into a subset of the network monitoring that is coming of age as we speak. The IETF has already begun to try and standardize protocols for use in this area...check out the Intrusion Detection Working Group for more info (the results produced by the IDWG would standardize the transfer from producers to consumers mentioned in the article).
-GregI have got to be misinterpreting this passage:
EMERALD security components can also help users analyze communications traffic, collecting Simple Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP) and Web server data directly from the Transmission Control Protocol (TCP) traffic stream. "For Web traffic where we deal with Secure Socket Layer (SSL) and cryptography, we've created an embedded component to decrypt Apache Web server traffic, and we're extending it over to Netscape's Web server," Porras said.
Are they really saying that, for the purposes of intrusion detection, they will be decrypting SSL traffic off the wire and on the fly? More to the point, they're saying that this can be (relatively) easily done?
Or, is it that they're talking about an Apache module which will examine the traffic on the other side of the tunnel? The wording is a little confusing.