Zicht op risico s van legacysystemen. Een self-assessmentmethode om de risico s van (vitale) legacysystemen in kaart te brengen

Zicht op risico’s van legacysystemen Een self-assessmentmethode om de risico’s van (vitale) legacysystemen in kaart te brengen

Zicht op risico’s van legacysystemen Een self-assessmentmethode om de risico’s van (vitale) legacysystemen in kaart te brengen

Versie 1 november 2015

ncsc |

2

Zicht op risico’s van legacysystemen | ncsc

Inhoud

Introductie voor het management

5

Inleiding7 Wanneer het self-assessment gebruiken?

9

Voor u begint

13

Onderdeel 1 - Bepalen veiligheid

15

Onderdeel 2 - Impact van verstoringen

23

Onderdeel 3 - Risicoprofiel en risicomitigatie

25

Totstandkoming28

3

ncsc |

4


Introductie voor het management

Waarom een self-assessmentmethode voor risico’s van legacysystemen? Legacysystemen zijn systemen die gebouwd zijn met technologie die niet of nauwelijks meer wordt ondersteund door externe leveranciers en/of de eigen organisatie. Veel organisaties maken voor hun dienstverlening nog gebruik van deze moeilijk te onderhouden legacysystemen. Legacysystemen worden ook vaak ingezet in vitale processen. Daarmee vervullen deze systemen een cruciale rol in de Nederlands samenleving, zoals in het betalings verkeer of in openen en sluiten van waterkeringen en de bewaking van de drinkwaterkwaliteit. De beveiligingsrisico’s van deze systemen nemen toe doordat systemen steeds meer aan elkaar gekoppeld worden en aangesloten zijn op het internet. Deze self-assessmentmethode helpt u om op gestructureerde wijze inzicht te verkrijgen in de risico’s. Op basis van dit inzicht kunt u vervolgens beslissingen nemen om de risico’s te beperken.

Besluitvorming over legacysystemen vraagt strategische aandacht Voor het nemen van een verantwoorde investeringsbeslissing over een legacysysteem is het belangrijk dat u een objectief beeld krijgt van de risico’s die uw organisatie loopt met de legacysystemen. Bij een laag risico kunt u beslissen tot handhaven van het systeem en blijven monitoren of de kwetsbaarheid toeneemt. Blijkt het risico hoog te zijn dan kan u beslissen tot ingrijpendere maatregelen zoals de volledige vervanging van het systeem. Vervanging van een legacysysteem is vaak een risicovol en meerjarig traject dat directe strategische besturing vraagt.

Wat is uw rol bij het self-assessement Het is goed om bij de strategische besluitvorming over de toekomst van informatiesystemen regelmatig geïnformeerd te worden over de risico’s van legacysystemen. U kunt daarbij de volgende stappen overwegen: 1. Beslis op directieniveau over het regelmatig uitvoeren van het self-assessment als onderdeel van uw besluitvormingsproces over strategische investeringen in kritische informatiesystemen. 2. Bepaal in overleg met de proces- en systeemeigenaren voor welke systemen het self-assessment zinvol is. Dit is geen wet van Meden en Perzen, maar een collegiale inschatting voor welk systeem of voor welke systemen het self-assessment zinvol kan zijn. 3. Geef opdracht aan een team van systeemeigenaar en ICT- en security-experts om het self-assessment uit te voeren en de uitkomsten in termen van een onderbouwd risicoprofiel te rapporteren. 4. Laat u op basis van de uitkomsten van het self assessement adviseren over de te volgen koers voor de toekomst van het systeem. Is een systeem aan vervanging toe of kunnen de kwetsbaarheden door relatief eenvoudige ingrepen worden weggenomen? 5. Overweeg dit self-assessment jaarlijks uit te laten voeren zodat u de meerjarige ontwikkeling van risico’s bij legacysystemen kunt volgen.

5

ncsc |

6


Inleiding

Nederland is in hoge mate afhankelijk van het goed functioneren van informatie- en communicatietechnologie (ICT1). Incidenten met ICT-systemen kunnen grote maatschappelijke gevolgen hebben. De zogenaamde ‘legacysystemen’ verdienen hierbij bijzondere aandacht. Dit zijn systemen die gebouwd zijn met technologie die niet of nauwelijks meer wordt ondersteund door externe leveran ciers en/of de eigen organisatie. Veel van deze legacysystemen draaien al jaren uitstekend. Ze zijn ogenschijnlijk betrouwbaar en er hebben zich al jaren geen inciden ten voorgedaan. De keerzijde hiervan is dat er wanneer zich een incident of probleem voordoet, vaak niet meer voldoende kennis aanwezig is binnen de eigen organisatie om deze op te lossen. Daarnaast zijn veel legacysystemen inmiddels gekoppeld aan andere systemen of aan het internet, koppelingen waar de systemen oorspronkelijk niet voor zijn ontworpen. Doordat de beveiliging van deze systemen niet is toegerust op deze koppelingen, zijn legacy systemen kwetsbaarder voor stroringen of kwaadaardige activiteiten zoals cybercrime of spionage. Kortom: qua beschikbaarheid, integriteit en vertrouwelijkheid zijn legacysystemen in vergelijking met modernere systemen kwetsbaarder en daarmee onveiliger. Als het gaat om systemen bij organisaties in vitale sectoren kan deze kwetsbaarheid grote gevolgen hebben, zowel voor de eigen organisatie als voor de maatschappij. Het is dan ook van belang dat organisaties zich bewust zijn van deze relatieve onveiligheid en dat deze organisaties weten bij welke systemen dergelijke onveilig heden zich voordoen en om welke specifieke onveiligheden het gaat. Maar ook dat zij beschikken over strategieën voor het wegnemen of verkleinen van de risico’s. Om organisaties hierbij te helpen heeft het Nationaal Cyber Security Centrum (NCSC) van de Nationaal Coördinator Terrorismebestrijding en Veiligheid (NCTV) dit self-assessment ontwikkeld.

1

Met het doorlopen van dit self-assessment krijgt u inzicht in de concrete onveiligheden en kwetsbaarheden van een systeem. Het self-assessment geeft voorts inzicht in de kans op incidenten en de impact van verstoringen en levert input voor beslissingen over de toekomst: is een systeem aan vervanging toe of kunnen de kwetsbaarheden door relatief eenvoudige ingrepen worden weggenomen? Het self-assessment kan zowel door ICT- als security-experts worden gebruikt, maar biedt ook het management een tool om het benodigde inzicht te krijgen voor te nemen investeringsbeslissingen. Het self-assessment beperkt zich tot een vooraf geselecteerd legacysysteem in een organisatie. Vaak werken deze systemen binnen complexe informatieketens die de organisatiegrens overstijgen. Een volledige risicoanalyse op de gehele informatieketen is aan te raden, maar ligt buiten de scope van dit self-assessment. De uitkomsten van het self-assessment kunnen wel input leveren voor overleg binnen en tussen organisaties en voor overleg met ketenpartners, leveranciers en overheden over verder onderzoek naar en opties voor het managen van risico’s van legacysystemen. Dit self-assessment wordt u aangeboden als hulpmiddel om op eenvoudige en laagdrempelige wijze inzicht te krijgen in de risico’s en om u handelingsperspectief te bieden voor het zo veilig mogelijk maken van uw vitale legacysystemen. Het self-assessment is geheel vrijwillig en het staat u vrij om het self-assessment naar eigen inzicht aan te passen op uw specifieke situatie.

Onder ICT verstaan we in dit kader naast gegevensverwerkende systemen ook industriële controlesystemen (ICS/SCADA en aan SCADA gerelateerde protocollen als Profinet, FieldBus, ModBus, ProfiBus en CAN). Het NCSC heeft voor deze systemen een aparte checklist beveiliging van ICS/ SCADA-systemen ontwikkeld. 7

ncsc |

8


Wanneer het selfassessment gebruiken? Het self-assessment is bedoeld voor alle organisaties die zich zorgen maken over de veiligheid van hun legacysystemen. Het self-assessment is in eerste instantie geschreven voor organisaties in vitale sectoren met legacy-systemen, maar is ook toepasbaar in andere grote organisaties met legacy-systemen. Hierbij is het van belang dat de veiligheid van een systeem wordt bepaald door zowel technische aspecten als door de context van het systeem. Onderstaand wordt eerst de scope en doelgroep van het self-assessment beschreven. Vervolgens worden enkele handvatten gepresenteerd om potentieel onveilige legacysystemen te herkennen, systemen waarvoor het de moeite loont om opdracht te geven tot het uitvoeren van een self-assessment.

Scope en doelgroep Legacysystemen Doel van dit self-assessment is het in kaart brengen van het risico van legacysystemen binnen uw organisatie, inzicht te geven in concrete kwetsbaarheden van deze systemen en een handreiking te bieden voor het nemen van beslissingen omtrent deze systemen. Legacy-systemen kunnen omschreven worden als systemen die gebouwd zijn met technologie die inmiddels door leveranciers niet of beperkt ondersteund wordt, waardoor het onderhoud moeilijk wordt. De risico’s bij deze systemen en de toenemende connectiviteit tussen legacy-systemen in overige systemen vragen daarom extra aandacht. Legacy-systemen worden ingezet in vitale processen, hiermee vervullen deze legacy-systemen een centrale rol in de vitale infrastructuur. De gevolgen van de uitval van deze systemen kunnen daarom voor grote delen van de Nederlandse samenleving vergaande gevolgen hebben en herstel wordt erg lastig of zeer kostbaar. Legacy-systemen zijn niet noodzakelijkerwijs onveilig(er): veel van deze systemen draaien al jaren uitstekend. Ze zijn ogenschijnlijk betrouwbaar en er hebben zich al jaren geen incidenten voor gedaan. Legacy-systemen kunnen wel onveilig(er) zijn. Dit selfassessment is bedoeld om dit te toetsen.

Aanvulling op andere methoden In risicomanagement en informatiebeveiliging zijn veel andere methoden beschikbaar, zoals ISO 27002 en 27005, ISF Sprint, NIST SP 800-53, BIV-classificaties, Baseline Informatiebeveiliging Rijk etc. Dit self-assessment is anders in die zin dat wordt gekeken naar onveiligheden en opties die specifiek voor legacysystemen relevant zijn, en dat de gekwantificeerde risico’s voor de eigen organisaties én de samenleving aan de orde komen. Het self-assessment is niet

bedoeld als vervanging, maar als mogelijke aanvulling op andere methoden. Als u binnen uw organisatie het lifecyclemanagement op informatiesystemen heeft ingericht en u daarbinnen ook securityrisicoanalyses uitvoert, is het raadzaam om eerst na te gaan in hoeverre dit self-assessment daadwerkelijk een aanvulling is op deze analyses.

Vitale organisaties Het self-assessment is te gebruiken door alle (grotere) organisaties met een legacyproblematiek, maar richt zich primair op organi saties in vitale sectoren. Uiteraard kan de methodiek, of delen daarvan, ook door andere (minder vitale) organisaties worden gebruikt. Organisaties en systemen bestaan niet los van elkaar. Steeds meer werken organisaties samen in netwerken, zowel op organisatorisch vlak als op het gebied van informatie-uitwisseling (keteninformatisering). Dit maakt de onderlinge afhankelijkheid en de kwetsbaarheid in de keten steeds belangrijker. Als informatie systemen in niet-vitale organisaties aangevallen worden, dan kan dat door de ketenafhankelijkheid ook het systeem van de keten partner bedreigen. Daarom worden in het self assessment ook koppelingen tussen systemen en tussen onderdelen van systemen behandeld. De ketenproblematiek valt buiten de scope van het self-assessment.

Focus op essentiële systemen Het self-assessment richt zich op essentiële/vitale legacysystemen. Dat wil niet zeggen dat de methodiek niet kan worden gebruikt voor de analyse voor nieuwere of minder belangrijke systemen. H oewel gedacht wordt aan systemen voor het primaire proces van de organisatie, kunnen ook systemen die andere processen van de organisatie ondersteunen met deze methodiek worden geanalyseerd. 9

ncsc | Wanneer het self-assessment gebruiken?

Alle soorten ICT-systemen Het self-assessment is toepasbaar op alle soorten ICT-systemen, ongeacht hun functie in de maatschappij (alleen informatie verwerking, zoals in het betalingsverkeer, of ook procesbesturings systemen, zoals bij waterkeringen en elektrische installaties), soort (frontend of backend, client, applicatie, platform, besturings system, hardware, netwerk/middleware of combinatie daarvan), technologie (bijvoorbeeld programmeertaal), ontwerper of leverancier. Hoewel ook personele en fysieke beveiliging van belang zijn voor de veiligheid van ICT-systemen, wordt in deze methodiek alleen ingegaan op aan de ICT-gerelateerde onveiligheden en kwetsbaarheden. Ook ligt de nadruk op kwetsbaarheden en beveiligingsopties die specifiek zijn voor legacysystemen.

Per systeem één self-assessment Deze methodiek is bedoeld voor het verkrijgen van inzicht in de kwetsbaarheid van één systeem. Onder een systeem wordt hier verstaan een logische samenhangend samenstel van ICT-systemen, apparaten, machines, etc. met een gedefinieerd bedrijfsdoel. Het systeem kan uit meerdere onderdelen bestaan, zoals combina ties van hard- en software of systemen die samen één of meerdere bedrijfsfuncties ondersteunen. Als u meerdere vitale legacysystemen heeft, kunt u voor ieder van deze systemen het self-assessment uitvoeren. Als bij de uitvoering van het self-assessment blijkt dat het niet mogelijk is om één gelijkluidend antwoord te geven voor verschillende delen van het systeem, kies er dan voor om het self-assessment voor maar één deel of voor elk van de delen apart uit te voeren.

Risicobenadering In het self-assessment worden drie verschillende begrippen van risico gehanteerd: • Risicoprofiel. Het risico (de veiligheid van het systeem en de impact van een verstoring op de omgeving) van het legacysysteem dat geanalyseerd wordt. • Risico-afweging. Hoe de (management)verantwoordelijke(n) van het systeem de omvang van het risico afzetten tegen de overige doelen van de organisatie en de nadelen (ook de kosten) van opties om de onveiligheid van het systeem te verminderen. • Migratie-risico. De gevaren voor de continuïteit van de bedrijfs voering die verbonden zijn aan het doorvoeren van maatregelen om het systeem veiliger te maken of (deels) te vervangen.

Zicht op onveilige legacysystemen Om tijdig te kunnen besluiten om verbeteringen in de beveiliging door te voeren zouden organisaties van al hun systemen in beeld moeten hebben wanneer de vertrouwelijkheid, beschikbaarheid en/ of integriteit van hun systemen bedoeld of onbedoeld in het geding komen (met andere woorden: wanneer een systeem onveilig wordt). De werkelijkheid blijkt echter weerbarstiger. In veel organisaties ontstaan onder betrokken medewerkers discussies of alle legacysystemen wel bekend zijn, of wel voldoende duidelijk is hoe (on)veilig een specifiek legacysysteem is, of er niet te weinig aandacht is voor de veiligheid van een legacysysteem, of er niet meer onderzoek naar moet worden gedaan, of over de vraag of het niet tijd is een plan te maken voor het uitfaseren van een specifiek systeem juist omdat het te onveilig is. Dergelijke discussies sluimeren soms jarenlang, waardoor het voor specialisten en management niet eenvoudig is om over de toekomst en (on) veiligheid van legacysystemen te spreken. In dit soort situaties kan het nuttig zijn om gezamenlijk, gestructureerd (nog) eens in kaart te brengen hoe veilig het legacysysteem is en welke opties reëel zijn om de belangen van de bedrijfsvoering – en zeker voor vitale organisaties ook de samenleving – te borgen. Concreter zouden (management)verantwoordelijken in ieder geval over moeten gaan tot nadere analyse als meerdere van de onder staande situaties aan de orde zijn: • Het systeem ondersteunt vitale processen voor de eigen organisatie, andere organisaties of de maatschappij. • Het systeem verwerkt vertrouwelijke informatie (denk bijvoor beeld aan gegevens die vallen onder de Wet bescherming persoonsgegevens). • Het systeem kent koppelingen met andere systemen. • Het systeem is gebouwd met niet meer ondersteunde technologie. • Incidenten met het systeem op het gebied van vertrouwelijkheid, beschikbaarheid of integriteit nemen toe en kunnen niet goed meer worden opgelost. • Het onderhoud van het systeem lijkt ‘kunst- en vliegwerk’ te zijn geworden. • Documentatie over het systeem ontbreekt. • Voor het systeem cruciale medewerkers verlaten de organisatie. • Er hebben zich grote ICT- of organisatieveranderingen rondom het systeem voorgedaan. • Externe ondersteuning van het systeem of het aantrekken van nieuwe, eigen medewerkers voor de ondersteuning van het systeem is problematisch geworden. • Specialisten horen van steeds meer hacks of hiccups op vergelijkbare systemen bij andere organisaties. Deze situaties zijn indicaties dat de veiligheid van een systeem niet zonder meer gewaarborgd is en dat het raadzaam is om het systeem verder te onderzoeken.

10


Dit self-assessment is bedoeld als een hulpmiddel bij het nader onderzoeken van het systeem, het bespreken van de (on)veiligheid van een systeem binnen de organisatie en het nemen van beslissingen over de toekomst van het systeem. Het kan zijn dat er binnen uw organisatie nog geen totaalbeeld is van de legacysystemen en het risicoprofiel. In dat geval is het raadzaam te onderzoeken of er toch legacysystemen zijn waarvoor verdere analyse nodig is, ook als u deze systemen nog niet direct voor ogen heeft. Breng in dat geval uw systemen in kaart en bekijk of de voornoemde situaties op de systemen van toepassing zijn. Het verdient daarnaast aanbeveling dit self-assessment uit te voeren voor alle legacysystemen die al lange tijd niet meer op hun veiligheid zijn beoordeeld. Ook alle systemen die volgens medewerkers onveilig zouden kunnen zijn kunnen met dit self-assessment verder worden onderzocht.

11

ncsc |

12


Voor u begint

Als eenmaal de keuze is gemaakt het self-assessment voor een bepaald systeem uit te voeren is het van belang om bij de uitvoering de volgende factoren in het oog te houden:

Zorg dat rollen, taken en verantwoordelijkheden goed zijn geformuleerd

Structureer de uitvoering Verzamel documentatie en archiveer deze documentatie. Leg verslagen van gesprekken vast en archiveer deze. Leg besluitvorming ook vast.

Blijf onderzoeken

Benoem binnen uw organisatie de mensen die voor een bepaald legacysysteem verantwoordelijkheid dragen en expliciteer hoe de taken en verantwoordelijkheden van deze mensen binnen de organisatie passen. Wees expliciet over rollen, taken en verantwoor delijkheden. Dit is niet specifiek voor dit assessment.

Als u een vraag uit het assessment niet kunt beantwoorden, dan is meer onderzoek op het desbetreffende punt nodig. Dit kan bijvoorbeeld door het raadplegen van leveranciers, oud-medewerkers of aan de hand van een expertschatting.

Managementcommitment

Als u een punt van onveiligheid of kwetsbaarheid van het systeem snel en eenvoudig kunt wegnemen, dan adviseren wij u uiteraard dit snel te doen, en het self-assessment vervolgens in te vullen voor de situatie na de verbetering.

Zorg voor duidelijke afspraken met het senior management over het belang van het self-assessment, de inzet van de benodigde resources en de wijze van terugkoppeling en verdere behandeling van de uitkomsten van het self-assessment.

Organiseer de uitvoering Het self-assessment moet worden geleid door de eindverantwoorde lijke voor het systeem, ook al komt het initiatief mogelijk van een specialist. Betrek alle relevante functionarissen bij het selfassessment: ICT-management, personen die met het systeem werken, specialisten van de ICT-afdeling, securityspecialisten die kennis hebben van de omvang van de (maatschappelijke) impact van aantasting van het systeem en indien van toepassing de liaisons naar andere organisaties die met het desbetreffende systeem te maken hebben. Als het beheer van het systeem is uitbesteed, kan het noodzakelijk zijn de partij die het beheer uitvoert te betrekken bij het self assessment. Het verdient de aanbeveling om het self-assessment niet alleen in te laten vullen door één bepaalde specialist, maar om het self-assessment gezamenlijk met alle relevante personen te doorlopen. Dit zodat de benodigde discussie plaatsvindt en daadwerkelijk alle relevante informatie op tafel komt. Een securityspecialist kijkt immers anders naar veiligheid dan de persoon die dag in dag uit met het systeem werkt. Zorg dat de discussie goed wordt geleid door een voorzitter.

Los eenvoudige problemen direct op

Houd rekening met de betrouwbaarheid Houd bij het uitvoeren van het assessment rekening met de betrouwbaarheidsindicator: “Hoe zeker weet u het?”. Geeft u in het assessment aan op welke punten de antwoorden niet goed onderzocht of niet goed bekend zijn. Daarnaast kunt u uiteraard meer informatie blijven zoeken en als u deze informatie vindt de betrouwbaarheidsindicator bijstellen.

Beschouw het self-assessment als een learning loop Het self-assessment is bedoeld als een zogenaamde ‘learning loop’ (Plan-Do-Check-Act): voer het assessment eens in de zoveel tijd uit en verbeter zo de veiligheid van uw systemen steeds verder. En bedenk dat wat nu nog geen legacy is, dat over een aantal jaren waarschijnlijk wel zal zijn. Het self-assessment kan daarom ook kennis en bewustzijn genereren die maakt dat u bij het inkopen of aanpassen van nieuwe systemen toekomstige legacyproblemen voor kunt zijn. Integreer het self-assessment in het lifecycle management van uw organisatie. Kijk daarom ook vooruit: welke ontwikkelingen in de komende jaren kunnen van invloed zijn op de veiligheid van het systeem?

13

ncsc | Voor u begint

Verdeel als het nodig is het self-assessment in twee sessies Als bij de uitvoering van het self-assessment alle benodigde informatie voor handen is, en alle relevante functionarissen betrokken zijn, kan het self-assessment in twee tot drie uur worden uitgevoerd. Als blijkt dat de antwoorden op meerdere vragen niet bekend zijn, is het raadzaam om deze eerst uit te zoeken om in een later stadium opnieuw bij elkaar te komen. Het self-assessment zal in de meeste gevallen in maximaal twee sessies kunnen worden uitgevoerd.

Begin met de uitvoering! Het self-assessment kent een aantal onderdelen: (0) selectie van het legacysysteem waarvoor de analyse uitgevoerd zal worden op basis van de geschetste situaties in de paragraaf ‘Zicht op onveilige legacysystemen’ (1) bepalen van de veiligheid van het systeem, (2) het bepalen van de impact van verstoringen en (3) het bepalen van het risicoprofiel en de mitigatiestrategieën. In de volgende hoofdstukken is per onderdeel een aantal vragen opgenomen die u helpen om inzicht te krijgen in de risico’s van het systeem en een handreiking geven hoe u met deze risico’s om kunt gaan. U kunt vanzelfsprekend naar eigen inzicht vragen toevoegen aan de verschillende fasen die voor uw organisatie relevant zijn. D e gestelde vragen kunt u op kwalitatieve wijze beantwoorden, met eigen informatie en eigen overwegingen. Daarnaast zijn voor de onderdelen veiligheid en impact vragenlijs ten ontwikkeld die het mogelijk maken om op eenvoudige wijze inzicht te krijgen in de eventuele risico’s van het systeem. De vragenlijsten bevatten scoringstabellen die zijn onderverdeeld in scores 1 tot en met 5. Een score van 5 geeft aan dat er op dat onderdeel geen veiligheidsrisico is of dat een verstoring van het systeem geen impact heeft. Bij een score van 3 of minder op een onderdeel is het van belang dat de verantwoordelijken voor het systeem verdere actie ondernemen. Met andere woorden: hoe lager u scoort, hoe groter de urgentie om de risico’s van het systeem op te lossen en hoe meer vragen bij een bepaald systeem laag scoren, hoe groter het risico van het systeem is. Mocht uw specifieke situatie of inzichten daar aanleiding toe geven dan kunt u andere of extra informatie of extra vragen invoegen of de verdeling over de schaal aanpassen. Omdat het self-assessment toepasbaar moet zijn op allerlei soorten legacysystemen, en bij het ene systeem een bepaalde onveiligheid meer invloed heeft dan bij het andere systeem, leidt het selfassessment niet tot een totaalscore die exact uitwijst hoe groot het risico van een bepaald systeem is. Wel geeft iedere fase een algemeen beeld voor het (senior) management hoe veilig een systeem is, het groot de impact is als het systeem wordt aangetast en welke strategie(en) de onveilige situatie het meest zou(den) verbeteren. De vragen in dit self-assessment laten u bewust nadenken over de risico’s van een legacysysteem en zijn bedoeld om de discussie binnen organisaties over een bepaald systeem te structureren en te prikkelen.

14

In schema ziet het self-assessment er als volgt uit:

Onderdeel 0

Selectie legacy systeem

Onderdeel 1

Bepalen veiligheid

Onderdeel 2

Bepalen impact van verstoringen

Onderdeel 3

Bepalen risicoprofiel Bepalen mitigatie strategieën


Onderdeel 1 Bepalen veiligheid 1.1 Inleiding De veiligheid van een legacysysteem wordt bepaald door technische aspecten, maar ook door de context rondom het systeem. Is het systeem beveiligd tegen actuele aanvallen, zijn er voldoende maatregelen getroffen om te voorkomen dat mensen die niets in het systeem te zoeken hebben toch toegang hebben en zijn er voldoende mogelijkheden om het systeem up-to-date te houden en aan te passen naar actuele eisen en wensen? Maar ook: zijn er nog mensen binnen de organisatie die weten hoe het systeem werkt en wat er moet gebeuren als het systeem crasht? In dit eerste deel van het self-assessment is een aantal vragen opgenomen dat u helpt inzicht te krijgen in de veiligheid van het systeem. Deze fase eindigt met een samengevat beeld van de veiligheid van het systeem voor het (senior) management.

1.2 Vragen De onderstaande vragen zijn gecategoriseerd naar onderwerp. Bij iedere vraag kan een score gegeven worden. De scores hebben de volgende betekenis: 1. Niet/onbekend 2. Zeer beperkt 3. Beperkt 4. Voldoende 5. Ruim voldoende/ niet relevant Wanneer u op een vraag laag scoort, zou u zich de vraag moeten stellen hoe u de desbetreffende onveiligheid kunt wegnemen. Hoe meer vragen een lage score krijgen, hoe onveiliger het systeem is. Deze score geeft ook een indicatie over de waarschijnlijkheid dat verstoringen van het systeem optreden. Soms kan een zwakke beheersmaatregel in het ene onderdeel gecompenseerd worden door een sterke beheersmaatregel in een ander onderdeel. Probeer bij de beantwoording van de vragen wel zo veel mogelijk per onderdeel een score te geven zonder daarbij reeds compenserende maatregelen mee te wegen. Bij het opstellen van het totaalbeeld kan vervolgens met behulp van wegingsfactoren

of door het geven van een toelichting aangegeven worden in welke mate lage scores op het ene onderdeel gecompenseerd worden door een hogere score in een ander onderdeel In 1.5 wordt aangegeven op welke wijze een totaalbeeld van het veiligheidsprofiel kan worden opgemaakt.

1.3 Waarschijnlijkheid van optreden verstoringen Hoewel ervoor is gekozen om in het self-assessment geen specifieke vragen over de waarschijnlijkheid van verstoringen van het systeem op te nemen, verdient dit onderwerp wel de aandacht. In algemene zin is het uiteraard zo dat hoe lager uw systeem in dit hoofdstuk heeft gescoord op veiligheid, hoe groter de kans is dat verstoringen optreden. De waarschijnlijkheid van verstoringen is en blijft een inschatting, waarbij de werkelijkheid positiever of negatiever kan uitpakken. Als zich met regelmaat incidenten voordoen of wanneer er sprake is van een duidelijke toename van incidenten, kan dit erop wijzen dat het systeem onveiliger wordt. Andersom is een systeem waarmee nauwelijks incidenten zijn niet per se veilig. Aanwezige kwetsbaar heden kunnen immers ineens leiden tot (ernstige) verstoringen. Verstoringen kunnen het gevolg zijn van toeval of onbewuste fouten van eigen medewerkers of externe ondersteuners. Ook bij een moedwillige verstoring is het soms toeval dat juist uw o rganisatie en niet een andere organisatie het doelwit wordt van bijvoorbeeld criminelen. Omdat internet gekoppelde systemen automatisch worden gescand en afgetast is de dreiging van infectie via het internet een permanent aanwezige dreiging. Daarom is bij systemen die aan internet gekoppeld zijn (direct en indirect) de waarschijnlijk heid van verstoring aanzienlijk en moet de bescherming voldoende zijn. Juist vitale organisaties vormen een interessant doelwit voor zware criminelen, terroristen en buitenlandse inlichtingendiensten. De waarschijnlijkheid van verstoring van belangrijke systemen van vitale organisaties is dus hoger, ook omdat de tegenstanders veel meer technische middelen hebben om verstoringen te veroorzaken. 15

ncsc | Onderdeel 1 - Bepalen veiligheid

1.4 Onderwerpen

Governance en beheer

Ontwikkeling Om eventuele kwetsbaarheden in de beveiliging te kunnen repareren of additionele beveiligingsmaatregelen aan te kunnen brengen, dient de software van zowel de clientomgeving, de applicatieomge ving als onderliggende componenten aangepast te kunnen worden. Om wijzigingen in het systeem op een gecontroleerde wijze aan te brengen, te testen, te accepteren en op gecontroleerde wijze in productie te kunnen brengen, is het aanwezig zijn van een gescheiden ontwikkel-, test-, acceptie- en productieomgeving (OTAP) een vereiste. Wijzigingen voor de productiefase worden getoetst aan een pakket van eisen van de businesseigenaar en de wensen van gebruikers. In legacysystemen is het systeemontwerp soms weinig gestructureerd en is het niet ongebruikelijk dat delen van de businessfunctionali teit hard gecodeerd in de software zijn vastgelegd. Wanneer er niet voldoende kennis of documentatie van het ontwerp en de functio naliteit van de applicatie aanwezig is, neemt het vermogen tot aanpassing van de applicatie af en komt het herstellend vermogen bij verstoringen in gevaar.

1. Ontwikkeling 1 2 3 4 5 1.1 In hoeverre zijn door leveranciers bij de ontwikkeling actief ondersteunde of breed geaccepteerde componenten voor het systeem gebruikt? Denk daarbij aan applicatiesoftware, clientsoftware, besturingssystemen, servers, databases, middleware, netwerken embedded componenten. 1.2 In welke mate beschikt de organisatie nu en in de nabije toekomst over deskundigen met de benodigde kennis om de voor het systeem gebruikte componenten te onderhouden of te laten houden onderhouden? Denk hierbij aan kennis over de programmeeromgeving, operating systemen, broncodes, testplannen en proces- en organisatiekennis. 1.3 In hoeverre is er een OTAP-omgeving beschikbaar waar systeemwijzigingen aangebracht, getest en geaccepteerd worden en op gecontroleerde wijze in productie kunnen worden genomen? 1.4 In hoeverre is er toegang tot actueel onderhouden documentatie aangaande het systeemontwerp, wijzigingenhistorie, de implementatie, de businessfunctionaliteit, procesmodellen en de gebruikte algoritmen? 16

Bij legacysystemen sluit het eigenaarschap en het beheer niet altijd aan op de vastgestelde processen en procedures. Voor het uitvoeren van governance en beheer is het noodzakelijk dat de hiervoor benodigde taken, rollen en bevoegdheden eenduidig belegd zijn binnen de eigen organisatie en dat hierover, zo nodig, goede afspraken zijn gemaakt met de leverancier. Daarnaast is het zo dat naarmate een systeem langer in gebruik is, de aanwezige kennis over een systeem en eerdere incidenten en problemen kan verdwijnen. Specialisten verlaten de organisatie en er vindt niet voldoende kennisoverdracht of nieuwe kennisopbouw plaats. Dit kan ook het geval zijn bij de leverancier. Hierdoor neemt het herstellend vermogen en de weerbaarheid van een systeem af. Wanneer de beschikbare beheerkennis bij specialisten afneemt, neemt het belang van voldoende en actuele documentatie alleen maar toe. Daarnaast is het aanwezig zijn van de vereiste documenta tie een goede indicator van de kwaliteit van het beheer.

2. Governance 1 2 3 4 5 2.1 In hoeverre zijn taken, rollen en verantwoorde lijkheden met betrekking tot het systeem belegd? 2.2 In hoeverre is het eigenaarschap van het systeem belegd? 2.3 In hoeverre vindt er door de onderhoudsexperts gestructureerde managementrapportage over de kwaliteit van het systeem aan de systeemeigenaar plaats en vindt de besluitvorming over het systeem op gestructureerde wijze plaats?


Lifecyclemanagement

Beheer

Het is van belang om continu kritisch te kijken naar de legacy systemen binnen de organisatie en zorg te dragen voor een goed doordachte, systematische planning en lifecyclemanagement. Zeker bij legacysystemen is monitoring van essentieel belang. Als het niet meer mogelijk is om een systeem op goede wijze te monitoren, dan neemt het zicht op de veiligheid af.

Zoals bij Governance is aangegeven, kan de kennis over het systeem verwateren naarmate een systeem langer in gebruik is. Dit kan zowel binnen de eigen organisatie als bij de leverancier gebeuren. Hierdoor neemt het herstellend vermogen en de weerbaarheid af. Wanneer de beschikbare beheerkennis bij specialisten afneemt, neemt het belang van voldoende en actuele documentatie alleen maar toe. Daarnaast is het aanwezig zijn van de vereiste documenta tie een goede indicator van de kwaliteit van het beheer. Van belang is hierbij een goede afstemming tussen de operationele beheerta ken en de tactische beheertaken.

3. Lifecyclemanagement 1 2 3 4 5 3.1 In hoeverre zijn de kwetsbaarheden van het systeem periodiek in beeld gebracht?

5. Beheer 1 2345

3.2 In hoeverre zijn de bedrijfskritische onderdelen van het systeem bekend?

5.1 In hoeverre worden functionele en technische beheerprocessen conform overeengekomen serviceniveaus uitgevoerd?

3.3 In hoeverre bestaat er een systematisch lifecyclemanagementproces met betrekking tot het systeem?

5.2 In hoeverre is de benodigde kennis nu en in de nabije toekomst beschikbaar, bij eigen personeel of bij de leverancier, voor het plegen van onderhoud aan het systeem en het herstellen van problemen?

3.4 In hoeverre kunnen de prestaties van de infrastructuur en de betrouwbare werking van de applicatie op adequate wijze worden gemonitord? Denk daarbij aan monitoring van de performance, incidenten, security issues en dergelijke.

5.3 In hoeverre zijn er draaiboeken en noodplannen in het geval zich incidenten voordoen?

Incidenten Het aantal incidenten dat zich inmiddels heeft voorgedaan bij het systeem, geeft een indicatie over de betrouwbare werking van dat systeem. Dit neemt niet weg dat ook een systeem waar zich geen eerdere incidenten hebben voorgedaan ineens kan falen.

4. Incidenten 1 2 3 4 5 4.1 In hoeverre heeft het systeem de afgelopen jaren gewerkt zonder grote verstoringen van de bedrijfsprocessen? 4.2 In hoeverre heeft het systeem de afgelopen jaren gewerkt zonder grote technische incidenten? 4.3 In hoeverre heeft het systeem de afgelopen jaren gewerkt zonder grote security-incidenten?

5.4 In hoeverre zijn de draaiboeken en noodplannen getest? 5.5 In hoeverre is er actuele documentatie voor beheer aanwezig aangaande de systeemconfiguratie, de bedieningsprocedures en de gebruikte protocollen en technologieën? 5.6 In hoeverre zijn beheerders zich bewust van de kwetsbaarheid van het legacysysteem en wordt daar door het management op gestuurd?

Wijzigingen Het aantal wijzigingen in een systeem en de mate waarin een systeem wordt gebruikt waarvoor het ooit bedoeld is, zegt iets over kwetsbaarheid. Regulier (adaptief en correctief ) onderhoud verlaagt de kwetsbaarheid van het systeem. Grootschalige aanpassingen en het toevoegen van extra functionaliteiten waar het systeem niet voor gemaakt is en niet op berekend is kan de kwetsbaarheid verhogen.

6. Wijzigingen 1 2 3 4 5 6.1 In hoeverre heeft regulier onderhoud op het systeem plaatsgevonden?

17


Externe ondersteuning Hoe afhankelijker een systeem is van externe partijen (leveranciers of ICT-dienstverleners), hoe beter de afspraken moeten zijn over onderhoud en beheer. Deze afspraken liggen meestal vast in een Service Level Agreement (SLA) en een Dossier van Afspraken en Procedures (DAP). Afspraken gelden met name voor het tijdig oplossen van beveiligingslekken en het snel reageren op kritische en beveiligingsincidenten. Wanneer de ondersteuning van het systeem door de externe partijen wegvalt ontstaat er vanzelfspre kend een kwetsbare situatie.

8. Beveiliging 1 2 3 4 5 8.1 In hoeverre is in het systeemontwerp rekening gehouden met beveiligingsprincipes (security by design)?

7. Externe ondersteuning 1 2 3 4 5 7.1 In hoeverre zijn duidelijke afspraken over beheer, ondersteuning, reparatie etc. gemaakt met externe leveranciers? 7.2 In hoeverre zijn afspraken gemaakt over de ondersteuning van het systeem in de toekomst?

Beveiliging Onderdelen van systemen die via een intranet of het internet te benaderen zijn, dienen regelmatig onderzocht te worden op kwetsbaarheden. Het inventariseren van kwetsbaarheden in de beveiliging vergt diepgaande specialistische kennis van zowel informatiebeveiliging als van de gebruikte protocollen, technolo gieën en algoritmen. Wanneer het systeem kwetsbaarheden in de beveiliging bevat, dienen deze spoedig gerepareerd te worden middels patches of systeemaanpassingen. Naarmate de tijd verstrijkt, verouderen beveiligingsalgoritmen, protocollen en technologieën of worden er onoplosbare kwetsbaar heden gevonden. Zo werd bijvoorbeeld het hashing-algoritme MD5 medio jaren negentig nog breed toegepast, maar wordt dit u afgeraden. Wanneer een systeem dateert uit het pre-cybercrime tijdperk, is er tijdens het ontwerp en implementatie niet bewust rekening gehouden met actuele aanvalsmethodieken en vectoren. Denk hierbij aan zaken als injectie van malware op de client, man-in-themiddle-aanvallen, SQL-injectie, en dergelijke. Legacysystemen missen soms de technische mogelijkheden om aan te sluiten bij een moderne beveiligingsarchitectuur. Hierdoor is het systeem mogelijk niet aangesloten op een single-sign-on (SSO) infrastructuur, ontbreken de mogelijkheden voor tweefactorauthenticatie of wordt er op onveilige wijze toegang op afstand verleend.

18

Voor beveiliging van gevoelige informatie tijdens transport of in opslag, dient mogelijk encryptie te worden toegepast. Als een legacysysteem al encryptiemogelijkheden biedt, bestaat de kans dat de geboden technologie, algoritmen of de gebruikte sleutellengtes in de huidige tijd niet meer volstaan voor een afdoende beveiliging.

8.2 In hoeverre wordt het systeem onderzocht op generieke en systeemspecifieke kwetsbaarheden in de beveiliging? 8.3 In hoeverre zijn de aangetroffen kwetsbaarheden in de beveiliging gemitigeerd? 8.4 In hoeverre worden externe bronnen geraadpleegd om beveiligingsissues te weten te komen? 8.5 In hoeverre wordt tijdig gerapporteerd over kwetsbaarheden in de beveiliging? 8.6 I n hoeverre zijn veilige protocollen, technologieën of algoritmen toegepast? 8.7 In hoeverre is het systeem vrij van programmeertalen die nauwelijks nog door marktpartijen worden ondersteund? 8.8 In hoeverre is het systeem over de tijd gemoderniseerd met beveiligingsmaatregelen tegen actuele aanvallen, die ten tijde van de bouw mogelijk nog niet gangbaar waren? 8.9 In hoeverre biedt het systeem voldoende functionele en technische mogelijkheden voor veilige toegangsverlening aan andere systemen, gebruikers en beheerders? 8.10 In hoeverre ondersteunt het systeem industriestandaardencryptie of PKI voor veilige opslag van gevoelige bedrijfsinformatie? 8.11 In hoeverre ondersteunt het systeem industriestandaardencryptie of PKI voor veilige transmissie van gevoelige bedrijfsinformatie?


Koppelingen De mate waarin het systeem wordt blootgesteld aan dreigingen is in belangrijke mate afhankelijk van de koppelingen die het systeem via netwerken heeft met andere systemen, met beheerders en gebrui kers en eventueel ook leveranciers of andere externe organisaties. Hoewel het gebruik van internet voor een of meerdere van deze koppelingen het dreigingsniveau aanzienlijk doet toenemen, kunnen ook interne koppelingen en koppelingen met andere organisatie bedreigingen vormen. Toegang tot het systeem via de diverse koppelingen moet zo veel mogelijk beperkt worden tot uitsluitend die gebruikers en systemen waarvoor de koppeling bedoeld is. Gebruikers van de koppelingen dienen zich te authentiseren en het netwerkverkeer over de koppeling dient beveiligd te zijn tegen ongewenste modificatie of afluisteren. Tevens dient de beschikbaarheid van de koppelingen beschermd te zijn tegen uitval van netwerkcomponenten en eventuele aanvallen gericht op de beschikbaarheid van het systeem. Legacysystemen missen soms de technische mogelijkheden om aan te sluiten bij een moderne beveiligingsarchitectuur. Hierdoor is het systeem mogelijk niet aangesloten op een single-sign-on (SSO) infrastructuur of ontbreken de mogelijkheden voor tweefactorauthen ticatie en/of client-serverauthenticatie. Ook is er mogelijk geen veilig transmissieprotocol voorhanden voor het versleutelen van netwerkver keer dat over publieke of semipublieke netwerken verzonden wordt of wordt er op onveilige wijze toegang voor beheer op afstand verleend. Bij een legacysysteem is er tijdens het ontwerp en implementatie mogelijk geen rekening gehouden met de actuele cybercrime-aanvallen. Denk hierbij aan zaken als injectie van malware op de client, man-in-themiddle-aanvallen, SQL-injectie of denial-of-service-aanvallen.

1 2 3 4 5

9.2 In hoeverre worden koppelingen met andere systemen of sensoren/PLC’s tot stand gebracht op basis van geauthentiseerde verbindingen (client- of client-serverauthenticatie)? 9.3 In hoeverre is benodigde telecommunicatie over publieke of semipublieke netwerken (sensornetwerken of apparatuur aansturing over TCP/IP, X.25, telefonie, gsm, etc.) beschermd tegen ongeautoriseerde toegang? (VPN’s, APN’s, authenticatie, encryptie)

9.5 In hoeverre vindt toegang tot het systeem door beheerders plaats over een van het gebruikersnetwerk gescheiden beheernetwerk (trusted path, out-of-band beheer)? 9.6 In hoeverre vindt toegang door beheerders plaats op basis van tweefactorauthenticatie? 9.7 In hoeverre vindt beheer op afstand (remote access) door beheerders en/of door leveranciers plaats op basis van tweefactorauthenticatie en versleutelde verbindingen? 9.8 In hoeverre zijn er beperkingen in de tijd en in de verleende autorisaties aangebracht voor beheer op afstand door leveranciers? 9.9 In hoeverre wordt het netwerktoegangspad tot het systeem voor gebruikers, andere systemen of sensoren/PLC’s expliciet beperkt tot de daadwerkelijk bedoelde koppelingen? 9.10 In hoeverre biedt het systeem voldoende functionele en technische mogelijkheden voor een veilige toegangsverlening aan gebruikers, andere systemen of sensoren/PLC’s? 9. 11 In hoeverre wordt toegang tot het systeem gemonitord om kwaadaardige toegangspogingen en ongeautoriseerde toegang tijdig te onderkennen (SIEM, IDS/IPS)? 9.12 In hoeverre ondersteunt het systeem industriestandaardencryptie of PKI voor veilige transmissie van gevoelige informatie?

9. Koppelingen 9.1 In hoeverre is het systeem afgeschermd van publieke of semipublieke netwerken bijvoorbeeld door apparatuur die in een DMZ is geplaatst (firewalls, webserver)?

9.4 In hoeverre worden authenticatietokens (wachtwoorden, pass phrases, etc.) die gebruikt worden voor de koppelingen met andere systemen of sensoren/PLC’s periodiek gewijzigd?

9.13 In hoeverre is het systeem gemoderniseerd met beveiligingsmaatregelen tegen actuele aanvallen, die ten tijde van de bouw mogelijk nog niet gangbaar waren? 9.14 In hoeverre zijn de toegangspaden naar het systeem, voor zowel beheer als voor gebruik, ontdaan van single-points-of-failure in de netwerkinfrastructuur? 9.15 In hoeverre is het toegangspad voor gebruikers bestand tegen aanvallen vanaf publieke netwerken, gericht op de beschikbaarheid van het systeem (denail-of-service-aanvallen)?

19


Uniciteit Enkelvoudig uitgevoerde (unieke) systemen zijn vatbaarder voor dreigingen en kwetsbaarheden. Er is bij enkelvoudige systemen vaak onvoldoende redundantie en externe ondersteuning beschik baar. Redundantie van het systeem (‘dubbel uitvoeren’) of alterna tieve werkwijzen en ‘workarounds’ in de bedrijfsprocessen wanneer het systeem uitvalt kunnen de afhankelijkheid in de organisatie van het systeem beperken. Zeker als het gaat om PLC’s (Programmable Logic Controllers), embedded en/of procesbesturingssystemen (ICS/SCADA) in de industrie is er vaak geen uitwijk mogelijk (immers: één onderdeel met één proces). Daarnaast is het uitvoeren van ketentesten zeer complex bij dergelijke systemen: legacysoftware gedraagt zich onvoorspelbaar als het wordt geconfronteerd met nieuwe testtechnieken, met als risico dat het systeem (onherstelbaar) beschadigd wordt.

10. Uniciteit van het systeem 1 2 3 4 5 10.1 In hoeverre bestaan er alternatieve werkwijzen in de bedrijfsprocessen wanneer het systeem uitvalt? 10.2 In hoeverre is het systeem redundant uitgevoerd?

Client Wanneer de serverlogincredentials op de client opgeslagen worden, hetgeen in legacy systemen niet ongebruikelijk is, bestaat de kans dat deze credentials worden ontvreemd en misbruikt worden voor ongeautoriseerde toegang tot de server. Daarnaast is het in legacysystemen niet ongebruikelijk dat er, bijvoorbeeld om performanceredenen, (gevoelige) bedrijfsinforma tie op de client word opgeslagen. Wanneer deze clientomgeving niet afdoende beveiligd is of bijvoorbeeld middels een verloren of gestolen laptop buiten de invloed van de organisatie raakt, bestaat het risico van informatielekkage. Wanneer de client ontworpen, gebouwd en geïmplementeerd is zonder specifieke aandacht voor “veilig programmeren”, kan er mogelijk, middels aanvallen op bijvoorbeeld de gebruikersinter face, ongeautoriseerde toegang verkregen worden tot bedrijfsinfor matie in het systeem. Bij het ontwerp en de bouw van de client dienen de in de industrie bekende programmeerfouten (zoals bijvoorbeeld beschreven in SANS 25) die kwetsbaarheden kunnen veroorzaken vermeden te worden en dient de gebruikersinterface getest te worden op het weerstaan van de aanvallen gebaseerd op in de industrie bekende kwetsbaarheden (zoals onder andere beschreven in OWASP 10). Wanneer er voor de toegangsbeheersing tot bedrijfsinformatie wordt vertrouwd op beveiligingsmaatregelen in de clientsoftware, dan dient voorkomen te worden dat er toegang tot de server verkregen kan worden met andere tools of software 20

dan de bedoelde clientsoftware. Denk aan zaken als aangepaste clientsoftware, SQL-interfaces of terminal emulatieprogramma’s.

11. Client 1 2 3 4 5 11.1 In hoeverre is het ontwerp zodanig dat er op de client geen serverlogincredentials opgeslagen kunnen worden? 11.2 In hoeverre is de clientomgeving na gebruik weer geheel vrij van vertrouwelijke bedrijfsinformatie? 11.3 In hoeverre is de applicatie beschermd tegen recente kwetsbaarheden zoals verwoord in de industriestandaarden voor kwetsbaarheden? 11.4 In hoeverre zijn er maatregelen getroffen om toegang tot de applicatie middels ongeautoriseerde clientsoftware of -tools te voorkomen?

Autorisatiemodel applicatie Het aanwezige autorisatiemodel dient te voorzien in implementatie van het “need-to-know” principe. Dit principe houdt in dat iedere gebruiker toegang krijgt tot die informatie die nodig is voor de uitvoering van taken en niet meer dan dat. In legacyapplicaties is het aanwezige autorisatiemodel niet altijd voldoende fijnmazig om dit principe te kunnen realiseren. Daarnaast zijn soms, om de beheerinspanning te beperken, niet alle aanwezige mogelijkheden in het autorisatiemodel benut om tot een voldoende fijnmazige inrichting van de autorisaties te komen. Voorts is het in legacysystemen niet ongebruikelijk dat er voor toegang tot de database volledig wordt vertrouwd op de aanwezige beveiligingsmaatregelen in de client of de applicatie. Hierdoor kan er mogelijk buiten de applicatie om directe toegang tot de database verkregen worden. Wanneer de programmabibliotheken waar de applicatie uit opgebouwd is niet afdoende beveiligd zijn tegen ongeautoriseerde aanpassingen, kunnen de applicatiefunctionaliteit en eventuele beveiligingsmaatregelen ongewild aangepast worden, waardoor inbreuken op de beveiliging kunnen optreden.


13. Systeemsoftware

12. Applicatie 1 2 3 4 5 12.1 In hoeverre is de benodigde fijnmazigheid in het autorisatiemodel (bijvoorbeeld een userID per gebruiker en differentiatie in autorisatieniveaus binnen de applicatie of ‘role based access control’) aanwezig voor implementatie van het “need-to-know” principe? 12.2 In hoeverre is het onder 12.1 genoemde “need-to-know” principe geïmplementeerd? 12.3 In hoeverre zijn er maatregelen getroffen waardoor uitsluitend via de client- en applicatiesoftware toegang tot de database verkregen kan worden en zijn toegangsmogelijkheden via het besturingssysteem afgegrendeld? 12.4 In hoeverre worden de programmabibliotheken waar de applicatie uit is opgebouwd beveiligd tegen ongeautoriseerde of onbedoelde aanpassingen? 12.5 In hoeverre worden veilige beheermechanismen gebruikt voor externe toegang tot de applicatie door leveranciers?

Systeemsoftware, zoals besturingssystemen, middleware, databases Wanneer legacysysteemsoftware vereist is voor het functioneren van het systeem, worden kwetsbaarheden in de beveiliging van deze systeemsoftware mogelijk niet meer (tijdig) gerepareerd. Hierdoor zal de mate van kwetsbaarheid van het systeem als geheel over de tijd toenemen. Wanneer de bedrijfsinformatie op het niveau van de systeemsoftware niet specifiek is afgeschermd van ongeautoriseerde toegang, bestaat het risico van ongeautoriseerde toegang tot bedrijfsinformatie vanuit de beheer- of systeemomgeving. Onder systeemsoftware wordt hierbij software verstaan als besturingssystemen, databases, middleware enzovoorts. In sommige legacysysteemsoftware zijn de mogelijkheden voor toegangsbeheersing tot het “file system” en het “job entry system” niet optimaal of lastig te configureren. Hierdoor ontstaat het risico van ongeautoriseerde toegang op bestandsniveau of kunnen ongeautoriseerde processen gestart worden.

1 2 3 4 5 13.1 In hoeverre worden bekende kwetsbaarheden voor de systeemsoftware tijdig gerepareerd door de leverancier? 13.2 In hoeverre worden gerepareerde kwetsbaarheden tijdig geïmplementeerd in de productieomgeving? 13.3 In hoeverre is toegangsbeheersing ook op het niveau van het systeemsoftware geïmplementeerd, waardoor bedrijfsinformatie ook op systeemniveau is afgeschermd? 13.4 In hoeverre zijn het file system en het job entry system beveiligd tegen ongeautoriseerde toegang of gebruik?

Hardware Wanneer de hardware vanwege kostenafwegingen of vanwege een beperkte beschikbaarheid van vervangende hardware niet tijdig vervangen wordt, ontstaan risico’s ten aanzien van de beschikbaar heid van het systeem. En wanneer er sprake is van beperkte beschikbaarheid van vervangende hardware of de benodigde hardware geheel niet meer leverbaar is, ontstaan risico’s ten aanzien van de continuïteit van het systeem. Voorts bestaat de mogelijkheid dat er ten tijde van bouw voor de beveiliging is vertrouwd op aanwezige hardwarematige of infra structurele voorzieningen, die inmiddels gewijzigd zijn waardoor eerdere aannames aangaande de beveiliging niet meer valide zijn. Zo kan er bijvoorbeeld ooit vertrouwd zijn op een fysieke verbinding met een domme terminal, maar is het systeem inmiddels via een ip-koppeling op het netwerk beschikbaar gemaakt.

14. Hardware 1 2 3 4 5 14.1 In hoeverre wordt de voor het systeem gebruikte hardware, binnen de verwachte technische levensduur, vervangen door nieuwe hardware? 14.2 In hoeverre is er nog voldoende vervangende hardware voor het systeem beschikbaar? 14.3 In hoeverre kan deze vervangende hardware na uitval tijdig verkregen worden? 14.4 In hoeverre is de beveiliging van het systeem getest na grote infrastructurele aanpassingen?

21


1.5 Bepalen veiligheidsprofiel Op basis van de bovenstaande vragen kunt u een samengevat en overzichtelijk beeld schetsen van het veiligheidsprofiel van een systeem om het (senior) management te informeren. Dit kunt u doen door middel van het opstellen van een zogenaamd radardia gram. Voor ieder van de 14 onderdelen van het veiligheidsprofiel kunnen de scores op de verschillende vragen gemiddeld worden. Hierdoor ontstaat per onderdeel een totaalscore tussen 1 en 5. Vanzelfsprekend wegen niet alle onderdelen van het veiligheids profiel even zwaar. De organisatie staat vrij om zelf wegingsfactoren voor de verschillende onderdelen aan te geven. Deze wegings factoren werken vervolgens door in de score op het radardiagram. Op het moment dat uit het radardiagram blijkt dat u op meerdere onderdelen een score behaalt van 3 of lager dan is het raadzaam te overwegen de veiligheid van het systeem te verbeteren. Indien slechts op één of enkele onderdelen een kwetsbaarheid is aange troffen, dan verdient het aanbeveling de aandacht te concentreren op deze onderdelen en daar gerichte verbeteringen in aan te brengen. Een kwetsbaarheid in één of enkele onderdelen van het systeem hoeft immers nog niet te betekenen dat het gehele systeem kwetsbaar is. Hoe lager de veiligheid van het systeem, hoe groter de kans op het optreden van een verstoring. Het radardiagram kan de volgende vorm hebben.

Hardware Systeemsoftware Applicatie

Ontwikkeling 5 4 3 2 1 0

Client

Koppelingen

Lifecycle management

Lifecycle management Incident Management

Beperkt

Beheer procedures

Voorbeeld veiligheid systeem

Wijziging management

Uniciteit

overnance

Governance

Externe ondersteuning Beveiliging

Incident Management

Beperkt

Beheer procedures

Voorbeeld veiligheid systeem

Wijziging management

terne ondersteuning

22

Ruim voldoende

Ruim voldoende


Onderdeel 2 Impact van verstoringen Voor de vraag in hoeverre de onveiligheden van een systeem een risico opleveren is tevens de vraag van belang welke maximale impact een verstoring van het systeem heeft op de maatschappij. Daarom kijken we in dit onderdeel naar de impact van verstoring van het systeem. De exacte aanleiding voor deze verstoring doet wat dit betreft niet ter zake. We gaan uit van een ‘all hazard benadering’, waarbij alleen de maximale impact voor de maatschappij wordt bezien. Bij de beantwoording van de vragen kunt u dan ook voor het gemak uitgaan van volledige uitval of grootste inbreuk op de vertrouwelijkheid of integriteit. Met dit onderdeel van het self-assessment kunt u het geheel van effecten inschatten, inclusief de effecten op andere ICT-systemen, de rest van de eigen organisatie, de directe impact op de maatschap pij en keteneffecten op andere organisaties. Bij een backendsysteem lijkt de directe impact van een verstoring op de buitenwereld op het eerste gezicht beperkt. Om de impact van een dergelijk systeem in te schatten kunt u bij de beantwoording van deze vragen het ‘dominoeffect’ meenemen. Schat hierbij in wat de schadelijke impact is van aantasting van andere (ICT-)systemen als direct en onvermijdelijk gevolg van aantasting van het onderzochte legacysysteem. Bij het invullen van dit onderdeel van het self-assessment kan informatie nodig zijn van de businessafdeling van uw organisatie.

Kosten van gevolgschade Aantasting van een systeem kan gevolgschade met zich mee brengen, zowel voor de organisatie zelf als voor de maatschappij. Volledige uitval (landelijk) van een vitaal systeem kan leiden tot flinke financiële schade bij de organisatie en zelfs tot faillissement, met alle gevolgen van dien. Ook kan uitval leiden tot schadeclaims van gebruikers (burgers). Bij deze vraag wordt gekeken naar de geschatte kosten van volledige uitval van het systeem.

15. Kosten van gevolgschade 1 2 3 4 5 15.1 Hoe hoog zijn de kosten van de gevolgschade van het uitvallen van het systeem? De scores hebben de volgende betekenis: 1: > 500 miljoen euro 2: 50 miljoen euro – 500 miljoen euro 3: 5 – 50 miljoen euro 4: 0,5 – 5 miljoen euro 5: < 0,5 miljoen euro

Vragen De maximale impact van een verstoring kan bestaan uit verschil lende factoren. Voor dit self-assessment zijn deze factoren vertaald naar de onderstaande vragen. Deze vragen zijn gecategoriseerd naar onderwerp. Hoe lager de score op een vraag is, hoe groter het belang van het systeem en hoe groter de impact bij een verstoring.

23

ncsc | Onderdeel 2 - Impact van verstoringen

Verstoring dagelijks leven

Doden en gewonden

Hierbij moet worden gekeken hoeveel en voor hoe lang eigen medewerkers of burgers in de samenleving ernstig worden gestoord om hun normale activiteiten te ondernemen. Daarbij kan worden gedacht aan het kunnen werken binnen de vitale organisatie die het betreft, naar werk of naar school gaan, telefoneren, internet gebruiken.

Hierbij wordt gekeken naar in welke mate bij verstoringen van een systeem doden of gewonden vallen. Denk hierbij bijvoorbeeld aan de gevolgen die zich kunnen voordoen bij verstoringen van systemen bij kerncentrales, vergiftiging van het drinkwater door moedwillige verstoringen in de waterzuivering etc.

18. Doden en gewonden

16. Verstoring dagelijks leven

1 2 3 4 5 1 2 3 4 5

16.1 Hoeveel en voor hoe lang worden eigen medewerkers of burgers in de samenleving gestoord bij het ondernemen van hun normale activiteiten?

18.1 In welke mate vallen er door de verstoring van het systeem doden en gewonden? De scores hebben de volgende betekenis: 1: > 100 2: 50-100 3: 10-50 4: < 10 5: geen

De scores hebben de volgende betekenis: 1: > 10.000 mensen, 1 week 2: 1.000 mensen, 1 dag – 10.000 mensen, 1 week 3: 100 mensen, 1 uur – 1.000 mensen, 1 dag 4: 10 mensen, 1 minuut – 100 mensen, 1 uur 5: < 10 mensen, 1 minuut

Samengevat beeld van de impact

De genoemde grenswaarden kunnen ook als één getal worden uitgedrukt. Bijvoorbeeld: 10.000 mensen 1 week (7 dagen) is 70.000 ‘mensdagen’. Met een impact van 7.000 mensen voor 10 dagen wordt dan dezelfde score behaald.

Maatschappelijke onrust Hierbij wordt gekeken naar in welke mate en hoe lang Nederlanders boos of bang zijn. Hierbij kan ook worden gekeken naar (ernstige) aantasting van het vertrouwen in de organisatie. Denk hierbij bijvoorbeeld aan het door hacks verliezen van data en ernstige schendingen van privacy van burgers.

Op basis van de bovenstaande vragen kunt u een samengevat beeld schetsen van de impact van een verstoring van het systeem om het senior management te informeren. Voor ieder van de 4 factoren om de impact te bepalen kunnen de scores op de verschillende vragen gemiddeld worden. Hierdoor ontstaat per onderdeel een totaalscore tussen 1 en 5. Het resultaat kunt u invullen in een zogenaamd radardiagram. Het radardiagram kan de volgende vorm hebben.

Impact van verstoringen

17. Maatschappelijke onrust 1 2 3 4 5 17.1 In welke mate en hoe lang zijn Nederlanders boos of bang?

Doden en gewonden

De scores hebben de volgende betekenis: 1: > 10.000 mensen, 1 week 2: 1.000 mensen, 1 uur – 10.000 mensen, 1 week 3: 100 mensen, 10 minuten – 1.000 mensen, 1 uur 4: 10 mensen, 1 minuut – 100 mensen, 10 minuten 5: < 10 mensen, 1 minuut

Kosten gevolgschade 5 4 3 2 1 0

Voorbeelds Hoog

Kosten gevolgschade 5 De genoemde grenswaarden kunnen ook als één getal worden uitgedrukt. 4 Met een Bijvoorbeeld: 10.000 mensen 1 week (7 dagen) is 70.000 ‘mensdagen’. impact van 7.000 mensen voor 10 dagen wordt dan dezelfde score 3behaald. 2 1 Doden en 0 gewonden

Maatschappelijke onrust

Beperkt Verstoring dagelijks leven

Voorbeeldscore Hoog

24

Beperkt Verstoring dagelijks leven

Maatschappelijke onrust


Onderdeel 3 Risicoprofiel en risicomitigatie 3.1 Inleiding Dit onderdeel geeft u een handreiking voor het bepalen van het risicoprofiel van het systeem en het bepalen van mogelijke strategieën voor het verminderen van het risico.

3.2 Bepalen risicoprofiel Op basis van de scores op de onderdelen van het veiligheidsprofiel kan een gemiddeld overall risicoprofiel van het legacysysteem opgesteld worden. Niet alle onderdelen uit het veiligheidsprofiel wegen even zwaar. De organisatie staat vrij om zelf wegingsfactoren toe te voegen. Deze wegingsfactoren werken vervolgens door in de gemiddelde totaalscore. Ook kan een gemiddelde totaalscore voor de impact van aantasting van het systeem opgesteld worden. De totaalscore voor het veiligheidsprofiel van systeem kan zijn: 1. Niet/onbekend 2. Zeer beperkt 3. Beperkt 4. Voldoende 5. Ruim voldoende/ niet relevant De totaalscore voor de impact van verstoring van het systeem kan variëren van: 1. Hoog tot 5. Beperkt Deze scores kunnen geplot worden op onderstaand schema, waardoor een overall risicoprofiel van het legacysysteem ontstaat, waarbij een hoge score op veiligheid en impact leidt tot een laag (L) of zeer laag (ZL) risicoprofiel en een lage score tot een hoog (H) of een zeer hoog (ZH) risicoprofiel.

Risicoprofiel legacysysteem Impact 5

M

L

L

ZL

ZL

4

M

M

L

L

ZL

3

H

M

M

L

L

2

H

H

M

M

L

1

ZH

H

H

M

M

1

2

3

4

5

Veiligheid

Op basis van het resulterende profiel kunt u bepalen of het aangetroffen risico beperkt dient te worden. Als het risico laag is of er een nieuwe versie of een vervanger van het systeem verwacht wordt dan kan het risico geaccepteerd worden. Overwegingen die daarbij een rol spelen zijn: • Is het maatschappelijk verantwoord en aanvaardbaar om het risico te accepteren? • Valt het risico binnen de grenzen van een wettelijke verplichting? • Kan het risico met voldoende mandaat geaccepteerd worden? • Zijn er voldoende financiële reserves om eventueel op incidenten te reageren? • Vindt er formele vastlegging en periodieke heroverweging van het risico plaats? Als het risico acceptabel is, is het niet noodzakelijk om mitigerende acties te (laten) nemen. Hierbij is het wel zaak om het risico door de verantwoordelijke leiding te laten vastleggen en accepteren (accountability) en vervolgens continu te monitoren. Het is raadzaam om de (management)aandacht voor het systeem te verhogen, waardoor het systeem vaker wordt meegenomen in rapportages, onderzoeken, beheerbudgetten, overleggen etc. Bij een hoog of zeer hoog risico zullen mitigatiestrategieën 25

ncsc | Onderdeel 2 - Impact van verstoringen

toegepast moeten worden. Dit is een managementafweging, waarbij naast een inschatting van het risico tevens bepaald wordt in welke mate het risico als acceptabel wordt gezien en welke kosten gemaakt kunnen worden om de risico’s te mitigeren.

3.3 Mogelijke mitigatiestrategieën De onderstaande strategieën zijn voor legacysystemen denkbaar, al kunnen sommige niet passen bij het specifieke systeem dat wordt bekeken. De strategieën staan gerangschikt van minst ingrijpend naar meest ingrijpend, waarschijnlijk ook in volgorde van oplopende kosten en van op korte termijn tot slechts op langere termijn te realiseren. Bij alle mitigatiestrategieën zal bepaald moeten worden hoeveel de desbetreffende strategie bijdraagt aan het verminderen van de risico’s en welke kosten daarvoor redelijker wijs gemaakt kunnen worden.

Detectie Wanneer een formele acceptatie van het risico geen optie is of wanneer dit om andere redenen niet wenselijk is, dan kan door aanvullende detectiemaatregelen sneller gereageerd worden op verstoringen. Denk hierbij aan actieve, softwarematige monitoring van het systeem om tijdig incidenten te onderkennen.

Beheer Verder kunt u de kans op incidenten verminderen door een aantal randvoorwaardelijke en beheersmatige zaken op orde te brengen en te houden. Denk hierbij aan zaken als: • Kennis – Voer een beleid gericht op het opbouwen of het behoud van kennis van het legacysysteem en de gebruikte technologieën. Koester de mensen die deze kennis nog bezitten, zorg voor een tijdige overdracht en vastlegging van deze kennis en neem zo nodig mensen die deze kennis (nog) bezitten (opnieuw) in dienst. Als u het beheer heeft uitbesteed, zult u nog steeds veel over het systeem moeten weten. Dit zowel om adequaat te reageren op incidenten als om bij verdere ontwikkeling of vervanging van het systeem op veiligheid te kunnen sturen. • Ondersteuning – Communiceer proactief met uw leverancier over de periode waarover u nog ondersteuning van het systeem en de gebruikte technologieën mag verwachten en maak hier goede afspraken over. Stel u op de hoogte van de bij de leveran cier nog aanwezige kennis en de kwaliteit van de ondersteuning die u nog geboden wordt. • Eigenaarschap – Zorg voor eigenaarschap in de business, in de vorm van een verantwoordelijke functionaris die toezicht houdt op de beheerprocessen, waaronder change-, configuratie-, incidenten patchmanagement. • Business – IT afstemming – Zorg ervoor dat verdere ontwikke ling en gebruik van het systeem goed worden meegenomen in de ontwikkeling van plannen en besluitvorming van de business afdelingen, andere IT-projecten, het (senior) management etc. Voorkom dat het systeem onveiliger wordt door omgevingsveranderingen.

26

Respons Het risico kunt u tevens verminderen door u goed voor te bereiden op een adequate incidentrespons. Denk hierbij aan het opstellen van een incidentresponsplan waarin alle belangrijke aspecten zijn geadresseerd, het inrichten van een (virtueel) incidentresponsteam met de benodigde kennis en mandaat en het testen en actueel houden van het responsplan en het oefenen met alle betrokkenen.

Herstel Een andere mogelijkheid is het voorbereiden van de technische randvoorwaarden voor herstel, zoals back-up en restore, reserve hardware, tools om het systeem te benaderen etc. Uiteraard moeten deze indien nodig ook worden gebruikt.

Afschermen Een andere strategie is het inzetten op afscherming van het systeem. Beperk de toegang tot het systeem tot het hoogst noodzakelijke, schakel onnodige functies en poorten op de systemen uit, pas veilige configuratiebaselines toe, breng de laatste patches aan, etc. (hardenen). Daarnaast kunt u de netwerktoegangspaden beperken tot uitsluitend die toegangspaden die nodig zijn voor de legitieme gebruikers van het systeem en deze toegangspaden beschermen middels zaken als ACL’s, firewalls en/of een DMZ.

Opdelen Om de potentiële impact van verstoringen te verkleinen, kunt u het systeem (of delen daarvan) opdelen (zoneren) in afzonderlijke delen.

Beschermen Nog een andere strategie is het verhogen van de bescherming van het systeem. Dit kan op verschillende manieren: • Virtuele patches – Breng extra bescherming aan door upstream in de toegangspaden naar de systemen firewalls en/of gateways op de applicatielaag op te nemen die voor het systeem relevante aanvallen filteren c.q. blokkeren. • Virtualiseren – Migreer het systeem naar een virtuele serverom geving om de afhankelijkheid van specifieke hardware te verminderen. • Isoleren – Scherm het systeem als geheel af door er op applicatie niveau een veilige “wrapper” omheen te bouwen, via welke alle koppelvlakken kunnen verlopen.

Upgraden U kunt ook overwegen het risico te verminderen door vervanging van de kwetsbare operating systemen, protocollen, technologieën en algoritmen en het geschikt maken van de applicatie voor de gemoderniseerde infrastructuur (upgraden). In deze strategie worden delen van het systeem of het hele systeem op een hoger veiligheidsniveau gebracht.

Diversificatie Bij diversificatie gaat het om het aanschaffen van soft- of hardware van andere leveranciers. Dit kan bijvoorbeeld voor Intrusion Detection Systems (IDS) of firewalls. Hoewel het een kostbare strategie is, kan dit de kwetsbaarheid van een systeem verlagen.


Uitfaseren Faseer delen van het systeem uit door de functionaliteit die afhankelijk is van kwetsbare componenten onder te brengen in andere (veilige) systemen.

belang gediend is met het nemen van daadwerkelijke maatregelen om de onveiligheid rondom het legacysysteem weg te nemen. Bij het maken van een afweging kunnen voor het senior management de volgende factoren een rol spelen:

Procesherontwerp

Risico-acceptatie

Herontwerp bedrijfsprocessen zodanig dat de noodzaak voor delen van het systeem komt te vervallen en delen van het systeem uitgezet kunnen worden. Hierbij kan worden gedacht aan het anders uitvoeren van primaire functies van het systeem, maar ook aan het niet meer als deel van het systeem laten uitvoeren van aansturings-, rapportage- of controleprocessen.

Voor het maken van een goede afweging is van belang hoeveel risico de organisatie wil en kan lopen. Bij deze overweging kunnen compliance, media-aandacht bij incidenten, relaties met klanten en afnemers, weten regelgeving en relaties met overheden een rol spelen.

Vervangen

Voor de uitvoering van de strategie moet een realistisch plan en de nodige bemensing beschikbaar zijn.

Bouw het systeem volledig opnieuw op basis van moderne technologie en voorzie het systeem van passende beveiligingsmaat regelen. Naast het vervangen van het systeem kunt u ook delen van het systeem (bijvoorbeeld een bepaalde hardwarelaag) of rand apparatuur vervangen.

3.4 Samengevat beeld van mogelijke strategieën Op basis van de bovenstaande vragen kunt u voor het (senior) management een samengevat beeld schetsen van de mate waarin bepaalde strategieën de risico’s beheersbaar maken en in hoeverre deze maatregelen kostentechnisch interessant zijn. Door bewust over de toepasbaarheid van de strategieën na te denken wordt het voor het (senior) management eenvoudiger om een goede beslissing te nemen over de toekomst van een systeem.

3.5 Managementbeslissing Na de analyses van de risico´s en mitigatiestrategieën van het systeem zullen management en verantwoordelijken binnen de organisatie moeten beslissen wat te doen aan het onveilige legacysysteem. Als de risico’s hoog zijn, dan zal een mitigatie strategie moeten worden gekozen.

Planvorming

Risico van transitie Zo moet ook worden ingeschat wat de risico’s zijn van de transitie, zoals door het aanpassen van hard- en/of software en of deze lager zijn dan de bestaande risico’s van het legacysysteem.

Transitieperiode Welke maatregelen men ook kiest, het senior management moet goed in beeld hebben welke tussentijdse maatregelen getroffen moeten worden tijdens de transitie van de huidige naar de uiteindelijke situatie.

Nieuwe technologieën Een inschatting van de kans dat zich in de toekomst nieuwe technologieën zullen aandienen die makkelijkere strategieën mogelijk maken kan behulpzaam zijn bij de vraag welke maat regelen passend zijn.

Afbouwproces Als verwacht kan worden dat de bedrijfsprocessen die het systeem uitvoert/ondersteunt in de voorzienbare toekomst door de organisatie zullen worden gestopt of afgebouwd, kan dit een reden zijn om ondanks onveiligheid en risico geen vergaande risico beheersingsmaatregelen te nemen.

De eindscores uit de verschillende fasen kunnen worden samen gebracht in een overall beeld voor het senior management om deze beslissing gemakkelijker te maken. Als er sprake is van een hoge mate van onveiligheid, met een grote impact, dan ligt het voor de hand het senior management te adviseren om te besluiten de risicovolle situatie aan te pakken. Men zou moeten overwegen om een plan te maken voor de invoering van de strategie(ën) die de meeste onveiligheid beheersbaar zou(den) maken en kosten technisch interessant zijn. Het (senior) management heeft de verantwoordelijkheid en de middelen om de hele organisatie te sturen. Het zal in een bredere afweging moeten bepalen of het organisatie- en maatschappelijk 27

ncsc | Onderdeel 3 - Risicoprofiel en risicomitigatie

Totstandkoming

Deze self-assessmentmethode is tot stand gekomen onder auspiciën van het Nationaal Cyber Security Centrum in samenwerking met een groot aantal verschillende organisaties.

Nationaal Cyber Security Centrum Het Nationaal Cyber Security Centrum (NCSC) draagt via samen werking tussen bedrijfsleven, overheid en wetenschap bij aan het vergroten van de weerbaarheid van de Nederlandse samenleving in het digitale domein. Het NCSC ondersteunt de Rijksoverheid en organisaties met een vitale functie in de samenleving met het geven van expertise en advies, respons op dreigingen en het versterken van de crisis beheersing. Daarnaast biedt het NCSC informatie en advies voor burger, overheid en bedrijfsleven ten behoeve van bewustwording en preventie. Het NCSC is daarmee het centrale meld- en informatiepunt voor ICT-dreigingen en -veiligheidsincidenten. Het NCSC is een onderdeel van de Directie Cyber Security van de Nationaal Coördinator Terrorismebestrijding en Veiligheid (NCTV). Bij het opstellen van deze methode is samengewerkt met een groot aantal organisaties en experts. Hun bijdragen, inhoudelijke reviews, proefneming tijdens pilots en deelname aan kennissessies hebben samen bijgedragen aan de inhoudelijke kwaliteit van de self-assessmentmethode.

28

Uitgave Nationaal Cyber Security Centrum Postbus 117, 2501 CC Den Haag Turfmarkt 147, 2511 DP Den Haag 070 751 55 55 Meer informatie www.ncsc.nl [email protected] November 2015

Zicht op risico s van legacysystemen. Een self-assessmentmethode om de risico s van (vitale) legacysystemen in kaart te brengen

Recommend Documents