Auteur:

Beveiliging en de afstemming op de processen

  door

Inmiddels beginnen we steeds meer te denken aan het beschermen van de processen om de continuïteit van onze organisatie beter te borgen. We hebben inmiddels ook wel door dat het helemaal niet draait om allerlei technische beveiligingsmaatregelen als firewalls, anti-virus en intrusion detection. Nee, inmiddels weten we dat de keuzes die we maken draait om het verhogen van de omzet, het verlagen van de kosten en het beschermen van ons imago. Dat we daarvoor uiteindelijk allerlei beveiligingsmaatregelen moeten nemen geloven we wel en is meer een zaak van de IT- en Facility-afdeling.

Willen we de uitvoerende afdelingen hun werk goed kunnen laten doen dan moeten we op tactisch niveau de kaders stellen waarbinnen zij kunnen opereren. Daarom de volgende vraag:
Zijn de eisen ten aanzien van de waarborging van de beschikbaarheid, exclusiviteit en integriteit op processen (bedrijfsvoering) afgestemd?

Denken we aan continuïteit van de bedrijfsprocessen en informatiesystemen dan denken we al snel aan de beschikbaarheidseisen die de waaraan moeten stellen. Meestal drukken we die uit in percentages als 95%, 98% of 99,9% die we doorvertalen naar brons, zilver en goud, omdat de klant die percentages helemaal niet wil horen. De percentages kunnen we meten en de IT-afdeling kan daar mooi verantwoording over afleggen. Hoewel dit allemaal makkelijker gezegd is dan gedaan, is er nog niet echt iets nieuws onder de zon.

Maar naast de beschikbaarheid moeten we ook kijken naar de eisen die we stellen aan exclusiviteit en integriteit. Exclusiviteit gaat in op de wijze waarop we ervoor zorgen dat alleen geautoriseerde personen of systemen toegang krijgen tot de informatie, terwijl integriteit juist ingaat op de juistheid, volledigheid en tijdigheid van de informatie.

Stellen we geen of de verkeerde eisen aan de exclusiviteit dan kan dat ervoor zorgen dat de informatie door ongeautoriseerde personen benaderbaar is en onze informatie al snel op straat komt te liggen. We lopen hiermee het risico dat ons imago een flinke deuk oploopt.

Hebben we te weinig zicht op de integriteit van de informatie dan kan dat er bijvoorbeeld voor zorgen dat we verkeerde keuzes maken op basis van onbetrouwbare informatie. Dit kan ons veel omzet schelen maar kan ook voor enorme kosten zorgen. Verkeerde keuzes kunnen ook leiden tot imagoschade. Denk maar aan het geval waar een arts op basis van de verkeerde informatie het verkeerde been van een patiënt amputeert.

Willen we dus continuïteit van onze organisatie en haar bedrijfsprocessen dan stellen we beschikbaarheids-, exclusiviteits, en integriteitseisen aan de informatiesystemen. Daarbij laten we de kosten en baten weer meewegen want hoe meer maatregelen we nemen, hoe meer kosten dat met zich meebrengt en hoe moeilijker de medewerkers hun werk kunnen doen. De kunst is niet om lukraak de eisen te stellen maar juist om het optimum te vinden waarbij de eisen zo goed mogelijk aansluiten bij de missie van onze organisatie. Daarbij moeten we zeker in de gaten houden dat het allemaal wel werkbaar moet blijven omdat de medewerkers er anders omheen gaan werken.

De eisen die we stellen kunnen per organisatie verschillen. Zo zal een geheime dienst andere eisen stellen dan de bakker om de hoek (als die laatste al eisen stelt). Maar ook per informatiesysteem kunnen de eisen verschillen. De kritische informatiesystemen krijgen wellicht hogere eisen opgelegd dan een niet kritisch systeem. Hierbij houden we uiteraard weer de relatie tussen de bedrijfsprocessen en informatiesystemen goed in het oog en leiden we het een en ander af uit de missie van onze organisatie. Wel stellen we graag eisen die haalbaar zijn, we maken ze SMART om te voorkomen dat het er op papier allemaal leuk uit ziet, maar in de praktijk nooit gaat werken.

Kritische bedrijfsprocessen en informatiesystemen

  door

Inmiddels weten we dat we het beheer van de informatiesystemen heel goed in kunnen richten met standaarden als ITIL, ASL en BiSL. Besluiten we om dat te gaan doen dan gaan we eerst nog wat aanvullende keuzes maken. Het heeft niet zoveel zin om te beginnen met professioneel beheren van informatiesystemen die we nauwelijks gebruiken. We moeten kijken naar de relatie tussen kritische bedrijfsprocessen en informatiesystemen. Daarvoor moeten we dus zicht hebben op de bedrijfsprocessen aan de ene kant en de ondersteunende informatiesystemen aan de andere kant.

We stellen ons daarom de volgende vraag:
Is er inzichtelijk welke kritische bedrijfsprocessen van welke informatiesystemen, netwerkcomponenten en IT-middelen afhankelijk zijn?

Bij de kritische bedrijfsprocessen denken we wellicht direct aan die processen waarmee we ons geld verdienen, de primaire processen. Inderdaad veelal belangrijke en kritische processen. Maar we moeten niet vergeten dat er ook veel secundaire processen zijn die voor het voortbestaan van de organisatie kritisch kunnen zijn. Met deze secundaire processen verdienen we dan niet direct ons geld, maar ze zijn wel erg belangrijk om de primaire processen hun werk te kunnen laten doen.

We zullen dus zicht moeten hebben op de processen die ervoor zorgen dat onze organisatie werkt zoals ze werkt. Vervolgens zullen we goed moeten kijken welke informatiesystemen, netwerkcomponenten en IT-middelen een belangrijke bijdrage leveren aan die kritische bedrijfsprocessen. Juist voor deze systemen, componenten en middelen willen we het beheer goed inregelen. Waarom? Simpel: omdat uitval daarvan ons direct geld kost.

Klinkt weer eens erg cryptisch, maar geen nood. Een simpel voorbeeld: stel dat we een productiebedrijf zijn. Onze productiestraat is van groot belang en deze is inmiddels geheel geautomatiseerd. Tot zover niets bijzonders. Voor de toegang tot onze productiehal gebruiken we een geautomatiseerd toegangssysteem. Geen pasje, geen toegang, lekker veilig. Maar wat als het toegangssysteem hapert en de medewerkers niet naar binnen kunnen? Hoe snel kunnen we ervoor zorgen dat er een andere deur open gaat zodat de productie kan worden opgestart? Juist: het toegangssysteem hebben we nooit als kritisch gemarkeerd (en dat is misschien ook helemaal niet nodig), maar we hebben er wel enorme last van als de medewerkers een dag niet naar binnen kunnen en we een dag dus geen productie kunnen draaien.

We hebben het al vaker geschreven: processen kunnen we niet (of nauwelijks) beveiligen omdat een proces slechts een beschrijving is. De activiteiten en middelen die ervoor zorgen dat dat proces werkt, die kunnen we wel beschermen. Daarbij zagen we eerder al dat we ons kunnen richten op de informatiesystemen (inclusief netwerkcomponenten, IT-middelen, etc.) en op de assets en de mensen.

De moeilijkheid zit hem er in om de juiste relatie te leggen tussen die processen en informatiesystemen. Lukt ons dat dan kunnen we het beheer van die informatiesystemen die een belangrijke bijdrage leveren als eerste professionaliseren. De beschikbaarheid van deze systemen moeten gegarandeerd worden omdat bij uitval van dat systeem we daar last van ondervinden. Maar hoe snel ondervinden we er last van? Dat is een van de vragen die van belang is voor de inspanningen die we moeten verrichten.

Kan een proces 1 minuut, 1 uur, 1 dag, 1 week of 1 maand uit de lucht zijn? Wanneer ondervinden onze klanten (want daar doen we het voor, toch?) er last van en hoe lang duurt het voordat zij overstappen naar onze concurrent? Afhankelijk van het antwoord op die vraag nemen we een juiste set aan maatregelen om de kritische bedrijfsprocessen en informatiesystemen te beheersen. Daarbij moeten we kijken naar de gehele keten en ervoor zorgen dat alle onderdelen van die keten aan de gestelde beschikbaarheidseisen kunnen voldoen. De keten is zo zwak als de zwakste schakel, dat geldt net zo goed voor de continuïteit van de bedrijfsprocessen en de onderliggende informatiesystemen.

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.