Da 80 % af webangrebene er browserbårne, bliver organisationer konstant udsat for forskellige angreb, når medarbejderne bruger deres browser. Disse inkluderer drive-by downloads, malvertising, ondsindet kodeindsprøjtning, cross site scripting og mange andre.
Som følge heraf søger organisationer konstant efter effektive måder at beskytte sig mod netbårne risici, trusler og angreb. Nogle organisationer henvender sig til sikkerhedsløsninger til browserisolering i et forsøg på at håndtere disse angrebsvektorer. I denne artikel vil jeg uddybe, hvorfor denne tilgang er forældet og ineffektiv og argumentere for, at der er bedre og mere sikre browsersikkerhedsløsninger, der skal overvejes.
Hvad er browserisolering?
Når en bruger besøger et websted, browseren henter sidens filer fra en Webserver og så grafisk gengiver siden på enhedens skærm. Fra et sikkerhedsmæssigt perspektiv er dette en fremtrædende angrebsflade, fordi den involverer at køre kode fra en ukendt kilde på enheden.
Browserisolering er en teknologi, der adskiller processen med at indlæse websider fra brugernes fysiske enheder. På den måde kan filer og kode ikke nå brugerens enhed og dens operativsystem, hvilket forhindrer potentielt ondsindet kode i at køre på en brugers enhed og reducerer risikoen for download af malware.
Med andre ord beskytter browserisolering browseraktivitet mod kodebaserede trusler af flytte internetaktivitet væk fra en virksomheds lokale netværk og infrastruktur.
Ulemperne ved browserisolering
Browserisoleringstilgangen har mange problemer, herunder latensproblemer, brugerfrustration, høje omkostninger, en underordnet sikkerhedsstilling og ineffektivitet. Desuden mener vi, at browserisolering ikke længere er relevant i nutidens trusselslandskab.
Nogle af hovedudfordringerne med browserisolering inkluderer:
Dårlig ventetid og brugeroplevelse
Browserisolering er forstyrrende for brugeren. Hvis browserisolationen hostes på en offentlig sky eller et geografisk fjernt datacenter, vil slutbrugeren normalt opleve dårlig browserhastighed og ydeevne. Hver gang brugere vil starte browseren, skal de desuden først hoppe gennem browserisoleringsapplikationen. Dette kan forårsage frustration, især hvis applikationen ikke er opdateret i overensstemmelse med browseren, hvilket kan føre til, at nogle websteder simpelthen ikke fungerer i browserisolation.
Derudover forstyrrer isoleringsprocessen alvorligt dynamiske webapplikationer, da de er JavaScript-tunge og inkluderer en masse kodegengivelse på klientsiden. Med de fleste SaaS-applikationer, der fungerer på den måde, er browserisolering ikke et relevant værktøj for cloud-positive organisationer.
Belastende for IT-teamet
De førnævnte latens- og kompatibilitetsproblemer bruger også meget af IT-teamets tid. IT-teams er forpligtet til at installere og opdatere browserisoleringssoftwaren på hver endpointenhed og derefter tage sig af alle de fejl og problemer, der opstår. Denne udfordring bliver mere kompliceret, når der er mange medarbejdere at tage sig af, med fjernarbejde, og når tredjepartsleverandører også bruger organisationens software.
Dette fører til, at it-teams i det uendelige beskæftiger sig med kompatibilitetsproblemer, ikke-responsive websteder eller suboptimal browsing, mens de distraherer dem fra vigtigere opgaver.
Høje omkostninger
Browserisolering er ikke kun ubehageligt at bruge, det er også dyrt. Browserisoleringsløsninger kræver, at al en organisations webtrafik dirigeres gennem skyen. Denne kontinuerlige kodning af trafikken kræver betydelig båndbredde, hvilket gør processen med browserisolering ressourcekrævende og dermed dyr for virksomheden. Tredjeparts offentlig cloud-infrastruktur, hvorpå isolationstjenesten er hostet, medfører ofte ekstra omkostninger, som også sendes videre til kunderne. Alt i alt gør disse isoleringsløsninger meget dyre for organisationer at bruge.
Browserisolation bruges sporadisk og efterlader organisationen afsløret
Som forklaret ovenfor er browserisolering dyrt og forstyrrende for brugerne. Som følge heraf vælger organisationer ofte kun at bruge det i bestemte indstillinger. Virksomheden kan for eksempel kun kræve dets brug i teams med adgang til særligt følsomme data eller alternativt fritage brugen af browserisolering, når brugere tilgår velkendte domæner som Google, Microsoft eller AWS.
Det er uheldigt, som vi har set talrige phishing-angreb, der udnytter AWS- eller Microsoft-domæner i det seneste år. Phishing-kampagner er blevet mere sofistikerede, og nogle formår at bruge legitime domæner til at sprede malware og stjæle personlige data. Så når organisationen tillader delvis brug af browserisoleringen, forbliver den udsat for reelle, udbredte phishing-angreb.
Generelt ineffektiv mod phishing-angreb
Selvom det bruges uden afbrydelser, er browserisolering for det meste ineffektiv mod phishing-angreb. Browserisoleringslogik er afhængig af at blokere cyberangreb ved at forhindre ondsindet webkode i at køre på brugerens enhed. De fleste phishing-angreb kører dog ikke våbenkode, men stjæler snarere legitimationsoplysninger eller andre personlige data indsat af intetanende brugere.
Phishing-angreb er afhængige af inputhandlinger fra brugere på websteder, der virker legitime. Faktisk inkluderer de fleste browserbårne angreb i dag en brugerinteraktion, som browserisolationen ikke kan forhindre. For at sige det helt klart kører phishing-angreb ikke kode, så browserisolering er praktisk talt ubrugelig mod disse angreb.
Dette er et stort sikkerhedshul, da phishing-angreb er en enorm trussel og bliver mere udbredt hvert år. Forskning foretaget af den britiske regering fandt, at af virksomheder, der rapporterede at have haft brud på cybersikkerheden eller angreb inden for det sidste år, 83 % har været udsat for phishing-angreb. Geniale phishing- og malware-angreb udgør en alvorlig trussel, der kan forårsage skade på organisationer på mange måder: økonomiske tab, privatlivslæk, datatab og meget mere.
Overflødig med Chromes webstedsisolering
For at toppe det hele viser det sig, at browserisolering allerede er en eksisterende sikkerhedsfunktion i Google Chrome. Funktionen, kaldet Site Isolation, er aktiveret som standard i Chrome lige siden dens version 67-opdatering i maj 2018. Den placerer sider fra forskellige websteder i forskellige processer, der hver kører i en sandkasse, der begrænser, hvad processen må gøre. Denne isolation er en specifik type browserisolation på klientsiden, der indlæser websiderne på en brugerenhed, men bruger sandboxing til at holde webstedskode og indhold adskilt fra resten af enheden.
Forskellen mellem de to mekanismer er, at Site Isolation mangler den fysiske adskillelse af skadelig kode fra enheden, mens Remote Browser Isolation kører hjemmesidekoden på cloud-infrastruktur uden for brugerens enhed. Denne forskel er dog af ringe betydning, fordi angrebsvektorer, der er i stand til at undslippe sandkasser og derefter angriber enheden, er relativt sjældne.
Sårbarheder, der inkluderer sandkasse-escape, betragtes som noget "højt niveau" angreb. De er sjældne, kræver kompliceret teknologisk ekspertise og er konstant eftertragtet af sikkerhedsforskere. Google, for eksempel, belønner betydelige summer til forskere, der rapporterede nævnte sårbarheder til virksomheden, som en del af deres bug bounty-belønningsprogram.
Alt dette er for at sige, at disse udnyttelser er så sofistikerede og opfindsomme, at de sandsynligvis også kan overgå andre konventionelle sikkerhedsfunktioner som Remote Browser Isolation. Enkelt sagt vil standard RBI'er sandsynligvis heller ikke blokere dem.
Browserisolering virker ikke: Det er tid til en ny æra inden for browsersikkerhed
I dag er browseren et ekstremt vigtigt og uerstatteligt arbejdsværktøj. Tidligere svarede browserisolering et reelt behov, som er at beskytte brugere mod ondsindet kode, der lurer på nettet. Imidlertid har det skiftende trusselslandskab, nemlig stigningen i ikke-kodeeksekverende phishing og fremkomsten af klientside-isolering, gjort RBI ineffektiv og irrelevant. Isolation er som at svømme i en astronautdragt – ikke særlig hjælpsom og meget belastende.
Det er tid til en holistisk tilgang til browsersikkerhed, der kan give bedre resultater for brugerne og for organisationens behov for cybersikkerhed. LayerX-sikkerhed giver de positive kerneelementer, der gjorde RBI nyttig: realtidsovervågning og styring af brugernes interaktion på nettet og beskyttelse mod malware. Det vigtigste er dog, at det giver reel beskyttelse mod browserbårne phishing-angreb uden at forstyrre brugerens oplevelse.
En god løsning til browsersikkerhed skal give brugerne mulighed for at bruge browseren problemfrit og nyde dens fordele med hensyn til produktivitet og effektivitet. Bygg derefter på de eksisterende sikkerhedsfunktioner i browseren og giv derefter det afgørende ekstra lag til at blokere de mest relevante angreb.
