INTRUSION DETECTION SYSTEMS

Transcriptie

1 INTRUSION DETECTION SYSTEMS POSTADRES Postbus AA Den Haag BEZOEKADRES Wilhelmina van Pruisenweg AN Den Haag TELEFOON FAX Auteur : GOVCERT.NL Versie : 1.2 Den Haag : 21 maart 2008

2 0 SAMENVATTING Sinds begin jaren 2000 was er sprake van een sterke toename van de toepassing van Intrusion Detection Systems (IDS) als belangrijke schakel van netwerkbeveiliging. Ondertussen is veel geleerd over de IDS-sen en kan meer genuanceerd gesproken worden over de manier waarop ze effectief ingezet kunnen worden. Een IDS is een systeem dat ongeautoriseerde toegangen tot een informatiesysteem of netwerk herkent en signaleert. Het is dus een middel dat als detectiemaatregel ingezet kan worden. Deze white paper geeft een overzicht van de technologie en de factoren die van invloed zijn op het succes van de toepassing van IDS. IDS is geen Haarlemmer olie voor security problemen, maar vormt een onderdeel in de beveiligingsketen. Er moeten aan een aantal randvoorwaarden worden voldaan, om gebruik te kunnen maken van de toegevoegde waarde die een IDS kan bieden. Een goede organisatorische inbedding is één van de vereisten om optimaal gebruik te kunnen maken van een IDS. Een IDS kan effectief ingezet worden voor het verkorten van de responstijd bij aanvallen en het analyseren van de toedracht van een incident. Snel kunnen correleren van meldingen helpt hierbij. Daarnaast is het een bron van statistische informatie over onregelmatigheden op netwerken en systemen. Belangrijk is vooraf helder te maken voor welk doel IDS wordt toegepast en hoe dit in de aanpak voor security management past. Daarnaast moet rekening gehouden worden met additionele kosten in beheer en onderhoud en respons op meldingen, die hoger kunnen uitvallen dan vooraf voorzien. Een derde punt is dat een IDS niet kennis en ervaring kan vervangen bij het inschatten van de ernst van een melding en de prioriteitstelling bij vervolgstappen. Dit wordt versterkt omdat de betrouwbaarheid van de output van een IDS door loze alarmen en ongedecteerde aanvallen kan verminderen. Het monitoringsysteem dat GOVCERT.NL samen met SURFNet heeft ontwikkeld is een vorm van een gedistribueerde hybride IDS. Dit systeem maakt gebruik van enkele in deze white paper beschreven technieken.

3 INHOUD 0 Samenvatting Inleiding Positionering IDS Opbouw IDS Leeswijzer Waarom een IDS? Doelbepaling Scope bepaling Concepten Detectie van patronen of afwijkingen Network IDS of Host IDS Honeypots Passieve en reactieve Intrusion Detection systemen Intrusion prevention systems Generiek of specifieke IDS Aandachtspunten bij toepassing van IDS Kosten Tuning en updates Betrouwbaarheid output Uitvoeren van monitoring taken Interpretatie van IDS output Correlatie Versleuteling van dataverkeer Organisatorische Inbedding van een IDS Relatie met andere processen Beleid rondom een IDS Opzet IDS Kwetsbaarheden van IDS Omzeilen van IDS functionaliteit Toegang tot de IDS Locatie van het IDS Onbetrouwbare IDS output Ervaringen met een IDS Conclusies...25

4 1 INLEIDING Begin jaren 2000 was er sprake van een hype rondom de term Intrusion Detection Systems (IDS) waarbij deze werden gezien als een kernpunt van de netwerkbeveiliging. Inmiddels is duidelijk geworden dat het niet zo eenvoudig ligt. De betrouwbaarheid en het feit dat IDS-en per definitie achter de feiten aanhollen het kwaad is vaak al geschied op het moment dat een IDS het detecteert - speelt hierbij een grote rol. Toch kan een goed toegepaste IDS belangrijke informatie geven voor de response en afwikkeling van een beveiligingsincident. Deze white paper geeft een overzicht van de technologie en de factoren die van invloed zijn op het succes van de toepassing van IDS. NOOT 1 Detectiesystemen tegen fysieke inbraak in gebouwen worden ook vaak Intrusion Detection Systems genoemd. In deze white paper wordt met een IDS een component in een informatiesysteem of netwerk bedoeld. 1.1 Positionering IDS Een IDS is een systeem dat afwijkende patronen in toegang tot een informatiesysteem of netwerk signaleert en is dus duidelijk gepositioneerd als detectieve maatregel. Dreigingen Preventie Incident Detectie Repressie Herstel Evaluatie Figuur 1-1 De keten van beveiligingsmaatregelen In Figuur 1-1 is de samenhang tussen verschillende type maatregelen te zien. Intrusion Detection Systems versie maart /26

5 Preventieve maatregelen worden getroffen om relevante dreigingen het hoofd te bieden. Een firewall voorkomt ongeautoriseerde toegang tot een netwerk en is een preventieve maatregel. Dreigingen kunnen manifest worden als de preventieve maatregel faalt of als een geaccepteerd risico toch een incident tot gevolg heeft. Detectieve maatregelen zorgen voor herkenning van een incident. Een audit is een detectieve maatregel, net als een rookalarm. Ook een IDS is een detectieve maatregel. Vervolgens moeten er nog maatregelen aanwezig zijn die erop gericht zijn om de vervolgschade te kunnen beperken en de normale situatie te herstellen. Deze repressie- en herstelmaatregelen worden in gang gezet door detectie van een incident. Een vroege detectie, gevolgd door een doeltreffende reactie kan veel schade voorkomen. Het doel is de tijd tussen het begin van een incident en het moment van ingrijpen zodanig te verkorten dat schade kan worden voorkomen. Ten slotte zal op basis van een evaluatie bepaald moeten worden hoe het incident heeft kunnen plaatsvinden en welke maatregelen eventueel aangepast moeten worden. Een IDS op zichzelf speelt hiermee een beperkte rol in de gehele keten van beveiliging. Deze rol wordt sterker als het is gekoppeld aan effectieve respons. De maatregelen liggen niet alleen op technisch vlak en daarom is het noodzakelijk om ook de organisatorische inbedding van een IDS te realiseren. 1.2 Opbouw van een IDS Monitor (presentatie) Log Output Engine Processing Data Sensor Sensor Sensor Sensor Figuur 1-2 Generieke opbouw van een IDS Figuur 1-2 geeft schematisch weer uit welke generieke componenten een IDS in het algemeen is opgebouwd: Eén of meerdere sensoren die in de datastroom speuren naar elementen die een incident kunnen vormen en de waarnemingen daarvan doorgeven. Intrusion Detection Systems versie maart /26

6 Een centrale verwerkingseenheid die de waarnemingen van de sensoren verwerkt, correleert en dit vertaalt naar waarschuwingen. Daarbij kunnen de resultaten van de sensoren door de engine opgeslagen worden in een database. De monitor (ook wel console genoemd) wordt vervolgens gebruikt om de waarschuwingen op een voor mensen begrijpelijke vorm te presenteren. Afhankelijk van de fabrikant en omvang van een IDS kunnen deze componenten verdeeld zijn over verschillende systemen of geïntegreerd zijn in één systeem. 1.3 Leeswijzer Dit rapport biedt handvatten voor het opzetten van een Intrusion Detection System. Hoofdstuk 2 gaat in op het bepalen van het doel en scope van een IDS. Daarna wordt in Hoofdstuk 3 ingegaan op de verschillende IDS concepten. De met een IDS samenhangende probleemgebieden en valkuilen worden in Hoofdstuk 4 beschreven. De organisatorische en beleidsmatige aspecten komen in Hoofdstuk 5 aan bod. Een IDS kent ook kwetsbaarheden, welke in Hoofdstuk 6 worden beschreven. Om te leren van de praktijk wordt in Hoofdstuk 7 de ervaringen uit het monitoringproject van GOVCERT.NL gegeven. In dit document wordt veelvuldig gebruik gemaakt van afkortingen en specifieke termen. Een overzicht van alle gebruikte afkortingen en termen kunt u terugvinden in Bijlage A. NOOT 2 Indien in dit document de naam van een product, dienst, fabrikant of leverancier wordt genoemd betekent dit niet dat GOVCERT.NL deze op enige wijze goedkeurt, afkeurt, aanraadt, afraadt of anderszins hiermee verbonden is. Intrusion Detection Systems versie maart /26

7 2 WAAROM EEN IDS? Het in stand houden van een IDS, inclusief de organisatie eromheen is niet triviaal. Het advies is dan ook eerst goed na te denken over het doel van een IDS voordat besloten wordt om deze daadwerkelijk in te zetten. Want mits goed toegepast kan een IDS een waardevolle bron van informatie zijn, maar de hoeveelheid informatie kan evengoed een valkuil worden. De twee kernvragen om te stellen zijn: En 1. Over welke incidenten wil ik informatie verzamelen? 2. Wat wil ik vervolgens met deze informatie doen? De vraag die daaruit logisch volgt is uiteindelijk: 3. Kan een IDS daadwerkelijk bijdragen aan een antwoord op de voorgaande vragen? Om optimaal gebruik te kunnen maken van een IDS is een duidelijk beeld noodzakelijk over het doel waarmee het wordt ingezet. Dit heeft namelijk sterke invloed op de wijze waarop een IDS moet worden geïmplementeerd in een organisatie. Soms is het doel vooraf duidelijk, m.n. als het gaat over het beschermen van een specifiek systeem of bepaalde informatie. De vraag is dan vooral hoe een IDS het beste toegepast kan worden. 2.1 Doel van het IDS Het doel waarmee een IDS wordt ingezet bepaalt onder andere de complexiteit van een IDS, waar een IDS wordt geïmplementeerd en hoe de (beheer)organisatie rondom een IDS er uit ziet. Doel: statistische informatie Vaak wordt een IDS ingezet voor het verkrijgen van statistische informatie. Denk hierbij bijvoorbeeld aan rapportages over het aantal gedetecteerde inbraakpogingen Hierbij kan de vraag gesteld worden of deze informatie echt relevant is voor de organisatie of dat het bedoeld is als scare tactic richting het management. Een andere meer positieve benadering is gebruiken van deze rapportages om de effectiviteit van beveiligingsmaatregelen te bepalen. Als dit het doel is van een IDS is het goed om te weten dat de informatie voor dit soort rapportages in de vorm van logginginformatie vaak al elders in de organisatie beschikbaar is. Intrusion Detection Systems versie maart /26

8 Figuur 2-1 Voorbeeld van statistische informatie uit het monitoringsysteem. Uit deze grafiek blijkt dat 62% van de aangeboden malware niet herkend wordt door de virusscanners op het analysesysteem. Doel: detectie Behalve het verzamelen van informatie over wat er speelt op de IT-infrastructuur is een ander doel van IDS de reactietijd bij een incident te versnellen. Als een inbraak pas bij de wekelijkse controle van de logfiles wordt gesignaleerd kan al veel schade berokkend zijn. Ook kunnen wormbesmettingen soms vroegtijdig ontdekt worden door een toename van poortscans op het netwerk. Door een snelle analyse en reactie kan een grootschalige uitbraak en hiermee afname van beschikbaarheid van systemen worden voorkomen. Doel: analyse Informatie uit een IDS kan worden toegepast om de toedracht van een incident achteraf te reconstrueren. Deze informatie is vaak gedetailleerd en relevant, mits de IDS-sen goed geplaatst en geconfigureerd zijn. Als dit het enige doel van de IDS is, is het goed na te gaan of dezelfde informatie niet al gelogd wordt op andere plaatsen in het systeem, bijvoorbeeld een firewall log. 2.2 Scope van het IDS Na de keuze van het doel moet het toepassingsgebeid bepaald worden. In het kader van IDS wordt onderscheid gemaakt tussen de beveiliging van de infrastructuur en de beveiliging van informatie. Scope: beveiliging van infrastructuur De beveiliging van de infrastructuur richt zich vooral op het verkrijgen van inzicht of er ongeautoriseerde toegang tot of wijzigingen aan componenten in de infrastructuur plaatsvinden (proactief) of hebben plaatsgevonden (reactief). De Intrusion Detection Systems versie maart /26

9 benodigde informatie over de infrastructuur is vaak in handen van één organisatieonderdeel, de ICT organisatie. Het verkrijgen van inzicht in de beveiliging van de infrastructuur is vaak eenvoudiger te realiseren dan inzicht in de beveiliging van informatie. Dit wil overigens niet zeggen dat het simpel is. Hoe complexer de infrastructuur hoe complexer een IDS voor de beveiliging hiervan zal zijn. Scope: informatiebeveiliging Om inzicht te krijgen in ongeautoriseerde toegang tot informatie moet bekend zijn wie bij welke informatie mag en waar ongeautoriseerde toegang uit bestaat. Hiervoor is een vergaand inzicht in de samenhang informatiestromen en de infrastructuur noodzakelijk. De inrichting van een IDS zal in dit geval een stuk complexer worden omdat meerdere organisatieonderdelen hier een rol in zullen spelen. Scope: Incidenten Het kan zijn dat specifieke incidenten door het IDS gedetecteerd moeten worden, bijvoorbeeld bepaalde typen malware of netwerkscans. Dit heeft direct invloed op het type en de plaatsing van de IDS. 2.3 Voorbeelden Hieronder volgen een aantal voorbeelden waarvoor een IDS ingezet kan worden. Inzet van een IDS voor het vaststellen van ongeautoriseerde wijzigingen op de infrastructuur. Als alternatief hiervoor kan gekeken worden naar het aanscherpen van wijzigingsprocedures voor de infrastructuur. Van belang is om vast te stellen wat het gewenste effect is en welk geheel van maatregelen hier het beste bij past binnen een organisatie. Inzet van een IDS bij het ondersteunen van forensisch onderzoek. Hierbij wordt een IDS gebruikt om na een incident na te kunnen gaan wat er gebeurd is en speelt dus een belangrijke rol in de evaluatie van een incident. Indien het ook de bedoeling is om dit te gebruiken in een juridisch proces is het noodzakelijk om de gegevens uit een IDS te verzamelen en op te slaan conform de juridische eisen. Inzet van een IDS als audit/evaluatie middel waarbij een IDS helpt om ongeautoriseerde systemen en applicaties op te sporen. Ook hierbij kunnen juridische aspecten een rol spelen bijvoorbeeld wanneer een IDS een van de maatregelen is om aan te kunnen tonen dat aan voorgeschreven regels wordt voldaan. Uit de voorgaande voorbeelden is af te leiden dat het doel waarvoor een IDS wordt ingezet in sterke mate bepaalt hoe een IDS organisatorisch ingebed wordt. Intrusion Detection Systems versie maart /26

10 3 CONCEPTEN Er is een aantal verschillende IDS-concepten te onderkennen. Dit is vaak een bron van verwarring met betrekking tot de rol die een IDS kan vervullen in het beveiligen van een organisatie, omdat ieder concept z n eigen toepassing kent. Dit hoofdstuk gaat in op de verschillende concepten die de basis vormen van de huidige verschijningsvormen van een IDS. 3.1 Detectie van patronen of afwijkingen Ruwweg zijn er twee concepten voor de werking van een IDS. Enerzijds is het mogelijk om op basis van patronen of zogenaamde signatures te werken. Dit zijn karakteristieken van specifieke aanvallen die een IDS gebruikt om te bepalen of die aanval plaats vindt. Ieder type aanval kent een eigen patroon, zoals een poortscan of de toepassing van een bepaalde exploit. Een IDS controleert dus niets anders dan of de acties die het ziet voldoen aan een bekend patroon. Het grote nadeel van deze signatures is dat de aanval in principe al bekend moet zijn bij de IDS leverancier en dat deze hiervoor een werkende signature beschikbaar heeft. Er kan dus een lange tijd sprake van zijn dat de aanval wel kan worden uitgevoerd, terwijl deze niet kan worden gedetecteerd. In feite specificeert een signature-based IDS alle mogelijke bekende ongewenste gedragingen. Anderzijds kan het IDS ook gebruik maken van zogenaamde afwijking of anomaly detectie. Dat wil zeggen dat het IDS kennis heeft wat normaal gedrag is. Op het moment dat gedrag daar (te veel) van afwijkt, geeft het een waarschuwing af. Deze methode probeert dus het grote probleem van signatures te vermijden, door te definiëren wat toegestaan is. Een eenvoudig voorbeeld van zo n regel kan zijn: werknemers werken normaliter tussen 9 en 5 uur. In die periode mogen dus werknemers inloggen op hum werkplek. Wanneer er dus om 1 uur s nachts wordt ingelogd is er sprake van een afwijking op het normale gedrag. Samenvattend is een signature detectie systeem een systeem dat definieert wat niet is toegestaan, terwijl een anomaly detectie systeem definieert wat wel is toegestaan. Deze laatste vorm van detectie anomaly - is tamelijk moeilijk te implementeren, zeker wanneer er sprake is van complexe aanvallen. Ook is een leerperiode nodig voor het goed functioneren van een anomally based IDS 3.2 Network IDS of Host IDS Een Intrusion Detection Systeem kan op twee manieren worden ingezet. Het uitgangspunt is dat detectie plaatsvindt op een plek zo dicht mogelijk bij de bron van de aanval of zo dicht mogelijk bij het doel van de aanval. In geval van een netwerk IDS wordt het eerste gekozen, met als aanname dat de aanvallen via de externe koppeling het eigen domein in komen. In de praktijk zal dit in een DMZ zijn, in de buurt van de firewall behorende bij die koppeling. Ook op andere knooppunten in het netwerk kan zo n Network based IDS (NIDS) worden geplaatst. Een NIDS richt zich dan ook op het detecteren van aanvallen die op het netwerk gericht zijn of van het netwerk gebruik maken. Een NIDS richt zich vaak op een breed scala van systemen, namelijk van welke het de netwerkstromen kan Intrusion Detection Systems versie maart /26

11 inspecteren, en dus over de netwerkinterface van het NIDS komen. Snort 1 is een typisch voorbeeld van een Netwerk IDS. Figuur 3-1, voorbeeld van plaatsing van NIDS in de netwerkinfrastructuur. De plaatsing is afhankelijk van het doel en zo dicht mogelijk bij de bron Een Host based IDS (HIDS) daarentegen is een applicatie die op het eindsysteem wordt geplaatst. Dit kan zowel serversystemen betreffen als ook werkstations van gebruikers. Naast netwerkaanvallen die specifiek gericht zijn op het systeem, kan een HIDS ook aanvallen die op applicaties gericht zijn onderzoeken. Hierbij valt te denken aan het voorkomen van buffer overflows, of het overschrijven van systeembestanden. Een HIDS is vaak sterk geïntegreerd in het operating systeem waar het op draait en kan in principe ook de interne datastructuren van het OS monitoren om te bepalen of er sprake is van een aanval. Veelal zijn dergelijke producten voor de consumentenmarkt geïntegreerd in een personal firewall of virusscanner. Virusscanners zijn in principe niets anders dan een specialistische vorm van een HIDS. Deze detecteren, voornamelijk op basis van signatures, of bestanden virussen 2 bevatten. Een andere specifieke vorm van een HIDS is een applicatie die de integriteit van bestanden beschermd zoals AIDE 3 of de commerciële producten van Tripwire. Een dergelijke applicatie genereert van alle of een geselecteerd aantal bestanden een zogenaamde signature in feite is dit niets anders dan een hash functie en controleert het periodiek of de bestanden gewijzigd zijn. Zo ja dan is er blijkbaar Virussen, of wormen en andere malware 3 Intrusion Detection Systems versie maart /26

12 een aanval geweest. In sommige gevallen wordt deze functionaliteit ook in een virusscanner geïmplementeerd. Het probleem met deze software is dat het altijd achteraf controleert of er iets is misgegaan. Tevens is het dan heel moeilijk om het vertrouwen ergens op te baseren, namelijk wanneer er een aanval heeft plaatsgevonden, is het zeer goed mogelijk dat de aanvaller ook aanpassingen heeft gedaan in het IDS of het besturingssysteem, waardoor de detectie niet meer goed werkt. De enige manier om dit af te vangen is het controle mechanisme alsmede de signatures gescheiden op te slaan en het controle mechanisme te gebruiken in een vertrouwde toestand. Het is ook verstandig de IDS te verbergen, bijvoorbeeld door de netwerkinterface geen IP-adres toe te kennen of te verbinden met een read-only interface. 3.3 Honeypots Om aanvallers af te leiden van echte systemen worden er soms systemen ingezet die ogenschijnlijk eenvoudig zijn te misbruiken een dergelijk systeem wordt ook wel honeypot genoemd. In vele gevallen wordt hierbij ook een detectie systeem ingezet die waarschuwt op het moment dat een aanval plaatsvindt. Een honeypot kan een complete, maar ongebruikte omgeving bevatten (z.g. hig-hinteraction honeypots). Er zijn ook speciale systemen beschikbaar die wel de interfaces bieden maar niet de functionaliteit (de low-interaction honeypots). Een honeypot kan naast afleiding ook als doel hebben om inzicht te krijgen in aanvallen die plaatsvinden waardoor in het feitelijke netwerk al acties kunnen worden ondernomen om hiertegen bescherming te bieden. Het uitgangspunt is dat een honeypot een aantrekkelijker doelwit moet lijken dan het feitelijke netwerk. Een implementatie van honeypots is het Honeynet project 4 dat gebruikt maakt van verschillende toepassingen om onderzoek te doen naar nieuwe aanvallen die op Internet plaatsvinden. Ook het monitoringsysteem van GOVCERT.NL maakt gebruik van honeypots. 3.4 Passieve IDS en reactieve IDS Oorspronkelijk is een IDS een systeem dat gebruikt wordt om inbreuken te detecteren. In feite betekent dit dat het passief is, het geeft alleen aan dat er iets aan de hand is en specificeert voor zover mogelijk wat het probleem is. Het is echter ook mogelijk om een reactief IDS op te zetten. Een reactief IDS reageert op de gedetecteerde aanvallen. Op technisch niveau zijn er talloze manieren waarop een IDS kan reageren op een aanval. Hierbij valt te denken aan het afsluiten van een TCP verbinding door een TCP Reset te sturen naar beide eindpunten van de verbinding of door het tijdelijk blokkeren van een IP adres of IP range in de firewall of door een actie te blokkeren. Hierin schuilt echter een gevaar, namelijk dat het IDS wordt gebruikt om een Denial of Service (DoS) te realiseren. Ook kan dit als resultaat hebben dat er onnodige reacties plaatsvinden die het goed functioneren van de te beschermen omgeving tegengaan. Bij het definiëren van acties is het erg belangrijk vast te stellen wat de mogelijke gevolgen van een actie zijn. Een reactieve IDS vertoont een zekere overlap met het IPS concept, zie paragraaf 3.5. Het grote verschil tussen een 4 Intrusion Detection Systems versie maart /26

13 reactieve IDS en een IPS is dat een IPS een pro-actief wordt ingezet om aanvallen te voorkomen. 3.5 Intrusion prevention systems Een Intrusion Prevention System (IPS), kan enerzijds worden gezien als een uitbreiding op het concept van een IDS, maar anderzijds is het eerder een uitbreiding op het concept van een firewall waarbij ook op applicatie niveau wordt gecontroleerd. In feite is een IPS een functionaliteit die netwerkverkeer opvangt en op basis van access control regels bepalen of het verkeer al dan niet wordt toegestaan. In vele gevallen wordt dit geïntegreerd in een firewall of in een proxy systeem. 3.6 Generiek of specifieke IDS De meeste IDS-en zijn tamelijk generiek opgezet. Dat wil zeggen ze zijn dusdanig ontwikkeld dat ze zoveel mogelijk aanvallen kunnen detecteren, meestal gericht op Internet omgevingen. Daarnaast zijn er ook systemen die zich meer richten op specifieke dreigen. Hierbij valt bijvoorbeeld te denken aan fraude management systemen die gebruikt worden door telecom providers om verdachte (trans)acties op het gebied van telefoonverkeer te vinden en het bijbehorende billing systeem. 3.7 Opzet IDS Er is een aantal verschillende redenen mogelijk om een IDS in gebruik te nemen. Over het algemeen is de belangrijkste reden om inzicht te krijgen in het netwerkverkeer (zie ook hoofdstuk 2, Waarom een IDS?). Pas als het doel duidelijk is, is het mogelijk om te bepalen hoe en waar een IDS ingezet moet worden. Dit is van toepassing op zowel de netwerkarchitectuur (bij NIDS) als op de inbedding in de organisatie. In het geval van HIDS is de netwerkarchitectuur minder relevant, omdat deze applicatie altijd op de hostcomputer aanwezig is. De output van de HIDS moet vaak wel via het netwerk naar een centrale server gestuurd worden voor correlatie en analyse, maar dit wordt over het algemeen over het normale intranet gedaan. In geval van NIDS wordt hier ook wel een parallel managementnetwerk voor gebruikt (zoals weergegeven in Figuur 3-1. Het sterke punt van een HIDS is het feit dat het naar meer bronnen kijkt dan alleen netwerkverkeer om inbraken te bepalen. Zo kunnen ook bepaalde hardware gegevens, zoals de inhoud van het geheugen, worden gebruikt. Een NIDS kan dit niet en zal daarom altijd afhankelijk zijn van het netwerkverkeer om analyses op te baseren. Een NIDS kan informatie verschaffen in de aanvallen die van het externe netwerk komen door het NIDS tussen die netwerkkoppeling te plaatsen. Als het goed is worden die aanvallen geneutraliseerd door middel van een firewall; om inzicht in het totale patroon van aanvallen te krijgen kan er ook een IDS aan de andere kant van de firewall geplaatst worden. Dit wordt toegepast bij GOVCERT.NL s monitoringsysteem, waarbij de sensoren buiten de firewall en buiten de normale datastroom staat. Intrusion Detection Systems versie maart /26

14 Omdat een NIDS vaak inzicht moet hebben in al het verkeer zijn er twee mogelijkheden: 1. het NIDS is een systeem met meerdere netwerkinterfaces, welke geplaatst is tussen de netwerkkoppeling waar al het verkeer doorheen gaat; 2. het NIDS wordt naast de te monitoren koppeling(en) geplaatst, en door middel van de netwerkconfiguratie wordt gerealiseerd dat alle data bij het NIDS aankomt. In Figuur 3-2 zijn deze twee alternatieven schematisch weergegeven. Alternatief 1 NIDS Netwerksegment A Netwerksegment B Alternatief 2 NIDS Netwerksegment A Netwerksegment B Figuur 3-2 Plaatsing van een NIDS als schakel in de koppeling of als monitor ernaast Het nadeel van alternatief 1 is dat het NIDS een Single Point of Failure (SPoF) is, maar staat wel toe dat het NIDS direct maatregelen neemt. Een voorbeeld hiervan is het tegenhouden van aanvallen na detectie. Ook de prestaties van het NIDS worden belangrijker, deze beïnvloeden immers de netwerkcapaciteit van de koppeling. Bij mogelijkheid 2 kan het IDS ook ingrijpen, maar dit vereist dat het NIDS de configuratie kan wijzigen van netwerkelementen als routers of firewalls, indien adreslijsten in de routers moet worden aangepast. In geval van bijvoorbeeld een hardware crash zal het netwerkverkeer niet beïnvloedt worden; in tegenstelling tot mogelijkheid 1. Onvoldoende prestatie van de NIDS leidt tot minder goede detectie en niet tot vermindering van netwerkcapaciteit. Intrusion Detection Systems versie maart /26

15 4 AANDACHTSPUNTEN BIJ TOEPASSING VAN IDS Zoals in de voorgaande hoofdstukken is beschreven, speelt een samenspel van factoren een rol bij de introductie van een IDS. Dit hoofdstuk gaat in op een aantal van deze factoren om zo vaak gemaakte fouten te kunnen voorkomen. 4.1 Kosten Bij de introductie van een IDS is er een aantal andere kosten waar rekening mee gehouden moet worden. Deze omvatten in ieder geval: 1) Aanschafkosten 2) initiële installatie/configuratiekosten; 3) operationele kosten. Ad 1) In deze eerste categorie vallen de kosten van het IDS zelf. Deze kosten kunnen in de vorm zijn van licentiekosten van een softwarepakket welke de rol van IDS vervuld. Naast deze softwarepakketten is het ook mogelijk dat het IDS wordt geleverd in de vorm van een appliance, waarbij de software op speciale hardware wordt geleverd. Deze hardware is veelal geoptimaliseerd voor maximaal rendement en voldoet aan de minimale systeemeisen van de software. De aanschafkosten zijn sterk afhankelijk van de fabrikant van het pakket, configuratie van de hardware en mogelijke onderhoudscontracten afgesloten met fabrikant/leverancier. Naast commerciële software pakketen zijn er ook een aantal software pakketen waaraan geen licentiekosten zijn verbonden zoals Snort. Snort Open Source IDS Al geruime tijd vormt Snort een de facto standaard voor netwerk IDS. Het systeem, ontwikkeld als open source product door Martin Roesch en Sourcefire, is beschikbaar voor Linux en Windows platforms en wordt breed ingezet voor monitoring van IPnetwerken. Bij nieuwe typen aanvallen worden door de open source community ( en Sourcefire nieuwe signatures ontwikkeld. De Snort signatures vormen een de-facto standaard die ook door andere producten gebruikt worden. Ad 2) De inzet van een IDS kan niet worden gezien als het toevoegen van een extra server in de infrastructuur. Mogelijk dat er wijzigingen in de infrastructuur/configuratie noodzakelijk zijn voor een correcte werking van het IDS. Denk hierbij bijvoorbeeld aan configuratie monitoring poort in een switched netwerk en/of koppeling naar beheeromgeving. Naast deze noodzakelijke aanpassingen in de infrastructuur kan ook de configuratie van het IDS een tijdrovende activiteit worden. Dit hangt samen met het doel van het IDS. Naast deze configuratie zal het IDS ook correct, volgens het beleid betreffende het IDS, moeten worden geconfigureerd voor onder andere een juiste reactie bij detectie van onregelmatigheden. Dit tunen is uiterst belangrijk. Ad 3) De kosten in deze categorie zijn onder andere de kosten voor eventuele updates van signatures en software, indien deze niet onder de onderhoudscontracten vallen. Naast deze directe kosten zijn er nog andere kosten welke worden gemaakt tijdens het operationeel zijn van het IDS zoals de kosten voor monitoren van het IDS (mogelijk 24/7); opleiden van personeel welke de Intrusion Detection Systems versie maart /26

16 gegevens van het IDS juist kunnen interpreteren. Daarbij komen ook nog de overige beheerkosten voor de systemen waaruit de IDS is opgebouwd. Al de bovenstaande aspecten maken de inzet van een IDS kostbaarder dan alleen de aanschafkosten van het product met mogelijk extra hardware. Al deze aspecten samen bepalen de totale kosten van het systeem, vaak worden deze kosten sterk onderschat! De kosten kunnen ook worden samengenomen door de uitbesteding van de monitoring en respons aan een bedrijf dat gespecialiseerd is in managed security services. Aanschaf- en operationele kosten worden in het uitbestedingscontract opgenomen, er moet nog wel rekening gehouden worden met de kosten van transitie. Deze transitie kosten zijn de kosten die gemaakt moeten worden om van een experimenteer opstelling naar een operationeel systeem over te gaan. 4.2 Tuning en updates Onafhankelijk van de gebruikte methode, signatures of anomaly detectie, dient het IDS wel zo geconfigureerd te worden dat deze daadwerkelijk onregelmatigheden detecteert en niet te veel valse alarms afgeeft. De meeste op signatures gebaseerde IDS-en, beschikken over een breed scala aan mogelijke intrusions welke niet alle van toepassing zijn op de infrastructuur waar deze wordt ingezet. Als voorbeeld kan een infrastructuur zijn opgebouwd uit alleen maar systemen met een windows besturingssysteem. De signatures welke betrekking hebben op andere besturingssystemen zullen voor deze organisatie minder relevant zijn. Daarnaast kunnen deze signatures false positives (zie volgende paragraaf) opleveren. Het is dan ook zaak om deze signatures een lage prioriteit te geven of uit te schakelen. Naast deze tuning waarbij onderscheid wordt gemaakt in relevante en minder relevante patronen zal het IDS ook moeten worden aangepast als er veranderingen in de infrastructuur plaatsvinden. In bovenstaand voorbeeld, als er in verloop van tijd alsnog andere besturingssystemen worden geïntroduceerd worden de bijbehorende signatures weer relevant. Hierbij geldt dan dat het tuning een proces is waarbij het IDS continue moet worden geëvalueerd en waarnodig bijgesteld. Een handig tool bij het tunen van een IDS is Snot. Dit programma kun je configureren met de regels van je IDS, waarna het patronen gaat genereren die de IDS dan weer kan detecteren. Afgezien van het toekennen van verschillende prioriteiten aan de beschikbare signatures, komen in de loop van de tijd ook nieuwe signatures beschikbaar. Over het algemeen zal de beschikbaarheid van nieuwe signatures achter lopen op het optreden van onregelmatigheden. Het is belangrijk voor de doeltreffendheid van de IDS om een zo volledig mogelijk beeld te houden over de onregelmatigheden welke optreden, al is het dan niet altijd 100%. Zorg daarom dat het IDS is up-todate is met de meest recente signatures. 4.3 Betrouwbaarheid output Een algemeen probleem van detectieve maatregelen is dat de alertheid voor respons afneemt met het aantal valse alarmen, dat gegenereerd wordt. Daarom is het cruciaal te bepalen in hoeverre de informatie die het IDS geeft juist is. Intrusion Detection Systems versie maart /26

17 In het geval van een onjuiste configuratie, tuning of het niet up-to-date zijn van de laatste aanvalssignatures kan een onjuist beeld ontstaan van de onregelmatigheden welke optreden. Er zijn twee soorten foutieve resultaten, namelijk false positive en false negative. In het geval van een false positive wordt een melding gemaakt van een onregelmatigheid daar waar geen onregelmatigheid is opgetreden. Een ongewenst effect van het herhaaldelijk optreden van een false positive is dat in de toekomst het vertrouwen in meldingen afneemt. Bovendien bestaat de mogelijkheid dat echte meldingen niet meer worden gezien door de hoeveelheid van de foutieve meldingen. Een derde nadeel van false positives is de onnodige effort en/of kosten die gemaakt worden bij een respons. In het geval van false negative wordt er geen melding gegeneerd in het geval waar wel een onregelmatigheid optreedt. Dit houdt in dat er een mogelijke aanval wordt uitgevoerd waarbij er in het IDS geen melding van wordt gemaakt, waardoor hierop geen (re)actie wordt gegeven. 4.4 Uitvoeren van monitoring taken Het geven van meldingen door het IDS op zichzelf is niet voldoende. Ze krijgen pas waarde als ze worden geïnterpreteerd en er mogelijk actie wordt ondernomen. Afhankelijk van het doel en de acceptabele response tijden, kan dit leiden tot een continue monitoring/beschikbaarheid, 24x7, aangezien onregelmatigheden niet aan kantoortijden gebonden zijn. Een alternatief is alarmering van de beheerder buiten kantoortijden via pager of SMS, waarna actie kan worden ondernomen. Dit aspect zal zijn weerslag hebben op de operationele kosten van de inzet van het IDS. De meldingen die worden gegenereerd verschillen in detail, zowel per type melding als ook per IDS product. In de meeste gevallen wordt een overzicht gegeven met een generieke aanval benaming, waarbij veel naar de bekende kwetsbaarhedendatabases wordt verwezen, zoals CVE. Vaak is het mogelijk om via een gebruikersinterface aanvullende informatie op te vragen. In enkele gevallen is er ook informatie beschikbaar over de pakketten die geleid hebben tot het genereren van een melding. Voor een juiste interpretatie van meldingen en het selecteren van een juiste (re)actie dient de beheerder van het IDS te beschikken over een gedegen kennis. Deze kennis is niet alleen beperkt tot het kunnen vertalen van deze generieke aanvalsbenaming naar meer detail. De beheerder moet in staat zijn een vertaling te maken wat dit voor de infrastructuur betekent. Dit houdt in dat de beheerder tenminste kennis moet hebben van omgang met de IDS omgeving en algemene infrastructuur kennis. Bovendien moet de beheerder kennis hebben over de mogelijke onregelmatigheden die kunnen optreden. Zo zal een beheerder bijvoorbeeld een smurf aanval moeten kunnen interpreteren. Na de interpretatie van een melding zal besloten moeten worden welke vervolgstappen genomen worden. Deze zijn afhankelijk van de ernst en aard van de melding en kan uiteindelijk bestaan uit escalatie naar de informatiebeveiligingsverantwoordelijke of GOVCERT.NL Voor een beheerder dient het duidelijk te zijn welke vervolgstappen mogelijk zijn en in welk geval welke keuze gemaakt dient te worden. Hieraan ligt een heldere incidentmanagement procedure ten grondslag. Hierin is een duidelijk escalatiepad Intrusion Detection Systems versie maart /26

18 noodzakelijk. Het moet dus ook duidelijk zijn wie welke verantwoordelijkheid en welke bevoegdheid heeft. In het ergste geval zal de gehele infrastructuur moeten wordt afgesloten om escalatie van problemen te voorkomen. 4.5 Interpretatie van IDS output Een van de belangrijkste onderdelen van het effectief toepassen van een IDS is de manier waarop de IDS-output wordt verwerkt. Voorbeelden van het verwerken van IDS-output zijn: Bepalen of een melding van een aanval correct is; Bepalen of een aanval succesvol is geweest; Bepalen of meerdere meldingen kunnen worden gecorreleerd tot 1 aanval; Bepalen of er nieuwe soorten aanvallen zijn uitgevoerd; Verzamelen van meer informatie over een aanval (bijvoorbeeld locatie aanvaller). Dit kan natuurlijk volledig handmatig gedaan worden, maar dat wordt onpraktisch wanneer het IDS veel data genereert. Er zijn wel oplossingen die de IDS-output automatisch kunnen correleren en verwerken tot een rapportage maar deze bevinden zich nog grotendeels in de ontwikkelfase. Er is ook software die de output van meerdere IDS-en en eventueel ook andere bronnen zoals firewalls, virusscanners, honeypots, nessus-scans etc. Deze software is zodanig geconfigureerd dat het de input kan correleren en combineren tot een enkele presentatie. Voorbeelden zijn Prelude, Sims, OSSIM, OpenSims, OSSEC. Deze pakketten zijn over het algemeen lastig te configureren. Om de correcte interpretatie van IDS-output te controleren, zowel door het IDS, de IDS-output processor en de beheerders, is het mogelijk om periodiek penetratietesten uit te voeren om te bepalen of a) de IDS werkt en b) de beheerders hier correct op reageren. Indien dit laatste een van de doelstellingen is van een penetratietest is het nodig dat de beheerders niet op de hoogte zijn van deze penetratietest. Feitelijk is een IDS nutteloos als er geen kundige beheerders zijn die de IDSoutput correct weet te interpreteren. De beheerders moeten daarom technisch onderlegd zijn, en weten welke handelingen wanneer uitgevoerd moeten worden. Op basis van kennis en ervaring van de beheerders moeten beslissingen genomen worden, zoals: Blokkeren van netwerktoegang voor een IP adres Het melden van misbruik aan de leiding gevende van een gebruiker die de IDS melding veroorzaakt Abus sturen naar ISP van aanvaller Escaleren naar de security officer Intrusion Detection Systems versie maart /26

19 Figuur 4-1 Voorbeeld van een IDS-monitor (SAM in combinatie met Snort) 4.6 Correlatie tussen meldingen Naast de vervolgstappen op meldingen van het IDS is het mogelijk om de meldingen te gebruiken voor de identificatie van relaties tussen verschillende meldingen van verschillende systemen en/of sensoren. Correlatie van meldingen kan worden gebruikt voor het verminderen van foutieve meldingen, zowel false positives als false negatives. Zo kan bijvoorbeeld aan de hand van een tweede melding worden gecontroleerd of de eerste melding valide is (alarmverificatie). Tevens is het mogelijk door de combinatie van twee meldingen meer informatie in te winnen over de onregelmatigheid. Een voorbeeld is dat detectie van een netwerkscan gevolgd door een portscan van eenzelfde bron geeft inzicht over de mogelijke voortgang van een aanval. In de meest eenvoudige vorm worden meerdere sensoren van hetzelfde IDS geplaatst in de infrastructuur. Deze sensoren genereren meldingen welke centraal worden geanalyseerd en gecorreleerd. In dit geval wordt er gebruik gemaakt van een leverancier welke meerdere sensoren plaatst. Het formaat en syntaxis van meldingen kan door de leverancier gekozen worden, en zolang het centrale analyse en correlatie onderdeel deze syntaxis kan interpreteren kan correlatie plaatsvinden. In een tweede opzet worden sensoren van verschillende leveranciers gecombineerd. In dit geval zal het niet altijd mogelijk zijn om deze meldingen (automatisch) aan elkaar te relateren doordat de syntaxis van de meldingen van beide leveranciers afwijken en geen van beide de syntaxis van de ander kan interpreteren. Er zijn ontwikkelingen voor een generieke syntaxis welke dit Intrusion Detection Systems versie maart /26

20 probleem zal kunnen overbruggen. Een voorbeeld hiervan is het Intrusion Detection Message Exchange Format (IDMEF). Dit vereist veelal een aanpassing van de software van de verschillende leveranciers, of het inzetten van een middleware oplossing. Naast het koppelen van meldingen van IDS-en kan een meer generieke aanpak gekozen worden door gebruik te maken van informatie die beschikbaar is in de infrastructuur. Bestaande systemen beschikken veelal over de mogelijkheid om activiteiten op te slaan en te rapporteren. Deze informatie kan gebruikt worden voor optimalisatie van het detecteren van onregelmatigheden. Een voorbeeld is de syslog informatie beschikbaar op routers of de log-informatie gegenereerd en opgeslagen op firewalls. Ook hier gelden dan de beperkingen van formaat en syntaxis van de verschillende systemen. De relaties tussen verschillende meldingen kan vergeleken worden met bekende aanvalspatronen. Dit houdt in dat er vooraf kennis moet zijn over de mogelijk verschillende relaties tussen meldingen en dat deze moeten worden geconfigureerd in het IDS systeem. Uiteindelijk komt het erop neer dat de kennis met betrekking tot relaties, van de beheerder wordt verschoven naar een automatische analyse. Deze automatische analyse komt van pas daar waar veel meldingen worden gegenereerd en waar het handmatig niet meer overzien kan worden. Dit kan ook komen door relaties tussen meldingen welke over een lange tijdsperiode optreden. Het invoeren van deze kennis in een correlatieproces moet niet worden gezien als vervanging van de eigen kennis met betrekking tot aanvalspatronen en kennis over de infrastructuur. Deze eigen kennis is nog steeds essentieel in het gehele proces, omdat dit de ernst van aanvallen helpt inschatten of recente wijzigingen in de infrastructuur inbrengt. Voor IDS-en bestaat de mogelijkheid deze nauw samen te laten werken met bijvoorbeeld kwetsbaarheidscanners zoals Nessus. De resultaten van een kwetsbaarheidscanner kan invloed hebben op het bepalen van prioriteiten van aanvalspatronen. Kwetsbaarheidscanners beschikken over de mogelijkheid om te bepalen welke services op een systeem aangeboden worden. Daarnaast zijn ze ook vaak in staat te achterhalen welk besturingssysteem op de verschillende componenten gebruikt wordt. Deze informatie kan worden gebruik bij het configureren en afstellen van het IDS. 4.7 Versleuteling van dataverkeer IDS-en die gebruik maken van signatures moeten toegang hebben tot onversleutelde gegevens om het dataverkeer te kunnen beoordelen op eventuele problemen. Het gebruik van versleuteld dataverkeer, zoals bijvoorbeeld het geval is bij https of ander SSL verkeer, kan er voor zorgen dat het IDS niet kan bepalen of er sprake is van een aanval, immers het IDS kan de versleutelde data niet interpreteren. Deze beperking betreft voornamelijk netwerk IDS-en, aangezien Host IDS-en over het algemeen wel toegang hebben tot de onversleutelde data omdat deze meestal geïntegreerd zijn in het operating systeem. Een mogelijkheid is dat het IDS wordt uitgerust met de sleutels die voor de versleuteling worden gebruikt. Al roept dit allerlei nieuwe vragen op ten aanzien van het werken met sleutelmateriaal. Intrusion Detection Systems versie maart /26