Statens sikkerhed

sikkerdigital.dk

1. juli skal staten være færdig med at implementere Tekniske minimumskrav for statslige myndigheder
For de fleste tiltags vedkommende er det lidt svært at sige om man er kommet i mål, men der er også dele som er fuldt synlige ude fra det åbne Internet.
Herunder kan du se status på nogle få udvalgte domæner. Det ser ikke lige godt ud alle steder, godt der er lang tid til d. 1. juli.

DomæneDNSSECDMARCTLS 1.2
borger.dkOKOKOK
cfcs.dkOKOKOK
datatilsynet.dkOKOKOK
digst.dkOKOKOK
domstol.dkFAILFAILOK
dst.dkFAILFAILOK
em.dkOKOKOK
fm.dkOKFAILOK
fmn.dkOKOKFAIL
forsvaret.dkOKOKFAIL
ft.dkOKOKOK
justitsministeriet.dkOKFAILFAIL
pet.dkFAILFAILFAIL
politi.dkOKOKOK
regeringen.dkFAILOKFAIL
rigsrevisionen.dkOKOKFAIL
sikkerdigital.dkOKOKOK
skat.dkOKOKOK
smittestop.dkFAILOKFAIL
sst.dkFAILFAILOK
statens-it.dkOKOKOK
um.dkOKFAILOK

Sidst opdateret: 1/07/2020

Årets første fuser

Ufravigelige krav

Da kalenderen i nat skiftede til 2020 blev årets sidste og ved samme lejlighed  det nye års første sikkerheds fuser en realitet.
30 September 2019 blev en række ufravigelige krav til statens IT sikkerhed offentliggjort. Der er ikke noget revolutionerende i kravene, der er mest tale om best practise som burde have været indført for mange år siden.
Nogle af kravene havde deadline 1/1/2020, andre først senere i 2020.

Aktivering af DNSSEC på alle statens domæner er et af de krav som havde deadline 1/1/2020.

For kunder hos Statens IT, set det egentlig OK ud, der er ihvertfald sket noget.

Hos de styrelser, ministerier osv. som står for egen IT drift ser tingene helt anderledes ud.
Nogle af dem som ikke nåede i mål er:
Justitsministeriet.
Forsvarsministeriet
Rigsrevisionen
Center for Cybersikkerhed
Forsvarets efterretningstjeneste
Politiets efterretningstjeneste

Men der er vel en eller anden god forklaring. Noget med at det er ekstremt svært at aktivere DNSSEC på et domæne?
Nej det er der ikke, lad os nu tage Justitsministeriet som eksempel, opgaven består i at trykke på en knap der ser således ud hos deres DNS host Cloudflare:

Den opgave har man haft 93 dage til at få udført, og mislykkes alligevel.
Lad os håbe år 2020 byder på mindre snak og mere handling på sikkerhedsområdet, det er der i den grad brug for.

 

 

 

Når gode råd bliver dårlige

DR-Logo

De kriminelle som sender os phishing emails er blevet bedre til at skrive dansk og det er jo lidt et problem når de kloge mennesker, som rådgiver os i forhold til phishing i årevis har angivet dårligt dansk som et af de sikre kendetegn ved en phishing email.
DR har skrevet en artikel om problemet med vellignende phishing emails.
Artiklen starter fint med en gennemgang af problemet og viser en del eksempler.
Men i sidste afsnit: “Kig på afsenderadressen” bliver den gode artikel til en direkte misvisende og farlig artikel.

Når det drejer om ansvarlige firmaer 1 som Yousee, SKAT, Netflix, Paypal & Twitter er det ganske rigtig det sikreste blot at kigge på afsenderadressen for at afgøre om en given email er falsk.
Men når det drejer sig om email fra Postnord gælder dette tip altså ikke, ingen af Postnords domæner er sikret mod misbrug, enhver kan frit misbruge @postnord.dk, @postdanmark.dk og @ecmail.post.dk email adresser.

Det skal for god ordens skyld nævnes at Postnord gentagne gange de sidste 7 år er blevet opfordret til at beskytte deres domæner mod misbrug, indtil videre uden held.
Ligeledes er journalisten bag artiklen forsøgt kontaktet med henblik på at få rettet fejlen, også uden held.

1 Mange firmaer har valgt at beskytte sig selv og deres kunder mod falske emails, du kan se nogle af dem her.

BIMI

BIMI logo

DMARC handler normalt om sikkerhed. Din egen sikkerhed, dine kunders sikkerhed og ikke mindst dine leverandører og samarbejdspartneres sikkerhed. Hele vejen rundt kan man med DMARC slippe for de mest vellignende phisning emails ved hjælp af DMARC.
Hvis den slags sikkerhed er helt uinteressant for dig er DMARC uinteressant for dig….. og dog, bliv lige hængende lidt endnu.
I sidste uge blev Google/Gmail en del af BIMI projektet.

BIMI er den korte udgave af Brand Indicators for Message Identification.
Med BIMI kan man få vist sit firma logo sammen med afsender navnet i modtagerens inbox.
Det kunne f.eks se således ud.

BIMI example

Ser det interessant ud? Jamen så blev DMARC alligevel interessant for dig. BIMI er nemlig kun en mulighed hvis du har en DMARC reject eller quarantine policy i drift.

Læs mere om BIMI

Bedre sent end aldrig – men

Digitaliseringsstyrelsen

NemID phishing har været vældig populært denne sommer.

Nemid.nu domænet har været beskyttet imod misbrug i lang tid, så de kriminelle har været nødt til at anvende alternative domæner.

Først blev NETS misbrugt, deres domæne (nets.eu) står til fri afbenyttelse, de er aldrig rigtig blevet færdige med at implementere DMARC. De er over årene adskillige gange blevet gjort opmærksomme på at det ville være hensigtsmæssigt hvis de fik sig en fuld DMARC implementering, men den slags behøver man som monopol ikke at bekymre sig om.

Så var det Dansk ITs tur (dit.dk), Email sikkerheden hos Dansk IT har ikke været tidssvarende siden engang i 2005. Så ja, det er vel ikke så overraskende at deres domæne blev misbrugt.

Så kom turen til Digitaliseringsstyrelsen (digst.dk)
Nu begynder det at blive lidt pinligt. Tilbage i 2017 deltog jeg i en workshop hos Center for Cybersikkerhed sammen med Digitaliseringsstyrelsen, Statens IT & Danske Bank.
Vi kom med input til hvad der senere blev til Center for Cybersikkerheds vedledning om DMARC.
Jeg har jo i en del år forsøgt at udbrede kendskabet til DMARC, så jeg gik vældig glad hjem fra den workshop og tænkte, “Fedt, nu skal de alle hjem og igang med DMARC”, ja OK ikke Danske Bank, de var den første bank der implementerede DMARC i Danmark.
Statens IT kom hurtigt igang, men hos Digitaliseringsstyrelsen skete der ikke rigtig noget, trods nogle opfordringer til at komme igang blev deres domæne ved med at være ubeskyttet.

Så gik det galt, og fik de endelig fingrene ud hos Digitaliseringsstyrelsen.
De har nu en fuld DMARC implementering + DNSSEC + DANE.

Så tillykke til Digitaliseringsstyrelsen og velkommen på Elite listen

Bedre sent end aldrig – men det havde været endnu bedre hvis de havde handlet før de blev misbrugt.

NemID phishingmail i omløb
Styrelse advarer: NemID-svindlere på spil

SPF skrald

Landfill

Forholdsvis mange firmaer har et domæne med en defekt SPF record.
Den nok hyppigste årsag til SPF record defekter er for mange DNS opslag.

Synderen er for det meste Sender ID standarden.
Sender ID havde nogle alvorlige defekter fra fødsel, og kun nogle Microsoft ildsjæle tog i en periode standarden alvorligt, herefter overgik den hurtigt til en slags vegetativ tilstand.
I slutningen af 2011 begyndte selv Microsoft at anvende SPF.
Endelig i 2015 blev Sender ID standarden erklæret officielt død.

Der er dog stadig masser af firmaer der vil bede dig lave tilføjelser til din SPF record som kun har til formål at understøtte den afdøde Sender ID standard, det bliver desværre i sidste ende tit på bekostning af SPF funktionalitet som ophører med at virke.
Det hele bliver ekstra forvirrende af at disse leverandører omtaler Sender ID understøttelsen som om der var tale om SPF.

I et forsøg på at komme dette problem til livs, kommer her en liste over elementer du kan fjerne fra SPF recorden i roden af dit domæne, idet de ikke har noget med understøttelse af SPF standarden at gøre.

include:emsd1.com
include:trustpilotservice.com
include:mktomail.com
include:agspf.agillic.eu
include:_spf.presscloud.com
include:_spf.anpdm.com
include:send.aweber.com
include:spf.mailjet.com
include:mailmailmail.net
include:bounce.peytz.dk
include:_spf.createsend.com
include:emarsys.net
include:emsmtp.com
include:emarsys.us
include:emsmtp.us
include:musvc.com
include:spf.sendinblue.com
include:_spf.salesforce.com
include:carmamail.com
include:hubspotemail.net

Listen vil blive opdateret efterhånden som jeg falder over mere skrald

Der eksisterer også en del firmaer med denne include i SPF recorden i roden af deres domæne:

include:amazonses.com

Det er det lodret modsatte af hvad Amazon SES angiver i sin SPF vejledning, så den kan også fjernes.

Læsestof:
M3AAWG Best Practices for Managing SPF Records.
SPF Standarden RFC 7208.

 

Transmission af personoplysninger via e-mail

Fra nytår træder Datatilsynets nye regler for transmission af personoplysninger via e-mail sådan rigtig i kraft.
Vejledningen er lidt uklar, der er mange “kan” og “bør” og meget få “skal” og “er”
Alt i alt, er der som databehandler mulighed for at komme galt afsted.

Tænk hvis vi havde fået simple regler i stil med:
SMTP trafik skal foregå over en TLS forbindelse.
Transmission af personoplysninger der omfatter mere end et enkelt individ skal end-to-end krypteres.

Nå, tilbage til den besværlige virkelighed.

Der er også ting i vejledningen som er helt klart beskrevet, det er f.eks altid databehandler (afsenders) ansvar at en e-mail kan sendes sikkert til modtagerens mailserver.

Det er jo klar tale, men hvordan finder man ud af om det overhovedet kan lade sig gøre?

Lad os forestille os jeg vil sende en e-mail over TLS fra dmarc.dk til datatilsynet.dk.

I Holland tager man elementær sikkerhed noget mere alvorligt end vi gør her i Danmark, på https://internet.nl kan man finde en funktion til at teste et domænes e-mail konfiguration.

Her kan du se en rapport for dmarc.dk
Så langt, så godt, min egen e-mail løsning kan godt transmittere e-mail over TLS.
Nu er det så min opgave at sikre mig jeg kan sende sikkert til Datatilsynets mailserver, her kan du se en rapport for datatilsynet.dk
Ja kønt er det jo ikke ligefrem, e-mail sikkerhed har bestemt ikke nogen høj prioritet hos Datatilsynet, men det er dog muligt at levere en e-mail over en TLS forbindelse til dem.

Så er alt vel godt, og jeg kan roligt trykke på Send knappen?
Ja og nej, Datatilsynet har ikke sikret datatilsynet.dk med DNSSEC, så jeg skal kunne  leve med at min e-mail falder i forkerte hænder hvis nogen har overtaget kontrollen over indgående e-mail til @datatilsynet.dk adresser.

Datatilsynet kunne selvfølgelig bare aktivere DNSSEC for datatilsynet.dk, det tager ikke mange minutter, hos en del DNS udbydere kræver det kun et tryk på en knap.
Udfordringerne stopper imidlertid ikke her, Datatilsynets e-mail leverandør anvender heller ikke DNSSEC. Der er ikke tale om noget unikt for netop deres leverandør, heller ikke de helt store e-mail leverandører som G-Suite & Office365 anvender DNSSEC.

Jeg havde mig en god lang snak med Googles support om netop dette. Det er ikke overraskende ikke specielt nemt at få Google til at indrømme deres standard konfiguration ikke er helt sikker, på den anden side er jeg heller ikke specielt nem at slippe af med igen.

Til slut tryllede Google 4 DNSSEC signede MX hosts op af hatten til mig.

mx1.smtp.goog
mx2.smtp.goog
mx3.smtp.goog
mx4.smtp.goog

Anvender du G-Suite kan du udskifte dine eksisterende MX records med ovenstående, for at få bedst mulighed sikkerhed for at din e-mail leveres til dig.

Alt i alt:
Vi skal snart leve med nogle nye strengere regler for e-mail som skal gøre omgangen med personoplysninger mere sikker.
På papiret ser det fint ud, men i realiteten er der tale om et sminket lig.

Lidt læsestof:
DK-Hostmasters statistik over DK domæner med DNSSEC
How-to Geek om DNS Cache poisoning
Wikipedia artikel om DNS Spoofing