Flowchart for håndtering af phishing-hændelser (indberettet mail)

Hvad er flowchart for håndtering af phishing-hændelser (indberettet mail)?

Håndtering af phishing-hændelser er det, der sker, efter én person videresender én mail. Udløseren er en indberetning frem for en alarm: nogen trykker på indberetningsknappen i deres mailklient, eller ringer til servicedesken om en mail, der ikke ser rigtig ud. Derfra er arbejdet en kort, gentagelig sløjfe. Triagér prøven til en verdikt, find hver eneste anden kopi af den, der nåede organisationen, fjern de kopier og blokér det, de pegede på, gør om igen, hvad modtagerne allerede nåede at gøre, og fortæl folk, hvad der skete. Diagrammet herunder følger én indberetning fra start til slut gennem seks faser, fra modtagelse over triage, afdækning af omfang, inddæmning og genetablering til det metrik- og awareness-arbejde, der afgør, hvor mange indberetninger I får næste måned.

Det her er kun mailbårne hændelser. Det er ikke den generelle proces for håndtering af cyberhændelser, et security operations center kører fra en detektionsalarm: den proces starter fra telemetri frem for fra et menneske, og dette diagram overdrager til den ved 'Tegn på kompromitteret konto?', når en postkasse viser sig at være under en andens kontrol. Det er heller ikke alvorstrappen i en proces for eskalering af sikkerhedshændelser, og det er heller ikke en almindelig nulstilling af adgangskode, for nulstillingen her er inddæmning af loginoplysninger, en angriber allerede har, og den følges af tilbagekaldelse af sessioner. Det er heller ikke anmeldelse af databrud: hvis personoplysninger er nået frem til en angriber, hører vurderingen, den lovbestemte frist og samtalen med en tilsynsmyndighed til hos juridisk og databeskyttelsesrådgiveren og kører ved siden af dette diagram frem for inde i det. Betragt diagrammet som et uddannelsesmæssigt udgangspunkt, der skal tilpasses jeres egne procedurer for hændelseshåndtering, de regler, der gælder for jer, og jeres sikkerhedsansvarliges gennemgang.

Fire beslutninger bærer processen. 'Er den indberettede mail skadelig?' er den verdikt, der skiller en gene fra en hændelse, og den ligger hos SOC-analytikeren frem for servicedesken, fordi et look-alike-domæne og en fejlet afsenderautentificering ikke er en førstelinjevurdering. 'Klikkede eller svarede nogen?' gør et mailhygiejnejob til et identitetsjob, og alt det dyre i diagrammet hænger på den. 'Hvad gjorde den berørte bruger?' er tegnet som én trevejsgren frem for en kø af ja/nej-spørgsmål, fordi indtastede loginoplysninger, en åbnet vedhæftet fil og en nærved-hændelse kræver forskellige teams, der arbejder efter forskellige ure. 'Er der brug for en advarsel til alle medarbejdere?' ligger med vilje i banen Sikkerhedsledelse: en besked til alle medarbejdere er en kommunikationsbeslutning med en pris, og den analytiker, der fandt kampagnen, bør ikke være den eneste, der træffer den.

Hvad dette flowchart dækker

I denne skabelon

• Fem swimlanes (Medarbejder / anmelder, Servicedesk, SOC-analytiker, IT / identitetsteam og Sikkerhedsledelse) fordelt på seks faser: Rapportering og modtagelse, Triage og verdikt, Afdæk kampagnens omfang, Inddæmning og udrensning, Genetablering og kommunikation samt Afslutning og læring
• To indgange til én kø: et tryk på indberetningsknappen, der sender prøven direkte til sikkerhedsteamet, og en sag hos servicedesken for den, der ringer i stedet, logget med den oprindelige mail vedhæftet frem for beskrevet
• En verdiktbeslutning, 'Er den indberettede mail skadelig?', hvis uskadelige gren svarer anmelderen, tuner mailfilteret og lukker indberetningen som ikke-skadelig frem for bare at lade den falde væk i stilhed, fordi det er svaret, der holder folk i gang med at indberette
• Afdækning af omfang før sletning med 'Søg i hele tenanten efter andre kopier' og 'Klikkede eller svarede nogen?', derefter en inddæmningsrunde, der sletter hver kopi, blokerer afsenderen, URL'er og filhashes, og løkker på 'Kommer der stadig flere kopier?', mens kampagnen stadig lander
• En trevejsgren, 'Hvad gjorde den berørte bruger?': indtastede loginoplysninger går til 'Nulstil adgangskoden og tilbagekald sessioner' i identitetsbanen, en åbnet vedhæftet fil går til isolering af maskinen og en fuld scanning, og 'Tegn på kompromitteret konto?' eskalerer i stedet for at lukke
• Kommunikation og afslutning: 'Er der brug for en advarsel til alle medarbejdere?' godkendes i banen Sikkerhedsledelse, modtagerne får at vide, hvad de skal holde øje med, og sagen lukker først, når indikatorerne, tidslinjen, rapporteringsraten og klikraten samt en awareness-opfølgning er registreret

Hvornår du skal bruge skabelonen

• I har en indberetningsknap i Outlook eller Gmail og ingen aftalt playbook bag den, så det, der sker med en indberettet mail, afhænger af, hvilken analytiker der samler den op
• Brugerne videresender mistænkelige mails til en fælles indbakke, ingen rigtig ejer, og I har brug for, at modtagelsen, verdikten og svaret til anmelderen er tegnet som én vej
• En credential-phishingkampagne er lige landet, og I vil have sletningen, nulstillingen, tilbagekaldelsen af sessioner og tjekket af postkasseregler sat i rækkefølge, før den næste ankommer
• I skriver phishing-afsnittet af en beredskabsplan og har brug for, at det overdrager rent til den bredere proces for håndtering af sikkerhedshændelser frem for at duplikere den
• En auditor har spurgt, hvordan medarbejdere indberetter en mistænkt sikkerhedshændelse, og hvad der sker derefter, hvilket er den indberetningsmekanisme, ISO/IEC 27001:2022 bilag A kontrol 6.8 beder om

Sådan fungerer det

1. Omdøb banerne til jeres roller

   Erstat Medarbejder / anmelder, Servicedesk, SOC-analytiker, IT / identitetsteam og Sikkerhedsledelse med de roller, I reelt har. Mange organisationer har slet ingen servicedesk-bane, fordi indberetningsknappen går direkte til sikkerhed, og mange kører identitetsarbejdet inde i SOC'et. Slet en bane frem for at lade den stå ubemandet, og split en, hvis en managed service-udbyder ejer en del af den.

2. Skriv hver eneste indgang ned

   List enhver måde, en phishing-indberetning kan komme ind på: indberetningsknappen, en fælles postkasse, servicedeskens telefon, en leder, der videresender på nogens vegne, en kunde, der fortæller jer, at deres faktura blev omdirigeret. Markér derefter, hvilke af dem der lander i triagekøen automatisk, og hvilke der afhænger af, at nogen husker at videresende den, for det er dét hul, indberetninger stille forsvinder i.

3. Fastsæt kriterierne for triageverdikten

   Åbn 'Er den indberettede mail skadelig?' og skriv de tjek ned, jeres analytikere reelt kører: overensstemmelse i afsenderautentificering, look-alike- og nyregistrerede domæner, detonering af URL'er, sandboxing af vedhæftede filer, og om mailen beder om loginoplysninger, betaling eller haster. Sig også, hvad der sker med en genemail, så spam er en beslutning frem for et skuldertræk.

4. Få søgningen af omfang på plads før sletningen

   Sletningen er kun så god som søgningen foran den. Registrér, hvad I søger på, hvilket bør omfatte afsenderadressen, visningsnavnet, emnet, URL'en og hash'en på den vedhæftede fil, og hvor langt tilbage jeres værktøj rækker, hvilket som regel er et kort, tilbagevirkende vindue kun over cloud-postkasser. Notér separat, hvordan I finder kopier i on-premises-postkasser, arkiver og alt, der allerede er videresendt ud.

5. Aftal identitetsresponsen, og hvem der kan beordre den

   Beslut, hvad 'Nulstil adgangskoden og tilbagekald sessioner' forpligter jer til, og hvem der må beordre det klokken tre om natten. En nulstilling alene lader et stjålet sessiontoken blive ved med at virke, så tilbagekaldelsen og tjekket af MFA-metoder, postkasseregler og godkendte applikationer hører til på samme trin. Angiv, hvordan de nye loginoplysninger når brugeren gennem en kanal, angriberen ikke kontrollerer.

6. Beslut, hvem der godkender en advarsel til alle

   Sæt et navn på 'Er der brug for en advarsel til alle medarbejdere?' og en tærskel derunder: hvor mange modtagere, hvilke mærker eller ledere der efterlignes, om nogen allerede har betalt eller indtastet loginoplysninger. Udkast advarslen på forhånd, for den version, der skrives under pres, er den, der beder medarbejderne holde øje med en emnelinje, angriberen skiftede for en time siden.

7. Prøv det af mod en rigtig indberettet mail

   Tag to nylige indberetninger, én der viste sig at være spam, og én der blev til en rigtig hændelse, og følg hver af dem gennem diagrammet sammen med dem, der håndterede dem. De trin, ingen kan sætte navn på en ejer for, og de trin, der tydeligvis skete, men ikke er tegnet, er de fund, der er værd at rette, før I udgiver playbooken og øver den.

Ofte stillede spørgsmål

Hvilke trin består håndtering af en phishing-hændelse af?

En medarbejder opdager en mistænkelig mail og indberetter den, enten via knappen i sin mailklient eller ved at oprette en sag hos servicedesken med den oprindelige mail vedhæftet. En analytiker undersøger headere, links og vedhæftede filer og når frem til en verdikt. En genemail får et svar til anmelderen, en filterændring og en lukket sag. En skadelig mail bliver afdækket: søg i tenanten efter andre kopier, og fastslå, om nogen klikkede eller svarede. Inddæmningen sletter derefter hver kopi, blokerer afsenderen, URL'er og filhashes, og gentages, mens flere kopier ankommer. Det, den berørte bruger gjorde, afgør resten. Indtastede loginoplysninger betyder en nulstilling af adgangskoden med tilbagekaldte sessioner og et tjek af MFA-metoder, postkasseregler og godkendte applikationer; en åbnet vedhæftet fil betyder isolering af maskinen og en scanning; tegn på en kompromitteret konto eskalerer til hændelseshåndtering. Ellers vejer teamet en advarsel til alle medarbejdere, fortæller modtagerne, hvad de skal holde øje med, registrerer indikatorerne og målene, og lukker sagen med anmelderen.

Hvordan adskiller phishing-håndtering sig fra håndtering af cyberhændelser?

Omfang og udløser. Håndtering af phishing er en proces med højt volumen og stort set gentagelig, der starter med, at en person indberetter en mail, og de fleste sager ender uden nogensinde at blive erklæret en hændelse: mailen slettes, indikatorerne blokeres, og anmelderen får svar. En proces for håndtering af cyberhændelser starter fra en detektion eller en bekræftet kompromittering og kører erklæring, alvorsgrad, en incident commander, retsteknisk arbejde, udrensning og genetablering. De to mødes ét sted på dette diagram. Når identitetstjekkene viser, at en postkasse ikke længere er under ejerens kontrol, har phishing-håndteringen gjort sit arbejde og overdrager. Det betyder noget at holde dem adskilt i begge retninger: at køre hver eneste indberettet mail gennem en fuld hændelseslivscyklus udmatter teamet, og at behandle en levende kontoovertagelse som en postkasseoprydning mister angriberen.

Er en nulstilling af adgangskoden nok, efter nogen har indtastet loginoplysninger på en phishing-side?

Som regel ikke. Moderne credential-phishing-værktøjer fungerer som en adversary-in-the-middle: den falske side proxyer det rigtige login, så både adgangskoden og MFA-prompten videresendes til den ægte tjeneste, og angriberen indfanger de session- og refresh-tokens, der kommer tilbage. De tokens bliver ved med at virke, efter adgangskoden er skiftet, og det er derfor, dette diagram parrer nulstillingen med tilbagekaldelse af sessioner i samme trin og følger op med et tjek af tilmeldte MFA-metoder, postkassens videresendelsesregler og godkendte OAuth-applikationer - de tre steder, angribere som regel efterlader en vej tilbage ind. På længere sigt er den kontrol, der fjerner angrebet frem for at rydde op efter det, phishing-resistent autentificering. CISA's vejledning peger på FIDO/WebAuthn-authenticators og PKI-baserede metoder som smartcards som de phishing-resistente former, fordi de binder loginnet til det rigtige domæne og fejler på en proxy.

Kan man fjerne en phishing-mail fra samtlige postkasser, efter den er blevet leveret?

Delvist, og det er værd at kende grænserne, før I lover det. Cloud-mailplatforme giver mulighed for efterfølgende fjernelse af mails, der viser sig at være skadelige efter levering. Microsofts zero-hour auto purge handler for eksempel på allerede leveret mail i cloud-postkasser, dens søgning dækker de sidste 48 timer af leveret mail, og den virker ikke i on-premises-postkasser beskyttet af Microsoft 365. Analytikerstyret søgning og sletning fra sikkerhedsportalen giver jer et bredere net, men stadig kun over de postkasser, den platform har. Det, ingen sletning når, er en kopi, modtageren allerede har videresendt ud, en mail hentet ned i et lokalt arkiv, eller et skærmbillede i en chattråd. Det er derfor, diagrammet løkker på 'Kommer der stadig flere kopier?' frem for at behandle sletningen som én enkelt begivenhed, og hvorfor det at fortælle modtagerne, hvad de skal holde øje med, bliver på den kritiske vej.

Skal en phishing-hændelse indberettes til en tilsynsmyndighed?

Det afhænger af, hvad angriberen fik fat i, og det er ikke en beslutning, analytikeren skal træffe alene. Efter UK og EU's GDPR skal en dataansvarlig underrette sin tilsynsmyndighed om et brud på persondatasikkerheden uden unødig forsinkelse og, hvor det er muligt, senest 72 timer efter at være blevet opmærksom på det, medmindre bruddet sandsynligvis ikke indebærer en risiko for fysiske personers rettigheder og frihedsrettigheder; en for sen underretning skal ledsages af begrundelsen for forsinkelsen. Sektorregler, kontrakter og cyberforsikringer sætter deres egne ure oven i det. Den praktiske regel er, at i det øjeblik dette diagram når frem til tegn på kompromitteret konto, bliver juridisk og databeskyttelsesrådgiveren inddraget parallelt, mens det tekniske arbejde fortsætter. Adskilt herfra tager flere nationale myndigheder selve prøven imod: i Storbritannien tager NCSC's Suspicious Email Reporting Service imod mails videresendt til report@phishing.gov.uk.