Börja med identiteten, inte incidentetiketten
Kompromiss med e-post för företag beskriver ett skadligt affärsscenario, inte ett unikt resultat för e-postautentisering. En vilseledande förfrågan kan komma från en domän som utger sig för att vara en domän, en intrång i leverantörens brevlåda, ett missbrukat internt konto eller en obehörig applikation som använder legitim sändningsinfrastruktur. Utredningen ska fastställa vilken identitet som uppvisades, vilket system som autentiserade den och vilken affärsmyndighet mottagaren trodde att den representerade. Utan den separationen kan ett team reparera fel kontroll medan den underliggande risken kvarstår.
De IC3 molnbaserad e-postrådgivning, daterad 6 april 2020, beskriver hur komprometterade molnkonton kan stödja BEC och rekommenderar oberoende verifiering och kontoskydd. Det är bakgrundsvägledning, inte bevis på en aktuell incident. Microsofts vägledning för utsatta konton beskriver likaledes missbruk och utredning av brevlåde i Microsoft 365 . Ingen av källorna fastställer att någon redogörelse som diskuterats i en hypotetisk övning faktiskt har äventyrats.
Bevara begäran och pausa affärsåtgärden
Den första operativa frågan är vad meddelandet ber någon att göra: ändra betalningsinformation, släppa information, godkänna åtkomst, ändra en leverantörspost eller vidta en annan följdåtgärd. Spela in handlingen på ett neutralt språk. Pausa exekveringen genom organisationens etablerade process när begäran är misstänkt. Undvik att göra själva utredningen till en obehörig betalning, kontoändring eller avslöjande. En analytiker kan dokumentera begäran utan att följa den.
Bevara det ursprungliga meddelandet och relevanta affärsuppgifter på en godkänd plats med begränsningar. En skärmdump kan visa presentation men kan inte ersätta fullständiga meddelandebevis. En vidarebefordrad kopia kan ändra sammanhanget och lägga till rubriker; märka det därefter. Håll en kronologi med tidszoner och identifiera vem som samlat in varje föremål. För en delad sammanfattning, ta bort onödiga personuppgifter samtidigt som du behåller de distinktioner som behövs för att jämföra identiteter. Sprid inte inloggningsuppgifter, åtkomsttokens eller fullständig känslig korrespondens som rutinmässigt felsökningsmaterial.
Konstruera en identitetsstack
Lista det synliga visningsnamnet, tolkat från adress, svarsadress, kuvertsändare, DKIM signeringsdomän, mottagarautentiseringsresultat och påstådd affärsroll. Lägg bara till postlådan eller applikationskontot om auktoriserade utredningsbevis identifierar det. Dessa är separata rader, inte utbytbara etiketter för "avsändaren". Domänen som autentiserade ett meddelande kan skilja sig från den person vars auktoritet mottagaren ansåg.
RFC 9989 gör gränsen tydlig: DMARC använder domänjustering och autentiserar inte andra enheter än domäner eller analyserar innehåll. Ett framgångsrikt sammanställt resultat kan därför inte bekräfta en faktura, en ny bankdetalj eller en chefs godkännande. Omvänt etableras inte ett misslyckat resultat kontoövertagande. En utredning bör undvika att hoppa från ett protokollresultat till en slutsats om vem som kontrollerade en persons konto.
Fastställ förtroendegränsen för varje observation
Bestäm vilken mottagare som producerade autentiseringsresultatet och om posten erhölls via den mottagarens betrodda gränssnitt eller loggar. RFC 8601 adresserar förtroende för Authentication-Results påståenden. En avsändare kan inkludera vilseledande text, så närvaron av ett fält räcker inte. Dokumentera grunden för att behandla ett påstående som lokalt och pålitligt. Om den grunden saknas, markera resultatet som overifierat istället för att upprepa det som fakta.
Applikationsloggar och kontorevisionsposter svarar på olika frågor. En sändningslogg kan visa en lyckad inlämning utan att bevisa att människan avsåg det. En postlådegranskning kan visa en regeländring utan att bevisa att regeln var skadlig. Kombinera observationer efter tid, konto och meddelandeidentifierare där det är tillåtet, vilket bevarar osäkerheten när kopplingen är svag. Undvik att behandla en enda ovanlig plats eller ett isolerat fel som avgörande bevis på kompromiss.
Jämför mekanismer innan du väljer kontroller
Använd en identitets- och kontrollmatris. För exakt domänimitation utan anpassad autentisering, undersök domänpolicyn och sändningsvägen. För missbruk av visningsnamn eller lookalike-domän, undersök presentation, igenkänning och oberoende företagsverifiering. Vid misstänkt kontointrång, undersök kontoåtkomst och obehöriga åtgärder. För ett missbrukat program, kontrollera dess behörighets- och meddelandekonstruktionsgränser. Mer än en mekanism kan förekomma i samma fall.
Microsofts vägledning listar potentiella symptom som misstänkta inkorgsregler, vidarebefordran och saknade eller raderade meddelanden. Dessa är utredningsledningar, inte automatiska domar. Dess åtgärdssekvens inkluderar att inaktivera ett påverkat konto, återkalla åtkomst och granska autentiseringsenheter, samtyckta applikationer, roller och vidarebefordrare. Dessa är administrativa åtgärder för en auktoriserad räddare. Den här artikeln instruerar inte en assistent att utföra dem, ge behörigheter eller samla in referenser; den identifierar den lämpliga svarsdomänen när bevis stöder hypotesen.
Arbetsbladet för jämförelse
Skapa en rad per hypotes. Inkludera den påstådda identiteten, stödjande observation, källan till den observationen, motstridiga bevis, påverkad kontroll, föreslagen nästa auktoriserade kontroll och den ansvariga personen. Lägg till en förtroendeetikett med en klarspråkig förklaring. "Betrodda mottagare rapporterar anpassade DKIM för leverantörsdomänen" är smalare och mer användbar än "leverantör bekräftad säker." "Mottagaren kommer ihåg visningsnamnet" motsvarar inte en autentiserad leverantörsadress.
Lägg till en separat rad för företagsverifiering. Identifiera en kontaktkanal som upprättats före den misstänkta begäran, den exakta ändringen som behöver bekräftas, den auktoriserade verifieraren och det registrerade resultatet. Svaret ska bekräfta eller avvisa den begärda affärsåtgärden, inte bara att kontakten känner igen avsändarens namn. Använd inte telefonnummer, länkar eller alternativa adresser som endast anges i det tvivelaktiga meddelandet som oberoende verifiering. Det här föreslagna arbetsbladet är inte en exekverad incidentresponspost.
Fiktiv diagnos: en begäran om fakturaändring
En fiktiv tillverkare får en begäran om att ändra en leverantörs betalningsdestination. Visningsnamnet stämmer överens med kontoansvarig, och betrodda mottagarbevis visar anpassad autentisering för leverantörens verkliga domän. Mottagaren antar att detta utesluter BEC. Säkerhetsteamet drar istället en snävare slutsats: meddelandet använde en autentiserad leverantör-domänsökväg. Om leverantörskontot, en integration eller en auktoriserad person initierade förändringen är fortfarande okänt.
Med hjälp av en tidigare registrerad leverantörskontakt skulle företagsägaren verifiera den specifika föreslagna förändringen. En auktoriserad leverantörssvarare skulle undersöka sitt eget konto och ansökan. Om leverantören avslår begäran, stöder det avslaget att stoppa ändringen men identifierar inte i sig hur e-postmeddelandet skickades. Ärendet förblir öppet tills konto- eller tjänstebevis löser mekanismen. Hela detta exempel är fiktivt; ingen betalningsuppgift, leverantörskonto eller riktig korrespondens erhölls.
Stäng varje osäkerhet med rätt bevis
En sund slutsats anger vad som observerades, vilken mekanism som stöds, vad som förblir osäkert och vilken kontroll som ändrades genom auktorisation. Märk inte alla meddelanden från den berörda domänen som skadliga, hävda att en DNS redigering innehåller ett kontoövertagande eller förklara att åtgärden är slutförd bara för att senare e-post autentiserar. Verifiering av affärsprocesser, kontoinneslutning och e-postautentisering svarar på olika frågor.
Katalogen kräver en redigerad identitets- och kontrolljämförelse byggd från betrodda meddelandebevis. Det beviset förblir öppet. Detta utkast tillhandahåller en metod och ett fiktivt fall, inte pålitligt originalmeddelandematerial. Oberoende specialistgranskning, aktuell källtillämplighet, kontroller av produktionsvägar, visuell tillgänglighet och ägarefrigivning är också öppna. Publicering bör vänta på ett auktoriserat bevispaket som visar jämförelsen utan att avslöja känslig kontodata eller antyda att ej utförda svarsåtgärder inträffade.