Beveiligingsincidenten: melden, vastleggen, analyseren en rapporteren

Vallen we niet in herhaling, zul je zeggen? Voor een deel wel, maar we gaan het hier met name hebben over de verzameling incidenten. Die we, in een eerder stadium gemeld hebben gekregen, die we hebben vastgelegd, die we analyseren en die we vervolgens ook nog eens aan het management rapporteren.

De vraag die we stellen is:
Worden de beveiligingsincidenten gemeld, vastgelegd, geanalyseerd en gerapporteerd?

Het melden van beveiligingsincidenten hebben we eerder al aangehaald. Ik ga er voor het gemak vanuit dat we deze meldingen ook registeren (ja, ik weet het, aannames zijn levensgevaarlijk). Incidenten kunnen losstaand zijn maar kunnen ook onderdeel van een groter probleem zijn. De kunst is nu om door al die verschillende incidenten heen te kijken en de verbanden te leggen tussen meerdere incidenten.

Als dat lukt kunnen we nog meer op zoek naar de echte oorzaken van een probleem. Ook hierbij geldt weer dat een eenmalig incident iets totaal anders kan zijn dan een bundeling van beveiligingsincidenten. Daarom analyseren we op een hoger abstractieniveau wat er zoal gemeld en gebeurd is. Kunnen we daar lijnen in ontdekken dan kunnen we ook structurele oplossingen aandragen.

Stel dat we veel meldingen krijgen van geblokkeerde accounts van een specifieke afdeling. Dat kan toeval zijn, maar het kan ook zo zijn dat meerdere mensen al jaren onder hetzelfde account werken. Persoonlijke accounts zijn in de praktijk groepsaccount geworden. Later zullen we dus niet meer na kunnen gaan welk individu een bepaalde actie heeft gepleegd, maar ook beschikken we zeer waarschijnlijk niet over voldoende licenties wat weer tot boetes kan leiden.

We raken hier met beveiliging het vakgebied van “business intelligence”. Beide ingewikkelde vakgebieden maar als we ze goed in weten te regelen kan dat enorme synergetische voordelen opleveren. De BI-specialist ontwikkeld de methoden om grote aantallen gegevens te analyseren en wij gaan met de uitkomsten van die analyses bedenken welke mogelijke beveiligingsissues daaraan kleven.

Uiteraard maken we ook aan het management inzichtelijk wat er zoal gebeurt. We rapporteren niet de afzonderlijke incidenten (tenzij ze echt noemenswaardig zijn natuurlijk), maar rapporteren de trends en de uitkomsten van de analyses. Zo wordt het management betrokken maar niet lastig gevallen met allerlei technische details (waar ze of geen interesse in of geen verstand van hebben). We zetten beveiliging op de kaart en tonen onze meerwaarde aan voor het bereiken van de doelstellingen van de organisatie. En hoe mooi die doelstellingen vaak ook omschreven zijn, ze komen bijna altijd op het volgende neer: verhoging van omzet (of optimale inzet van budget voor non-profits), verlaging van kosten en bescherming van imago.

Informatiebeveiligingsplannen

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?