Hendelseshåndtering, kryptografi, og tilfellet WPA3 vs. TLS

Hendelseshåndtering er et begrep som vanligvis brukes ved datainnbrudd, men i en mer generell betydning omfatter det håndterings- og oppfølgingsrespons for enhver sikkerhetshendelse, inkludert håndtering av nyoppdagede sårbarheter i kritiske systemer. Hvordan ser hendelseshåndtering ut i tilfelle angrep på underliggende kryptografiske protokoller som brukes i verdensomspennende nettverk? Og enda viktigere, hvordan bør det se ut?


På CES 2018 i januar annonserte Wi-Fi Alliance utgivelsen av Wi-Fi Protected Access 3 (WPA3), den siste oppdateringen til WEP, WPA og WPA2-serien. Det som er mest bemerkelsesverdig i denne utgivelsen er timing. Det har gått nesten 14 år fra den forrige WPA2-standarden og utgivelsen av WPA3. Fjorten år er et årtusen i internettid, men for protokollstandardisering er det ikke så overraskende lenge å vente. Hjørnesteins-protokollen for internettsikkerhet, TLS, tok nesten 10 år å oppdatere fra TLS 1.2 til TLS 1.3. Men, det er en ting som gjør WPA3 enda mer interessant: KRACK.

Ryktene sier at WPA3 kom som svar på KRACK-angrepet i oktober 2017. Mens WPA2 har flere kjente svakheter, var KRACK et angrep som ser ut til å ha vært en katalysator til handling. Faktisk gikk det kun måneder fra kunngjøringen av KRACK til kunngjøringen av WPA3. Til sammenligning har TLS 1.2 blitt utsatt for flere betydelige angrep på protokollsikkerheten: FREAK, Logjam, DROWN, BEAST, CRIME, BREACH, POODLE, i tillegg til mange angrep uten <<fancy>> navn. (Heartbleed er utelatt fra denne listen siden det var et angrep som utnyttet sårbarheter i implementeringen, ikke selve protokollen.) Flere av disse angrepene ble publisert lenge før det første utkastet til TLS 1.3 i 2014 (nesten 4 år før de ble fullført).

Sikkerhetshendelser skjer. Alle vet det. Det bør ikke være overraskende at angrep på kritiske protokoller også forekommer, men av en eller annen grunn reagerer verden som overrasket og sjokkert hver gang en sikkerhetsforsker finner et nytt spektakulært sikkerhetshull i en protokoll.

Hvorfor er vi så uforberedt på å respondere på fremtidige protokollangrep?

Tilsynelatende forventer de fleste at den gåtefulle << kryptografiske kjerne >> av en protokoll er ubrytelig. I virkeligheten er slik kryptografi utformet for å beskytte mot bestemte angrepstyper. Hvis en angriper finner en ny angrepsvektor, er det ikke nødvendigvis noen garanti for en protokolls sikkerhet. Dette kan ses i bekymringen rundt moderne kryptografiske protokoller i møte med forestående kvantedatamaskiner – en kvantedatamaskin er en ny type motstander som disse protokollene ikke var laget for å beskytte mot.

I tillegg til naivitet med hensyn til sikkerhetsgarantier, er det store omfanget av hendelseshåndteringen for protokollangrepene avskrekkende. I stedet for å beskytte systemer innen en organisasjon snakker vi om å beskytte hele verden (Wi-Fi, internett, etc.). Men dette understreker viktigheten av å ha en plan for når standarder blir oppdatert, når og hvordan gamle protokoller blir fjernet fra bruk, og hvordan en vanlig bruker kan være trygg på at svakheter er blitt håndtert, slik at tjenesten igjen er trygg å bruke.

For øyeblikket er den eneste tilsynelatende planen for protokollangrep å få leverandøren til å produsere en sikkerhetsoppdatering <<så fort som mulig>>. I tillegg har man alle tredjepartsleverandører som har bygd inn protokollen i sine løsninger og tjenester, som må sørge for å få implementert og integrert sikkerhetsoppdateringen. Deretter er det opp til alle organisasjoner og sluttbrukere som er avhengige av denne protokollen i sine systemer å få oppdatert til siste versjon. Noen haster med å få oppdatert systemene, andre bruker lengre tid, og det er svært utfordrende for den vanlige brukeren å vite hvilke systemer som er patchet og hvilke som ikke er det. Mange systemer blir aldri patchet, og man får i mange tilfeller som bruker ingen andre valg enn å akseptere risikoen. Generell håndtering av slike angrep er uorganisert og ikke transparent i beste fall. Dette kan ses i tilfellet TLS 1.2.

Hvis utgivelsen av WPA3 faktisk skyldes KRACK, har Wi-Fi Alliance gjort en beundringsverdig jobb i å reagere på angrepet. Videre, basert på WPA2s historie, kan vi forvente at WPA3 vil være obligatorisk for alle enheter som bærer Wi-Fi-varemerket innen de neste 1-2 årene – noe som er en rimelig gjennomføring av implementeringen. Å ha planer for håndtering av sikkerhetshendelseser på alle nivåer er avgjørende. I denne raskt utviklende verden vet vi ikke hvordan neste cyber-angrep vil skje, og å lage en responsplan gjør det mulig å forberede seg mot det uunngåelige.