Tweaking IPS/IDS Vendors at Trade Shows
If you follow the NSM (Network Security Monitoring) philosophy, you focus on collecting and analyzing 4 types of data: statistical, flow/session data, full-content packet capture data, and alert data from an IDS (and possibly other sources of alert data). The best place to learn about the approach is here:
Snort is my choice for an IDS because it is Open Source (source code auditable, available for outside improvement especially feature development), which means it's Free-as-in-Beer as well as Free-as-in-Speech. Got a rant on the subject. It is incredibly flexible: I can read every signature and understand what it is trying to detect; I can get the output in any number of formats, which means the data winds up where I can use it best. Some vendors want you to buy a console that will cost as much as the sensor!
Sguil is my choice for viewing NSM data because it collects all the data I routinely need to look at and sticks it on a panel where I can use it. I've heard several analysts say sguil makes them four times as productive, with greater detection success. I won't go into all of why this works so well, but the big win is the database. Sguil stores data in a mysql database whose schema scales much better than other, similar projects. Here's an example of how it works: suppose you have an alert from your IDS. The state of the technology being what it is, you aren't sure if this is a real attack or not. By right-clicking on the source of the alert, you get a menu that offers options to see what other alerts this source has been involved with. If you see multiple attack signatures triggered, that's pretty good correlation and confirmation. You can also click a radio button to look up information about the owner of the network that source is from. You can click a button to display the rule that matched the traffic and triggered the alert. You can see the packet payload with another click. And - and this is the killer - you can right-click on the event id and either get a plain-text transcript of the connection, or get a bit-for-bit copy of the communication between source and destination. You can see the whole thing, as it transpired. You can send it to other, potentially wiser people for their analysis. You can replay the traffic to test solutions and defenses. You can extract any attack tools downloaded. Finally, if you confirmed that it was an attack, and the transcript showed it succeeded, you can easily bring up a record of all connections between the attacker and other hosts on your network. Even better, you can look at all the susequent network traffic of the compromised destination. It's very, very cool.
Back to the narrative.
I went to a local security expo where four vendors of IPS/IDS products had booths. They make what are essentially tricked-out firewalls. The most crude form of firewall, the packet filter, can make block/permit decisions based only on surface aspects of a single packet, like the source or destination IP address and/or port. Each packet is examined in isolation, which is not good.
A stateful firewall keeps a table of connections, so it can examine a packet in relation to other packets in the same conversation. For example, unlike a packet filter, a stateful firewall can look at a response packet and know that it is really in response to traffic initiated by a host allowed to have that kind of traffic. Stateful firewalls are still limited to surface aspects, but it can look at them in context, which is a big improvement. Application firewalls (Sometimes called "Layer 7") actually model/decode application level protocols. For example, one might be used to discriminate between legitimate HTTP traffic (web traffic), which usually travels to a web server on TCP port 80, and a P2P (Peer-peer) application like the old Napster, which might sneak out on TCP port 80 pretending to be web traffic. A half-step beyond the application level firewall is the IPS. They look deeper into the packet than an application firewall might. They use IDS approaches to looking for attack patterns and behaviors, and go beyond issuing an alert. There are pros and cons to this, among them that the behavior of the firewall may change in response to stimulous of an attacker's choice. An attacker may be able to issue stimuluous that will cause Bad Things to happen, like make blocking decisions that prevent necessary communication. On the other hand, they can keep other Bad Things from happening, like preventing malicious web sites from taking advantage of specific weaknesses in web browsers.
On to the tweaking: I already mentioned why I like Snort and Sguil. I went around asking the booth weasles for the IPS vendors if I could view the signatures and write my own. What kind of output options did I have for reporting. Could I get Flow data? Full content packet captures? The reps for McAfee, ISS, and RealSecure did not cover themselves with glory. For the most part, they had no idea what I was talking about. I don't think they would have recognized a packet dump. I got much blank look and repitition of previous points. (Kinda reminded my of my 3 year old son: "I want ice cream." "You can't have ice cream right now because blah blah blah." Blank look. Shake head to clear it of irrelevant and incomprehensible bullshit. "I want ice cream.") They might as well have been selling refrigerators. "Now, some people don't know that Maytag models give you cancer." The Tipping Point booth weasel did know what he was talking about, and even more, he knew what *I* was talking about. He was pretty comfortable defending the approach his company took. Most people don't do real IDS stuff.
If you follow the NSM (Network Security Monitoring) philosophy, you focus on collecting and analyzing 4 types of data: statistical, flow/session data, full-content packet capture data, and alert data from an IDS (and possibly other sources of alert data). The best place to learn about the approach is here:
Snort is my choice for an IDS because it is Open Source (source code auditable, available for outside improvement especially feature development), which means it's Free-as-in-Beer as well as Free-as-in-Speech. Got a rant on the subject. It is incredibly flexible: I can read every signature and understand what it is trying to detect; I can get the output in any number of formats, which means the data winds up where I can use it best. Some vendors want you to buy a console that will cost as much as the sensor!
Sguil is my choice for viewing NSM data because it collects all the data I routinely need to look at and sticks it on a panel where I can use it. I've heard several analysts say sguil makes them four times as productive, with greater detection success. I won't go into all of why this works so well, but the big win is the database. Sguil stores data in a mysql database whose schema scales much better than other, similar projects. Here's an example of how it works: suppose you have an alert from your IDS. The state of the technology being what it is, you aren't sure if this is a real attack or not. By right-clicking on the source of the alert, you get a menu that offers options to see what other alerts this source has been involved with. If you see multiple attack signatures triggered, that's pretty good correlation and confirmation. You can also click a radio button to look up information about the owner of the network that source is from. You can click a button to display the rule that matched the traffic and triggered the alert. You can see the packet payload with another click. And - and this is the killer - you can right-click on the event id and either get a plain-text transcript of the connection, or get a bit-for-bit copy of the communication between source and destination. You can see the whole thing, as it transpired. You can send it to other, potentially wiser people for their analysis. You can replay the traffic to test solutions and defenses. You can extract any attack tools downloaded. Finally, if you confirmed that it was an attack, and the transcript showed it succeeded, you can easily bring up a record of all connections between the attacker and other hosts on your network. Even better, you can look at all the susequent network traffic of the compromised destination. It's very, very cool.
Back to the narrative.
I went to a local security expo where four vendors of IPS/IDS products had booths. They make what are essentially tricked-out firewalls. The most crude form of firewall, the packet filter, can make block/permit decisions based only on surface aspects of a single packet, like the source or destination IP address and/or port. Each packet is examined in isolation, which is not good.
A stateful firewall keeps a table of connections, so it can examine a packet in relation to other packets in the same conversation. For example, unlike a packet filter, a stateful firewall can look at a response packet and know that it is really in response to traffic initiated by a host allowed to have that kind of traffic. Stateful firewalls are still limited to surface aspects, but it can look at them in context, which is a big improvement. Application firewalls (Sometimes called "Layer 7") actually model/decode application level protocols. For example, one might be used to discriminate between legitimate HTTP traffic (web traffic), which usually travels to a web server on TCP port 80, and a P2P (Peer-peer) application like the old Napster, which might sneak out on TCP port 80 pretending to be web traffic. A half-step beyond the application level firewall is the IPS. They look deeper into the packet than an application firewall might. They use IDS approaches to looking for attack patterns and behaviors, and go beyond issuing an alert. There are pros and cons to this, among them that the behavior of the firewall may change in response to stimulous of an attacker's choice. An attacker may be able to issue stimuluous that will cause Bad Things to happen, like make blocking decisions that prevent necessary communication. On the other hand, they can keep other Bad Things from happening, like preventing malicious web sites from taking advantage of specific weaknesses in web browsers.
On to the tweaking: I already mentioned why I like Snort and Sguil. I went around asking the booth weasles for the IPS vendors if I could view the signatures and write my own. What kind of output options did I have for reporting. Could I get Flow data? Full content packet captures? The reps for McAfee, ISS, and RealSecure did not cover themselves with glory. For the most part, they had no idea what I was talking about. I don't think they would have recognized a packet dump. I got much blank look and repitition of previous points. (Kinda reminded my of my 3 year old son: "I want ice cream." "You can't have ice cream right now because blah blah blah." Blank look. Shake head to clear it of irrelevant and incomprehensible bullshit. "I want ice cream.") They might as well have been selling refrigerators. "Now, some people don't know that Maytag models give you cancer." The Tipping Point booth weasel did know what he was talking about, and even more, he knew what *I* was talking about. He was pretty comfortable defending the approach his company took. Most people don't do real IDS stuff.
posted by JimmytheGeek at 4:41 PM
0 Comments:
Post a Comment
<< Home