Bij de keuze voor bedrijfsapplicaties zoals inkoopsoftware moeten eisen worden gesteld aan de continuïteit (beschikbaarheid van systemen en gegevens). Het uitvallen van belangrijke systemen of het verliezen van gegevens betekent voor organisaties vaak een grote schadepost.

In deze eerste van drie blogs gaan we in op

• De belangrijkste risico’s voor de continuïteit van systemen
• De daaruit af te leiden eisen die minimaal overwogen moeten worden bij het opstellen van een programma van eisen

In het tweede deel over continuïteit laten we zien hoe je met behulp van een impactanalyse de eisen op de situatie van jouw organisatie afstemt. In het afsluitende deel geven we een handreiking voor het opstellen van een Disaster Recovery Plan zodat bij het zich voordoen van een calamiteit duidelijk is wie op welke wijze kan bijdragen aan het realiseren van het gewenste niveau van continuïteit.

Continuïteit in programma’s van eisen

Om de vereiste mate van continuïteit te realiseren is vaak een complex van maatregelen nodig. Al deze maatregelen zijn gericht op het realiseren van een tweetal doelstellingen:

1. De tijd die nodig is om een applicatie weer beschikbaarheid te krijgen (RTO of Recovery Time Objective)
2. De hoeveelheid gegevens (uitgedrukt in uren of dagen) die een organisatie zich kan of wil veroorloven om kwijt te zijn (RPO of Recovery Point Objective)

Om deze doelstellingen te bereiken zien we dat programma’s van eisen zich vaak beperken tot een drietal basiseisen

1. Het eisen van een bepaalde beschikbaarheid van een systeem (x% van de tijd)
2. Het eisen van een periodieke back up van gegevens
3. Het beschikken over een ISO 27001 of ISAE 3402 certificering

In de praktijk blijken deze eisen en het voldoen daaraan zelden wat waard.
De eerste twee eisen geven weliswaar invulling aan de twee eerder genoemde doelstellingen, het vereisen van een certificering geeft echter geen garantie dat aan de eisen kan worden voldaan. Zoals in de praktijk veelvuldig blijkt.

Continuïteitsproblemen in de praktijk

Het uitvallen van belangrijke bedrijfssystemen treft elke sector en kent verschillende met regelmaat terugkerende oorzaken.

De drie onderstaande praktijkvoorbeelden maken goed zichtbaar welke aspecten in elk geval in een programma van eisen terug te vinden moeten zijn. Echter, ook wordt duidelijk dat niet alle risico’s via een programma van eisen zijn te beperken.

Recente praktijkvoorbeelden van calamiteiten

Voorbeeld 1. Onkunde bij Gemeente Drechtsteden (7 gemeenten, 290.000 inwoners)
“Waar zijn onze gegevens gebleven?” Dat zullen ze geroepen hebben bij de Gemeente Drechtsteden toen het data center uitviel. Zo’n € 500.000 aan herstelwerkzaamheden verder was het systeem weer up-and-running en een deel van de verdwenen gegevens weer ingevoerd.
Directe oorzaak: Het koelsysteem was uitgevallen waardoor servers werden uitgeschakeld. Kritische bedrijfsapplicaties waren niet meer toegankelijk en back ups raakte verloren.
Aanwezige maatregelen: Geen werkende basismaatregelen getroffen. Het lijkt er niet op dat er een risicoanalyse of gegevensbeveiligingsplan is opgesteld of eisen zijn gesteld aan het data center.

Voorbeeld 2. Stroomuitval legt data centra plat
Het Franse OVH, met meer dan 27 data centers in 19 landen, host de applicaties en gegevens van een groot aantal multinationals en organisaties als Wikileaks. Een regionaal probleem met de stroomvoorziening legde verschillende OVH-data centers binnen een regio plat.
Directe oorzaak: noodstroomvoorzieningen die niet werkte bij meerdere data centra.
Aanwezige maatregelen: Data mirroring waardoor “real time replica’s” van applicaties en gegevens op verschillende locaties beschikbaar zijn en noodstroomvoorzieningen.
Door een regionale stroomstoring kwamen meerdere geografisch verspreide data centra zonder stroom te zitten. Doordat de noodstroomvoorzieningen niet werkten waren de verschillende “real time replica’s” geen van alle bereikbaar. De werking van deze noodvoorzieningen waren reeds langere tijd niet getest.

Voorbeeld 3. Bewuste aanvallen van buiten af leggen onderwijs plat
Aanvallen (DDos) op de servers van schoolsysteem Magister zorgden er voor dat honderden scholen geen toegang meer hadden tot roosters, lesmaterialen en cijfers. Hierdoor konden onder andere diverse tentamens geen doorgang vinden.
Ransomware (“gijzelsoftware”) zorgde er voor dat medewerkers en studenten van de Universiteit van Maastricht geen toegang meer konden krijgen tot hun gegevens. Deze waren met een code via de gijzelsoftware onherkenbaar en onherleidbaar versleuteld. Hierdoor moesten onder andere tentamens worden afgezegd en waren scripties niet meer toegankelijk. Door het betalen van “losgeld” werden gegevens weer toegankelijk gemaakt.

Minimale te stellen eisen aan continuïteit

De voorbeelden laten zien dat de eerdergenoemde drie eisen aanvulling behoeven.

1. Alle eisen gelden de leverancier van de software en alle leveranciers en dienstverleners waar deze gebruik van maakt.
2. Bepaalde beschikbaarheid van een systeem (x% van de tijd)
3. Het eisen van een periodieke back up van gegevens
   • Op een veilige locatie op te slaan, dus buiten het bereik van de locatie waar de originele gegevens zijn opgeslagen
   • Gedurende een bepaalde tijd te bewaren
   • De mogelijkheid om zelf te kunnen beschikken over een kopie van de back up
   • Het laten toelichten op welke wijze de leverancier dit heeft geregeld
4. De leverancier beschikt over relevante certificeringen zoals ISO 27001 of ISAE 3402 Type II
   • Inzage in de certificering zodat duidelijk is waarop deze betrekking heeft
   • Bij ISAE 3402 Type II, inzage in hetgeen eventueel van de eigen organisatie aan aanvullende maatregelen wordt vereist
5. Data centra beschikken over afdoende beveiligingsmaatregelen om externe aanvallen tijdig te kunnen detecteren en te weerstaan
6. Data centra beschikken over back up voorzieningen voor kritieke processen en functies
   • Zoals stroomnoodvoorzieningen, koeling, brandbeveiliging, servers, opslag, etc.
   • Inzage in de testverslagen van de backup voorzieningen
7. Het continue monitoren van de beschikbaarheid van het systeem inclusief
   • Inzage in periodieke performance rapportage
   • Meldingen van afwijkingen via een ticket systeem

Indien een permanente beschikbaarheid wordt vereist

8. Mirroring van software en gegevens tussen van elkaar onafhankelijk opererende data centers
   • Mirroring zorgt in feite voor een real time replica van software en gegevens
   • In een ideale, volledig betrouwbare situatie maakt deze oplossing het maken van een back up overbodig en is sprake van een zo goed als perfecte continuïteit.
   • Deze oplossing is in vergelijking met het kunnen beschikken over een back kostbaarder.

Verder is het vereist om een indicatief onderzoek uit te voeren naar mogelijk het effect van het gebruik van de software op privacy. Dit onderzoek kan uitmonden in het verplicht uitvoeren van een zogenaamd Data Protection Impact Assessment. Het niet voldoen aan deze vereiste kan een boete opleveren tot € 10.000.000 of 2% van de wereldwijde omzet.
Vanuit deze verplichting en mogelijk andere overwegingen wordt in een programma van eisen de volgende eis opgenomen:

9. De software en gegevens worden gehost door data centra binnen de EU zone en voldoen aan alle eisen zoals gesteld in de GDPR

Voor de exacte formulering van de bovenstaande eisen is het nodig om een impactanalyse uit te voeren. Onder andere omdat maatregelen geld kosten en keuzes in veel gevallen een kosten-baten afweging vragen. Dit is met name herkenbaar bij de eisen 4, 5, 6 en 8.

Lees in deel 2 over het opzetten en uitvoeren van de impactanalyse.

Enkele aanvullende lessen vanuit de praktijkvoorbeelden

De bovenstaande voorbeelden maken onder meer duidelijk dat

• Een gebrek aan inzicht in risico’s al snel kan uitmonden in (onnodige) grote schade. Het uitvoeren van een risicoanalyse is dan ook een must (Drechtsteden)
• Zelfs bij de aanwezigheid van uitgebreide beveiligingsmaatregelen deze wel regelmatig getest moeten worden (OVH)
• Van een leverancier verwacht mag worden dat voor de Software as a Service de nodige beveiligingsmaatregelen zijn genomen (Magister)
• Dat ongeacht de bedrijfsapplicaties die je selecteert de onderliggende ICT omgeving een goede bescherming nodig heeft tegen ongeautoriseerde, computervirussen en malware (Universiteit van Maastricht)

Samenvatting & Conclusie

Het kunnen beschikken over bedrijfsapplicaties en de bijbehorende gegevens is voor een organisatie vaak van niet te onderschatten belang. Dit besef vinden we terug in de programma’s van eisen. Hierin worden in de regel continuïteitseisen opgenomen. Deze zijn echter vaak te beperkt, niet gebaseerd op daadwerkelijk vastgestelde de risico’s en leggen de verantwoordelijkheid voor de aanwezigheid en werking vaak bij de leverancier.

Voor een bij de organisatie passende set van eisen dient daarom een impactanalyse te worden opgesteld. Aan de hand hiervan kunnen relevante en passende eisen worden gesteld waarmee een voor de organisatie vereist niveau van continuïteit kan worden nagestreefd. Met een leverancier kan vervolgens worden afgestemd welke maatregelen beschikbaar en wenselijk zijn. Op basis van de impactanalyse en de gekozen maatregelen kan een Data Recovery Plan). Aan de hand van dit sluitstuk in het proces kunnen gebruikers en leverancier gezamenlijk en op gestructureerde wijze de nodige actie ondernemen indien zich een calamiteit voordoet. Hiermee worden de nadelige effecten van een calamiteit zo beperkt mogelijk te houden en worden betrokkenen tijdig te informeren.

Wil je meer weten over de keuze van continuïteitseisen, het uitvoeren van een impactanalyse of het opstellen van een werkend Disaster Recovery Plan, neem dan gerust contact met ons op.

Wim Vriend
Kennispartner E-proQure