I find both Sguil and Bro to be venerable platforms, however Seth, I think that Bro is better left as a sniffer/preprocessor.  I think that the bulk of the processing (I would even argue things like the libmagic part) are better left to another process that Bro ships interesting things to via Broccoli.  While Bro sports a lot of really good plugins and a fair amount of extensibility, I think it's the wrong design path to throw everything into it as a framework.  It is no accident that it lacks native database support and has no frontend, because it wasn't designed to be all-encompassing, it was designed to do the heavy lifting and pass the rest off via Broccoli.  But Bro does have the great strength of allowing for extremely rich signature scripts, as you pointed out.<br>
<br>David, (I am a regular reader of your blog, BTW):  I consider Sguil the closest thing to an out-of-the-box solution for NSM out there, and I think that it is 100% on the right track.  In my opinion, though, the entire Sguil architecture feels archaic and a bit kludgy, and I definitely require a web console as opposed to a Tcl-based console.  I completely understand why Tcl was the original design choice, but AJAX has really made it obsolete.  My vote would be to extend the NSM ideas of Sguil to a platform based on a language with a wider audience, like Perl.  Admittedly, since I know Perl the best, I will of course advocate for it (just as you advocated Sguil and Seth advocated Bro).  That said, you can take a Perl class (or Java, .NET, or probably even Python) at any tech college, but very few places will teach Tcl.  Perl also has a much richer library of modules to draw on to do all of the really interesting things that you talked about in your last post.  As an example, as of this morning, all packed files downloaded in my org are extracted from the network and sent to VirusTotal, Symantec, and now CWSandbox, and the results are collected and stored in a local database for data mining purposes.<br>
<br>In any case, my goal is not to start a flame war over which programming language is best, but many vendors (like VMWare, HP, IBM, Cisco) chose to use Perl as the language in which to publish modules because of its ubiquity and extensibility.  I think that most of our work will be analytical in nature, and this work is best done away from the packet sniffing/recording environment in a framework based on a dynamic language.  I furthermore think that the best-suited dynamic language is Perl (maybe even Perl 6's Parrot platform).  All of this is of course debatable, and I welcome rebuttals.<br>
<br>--Martin<br><br><div class="gmail_quote">On Wed, Oct 29, 2008 at 2:55 PM, Seth Hall <span dir="ltr"><<a href="mailto:hall.692@osu.edu">hall.692@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
On Oct 29, 2008, at 2:13 PM, David J. Bianco wrote:<br>
<br>
> There was some discussion on this list about Bro.  I'm a big fan of<br>
> Bro.<br>
> It performs very well in the pattern analysis and policy-based<br>
> detection<br>
> arenas, in which Snort (and thus, Sguil) do poorly.  Conversely, Bro's<br>
> signature matching abilities aren't very good, and it certainly<br>
> doesn't have<br>
> a robust sig library like Snort does.<br>
<br>
</div>Bro's signature matching is only poor because it isn't used much by<br>
anyone that uses Bro heavily.  I don't believe that it would be too<br>
much of a project to flesh out the signature matching capabilities of<br>
Bro to mirror Snort.  One area where Bro's signature matching already<br>
bests Snort is in its ability to have bidirectional signatures.  You<br>
can define a signature that only triggers if another signature is seen<br>
in the opposite direction of the connection.  For example, if you're<br>
matching something that requests a certain URL, maybe you only care<br>
about it the server responds to the client with a 200 status code.<br>
This is easy to do with bidirectional signatures.  You can also have<br>
signature matches thrown into Bro policy script code so that you can<br>
do any number of extended heuristics based on other information Bro<br>
has detected.<br>
<div class="Ih2E3d"><br>
> My view is that they are both complementary technologies, and should<br>
> be<br>
> deployed in tandem.  It has been suggested on this list that Bro be<br>
> the<br>
> engine for future OISF implementation.  Great idea!  But I propose<br>
> that<br>
> we consider our project a framework, or suite of tools, and that Bro<br>
> be<br>
> a critical *piece* of that framework, but  not the only framework.<br>
<br>
</div>In my opinion, Bro would actually make a very general framework to<br>
build upon.  Bro is already more or less a general network analysis<br>
framework.  It has support for lots of various technologies that<br>
people want in order to do network traffic analysis and typically it's<br>
fairly easy to add new functionality building on top of existing<br>
functionality.  As an example of this, yesterday I wrote some small<br>
extensions that will identify windows executables being transferred<br>
over HTTP with libmagic and once a windows executable is identified it<br>
will begin building an MD5 hash of the data.  It then takes the MD5<br>
hash and checks it with the newly announced Team Cymru Malware Hash<br>
Repository[1] in realtime to see if they have that binary file in<br>
their malware repository.  If you would like to see how little code I<br>
had to write to make it work, here's the link to my changes:<br>
   <a href="http://github.com/sethhall/bro_scripts/tree/master/md5_hash_malware" target="_blank">http://github.com/sethhall/bro_scripts/tree/master/md5_hash_malware</a><br>
<br>
Malware Hash Registry docs:<br>
   <a href="http://www.team-cymru.org/Services/MHR/" target="_blank">http://www.team-cymru.org/Services/MHR/</a><br>
<br>
My point is just that Bro is very much in a position to be a central<br>
framework.  Much more so than any other tools currently available.<br>
<div class="Ih2E3d"><br>
> I can envision a scenario where I'd deploy, for example, signature<br>
> based<br>
> IDS (Snort), policy based IDS (Bro), correlated event alerts (OSSEC)<br>
> and<br>
> perhaps even application specific sensors (mod_security, database IDS,<br>
> spear phishing detection, etc).<br>
<br>
</div>The problem is that you're replicating effort there.  You'd have to<br>
maintain multiple machines just to run different tools (assuming<br>
you're looking at too much traffic to analyze on a single machine with<br>
multiple tools).  As I mentioned above, the problems with Bro's<br>
signature support are not due to a major failing in the software it's<br>
just temporarily suffering due to a lack of interest from the Bro<br>
community. :)<br>
<br>
It probably makes sense to feed the data from other tools like OSSEC<br>
into Bro first too because it has very good support for writing<br>
scripts that deal with data expiration over time and catching time<br>
based events.  We use it to look for anomalies and normalize our<br>
authentication logs by pushing a lot of them into Bro with the<br>
Broccoli library (it's included with Bro).  I know of another location<br>
that was using instrumented sshd servers to forward the content of all<br>
shell sessions to their Bro instance and looking for anomalies with<br>
the commands being typed over ssh to catch compromised accounts.<br>
<br>
After Bro has a chance to look at the data, it can then pass<br>
normalized and aggregated data (and maybe more notices if it caught<br>
anything strange in the data) into Squil and its database.<br>
<div class="Ih2E3d"><br>
> All these events should go to the same<br>
> analysis tool, they should be organized effectively, searchable,<br>
> cross-referenced, and tied to forensic data (network sessions, packet<br>
> captures, log files, etc).<br>
<br>
</div>I definitely agree with this!  Bro doesn't have anything yet that is<br>
end user focused towards doing forensics with the data being<br>
generated.  If Squil could give it that frontend, that would be awesome.<br>
<div class="Ih2E3d"><br>
> In fact, we're much of the way there already.  I released an agent to<br>
> slurp OSSEC events into Sguil quite some time ago, and we have done<br>
> the<br>
> same with other data sources as well.  Communication between Bro and<br>
> Sguil<br>
> is on my TODO list as well.  So really, the idea of deploying multiple<br>
> types of sensors feeding into the same analysis tool is a practical<br>
> one.<br>
> I think this should be a design goal of the project.<br>
<br>
</div>If you'd like assistance with integrating Squil and Bro, I'd be glad<br>
to give some pointers or lend a hand with it. :)<br>
<br>
   .Seth<br>
<br>
---<br>
<font color="#888888">Seth Hall<br>
Network Security - Office of the CIO<br>
The Ohio State University<br>
Phone: 614-292-9721<br>
</font><div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
Discussion mailing list<br>
<a href="mailto:Discussion@openinfosecfoundation.org">Discussion@openinfosecfoundation.org</a><br>
<a href="http://lists.openinfosecfoundation.org/mailman/listinfo/discussion" target="_blank">http://lists.openinfosecfoundation.org/mailman/listinfo/discussion</a><br>
</div></div></blockquote></div><br>