The trip to Amsterdam was totally uneventful yesterday and I was at the venue half an hour early. After looking around, picking up my badge and fetching a cup of coffee, it was time to sit down and start listening to the first presentation.

After a brief introduction, Martin Roesch took the floor and gave the audience (20-25 men) a nice view of how Snort came to be as it is now, and how Sourcefire is going to develop it to their version 3.

In his presentation Marty identified a serious problem. All IPS's today still need serious customizing and/or tuning before they generate output that is useful (low number of false positives, no false negatives). Marty stated that "Tuning as we know it today is a failure". Users are not intimitely aware of their networking infrastructure or server environment. Additionally, the rules that drive most IDS's are too complex, large, and interconnected. As a result, configuring IDS's with more than a few sensors is a very complicated and error-prone tasks.

Marty identified the root problem of present-generation IDS's to be the fact that most are all-purpose systems that have no knowledge about the assets that they are defending. An example that came back a number of times was that of a Code-red attack against an Apache webserver. Code Red is a buffer overflow attack, which is typically classified as an attack with a high priority. However, if the IDS would take into account that the attack was targeting an Apache server, it would be able to decide that the attack has no chance of succeeding, which would lower the priority of the event.

I asked a question: would it also be of value to not only incorporate knowledge of the asset that is being attacked, but also to include knowledge about the source of the attack? I illustrated my question with a similar example: suppose a code-red attack is detected against an apache server. Taking target-specific knowledge into consideration, that attack would most likely be classified a low-impact event. Now, add the fact that this attack originated from within the organization, and possible even from the CEO's laptop. That additional knowledge would conceivably be a very good reason to increase the priority of the event to one of high-priority. While the attack directed against the target was not important, the fact that it originated from the CEO's laptop definitely changes that perception.

Unfortunately, Marty was not able to give me an adequate answer to my question

The second part of Marty's presentation was about the product offerings of Sourcefire. Sourcefire's ,3D (PDF, 2.1Mb) approach (Discover, Determine, Defend), which stretches across the facets Before, During and After an Attack, reminded me sharply of Cisco's self-defending network concept. The underlaying premise is that defending against attacks is much more efficient when all defensive components communicate with each other, so that knowledge about the assets that are being defended can be exchanged. The 3D's (Discover, Determine, Defend) also closely resemble Cisco MARS's Monitoring, Analysis, Respond core functions.

All in all, I enjoyed the presentation and I learned more about the backgrounds of Sourcefire and of Snort. Additionally, I always find it very interesting to listen to successful Free Software entrepreneurs. In that, I admire what Marty's has achieved with Sourcefire and I am very grateful for him to keep this great product available as Free Software.

update Note to self: do not post to blog without proof-reading first. Many typos and lots of grammar fixed,.