Säkerhet / PERSPEKTIV 05
Säkra er e-post.
Nätfiske, falska avsändare och vad ledningen bör kräva av SPF, DKIM, DMARC och inloggningen.
DET VIKTIGASTE ATT TA MED
Ta reda på vem som skickar mejl i ert namn, hur inloggningen till mejlen skyddas och vem som läser DMARC-rapporterna innan ni skärper policyn.
Varför är mejlen en vanlig väg in?
CERT-SE beskriver bedrägerier via e-post som ett vanligt problem. Nätfiske, att lura till sig uppgifter eller få någon att öppna en länk eller bilaga, kallar de för en av de mest effektiva metoderna för obehörig åtkomst. Microsoft beskriver förfalskade avsändare som vanliga i nätfiske och i det som kallas business email compromise, BEC. PTS konstaterar i rapporten PTS-ER-2024:31 att sådana försök fortfarande förekommer trots filtrering, bland annat med avsändare som ser ut att tillhöra en känd organisation.
Tre mönster räcker som underlag. Vid nätfiske ska mottagaren lämna ifrån sig något, ofta ett lösenord, eller öppna det som följde med mejlet. Spoofing betyder att från-fältet ser trovärdigt ut fast mejlet skickades av någon annan. CERT-SE påpekar att ett mejl kan visa en adress man litar på och ändå vara förfalskat. VD-bedrägeri är en form av BEC: någon utger sig för att vara en chef och ber om en brådskande betalning, eller om att en ordinarie rutin ska frångås. CERT-SE tar just den situationen som exempel på när ärendet bör bekräftas i en annan kanal.
Vår rekommendation är att se mejlsäkerhet som en ledningsfråga med en namngiven ägare. Någon behöver veta vilka tjänster som får skicka i organisationens namn, hur inloggningen till mejlen är satt och vart ett misstänkt mejl rapporteras. ITKoncept hjälper er att reda ut de beroendena och prioritera nästa steg. Vi utreder inte intrång och vi driver ingen övervakning. Rapporter om pågående nätfiske tar CERT-SE emot.
Tre kontroller som hör ihop.
SPF, DKIM och DMARC gör olika delar av samma arbete. SPF är en uppgift i DNS om vilka servrar som får skicka för domänen. DKIM är en signatur på meddelandet. Mottagaren kan kontrollera att viktiga delar inte har ändrats på vägen, mot en nyckel som domänen publicerar. DMARC talar om vad mottagaren bör göra när kontrollerna inte går ihop, och kräver att den autentiserade domänen stämmer med den avsändare som syns.
Microsoft beskriver att de tre behöver fungera tillsammans. SPF tittar på den tekniska avsändaren och säger inget om att den stämmer med adressen i från-fältet. DKIM kan fortfarande gå att verifiera när ett mejl har vidarebefordrats och SPF därför faller. DMARC är det som knyter resultatet till den synliga avsändaren. Specifikationerna är RFC 7208, RFC 6376 och RFC 7489.
Två gränser är lätta att missa. Microsoft anger att varje domän bara får ha en SPF-post. Flera poster gör att kontrollen inte går att tolka. RFC 7208 sätter dessutom en gräns på tio termer som orsakar DNS-uppslag under en SPF-kontroll. Blir de fler ska resultatet bli ett fel, även om avsändaren är er. Utskick, fakturor och bokningssystem gör posten längre utan att någon har bytt mejlsystem.
Vårt förslag är att lista varje tjänst som skickar i ert namn innan ni ändrar DNS, och att ta med domäner som inte ska skicka alls. CERT-SE rekommenderar SPF även för sådana domäner. NCSC rekommenderar DMARC för alla domäner, också de som ligger oanvända. Hur vi kartlägger avsändare och mejlautentisering beskriver vi på sidan om e-postsäkerhet.
Från none till reject.
DMARC-policyn har tre värden. I RFC 7489 betyder none att domänägaren inte begär någon särskild åtgärd för leveransen. Quarantine betyder att mejl som inte klarar kontrollen ska behandlas som misstänkta. Reject betyder att mottagaren ombeds avvisa dem. Microsoft beskriver att reject normalt innebär att meddelandet kastas, medan quarantine kan hamna i skräppost, i karantän eller levereras med en markering. Vad som händer beror på mottagarens system.
Både Microsoft och NCSC beskriver samma riktning: börja med p=none, läs rapporterna och gå sedan till quarantine och därefter reject. NCSC kallar none en övervakningsfas som inte ska påverka leveransen. CERT-SE formulerar det som att först köra i monitorläge för att se hur domänen används, och sedan bedöma om blockering behövs. När SPF och DKIM stämmer och kända avsändare är med rekommenderar NCSC att gå vidare till quarantine, och därefter till reject. Microsoft beskriver att andelen mejl som den strängare policyn gäller kan höjas med pct, så att ett fel inte behöver träffa hela flödet på en gång.
Vår rekommendation är att inte välja reject för att det låter starkast. Publicera none, samla vilka som skickar, rätta SPF och DKIM, och höj först när legitima utskick klarar kontrollen. Låt någon fortsätta läsa rapporterna. En ny tjänst som börjar skicka utan att finnas med kan annars stoppa verksamhetens egen post.
Lösenordet till mejlen räcker inte.
Ett nätfiskemejl behöver inte förfalska er domän. Det kan komma från en annan avsändare och ändå be någon logga in på en sida som ser äkta ut. Då hjälper varken SPF eller DMARC på just det meddelandet. Skyddet sitter i stället på kontot. CERT-SE rekommenderar multifaktorautentisering för inloggning, även när mejlen nås utifrån, och att verksamheten överväger nätfiskeresistent MFA för det som är mer skyddsvärt. Som exempel nämner de fysiska säkerhetsnycklar eller smarta kort.
NCSC beskriver FIDO2 som nätfiskeresistent. Engångskoder i sms eller app kan fångas på en falsk inloggningssida, en svaghet NCSC pekar ut. Metoderna ger alltså inte samma skydd, även om båda kallas MFA.
Vårt förslag är att börja med de konton som kan läsa andras mejl, ändra regler eller godkänna en betalning: administratörer, ekonomi och delade funktionsbrevlådor. Ta reda på vilken metod som faktiskt krävs i dag. Prova en starkare metod i en liten grupp, med en väg tillbaka om en nyckel försvinner, innan ni kräver den av alla. Licens och tekniska förutsättningar behöver stämma i er miljö.
Filter först, vana sedan.
Tekniken ska ta den första träffen. NCSC rekommenderar att inkommande mejl filtreras eller blockeras innan de når användaren, och att mottagaren följer avsändarens DMARC-policy när den säger quarantine eller reject. I Microsoft 365 kontrolleras inkommande post mot SPF, DKIM och DMARC, men Microsoft beskriver också att plattformen väger in fler signaler. Ett autentiseringsfel avgör därför inte ensamt om mejlet stoppas. Microsoft rekommenderar att avsändarens DMARC-policy följs. Därutöver beskriver Microsoft funktioner i Defender for Office 365 som granskar länkar och bilagor. Vilka som ingår beror på licensen och behöver läsas av hos er, inte antas.
CERT-SE rekommenderar återkommande övning i säker mejlhantering, och att misstänkt post rapporteras. En användbar regel från deras vägledning: om någon som sällan skriver direkt ber om en brådskande betalning, eller om nästa steg är en inloggning, ska ärendet bekräftas i en annan kanal. Märkning av mejl från externa avsändare gör det också lättare att se när ett internt konto ser ut att skriva utifrån.
Vår rekommendation är en kort rutin med en namngiven ägare. Bestäm vart ett misstänkt mejl skickas, vem som avgör om ett konto ska spärras och hur ekonomi bekräftar en ändrad betalning. Rutinen ska göra nästa steg tydligt. Den ersätter inte filtren. Checklistan nedan är ett underlag för samtalet, inte en fullständig granskning.
TA MED TILL NÄSTA SAMTAL
Börja här.
Markera det ni vill ta vidare. Dina val finns bara på den här sidan och sparas inte när du lämnar den.
Checklistan laddas ner som PDF med dina markeringar.
LÄS VIDARE HOS KÄLLORNA
Vägledningen bakom.
Primärkällor som stöder resonemangen. Prioriteringar och checklistor är ITKoncepts förslag och behöver anpassas till er miljö.
- CERT-SERåd kring säkerhet i e-post
- CERT-SEHantera nätfiske (phishing)
- CERT-SEÖka motståndskraften mot bedräglig e-post
- PTSAtt motverka tillvägagångssätt där elektroniska kommunikationstjänster används för att genomföra bedrägerier · PTS-ER-2024:31
- Microsoft LearnEmail authentication in cloud organizations
- RFC EditorRFC 7208 · Sender Policy Framework (SPF)
- RFC EditorRFC 6376 · DomainKeys Identified Mail (DKIM) Signatures
- RFC EditorRFC 7489 · Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- Microsoft LearnSet up SPF to identify valid email sources for your custom cloud domains
- Microsoft LearnSet up DKIM to sign mail from your cloud domain
- Microsoft LearnSet up DMARC to validate the From address domain for cloud senders
- NCSCImplement a DMARC policy of none
- NCSCMark spoof emails as spam
- NCSCReject spoof emails
- NCSCRecommended types of MFA
- NCSCPhishing attacks: defending your organisation