Tag: meldingsprocedure

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.