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.

‘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 kritie-

MANAGEMENT & INFORMATIE 2002/6

TELT EEN GEWAARSCHUWDE ORGANISATIE VOOR TWEE?

ke 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).

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-

ren2 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.

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.

20

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-NL6 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



Computer Emergency Response. Op 5 juni is officieel door voormalig minister van Boxtel CERT-RO7 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 rfc9 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.

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’. FIRST10, 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;

22

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 Terena11 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 ITIL12 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:



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

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: 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


Strategisch

Managers Set

IT services organization

Tactisch Service level management

Availability management

Service Delivery Set

Security Management Perf. & capacity management

Business Continuity Planning

Operationeel Incident management

Problem management

Configuration & asset management

Change management

Service Support Set

Release management

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 patch13 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-

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.

24

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)



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!

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 InternetDraft 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.

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 wetgeving14 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


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 !

25

Over de auteur

Referenties

Mr. W.H.M. Hafkamp CISSP is programmamanager

[AMSR02]

Informatiebeveiliging Rabobankgroep. Ook is hij voorzitter van de

de Virtuele Ruimte, publicatie in de reeks Politiekunde van het

werkgroep Alarmering & Incident Response van het publiek-

Programma Politie en Wetenschap, Kerckebosch, Amsterdam, mei

private samenwerkingsprogramma Kwetsbaarheid Internet

2002.

(Kwint). De auteur doet promotieonderzoek naar de werking van

[ARVI02]

incident response- en alarmeringsmechanismen op het gebied van

related terminology – TERENA Incident Taxonomy and Description

ict-security en de invloed hiervan op de binnen ITIL gedefinieerde

Working Group, beschikbaar op het World Wide Web via

ict-beheerprocessen.

www.terena.nl, juni 2002.

Noten

het World Wide Web via www.cert.org, 2002.

1. Uit het rapport ‘Inrichtingsplan voor Hacking Emergency

[CCTA99]

Response Team’ (mei 2002) van het Landelijk projectbureau

Agency, Cazemier, Overbeek & Peters, Security Management IT

Digitaal Rechercheren.

Infrastructure Library, The Stationary Office, London, 1999.

[CERT02]

P. van Amersfoort, L. Smit, M. Rietvelt, Criminaliteit in

J. Arvidsson, Taxonomy of the Computer Security Incident

CERT®/CC, Overview of Attack Trends, beschikbaar op CCTA – Central Computer and Telecommunications

2. Firewall = An internetwork gateway that restricts data

[HILL01]

communication traffic to and from one of the connected networks

november 2001.

(the one said to be ‘inside’ the firewall) and thus protects that

[ISS02]

network’s system resources against threats from the other network

March 26, 2002 through June 24, 2002, beschikbaar op het World

(the one that is said to be ‘outside’ the firewall), IETF RFC 2828,

Wide Web via https://gtoc.iss.net, juli 2002.

May 2000.

[ITSM02]

3. Constituency = doelgroep, bijvoorbeeld de eigen ICT-afdeling of

introductie, van Haren publishing, V3.0 januari 2002.

G. Hillenius, Beperkte veiligheidslekken, Computable, 16

Internet Security Systems, Internet Risk Impact Summary for

ITSMF Nederland, IT Service Management, een

alle eindgebruikers van een dienst.

[KOEK02]

4. Soms ook aangeduid als Computer Security Incident Response

van het ICT Uitvoeringsorgaan Rijksoverheid in verband met de

Teams (CSIRT).

oprichting van een CERT voor de Rijksoverheid, februari 2002.

M. Koek, Omgevingsverkenning CERT-RO, interne nota

5. Zie http://www.cert.org.

[MOWE02]

6. Zie http://cert-nl.surfnet.nl.

Korps Landelijke Politiediensten Dienst Nationale Recherche

7. Zie http://www.cert-ro.nl.

Informatie, juli 2002.

8. Zie http://www.ecp.nl.

[OFFE02]

9. Request for Comments van de Internet Engineering TascForce.

kwartaalblad infosecurity.nl, tweede kwartaal 2002.

10. Zie http://www.first.org.

[OVER00] P. Overbeek, Beveiliging en Beheer met ITIL Security

11. TERENA = Trans European Research and Education Network

Management, Informatiebeveiliging Jaarboek 2000/2001, Ten Hagen &

Association (zie http://www.terena.nl).

Stam, Den Haag 2000.

12. Information Technology Infrastructure Library (ITIL) is een

[OVRS00]

door de Britse Central Computer and Telecommunications

Informatiebeveiliging onder controle, Pearson Education, Amsterdam,

Agency/Office of Government Commerce (CCTA/OGC)

2000.

uitgegeven, gestructureerde set van modules met ‘best practices’ op

[STTN01]

het gebied van ICT beheer; ITIL wordt binnen een groot aantal

veilig Internet verkeer, Eindrapportage van het onderzoeksproject

Europese landen beschouwd als dé de facto standaard voor het

‘kwetsbaarheid van internet’ in opdracht van het Ministerie van

beheer van ICT processen binnen organisaties.

Verkeer & Waterstaat, Januari 2001.

A. Mooij, J. van der Werf, Cybercrime, uitgave van het

A. Offerman, Vulnerabilities: publiceren ja of nee?, IDG

P. Overbeek, E. Roos Lindgreen, M. Spruit,

Stratix Consulting Group/TNO-FEL, Samen werken voor

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.

26


TELT EEN GEWAARSCHUWDE ORGANISATIE VOOR TWEE?

Recommend Documents