Med 80 % av webbattackerna är webbläsarburna utsätts organisationer ständigt för olika attacker när anställda använder sin webbläsare. Dessa inkluderar drive-by-nedladdningar, malvertising, skadlig kodinjektion, cross site scripting och många andra.

Som ett resultat av detta söker organisationer ständigt efter effektiva sätt att skydda sig mot webbburna risker, hot och attacker. Vissa organisationer vänder sig till säkerhetslösningar för webbläsarisolering i ett försök att hantera dessa attackvektorer. I den här artikeln kommer jag att utveckla varför detta tillvägagångssätt är föråldrat och ineffektivt och argumentera för att det finns bättre och säkrare webbläsarsäkerhetslösningar att överväga.

Vad är webbläsarisolering?

När en användare besöker en webbplats, webbläsaren hämtar sajtens filer från en webbserver och då grafiskt renderar sidan på enhetens skärm. Ur ett säkerhetsperspektiv är detta en framträdande attackyta eftersom det involverar körning av kod från en okänd källa på enheten.

Webbläsarisolering är en teknik som skiljer processen att ladda webbsidor från användarnas fysiska enheter. På så sätt kan filer och kod inte nå användarens enhet och dess operativsystem, vilket förhindrar potentiellt skadlig kod från att köras på en användares enhet och minskar riskerna för nedladdning av skadlig programvara.

Med andra ord, webbläsarisolering skyddar surfaktivitet från kodbaserade hot av flytta Internetaktivitet bort från ett företags lokala nätverk och infrastruktur.

Nackdelarna med webbläsarisolering

Webbläsarisoleringsmetoden har många problem, inklusive latensproblem, användarfrustration, höga kostnader, en undermålig säkerhetsställning och ineffektivitet. Dessutom tror vi att webbläsarisolering inte längre är relevant i dagens hotlandskap.

Några av de största utmaningarna med webbläsarisolering inkluderar:

Dålig latens och användarupplevelse

Webbläsarisolering är störande för användaren. Om webbläsarisoleringen är värd på ett offentligt moln eller ett geografiskt avlägset datacenter kommer slutanvändaren vanligtvis att uppleva dålig webbläsarhastighet och prestanda. Varje gång användare vill starta webbläsaren måste de dessutom först hoppa igenom webbläsarisoleringsapplikationen. Detta kan orsaka frustration, särskilt om applikationen inte uppdateras i enlighet med webbläsaren, vilket kan leda till att vissa webbplatser helt enkelt inte fungerar i webbläsarisolering. 

Dessutom stör isoleringsprocessen allvarligt dynamiska webbapplikationer, eftersom de är tunga för JavaScript och innehåller mycket kodrendering på klientsidan. Med de flesta SaaS-applikationer som fungerar på det sättet är webbläsarisolering inte ett relevant verktyg för molnpositiva organisationer.

Betungande för IT-teamet

Ovannämnda latens- och kompatibilitetsproblem upptar också mycket av IT-teamets tid. IT-team måste installera och uppdatera webbläsarisoleringsprogramvaran på varje slutpunktsenhet och sedan ta hand om alla buggar och problem som uppstår. Denna utmaning blir mer komplicerad när det finns många anställda att ta hand om, med distansarbete och när tredjepartsentreprenörer också använder organisationens mjukvara.

Detta leder till att IT-team i oändlighet tar itu med kompatibilitetsproblem, webbplatser som inte svarar eller surfar inte optimalt samtidigt som de distraherar dem från viktigare uppgifter.

Höga kostnader

Webbläsarisolering är inte bara obekvämt att använda, det är också dyrt. Webbläsarisoleringslösningar kräver att all organisations webbtrafik dirigeras genom molnet. Denna kontinuerliga kodning av trafiken kräver betydande bandbredd, vilket gör processen med webbläsarisolering resurskrävande och därmed kostsam för företaget. Offentlig molninfrastruktur från tredje part, på vilken isoleringstjänsten är värd, medför ofta extra kostnader som också förs vidare till kunderna. Sammantaget gör dessa isoleringslösningar mycket dyra för organisationer att använda.

Webbläsarisolering används sporadiskt och lämnar organisationen exponerad

Som förklarats ovan är webbläsarisolering dyrt och störande för användarna. Som ett resultat väljer organisationer ofta att bara använda det i specifika inställningar. Till exempel kan företaget kräva att den endast används i team med tillgång till särskilt känslig data eller alternativt undanta användningen av webbläsarisolering när användare kommer åt välkända domäner som Google, Microsoft eller AWS. 

Detta är olyckligt som vi har sett många nätfiskeattacker som utnyttjar AWS- eller Microsoft-domäner under det senaste året. Nätfiskekampanjer har blivit mer sofistikerade och vissa lyckas använda legitima domäner för att sprida skadlig programvara och stjäla personlig data. Så när organisationen tillåter delvis användning av webbläsarisoleringen förblir den utsatt för verkliga, utbredda nätfiskeattacker.

Överlag ineffektiv mot nätfiskeattacker

Även om den används utan avbrott är webbläsarisolering för det mesta ineffektiv mot nätfiskeattacker. Webbläsarisoleringslogik bygger på att blockera cyberattacker genom att förhindra skadlig webbkod från att köras på användarens enhet. De flesta nätfiskeattacker kör dock inte beväpnad kod, utan stjäler autentiseringsuppgifter eller andra personliga uppgifter som har infogats av intet ont anande användare.    

Nätfiskeattacker är beroende av indata från användare på webbplatser som verkar legitima. Faktum är att de flesta webbläsarburna attacker idag inkluderar en användarinteraktion som webbläsarisoleringen inte kan förhindra. För att uttrycka det klart, nätfiskeattacker kör inte kod, så webbläsarisolering är praktiskt taget värdelös mot dessa attacker. 

Detta är en stor säkerhetslucka eftersom nätfiskeattacker är ett enormt hot och blir mer utbrett för varje år. Forskning av den brittiska regeringen fann att av företag som rapporterade att de hade intrång eller attacker mot cybersäkerhet under det senaste året, 83 % har varit utsatta för nätfiskeattacker. Genialiska nätfiske- och skadliga attacker utgör ett allvarligt hot som kan skada organisationer på många sätt: ekonomiska förluster, sekretessläckor, dataförlust och mer.

Redundant med Chromes webbplatsisolering

Till råga på allt visar det sig att webbläsarisolering redan är en befintlig säkerhetsfunktion i Google Chrome. Funktionen, som kallas Site Isolation, är aktiverad som standard i Chrome ända sedan dess version 67-uppdatering i maj 2018. Den placerar sidor från olika webbplatser i olika processer, som var och en körs i en sandlåda som begränsar vad processen får göra. Denna isolering är en specifik typ av webbläsarisolering på klientsidan som läser in webbsidorna på en användarenhet, men använder sandlådor för att hålla webbplatsens kod och innehåll åtskilda från resten av enheten.

Skillnaden mellan de två mekanismerna är att Site Isolation saknar fysisk separation av skadlig kod från enheten, medan Remote Browser Isolation kör webbplatskoden på molninfrastruktur utanför användarens enhet. Denna skillnad har dock liten betydelse eftersom attackvektorer som kan fly sandlådor och sedan attackerar enheten är relativt sällsynta.

Sårbarheter som inkluderar sandlådeflykt anses vara attacker på något "hög nivå". De är sällsynta, kräver komplicerad teknisk expertis och är ständigt eftertraktade av säkerhetsforskare. Google, till exempel, belönar avsevärda summor pengar till forskare som rapporterat nämnda sårbarheter till företaget, som en del av deras bug-bounty-belöningsprogram.

Allt detta är att säga att dessa exploateringar är av sådan sofistikering och uppfinningsrikedom att de förmodligen också kan överträffa andra konventionella säkerhetsfunktioner som Remote Browser Isolation. Enkelt uttryckt kommer standard RBI förmodligen inte att blockera dem heller.

Webbläsarisolering fungerar inte: Det är dags för en ny era inom webbläsarsäkerhet

Numera är webbläsaren ett oerhört viktigt och oersättligt arbetsverktyg. Tidigare svarade webbläsarisolering på ett verkligt behov som är att skydda användare från skadlig kod som lurar på webben. Men det föränderliga hotbildet, nämligen uppkomsten av nätfiske som exekverar icke-kod och tillkomsten av isolering av webbplatser på klientsidan, har gjort RBI ineffektivt och irrelevant. Isolering är som att simma i en astronautdräkt – inte särskilt hjälpsam och mycket betungande. 

Det är dags för ett holistiskt synsätt på webbläsarsäkerhet som kan ge bättre resultat för användare och för organisationens behov av cybersäkerhet. LayerX-säkerhet tillhandahåller de positiva kärnelementen som gjorde RBI användbar: realtidsövervakning och styrning av användarnas interaktion på webben och skydd mot skadlig programvara. Men viktigast av allt, det ger verkligt skydd mot webbläsarburna nätfiskeattacker utan att störa användarens upplevelse.

En bra lösning för webbläsarsäkerhet måste tillåta användare att använda webbläsaren sömlöst och dra nytta av dess fördelar när det gäller produktivitet och effektivitet. Bygg sedan på webbläsarens befintliga säkerhetsfunktioner och ge det avgörande extra lagret för att blockera de mest relevanta attackerna.