Auteur:

Actieve monitoring van het netwerk

  door

Zo, de illegale software is ontdekt en we kijken goed of er geen nieuwe software bijkomt die we liever niet over ons netwerk hebben. Als we dan toch allerlei monitoring tools inzetten dan kunnen we dat net zo goed wat breder inzetten, toch?

De vraag:
Wordt het gebruik van de systemen en het netwerk actief gemonitord?

We willen graag weten wat er op ons netwerk gebeurt. Niet alleen voor beveiliging trouwens, maar ook om een optimale inzet van middelen te kunnen bewerkstelligen. Zo zien we maar weer dat beveiliging niet iets los of exotisch is. Nee, het maakt onderdeel uit van een groter geheel.

Weten we wat er op ons netwerk gebeurt dan kunnen we tijdig bijsturen en kunnen we tijdig bijvoorbeeld de capaciteit verhogen als dat nodig is. Ook daarbij gaan we natuurlijk weer eerst op zoek naar de oorzaken. Een mooi praktijkvoorbeeld hierbij is het geval waarbij een organisatie besloot om websites als Youtube, Hyves en LinkedIn dicht te zetten omdat het bandbreedte opslokte.

Altijd een mogelijkheid om sites dicht te zetten natuurlijk maar de vraag is of je commerciële en marketingafdeling niet dankbaar gebruik maken van de nieuwe mogelijkheden die geboden worden. Het dichtzetten van dergelijke sites kan tot verlies van klanten leiden…en we zijn op aarde om onze klanten te helpen, toch?

Nee, bij een nadere analyse bleek dat er de afgelopen 10 jaar niet zoveel aan bandbreedte bij was gekomen. Met web 1.0 was dat allemaal niet zo’n probleem, maar met filmpjes en interactieve netwerksites ontstond er toch een tekort.

Als we tijdig hadden gemonitord dan zagen we dit probleem natuurlijk allang aankomen en hadden we op tijd onze capaciteit uit kunnen breiden. Nu moeten er investeringen gedaan worden waarbij de Raad van Bestuur alleen maar voor dat soort bedragen mag tekenen. Een gemiste kans, maar ook een lesson learned…tenminste, als we vanaf nu wel gaan monitoren natuurlijk.

Richten we actieve monitoring in dan kunnen we incidenten in een aantal gevallen voorkomen. We zien dat de capaciteit minder en minder wordt en kunnen bedenken dat een server binnen niet al te lange tijd uit de lucht gaat. Daar gaan we natuurlijk niet op wachten…nee, we installeren bijvoorbeeld een nieuwe voeding zodat hij weer even mee kan. Daarnaast geldt dat als we weten wat er onder normale omstandigheden op ons netwerk gebeurt we afwijkingen sneller zullen ontdekken.

We zien dat er vreemde zaken gebeuren of raar verkeer voorbij komt. Daar kunnen we wat aan doen. We kunnen tot de conclusie komen dat een segment getroffen is door een virus. Als we wachten is straks het hele netwerk een puinhoop. We kunnen ook ingrijpen en dat segment loskoppelen om verdere schade te voorkomen.

Actieve monitoring doen we dus niet alleen om beveiligingsredenen maar ook om redenen als capaciteit en beschikbaarheid van het netwerk. Doen we dat op een goede manier dan merkt de klant niet eens dat er zich bijna een incident voordeed.

Kwaadaardige software

  door

De titel zegt het al, we gaan vandaag in op kwaadaardige software. De vaste lezers weten inmiddels wel dat ik geen techneut ben, dus verwacht hier geen opsomming van de laatste virussen en malicious software want daar heb ik geen zicht op. Trouwens, als deze virussen en software zich voordoen dan zijn we eigenlijk al te laat, we hebben de boot gemist en kunnen we alleen nog maar rennen om alles in de lucht te houden.

Nee, de vraag van vandaag:
Zijn er maatregelen getroffen tegen, de installatie van, kwaadaardige software?

Allereerst kunnen we natuurlijk hele bomen opzetten over wat we onder kwaadaardige software verstaan. Zijn dat virussen, trojan horses, wormen of weet ik hoe ze het allemaal noemen tegenwoordig? Die maken er vast onderdeel van uit. Maar hoe gaan we om met software die op zich legitiem is maar waarvoor we niet over de juiste rechten beschikken? Juist, de “illegale” software (ik weet het, de software is legaal alleen ons gebruik is niet legaal en ook dat zal juridisch wel niet kloppen).

Natuurlijk installeren we allerlei anti-virus pakketten en zorgen we ervoor dat we weten wat er zoal op ons netwerk gebeurt. Maar weten we ook over welke licenties we beschikken en of er niet meer installaties zijn dan licenties? Op zich weinig kwaadaardigs aan maar het kan ons wel op een boete komen te staan. Wat mij betreft zou je dergelijke voorvallen ook moeten detecteren.

Terug naar de vraag: hebben we maatregelen getroffen om installatie van kwaadaardige software te voorkomen? We kunnen hierbij direct denken aan technische maatregelen die er zeker onderdeel vanuit maken. Maar we moeten hierbij ook kijken naar de procedurele en organisatorische maatregelen.

Waarom zou iemand software willen installeren op het netwerk? Waarschijnlijk omdat hij functionaliteiten tekort komt om het werk goed te doen. Het aanvragen van een nieuwe applicatie is inmiddels zo ingewikkeld geworden dat de medewerker op zoek gaat naar zijn eigen oplossing. Een download is snel gemaakt en de installatie kost ook niet meer dan 3x op “ok” drukken. En hup, hij kan er mee aan de slag. Niet wetende dat er onderwater allerlei informatie de organisatie verlaat.

Allereerst moeten we de medewerker natuurlijk vertellen dat dit gedrag niet wenselijk is, daar helpt beveiligingsbewustzijn zeker bij. Maar direct daarna moeten we er ook voor zorgen dat hij op een makkelijke wijze zijn werk kan doen. Heeft hij een applicatie of functionaliteit nodig dan moeten we hem daarbij helpen.

Ik schrijf wel “we”, maar ik bedoel hier niet per definitie de security manager mee, nee, eerder de organisatie als geheel. De security manager kan, na het ontdekken van een installatie van kwaadaardige software, uiteraard wel analyseren wat de echte reden was en daar vervolgens een structurele oplossing voor adviseren. Allemaal leuk en aardig voor die medewerker die het onbewust heeft gedaan, die moeten we op een goede manier helpen en ondersteunen.

Dan houden we nog de medewerkers over die bewust, willens en wetens, software installeren om de boel plat te leggen of om informatie te stelen. Ook die medewerker moeten we helpen…maar op een andere manier. We helpen hem zijn spullen in een doos te doen en wijzen hem nog eenmaal waar de uitgang van het gebouw is.

Kortom: ook bij het ontdekken van kwaadaardige software (wat we er ook onder mogen verstaan) moeten we analyseren wat de oorzaak daarvan is of kan zijn. Weten we die oorzaak dan adviseren we structurele oplossingen om de oorzaken weg te nemen…oh ja, en de gevolgen deinstalleren we natuurlijk ook direct even.

Onderscheid tussen incidenten en beveiligingsincidenten

  door

We zijn er vorige week al kort op ingegaan, maar vandaag zoomen we nog wat dieper in op het verschil tussen incidenten en beveiligingsincidenten.

De vraag is dan ook niet voor niets:
Wordt er onderscheid gemaakt tussen beveiligingsincidenten en overige incidenten?

We schreven al dat we vanuit beveiligingsoptiek graag willen weten welke beveiligingsincidenten zich voordoen. Hier kunnen we namelijk onze aanpak op bijstellen. Doen we de juiste dingen en doen we de dingen nog juist? Het verschil tussen een incident en een beveiligingsincident kan hier het verschil in maken. Gisteren voegden we daaraan toe dat we het melden van incidenten zo makkelijk mogelijk willen maken om geen informatie verloren te laten gaan.

Nu kunnen we op papier en met een beetje Googlen best wat leuke definities ontwerpen voor het verschil tussen incidenten en beveiligingsincidenten. Dat moeten we zeker niet nalaten, maar we moeten degene die de incidenten als eerste te horen krijgen daar ook in trainen. En dat is makkelijker gezegd dan gedaan. De helpdesk medewerker heeft zijn “target” en moet binnen 5 minuten de klant weer op pad sturen (soms met een kluitje het riet in, maar het target is gehaald).

Daarmee gaat kostbare informatie verloren, die daarna wellicht nooit meer is terug te halen. Voor die beveiligingsincidenten die zich vaker voordoen is het nog mogelijk om mensen daarin te trainen. Ga maar na: na een alarmmelding van het inbraakdetectiesysteem weet de beveiligingsbeambte inmiddels wel wat hij moet doen en hoe hij moet reageren. Maar hoe reageert hij of zij als er een melding wordt ontvangen van een gijzeling op de directieverdieping?

Als het goed is hebben we natuurlijk allerlei procedures voor het opvolgen van incidenten maar het gaat er juist ook om dat degene die er mee geconfronteerd wordt zo creatief (en stressbestendig) is dat er ook echt wat in gang wordt gezet. De procedures zijn een goed hulpmiddel, maar niemand gaat, als het gebouw in de brand staat, een dik calamiteitenplan lezen.

We zullen dus mensen moeten trainen in het ontdekken van (mogelijke) beveiligingsincidenten maar juist ook in de opvolging daarvan. Dat geldt overigens niet alleen voor meer fysieke incidenten maar ook voor incidenten op informatiebeveiligingsgebied. Zien we dat de website uit de lucht gaat dan moeten we snel analyseren of het een technische storing betreft of een aanval van een scriptkiddie. De opvolging moet daarop worden afgestemd.

Omdat het verschil tussen een incident en een beveiligingsincident niet altijd duidelijk is, moeten we de meldpunten een mindset meegeven waarbij ze signalen herkennen. Jammer dat ze de targets even niet halen, maar het reageren op een beveiligingsincident is toch echt even belangrijker.

Juist als we helpdesken uitbesteden (al dan niet naar het buitenland) wordt het risico groter dat we beveiligingsincidenten missen. Er is immers weinig betrokkenheid bij onze “business” en de targetdruk is alleen maar groter. Een serieus risico waar we rekening mee moeten houden.

Als laatste halen we hier nog even kort de oorzaak-gevolg relatie aan. Dat hebben we al vaker gedaan, dus daar verwijs ik graag naar. De melding is veelal een gevolg (“mijn account is geblokkeerd”), de oorzaak kan soms een beveiligingsincident zijn (een collega heeft geprobeerd mijn account te gebruiken). Bij de melding moeten we dus op zoek naar de melding achter de melding…tenminste, als we echt iets van de incidenten willen leren…en dat verschilt dan weer juist niet tussen incidenten en beveiligingsincidenten want we willen beide structureel oplossen, toch?

Meldingsprocedure voor beveiligingsincidenten

  door

We zijn al even kort ingegaan op het verschil tussen een incident en een beveiligingsincident en zullen daar morgen nog wat dieper op ingaan. Maar we kunnen alleen maar wat doen aan incidenten als we ze ook daadwerkelijk opmerken. Het kan natuurlijk zo zijn dat we vanuit beveiliging vreemde zaken opmerken, maar we kunnen hierbij ook de hulp van alle medewerkers en zelfs van klanten inschakelen.

We moeten er dan alleen voor zorgen dat we het ze zo makkelijk mogelijk maken, dat we de melder bedanken (en eventueel belonen, in wat voor vorm dan ook want een simpel bedankje voelt ook al als een beloning) en dat we de melder ook informeren over hoe we met het incident zijn omgegaan en wat we er aan hebben gedaan.

De volgende vraag is dan ook niet meer dan logisch:
Is er een meldingsprocedure voor beveiligingsincidenten?

In de meest enge zin is het een procedure die op papier staat en die onder een dikke laag stof is opgeborgen. Leuk dat we ooit zo’n stap hebben gezet, maar dat was toch nooit het doel? Nee, het doel is dat we een juist mechanisme voor detectie hebben. Dat kan deels geautomatiseerd (door allerlei alarmsystemen of intrusion detection systems) maar kan ook gewoon door onze mensen te verzoeken hun ogen open te houden en vreemde zaken te melden.

Juist als het gaat om het melden van incidenten is het van belang om het juiste optimum te vinden tussen de risico’s die we af willen dekken en de maatregelen die we treffen. Teveel maatregelen zorgt ervoor dat de medewerkers juist gedwongen worden de regels te overtreden omdat ze anders hun werk niet kunnen doen.

Een voorbeeld? Ok, dat kan: stel dat we voor 20 applicaties een inlognaam en wachtwoord verstrekken. Het wachtwoord moet om de 90 dagen worden gewijzigd, maar voor alle 20 applicaties is dat op een andere dag. Ook zijn de eisen die we stellen aan de wachtwoorden per applicatie verschillend. Zo moeten we bij de een 2 cijfers, 2 hoofdletters en minimaal 8 karakters gebruiken terwijl we bij de andere applicatie dan maar 6 karakters vereisen. Geen mens dat 20 wachtwoorden kan onthouden, dus we schrijven het op een post-IT en plakken het onder het toetsenbord…een duidelijk geval waarbij we het optimum nog niet hebben gevonden.

Nu weer terug naar de meldingsprocedure. Een voorwaarde daarvoor is dat we het de ontdekker van het incident zo makkelijk mogelijk maken en hij of zij moet het ook nog eens anoniem kunnen melden als dat even mogelijk is. Dus niet iemand 20 minuten in de wachtstand zetten als hij de helpdesk belt, nee, gewoon het nummer noteren en zelf, actief, terugbellen. Dat is niet alleen goed voor de beveiligingsincidenten maar ook nog eens erg klantvriendelijk.

Neem als voorbeeld de phishing mails die we tegenwoordig allemaal ontvangen. Vaak van grote banken omdat daar nu eenmaal het geld te halen is. Zelf wil ik graag dergelijke mails doorsturen naar de banken zodat ze ze kunnen analyseren en de bijbehorende sites uit de lucht kunnen laten halen. Heb wel eens, tevergeefs, gezocht naar waar ik het dan heen kon sturen…helaas. Nu verdwijnen ze in de “verwijderde items” en wordt er niets mee gedaan. Een gemiste kans als je het mij vraagt. Natuurlijk zal de bank deze mails best ontvangen en analyseren…maar ik wil graag mijn bijdrage leveren…en dat versterkt ook nog eens het gevoel dat ik bij die bank heb (klantbetrokkenheid).

Een leuke tegenstrijdigheid bij het juist invoeren van een meldingsprocedure is dat we in eerste instantie meer incidenten gemeld krijgen. Vaak horen we dat dat lastig te “verkopen” is aan het management. Hoe kan dat nou? We doen er alles aan en het aantal incidenten gaat juist omhoog. Niet waar natuurlijk, dat aantal incidenten (en waarschijnlijk nog veel meer dan die we weten) was er altijd al, alleen krijgen we er nu zicht op. Krijgen we er zicht op dan kunnen we er ook wat aan doen. Na verloop van tijd en veel fine tuning zal dan het aantal meldingen afnemen en hebben we ons doel bereikt.

Willen we alleen maar compliant zijn dan volstaat misschien een stoffige papieren meldingsprocedure, maar willen we echt “in control” raken dan maken we dankbaar gebruik van de informatie die we ontvangen.

Beveiligingsincidenten

  door

Als we beveiliging goed (genoeg) inrichten dan kunnen we er op vertrouwen dat we de risico’s voldoende hebben afgedekt. Preventief zijn we bezig om juist die activiteiten op te pakken die bijdragen aan de continuïteit van onze organisatie. Toch zullen we zien dat preventieve maatregelen alleen niet genoeg zijn, nee, we zullen ook detectie moeten inregelen voor het geval er toch iets onverwachts gebeurt. We moeten met onze repressieve en correctieve maatregelen daarop in kunnen spelen om zo snel mogelijk terug te gaan naar de “business as usual”.

De vraag die daarbij speelt is:
Is er vastgelegd wat verstaan wordt onder beveiligingsincidenten?

Vanuit de IT zijn we gewend om te werken met incidenten. Een verstoring van de applicatie melden we bij de helpdesk zodat we zo snel mogelijk weer aan het werk kunnen. Logisch en als we er echt serieus mee bezig zijn dan richten we het incident management proces in conform ITIL.

Daar moeten we vooral mee door blijven gaan, want dit is zeker een aspect dat bijdraagt aan de continuïteit van de organisatie. Toch moeten we ook na gaan denken over wat we exact verstaan onder een beveiligingsincident. Deze kan veel overeenkomsten vertonen met een incident (conform IT), maar kan wel degelijk op een andere wijze worden opgelost.

Om het niet te cryptisch te maken even een kort voorbeeld: stel je komt terug van vakantie en bent je wachtwoord vergeten. Je probeert 3x in te loggen en blokkeert helaas je account. Helpdesk bellen en na een paar minuten kun je gelukkig toch weer aan de slag. Een incident dat we op moeten lossen omdat je anders liever weer terug gaat naar je vakantieadres. Maar stel nu dat tijdens jouw afwezigheid een collega geprobeerd heeft om met jouw account in te loggen. Hij moest even in je mailbox zijn om een mailtje te lezen. Jij komt terug en kunt niet meer inloggen, terwijl je er zeker van bent dat je het juiste wachtwoord hebt gebruikt. Verstaan we dit nog onder een incident of hebben we het hier toch eerder over een beveiligingsincident?

Enerzijds is het dus niet altijd gemakkelijk om de juiste definitie te hanteren voor beveiligingsincidenten, maar anderzijds is het ook nog lastig om ze te detecteren. Hoe kan de medewerker van de helpdesk nu weten of het een incident is omdat jij je wachtwoord bent vergeten of dat het een beveiligingsincident is omdat een collega geprobeerd heeft in te loggen?

Lekker relevant zul je zeggen. Ik ben net terug van vakantie en wil (of moet) weer aan de slag. Toch is het voor de beveiligingsaanpak relevant. Misschien probeert die collega namelijk nog wel meer illegale activiteiten uit te voeren. Stel dat het was gelukt om in te loggen en dat hij namens jouw een mail had gestuurd aan de directeur die hij voor stommeling uit maakt dan zijn de gevolgen wel anders.

Vanuit beveiligingsoptiek willen we graag weten welke beveiligingsincidenten zich voordoen. Hier kunnen we namelijk onze aanpak op bijstellen. Doen we de juiste dingen en doen we de dingen nog juist? Het verschil tussen een incident en een beveiligingsincident kan hier het verschil in maken.

Omgang met informatiebeveiligingsplannen

  door

Zoals we gisteren al schreven, maken we geen beveiligingsplannen om ze in de kast te zetten en ze te laten verstoffen. Nee, de beveiligingsplannen hebben een doel en we moeten dus ook goed kijken wat we exact met deze plannen willen en kunnen bereiken.

De vraag die daarbij hoort, is:
Is er een goed begrip binnen de organisatie met betrekking tot de omgang met deze beveiligingsplannen?

De plannen die we opstellen moeten ervoor zorgen dat de gemaakte keuzes vastliggen. Zover niets bijzonders, dat kan inderdaad eenmalig en vervolgens laten we flinke lagen stof ontstaan op deze plannen. Maar dat kan nooit het doel zijn. De plannen leggen vast wat we beloven, we zullen ze dus als kaders moeten gebruiken bij het afdekken van risico’s en het implementeren van maatregelen.

Dat zouden we natuurlijk ook eenmalig kunnen doen. Maar dan lijkt het meer op een projectplan dan op een beveiligingsplan. Een project is immers uniek en voeren we eenmalig uit, maar beveiliging is geen eenmalige activiteit. Nee, beveiliging is een continu proces.

Daarom moeten we na verloop van tijd goed kijken of onze plannen nog aansluiten bij de risico’s. Het kan best zo zijn dat de risico’s inmiddels gewijzigd zijn. Er zijn nieuwe dreigingen bij gekomen, de omgeving is gewijzigd of het risicogedrag van de organisatie is bijgesteld.

Nu vormen de plannen een mooie basis om onze evaluatie uit te voeren. Doen we het conform plan? Moeten we het plan bijstellen? De “lessons learned” helpen ons verder op onze weg om het juiste niveau van beveiliging te bereiken. Niet te weinig, maar zeker ook niet teveel doen.

De praktijk leert ons dat we bij de eerste cyclus die we doen eerder te weinig of het verkeerde aan beveiliging doen omdat we nog niet helemaal gewend zijn om risico’s af te dekken en niet slechts maatregelen te implementeren. Naarmate we verder in het traject komen zien we dat we juist eerder maatregelen af kunnen schaffen of technische maatregelen kunnen vervangen door organisatorische (die vaak goedkoper zijn en meer effect sorteren). Dat komt omdat iedereen zijn of haar rol beter in gaat vullen en beter leert te denken in de risico’s. Die risico’s hoeven we niet per definitie af te dekken en al helemaal niet met technische maatregelen, nee, we leren beter te kijken naar kosten en baten en daarmee bereikt de beveiliging al een beter niveau.

Informatiebeveiligingsplannen

  door

We hebben nu een basis beveiligingsniveau en voeren afzonderlijke risico analyses uit voor de verschillende systemen, de verschillende gebouwen, de processen, de projecten en alles waarbij we beveiliging in moeten bouwen. We willen deze informatie en onze keuzes niet verloren laten gaan en het mag ook niet bij een beperkt aantal mensen in het hoofd zitten. Nee, we moeten een aantal zaken vast gaan leggen.

De vraag die hierbij hoort is:
Zijn de beveiligingsmaatregelen per informatiesysteem vastgelegd in beveiligingsplannen?

Hoe een beveiligingsplan er exact uit komt te zien kan per organisatie verschillen. Wel kunnen we op centraal niveau onze eisen stellen aan dergelijke plannen. Wat willen we er minimaal in hebben, wie is er verantwoordelijk voor en welk format hanteren we. De basis voor het beveiligingsplan is het basis beveiligingsniveau aangevuld met de resultaten van onze risico analyse. We weten welke risico’s we lopen en hebben keuzes gemaakt voor de beheersingsmaatregelen die we willen treffen. Dergelijke zaken leggen we vast.

We leggen ze daarbij niet vast omdat we kasten vol met papier willen, maar omdat we in een later stadium na willen gaan waarom we sommige keuzes gemaakt hebben. Het kan immers best zo zijn dat we nu een keuze maken die logisch is, maar die over een poosje meer vragen dan antwoorden oproept.

Ook willen we voorkomen dat de aanpak die we hanteren en de maatregelen die we treffen alleen in het hoofd van een beperkt aantal functionarissen zit. Het risico is immers dat deze mensen ooit de organisatie verlaten en we blind worden voor de risico’s en de maatregelen.

Daarnaast kan het beveiligingsplan goed dienen als normenkader voor de auditors die komen controleren of onze aanpak echt zo goed is. Natuurlijk kunnen ze keuzes ter discussie stellen, maar dat is niet erg. Hebben we geen beveiligingsplan dan is het risico groot dat ze met een eigen normenkader aan de slag gaan en zelf keuzes maken. Het gevolg is dat wij de auditfindings aan de broek krijgen, terwijl we juist bewuste keuzes hadden gemaakt om risico’s te accepteren.

Het voordeel van beveiligingsplannen is dat we aantoonbaar kunnen maken dat we serieus met beveiliging (en risicomanagement) bezig zijn en dat onze keuzes ook in de toekomst nog terug te halen zijn. Gebruiken we de formats die op centraal niveau zijn vastgesteld dan ontstaat er herkenning van deze plannen en dat draagt weer bij aan het bewustzijn binnen de organisatie.

Natuurlijk heeft het ook een keerzijde. We kunnen gewezen worden op onze keuzes, doen we het niet conform onze plannen dan kunnen we daarop worden aangesproken. Maar draagt dit nu juist niet bij aan het volwassen worden van beveiliging binnen onze organisatie?

Beveiliging: centraal of decentraal

  door

Gisteren hebben we al gezien dat het wiel dat we uitvinden rond is en dat we er daarom ook voor kunnen kiezen om te gaan werken met een basis beveiligingsniveau. Bovenop dat basisniveau implementeren we dan de aanvullende maatregelen die komen uit onze risico analyse (want die doen we, toch?).

Maar als we er dan toch voor kiezen om een aantal maatregelen standaard te implementeren. Dan is de volgende vraag een logisch vervolg:
Is vastgesteld welke beveiligingsmaatregelen centraal en/of decentraal genomen (moeten) zijn?

Gaan we werken vanuit een basisniveau, corporate security framework, beveiligingspolicy of weet ik welke naam er binnen jouw organisatie aan gegeven is, dan kunnen we ook onderscheid gaan maken in de maatregelen die we centraal of juist decentraal moeten nemen.

Een beleidsdocument dat geldt voor de gehele organisatie is logischerwijs natuurlijk al snel een centrale maatregel die we eventueel op lokaal (decentraal) niveau door kunnen vertalen naar de specifieke eisen, wensen, wet- en regelgeving. Stel dat we in het beleid bepalen dat we aan toegangsbeveiliging tot ons gebouw gaan doen, dan kunnen we lokaal kijken of we dat doen met een toegangscontrole systeem op basis van toegangspasjes of dat we er toch liever voor kiezen om een gewapende wacht met een kalashnikov voor de deur te zetten.

Je zult zien dat het abstractieniveau nodig is omdat we niet voor iedere locatie, ieder land, ieder systeem dezelfde maatregel voor kunnen schrijven. Die gewapende wacht met een kalashnikov is in het buitenland misschien heel normaal, maar in Nederland is het niet toegestaan. Daarmee zouden we dus de wet overtreden.

Maar het gaat om meer dan de wet overtreden. We haalden eerder al het voorbeeld aan waarbij we ervoor kozen om te werken met een inlognaam, pincode en toegangspas. Maar kunnen alle systemen daar wel mee over weg? Hebben we niet wat, inmiddels verouderde, systemen staan die met pijn en moeite met inlognaam en wachtwoord werken? Naast de mogelijke overtreding van wetgeving moeten we er dus ook naar kijken wat (technisch) haalbaar is.

Juist daarom is het dus de kunst om het abstractieniveau zodanig te kiezen dat het algemeen toepasbaar is, maar niet zo algemeen dat het niet meer de richting voor beveiliging aangeeft. Hebben we dat gedaan en komen we uit op allerlei standaard maatregelen die we minimaal implementeren dan kunnen we daarbij ook kijken wat we daarvan centraal beleggen en wat we aan de lijnorganisatie over laten.

Laten we teveel in de lijn liggen dan is er weinig uniformiteit en bestaat het risico dat het een allegaartje wordt. Doen we echter teveel op centraal niveau dan zal er in de organisatie weinig betrokkenheid bij het afdekken van risico’s ontstaan. Willen we het goed doen dan moeten we kijken naar de cultuur van de organisatie en kunnen we kijken naar hoe we het op andere vlakken hebben ingericht. Is voor P&O zaken bijvoorbeeld veel belegd op decentraal niveau, dan is dat misschien een goed voorbeeld voor de aanpak van beveiliging.

In de praktijk lijkt het er op dat een top-down benadering van beveiliging veelal wat meer centraal aangestuurd wordt, terwijl een bottom-up benadering juist meer activiteiten in de lijn belegd. Hoe is jouw organisatie ingericht en zegt ons dat al iets over de wijze waarop we beveiliging daarin in kunnen passen? Het advies is om het vooral niet anders in te richten dan de rest van de zaken in de organisatie, beveiliging is al lastig genoeg, dus we zitten niet op allerlei organisatorische afwijkingen te wachten, toch?

Basis beveiligingsniveau

  door

We zijn inmiddels een aardig stuk onderweg en zijn al goed bezig om beveiliging ook echt werkend en geborgd te krijgen in de organisatie. We doen aan risico analyse en bepalen wat ons risicogedrag is. Voor die risico’s die we niet kunnen accepteren gaan we op onderzoek uit om de beheersingsmaatregelen te bepalen.

Hierbij komen we al snel tot de conclusie dat een aantal van die maatregelen toch minimaal geïmplementeerd moeten zijn en dat we iedere keer terug komen op diezelfde maatregelen (een deur in een gebouw is toch wel handig om buitenstaanders buiten te houden). Om te voorkomen dat we iedereen afzonderlijk deze basis maatregelen laten bepalen, gaan we op zoek naar de grote gemene deler.

De vraag die we daarom stellen is:
Is er een vastgesteld basis beveiligingsniveau waaraan alle informatiesystemen (maar ok gebouwen, processen, etc.) minimaal moeten voldoen?

Door de hele organisatie heen kunnen we een basis leggen waaraan we minimaal moeten voldoen. We nemen steeds dezelfde maatregelen en proberen die zo uniform mogelijk te maken. Waarom zouden we het wiel iedere keer opnieuw uitvinden als we toch weten dat een wiel dat rond is, het beste rolt?

Gelukkig kunnen we gebruik maken van allerlei standaarden die er op de markt te verkrijgen zijn. Neem bijvoorbeeld de Code voor Informatiebeveiliging waar we het basis beveiligingsniveau uit af kunnen leiden. Met common sense, of gewoon boeren verstand, kunnen we echt wel bepalen wat we als standaard zouden moeten hanteren.

We moeten echter wel even stil staan bij het abstractieniveau waarop we het basis beveiligingsniveau bepalen. Willen we bijvoorbeeld als standaard opnemen dat we iets aan logische toegangsbeveiliging moeten doen of nemen we expliciet op dat er gebruik moet worden gemaakt van een inlognaam, pincode en toegangspas? Dat laatste is misschien wel concreet, maar gaat het voor ieder systeem werken? We zijn natuurlijk niet op zoek naar papierentijgers maar naar een aanpak die ook echt de risico’s afdekt.

De kunst is juist om het optimum te vinden in het abstractieniveau en vervolgens de detaillering of specifieke invulling over te laten aan degene die we verantwoordelijk hebben gemaakt voor het informatiesysteem, maar net zo goed voor het fysieke gebouw en processen natuurlijk, want ook daarvoor kunnen we basis beveiligingsniveaus opstellen.

Het voordeel is dat we uniform maatregelen kunnen implementeren en dat we niet iedere keer opzoek hoeven naar zaken die standaard al ingeregeld zijn. Een juiste omgang met een basis beveiligingsniveau ondersteund dus het lijnmanagement, zorgt ervoor dat we aan de minimale eisen voldoen die passend is voor onze bedrijfsstrategie en kan er ook nog eens voor zorgen dat we schaalvoordelen bereiken bij de aanschaf van maatregelen.

Nog niet nagedacht over het basis beveiligingsniveau? Dan is dat nu een mooi moment om te doen voordat we verzanden in allerlei dubbele of onzinnige maatregelen die uiteindelijk veel meer kosten dan ze opleveren.

Beveiligingseisen in de keten

  door

Ja hoor, hier is hij weer: de keten is zo zwak als de zwakste schakel. Hoe vaak hebben we dat inmiddels niet genoemd? Misschien te vaak, maar toch geldt ook voor de eisen de we stellen aan beschikbaarheid, exclusiviteit en integriteit dat we over onze eigen grenzen heen moeten kijken om het goed te regelen.

Daarom de volgende vraag:
Zijn de eisen ten aanzien van de waarborging van de beschikbaarheid, exclusiviteit en integriteit in de systeemketen (IV-keten) afgestemd?

Allemaal erg leuk en aardig als we ons huis op orde hebben, maar wat als de buren er een zooitje van maken? Hoe ziet de straat er dan uit? Juist. Intern mogen we dan hard werken aan verdere professionalisering van onze bedrijfsprocessen en informatiesystemen, maar deze staan veelal niet los van de systemen die leveranciers of andere interne afdelingen aanbieden. Heeft de leverancier zijn zaakje niet op orde dan ondervinden wij daar last van en als wij daar last van ondervinden dan ondervinden onze klanten daar nog meer last van. De vraag is zomaar wie dat wordt aangerekend? Weet de klant eigenlijk wel dat we dat systeem hebben uitbesteed of schaadt het juist ons imago als het fout gaat?

Meestal is het laatste het geval en voor de klant natuurlijk terecht. Die heeft immers helemaal niets te maken met jouw leveranciers. Nee, hij of zij wil gewoon een dienst geleverd krijgen, daarvoor wordt goed geld betaald en jij moet er maar voor zorgen dat de keten werkt.

Stel je koopt een paar gloednieuwe schoenen bij de schoenwinkel. Je kiest voor kwaliteit en die kwaliteit heeft uiteraard een prijs. Na 2 dagen zit er al een gat in je zool en je gaat terug naar de schoenwinkel. De schoenwinkel kan natuurlijk zeggen dat het aan de fabrikant ligt, maar daar heb jij geen boodschap aan. Nee, de schoenwinkel moet gewoon een nieuw paar leveren en gaat maar lekker zelf in conclaaf met de fabrikant of importeur. Zo ook voor informatiesystemen. Als consument koop ik een dienst, daar betaal ik voor en of je leverancier het nu goed doet of niet, ik wil gewoon gebruik maken van die dienst en daar heb jij voor te zorgen.

Leuk dus dat wij allemaal eisen stellen aan de beschikbaarheid, exclusiviteit en integriteit van de informatie. Maar als de keten inderdaad zo zwak is als de zwakste schakel dan zullen we in overleg moeten met die zwakste schakel. Kan hij voldoen aan onze eisen? Moeten we aanvullende maatregelen nemen? Of moeten we accepteren dat we de eisen naar beneden toe bijstellen?

Leuk dat we een eis stellen van 99,9% beschikbaarheid voor een applicatie, maar als die applicatie gebruik maakt van het internet…welke beschikbaarheid is gegarandeerd door onze internetprovider? Als we voor ons netwerk een garantie afgeven van 95%, kunnen we dan voor afzonderlijke applicaties 99,9% garanderen?

Hier is een waarschuwing op zijn plaats. Er worden hoge percentages geroepen naar de klant toe (en daar betaald de klant grof voor), maar wat houdt dat percentage precies in? Of anders gezegd: wat is de scope? Het kan zijn dat er voor een applicatie bijvoorbeeld 99,9% wordt afgegeven maar dat het netwerk buiten de scope valt. Als je niet oplet betaal je kapitalen terwijl de end-to-end beschikbaarheid eigenlijk niet gegarandeerd kan worden. Leuk dat die applicatie gewoon doordraait (in het rekencentrum) als het internet een storing geeft, maar op afstand kunnen wij ons werk niet doen omdat de applicatie niet benaderbaar is, en daar ging het nu toch juist om?

Nee, ook bij het stellen van eisen aan de beschikbaarheid, exclusiviteit en integriteit moeten we goed kijken dat het geen wassen neus wordt en dat we niet teveel betalen. Als de zwakste schakel “slechts” 90% kan garanderen dan moeten we geen 99,9% aan de klant verkopen…tenminste als we integer willen zijn. Bij het stellen van de eisen moeten we dus een goede analyse loslaten op de keten, willen we de eisen naar boven toe bijstellen dan zal dat doorgevoerd moeten worden in die gehele keten. De dooddoener blijkt maar weer eens waar te zijn: de keten is zo zwak als de zwakste schakel.