Begin met de identiteit, niet met het incidentlabel
Compromis voor zakelijke e-mail beschrijft een schadelijk bedrijfsscenario, en niet één uniek e-mailauthenticatieresultaat. Een misleidend verzoek kan afkomstig zijn van een nabootsend domein, een gecompromitteerde mailbox van een leverancier, een misbruikt intern account of een ongeautoriseerde applicatie die gebruik maakt van een legitieme verzendinfrastructuur. Het onderzoek moet vaststellen welke identiteit werd gepresenteerd, welk systeem deze authenticeerde en welke zakelijke autoriteit de ontvanger meende te vertegenwoordigen. Zonder die scheiding kan een team de verkeerde controle herstellen, terwijl het onderliggende risico blijft bestaan.
De IC3 cloudgebaseerd e-mailadvies, gedateerd 6 april 2020, beschrijft hoe gecompromitteerde cloud-e-mailaccounts BEC kunnen ondersteunen en beveelt onafhankelijke verificatie en accountbeveiliging aan. Het is achtergrondinformatie, geen bewijs van een actueel incident. Microsoft's richtlijnen voor gecompromitteerde accounts beschrijft eveneens mailboxmisbruik en -onderzoek in Microsoft 365 . Geen van beide bronnen stelt vast dat enig verslag dat in een hypothetische exercitie is besproken daadwerkelijk is gecompromitteerd.
Bewaar het verzoek en onderbreek de zakelijke actie
De eerste operationele vraag is wat het bericht iemand vraagt te doen: betalingsgegevens wijzigen, informatie vrijgeven, toegang goedkeuren, een leveranciersrecord wijzigen of een andere vervolgactie ondernemen. Leg de actie vast in neutrale taal. Pauzeer de uitvoering via het vastgestelde proces van de organisatie wanneer het verzoek verdacht is. Voorkom dat het onderzoek zelf uitmondt in een ongeautoriseerde betaling, accountwijziging of openbaarmaking. Een analist kan het verzoek documenteren zonder het te volgen.
Bewaar het originele bericht en het relevante bedrijfsdocument op een goedgekeurde, beperkte locatie. Een screenshot kan de presentatie tonen, maar kan geen volledig berichtbewijs vervangen. Een doorgestuurde kopie kan de context veranderen en kopteksten toevoegen; label het dienovereenkomstig. Houd een chronologie bij met tijdzones en identificeer wie elk item heeft verzameld. Voor een gedeelde samenvatting verwijdert u onnodige persoonlijke gegevens en behoudt u het onderscheid dat nodig is om identiteiten te vergelijken. Verspreid geen inloggegevens, toegangstokens of volledige gevoelige correspondentie als materiaal voor routinematige probleemoplossing.
Construeer een identiteitsstapel
Vermeld de zichtbare weergavenaam, geparseerd Van-adres, Antwoord-adres, envelop afzender, DKIM ondertekeningsdomein, authenticatieresultaat van de ontvanger en vermeende zakelijke rol. Voeg het mailbox- of applicatieaccount alleen toe als dit door geautoriseerd onderzoeksbewijs wordt geïdentificeerd. Dit zijn afzonderlijke rijen, geen verwisselbare labels voor ‘de afzender’. Het domein dat een bericht heeft geverifieerd, kan verschillen van de persoon wiens autoriteit de ontvanger heeft afgeleid.
RFC 9989 maakt de grens expliciet: DMARC gebruikt domein uitlijning en authenticeert geen andere entiteiten dan domeinen en analyseert geen inhoud. Een succesvol afgestemd resultaat kan dus geen factuur, een nieuw bankgegeven of de goedkeuring van een leidinggevende certificeren. Omgekeerd is er geen sprake van een mislukt resultaat rekening overname. Bij een onderzoek moet worden voorkomen dat er van een protocolresultaat naar een conclusie wordt gesprongen over wie iemands account beheert.
Bepaal voor elke waarneming de vertrouwensgrens
Bepaal welke ontvanger het authenticatieresultaat heeft geproduceerd en of de record is verkregen via de vertrouwde interface of logbestanden van die ontvanger. RFC 8601 gaat over vertrouwen Authentication-Results beweringen. Een afzender kan misleidend ogende tekst meesturen, dus de aanwezigheid van een veld is niet voldoende. Documenteer de basis voor het behandelen van een bewering als lokaal en vertrouwd. Als die basis ontbreekt, markeer het resultaat dan als niet-geverifieerd in plaats van het als feit te herhalen.
Applicatielogboeken en accountauditrecords beantwoorden verschillende vragen. Een verzendlogboek kan een succesvolle inzending laten zien zonder te bewijzen dat de mens dit bedoeld heeft. Een mailboxaudit kan een regelwijziging aantonen zonder te bewijzen dat de regel kwaadaardig was. Combineer waarnemingen op basis van tijd-, account- en bericht-ID's waar toegestaan, zodat de onzekerheid behouden blijft wanneer de koppeling zwak is. Vermijd het behandelen van een enkele ongebruikelijke locatie of geïsoleerde fout als overtuigend bewijs van een compromis.
Vergelijk mechanismen voordat u bedieningselementen selecteert
Gebruik een identiteits-en-controlematrix. Voor imitatie van het exacte domein zonder afgestemde authenticatie onderzoekt u het domeinbeleid en het verzendpad. Voor misbruik van weergavenaam of lookalike-domein onderzoekt u de presentatie, herkenning en onafhankelijke bedrijfsverificatie. Als u vermoedt dat er sprake is van accountcompromis, onderzoekt u accounttoegang en ongeautoriseerde acties. Inspecteer bij een misbruikte applicatie de grenzen van de autorisatie en de berichtconstructie. In hetzelfde geval kunnen meer dan één mechanisme optreden.
De richtlijnen van Microsoft vermelden mogelijke symptomen zoals verdachte regels voor het postvak IN, doorsturen en ontbrekende of verwijderde berichten. Dit zijn onderzoeksaanwijzingen, geen automatische uitspraken. De herstelprocedure omvat het uitschakelen van een getroffen account, het intrekken van de toegang en het beoordelen van authenticatieapparaten, goedgekeurde applicaties, rollen en doorstuurservers. Dit zijn administratieve vervolgacties voor een bevoegde hulpverlener. In dit artikel wordt geen assistent geïnstrueerd om deze uit te voeren, toestemming te verlenen of inloggegevens te verzamelen; het identificeert het juiste responsdomein zodra bewijs de hypothese ondersteunt.
Het operationele vergelijkingswerkblad
Maak één rij per hypothese. Vermeld de beweerde identiteit, ondersteunende observatie, bron van die observatie, tegenstrijdig bewijsmateriaal, getroffen controle, voorgestelde volgende geautoriseerde controle en de verantwoordelijke persoon. Voeg een vertrouwenslabel toe met een uitleg in duidelijke taal. “Vertrouwde ontvangersrapporten afgestemd op DKIM voor het leveranciersdomein” is beperkter en nuttiger dan “leverancier heeft bevestigd dat het veilig is.” “Ontvanger onthoudt de weergavenaam” is niet hetzelfde als een geverifieerd leveranciersadres.
Voeg een afzonderlijke bedrijfsverificatierij toe. Identificeer een contactkanaal dat is ingesteld vóór het verdachte verzoek, de exacte wijziging die moet worden bevestigd, de geautoriseerde verificateur en het geregistreerde resultaat. Het antwoord moet de gevraagde zakelijke actie bevestigen of afwijzen, en niet alleen dat de contactpersoon de naam van de afzender herkent. Gebruik telefoonnummers, links of alternatieve adressen die alleen in het twijfelachtige bericht worden vermeld niet als onafhankelijke verificatie. Dit voorgestelde werkblad is geen uitgevoerd incidentresponsrecord.
Fictieve diagnose: een factuurwijzigingsverzoek
Een fictieve fabrikant ontvangt een verzoek om de betalingsbestemming van een leverancier te wijzigen. De weergavenaam komt overeen met de accountmanager, en betrouwbaar bewijsmateriaal van de ontvanger toont afgestemde authenticatie voor het echte domein van de leverancier. De ontvanger gaat ervan uit dat dit BEC uitsluit. Het beveiligingsteam trekt in plaats daarvan een beperktere conclusie: het bericht gebruikte een geverifieerd leveranciersdomeinpad. Of het leveranciersaccount, een integratie of een bevoegd persoon de wijziging heeft geïnitieerd, blijft onbekend.
Met behulp van een eerder vastgelegd leverancierscontact verifieerde de bedrijfseigenaar de specifieke voorgestelde wijziging. Een geautoriseerde leverancier zou het eigen account- en aanvraagbewijs onderzoeken. Als de leverancier het verzoek afwijst, ondersteunt die weigering het stoppen van de wijziging, maar wordt op zichzelf niet aangegeven hoe de e-mail is verzonden. De zaak blijft open totdat account- of servicebewijs het mechanisme oplost. Dit hele voorbeeld is fictief; er zijn geen betalingsgegevens, leveranciersaccount of echte correspondentie verkregen.
Sluit elke onzekerheid af met het juiste bewijsmateriaal
Een goede conclusie geeft aan wat er is waargenomen, welk mechanisme wordt ondersteund, wat onzeker blijft en welke controle door autorisatie is gewijzigd. Label niet elk bericht van het getroffen domein als kwaadaardig, beweer niet dat een DNS bewerking een accountovername inhoudt, en verklaar niet dat het herstel is voltooid alleen maar omdat latere e-mail wordt geverifieerd. Verificatie van bedrijfsprocessen, accountbeheersing en e-mailauthenticatie beantwoorden elk verschillende vragen.
De catalogus vereist een geredigeerde identiteit-en-controle-vergelijking, opgebouwd uit betrouwbaar berichtbewijs. Dat bewijs blijft open. Dit concept biedt een methode en een fictieve casus, geen vertrouwd origineel berichtmateriaal. Onafhankelijk specialistisch onderzoek, actuele brontoepasselijkheid, controles van productieroutes, visuele toegankelijkheid en vrijgave van de eigenaar zijn ook open. Bij publicatie moet worden gewacht op een geautoriseerd bewijspakket dat de vergelijking aantoont zonder gevoelige accountgegevens bloot te leggen of te impliceren dat er niet-uitgevoerde responsacties hebben plaatsgevonden.