Bekendheid met meldingsplicht beveiligingsincidenten

Zo, inmiddels hebben we de medewerkers verteld dat ze beveiligingsincidenten moeten melden en we hebben ze ook geprobeerd duidelijk te maken wat wij onder beveiligingsincidenten verstaan. Nu is het natuurlijk de vraag of het aantal meldingen inderdaad toeneemt.

Het gaat dus niet zozeer om de vraag, maar het feit of het ook echt werkt. De vraag:
Is het personeel duidelijk gemaakt dat beveiligingsincidenten gemeld moeten worden?

Bekende termen zijn “opzet”, “bestaan” en “werking”. In opzet en bestaan kunnen we het best goed geregeld hebben. We hebben mooie beleidsdocumenten, mooie procedures en voorschriften en we hebben ze ook nog eens beschikbaar gesteld op het intranet en via de mail aan iedereen verzonden. Nu willen we toch wel graag weten of het allemaal effect heeft, oftewel: werkt het? Want daar gaat het toch uiteindelijk allemaal om, is het niet?

We kunnen de medewerkers natuurlijk allemaal op de man (of vrouw) af vragen of ze weten dat ze beveiligingsincidenten moeten melden. Grote kans dat het antwoord volmondig ja is. Het is immers logisch dat we dat soort zaken melden. Toch is hier het risico op sociaal wenselijke antwoorden te groot. We zullen dus op zoek moeten naar aanvullende mogelijkheden om te testen of er ook echt gemeld wordt.

Nu wil ik je natuurlijk niet aanmoedigen om allerlei illegale of niet toegestane acties uit te voeren, maar er zijn best manieren om te kijken hoe het er mee gesteld is. Is het zichtbaar dragen van toegangspasjes binnen jouw bedrijf bijvoorbeeld verplicht? Draag dan het pasje eens een dag niet zichtbaar om te kijken of je er op wordt aangesproken (dat werk natuurlijk minder goed als je iedereen binnen het bedrijf persoonlijk kent).

Loop eind van de dag, als iedereen al lekker naar huis is, nog eens een rondje over je afdeling en kijk welke waardevolle spullen of informatie voor het grijpen ligt. Je zou dat kunnen melden, je zou er niets mee kunnen doen, of je zou de informatie kunnen verzamelen en eventueel een briefje achter kunnen laten dat ze het bij jou op kunnen komen halen. In principe mist iemand de volgende dag de informatie en hij gaat op zoek. Heb je een briefje achter gelaten dan zal hij het bij je op komen halen, ligt dat briefje er niet dan zal hij met een zoekende blik over de afdeling lopen.

Laat eens een deur open staan (uiteraard even in de gaten houden wie er stiekem naar binnen glipt) en kijk wat mensen doen. Laten ze de deur zelf ook open staan, doen ze de deur juist dicht of bellen ze even met de beveiliging om door te geven dat deze deur open staat?

Een aantal simpele manieren om te testen hoe het gesteld is met de beveiligingscultuur van de medewerkers. Nemen ze zelf actie, doen ze juist helemaal niets of maken ze er melding van? Zodra we dat weten kunnen we weer volgende stappen zetten en het melden van beveiligingsincidenten verder onder de aandacht brengen.

We moeten er dan natuurlijk wel voor zorgen dat het melden makkelijk is. Dus geen lange wachttijden als ze telefonisch melden en geen ingewikkelde formulieren om het op papier te doen.

Een leuke optie is om er een competitie van te maken. Iedere zoveelste melder krijgt een taart, gemelde beveiligingsincidenten worden gebruikt om de medewerkers te trainen (bijvoorbeeld door ze te behandelen in ons “security krantje”). Oppassen natuurlijk dat medewerkers er geen sport van gaan maken om maar zoveel mogelijk incidenten te veroorzaken, dan schieten we juist weer door naar de verkeerde kant.

Voorwaarde is natuurlijk wel dat we over voldoende (en kwalitatief goede) capaciteit beschikken om de incidenten op te pakken, te analyseren en verbeteringen door te voeren.

Beveiligingsincidenten zien er op papier vaak ingewikkeld uit: zware aanvallen op het netwerk, ramkraken om ons gebouw binnen te dringen…maar juist de dagelijkse gang van zaken kunnen grote risico’s met zich meebrengen en voor die dagelijkse gang van zaken hebben we de oren en ogen van onze medewerkers nodig om de boel steeds veiliger te krijgen.

Voorschriften voor vertrouwelijke informatie

Gaan we het nu alweer over voorschriften voor informatie hebben? Ehm, juist, inderdaad. De nuance zit hem nu in het feit dat het hier over vertrouwelijke informatie gaat. We willen immers niet dat onze informatie op straat komt, maar we willen al helemaal niet dat onze vertrouwelijke informatie daar belandt.

De vraag:
Zijn er voorschriften opgesteld ter bescherming van vertrouwelijke informatie tegen onbevoegde kennisneming, verlies en/of beschadiging?

Het interessante bij deze vraag is dat gegevens afzonderlijk niet vertrouwelijk hoeven te zijn, maar dat als we ze samen brengen ze dat in eens wel weer zijn. Vergelijk het met je inlognaam en wachtwoord. Afzonderlijk van elkaar kun je er niet zoveel mee (ja, ja, ik weet het met illegale activiteiten kun je alsnog erg ver komen, maar dat gaat voor nu te ver). Brengen we ze echter samen dan zijn we ineens een stap verder. Als je weet dat mijn inlognaam “pietje1234” is dan is dat een feit. Weet je aan de andere kant dat mijn wachtwoord “Welkom01” is dan heb je wederom een feit te pakken. Ken je beide en weet je dat ik via Hotmail mail dan is het een koud kunstje om namens mij in te loggen.

Ik wil je overigens nergens toe aansporen. De gegevens zijn natuurlijk fictief…maar excuses voor alle Pietjes en voor alle mensen die Welkom01 als wachtwoord gebruiken.

Dezelfde parallel geldt voor de gegevens in veel van onze databases. De afzonderlijke gegevens zeggen misschien niet zoveel, maar de combinatie van meerdere gegevens kan ineens vertrouwelijk zijn. Juist daarom willen we extra inzoomen op de voorschriften voor vertrouwelijke informatie.

Natuurlijk willen we gemeld hebben als niet vertrouwelijke informatie in verkeerde handen terecht is gekomen of als we die op het dak van onze auto hebben achtergelaten voordat we wegreden (geloof me, het gebeurt vaker dan je denkt). Maar misschien moeten we wel andere stappen ondernemen als blijkt dat het hier om vertrouwelijke informatie ging.

Een issue daarbij is dat medewerkers er, in enkele gevallen, niet bij gebaat zijn om het te melden. Stel je voor, straks volgen er sancties. Nee, we beschouwen de informatie als verloren en maken gewoon een nieuw printje. Natuurlijk kunnen we bepalen om sancties op te leggen bij dergelijke incidenten. We geven de medewerker een veeg uit de pan en in het ergste geval nemen we afscheid van elkaar. Dat is toch een beetje de put dempen als het kalf verdronken is. Beter is het om te proberen de schade te beperken. Analyseer wat er gebeurt is en of we de informatie wellicht nog terug kunnen krijgen zonder dat ons imago kleerscheuren oploopt.

Lukt dat niet omdat we de informatie echt uit het oog zijn verloren, dan zullen we met de billen bloot moeten. We kunnen natuurlijk met ons voltallig personeel gaan zitten duimen, in de hoop dat de informatie niet ineens in de krant belandt…maar dat kan destructief zijn voor ons imago en is dus erg risicovol. Aan de andere kant, als we onze verantwoordelijkheid nemen en de klant informeren dat we zijn gegevens rond hebben laten slingeren, dan weten we zeker dat we in de krant komen.

Een lastig besluit en in heel veel gevallen een besluit dat we niet vanuit beveiliging moeten nemen. Nee, we informeren de juiste managementlagen en komen misschien zelfs met het crisisteam bij elkaar om het vervolg te bepalen. Geen leuke situatie natuurlijk, maar wel van groot belang. Dergelijke incidenten willen we niet onder onze beveiligingspet houden, daar is ons petje te klein voor.

Vertrouwelijke informatie verdient dus wat extra aandacht…en laat dat “wat” eigenlijk maar weg. We moeten zowel preventief, detectief, correctief als repressief extra nadenken over de impact van die informatie. Doen we dat niet dan staan we vast en zeker binnenkort in de krant…en negatieve berichten zijn ook reclame, maar of we daar op zitten te wachten is de vraag.

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.

Werknemers ontslagen na melden beveiligingslek

Twee werknemers van een Amerikaans energiebedrijf, zeggen ontslagen te zijn omdat ze een beveiligingslek hebben gemeld (bron). De twee ontdekten en rapporteerden dat ongeautoriseerde computers op het mainframe van de centrale waren aangesloten. Het systeem van de centrale zou ook op software zijn aangesloten die zich nog in de testfase bevond. Verder zouden teveel werknemers toegang tot de computers hebben. Reden genoeg voor de twee om alarm te slaan vorige week hoorden ze dat ze ontslagen waren.

Hartstikke goed (not), shoot the messengers: ontslaan die mensen. Het levert alleen maar werk en kosten op als iedereen incidenten en lekken gaat melden. Nee struisvogel politiek is in dit geval de juiste keuze, kop in het zand dan zien we niks en wat we niet zien gebeurt ook niet.

Voordeel voor het energiebedrijf is natuurlijk wel dat geen van de werknemers het meer in zijn hoofd zal halen om lekken te melden, het kan je de kop kosten. Als er geen lekken gemeld worden, dan zijn er ook geen lekken en zijn we dus veilig. Ehm, benieuwd wanneer er een power down plaats zal vinden in deze stad, als ik daar woonde zou ik toch maar een generator aanschaffen.

Ik zeg: maak ze medewerkers van de maand, ze hadden een energiebedrijf kunnen behoeden voor grote gevolgen en de gevolgen van de klanten. Als binnenkort het licht uitgaat zal er door de klanten een behoorlijke claim worden neergelegd. Ben benieuwd of we er ooit nog wat van horen.