ISO 27001 – Bilaga A.16: Informationssäkerhetsincidenthantering

Vad är syftet med bilaga A.16.1?

Bilaga A.16.1 handlar om hantering av informationssäkerhetsincidenter, händelser och svagheter. Målet i detta bilaga A-område är att säkerställa ett konsekvent och effektivt förhållningssätt till livscykeln för incidenter, händelser och svagheter. ISO 27001:2013 tar upp livscykeln tydligt genom A.16.1.1 till A.16.1.7 och det är en viktig del av ledningssystemet för informationssäkerhet (ISMS), särskilt om du vill uppnå ISO 27001-certifiering. Låt oss förstå dessa krav och vad de betyder lite mer djupgående nu.

A.16.1.1 Ansvar och rutiner

En bra kontroll beskriver hur ledningen upprättar ansvar och rutiner för att säkerställa ett snabbt, effektivt och ordnat svar för att åtgärda svagheter, händelser och säkerhetsincidenter. Enkelt uttryckt är en incident där någon form av förlust har inträffat kring konfidentialitet, integritet eller tillgänglighet.

Ett exempel är där ett fönster lämnades öppet och en tjuv stal en viktig fil som satt på skrivbordet... Efter den tråden är en händelse där fönstret lämnades öppet men ingen stal filen. En svaghet är att rutan lätt går sönder eller är gammal och kan vara en självklar plats för inbrott. En svaghet är också en vanlig riskhantering eller förbättringsmöjlighet.

Procedurerna för incident-, händelse- och svaghetsresponsplanering måste vara tydligt definierade innan en incident inträffar och godkänts av ditt ledarskap. Dessa procedurer är ganska lätta att utveckla eftersom resten av denna bilaga A-kontroll stavar dem. Din revisor förväntar sig att se alla dessa formella, dokumenterade rutiner på plats och bevis på att de fungerar.

A.16.1.2 Rapportering av informationssäkerhetshändelser

En bra kontroll här säkerställer att informationssäkerhetsincidenter och händelser kan rapporteras via lämpliga ledningskanaler så snart som möjligt.

Anställda och associerade intressenter (t.ex. leverantörer) måste göras medvetna om sina skyldigheter att rapportera säkerhetsincidenter och du bör täcka det som en del av din allmänna medvetenhet och utbildning. För att göra detta bra måste de ha medvetenhet om exakt vad som utgör en svaghet, händelse eller incident i informationssäkerheten, så var tydlig med det, baserat på det enkla exemplet ovan. Om en informationssäkerhetshändelse inträffar eller tros ha inträffat ska det omedelbart rapporteras till den utsedda informationssäkerhetsadministratören och det behöver dokumenteras därefter.

Några av de möjliga orsakerna till att rapportera en säkerhetsincident inkluderar; ineffektiva säkerhetskontroller; antagna brott mot informationsintegritet eller konfidentialitet, eller tillgänglighetsproblem, t.ex. att inte kunna få tillgång till en tjänst.

Revisorn kommer att vilja se och kommer att ta prover för bevis på medvetenhet om vad som utgör en svaghet, händelse eller incident bland allmän personal, och medvetenhet om incidentrapporteringsprocedurer och ansvar.

A.16.1.3 Rapportering av svagheter i informationssäkerheten

Denna kontroll bygger helt enkelt på incidenter och händelser men kan behandlas något annorlunda när den väl har rapporterats (se A.16.1.4). Det är viktigt för anställda att vara medvetna om det faktum att när de upptäcker en säkerhetsbrist, får de inte försöka bevisa denna svaghet , som att testa det kan tolkas som ett missbruk av systemet, samtidigt som det riskerar att skada systemet och dess lagrade information, vilket orsakar säkerhetsincidenter!

A.16.1.4 Bedömning av och beslut om informationssäkerhetshändelser

Informationssäkerhetshändelser ska bedömas och sedan kan det avgöras om de ska klassas som informationssäkerhetsincidenter, händelser av svagheter. När en säkerhetshändelse väl har rapporterats och sedan loggats måste den utvärderas för att bestämma den bästa åtgärden att vidta. Denna åtgärd måste syfta till att minimera eventuella kompromisser av informationens tillgänglighet, integritet eller konfidentialitet och förhindra ytterligare incidenter. Helst kommer det att ha minimal inverkan på andra användare av tjänsterna. Övervägande av exakt vem som behöver göras medveten om incidenten, internt, kunder, leverantörer, tillsynsmyndigheter kan ske även i denna del av livscykeln.

GDPR och Data Protection Act 2018 innebär att vissa informationssäkerhetsincidenter relaterade till personuppgifter måste rapporteras till tillsynsmyndigheten också, så dina kontroller bör också kopplas till dessa överväganden för att uppfylla regulatoriska krav och undvika dubbelarbete eller luckor i arbetet.

A.16.1.5 Åtgärder vid informationssäkerhetsincidenter

Det är alltid bra att tilldela ägare, vara tydlig med åtgärder och tidsskalor, och som med allt för ISO 27001, behålla informationen för revisionsändamål (även viktigt om du har andra intressenter och tillsynsmyndigheter att ta hänsyn till). Den person som är ansvarig för att hantera säkerhetshändelsen kommer att ansvara för att återställa en normal säkerhetsnivå samtidigt som

• samla in bevis så snart som möjligt efter händelsen;
• genomföra en forensisk analys av informationssäkerhet (stor term men åtminstone vara tydlig med grundorsaken och relaterade aspekter eller vad som hände och vem som var inblandad, varför etc);
• eskalering, om så krävs, till exempel till relevanta tillsynsmyndigheter;
• se till att alla inblandade svarsaktiviteter loggas korrekt för senare analys;
• kommunicera förekomsten av informationssäkerhetsincidenten eller alla relevanta detaljer till ledningen för att de ska kunna vidarebefordras till olika individer eller organisationer på behov av att veta; och
• hantera brister i informationssäkerheten som har visat sig orsaka eller bidra till incidenten.

A.16.1.6 Lärande av informationssäkerhetsincidenter

Detta är en viktig kontroll, och din policy måste visa att kunskap som erhållits genom att analysera och lösa informationssäkerhetsincidenter kommer att användas för att minska sannolikheten eller effekten av framtida incidenter. Som en del av engagemanget för ständiga förbättringar av tjänsterna bör du se till att du drar lärdom av alla säkerhetsincidenter för att därför hjälpa till att utveckla och anpassa ISMS för att möta det föränderliga landskapet som bearbetas i.

När en incident har lösts bör den placeras i en status för granskning och inlärning, där ansvarig för den incidenten kommer att diskutera eventuella ändringar som krävs av processerna för ISMS-policyerna som ett resultat. Alla relevanta rekommendationer bör sedan läggas fram till ISMS-styrelsen för vidare diskussion. När granskningen och lärandet har slutförts, uppdateringar av policyerna har gjorts efter behov, den relevanta personalen måste meddelas och omutbildas vid behov, och cykeln av informationssäkerhetsmedvetenhet och utbildning fortsätter.

A.16.1.7 Insamling av bevis

Organisationen måste definiera och tillämpa kontroller för identifiering, insamling, inhämtning och bevarande av information, som kan användas som bevis, särskilt om det finns straffrättsliga eller civilrättsliga förfaranden som sannolikt kommer att hända från händelsen.

Om organisationen misstänker eller vet att en säkerhetsincident kan leda till rättsliga eller disciplinära åtgärder, bör de genomföra bevisinsamlingen noggrant, säkerställa en god vårdnadskedja och undvika varje hot om att bli gripen av dålig ledning.

Det är förnuftigt att tydligt knyta informationssäkerhetsincidenthantering till disciplinära förfaranden. Alla ska veta att vidta försiktighetsåtgärder samtidigt som de är tydliga med konsekvenserna för dem som inte tar det på allvar.