Min kollega och vän skrev för ett par veckor sedan om vikten att kunna återställa förlorat data och vikten av att ha planerat för återställning, design och automatisering för att kunna återställa data. Och som Fredrik nämner så är det bara en pusselbit i kampen mot hot. Att de finns hot visade inte minst attacken mot Coop i somras. Coop var dessvärre långt ifrån ensamma om att drabbas och vi ser där ett exempel på hur hotbilden flyttas från klienter till ett mer sofistikerat och riktade angrepp. I fallet mot Coop med flera attackerades servern för fjärrstyrning av servrar och klienter. I och med att servern för fjärrstyrning var infekterad fanns nu möjligheten att ladda ner ransomware till servrar och klienter.
Tittar vi på klientsäkerhet som min vän Stefan skrev om för ett par veckor sedan så är ett ”virus” i dag nästan utan undantag unikt och det är nästan alltid krypterad trafik. Detta innebär att signaturbaserade virus och traditionella brandväggar som bara tittar på upp till ”layer4” (ip:tcp port) är chanslösa. Oavsett om data ligger i molnet eller på marken i ditt egna moln eller en kombination av ”Cloud” och ”On prem” är traditionell brandvägg och virusskydd inte tillräckligt.
Ett enkelt sätt att skydda klienter och servrar är att använda ”allowed list” för utgående trafik. Försöker vi stoppa trafiken med en ”blocklist” är det nästan alltid för sent då signaturer sällan hittar unikt eller krypterat innehåll. För ett antal år sedan var det en omöjlighet på grund av öppningar mot Microsoft, Google, Acrobat servrar som finns på tusentals adresser med flera services. Nu när vi har en möjlighet att använda ”Internet Services” i vårt regelverk behöver vi inte bygga en ”Policy” som ser ut som en Schweizerost utan vi kan tillåta t.ex. ”Microsoft update”, Acrobat m.m. och efter det definiera protokoll och webfilter samt blockera övrig trafik. Jo, det kommer att bli ”false positives” och undantag, men en betydligt säkrare miljö då vi kan addera varningar mot nyligen registrerade domäner o.s.v. via webfilter, applikationsfilter och andra säkerhetsfunktioner för att förhindra anslutning från klient mot botnet och siter för nedladdning av skadlig kod.
Även på serversidan ökar vi säkerheten med en ”allowlist”. Tittar vi på lansering av nytt innehåll på applikationer i dag så sker det i en rasande fart. Se på Spotify, Banker, Konsumentsidor m.m. Innehåll och hur ”content” förändras så sker det med en rasande fart. Kravet på att utvecklare skall inveckla sidan är enormt. Det är inte längre FrontPage eller WordPress som används utan det styrs via APIer. JSON, XML och Java används för att integrera med applikationen. DevOps och för den delen applikationer finns inte bara bakom våra ”brandmurar” utan innehåll utvecklas utanför vår ”domän” Våra SaaS applikationer spinner upp i Google Cloud, Azure eller annan molntjänst. Detta ställer helt nya krav på hur våra applikationer skall skyddas och också vem som skall skydda tjänsterna. Cuebid använder teknik från F5 för att skydda applikationer (AWAF / ASM). Webbapplikationsbrandvägg kan köras på NGINX och BigIp-plattformar. Till skillnad från ovanstående exempel med Webfilter och Internet Services så sätts en WAF framför POD, Server, lastdelade servrar eller vad som skall skyddas. Trafiken som passerar dekrypteras, analyseras och lärs av AWAF och om så önskas krypteras igen. API anrop kan också autentiseras av APM modulen i bigip´n. När inlärningsperioden är över är det bara godkänd trafik och om det är enligt godkänt schema skickas anropet vidare mot tjänst.
I nästa blogg kommer jag gå in ipå detaljer vad som skiljer en ”WAF” från ”Next Generation Firewall” och vilka funktioner som hjälper oss att skydda våra applikationer.
Så låt endast den rätte komma in oavsett var i Cyberrymden hen kommer från.
