Tag: beveiligingsincident

Beveiligingsincidenten: melden, vastleggen, analyseren en rapporteren

  door

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.

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.

Veilig internetten geen prioriteit bij studenten

  door

Een onderzoek van SURFnet in samenwerking met een aantal hoger onderwijs- en onderzoeksinstellingen naar het beveiligingsbewustzijn van studenten en medewerkers, laat zien dat de aandacht voor internetbeveiliging onder studenten laag is (bron).

Ai, dit is een pijnlijk probleem voor de toekomst. De jeugd heeft de toekomst maar als de jeugd onvoldoende beveiligingsbewust is dan hebben we nog een hoop werk te doen. De studenten van nu zijn de directeuren van de toekomst. Als ze zich nu al geen raad weten met de beveiliging hoe moet dat dan voor de bedrijven die ze gaan leiden in de toekomst? Wordt het dan leiden of lijden?

Jammer is dat het onderzoek niet heeft geprobeerd te achterhalen wat de oorzaken zijn. Dat is wat ons nu juist moet interesseren. Niet alleen voor de studenten maar juist ook voor het bedrijfsleven. Kennen we de oorzaken niet dan kunnen we alleen aan symptoombestrijding doen.

Probeer bij een beveiligingsprobleem of incident in je praktijksituatie eens te achterhalen wat de oorzaak is en dan bedoel ik de echte oorzaak, dus niet het sociaal wenselijke antwoord dat we krijgen. Nee, vraag nog even door. Wat bedoel ik hier nu weer mee? Ik zal het kort proberen toe te lichten: een medewerker veroorzaakt een incident. Is dan de medewerker de oorzaak (zo ja dan moeten we daar dus wat aan doen), maar is dat wel echt zo? In veel gevallen is de medewerker niet de oorzaak, ja hij veroorzaakt het probleem, maar waarom? Doorvragen dus. Wist hij niet dat hetgeen hij deed een risico vormde? Was er voor hem geen andere mogelijkheid om zijn werk uit te voeren? En ga zo nog maar even door.

Als hij niet wist dat het een risico vormde wat hij deed dan moeten we ons dat zelf kwalijk nemen. Blijkbaar is het ons niet gelukt om onze kennis voldoende bij hem over te brengen (zijn wij nu ineens de oorzaak? En moeten we daar dan niets aan doen?). Had de medewerker wel de middelen om het veilig te doen?

Neem als voorbeeld maar eens het gebruik van (privé) webmail binnen organisaties. De medewerker stuurt via webmail documenten naar zijn privé adres om er thuis verder aan te kunnen werken. “Strafbaar” feit omdat we in ons beleid hebben opgenomen dat dat niet mag? Of is dit de enige manier voor de medewerker om zijn deadline te halen? Moeten we er bijvoorbeeld niet voor zorgen dat hij een veilige thuiswerkplek heeft of moeten we hem niet een veilige USB-stick geven? Dat zouden we kunnen doen, maar waar we ook eens naar moeten kijken is de werkdruk die we hem hebben opgelegd.

Te vaak zien we nog dat managers opdrachten accepteren van de directie zonder daarbij met de medewerkers af te stemmen. De manager zegt dat het morgen af is (commitment aan de directie) en schuift het probleem door naar de medewerker. De medewerker op zijn beurt wil zijn manager niet teleurstellen (of is bang dat hij zijn bonus niet haalt) en gaat tegen beter weten in de opdracht aan. Hij mailt de nodige informatie naar zijn huisadres, maakt een typefout en het staat morgen in de krant.

Mogen jullie drie keer raden wie hier voor opdraait? De directie, de manager of de medewerker?
Al snel zullen we wijzen naar de medewerker, toch? Natuurlijk had de medewerker nooit de informatie over een onbeveiligde lijn moeten versturen, maar waarom deed hij dat? Om zijn manager niet teleur te stellen. De manager gaf hem niet genoeg tijd om zijn werk goed te kunnen doen, is de manager dan niet schuldig aan dit incident? De directie heeft onvoldoende budget ter beschikking gesteld en vindt veilige thuiswerkplekken een te dure oplossing. Is de directie niet schuldig dan?

Zo zie je maar, we zien ogenschijnlijk een beveiligingsincident maar eigenlijk is dat slechts het gevolg van een managementprobleem. Ga voor jezelf nog eens wat actuele beveiligingsincidenten na, was dat echt de schuld van de medewerker of hebben we die als symptoombestrijding de schuld gegeven en was daarmee de kous af?

Deze medewerker zal in de toekomst een dergelijk incident (hopelijk) niet meer veroorzaken maar hoeveel medewerkers kunnen dat nog wel doen? Moeten we niet de echte oorzaken (welke dat ook mogen zijn) proberen weg te nemen door bijvoorbeeld de werkdruk af te stemmen of de juiste middelen ter beschikking te stellen?