Bijlage 1 aan collegenota DRP test 1. de noodzaak van een DRP test in de context van een professionele dienstverlening en risicobeheersing De werking van Stads- en OCMW diensten is de voorbije jaren in belangrijke mate afhankelijk geworden van de werking van de ICT infrastructuur. Zo werken tegenwoordig niet enkel de PC s of printers op het netwerk, maar ook: Telefoons Kassa s en betaalterminals Gebouwbeheersystemen en toegangscontrole (WZC s, Zwembad, ) Digitale klassen in academie (draadloze) internettoegang Tijdsregistratie Self-service balies (bib) Systemen van brandweer en politie Alarmcentrales (brand en kameroproepsystemen WZC) Camera s Temperatuurmetingen op koelwagens en douches (HACCP) Dit houdt in dat bij uitval van het netwerk al deze functies ook onbeschikbaar worden. Om de meeste risico s op te vangen hebben we een systeem uitgebouwd met ver doorgedreven virtualisering (servers) en redundantie (servers en netwerk). We hebben een goed monitoringsysteem dat ons een permanent overzicht geeft van de status van meer dan 4000 componenten in ons netwerk, waardoor wij bij problemen onmiddellijk kunnen ingrijpen, meestal zelfs vooraleer een gebruiker iets merkt. Dit heeft zich de voorbije jaren vertaalt in een zeer hoge graad van beschikbaarheid. Het is echter onmogelijk om alle risico s op te vangen. We moeten daarom procedures en draaiboeken opstellen om het systeem terug te kunnen heropstarten bij een onverwachte uitval. Hiervoor is het noodzakelijk dat minstens 1 keer per jaar het systeem geheel of gedeeltelijk wordt uitgeschakeld, zodat ICT kan kijken hoe de servers en gegevens van het OCMW datacenter naar het datacenter op het stadhuis kunnen worden overgezet. Dit proces neemt indien alles goed verloopt- minstens 3 uur in beslag voor het overzetten, 2 uur evaluatie en 3 uur voor het terugzetten. Aangezien dit een test is om te weten te komen wat de precieze impact is, kan de exacte duurtijd niet op voorhand worden ingeschat. De leverancier die ons begeleidt vraagt om te kunnen starten om 8u s morgens, en heeft voorzien dat de test maximaal 24 uur kan duren. Indien we later dan 8u starten is de dienstverlening de volgende dag dus niet gegarandeerd. Deze test moet ons toelaten om procedures op te stellen die de infrastructuur binnen een halve dag terug operationeel te maken bij calamiteiten (stroompannes, brand, )
2. Oproep globaal rampenplan 2013 Business Continuity plan Naar 2013 en volgende toe is het aangewezen dat deze test wordt gekaderd in een globaal rampenplan, i.s.m publieke veiligheid, veiligheidsdiensten, verpleegkundigen, personeel, PBW, De bedoeling hiervan is te bekijken wat de impact van een onverwachte uitval van het netwerk is of van een langdurige onbeschikbaarheid door hacking of virussen. ( Business Continuity ) Evalueren van impact op: 1. de operationele werking van diensten o stadhuis, OCMW administratie/uitbetaling leefloon, woon en zorgcentra 2. dienstverlening aan burgers o loketten, betaalterminals en kassa s, bibliotheek, academies, stadschouwburg, zwembad, 3. publieke veiligheid o zijn alle procedures voor de commandokamer ook beschikbaar als er geen netwerk is? 4. veiligheid personeel en bewoners WZC o blijven er geen -door toegangscontrole geblokkeerde- deuren gesloten? 5. zijn medicatiefiches off-line beschikbaar? 6. Heeft elke dienst een rampenplan bij uitval van de ICT infrastructuur. Kent elke medewerker de procedures die op dat moment moeten worden gevolgd? 7. Wat is de impact op operationele diensten zoals Politie en Brandweer? 8. Wat is de impact van de uitval van de telefonie è eigenlijk zou hiervoor net zoals bij brandoefeningen een onverwachte uitval tijdens de diensturen moeten worden gesimuleerd è er dient rekening te worden gehouden met een uitval van enkele uren tot enkele dagen Een dergelijke oefening zou bijkomend een duidelijk beeld kunnen geven van de eisen van het bestuur en de administratie qua beschikbaarheid en dienstverlening, door vragen te beantwoorden zoals: Welke dienst moet eerst terug operationeel zijn (bevolking? Brandweer?) Welke diensten moeten er zeker werken indien er slechts een halve capaciteit is (1 datacenter) Hoe lang mag een bepaalde netwerkcomponent onbeschikbaar blijven. Deze eisen zijn recht evenredig met de kost van het systeem dat dient opgezet te worden om eraan te voldoen. Momenteel schatten we de minimale downtime van het hele systeem bij uitval op 4 uur. Vraag is dus ook of iedereen er zich van bewust is dat het risico hierop zeer reëel is. Dit vormt ook een onderdeel van het globale Service Level Agreement (SLA) (dienstverleningsovereenkomst) Zie punt 3
3. Dienstverleningsovereenkomst (SLA) Naast de bovenvermelde vragen is het ook van belang dat er afspraken worden gemaakt over de verwachtingen van het bestuur naar : Welke dienstverlening verwachten we van ICT buiten de normale diensturen en in het weekend Welke reactietijd en reparatietijd is acceptabel (beschikbaarheid gekwalificeerd personeel) Wat is de maximale capaciteit van persoonlijke opslagruimte /mailbox Hoelang mag het netwerk/telefonie/een bepaalde toepassing onbeschikbaar zijn Hoeveel jaar dienen gegevens bewaard te blijven Reactietijd op helpdeskmeldingen Welke dagen kunnen worden gebruikt voor DRP testen Welke dagen/uren kunnen worden gebruikt voor gewone updates (conflictsituatie met leveranciers CEVI/CIPAL die enkel tijdens de werkuren updates willen doen) Wanneer kan er aan draadloze verbindingen worden gewerkt (uitval volledige deelgemeente) Hoe krijgt ICT toegang tot alle gebouwen waar kritische apparatuur staat Wat is de beschikbaarheidseis voor het netwerk? (90% tot 99,5%?) afspraken rond componenten 'in scope' van ICT. Meer en meer apparaten krijgen een netwerkaansluiting. Het is niet altijd duidelijk wie waarvoor moet instaan (zie opsomming van de componenten hierboven) deze afspraken kunnen niet op dienstniveau worden gemaakt, maar dienen globaal te worden vastgelegd (wie beslist? MT stad, MT OCMW, College en of OCMW Raad) Dit is zeer cruciale informatie bij het bepalen van de geschikte infrastructuur, de organisatie van het team, het aantal personeelsleden en de eventuele aankoop van reservemateriaal. Ook contracten met leveranciers dienen in functie van de afspraken op punt te worden gezet. Ook hier geldt weer de regel dat kosten lineair (soms exponentieel) stijgen bij hogere eisen. Afspraken moeten minstens op papier worden gezet. De ICT dienst is momenteel ook enkel georganiseerd om ondersteuning te leveren van 8:15u tot 16:45u op weekdagen, omdat bovenstaande verwachtingen noch op ambtelijk noch op bestuurlijk niveau geëxpliciteerd zijn.
4. Risicoanalyse en informatieveiligheidsplan Vertrekkende van de eisen of verwachtingen rond beschikbaarheid en dienstverlening kan een risicoanalyse worden opgestart. Deze vormt de basis voor een informatieveiligheidsplan en het afgeleide informatieveiligheidsbeleid. Dit moet een antwoord bieden op de vragen: Welke risico s zijn er met betrekking tot o Continuïteit van de dienstverlening o Integriteit van de gegevens o Vertrouwelijkheid van de gegevens Hoe schatten we die risico s in (waarschijnlijkheid + impact) Hoe beheersen we die riscio s (verzekering, vermijden, contingentieplannen, aanvaarden, ) Hoe wordt dit gecommuniceerd naar en opgevolgd door het management Welke maatregelen nemen we om risico s te voorkomen Omdat het netwerk van stad Sint-Niklaas verbonden is met het OCMW is het een wettelijke verplichting om dit te beheersen en hierover te rapporteren en audits te laten uitvoeren. (KSZ wetgeving) 5. Globaal kader Er is uiteraard geen reden tot paniek. Door de implementatie van ITIL processen binnen de ICT dienst hebben we de meeste directe risico s onder controle. Dat maakt bovenstaande acties echter niet minder dwingend of dringend. Het organiseren van de (beperkte) DRP test op 8 december is dan ook minimaal nodig. De ICT dienst werkt volgens de processen van ITIL (IT Infrastructure Library). Dit is een set van beste praktijkvoorbeelden voor de organisatie van een IT dienst. Betrokken processen: 1. Service Delivery. 1. Financial Management for IT Services (FMITS) 2. Capacity Management 3. Availability Management 4. IT Service Continuity Management (ITSCM) 5. Service Level Management 6. Security Management 2. Service Support. 1. Change Management 2. Release Management 3. Problem Management 4. Incident Management 5. Configuration Management 6. Service Desk Helpdesk De service support processen dekken we af met onze helpdesk en incident, problem, change & release beheer. Dit is de operationele taak van de ICT afdeling en neemt meer dan 80% van de beschikbare tijd in beslag. De service delivery processen dienen voor een belangrijk deel bepaald en aangestuurd te worden door de organisatie(s) zelf. IT is hier uitvoerder of bewaker.
Het ontbreken van een regelmatige routine in DRP testen is een rem op een goed Availability (1.3) & ITSCM (1.4) beheer. Het ontbreken van duidelijke afspraken over dienstverleningsniveau s maakt een goed Service Level (1.5), Capacity (1.2) beheer moeilijk. Het Security management luik (1.6) gaan we in de komende maanden zelf uitwerken vanuit ICT en voorleggen aan de organisatie Het Financial management luik (1.1) brengen we onder controle door een gedetailleerde analyse en budgettering van de werkingskosten We zouden bij het begin van de nieuwe legislatuur een voorstel willen doen waarmee afspraken rond het totaalplaatje kunnen worden gemaakt Afspraken rond DRP testen en globale oefeningen (business continuity & recovery) Afspraken rond dienstverleningsovereenkomst (SLA) Afspraken rond het informatieveiligheidsplan en beheer (ISMS)