Detta är en artikel om CIS-kontrollerna, version 7 och den här artikeln handlar om hur du bygger ett skydd för webbläsare och e-post. Två av de tveklöst vanligaste initiala vektorerna vid ett intrång. Det är med andra ord viktiga åtgärder som placeras här. Personligen tycker jag detta borde vara åtgärd nummer 1.
Nyckelinsikter
- Enkla åtgärder: hjälp andra, inför SPF/DKIM och någon gång även DMARC.
- Inför ett skydd på DNS-nivå som blockerar uppslag av skadliga domäner. Det hjälper på bred front, inte bara webbläsare och e-post.
- Inför en webb-proxy, främst för att kunna tvinga HTTP(S)-trafik genom ett ställe, som sedan kombineras med lokala brandväggsregler (endast webbläsare får nå proxy) och centrala brandväggsregler (endast proxy får komma åt HTTP(S)-resurser.
- Undersök möjligheten att införa ett dedikerat anti-phishingskydd, det har ni mycket att vinna på.
Innehållsförteckning
- Inledning
- Åtgärdsområdets målsättning
- Införande
- Steg 1 - Avgör mognad
- Steg 2 - Påbörja införande
- Steg 3 - Mäta effektivitet
- Sammanfattning
Inledning
Du kommer inte kunna läsa en enda hotrapport, se här och här , som inte nämner phishing via e-post eller webbläsaren. Inte nog med att phishing alltid omnämns så är det också den tveklöst vanligaste metoden för att påbörja ett intrång. Detta gäller för såväl opportunistiska som statliga angrepp. Zerodays låter kanske otäckt, men det är phishing och mer specifikt spearphishing som fler borde oroa sig för på riktigt eftersom det så ofta lyckas.
Det är därför med stor glädje jag presenterar den här artikeln som handlar om skydd i webbläsare och e-post. I CIS-kontrollerna finns det totalt 10 st specifika åtgärder som är fördelade i två övergripande åtgärdsområden (applikation och nätverk). Åtgärderna avser exempelvis saker som att inte tillåta plugins i webbläsaren, implementera SPF, DKIM och DMARC samt DNS-loggning/-blockering.
Åtgärdsområdets målsättning
Det finns egentligen inte så mycket att säga här. Målsättningen med åtgärd 7 är att införa åtgärder som skyddar mot de två absolut vanligaste vektorerna för intrång, webbläsaren och e-post. Saknar du skydd här innebär det en avsevärt förhöjd sannolikhet för intrång.
Införande
Steg 1 - Avgör mognad
Mognaden syftar inte till att vetenskapligt etablera er mognad avseende skydd av webbläsare och e-post. Den syftar endast till att ge en initial och övergripande bild av var ni står, det kanske inte är här ni ska lägga er tid… eller så är det precis här ni ska lägga tid?
Ingen förmåga
Räcker det inte med antivirus?!
Partiell förmåga
Webbläsaren uppdaterar vi automatiskt, all HTTP(S)-trafik går genom en proxy där det finns en URL-filtrering. Vi har även infört ett SPF-record i vår DNS.
God förmåga
Plugins i webbläsaren är vitlistade, all trafik genom proxy, lokala brandväggsregler tillåter endast webbläsaren mot proxy, SPF/DMARK/DKIM… vi har det. Vi irriterar oss på att URL-filtreringen inte uppdateras tillräckligt snabbt.
Jag misstänker att det finns stor variation mellan organisationer när det gäller skydd av webbläsare och e-post. Men det finns troligen åtminstone någon åtgärd en majoritet av organisationer och företag skulle kunna hitta och genomföra.
Jag är av inställningen att mycket tid och energi ska placeras precis här, klienterna och klientskyddet. Som tidigare nämnt är det här en majoritet av intrång börjar och det är därför av stor vikt att också förstå hur angreppen genomförs och hur de kan blockeras, upptäckas eller förhalas så tidigt som möjligt i angreppskedjan.
Steg 2 - Påbörja införande
Vissa saker är viktigare än andra. Det här med plugins kan du vänta med, det är väldigt få angrepp som börjar med att en användare installerar ett plugin till en webbläsare som sedan kan utnyttjas av en angripare. Däremot börjar väldigt många angrepp med någon form av länk du ska besöka. Därför skulle jag vilja slå ett slag för följande:
- Lägg till ett SPF-rekord i DNS:en. Det är enkelt och hjälper andra företag att veta om någon försöker utnyttja er domän för phishing. Ni får gärna även passa på att införa DKIM, det är också bra för andra att veta att ER e-postserver har skickat ett givet mail.
- Börja med att undersöka era möjligheter att blockera skadliga domäner på DNS-nivå. Det ger skydd inte bara i webbläsaren utan generellt sett. Säkerställ att ni har DNS-loggning påslaget och gör några tester av dessa för att säkerställa att ni har det ni tror ni får.
- Komplettera gärna detta med någon, eller några, källor med listor på skadliga domäner ni kan plugga in i lösningen för (1).
- Därefter skulle jag vilja föreslå att ni skaffar en webb-proxy för all kommunikation mot HTTP(S)-baserad. Huruvida ni väljer att bryta TLS-koppel får ni avgöra själva. Det innebär trots allt att ni behöver sprida trust till en intern CA vilket kanske upplevs som bökigt i förhållande till “vinsten”.
- Implementera DMARC för att “slutföra” DKIM/SPF/DMARC-triaden.
- Undersök möjligheten och alternativen till att skaffa en dedikerad anti-phishinglösning.
- Avancerat: Undersök möjligheten att köra webbläsare i en typ av sandbox utan möjligheter att skriva/läsa från övriga delar av OS/lagring. Det kanske går att sprida en sådan lösning till en majoritet av de anställda?
Steg 3 - Mäta effektivitet
Och så var vi här igen, mäta effekter av skyddsåtgärderna. Innan ni kan mäta något behöver ni börja med att konstatera någon form av basvärde. Upptäcker ni några som helst skadliga länkar, e-post osv idag? Anteckna och notera som basvärdet, er utgångspunkt.
- Samla in mätningar per dag/vecka/månad. Jämför med basvärde, upp eller ner? Fler eller färre?
- Får ni fler “rapporter” från användare som resultat av det förbättrade skyddet?
- Utifrån eventuellt nya blockeringar, hur många av dessa bedömer ni hade haft potential att leda till en incident?
Sammanfattning
Kort och gott, ska du skydda något ska du skydda webbläsaren och e-posten. Det är här som en klar majoritet av alla cyberangrepp börjar och där du således kan få mest pang för pengarna. Det finns som alltid många vägar att gå, men fokus bör vara på att upptäcka phishing, skadliga länkar eller annat innehåll som på något sätt kan antas vara skadligt.
I sammanhang av det här skulle jag också vilja slå ett förslag på “assume breach”, alltså antag intrång. I många fall innebär detta att nya processer (exekverande program) finns på klienten med vissa givna mönster och beteenden. Vad ser ni av detta? Det är nästa steg… och också nästa åtgärdsområde inom CIS… fortsättning följer.