Under de första timmarna av en säkerhetsincident kan du inte få en fullständig teknisk bild av vad som har hänt. Ditt team kanske fortfarande försöker förstå vilket konto som har komprometterats, vilka uppgifter som har nåtts, hur långt angriparen har kommit eller om incidenten fortfarande är aktiv.

Parallellt med utredningen börjar pressen att agera omedelbart. Medarbetare hör fragment och behöver veta vad de ska göra. Samtidigt kan kunder märka avbrott i tjänsten, misstänkt aktivitet eller ovanliga begäranden om återställning av lösenord. Affärspartner kan fråga om deras system eller uppgifter berörs, och ledningen behöver besluta vem som talar, vad som kan bekräftas och när tystnaden blir en risk i sig.

Kommunikation vid säkerhetsincidenter är svårt eftersom en verksamhet måste vara transparent innan den har alla svar, men samtidigt tillräckligt informerad för att inte gissa. Meddelanden som skickas för tidigt kan skapa förvirring, men om de skickas för sent kan de skada förtroendet, fördröja skyddande åtgärder och väcka regulatoriska frågor.

Det är osannolikt att små och medelstora företag har skapat eller övat på sin plan för incidenthantering, och detta kan orsaka ytterligare kaos. Även för större företag med en plan kan de tekniska stegen vara dokumenterade: begränsa incidenten, återställ åtkomst, bevara bevis, återställ system. Kommunikationen kan lämnas till senare, tills incidenten plötsligt eskalerar eller förändras.

En del av förberedelserna inför en incident är att veta vem som behöver höra av dig, vad de behöver veta, vem som godkänner meddelandet och hur fakta kan kommuniceras tydligt medan utredningen fortfarande pågår.

Kommunikationsplanering hör hemma inom incidenthanteringen

Tvåspårsstrukturen för din respons

Börja med målgruppen, inte med tillkännagivandet

Vad som ska kommuniceras internt

Så meddelar du kunder om ett intrång

När tillsynsmyndigheter ska meddelas

Förbered meddelanden innan du behöver dem

Hur Proton Pass for Business kan hjälpa till

Kommunikationsplanering hör hemma inom incidenthanteringen

Incidenthantering beskrivs ofta som en teknisk process, men en verklig incident blir snabbt tvärfunktionell. IT-team kan begränsa hotet, men ledning, juridik, kundsupport, HR, kommunikation och drift behöver alla veta vad som händer och vad de får säga.

NCSC:s vägledning om effektiv kommunikation vid en cyberincident(nytt fönster) – allmän bästa praxis som gäller långt utanför Storbritannien – gör denna punkt tydlig: organisationer prioriterar ofta den tekniska responsen och skjuter kommunikationen i bakgrunden, trots att kommunikationen formar hur medarbetare, kunder, intressenter och medier uppfattar organisationen under en kris.

Inte varje incident kräver ett offentligt uttalande. Men verksamheten bör i förväg veta vem som beslutar vad som ska kommuniceras, vem som godkänner externa meddelanden, vem som talar med kunder och vem som hanterar rapportering till tillsynsmyndigheter.

En stark plan för hantering av dataintrång behöver innehålla ett kommunikationslager. Detta bör omfatta praktiska detaljer:

  • Kontaktlistor
  • Utkast till mallar
  • Godkännandeflöden
  • Juridisk granskning
  • Talar punkter för kundsupport
  • Ansvarsområden för avisering till tillsynsmyndigheter
  • Register över vad som skickades, när och till vem.

Tvåspårsstrukturen för din respons

Incidenthantering behöver två spår: teknisk respons och kommunikationsrespons. De löper parallellt med varandra och incidentledaren/responsägaren kopplar samman dem båda.

Vänster spår: Teknisk responsHöger spår: Kommunikationsrespons
Begränsa incidentenUppdatera det interna teamet
Säkra berörda kontonMeddela berörda kunder eller partner
Bevara bevisBedöm avisering till tillsynsmyndigheter
Återställ systemHåll meddelanden konsekventa när fakta förändras

Detta gör att du kan strukturera din respons och säkerställa att samarbetet fortsätter när teammedlemmar tar på sig olika uppgifter.

Börja med målgruppen, inte med tillkännagivandet

Kommunikation vid säkerhetsincidenter misslyckas när ett enda meddelande försöker tjäna alla. Medarbetare, kunder, partner och tillsynsmyndigheter behöver olika nivåer av detaljer eftersom de har olika beslut att fatta.

Ditt interna team behöver klarhet först

De behöver inte varje detalj – särskilt inte medan utredningen pågår – men de behöver klarhet kring vad som är bekräftat, vad de ska göra just nu och vem som leder responsen. Det innebär att veta vilka system eller konton som ska undvikas, vilka åtgärder som ska vidtas omedelbart och vilka frågor som fortfarande är öppna.

Medarbetare behöver också veta vad de inte ska göra. Till exempel:

  • Diskutera inte incidenten offentligt
  • Återställ inte inloggningsuppgifter utanför den godkända processen
  • Kontakta inte kunder med improviserade förklaringar
  • Vidarebefordra inte misstänkta meddelanden utan vägledning.

Kunder och partner behöver veta hur de påverkas

De vill veta om deras uppgifter, åtkomst, betalningar, tjänst eller drift påverkas. En bra avisering till kunder bör förklara:

  • Vad som är känt
  • Vilken typ av data som kan beröras
  • Vad verksamheten gör
  • Vad kunderna bör göra nu, om något
  • Var de kan få uppdateringar.

Tonläget bör vara enkelt och direkt. En kund behöver inte heller några forensiska detaljer, utan bara tillräckligt med information för att kunna skydda sig.

Tillsynsmyndigheter behöver ett sakligt underlag

En anmälan om intrång enligt GDPR till relevant tillsynsmyndighet (ICO(nytt fönster) i Storbritannien, den nationella dataskyddsmyndigheten i varje EU-medlemsstat) är inte ett marknadsföringsmeddelande eller en lugnande information till kunderna. I stället behöver den vara ett sakligt underlag över vad som hände, vilka som berörs och vad ni gör åt det. Vi går igenom exakt vad som ska ingå i avsnittet om att avisera tillsynsmyndigheter nedan.

Vad som ska kommuniceras internt

Dina medarbetare är en del av hanteringen, även när de inte ingår i incidentteamet. Ett förvirrat team kan av misstag skapa mer brus, dela felaktig information eller bromsa in begränsningen av skadan. Ett välinformerat team kan däremot hjälpa till att skydda konton, hänvisa kunder till rätt kanal och undvika att spekulationer växer.

Ett internt meddelande om en säkerhetsincident bör omfatta:

  • En tydlig sammanfattning av vad som har bekräftats hittills, på ett enkelt språk
  • Vilka system, konton, team eller data som potentiellt berörs
  • Vad verksamheten gör nu
  • Vad medarbetarna omedelbart bör göra
  • Vem som får kommunicera externt
  • Var uppdateringar kommer att publiceras
  • Hur man rapporterar relaterad misstänkt aktivitet

Det finns saker som inte bör ingå: attackvektorer, rotorsaksanalys och specifika sårbarheter delas i allmänhet inte internt medan en incident pågår, och ofta inte efteråt heller, eftersom dessa detaljer kan hjälpa andra angripare, skapa rättslig exponering eller blotta brister som ännu inte har stängts.

Det första interna meddelandet behöver inte svara på alla frågor, det behöver skapa ordning. Medarbetare kan till exempel behöva återställa lösenord endast via en godkänd process, undvika att använda ett specifikt system, bevara misstänkta e-postmeddelanden eller sluta använda delade inloggningsuppgifter tills insatsteamet har granskat klart.

Att utvärdera dina befintliga åtkomstkontroller mot bästa praxis för lösenordshantering är också avgörande. Under en incident kan inaktuellt eller informellt delande av inloggningsuppgifter göra det svårare att förstå vad som exponerades.

Protons guider till skydd mot dataintrång och förebyggande av dataintrång för företag förklarar hur skiktade kontroller minskar exponeringen innan ett intrång sker. Säker hantering av inloggningsuppgifter är ett av dessa skikt eftersom det hjälper verksamheten att veta vilka konton som finns, vem som kan få åtkomst till dem och vad som snabbt behöver ändras.

Hur man aviserar kunder om ett intrång

En avisering om dataintrång till kunder är svårare eftersom den har betydelse för anseendet och juridiskt. Människor kan vara oroliga för identitetsstöld, kontokapning, ekonomiskt bedrägeri eller exponering av privat information. De kan också vara frustrerade över att företaget inte förhindrade incidenten.

Ett bra kundmeddelande bör vara ärligt utan att vara alarmerande. Det bör undvika teknisk jargong men vara tydligt. Kunderna behöver förstå vilka data som berördes, vilken risk det skapar och vad de bör göra härnäst.

En användbar struktur är:

  • Vad som hände, med en detaljnivå som är lämplig för kunder
  • När verksamheten fick kännedom om det
  • Vilken information eller vilka tjänster som kan beröras
  • Vilka åtgärder verksamheten har vidtagit
  • Vad kunderna bör göra nu
  • Hur verksamheten kommer att ge uppdateringar
  • Vem kunderna kan kontakta med frågor

Om utredningen fortfarande pågår bör detta uppges. Noggrannhet och öppenhet hjälper till att återställa förtroendet. Att vara öppen om konsekvenserna kräver inte att man avslöjar tekniska detaljer som skulle hjälpa någon att upprepa attacken.

Vid allvarliga incidenter kan kunderna behöva praktiska instruktioner: ändra ett lösenord, aktivera MFA, se upp för nätfiskemejl, kontakta sin bank och ignorera meddelanden som påstår sig komma från företaget om de inte kommer via en officiell kanal. Aviseringen bör göra dessa steg lätta att förstå.

När och hur man aviserar tillsynsmyndigheter

Inte varje säkerhetsincident behöver rapporteras till tillsynsmyndigheterna. Om ett intrång i personuppgifter är anmälningspliktigt enligt brittisk och EU-gemensam GDPR beror på om det sannolikt leder till en risk för människors rättigheter och friheter.

ICO:s vägledning om intrång i personuppgifter(nytt fönster) speglar ett krav som är gemensamt för både brittisk och EU-gemensam GDPR: organisationer måste rapportera ett anmälningspliktigt intrång utan onödigt dröjsmål och senast 72 timmar efter att de fått kännedom om det. En försenad rapport kräver skäl för förseningen.

Detta 72-timmarsfönster kan skapa press, särskilt när utredningen fortfarande är ofullständig. GDPR erkänner att organisationer inte kan ha varje detalj inom de första 72 timmarna, så information kan lämnas i etapper, så länge ytterligare uppdateringar ges utan onödigt dröjsmål.

En avisering till relevant tillsynsmyndighet (ICO i Storbritannien eller den nationella dataskyddsmyndigheten i EU) bör vanligtvis omfatta:

  • Typen av intrång i personuppgifter
  • Kategorierna och det ungefärliga antalet berörda personer
  • Kategorierna och det ungefärliga antalet berörda personuppgiftsposter
  • Namn och kontaktuppgifter till dataskyddsombudet eller en annan kontaktpunkt
  • De sannolika konsekvenserna av intrånget
  • De åtgärder som vidtagits eller föreslås för att åtgärda det

ICO tillhandahåller också en central sida för att rapportera ett intrång(nytt fönster) och hänvisa organisationer till rätt rapporteringsprocess.

För berörda personer är tröskeln en annan. Om ett intrång i personuppgifter sannolikt leder till en hög risk för människors rättigheter och friheter måste de informeras utan onödigt dröjsmål. Detta är en situation där juridiska team, integritetsteam och ledning tidigt bör involveras, även i ett litet företag.

Förbered meddelanden innan du behöver dem

Den sämsta tiden att utforma en kommunikationsprocess är under en incident. Det är inte hjälpsamt att utfärda uttalanden eller vägledning som behöver uppdateras och ändras.

Det är därför det är hjälpsamt att förbereda strukturen för dina meddelanden innan du behöver dem. Inte den slutliga formuleringen, eftersom varje incident blir olika, utan strukturen: vem som behöver godkänna meddelandet, vilka detaljer som måste ingå, var uppdateringar ska registreras och vem som ansvarar för varje målgrupp.

Ett enkelt kommunikationspaket räcker för att göra den första timmen mindre kaotisk. Det kan innehålla:

  • En mall för intern incidentmeddelande
  • En mall för kundavisering
  • En mall för uppdatering till partner eller leverantör
  • Talar punkter för kundsupport
  • Checklista för avisering till tillsynsmyndighet
  • Lista över godkända talespersoner
  • Eskaleringskontakter för juridik, IT, integritet, ledning och kommunikation
  • En plats för att dokumentera alla uppdateringar och beslut

Förberedelser ger teamet en trygg utgångspunkt när både snabbhet och noggrannhet är viktiga. En färdig mall frigör mer uppmärksamhet åt fakta om incidenten: vad som hände, vilka som berörs, vad som redan gjorts och vad folk behöver göra härnäst.

Så kan Proton Pass for Business hjälpa till

Kommunikation vid säkerhetsincidenter bygger på fakta. Ju tydligare ett företag hanterar åtkomst före en incident, desto enklare är det att förklara vad som hände, vad som kan påverkas och vad som har ändrats.

En lösenordshanterare för företag som Proton Pass for Business hjälper team att minska exponering kopplad till inloggningsuppgifter. Medarbetare kan generera starka lösenord, lagra dem i krypterade lösenordsvalv, använda autofyll, dela inloggningsuppgifter på ett säkert sätt, hantera passnycklar och använda inbyggd tvåfaktorsautentisering. Admins kan tillämpa lösenordspolicyer, granska aktivitetsloggar, hantera åtkomst med rollbaserade kontroller och stödja provisionering via SCIM- och SSO-integrationer.

Under en incident kan dessa funktioner hjälpa företag att agera med större självförtroende. Om ett medarbetarkonto komprometteras kan admins granska åtkomst, identifiera delade inloggningsuppgifter som kan behöva bytas ut, genomdriva starkare autentisering och minska beroendet av lösenord som kopierats via chatt eller kalkylblad.

Var redo att agera innan ett intrång sker med en lösenordshanterare för företag.