Een door een Nederlander ontwikkeld systeem moet straks de motor zijn van alle systemen die inbraken door hackers moeten detecteren. Victor Julien is de hoofdontwikkelaar van Suricata, een open source Intrusion Detection Systeem (IDS) vernoemd naar de altijd oplettende stokstaart. Eerder werkte Julien ook al aan Vuurmuur, een open source firewall.

Security.nl sprak met Julien. Donderdag verscheen het eerste deel, vandaag het tweede en laatste deel.

Wat is het businessmodel achter Suricata?
Julien: Suricata's ontwikkeling is juridisch georganiseerd in de Open Information Security Foundation (OISF). De OISF is een geregistreerde non-profit in de VS. De OISF bezit alle Suricata code en wordt bestuurd en gecontroleerd door de community. In ons handvest is opgenomen dat we de code altijd beschikbaar houden als open source. Het mag dus duidelijk zijn dat er geen winstoogmerk is.

Onze initiële financiering komt van de Department of Homeland Security (DHS), een ministerie van de federale overheid in de VS. Momenteel zitten we in een transitie van die overheidsfinanciering naar financiering door het bedrijfsleven. Hiervoor hebben we een consortium opgezet. Marktpartijen kunnen lid worden en doneren geld, apparatuur, code of andere dingen die van waarde zijn voor OISF. In ruil krijgen ze exposure, toegang tot de ontwikkelaars en een licentie op de code die integratie in commerciële producten mogelijk maakt.

Op deze manier hopen we het project op de lange termijn levensvatbaar te houden.

Wat hoop je met het Suricata IDS te bereiken?
Julien: Hoewel ik zelf erg enthousiast ben over een IDS/IPS engine, snap ik dat de meeste mensen vooral geïnteresseerd zijn in het grotere geheel en vooral ook bruikbare producten. De meest bedrijven in onze sector besteden dan ook erg veel moeite aan mooie gui's, beheertools en professionele rapportagemogelijkheden. De kwaliteit van de IDS engine lijkt maar van beperkt belang, ook bij veel kopers. De IDS engine zelf is maar in beperkte zin een "business differentiator".

Wat wij willen zijn, is het standaard IDS/IPS engine component voor al die bedrijven. Net zoals bijna geen enkel bedrijf nog een eigen kernel/OS gaat ontwikkelen voor een product maar gewoon Linux gebruikt, denken wij dat er ook een IDS engine kan zijn die de standaard wordt voor integratie. Die engine doet alles wat sowieso goed moet zijn en de bedrijven kunnen dan daarbovenop hun eigen waarde gaan toevoegen.

In ons consortium model hopen we dat al die bedrijven een beperkte bijdrage leveren aan de ontwikkeling. OISF kan dan op lange termijn aan de engine blijven werken. Dit is dan voor iedereen goedkoper, aangezien het bouwen en onderhouden van een IDS engine kostbaar is.

Hoe maken jullie de signatures om aanvallen te detecteren en hoe hou je die up-to-date
Julien: Wij maken zelf geen eigen signatures/rules. Het welbekende Emerging Threats project ondersteunt Suricata met een specifieke ruleset. Maar omdat we veruit de meest Snort signatures ondersteunen, zal ook Sourcefire's VRT ruleset werken. Dit wordt echter niet door Sourcefire's VRT ondersteund dus Emerging Threats is de beste optie. Uiteraard kunnen gebruikers ook zelf signatures ontwikkelen. We hebben verschillende tools ingebouwd die feedback geven over de regels, met betrekking tot performance maar ook over de kwaliteit van de regels.

De meeste mensen zullen bestaande tools als Oinkmaster en Pulledpork gebruiken voor de dagelijkse rule updates. Suricata heeft een mogelijkheid regels te herladen zonder herstart, dus zonder iets van het verkeer te hoeven missen.

Wat is de toegevoegde waarde van een IDS, aangezien signatures niet erg effectief meer zijn in het herkennen van nieuwe aanvallen/dreigingen?
Julien: Signatures hebben zeker beperkingen, maar zijn vaak ook nog wel nuttig. Overigens hebben we lichtgewicht scripting optie ingebouwd in onze huidige beta, gebaseerd op Lua. Door Luajit te gebruiken is de performance nog best aardig. Er zijn inmiddels interessante scripts opgedoken, die bijvoorbeeld een gecomprimeerd Flash-bestand uitpakken en vervolgens op een specifieke kwetsbaarheid kunnen testen.

Mijns inziens heeft een IDS op zichzelf maar beperkte waarde. Het geeft de gebruiker een indicatie dat er mogelijk iets is gebeurd, maar daarbij slechts zeer beperkte context. Iedereen die zich serieus bezig houdt met indicent response kan waarschijnlijk beamen dat op basis van een alleen IDS alert/event het vaak onmogelijk is om vast te stellen of er sprake is van een false positive of een echte aanval, en of in het laatste geval de aanval ook geslaagd is.

Om deze reden zien we dat er steeds meer context wordt toegevoegd. Zelf ben ik van mening dat een IDS eigenlijk alleen zou moeten worden gebruikt als onderdeel van een complete Network Security Monitoring (NSM) architectuur.

Wat vind je van anomaly detectie? [het detecteren van aanvallen aan de hand van verdacht gedrag – red.]
Julien: Voor NIDS en NIPS heeft 't mijns inziens nog niet veel opgeleverd, de verscheidenheid en veranderlijkheid van netwerkverkeer is veel te groot. Bij meer domeinspecifieke aanpakken kan het denk ik wel wat opleveren, bijvoorbeeld bij het leren wat voor HTTP request parameters "normaal" zijn bij verkeer naar je webservers. Een aanvullend probleem is rapportage. Er was ooit een statistische detectie module voor Snort. Niemand begreep de output er van, behalve mensen die statistiek hadden gestudeerd waarschijnlijk. Aangezien false positives ook bij anomaly detectie een probleem zijn, is begrijpelijke rapportage essentieel. In Suricata zijn regels logisch opgebouwd en goed voor een incident responder te volgen.

Hoe waarborg je veilige ontwikkeling in een open source project?
Julien: Als hoofdontwikkelaar ben ik de enige met commit rechten op ons source code management systeem. Dus alle code loopt via mij. Ik review alles. Daarnaast doen andere ontwikkelaars ook reviews van elkaars patches. Github heeft het review proces overigens een stuk makkelijker gemaakt.

Gebruiken jullie richtlijnen/checklists voor veilig programmeren?
Julien: We proberen ons zoveel mogelijk aan de Cert C Secure Coding standard te houden. Ik zie hier op toe in reviews. Ook hebben we hebben "banned" functies en andere code constructies die we geautomatiseerd afdwingen met coccinelle.

Hoe controleer je de code op beveiligingslekken en problemen?
Julien: We gebruiken veel geautomatiseerde checks. We hebben vele duizenden ingebouwde unittests. We gebruiken momenteel 3 statische code analyzers: het commerciële Coverity via een open source scan programma van Coverity, cppcheck en clang/scan-build. Allemaal met sterke en zwakke punten, maar elk zeer nuttig.

Dynamische analyse doen we vooral met valgrind.

Dan is er nog een heel batterij aan tools die meestal voor pentesting worden gebruikt: Metasploit, Nikto, etc voor de nauwkeurigheid van detectie, opmerken van evasions, etc.

We hebben verschillende live sensors, onder andere in verschillende buitenlands internetproviders, waarmee we op high speed netwerken kunnen testen.

Ten slotte doen we veel regresstion testing. We hebben vele terabytes aan netwerk verkeer opnames (pcaps) waaronder veel pcaps van specifieke problemen uit het verleden, hacks, command en control, etc.