Det intressanta med Business Email Compromise är hur snabbt teori möter drift: en kontroll måste fungera även när systemet uppdateras, felsöks och utsätts för fel. Business Email Compromise utnyttjar ofta legitima konton, sociala processer och betalningsrutiner snarare än malware, vilket gör identitets- och verksamhetskontroller centrala.
Business Email Compromise i praktiken
Första byggstenen: Nya inbox rules kan användas för att dölja svar eller fakturor. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
En annan viktig del: OAuth consent kan ge beständig åtkomst utan att angriparen behåller lösenordet. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: Lookalike-domäner kan imitera leverantörer utan kontokompromiss. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det som ofta avgör kvaliteten: Out-of-band-verifiering av betalningsändringar är en verksamhetskontroll som tekniken inte ersätter. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Så skulle jag testa det i en riktig miljö
- Granska sign-ins, MFA och sessionsrisk runt misstänkt tid.
- Kontrollera mailbox rules och forwarding.
- Inventera nya app consents.
- Sök efter liknande meddelanden till andra mottagare.
- Verifiera betalnings- eller kontouppgifter via separat kanal.
För Business Email Compromise håller jag därför införandet i små steg. Då går det att skilja ett säkerhetsproblem från ett rent driftfel och att rulla tillbaka just den ändring som gav ett oväntat resultat.
Praktiskt exempel
Om en leverantör plötsligt byter bankkonto behandlar jag det som en processavvikelse även om mailet är perfekt formulerat. Ett telefonsamtal till ett redan känt nummer kan stoppa en incident som teknisk e-postfiltrering missar.
Misstag som skapar falsk trygghet
- Att fokusera bara på endpoint efter ett mailbedrägeri.
- Att återställa lösenord men lämna aktiva sessions- eller app-tokens.
- Att bekräfta ändrade bankuppgifter genom att svara på samma mailtråd.
Verifiering före stängning
För Business Email Compromise vill jag avsluta med mätbara efterkontroller i stället för att nöja mig med att en statusruta visar ”enabled”. De viktigaste kontrollerna här är:
- Misstänkta sessions och tokens är revokerade.
- Skadliga forwardingregler är borta.
- Berörda ekonomiprocesser har separat verifiering innan betalning.
Ett negativt test hör också till Business Email Compromise: den väg, identitet eller operation som inte ska vara tillåten ska misslyckas på ett förutsägbart sätt. Då kan nästa tekniker upprepa kontrollen och förstå både avsikten och gränsen.
Slutsats
Business Email Compromise – när identitet och betalningsflöden är attackytan handlar därför inte om att samla fler säkerhetsinställningar. Det handlar om att minska en konkret risk med en kontroll som har tydligt scope, tydlig ägare och ett verifierbart resultat. När före-läge, förändring och eftertest dokumenteras blir säkerhetsarbetet både säkrare och lättare att förvalta.