TELT EEN GEWAARSCHUWDE ORGANISATIE VOOR TWEE?

VOORKOMEN EN BESTRIJDEN Wim Hafkamp 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 bestrijden ervan. De auteur doet een promotieonderzoek naar het fenomeen. In dit artikel doet hij hiervan een voorlopig verslag. TELT EEN GEWAARSCHUWDE ORGANISATIE VOOR TWEE? Meer blauw in cyberspace is een van de aanbevelingen uit een onderzoek [AMSR02] 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. Binnen de Nederlandse politieorganisatie is inmiddels een plan ontwikkeld tot de oprichting van een zogeheten Hacking Emergency Response Team (HERT) 1 dat een centrale rol moet gaan spelen bij de opsporing, bestrijding en voorkoming van (opzettelijke) elektronische aanvallen op kritieke infrastructuren in Nederland. De nadruk zal hierbij worden gelegd op opsporing van daders. Het rechercherapport Cybercrime [MOWE02] 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) denial-ofservice aanvallen en computervredebreuk (hacking). MANAGEMENT & INFORMATIE 2002/6 19

EXPERTISE BUNDELEN 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 anti-virus software op (mail)servers en firewallarchitectu- Trends in beveiligingsincidenten In 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) geeft een aantal trends [CERT02] 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 (= zogeheten hybride aanvallen). Trend 2 Toenemende complexiteit van aanvalsmiddelen Signatures van aanvalsmiddelen zijn moeilijker te analyseren en te detecteren (door bijvoorbeeld antivirus programmatuur). 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 zich 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 softwarecode 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. ren 2 beschikken veel 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 constituency 3 te ondersteunen bij het verhelpen van een informatiebeveiligingsincident. De term Computer Emergency Response Teams (CERT) 4 is in 1988 ontstaan nadat een worm programma een explosie van kopieën van zichzelf verspreidde naar andere op internet aangesloten computers. Het programma resulteerde in een computer shutdown van ongeveer 10 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) 5 door het Defense Advanced Research Projects Agency (Darpa). Al snel volgden andere landen het voorbeeld. In Nederland werd CERT-NL 6 als overkoepelend Incident Response Team voor SURFnet en de daarop aangesloten netwerken (hoofdzakelijk hoger onderwijs en onderzoekswereld) opgericht. Een greep uit landen met actieve nationale teams: Italië (CERT-It), Canada (CanCERT), Australië (AusCERT) en Slovenië (Si-CERT). Het woord nationaal staat tussen aanhalingstekens omdat deze teams niet specifiek door of voor de overheden zijn ingesteld, maar hun land wel als hun constituency zien. De teams zijn samengesteld uit expertteams werkzaam binnen de rekencentra die de academische netwerken beheren. Deze netwerken waren van oudsher via internet aan elkaar gekoppeld. Na de commotie rond het I-Love-you virus en distributed denial-of-service aanvallen op gerenommeerde Amerikaanse websites aan het eind van de vorige eeuw heeft een aantal nationale overheden besloten tot oprichting van een nationaal meldpunt- en coördinatiepunt voor computer security incidenten [KOEK02]. Ook de Nederlandse rijksoverheid heeft recent initiatieven genomen op het terrein van 20 MANAGEMENT & INFORMATIE 2002/6

VOORKOMEN EN BESTRIJDEN Computer Emergency Response. Op 5 juni is officieel door voormalig minister van Boxtel CERT-RO 7 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. De gezamenlijke ministeries participeren daarnaast samen met een aantal marktpartijen actief in het programma Kwint van het Electronic Commerce Platform Nederland. 8 Het met overheidsgeld gesubsidieerde programma is voortgekomen uit het Stratix/TNO onderzoeksrapport over de kwetsbaarheid van internet [STTN01] en de daaropvolgende behandeling van de kabinetsnota rondom het thema Kwetsbaarheid Internet in de zomer van 2001. Het programma Kwint heeft eind 2001 een aantal actielijnen uitgezet waaronder de formering van een nationale werkgroep Alarmering & Incident Response. STANDAARDISEREN Een min of meer geslaagde poging om beleid, taken en inrichting van incident response teams te standaardiseren is de introductie van IETF rfc 9 2350, 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 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 disclosurepolicy een betrouwbaar en veilig communicatiekanaal ter beschikking te stellen. In de rfc wordt aanbevolen om gebruik te maken van gangbare mechanismen zoals e-mail berichten beveiligd met s/mime of pgp. 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 proactieve 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 aan logfiles, contactinformatie, etc. 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 verstaan het elimineren van de oorzaak van het incident en zijn effect. Veelal gebeurt dit door het installeren van een fix 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 historiedatabases), hulpmiddelen voor auditing, scholing en training, productevaluatie en auditing & advies. Het meest bekend is de service informatievoorziening. Veel CSIRT s bieden informatie over nieuwe kwetsbaarheden en beschikbare patches aan via mailinglists en/of de eigen website. MANAGEMENT & INFORMATIE 2002/6 21

DEFINITIES VAN BEVEILIGINGINCIDENTEN In de literatuur is een relatief grote variëteit aan definities gerelateerd aan computer- of informatiebeveiligingsincidenten terug te vinden. Het IT Infrastructure Library Security Management [CCTA99] beschrijft informatiebeveiligingsincidenten als gebeurtenissen die schade kunnen veroorzaken aan de vertrouwelijkheid, integriteit of beschikbaarheid van informatie of informatieverwerking. Hierbij kan het gaan om opzettelijke activiteiten of ongelukken. Het begrip incident dient hierbij zeer ruim te worden beschouwd, namelijk elke gebeurtenis die niet behoort tot een systeem of dat geen onderdeel is van een standard operation. FIRST 10, het wereldwijde forum van incident response en security teams definieert een informatie beveiligingsincident als een gebeurtenis met daadwerkelijk of potentieel nadelige effecten op computer- of netwerkhandelingen die resulteert in: fraude, verspilling of misbruik; het in opspraak brengen van informatie; verlies of schade aan eigendom of informatie. Het binnendringen van computersystemen, exploitatie van technische onvolkomenheden en introductie van computervirussen of andere kwaadaardige software zijn volgens FIRST voorbeelden van beveiligingsincidenten. Het CERT/CC gaat voor een geheel andere benadering. Zij beschrijven een beveiligingsincident als een activiteit die een expliciet of impliciet (informatie)beveiligingsbeleid schendt. Aan deze definitie kleeft een belangrijk bezwaar. CERT/CC veronderstelt dat organisaties een, min of meer uniform, beveiligingsbeleid hanteren. Om aan dit bezwaar tegemoet te komen heeft het CERT/CC op zijn website activiteiten gekarakteriseerd die wereldwijd zijn erkend als schendingen van security policies. Deze activiteiten zijn: 1. pogingen (succesvol en niet-succesvol) om ongeautoriseerd toegang te krijgen tot een systeem of zijn gegevens; 2. niet-gewenste verstoring of dienstontzegging; 3. ongeautoriseerd gebruik van een verwerkingssysteem of van opgeslagen gegevens; 4. wijzigingen van hardware, firmware of software karakteristieken zonder kennis van de eigenaar, instructie of overeenstemming. Om uitwisseling van incidenten tussen CERT s te faciliteren heeft een Terena 11 Incident Taxonomy and Description Working Group een overzicht samengesteld [ARVI02] met veel voorkomende security incidenten. Het gebruik van dezelfde precisie en granulariteit in gebruikte termen is van belang om de ernst en omvang vast te kunnen en geeft daarnaast inzicht in de (pogingen tot) tegenmaatregelen en de (mogelijke) betrokken kosten, aldus de werkgroep. Zij onderscheidt de termen incident, security incident en IT security incident. De conclusie kan niet anders luiden dan dat verschillen in definities kunnen leiden tot interpretatiefouten bij incidentanalyse en onderlinge uitwisselbaarheid van incidentinformatie bemoeilijken. Een wereldwijd erkende standaardisatie van (security) incidentobject definities (ISO/IEC of IETF standaard) kan een oplossing bieden voor de huidige situatie. INCIDENT RESPONSE EN ITIL Binnen Europa hebben veel organisaties hun ICT beheerprocessen ingericht volgens de ITIL 12 methodologie. ITIL gaat uit van een procesmatige benadering van ict-beheer. Dit komt met name tot uitdrukking in het cyclische karakter: plannen, implementeren, evalueren, onderhoud. De Service Support Set en de Service Delivery Set zijn de belangrijkste verzameling van processen in ITIL [ITSM02]. 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: 22 MANAGEMENT & INFORMATIE 2002/6

VOORKOMEN EN BESTRIJDEN Service Level Management: vastleggen en nakomen van afspraken Availability Management: beschikbaarheid van ictcomponenten IT Services Continuity Management: continuiteitsbeheer van de it-dienstverlening Performance and Capacity Management: optimale inzet van ict-hulpmiddelen Tactisch Strategisch Service level IT services organization Managers Set Availability Service Delivery Set 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: Operationeel Incident Perf. & capacity Configuration & asset Security Management Problem Business Continuity Planning Release Change Service Support Set Configuration & Asset Management: samenstelling van de ict-infrastructuur Incident Management/Helpdesk: registratie en bewaking van alle gemelde incidenten Problem Management: beheren van problemen Change Management: beheren en beheersen van wijzigingen Release Management: implementatie van software en versiebeheer De jongste ITIL-loot is Security Management die in het midden van de piramide wordt gepositioneerd. Hoofddoel van ITIL Security Management is enerzijds het realiseren van de Service Level Agreements eisen ten aanzien van informatiebeveiliging en anderzijds het realiseren van een zeker basis beveiligingsniveau [OVER00]. Het proces Security Management heeft raakvlakken met vrijwel alle hierboven genoemde ITIL-processen. De ITIL-modules geven in redelijk detail 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 Management. Zo is er een relatie met Configuration and Asset Management waar alle ICT Configuration Items (ci), zijnde Figuur 1. De drie niveaus met oor ITIL Security Management relevante processen [OVRS00]. software, hardware, processen, procedures en documentatie worden vastgelegd in een Configuration Management Database. Een (dreigend) security incident heeft immers betrekking op één of meerdere ci s. Uiteraard is er een directe link met Incident Management en Problem Management waar alle incidenten, inclusief de security incidenten, worden geregistreerd en bewaakt. Ook is er een nauwe relatie met Change Management en/of Release Management. Security advisories van een CERT betekenen veelal de installatie van een patch 13 of het aanbrengen van nieuw softwarerelease, handelingen die volgens het van toepassing zijnde ITIL-proces dienen te worden uitgevoerd. Een calamiteit wordt binnen IT Service Continuity Management 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, wordt genoemd in de reeks van voorbeelden van calamiteiten. De missie van IT Service Continuity Management (ITSCM) is het zeker stellen dat de IT- MANAGEMENT & INFORMATIE 2002/6 23

infrastructuur en IT-(ondersteunende) diensten na een calamiteit zo snel mogelijk worden hersteld. ITSCM ondersteunt het bovenliggende Business Continuity Management (BCM). Business Continuity Management richt zich op het beheersen van bedrijfsrisico s teneinde een minimaal noodzakelijke productiecapaciteit en/of dienstverlening te waarborgen. Zowel in preventieve als in detectieve/repressieve zin raken taak en werkzaamheden van Computer Emergency Response Teams het ITIL-proces IT Service Continuity Management en vice versa. De al eerder aangehaalde definitiekwestie speelt hierbij een belangrijke rol: welk CERT security incident bijvoorbeeld is binnen de ITIL-terminologie een calamiteit?! 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 resp. Universiteit Twente en Universiteit van Amsterdam. Het onderzoek heeft als hoofddoel het verkrijgen van (meer) inzicht in de werking van incident response- en alameringsmechanismen op het gebied van ict-security en de invloed hiervan op de binnen ITIL gedefinieerde ict-beheerprocessen. In het kader van deze publicatie hanteer ik een tweetal stellingen. Stelling 1 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 Management. Standaardisatie werkt in zijn algemeenheid efficiëntie en effectiviteit verhogend. Echter er zijn ook nadelen. Standaardisatie kan verlammend werken op het aspect 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) 24 MANAGEMENT & INFORMATIE 2002/6

VOORKOMEN EN BESTRIJDEN te achterhalen adviseert het CERT om tijdelijk een honingpot, een leeg systeem met aansprekende naam als lokaas, te activeren. De ITIL processen Change Management en Configuration and Asset Management 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 businessprocessen ondersteunt de ci. Na het nemen van deze hobbel wordt vervolgens een requestfor-change (rfc) aangemaakt om de uitbreiding van netwerkconfiguratie met het ci mogelijk te maken, de rfc wordt door het Change Advisory Board beoordeeld, etc., etc. 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 Management. 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-patch 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 14 op het gebied van computercriminaliteit zal de klokkenluider uit de hackersgemeenschap voorzichtiger maken. Hij loopt immers het risico zelf betrokken te raken bij justitiële vervolging. Ook leveranciers van software 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. 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 [HILL01]. Ook in IETF verband is het onderwerp zeer actueel. Een in februari jl. bij de IETF vrijgegeven Internet- Draft getiteld Responsible Vulnerability Disclosure Process 15 heeft binnen de security en hackers community tot veel commotie geleid [OFFE02]. 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 securityexpertise binnen de teams en tot minder druk bij de leveranciers om tijdig patches ter beschikking te stellen. TOT SLOT Het onderzoek is in een pril stadium. Het trekken van conclusies en het doen van aanbevelingen zijn nog niet aan de orde. Wel mag duidelijk zijn dat de huidige situatie niet optimaal is zowel bezien vanuit het perspectief van Computer Emergency Response Teams alsmede vanuit het perspectief van de ict-beheer- en gebruikersorganisaties. Een nog nader uit te voeren case-study in 2003 zal hopelijk (meer) aangrijpingspunten verschaffen. In de verwachting dat de uitkomst een positieve bijdrage levert aan het werk van Computer Emergency Response Teams: Mission Completed! MANAGEMENT & INFORMATIE 2002/6 25

Over de auteur Mr. W.H.M. Hafkamp CISSP is programmamanager Informatiebeveiliging Rabobankgroep. Ook is hij voorzitter van de werkgroep Alarmering & Incident Response van het publiekprivate samenwerkingsprogramma Kwetsbaarheid Internet (Kwint). De auteur doet promotieonderzoek 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. Noten 1. Uit het rapport Inrichtingsplan voor Hacking Emergency Response Team (mei 2002) van het Landelijk projectbureau Digitaal Rechercheren. 2. Firewall = An internetwork gateway that restricts data communication traffic to and from one of the connected networks (the one said to be inside the firewall) and thus protects that network s system resources against threats from the other network (the one that is said to be outside the firewall), IETF RFC 2828, May 2000. 3. Constituency = doelgroep, bijvoorbeeld de eigen ICT-afdeling of alle eindgebruikers van een dienst. 4. Soms ook aangeduid als Computer Security Incident Response Teams (CSIRT). 5. Zie http://www.cert.org. 6. Zie http://cert-nl.surfnet.nl. 7. Zie http://www.cert-ro.nl. 8. Zie http://www.ecp.nl. 9. Request for Comments van de Internet Engineering TascForce. 10. Zie http://www.first.org. 11. TERENA = Trans European Research and Education Network Association (zie http://www.terena.nl). 12. 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. 13. A patch (sometimes called a fix ) is a quick repair job for a piece of programming (NIST Special publication 800-40). 14. Europese Commissie, Voorstel voor een Kaderbesluit van de Raad over aanvallen op informatiesystemen, COM(2002) 173 definitief, Brussel 19 april 2002. 15. In februari 2002 door Steve Christey en Chris Wysopal geplaatste Internet-Draft, textfile draft-christey-wysopal-vulndisclosure-oo.txt op www.ietf.org binnen de categorie Best Current Practice. Referenties [AMSR02] 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. [ARVI02] 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. [CERT02] CERT /CC, Overview of Attack Trends, beschikbaar op het World Wide Web via www.cert.org, 2002. [CCTA99] CCTA Central Computer and Telecommunications Agency, Cazemier, Overbeek & Peters, Security Management IT Infrastructure Library, The Stationary Office, London, 1999. [HILL01] G. Hillenius, Beperkte veiligheidslekken, Computable, 16 november 2001. [ISS02] Internet Security Systems, Internet Risk Impact Summary for March 26, 2002 through June 24, 2002, beschikbaar op het World Wide Web via https://gtoc.iss.net, juli 2002. [ITSM02] ITSMF Nederland, IT Service Management, een introductie, van Haren publishing, V3.0 januari 2002. [KOEK02] 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. [MOWE02] A. Mooij, J. van der Werf, Cybercrime, uitgave van het Korps Landelijke Politiediensten Dienst Nationale Recherche Informatie, juli 2002. [OFFE02] A. Offerman, Vulnerabilities: publiceren ja of nee?, IDG kwartaalblad infosecurity.nl, tweede kwartaal 2002. [OVER00] P. Overbeek, Beveiliging en Beheer met ITIL Security Management, Informatiebeveiliging Jaarboek 2000/2001, Ten Hagen & Stam, Den Haag 2000. [OVRS00] P. Overbeek, E. Roos Lindgreen, M. Spruit, Informatiebeveiliging onder controle, Pearson Education, Amsterdam, 2000. [STTN01] 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. 26 MANAGEMENT & INFORMATIE 2002/6