Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter.
Kryptering har længe været en hjørnesten i cybersikkerhed.
Uden kryptering ville data i transit være et åbent tag-selv-bord for alle med adgang til netværket.
Som sikkerhedsansvarlige ønsker vi, at vores brugeres data er beskyttet mod aflytning, manipulation og kompromittering. Set i det lys er Google QUIC og HTTP/3 en naturlig teknologisk udvikling.
QUIC er en moderne transportprotokol, som erstatter TCP og bygger på UDP, mens HTTP/3 er en applikationsprotokol, der anvender QUIC som fundament. Med andre ord, QUIC transporterer data, mens HTTP/3 strukturerer og formidler dem.
Begge protokoller bygger videre på ønsket om større fortrolighed, lavere latenstid og bedre ydeevne.
Men netop den stærke, end-to-end kryptering, der er indlejret i disse protokoller, vender samtidig op og ned på en af grundpillerne i netværksbaseret cybersikkerhed: synlighed.
QUIC krypterer ikke kun indholdet af webtrafikken, men også de metadata, man traditionelt har brugt til at analysere trafikkens karakter og identificere trusler.
Det gælder blandt andet metadata som servercertifikater, hostnavne og HTTP-headerfelter, som ellers kunne give vigtige indikationer om, hvorvidt trafikken indeholder skadeligt indhold.
Kryptering uden overblik giver sikkerhedstab
Det har en række konsekvenser, som bør give anledning til overvejelse hos enhver, der arbejder med netværkssikkerhed i dag.
Den lukkede struktur i QUIC betyder, at traditionelle netværksprodukter – som intrusion detection systems, DLP-løsninger og netværksovervågningsværktøjer – mister store dele af deres funktion.
QUIC-trafik ikke kan scannes for malware uden adgang til krypteringsnøgler, hvilket gør det vanskeligere at opdage skadeligt indhold som, dataeksfiltration og phishing-angreb.
Flere virksomheder forsøger derfor at omgå problemet ved at blokere eller deaktivere QUIC-trafik i deres firewalls og proxyservere. Det tvinger trafikken tilbage til mere gennemsigtige protokoller som HTTP/2 over TCP, hvor de eksisterende sikkerhedsværktøjer stadig virker.
Men det er en defensiv og midlertidig løsning. QUIC er allerede udbredt i Google, Microsoft og Facebooks systemer, og flere applikationer forventer netop denne protokol som standard.
Derudover bruges disse tjenester på netværk, som sikkerhedsafdelingen ikke kontrollerer – for eksempel hjemmearbejdspladser og 5G-netværk.
Samtidig er det teknisk og organisatorisk uhensigtsmæssigt at basere sikkerhedsstrategien på at afvise nye standarder, alene fordi de er sværere at kontrollere.
I stedet bør vi ændre vores tilgang og flytte beskyttelsen tættere på slutbrugeren. Browseren er i stigende grad det sted, hvor angreb opstår – det er her sessionen etableres, og her skadelig kode aktiveres.
Ved at implementere sikkerhedskontroller direkte i browsermiljøet, kan man genvinde overblik, synlighed og handlekraft, uden at kompromittere ydeevne eller bryde kryptering.
Sådan griber vi udfordringen rigtigt an
Denne arkitekturmæssige ændring indebærer dog, at vi også må gentænke, hvordan vi definerer politikker, adgang og kapacitet.
QUIC er ikke en trussel i sig selv – men det er en ændring i forudsætningerne, som vi skal forholde os aktivt til.
I vores arbejde ser vi et voksende behov for, at organisationer lægger en eksplicit strategi for QUIC, der balancerer kryptering med kontrol. Et første skridt kan være at formulere en klar politik med disse tre principper som fundament:
• Skab en formel politik for QUIC-brug i organisationen. Mange sikkerhedsprogrammer er endnu ikke opdateret til at tage stilling til QUIC, og det efterlader både sikkerhedshuller og teknisk gæld.
En formel politik bør definere, hvordan man balancerer behovet for moderne protokoller med ønsket om kontrol, og den bør være forankret i både tekniske og organisatoriske vurderinger.
• Begræns QUIC-trafik til godkendte tjenester og domæner. Hvis man endnu ikke har infrastrukturen på plads til fuldt ud at håndtere inspektion og risikovurdering af QUIC-trafik, kan man vælge en selektiv tilladelsesmodel.
Ved hjælp af DNS- og IP-lister kan man tillade QUIC til specifikke leverandører og tjenester – eksempelvis Google Workspace – mens al anden QUIC-trafik begrænses eller registreres særskilt. Det giver en kontrolleret overgang, snarere end et enten-eller-scenarie.
• Flyt inspektion og beskyttelse tættere på browseren. Når netværkslaget ikke længere giver den nødvendige indsigt, er det nødvendigt at flytte sikkerhedsmekanismerne helt frem til det punkt, hvor brugeren interagerer med internettet.
Browserbaseret sikkerhed giver mulighed for at opdage og afvise trusler som malware, phishing og uautoriseret datadeling i realtid – uanset hvilken protokol der bruges nedenunder. Det giver både robusthed og fleksibilitet i en arkitektur, der bliver stadig mere decentral.
QUIC og HTTP/3 er kommet for at blive. Hvis vi vil bevare synlighed og reaktionsevne, må vi rykke tættere på det sted, hvor truslerne opstår: i browseren.
I sidste ende handler det ikke om at vælge mellem sikkerhed og kryptering, men om at sikre, at beskyttelse følger med teknologien.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie, eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.
