organisatie voor twee?

THEMA INFORMATIEBEVEILIGING: CYBERCRIME Steeds meer beveiligingsincidenten steken de kop op Mr. W.H.M. Hafkamp, programmamanager Informatiebeveiliging Rabobank Groep te Utrecht (w.h.m.hafkamp@rn.rabobank.nl) Telt een gewaarschuwde organisatie voor twee? 19 Informatiebeveiligingsincidenten zijn in de Westerse samenleving een serieus probleem aan het worden. Niet voor niets besteden overheid, het bedrijfsleven en de academische wereld veel aandacht aan het voorkomen en het bestrijden ervan. In dit artikel doet de auteur een voorlopig verslag van een promotieonderzoek naar dit fenomeen. WIM HAFKAMP

20 Meer blauw in cyberspace, zo luidt een van de aanbevelingen uit een onderzoek uitgevoerd door het onderzoeks- en adviesbureau DSP groep en TNO/FEL in opdracht van het door de minister van Binnenlandse Zaken geïnitieerde Programma Politie en Wetenschap. Het onderzoek schetst een beeld van de omvang en ontwikkeling van cybercrime in Nederland en geeft aanbevelingen voor de bestrijding ervan. Binnen de Nederlandse politieorganisatie is inmiddels een plan ontwikkeld tot de oprichting van een zogenoemd Hacking Emergency Response Team (HERT), dat een centrale rol moet gaan spelen bij de opsporing, bestrijding en voorkoming van (opzettelijke) elektronische aanvallen op kritieke infrastructuren in Nederland (zie hiervoor het Inrichtingsplan voor Hacking Emergency Response Team mei 2002, van het Landelijk projectbureau Digitaal Rechercheren). De nadruk zal hierbij worden gelegd op opsporing van daders. Veel organisaties zijn kwetsbaar voor cybercrime Cybercrime Het rechercherapport Cybercrime van het Korps Landelijke Politiediensten onderscheidt twee verschijningsvormen van cybercrime. De eerste vorm is die waarbij de computer als middel wordt gebruikt bij de uitvoering van strafbare of strafwaardige gedragingen, zoals (virtuele) kinderpornografie en witwassen. De tweede verschijningsvorm is die waarbij de computer ook het doel is van de strafbare of strafwaardige gedragingen: cybercrime in enge zin, zoals (distributed) denialof-service-aanvallen en computervredebreuk (hacking). Expertise-bundeling De razendsnelle opkomst en verspreiding van bedreigingen voor gegevensverwerkende ICT-componenten heeft in de afgelopen jaren geleid tot een forse toename van technische maatregelen. Naast de implementatie van antivirussoftware en firewall-systemen beschikt een aantal ondernemingen inmiddels over een Intrusion Detection System, waarmee afwijkende netwerkpatronen real-time kunnen worden gedetecteerd en gemeld. Ook in organisatorische zin is er het nodige gebeurd, waaronder de inrichting van zogeheten Computer Emergency Response Teams (CERT s). Doel van dergelijke teams is het bundelen van vooral technische expertise om de ICT-beheerder of gebruiker te ondersteunen bij het verhelpen van een informatiebeveiligingsincident. De term Computer Emergency Response Teams CERT (soms ook aangeduid als Computer Security Incident Response Teams CSIRT), is in 1988 ontstaan nadat een zogenoemd wormprogramma een explosie van kopieën van zichzelf verspreidde naar andere op internet aangesloten computers. Het programma veroorzaakte een computer shutdown van ongeveer tien procent van alle, wereldwijd, op internet aangesloten computers. Dit eerste majeure computerbeveiligingsincident leidde in Amerika tot de oprichting van het CERT (Coordination Center) (CERT/CC; www.cert.org) door het Defense Advanced Research Projects Agency (Darpa). Al snel volgden andere landen het voorbeeld. In Nederland werd als eerste CERT-NL (cert-nl.surfnet.nl) als overkoepelend Incident Response Team voor SURFnet en de daarop aangesloten netwerken (hoofdzakelijk hoger onderwijs en onderzoekswereld) opgericht. figuur 1 Most Agressive Attack Sources By IP-Address

Trends in beveiligingsincidenten Als gevolg van de naweeën van grote wereldwijde computervirusincidenten en beschikbaarheidsaanvallen op webservers blijkt dat veel organisaties die actief zijn op internet ondanks forse informatiebeveiligingsmaatregelen kwetsbaar zijn voor cybercrime, zoals (distributed) denial-of-service-aanvallen en computervredebreuk (hacking). Het Amerikaanse CERT( Coordination Center (CERT/CC; zie www.cert.org) geeft een aantal trends met betrekking tot informatiebeveiligingsincidenten: Trend 1: Automatisering; snelheid van aanvalsmiddelen Het niveau van automatisering in aanvalsmiddelen neemt verder toe. Geautomatiseerde aanvallen kennen over het algemeen vier fasen: 1. Scannen op potentiële slachtoffers; 2. Compromitteren van kwetsbare systemen; 3. Propageren van de aanval; 4. Gecoördineerd beheer van aanvalshulpmiddelen ten behoeve van denial-of-service-aanvallen, scanning en compromitteren van kwetsbare systemen (de zogeheten hybride aanvallen). Trend 2: Toenemende complexiteit van aanvalsmiddelen Signatures van aanvalsmiddelen zijn moeilijker te analyseren en te detecteren (door bijvoorbeeld antivirusprogrammatuur). Drie karakteristieken voor deze trend zijn: het anti-forensische karakter, het dynamische gedrag en de modulariteit van de aanvalsmiddelen. Dit alles leidt ertoe dat het steeds moeilijker wordt om aanvallen te onderscheiden van legitiem netwerkverkeer. Trend 3: Snellere ontdekking van kwetsbaarheden Het aantal nieuw ontdekte kwetsbaarheden gerapporteerd aan het CERT Coordination Center verdubbelt ieder jaar. Het is voor beheerders een moeilijk taak om bij te blijven met patches. Bovendien worden ieder jaar nieuwe klassen kwetsbaarheden ontdekt. Reviews van bestaande softwarecodes leiden soms tot de ontdekking van deze nieuwe kwetsbaarheden in honderden verschillende softwareproducten. Indringers zijn vaak in staat om deze exemplaren sneller te ontdekken dan dat leveranciers in staat zijn ze te corrigeren. Vanwege deze trend tot geautomatiseerde ontdekking van nieuwe kwetsbaarheden wordt de zogeheten time to patch steeds kleiner. Na de commotie rond het I-Love-you-virus en distributed denial-of-service-aanvallen op gerenommeerde Amerikaanse websites aan het eind van de jaren negentig heeft een aantal nationale overheden besloten tot oprichting van een nationaal meldpunt- en coördinatiepunt voor computer security-incidenten. Ook de Nederlandse rijksoverheid heeft initiatieven genomen op het terrein van Computer Emergency Response. Op 5 juni 2002 is door voormalig minister Van Boxtel de CERT van de rijksoverheid (www.govcert.nl) geïnstalleerd. Deze onder de vlag van het ICT Uitvoeringsorgaan Rijksoverheid (ICTU) operationele afdeling verleent assistentie bij (grootschalige) beveiligingsincidenten binnen een van de aangesloten departementen en geeft uit oogpunt van preventie zogeheten security advisories uit. Onlangs is het ministerie van Economische Zaken een gratis informatiedienst gestart om het MKB en de particuliere internetgebruikers te informeren over nieuw ontdekte virussen en beveiligingslekken. Aantal nieuw ontdekte kwetsbaarheden verdubbelt ieder jaar Een aantal ministeries participeert daarnaast samen met een aantal marktpartijen actief in het programma Kwint van het Electronic Commerce Platform Nederland (www.ecp.nl). Het met overheidsgeld gesubsidieerde programma is voortgekomen uit het Stratix/TNO-onderzoeksrapport over de kwetsbaarheid van internet en de daaropvolgende behandeling van de kabinetsnota rondom het thema Kwetsbaarheid Internet in de zomer van 2001. Standaardiseren Een min of meer geslaagde poging om beleid, taken en inrichting van incident response teams te standaardiseren, is de introductie van IETF rfc 2350 (Request for Comments van de Internet Engineering TascForce (= Internet standaardisatie gremium), getiteld Expectations for Computer Security Incident Response in 1998. De rfc spreekt niet meer van Computer Emergency Response Teams, een tot die tijd gangbare benaming, maar van Computer Security Incident Response Teams (CSIRT). Dit heeft vermoedelijk te maken met het feit dat de term Computer Emergency Response Team door het CERT (Coordination Center) is gepatenteerd. Volgens de rfc dient iedere CSIRT een duidelijk beleid kenbaar te maken met betrekking tot het type incidenten dat in behandeling wordt genomen en het niveau van ondersteuning hierbij. Om de vertrouwelijkheid van de melder te garanderen, dient de CSIRT naast een heldere disclosure-policy een betrouwbaar en veilig communicatiekanaal ter beschikking te stellen. In de rfc wordt aanbevolen gebruik te maken van gangbare mechanismen zoals e-mail-berichtenbeveiliging met s/mime of pgp. Incident response De diensten van een CSIRT worden in de rfc gesplitst in twee hoofdgroepen. De ene groep bestaat uit real-time-activiteiten direct gerelateerd aan de hoofdtaak incident response. De tweede groep bestaat uit non-real-time pro-actieve activiteiten, ondersteunend aan de hiervoor genoemde taak. Incident response wordt binnen de rfc uitgewerkt in Incident Triage, Incident Coordination en Incident Resolution. Incident Triage is het interpreteren van binnenkomende incidenten, het prioriteren van de incidenten en het relateren aan ongoing incidents & trends. Een belangrijk aspect hierbij is het vaststellen of een incident werkelijk heeft plaatsgevonden en na bevestiging hiervan het bepalen van de omvang. Incident Coordination omvat het categoriseren van de aan het incident gerelateerde informatie met betrekking tot de disclosure policy. Denk hierbij 21

aan logfiles, contactinformatie, et cetera. In dit stadium worden ook andere betrokken partijen geïnformeerd. Dit alles uiteraard onder de uitgangspunten en voorwaarden van de eerder genoemde policy. De rfc geeft bij Incident Resolution drie gangbare diensten: technische assistentie (inclusief analyse van het gecompromitteerde systeem), eradication (ontworteling) en herstel. Onder eradication wordt het elimineren van de oorzaak van het incident en zijn effect verstaan. Veelal gebeurt dit door het installeren van herstelsoftware of het wijzigen van instellingen om de kwetsbaarheid weg te nemen. De andere CSIRT-hoofdtaak wordt samengevat onder de noemer pro-actieve activiteiten. Er worden vijf voorbeelden genoemd: informatievoorziening over bekende kwetsbaarheden en tegenmaatregelen (onder andere historie-databases), hulpmiddelen voor auditing, scholing en training, productevaluatie en auditing & advies. De jongste ITIL-loot is Security die in het midden van de piramide in figuur 4 wordt gepositioneerd. Hoofddoel van ITIL Security is enerzijds het realiseren van de service level agreements-eisen ten aanzien van informatiebeveiliging en anderzijds het realiseren van een zeker basis beveiligingsniveau. Het proces Security Management heeft raakvlakken met vrijwel alle hierboven genoemde ITIL-processen. figuur 4 De drie niveaus met voor ITIL Security Management relevante processen Strategisch Managers Set 22 Incident response en ITIL Binnen Europa hebben veel organisaties hun ICT-beheerprocessen ingericht volgens de ITIL-methodologie. Information Technology Infrastructure Library (ITIL) is een door de Britse Central Computer and Telecommunications Agency/Office of Government Commerce (CCTA/OGC) uitgegeven, gestructureerde set van modules met best practices op het gebied van ICT beheer; ITIL wordt binnen een groot aantal Europese landen beschouwd als dé de facto-standaard voor het beheer van ICT-processen binnen organisaties. ITIL gaat uit van een procesmatige benadering van ICT-beheer. Dit komt met name tot uitdrukking in het cyclische karakter: plannen, implementeren, evalueren en onderhoud. De Service Support Set en de Service Delivery Set zijn de belangrijkste verzameling van processen in ITIL. Service Delivery beschrijft de diverse diensten die de business van de klant nodig heeft en wat er nodig is om deze diensten te kunnen leveren. De Service Delivery Set maakt onder andere onderscheid in de volgende processen (zie figuur 2): Operationeel Tactisch Performance & capacity Incident IT services organization Service level Configuration & asset Security Problem Availability Service Delivery Set Business continuity planning Release Change Service Support Set figuur 2 Service Delivery Set Service level Availability IT Services continuity Performance and capacity Vastleggen en nakomen van afspraken Beschikbaarheid van ICT-componenten Continuïteitsbeheer van de IT-dienstverlening Optimale inzet van ICT-hulpmiddelen Het ITIL-boek over Service Support beschrijft, de naam zegt het ten dele, hoe de klant toegang krijgt tot de diverse IT-dienstverleners om zijn business te ondersteunen. De Service Support Set richt zich vooral op het beheer van de ICT-middelen zelf (zie figuur 3): figuur 3 Service Support Set Configuration & asset Incident / Helpdesk Problem Change Release Samenstelling van de ICT-infrastructuur Registratie en bewaking van alle gemelde incidenten Beheren van problemen Beheren en beheersen van wijzigingen Implementatie van software en versiebeheer

De ITIL-modules geven redelijk gedetailleerd weer wat een organisatie allemaal moet regelen om haar beheer te laten verlopen conform het ITIL-proces. Hoe dit kan worden gerealiseerd (met welke middelen) wordt niet voorgeschreven. Een Computer Emergency Response Team werkzaam binnen een op ITIL gebaseerde ICT-organisatie heeft voornamelijk te maken met processen uit de ITIL Service Support Set en met IT Service Continuity. Zo is er een relatie met Configuration and asset waar alle ICT Configuration Items (CI s), zijnde software, hardware, processen, procedures en documentatie worden vastgelegd in een Configuration Management Database. Een (dreigend) securityincident heeft immers betrekking op één of meerdere CI s. Uiteraard is er een directe link met incident en problem waar alle incidenten, inclusief de securityincidenten, worden geregistreerd en bewaakt. Ook is er een nauwe relatie met change en/of release. Security advisories van een CERT betekenen veelal de installatie van een patch of het aanbrengen van nieuw softwarerelease, handelingen die volgens het van toepassing zijnde ITILproces dienen te worden uitgevoerd. Een calamiteit wordt binnen IT Service Continuity omschreven als een gebeurtenis die een service of systeem zodanig verstoort dat veelal aanzienlijke maatregelen moeten worden genomen om het originele verwerkingsniveau te herstellen. Een calamiteit wordt als ernstiger getypeerd dan een incident. Voorbeelden van calamiteiten zijn brand, blikseminslag, inbraak en grootschalige stroomstoringen. Ook beschikbaarheidsaanvallen via internet, de denial-of-service attacks, die de communicatie van een bedrijf verlammen, worden genoemd in de reeks van voorbeelden van calamiteiten. Onderzoek In december 2001 is gestart met een promotieonderzoek naar het fenomeen Computer Emergency Response Teams. De promotoren, prof. ir. E. Michiels en prof. dr. E. Roos Lindgreen, zijn verbonden aan respectievelijk Universiteit Twente en Universiteit van Amsterdam. Het onderzoek heeft als hoofddoel het verkrijgen van (meer) inzicht in de werking van incident response- en alarmeringsmechanismen op het gebied van ICT-security en de invloed hiervan op de binnen ITIL gedefinieerde ICT-beheerprocessen. In het kader van deze publicatie hanteert de auteur twee stellingen. Stelling 1: Een calamiteit wordt als ernstiger getypeerd dan een incident Hoe meer de organisatie is ge-itil-iseerd, des te groter is de kans op langere aanwezigheid van aan internet gerelateerde beveiligingskwetsbaarheden. Een belangrijk uitgangspunt binnen ITIL is standaardisatie. De diverse processen Service Support en Service Delivery worden uitgewerkt in zogeheten standaardprocesstappen. Een voorbeeld is het hiervoor genoemde stappenproces binnen change. Standaardisatie werkt in zijn algemeenheid efficiëntie en effectiviteit verhogend. Standaardisatie bevordert in het algemeen efficiëntie en effectiviteit Er zijn echter ook nadelen. Standaardisatie kan verlammend werken op de creativiteit. Incident response vraagt soms om onorthodoxe methoden. Stelt u zich eens voor: het Intrusion Detection System (IDS) heeft een indringer gesignaleerd op uw netwerk. Het CERT wordt gewaarschuwd. Ter afleiding en om de identiteit van de indringer(s) te achterhalen, adviseert het CERT om tijdelijk een honingpot, een leeg systeem met aansprekende naam als lokaas, te activeren. De ITIL-processen change en configuration and asset staan een op zichzelf creatief voorstel van het CERT binnen een kort tijdsbestek echter niet toe. Er moet immers eerst een CI worden aangemaakt. Conform het beveiligingsbeleid wordt de CI geclassificeerd, alwaar het eerste probleem opduikt: welke business-processen ondersteunt de CI. Na het nemen van deze hobbel wordt vervolgens een request-for-change (rfc) aangemaakt om de uitbreiding van netwerkconfiguratie met het CI mogelijk te maken, de rfc wordt door het Change Advisory Board beoordeeld, et cetera et cetera. Een ander nadeel van standaardisatie is het aspect tijd. De bij standaardisatie behorende (proces)stappen volgen altijd een vast stramien. Ook hier weer het voorbeeld van change. De doorlooptijd van het initiëren van het wijzigingsvoorstel, de rfc, tot en met de uiteindelijk geaccepteerde en werkzame implementatie kan oplopen tot tien werkdagen. Het kwaad van een nieuw virus, een nieuwe inbraak of beschikbaarheidsaanval is dan al lang geschied. De maximale time-to-change laat zich wat dit aangaat niet uitdrukken in dagen, maar eerder in uren! Stelling 2: Informatie van Computer Emergency Response Teams levert in de toekomst weinig toegevoegde waarde. Computer Emergency Response Teams ontlenen hun bestaansrecht aan het feit dat zij in een vroeg stadium geïnformeerd worden over nieuwe ontwikkelingen op het terrein van beveiligingincidenten. Minder (snelle) meldingen zullen leiden tot minder kennis bij CERT s, waardoor de toegevoegde waarde van CERT s minder evident wordt. Strengere wetgeving (Europese Commissie, voorstel voor een Kaderbesluit van de Raad over aanvallen op informatiesystemen, COM (2002) 173 definitief, Brussel 19 april 2002) op 23

het gebied van computercriminaliteit zal de klokkenluider uit de hackers-gemeenschap voorzichtiger maken. Hij loopt immers het risico zelf betrokken te raken bij justitiële vervolging. Ook leveranciers van soft- of hardware worden voorzichtiger bij het melden van onvolkomenheden in hun producten uit angst voor de effecten van bekendmaking (negatieve publiciteit). Openbaarheid is pas aan de orde wanneer er een patch beschikbaar is voor het probleem. ook een pro-actief security change -beleid te voeren. Herstelsoftware in de vorm van security patches wordt nog te vaak opgespaard totdat de leverancier een volgend softwarerelease op de markt brengt. Of wordt pas aangebracht indien de kwetsbaarheid voor veel (negatieve) publiciteit heeft gezorgd. Hierdoor blijven organisaties langer kwetsbaar dan noodzakelijk. Het adagium een gewaarschuwde organisatie telt voor twee, gaat in deze situaties zeker niet op! 24 Strengere wetgeving maakt de klokkenluider uit hackers-gemeenschap voorzichtiger Onder het motto full disclosure helpt vooral de kwaadwillenden, heeft Microsoft in november 2001 een initiatief genomen tot regulering van verspreiding van gegevens over softwarefouten. Een aantal ICT-beveiligingsbedrijven heeft zich aan het eind van een driedaags forum bij dit initiatief aangesloten. Ook in IETF-verband is het onderwerp zeer actueel. Een in februari 2002 bij de IETF vrijgegeven Internet-Draft getiteld Responsible Vulnerability Disclosure Process (in februari 2002 door Steve Christey en Chris Wysopal geplaatste Internet-Draft, textfile draft-christey-wysopal-vuln-disclosure-oo.txt op www.ietf.org binnen de categorie Best Current Practice ), heeft binnen de security en hackers community tot veel commotie geleid. Een verdere behandeling van de discussie rondom full or partial disclosure zou binnen de context van dit artikel te ver voeren. Wel is duidelijk dat Microsoft hiermee voor zichzelf een trend heeft gezet: teveel openheid over de eigen tekortkomingen is niet meer aan de orde. De nadelen van beperkte openheid (partial disclosure) zijn evident: informatieachterstand bij zowel Computer Emergency Response Teams als bij eindgebruikers, wat ongetwijfeld zal leiden tot minder snelle opbouw van security-expertise binnen de teams en tot minder druk bij de leveranciers om tijdig patches ter beschikking te stellen. Tot slot Het promotieonderzoek is momenteel in volle gang. Uit een eerste casestudy bij een aantal Nederlandse bedrijven blijkt dat ICT-afdelingen vaak van diverse externe bronnen informatie, gratis en betaald, ontvangen met waarschuwingen over nieuw ontdekte virussen, zwakke plekken in ICT-infrastructuurcomponenten en aanvalstechnieken. Analyse van deze externe informatie blijkt arbeidsintensief en tijdrovend te zijn. Het ontbreekt systeembeheerders simpelweg aan tijd om alle meldingen, dagelijks soms tientallen, te lezen en vervolgens van een eventuele opvolgingsactie te voorzien. Het antwoord lijkt te liggen in gefilterde, op maat aangeleverde, relevante informatie door CERT s of andere leveranciers. Informatie waarbij de beheerder bij elk bericht zeker weet dat de informatie belangrijk is, omdat het gaat over hard- of software die hij in beheer heeft én waarin een belangrijke kwetsbaarheid is ontdekt. Het louter ontvangen van berichten is echter onvoldoende. De ICT-organisatie dient Mr. W.H.M. Hafkamp voert momenteel momenteel een promotieonderzoek uit naar de werking van incident response- en alarmeringsmechanismen op het gebied van ICT-security en de invloed hiervan op de binnen ITIL gedefinieerde ICT-beheerprocessen. Het artikel is een bewerkte en geactualiseerde versie van het in december 2002 verschenen artikel Telt een gewaarschuwde organisatie voor twee? in het tijdschrift Management & Informatie. Literatuur 1 P. van Amersfoort, L. Smit, M. Rietvelt, Criminaliteit in de Virtuele Ruimte, publicatie in de reeks Politiekunde van het Programma Politie en Wetenschap, Kerckebosch, Amsterdam, mei 2002. 2 J. Arvidsson, Taxonomy of the Computer Security Incident related terminology - TERENA Incident Taxonomy and Description Working Group, beschikbaar op het World Wide Web via www.terena.nl, juni 2002. 3 CERT(r)/CC, Overview of Attack Trends, beschikbaar op het World Wide Web via www.cert.org, 2002. 4 CCTA - Central Computer and Telecommunications Agency, Cazemier, Overbeek & Peters, Security Management IT Infrastructure Library, The Stationary Office, London, 1999. 5 G. Hillenius, Beperkte veiligheidslekken, Computable, 16 november 2001. 6 Internet Security Systems, Internet Risk Impact Summary for January 1, 2003 through March 31,2003, beschikbaar op het World Wide Web via https://gtoc.iss.net, April 2003. 7 ITSMF Nederland, IT Service Management, een introductie, van Haren publishing, V3.0 januari 2002. 8 M. Koek, Omgevingsverkenning CERT-RO, interne nota van het ICT Uitvoeringsorgaan Rijksoverheid in verband met de oprichting van een CERT voor de Rijksoverheid, februari 2002. 9 A. Mooij, J. van der Werf, Cybercrime, uitgave van het Korps Landelijke Politiediensten Dienst Nationale Recherche Informatie, juli 2002. 10 A. Offerman, Vulnerabilities: publiceren ja of nee?, IDG kwartaalblad infosecurity.nl, tweede kwartaal 2002. 11 P. Overbeek, Beveiliging en Beheer met ITIL Security Management, Informatiebeveiliging Jaarboek 2000/2001, Ten Hagen & Stam, Den Haag 2000. 12 P. Overbeek, E. Roos Lindgreen, M. Spruit, Informatiebeveiliging onder controle, Pearson Education, Amsterdam, 2000. 13 Stratix Consulting Group/TNO-FEL, Samen werken voor veilig Internet verkeer, Eindrapportage van het onderzoeksproject kwetsbaarheid van internet in opdracht van het Ministerie van Verkeer & Waterstaat, Januari 2001. Op pagina 14 e.v. vertelt drs. Ton Louwers RA, director Finance & Control bij Thales Nederland te Hengelo over zijn ervaringen met het werken in een branche die volledig in het teken staat van (informatie)beveiliging. Voor verdere verdieping raadpleegt u de KluwerFinanceBase op internet: www.kluwerfinancieel.nl. C