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?