Oisf Meeting and the Next Generation of Open Source Intrusion Detection Systems

Last week I had the opportunity to attend the first public planning/brainstorming session for the DHS seeded Open Information Security Foundation and their next generation IDS project. Lots of good discussion, with the first couple hours focusing on the foundation itself, and the rest of the day was spent discussing various features that would be required by the IDS and roughly prioritising them into “version 1″ or “later” categories.

For those of you who aren’t familiar with OISF, they were created primarily to build this next generation ids, and license it under GPLv2, but also allowing less restrictive licensing to vendors who don’t want to reveal/publish proprietary additions/plugins, and providing a safeguard against taking a source tree private/commercial. Something that has happened in many community projects in the past and left a lot of sour feelings from volunteer developers.

Onto the software. Most of the features discussed were obvious things that would be present, multi threading, stream and packet models, and ipv6 support, but there were a few that you may not be familiar with, such as IP reputation, scoring thresholds and hardware acceleration. You can read more about the details of each on the oisf wiki, but reputation and scoring thresholds basically allow for implementing some distributed/fuzzy logic into the system. But the hardware acceleration highlights a real balance that the OISF board/developers are going to have to maintain. The project has to be directed primarily towards beige box x86 platform, but they’re getting a lot of support from Endace currently, and probably others soon. The best case would be great support for both, but often timelines, schedules, and in development efforts interest in writing the code make that unlikely.

As far as how this relates to control systems, theres a lot of interest in supporting various SCADA protocols and doing them well. This could be a big early win for them if they get some vendor support in the form of expertise and programmer hours, but without getting that vendor support/endorsement use by the asset owners is going to be minimal. But even then, many operators seem to shy away from things that aren’t “fire and forget” solutions, and increased monitoring and maintenance required to get benefit from an IDS system would need a culture change in a lot of places. There are some definite advantages to getting in on the ground floor of the consortium, so if any of you in the vendor space are interest you’re going to have a lot more impact by acting now rather than later.

Overall I came away from the meeting optimistic. They have some very smart and dedicated people, and seem to have a good plan, and have resources to kickoff the project and keep it running for a while but everyone interested in supporting/using the ids have to realise that its a marathon and not a sprint. While they’re looking at version 1.0 at the end of the year, there is a lot of complicated code and it takes time to do it right and feature creep and clearly defined scope are going to be dealt with quickly and decisively to stay on course. The value and chance of success of the project increases significantly with each additional group involving in supporting it, but its a significantly higher risk/reward for early committals and getting a few of those are going to be the key to their success.