När jag arbetar med Phishinganalys försöker jag börja i den faktiska tillgången, datan och förändringen som ska skyddas. Phishinganalys behöver kombinera meddelandeheaders, URL:er, bilagor och vad mottagaren faktiskt gjorde; själva mailets utseende räcker inte för incidentbedömning.
Phishinganalys i praktiken
Första byggstenen: Received-kedjan visar transportväg men måste läsas i rätt riktning. 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: SPF, DKIM och DMARC ger autentiseringskontext. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: URL kan skilja mellan visad text och faktisk destination. 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: Endpointtelemetri avgör om länk öppnades eller bilaga kördes. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Från nuläge till verifierad kontroll
- Bevara originalmeddelandet i råformat.
- Kontrollera avsändardomän och autentiseringsresultat.
- Extrahera URL utan att besöka dem okontrollerat.
- Hasha bilagor och analysera säkert.
- Korrelera med proxy, DNS och endpoint efter mottagningstid.
För Phishinganalys 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.
Exempel från ett driftperspektiv
Ett uppenbart falskt loginmail kan fortfarande vara en mindre incident om ingen klickade, medan ett trovärdigt mail med lyckad session efter klicket kräver identitets- och endpointspårning direkt.
Fallgropar jag försöker undvika
- Att vidarebefordra mailet och därmed förlora originalheaders.
- Att klicka länken från analystens vanliga browser.
- Att stänga ärendet som phishing utan att kontrollera om användaren interagerade.
Kontrollpunkter
För Phishinganalys 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:
- Originalheaders är sparade.
- URL och bilagor har dokumenterade indikatorer.
- Användarens interaktion kan stödjas av telemetry.
Ett negativt test hör också till Phishinganalys: 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
Phishinganalys – headers, länkar, bilagor och användarkontext i samma tidslinje 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.