In Defense of David Bianco
I'd like to second the post by David Bianco that Sguil is not a Security Information Management (SIM) or Security Event Management (SEM) product. I think Sguil creator Bamm Visscher summarized the issue nicely when he said the following in the #snort-gui IRC channel:
SIMs take in all this information from points a-w, but the value is less than if you'd just grab data from x, y, and z.
I've advocated elsewhere that the garbage (the a-w) shoved into SIMs/SEMs does not necessarily produce a diamond when "correlated," summarized, or otherwise reported. I have advocated the value of simply collecting all logs in one place (log centralization), because logs should never be exclusively stored on a target system. (Bejtlich: "Every system is a future victim." This is a corollary of "Prevention eventually fails.")
Sguil's x, y, and z is alert data from Snort, session data from SANCP, and full content data from a second instance of Snort, or Tcpdump or Tethereal. In my experience performing network security, these are the three indispensible elements of detecting and responding to intrusions. I couldn't imagine doing my job without them, and prior to starting my own company I refused jobs at MSSPs that were unwilling to collect, analyze, and escalate that data.
SIMs take in all this information from points a-w, but the value is less than if you'd just grab data from x, y, and z.
I've advocated elsewhere that the garbage (the a-w) shoved into SIMs/SEMs does not necessarily produce a diamond when "correlated," summarized, or otherwise reported. I have advocated the value of simply collecting all logs in one place (log centralization), because logs should never be exclusively stored on a target system. (Bejtlich: "Every system is a future victim." This is a corollary of "Prevention eventually fails.")
Sguil's x, y, and z is alert data from Snort, session data from SANCP, and full content data from a second instance of Snort, or Tcpdump or Tethereal. In my experience performing network security, these are the three indispensible elements of detecting and responding to intrusions. I couldn't imagine doing my job without them, and prior to starting my own company I refused jobs at MSSPs that were unwilling to collect, analyze, and escalate that data.
Comments
I would argue that sguil and SIM/ESM are are two different levels entirely. Sguil is a great network security tool for permiter or internal network security analysis and reporting. In fact is it probably the premeir tool in that regard. In my opinion very few SIM's can get to the level of detailed analysis that Sguil can. There are SIM products that can take packet level data and provide at least some level of correlative information, but this is where Sguil excels and SIM's seem too cumbersome.
SIM/ESM on the otherhad has the ability to monitor on several levels that Sguil simply can not accomplish (to date). First SIM/ESM tools can take in sources outside of tradition network security devices and provide correlation for the enterprise not just the network. For example you can correlate physical access logs with VPN logs or domain controller logs and verify why a user who is physically located in a server room would also be accessing the corporate network via a remote VPN session - perhaps his wife/kids are using his logged in connection at home - no that never happens :) . Non traditional identification of anomalous acticity is also a key component of SIM/ESM tools - correlating system error messages with firewall drops or port increases can point to worm/virus before IDS/AV signature may be available. SIM/ESM also provide a robustness to the analytical toolsets that focused analytical tools do not provide. Incident Management tools, reporting, graphical analysis to name a few.
In the end the combination of tools is important but no more so than the people and processes around your enterprise security capability. Without properly trained staff, solid process and procedure it doesn't matter if you have sguil, arcsight, netforensics or smoke signals in your toolbelt.
>signals in your toolbelt.
Well, but does it have to stay the same in the future? I still think that the greatest NSM approach weakness is in the need to have a *very skilled analyst* to run the constituent tools. From my experience, few companies are willing (and likely will *ever* be willing) to hire such people for such roles. And without the analyst, the NSM approach fails - as Bruce Schneier likes to put it - ungracefully...
I think that future 'super-SIM' will automate more of the NSM tasks and thus will be "adoptable" by a wider audience than NSM...
I agree with you that you have to use these tools to look inside the packet and see what is really happening.
But you can't do this with every events/alert from the IDS and you should not relay on IDS alone.
IDS in large environments has a high false-positive rates due to many reasons:
- large environment = large number of events = multiple signature matches.
- Customized applications triggers IDS signatures.
- Network design imposes limitation on IDS locations.
- Return packets that belongs to a terminated session on the firewall will trigger host/network scan.
- Larger number of legitimate requests and replays will trigger DoS/DDoS alerts.
- Misconfigured router/firewall will cause applications/servers to behave unmorally and will be reflected on the IDS.
- And the list goes on and on.
And you should not relay on IDS alerts alone because you'll need to:
1- Verify the IDS alert with a firewall to know whether it passed or not.
2- If it passed the firewall then you will need to know relevance, severity of the target to determine attack threat level and the risk of the target.
An attack has a high relevance if it targeted an open port that has vulnerability.
High severity means that the target was targeted by a known attack before this one.
Sguil can't do these things, that’s why you will need to use some kind of event management system that would help you in selecting the most interesting events or narrows your scope.
This is based on my experience with more than 130 million event per day coming from IDSs, HIDSs, IPSs, Firewalls, AV, IMSS, IWSS, scan mail, and Nessus. I'm responsible of maintaining and writing correlation rules that detects such interesting events.