Ledare och yrkesverksamma som är ansvariga för e-postsäkerhet står inför ett fåtal sanningar varje dag. Det är förmodligen sant att deras e-post sänds via molntjänster och kommer med ett visst inbyggt skydd som gör ett OK jobb med att stoppa spam och malware. Det är förmodligen sant att de har lagt ned ansenlig tid, pengar och personalresurser på deras Secure Email Gateway (SEG) för att stoppa phishing, malware och andra mailburna hot. Trots detta är det också sant att e-post fortsätter att vara den mest vanliga källan till internethot varvid forskning from Deloitte visar att 91 % av alla cyberattacker inleds med phishing.
Varför kommer så många phish fortfarande igenom om anti-phishing och SEG-tjänster funnits så pass länge? Om du är välvilligt inställd till Ockhams rakkniv är det på grund av att SEG inte utformats för att skydda dagens små e-postmiljöer, och inte heller är effektiv vad gäller att på ett pålitligt sätt stoppa dagens phisingattacker.
Men om du behöver ett starkare case än vad Occam erbjuder — fortsätt att läsa!
Varför världen rört sig bortom SEG
Den mest framträdande förändringen inom e-postmarknaden är också vad som gör en konventionell SEG överflödig – övergången till molnbaserade e-posttjänster. Mer än 85 % av organisationer förväntas omfamna en ”cloud-first”-strategi lagom till 2025, enligt Gartner®. Organisationer som förväntar sig molnbaserad skala, motståndskraft och flexibilitet från sina säkerhetskontroller kommer inte att få det från traditionella enheter som SEG:ar.
När det gäller i synnerhet e-post, noterar Gartner® att, ”Avancerade e-postsäkerhetsfunktioner alltmer sätts i drift som integrerade molnbaserade e-postsäkerhetslösningar snarare än som en gateway” och att åtminstone 40 % av organisationerna använder inbyggda skyddsfunktioner från molnbaserade e-postleverantörer istället för SEG år 2023. Idag kommer mejl från överallt och går överallt – att sätta en SEG framför din Exchange-server är förlegat och att sätta en SEG framför molnbaserade inkorgar i en mobil- och remote-first värld är svårlöst. E-postsäkerhet idag bör följa dina användare, bör vara nära din inkorg, och bör vara ”överallt”.
Förutom att vara arkitektoniskt ur tiden brister en SEG även i att upptäcka avancerad phishing och socialt konstruerade attacker. Detta beror på att en SEG ursprungligen utformats för att hindra spam – ett omfattande problem som kräver prover från större attacker för att upptäcka och omintetgöra. Men dagens phishingattacker är mer krypskytt än hagelgevär. De är i små volymer, mycket riktade och utnyttjar vårt implicita förtroende i e-postkommunikation för att stjäla pengar och data. Att upptäcka moderna phishing-attacker kräver datorintensiv, avancerad e-postanalys- och hotdetekteringsalgoritmer som en SEG inte kan utföra i skala.
Ingenstans blottläggs en SEG:s obsoleta detektionsfilosofi mer än när administrativ personal ställs inför att skapa och finstämma ett berg av e-posthotpolicyer. Till skillnad från de flesta andra cyberattacker har e-postphishing och Business Email Compromise (BEC) för många ”fuzzy”-signaler och kan inte enbart upptäckas genom deterministiska hypotetiska påståenden. Dessutom står inte angripare still medan du skapar e-posthotpolicyer – de anpassar sig snabbt och ändrar tekniker för att kringgå reglerna du just skapat. Att förlita sig på justering av SEG för att stoppa phishing är som att spela spelet ”Klubba mullvad” när det riggats till angriparens fördel.
Se framåt för att stoppa phishing
Konventionellt e-postsäkerhetsskydd förlitar sig på kunskap om gårdagens aktiva attackegenskaper, däribland ryktesdata och hotsignaturer, för att upptäcka nästa attack, och kan därmed inte på ett tillförlitligt sätt erbjuda ett försvar mot moderna phishingattacker som ständigt utvecklas.
Vad som krävs framöver är säkerhetsteknik som inte enbart är medveten gårdagens aktiva phishingwebbplatser- och tekniker men som därutöver har kunskaper om hotaktörens nästa drag. Vilka sajter och konton äventyrar- eller etablerar dem för att använda i morgondagens attacker? Vilka koder och tekniker förbereder dem för att använda i sådana attacker? Var undersöker och rotar dem innan en attack?
Cloudflare Area 1 skannar, på ett proaktivt sätt, internet efter angriparinfrastruktur och phishingkampanjer som är under uppbyggnad. Area 1:s hotfokuserade webbcrawlers analyserar på ett dynamiskt sätt misstänkta webbsidor och koder och uppdaterar fortlöpande detektionsmodeller i takt med att angripares taktiker utvecklas– allt för att stoppa phishingattacker dagar innan de når inkorgen.
När det kombineras med 1T+ daily DNS-förfrågningar som observeras av Cloudflare Gateway, gör denna uppsättning av hotinformation det möjligt för kunden att stoppa phishinghot i de tidigaste stadierna av attackcykeln. Därutöver gör användningen av djup kontextuell analys för att förstå meddelandets andemening, ton, innebörd och trådvariationer det möjligt för Area 1 att förstå och särskilja mellan giltiga affärsprocessmeddelanden och sofistikerade imitationskampanjer.
Även om vi tror på skiktsäkerhet bör skikten inte vara överflödiga. En SEG duplicerar en hel del kapaciteter som kunder nu får ihopbuntade med deras molnbaserade e-posterbjudande. Area 1 har skapats för att förstärka – inte duplicera – inbyggd e-postsäkerhet och stoppa phishingattacker som kommer förbi de initiala försvarsskikten.
Planera inför ditt SEG-ersättningsprojekt
Det bästa sättet att börja med ditt SEG-ersättningsprojekt är att avgöra huruvida det rör sig om en ren ersättning eller en eventuell ersättning som börjar med ökning. Även om Cloudflare Area 1 har en hel del kunder som har ersatt sin SEG (mer om det senare) har vi också sett scenarier där kunder föredrar att köra Cloudflare Area 1 downstream av sitt SEG initialt, bedöma bägge tjänsters effektivitet och sedan fatta ett mer slutgiltigt beslut. Vi gör processen enkel oavsett vad du beslutar dig för!
När du startar projektet är det avgörande att involvera rätt intressenter. Du bör som ett minimum involvera en IT-admin för att se till att e-postleverans och produktivitet förblir oförändrad och en säkerhetsadmin för att övervaka detektionseffektivitet. Andra intressenter kan inbegripa din kanalpartner om det är din föredragna upphandlingsprocess och någon från integritets- och complianceteamet för att verifiera korrekt hantering av data.
I ett nästa steg bör du besluta dig för vilken driftsättningsarkitektur du föredrar med avseende på Cloudflare Area 1. Cloudflare Area 1 kan sättas i drift som MX-post över API:er och kan till och med köra i multi-modedriftsättning. Vi rekommenderar att du driftsätter Cloudflare Area 1 som MX-post för det mest effektiva skyddet mot externa hot men att tjänsten passar in i din värld baserat på din affärslogik och dina specifika behov.
Det slutliga förberedande steget består av att kartlägga ditt mejlflöde. Om du har flera olika domäner bör du identifiera var e-post från var och en av dina domäner dirigerar till. Kontrollera dina olika routingskikt (finns det exempelvis MTA:ar som förmedlar inkommande meddelanden?). En god förståelse för logiska och fysiska SMTP-skikt inom organisationen säkerställer korrekt dirigering av meddelanden. Diskutera vilken e-posttrafik Cloudflare Area 1 bör skanna (norr/söder, öst/väst, bägge) och var den passar in med dina befintliga e-postpolicyer.
Verkställande av övergångsplan
Steg 1: Implementera e-postskyddHär är de övergripande steg du bör följa om Cloudflare Area 1 konfigureras som MX-post (beräknad tidsåtgång: ~30 minuter):
Konfigurera downstream-tjänsten för att ta emot e-post från Cloudflare Area 1.
Se till att Cloudflare Area 1:s utgående IP-adresser inte är hastighetsbegränsade eller spärrade eftersom detta skulle påverka leverans av meddelanden.
Om e-postservern finns i lokalen, uppdatera brandväggsregler för att göra det möjligt för Cloudflare Area 1 att leverera till dessa system.
Konfigurera saneringsregler (exempelvis karantän, lägg till ämne eller meddelandetextprefix, och så vidare).
Testa meddelandeflödet genom att injicera meddelanden i Cloudflare Area 1 för att bekräfta lämplig leverans. (våra team kan biträda med detta steg.)
Uppdatera MX-post för att peka på Cloudflare Area 1.
Här är stegen om Cloudflare Area 1 är föremål för driftssättning downstream från en befintlig e-postsäkerhetslösning (beräknad tidsåtgång: ~30 minutes):
Konfigurera korrekta look-back-hops på Cloudflare Area 1 så att Cloudflare Area 1 kan upptäcka den ursprungliga avsändarens IP-adress.
Om din e-postserver finns i lokalen, uppdatera brandväggsregler för att göra det möjligt för Cloudflare Area 1 att leverera till e-postservern.
Konfigurera saneringsregler (exempelvis karantän, lägg till ämne eller meddelandetextprefix, och så vidare).
Testa meddelandeflödet genom att injicera meddelanden i Cloudflare Area 1 för att bekräfta lämplig leverans. (vårt team kan biträda med detta steg.)
Uppdatera leveransrutterna på din SEG för att leverera all e-post till Cloudflare Area 1 istället för till e-postservarna.
Steg 2: integrera DNSEtt av de mest vanliga post-e-poststegen som kunder följer är att integrera Cloudflare Area 1 med sin DNS-tjänst. Om du är Cloudflare Gateway-kund har vi goda nyheter – Cloudflare Area 1 använder nu Cloudflare Gateway som sin rekursiva DNS för att skydda slutanvändare från att få åtkomst till phishing- och skadliga sajter genom e-postlänkar eller webbsökning.
Steg 3: integrera med downstream säkerhetsövervaknings- och saneringstjänsterCloudflare Area 1:s detaljerade och anpassningsbara rapportering möjliggör en ögonblicklig överblick över hot. Genom att integrera med SIEM:ar genom våra robusta API:ar kan du enkelt korrelera Cloudflare Area 1-dektioner med händelser från nätverk, endpoint och andra säkerhetsverktyg för enklare incidenthantering.
Samtidigt som Cloudflare Area 1 tillhandahåller inbyggd sanerings- och meddelanderetraktion för att göra det möjligt för kunder att hantera hot direkt inom Cloudflare Area 1:s instrumentpanel väljer också många organisationer att integrera med orkestreringsverktyg för skräddarsydda listor med svarsstrategier. Många kunder utnyttjar våra API-hooks för att integrera med SOAR-tjänster för att hantera svarsprocesser inom ramen för sin organisation.
Mätmetoder för att mäta framgång
Hur vet du om ditt SEG-ersättningsprojekt varit framgångsrikt och lett till önskad effekt? Vi rekommenderar mätmetoder för mätning som är relevanta för såväl detektionseffektivitet som operativ enkelhet.
På detektionsfronten är den uppenbara mätmetoden för mätning antal och naturen av phishingattacker som spärrats innan och efter projektet. Ser du nya typer av phishingattacker som spärras som du inte tidigare sett? Får du insyn i kampanjer som når åtskilliga inkorgar? Den andra detektionsbaserade mätmetoden att ha i åtanke är antalet falska positiva svar.
På den operativa fronten är det avgörande att e-postproduktivitet inte påverkas. En god proxy för detta är att mäta antalet IT-ärenden som avser e-postleverans. E-postsäkerhetstjänstens tillgänglighet och drifttid är en annan nyckelfaktor att ha i åtanke.
Slutligen, och kanske viktigast av allt, bör du mäta hur mycket tid som ditt säkerhetsteam lägger ned på e-postsäkerhet. Förhoppningsvis är det mycket mindre än tidigare! En SEG är känd för att vara en ”heavy-lift service deployment” för fortlöpande underhåll. Om Cloudflare Area 1 kan frigöra ditt teams tid för att arbeta med andra kritiska säkerhetsfrågor, är det lika meningsfullt som att stoppa phishen själva.
Du är i sällskap av många
Anledningen till att vi formulerar en SEG-ersättningsplan här är eftersom många av våra kunder redan har gjort det och är nöjda med utgången.
Ett Fortune 50 globalt försäkringsbolag som betjänar 90 miljoner kunder i över 60 länder har exempelvis funnit att deras SEG är bristfällig vad gäller att stoppa phishingattacker. Det var i synnerhet en krävande process att leta efter ”missad phish” när det väl passerade SEG och nådde inkorgen. De behövde en e-postsäkerhetstjänst som kunde fånga dessa phishingattacker och stödja en hybridarkitektur med både molnbaserade inkorgar som inkorgar på plats.
Efter att ha satt Cloudflare Area 1 i drift downstream av deras Microsoft 365 och SEG-skikt skyddades vår kund från mer än 14 000 phishinghot inom den första månaden. Inget av dessa phishingmeddelanden nådde en användares inkorg. En enstegsintegration med befintlig e-postinfrastruktur innebar att underhåll och operativa frågor var nästan obefintliga. Cloudflare Area 1:s automatiserade meddelanderetraktions- och post-leveransskydd gjorde det vidare möjligt för försäkringsbolaget att därutöver enkelt söka efter- samt sanera eventuell missad phish.
Om du är intresserad av att tala med någon av våra kunder som har ökat- eller ersatt sitt SEG med Cloudflare Area 1 ber vi dig vänligen att vända dig till vårt account-team för att upptäcka mer! Om du vill se Cloudflare Area 1 in action ber vi dig registrera dig för en phishing-riskbedömning här.
Att ersätta en SEG är ett fantastiskt projekt för att passa in i din allmänna Zero Trust roadmap. För en fullständig sammanfattning av Cloudflare One Week och det senaste ber vi dig kolla in vårt sammanfattande webbseminarium.
-
1Gartner Press Release, “Gartner Says Cloud Will Be the Centerpiece of New Digital Experiences”, 11 November 2021
2GARTNER är ett registrerat varumärke och servicemärke som tillhör Gartner, Inc. och/eller dess dotterbolag i USA och internationellt och används här med tillstånd. Alla rättigheter förbehållna.