Categorie: Geen categorie

Standaard processen en procedures voor beheer

  door

Gisteren haalden we al kort een van de standaard processen voor het beheer van informatiesystemen aan: het patchmanagement. Maar er zijn er nog veel meer waar we dankbaar gebruik van kunnen maken. Waarom zouden we het wiel opnieuw uitvinden als we toch al weten dat het wiel rond zal worden? Juist, gebruik wat er al is en pas dat toe op de eigen situatie.

De vraag die we daarom stellen:
Zijn er standaard processen en procedures ten aanzien van het beheer van de informatievoorziening (wijzigingen-, autorisatie-, beveiligingsbeheer, etc.)?

Het klinkt allemaal erg simpel. Gebruik standaarden als ITIL (technisch beheer), ASL (applicatiebeheer) en/of BiSL (functioneel beheer) en klaar zijn we.

Theoretisch misschien juist, maar de complexiteit zit hem nu juist in het doorvertalen van dergelijke standaardprocessen naar onze eigen organisatie met haar eigen informatievoorziening. En dan is het ineens makkelijker gezegd dan gedaan. Het wordt allemaal nog wat complexer als we de verschillende processen en het technisch, applicatie en functioneel beheer ook nog eens onderling willen verbinden en ervoor willen zorgen dat het ook echt allemaal optimaal werkt.

Voor grotere organisaties zitten er vaak afdelingen en specialisten die al vaker met dit bijltje hebben gehakt en dan nog kom je de meest vreemde constructies tegen. Voor kleine en middelgrote organisaties gaat het vaak te ver en is het te ingewikkeld om het beheer volgens deze standaarden in te voeren. Die zullen moeten roeien met de riemen die ze hebben en komen er vaak niet aan toe om het beheer formeel in te regelen. “Ik heb een neefje die verstand heeft van computers en het wel even voor me regelt”, komt je vast bekend voor. Het kan, maar risicovol is het wel. Je laat je nichtje die bedrijfseconomie op de HAVO heeft gehad ook je boekhouding niet doen, toch?

Dat klinkt natuurlijk als een ramp: “De kleine organisaties kunnen het beheer niet goed inregelen omdat ze de middelen en kennis niet hebben.” Toch valt dat in de praktijk mee omdat de infrastructuur van die kleinere organisaties vaak een stuk eenvoudiger is dan van grote complexe organisaties.

We hebben het eerder ook al eens aangehaald: wordt er gebruik gemaakt van specialistisch advies? Dit is nu typisch zo’n onderwerp waarbij we van specialistisch advies gebruik kunnen maken. Niet van mensen die snel even een ITIL, ASL, of BiSL certificaat hebben gehaald, maar van mensen die deze certificaten (de theorie) in bezit hebben aangevuld met praktijk ervaring. Specialisten die de vertaalslag naar jouw organisatie, groot of klein, kunnen maken.

Wil je je beheer verbeteren dan loont het om je te verdiepen in de basis principes van ITIL, ASL en BiSL, daarvan het beste door te vertalen naar jouw eigen situatie en als het even kan gebruik te maken van specialisten die door de wol geverfd zijn. Het gaat er niet om, om al die processen lukraak in te voeren (papierentijgers) maar het gaat er om dat het beheer daadwerkelijk geprofessionaliseerd wordt zodat er continuïteit van de bedrijfsprocessen en informatievoorziening ontstaat (met een bepaalde mate van zekerheid die nooit 100% is). Kunnen we dat op een andere wijze beter voor elkaar krijgen dan staat die mogelijkheid zeker open maar het wiel zal waarschijnlijk toch weer rond worden.

Beveiliging door updates en patches

  door

Hadden we het vorige week nog over onderhoud waar we met name doelen op de onderhoud van allerlei systemen om te voorkomen dat componenten de “end-of-life” status bereiken. Nu gaan we in op het onderhoud van de software en applicaties. De vraag is daarom:

Wordt er voor gezorgd dat de software altijd up-to-date is en dat de laatste patches op een veilige wijze zijn doorgevoerd?

Aan het doorvoeren van updates en patches zitten meerdere kanten, maar we belichten er twee, namelijk:

  • Waarom zouden we updates en patches doorvoeren?
  • Hoe kunnen we updates en patches doorvoeren?

 
Het waarom lijkt natuurlijk simpel. We willen ervoor zorgen dat er geen beveiligingslekken zitten in de software en applicaties die we gebruiken. Door verouderde software te gebruiken kunnen er lekken ontstaan waarmee ongeautoriseerde toegang tot onze informatie mogelijk wordt. Hoewel het antwoord simpel is, zien we nog te vaak dat updates en patches niet of veel te laat worden doorgevoerd. Enerzijds omdat we niet weten dat er een update of patch is, anderzijds omdat we het nogal lastig vinden om ze door te voeren: het werkt toch?

Daarmee belanden we bij de tweede vraag: Hoe kunnen we updates en patches doorvoeren? We richten daar natuurlijk het patchmanagement proces voor in. Daarvoor gebruiken we de formats van ITIL en klaar zijn we, toch? Nou niet helemaal. We moeten er bijvoorbeeld rekening mee houden dat het doorvoeren van updates en patches ook risico’s met zich meebrengt. Het kan zomaar zijn dat door een update het systeem niet meer werkt zoals we willen.

Het klinkt misschien wat cryptisch. Maar stel: je hebt een Iphone waarmee je uiteraard kunt bellen, je mail kunt lezen en nog wel wat meer “smart” dingen kunt doen. De batterij gaat lekker lang mee en je hoeft dus niet al te vaak op te laden. Je koppelt je Iphone aan je Itunes en ziet dat er (weer) een update is. Je besluit om maar even snel de update door te voeren zodat je weer helemaal bij bent. Halverwege de update loopt je Iphone vast en je moet het proces opnieuw herhalen (in de hoop dat het nu wel gaat lukken). Maar, ja hoor, na de tweede keer is het gelukt. Je kunt weer vrolijk bellen en mailen. Maar je constateert wel dat de batterij ineens een stuk minder lang meegaat dan je gewend bent.

Een voorbeeld dat we allemaal wel kennen, toch? Heb je geen Iphone? Dan geldt dit vast ook voor de Blackberry of Nokia. Geloof het of niet, maar een telefoon is voor vele mensen tegenwoordig toch echt een kritisch systeem, zonder telefoon weten we ons geen raad meer. Dit vergelijk kunnen we doortrekken naar de applicaties die we op ons netwerk hebben draaien. Het kan zomaar zijn dat een update of patch er voor zorgt dat het allemaal niet meer zo soepel wil werken, dat we niet meer bij de informatie kunnen en dat het proces tot stilstand komt.

Je moet er niet aan denken, toch? Dan maar liever geen update doorvoeren, maar ja, dan zitten we met het feit dat er gaten in onze software zitten waarmee we een gewild slachtoffer kunnen worden. Maar gelukkig is een een remedie. We testen updates en patches eerst in een test omgeving. We hebben niet voor niets de teststraat, toch?

Ook hiervoor geldt weer dat we keuzes zullen moeten maken. Is de patch zo kritisch dat we niet eerst uitgebreid kunnen testen (en er maar het beste van moeten hopen) of kan de update best een dagje wachten en kunnen we eerst een goede test uitvoeren? Dat is de vraag die we situationeel zullen moeten beantwoorden. Zaken om rekening mee te houden bij het opzetten van het patchmanagement proces.

Beveiliging en onderhoud in onderhoudscontracten

  door

Inmiddels hebben we gezien waarom we eventueel kunnen kiezen voor onderhoud en dat als we daarvoor kiezen we dat goed in moeten plannen om het zo efficiënt mogelijk te maken. De afspraken die we met de leveranciers maken leggen we natuurlijk vast in Service Level Agreements. Niet geheel onlogisch is de volgende vraag dan ook:

Zijn er onderhoudscontracten (SLA, afspraken) voor de informatiesystemen, netwerkcomponenten en IT-middelen met erkende organisaties (insourcing, outsourcing, IT-beheerders, installateurs)?

We hebben inmiddels zicht op de voor ons kritische systemen waarvoor we minimaal onderhoud willen laten plegen. Als het goed is hebben we voor deze systemen Service Level Agreements opgesteld en zijn de afspraken daarin met de leverancier overeengekomen.

We kunnen onze eisen voor wat betreft het onderhoud in deze SLA opnemen en als we er dan toch mee bezig zijn: laten we dan ook direct maar een beveiligingsparagraaf in de SLA opnemen waarin we de beveiligingsafspraken en onze eisen ten aanzien van beschikbaarheid, exclusiviteit en integriteit vast leggen.

Ook voor de eisen die we stellen moeten we wederom proberen de afspraken zo SMART mogelijk te maken. Niet alleen voor onszelf, maar juist ook voor de leverancier. Willen we die Rolls Royce waar we het eerder over hadden of toch liever een Dacia Logan? En kan de leverancier die we geselecteerd hebben die Rolls Royce of Dacia ook daadwerkelijk leveren?

Een contract is een vastlegging van onderling gemaakte afspraken. Op zich niet zo veel bijzonders zul je zeggen. Toch is het van belang een goede band te realiseren tussen leverancier en klant. We zien nog wel eens dat degene met de meeste macht (of de grootste mond) de overhand heeft en eenzijdig de afspraken doorduwt. De leverancier wil graag leveren en zegt alles te kunnen. In de praktijk komt het er dan op neer dat de klant op papier het goed voor elkaar heeft maar dat de praktijk daar van af wijkt.

Een SLA is geen papierentijger…of behoort dat in ieder geval niet te zijn. We kunnen best boeteclausules afspreken, maar hou er rekening mee dat als we die clausule veelvuldig gaan gebruiken dat de band tussen leverancier en klant niet ten goede komt. Leven en laten leven en misschien nog wel belangrijker: leren van de fouten die gemaakt zullen worden. De fout ligt niet altijd automatisch maar bij de leverancier, misschien hebben we hem wel teveel uitgeknepen, misschien hebben we hem teveel onder druk gezet.

De contracten zijn niet zozeer bedoeld om elkaar keihard af te kunnen rekenen, er zullen best fouten gemaakt worden maar de kunst is om daar op een zo elegant mogelijke wijze mee om te gaan zodat de continuïteit van onze bedrijfsprocessen daar zo min mogelijk hinder van ondervindt. Daar ging het toch om? De continuïteit van de bedrijfsprocessen, daarvoor hebben we ondersteunende informatiesystemen en voor die systemen hebben we weer contracten.

De keten is zo zwak als de zwakste schakel, dat hebben we al eerder aangehaald. We willen onze leverancier niet zover onder druk zetten dat ze daardoor de zwakste schakel worden…daar worden zij niet blij van (en uiteindelijk gaan we het toch betalen) en daar worden wij niet blij van (omdat het niet doet wat we willen). Het gaat om samenwerking met hetzelfde doel voor ogen…en dat is inderdaad makkelijker gezegd dan gerealiseerd omdat iedereen weer andere belangen heeft.

Het daadwerkelijke onderhoud van informatiesystemen

  door

Gingen we gisteren in op het systeem (of eigenlijk met name de keuzes en de achtergronden) bij het onderhouden van de informatiesystemen. Vandaag gaan we kort in op het daadwerkelijke onderhoud.

Daarom de vraag:
Vindt onderhoud conform dit onderhoudssysteem periodiek plaats?

Leuk hoor dat we er inderdaad voor gekozen hebben dat we voor dit specifieke systeem onderhoud willen hebben. Dat ligt vast in de SLA met de leverancier en daarbij bood hij ons de keus tussen brons, zilver of goud…waarbij wij natuurlijk voor goud zijn gegaan. Nu nog zorgen dat dat onderhoud ook echt plaats gaat vinden en dat het middel niet erger gaat worden dan de kwaal.

We moeten er dus voor gaan zorgen dat we het onderhoud periodiek en gepland plaats laten vinden om zo de kans op uitval van het systeem te verminderen. Soms zullen we preventief alvast onderdelen moeten vervangen die aan het eind van hun Latijn lijken te zijn. De remblokken van de auto vervangen we, hopelijk, ook al voordat ze echt op zijn.

Toch een kanttekening bij het onderhoud. We moeten er voor waken dat het onderhoud er niet voor zorgt dat het systeem “in storing” staat gedurende de reguliere werktijden omdat we zo nodig even iets moeten onderhouden volgens de planning. Je wilt ook je CV-ketel thuis niet in onderhoud zetten als je vrouw net onder de douche springt (of, misschien wil jij dat juist wel…maar het gaat om het voorbeeld). Juist door het plannen kunnen we dit voorkomen, is er niet binnenkort een onderhoudsweekend gepland? Mooie gelegenheid om ook het onderhoud voor ons systeem uit te voeren, toch?

Ok, we kunnen echt niet alle storingen voorkomen, het kan altijd een keer gebeuren dat een component de geest geeft. Wel kunnen we proberen met onderhoud de kans op storing te minimaliseren, de technische levensduur en omzet te maximaliseren en de werking van de bedrijfsprocessen te continueren.

Zeurt de boekhouding of inkoopafdeling over de kosten voor onderhoud? Reken dan even voor wat uitval kost in de vorm van misgelopen omzet en wat het oplevert als we het systeem een paar jaar langer operationeel kunnen houden. Grote kans dat je de business case rond krijgt en inderdaad besluit dat voor “goud” (of zilver of brons) gaan in dit geval grote besparingen kan realiseren…de kosten gaan echter nog steeds voor de baten uit.

Het systeem voor onderhoud van informatiesystemen

  door

Zo, dat fantastisch mooie, nieuwe, supersnelle netwerkcomponent is aangeschaft en voorlopig zitten we er weer goed bij, toch? Afschrijving van dat systeem in 5 jaar, dus voorlopig hebben we er geen omkijken naar, toch? Onderhoud van het nieuwe component was optioneel bij de aanschaf, dus daar hebben we flink op kunnen bezuinigen, toch?

Als het gaat om onderhoud van de informatiesystemen dan moeten we verder kijken dan de neus lang is. We moeten niet alleen kijken naar de economische levensduur maar juist ook naar de technische levensduur (die wellicht vele malen belangrijker is). Gelukkig kunnen we met goed onderhoud die technische levensduur flink verlengen (en op de lange termijn dus flink wat geld verdienen). Maar goed, eerst maar even de vraag:

Is er een systeem voor het onderhoud van informatiesystemen, netwerkcomponenten en IT-middelen?

Je hebt het voorbeeld vast wel eens gehoord: het aanschaffen van een Rolls Royce is een ding, het onderhouden daarvan een ander. Dat was in het verleden, naar horen zeggen, ook de reden dat de prijzen nou niet echt overzichtelijk waren. Als je naar de prijs moest vragen dan kon je het niet betalen. As simple as that.

Trekken we de parallel naar het onderhoud van de informatiesystemen dan geldt daarvoor in enige mate hetzelfde. Het aanschaffen is een, maar het onderhouden is twee. Hoe vaak zien we niet dat de systemen weg staan te stoffen? De schoonmaker mag zeker niet in de serverruimte komen want wie weet wat die daar stuk kan maken (ja ja, ik weet het onderhoud is niet gelijk aan schoonmaak, maar we trokken een parallel, weet je nog?).

Onderhoud is niet goedkoop en kan al snel oplopen tot 20% van de aanschafprijs. Het voordeel is wel dat we daarmee de levensduur van het systeem kunnen verlengen en wat is er nou mooier dan een systeem te hebben dat de economische levensduur in technische zin overleeft.

Overigens moeten we met onderhoud ook weer niet doorschieten. Sommige systemen willen we helemaal niet onderhouden…we leven in een weggooimaatschappij, toch? Wie doet er nu nog 5 jaar met zijn smartphone of laptop? Willen we daar dan enorme onderhoudskosten voor dragen of accepteren we dat het vaak goed gaat en we zo af en toe een laptop wat eerder moeten vervangen?

Nee, bij onderhoud kijken we enerzijds naar de economische aspecten, maar we kijken natuurlijk juist ook naar hoe kritiek het systeem is. Welke kritische bedrijfsprocessen zijn afhankelijk van het systeem en hoe lang mogen die uit de lucht zijn voordat de klanten beginnen te piepen…of we omzet mislopen?

Kortom: ook bij onderhoud van de informatiesystemen is een kosten/baten en impact analyse noodzakelijk. Doen we dat op de juiste wijze dan kunnen we het onderhoudssysteem afstemmen op de bedrijfsvoering en besteden we alleen onderhoudskosten aan die systemen waarvoor we dat noodzakelijk vinden.

Verantwoordelijkheid voor informatiesystemen

  door

Zoals we inmiddels weten wordt voor de beveiliging van de bedrijfsprocessen gekeken naar de ondersteunende informatie, het materieel en het personeel. Voor de informatie wordt de digitale informatie in de informatiesystemen steeds belangrijker (soms overschatten we dat belang trouwens want wat is er mis met het schrijven van een brief, het plakken van een postzegel en het dichtlikken van een envelop als de email het niet meer doet?). En hoewel ik informatiesystemen graag breder zie dan alleen de digitale systemen (terugkomend op de geschreven brief…een postvak is in die zin ook onderdeel van een informatiesysteem) worden die digitale systemen belangrijker en belangrijker.

De vraag die we ons moeten gaan stellen is:
Zijn alle informatiesystemen toegewezen aan een verantwoordelijke?

Laten we maar direct onderkennen dat we de verantwoordelijkheid voor informatiesystemen echt niet alleen voor de beveiliging van dat systeem willen beleggen. Nee, beveiliging is nog steeds ondersteunend en er zijn andere redenen waarom we dat informatiesysteem in leven houden (althans: ik hoop dat die redenen er zijn want anders kunnen we ze beter uitzetten). Alleen al omdat het informatiesysteem een bijdrage levert aan het voortbestaan van de organisatie willen we dat het systeem zo goed mogelijk gemanaged wordt.

Als we dan toch al iemand aan hebben gewezen die verantwoordelijk is, dan is het nog een klein kunstje om hem of haar ook duidelijk te maken wat de taken, bevoegdheden en verantwoordelijkheden op het gebied van de beveiliging van dat informatiesysteem zijn. Op papier allemaal niet zo ingewikkeld maar laten we vooral die taken, bevoegdheden en verantwoordelijkheden niet zomaar over de schutting gooien.

Formeel is de verantwoordelijke ook verantwoordelijk voor de beveiliging, want beveiliging was immers een lijnverantwoordelijkheid. Maar laten we diegene daarin watertrappelen dan is de kans groot dat beveiliging het ondergeschoven kindje wordt. Nee, het is de taak van de security manager om de kaders te ontwikkelen, de formats, de standaarden, de richtlijnen en vooral ook om een luisterend oor te zijn voor de organisatie.

We kunnen het niet genoeg benadrukken: beveiliging moet het werken niet lastiger maken dan nodig, nee we moeten keuzes maken over het niveau van beveiliging…en die keuzes worden toch echt gemaakt door degene die we verantwoordelijk maken voor de informatiesystemen. Zijn wij het vanuit de beveiligingsoptiek het niet eens met de gemaakte keuzes dan gaan we eerst in overleg, leggen onze beweegredenen uit en laten eventueel een hoger echelon de definitieve hamerklap geven.

Beveiliging en externe verbindingen

  door

Bij de volgende vraag wordt al snel gedacht aan de internetverbinding waardoor we al die mooie flashy internetsites lekker snel kunnen bekijken. Natuurlijk valt dat onder de volgende vraag:

Zijn alle externe verbindingen inzichtelijk?

Maar bedenk dat er tegenwoordig vele externe verbindingen zijn waardoor we als organisatie risico’s lopen op ongeautoriseerde toegang tot ons netwerk, onze systemen en onze informatie.

De firewall en de verbindingen die via die firewall lopen kunnen we nog wel managen (toch?). Maar hoe zit het met al die draadloze verbindingen die via een simpel routertje met de buitenwereld verbonden zijn? Hoe zit het met de koffiezetautomaten, kopieerapparaten en toegangsbeveiligingssystemen die tegenwoordig ook al snel een externe verbinding in zich hebben? Hebben we die ook allemaal inzichtelijk en managen we die?

Je bent het inmiddels waarschijnlijk wel van me gewend, ik ga niet in op de wijze waarop je deze verbindingen technisch dicht kunt zetten of met technische maatregelen zo goed mogelijk kunt beveiligen. Nee, we gaan in op andere risico’s. Namelijk die van de informatie die via die verbindingen benaderd kan worden, zonder daarbij volledig te willen zijn.

Vele leveranciers (en afnemers misschien ook) maken gebruik van de informatie in onze systemen. Deels weten we dat omdat die leverancier nu eenmaal onderdeel is van de keten en willen we de keten goed kunnen besturen dan is dat gewoon noodzakelijk. We sluiten daarvoor allerlei SLA’s af en zorgen dat er geheimhoudingsverklaringen getekend zijn. Hoewel hier natuurlijk ook vele risico’s en vele kanten aan zitten, geloof ik wel dat we hier nog redelijk inzicht in kunnen krijgen.

Maar juist die systemen waarvan je het niet verwacht: de koffiezetapparaten en kopieerapparaten bijvoorbeeld. Onder het mom van het beter kunnen onderhouden van die systemen communiceren ze met de leverancier. Na zoveel kopjes koffie of na zoveel kopietjes moet er onderhoud gepleegd worden. Maar wie zegt me dat deze gegevens betrouwbaar zijn? Wie zegt me dat de meters geijkt zijn…dat willen we in een taxi toch ook graag, want teveel willen we zeker niet betalen.

Natuurlijk wil ik niet alle leveranciers van dergelijke apparaten over dezelfde kam scheren. Het merendeel zal trouwens betrouwbaar en integer zijn (hoewel ze nog steeds veel gegevens verzamelen waarvan we ons nog te weinig bewust zijn). Nee, het gaat juist om die leveranciers die we toch wat minder kunnen vertrouwen. Die de metertjes net wat sneller laten draaien waardoor er eerder onderhoud nodig is of die de kopietjes uitlezen en aan je concurrent doorverkopen (want, ja ze worden opgeslagen op de harde schijf in het apparaat).

Kortom, stel jezelf nog maar een keer de vraag: Zijn alle, echt alle, externe verbindingen inzichtelijk? En zo ja, weten we ook welke echte risico’s we met die verbindingen lopen?

Oh, even voor de duidelijkheid. Ik ben helemaal niet tegen dit soort verbindingen en veel leveranciers kun je gewoon vertrouwen. Nee, als het bijdraagt aan reductie van (onderhouds)kosten en we meer zekerheid hebben dat we iedere morgen een “vers” bakje koffie kunnen drinken, dan ben ik er alleen maar voor…mits we de risico’s onderkennen, natuurlijk.

Registratie van informatiesystemen

  door

Ik kan me goed voorstellen dat je inmiddels wel een beetje genoeg hebt gekregen van al die reservekopieën, geloof me, ik vind het ook niet het leukste onderdeel. Maar zoals we steeds aangeven is een integrale beveiligingsbenadering het beste. Alles op een bepaald basis niveau waarna we weer verder kunnen kijken. Reservekopieën zijn een belangrijk en nog wel onderschat onderdeel en zonder deze reservekopieën (in welke vorm dan ook) kunnen we niet zeggen dat we echt aan informatiebeveiliging doen. Net als de registratie van de informatiesystemen, trouwens, want dat is het volgende onderwerp.

De vraag voor vandaag:
Zijn alle informatiesystemen, netwerkcomponenten en IT-middelen geregistreerd en beschreven?

Net als bij de bedrijfsprocessen moeten we ervoor zorgen dat we zicht hebben op de informatiesystemen, netwerkcomponenten en IT-middelen. We moeten ze niet alleen inzichtelijk hebben maar moeten er ook voor zorgen dat iemand zich daar verantwoordelijk voor voelt. We moeten ze registreren en beschrijven zodat we weten wat we allemaal in huis hebben.

Daarbij moet je uiteraard keuzes maken in wat je vastlegt. Willen we bijvoorbeeld de werkplekken registreren? Registeren we dan ook alle beeldschermen? En alle muizen en toetsenborden? En alle muismatjes? En alle kabels? Je kunt zo ver gaan in de registratie als je zelf wilt, maar alles vastleggen is meestal niet de meest efficiënte optie.

Ook hier geldt weer de kosten moeten wel tegen de baten opwegen. Als het registreren van een muismatje veel tijd kost (want ja, waar staat exact het registratienummer op dat muismatje?) dan kun je er wellicht beter voor kiezen om die maar niet vast te leggen. Een gek voorbeeld? Ja, misschien wel. Toch zien we in de praktijk organisaties worstelen met de definitie van een werkplek en wat daarvan dan exact moet worden vastgelegd. Op zich is die worsteling helemaal niet erg, maar in dit geval kun je vooraf beter iets langer nadenken dan dat we het straks in de database allemaal moeten vastleggen of moeten wijzigen.

We gaan er voor het gemak maar even vanuit dat we inmiddels alle kritische informatiesystemen, servers, routers en dergelijke wel inzichtelijk en vastgelegd hebben. Maar hoe gaan we om met het mobiele werken? Iedereen een laptop en smartphone en aan de slag dan maar. Juist deze administratie is van belang want we willen niet dat dergelijke zaken de organisatie verlaten als iemand ontslag heeft genomen of gekregen. Vergeet ook vooral de tokens niet om veilig in te kunnen loggen.

Een mogelijkheid is het opstellen van gedragsrichtlijnen voor het personeel waarbij wordt afgesproken dat ze de spullen in zullen leveren bij einde dienstverband en dat ze diefstal of verlies ervan zo snel mogelijk melden. Uiteraard moet je dat wel even controleren bij uitdiensttreding want er wordt snel getekend in goede tijden maar hoe is de naleving in slechte tijden?

Niet alleen hebben de assets een geldelijke waarde (3 tot 5 jaar afschrijving) maar juist ook de informatie die er op staat wil je graag ongeschonden terug hebben.

Spullen die afgevoerd worden omdat we ze echt nooit meer gaan gebruiken registreren we natuurlijk ook, maar eerst zorgen we ervoor dat alle informatie er vanaf is, toch? We willen niet dat onze oude server of harde schijf via Marktplaats verkocht wordt en we dat later in de Telegraaf kunnen lezen.

Het klinkt allemaal vrij logisch, toch? Toch zien we in de praktijk dat het aan de registratie (vastgelegd in een CMDB: Configuration Management Data Base) nog wel eens schort. Raar eigenlijk want alle leaseauto’s in ons autopark hebben we wel inzichtelijk.

Het veilig opslaan van reservekopieen

  door

Nou, nog een keer over de reservekopieen dan voordat we dat verder met rust zullen laten. We hebben de eisen gesteld voor de beschikbaarheid, exclusiviteit en integriteit. We hebben keuzes gemaakt en we hebben getest of de gegevens ook echt benaderbaar zijn. Vandaag stellen we ons de vraag:

Worden de reservekopieen veilig opgeslagen (eventuele externe locatie)?

Waar slaan we de reservekopieen eigenlijk op? Doen we dat op tapes in ons eigen pand of kiezen we ervoor de tapes naar een ander pand te brengen? Hebben we zelf geen tapes en laten we de back-ups via internet overbrengen naar een extern datacenter en wie kunnen er dan eigenlijk allemaal bij? Oh ja, ik weet het, er zijn andere manieren dan tapes, maar het spreekt wel lekker tot de verbeelding, toch?

Laten we eerst ingaan op het opslaan van de reservekopieën in ons eigen pand. Dat is een optie, maar wat als ons hele pand afbrand? Hebben we dan nog ergens de gegevens beschikbaar? Hoe veilig is ons pand eigenlijk en welke incidenten vinden daar zoal plaats? Staat de back-up server op de kapstok bij de ingang (geloof me, ik heb het gezien) of kiezen we voor een veilig serverhok dat netjes op slot kan en waar de airco ervoor zorgt dat het niet al te warm wordt? Wie hebben er dan allemaal toegang tot de serverruimte en hebben zij allemaal die toegangsrechten wel nodig? Ook hier weer een groot aantal vragen die we onszelf kunnen stellen. Misschien kies je voor de, ogenschijnlijk, veiligere optie en host je de back-ups extern.

Maar ook in dat geval komen er een aantal vragen om de hoek kijken. Hebben we de juiste Service Level Agreements opgesteld en houdt de leverancier zich daaraan? Hoe betrouwbaar is die leverancier eigenlijk en wie is eigenaar van de servers en data? Staat de informatie in Nederland of ergens in het buitenland? Welke medewerkers bij de leverancier kunnen eigenlijk bij onze data? Er wordt nog wel eens gewerkt met een algemeen “Admin-account”, maar is nu nog te traceren welke medewerker er op welk moment dat account gebruikt heeft? Zo zie je maar, ook hier een aantal (en nog vele malen meer) vragen waar we toch even bij stil moeten staan.

Het doel blijft zo snel mogelijk weer over de data kunnen beschikken op het moment dat dat nodig is. Afhankelijk van de aard van de organisatie kunnen we ervoor kiezen onze data veilig op te slaan in ons eigen pand, op een andere locatie of extern onder te brengen bij een specialist. Hebben we te maken met echt spannende data die voor het voortbestaan van onze organisatie cruciaal is, dan kan het ook zomaar zijn dat we voor een combinatie kiezen.

Alles voor het voortbestaan van onze organisatie, toch? Ja, maar ook in dit geval moeten de kosten tegen de baten opwegen en met logisch nadenken komen we al een heel eind. Testen we vervolgens of het geplande ook nog werkt dan bieden we toch een bepaalde mate van zekerheid. Vinden we dat nog niet genoeg? Dan zullen we aanvullende maatregelen moeten nemen.

Het testen van reservekopieen

  door

We hebben het van de week ook al even aangehaald, maar vandaag gaan we er iets verder op in. Niet op de techniek, maar de gedachte er achter: Het testen van reservekopieen.

Logisch dan natuurlijk dat de formele vraag als volgt is:

Worden de reservekopieen getest of de gegevens benaderbaar zijn?

Gisteren schreven we het ook al. We maken geen reservekopieen om maar over kopietjes te beschikken of omdat het zo nodig moet van de Code voor Informatiebeveiliging. Nee, we maken ze om na een incident nog over de voor ons waardevolle informatie te kunnen beschikken. Daarom is het ook van belang om te testen of de reservekopien ook echt aan onze eisen voldoen.

Bevat de reservekopie inderdaad de voor ons belangrijke gegevens en zijn die gegevens nog benaderbaar? Als de gegevens uit een nogal exotisch programma komen is het ook van belang om te kijken naar de back-up van dat exotische programma. Anders beschikken we straks wel over de gegevens maar niet over het programma om die gegevens te kunnen lezen.

Ok, ok, maar jullie hebben de reservekopieen extern gehost, zoals dat zo mooi heet. Iedere nacht worden de gewijzigde gegevens weggeschreven naar onze leverancier. Hartstikke goed, maar weten we ook zeker dat we de gegevens weer snel genoeg terug kunnen halen? Hoe lang doen we er straks over om terabytes aan data terug te zetten? Kan dat binnen de tijd die we gesteld hebben voor onze kritische processen? En wat doen we als de internetverbinding door hetzelfde incident getroffen is? Kunnen we dan ook nog op tijd bij de data komen?

Ook moeten we goed kijken naar de kritische processen die als eerste de lucht weer in moeten. We moeten dus keuzes maken in de data die we als eerst terug zetten en de data die minder van belang is en wel even kan wachten. Al die terabytes aan informatie kunnen immers niet op hetzelfde moment over onze interverbinding en komen achter elkaar binnen.

Willen we er echt zeker van zijn dat het allemaal werkt? Ja, dan zullen we toch echt moeten gaan testen. Dat kan een papieren test zijn maar ook een test waarbij we de data echt terug gaan zetten om te kijken wat er gebeurt. De lessen die we daaruit kunnen trekken verwerken we weer zodat we onze aanpak van reservekopieen continu kunnen verbeteren. Je raadt het al: om zekerheid te hebben moeten we vaker testen en misschien zelfs noodscenario’s achter de hand hebben voor het geval dat.