Først. Bildet, et resultat av følgende utfordring til AI: “fjernaksess skaper paranoide myndigheter”, noe som illustrerer en dårlig utført jobb av meg, og som resulterer i nettopp et dårlig resultat, mye likt det jeg vil skrive om videre i artikkelen.
Status quo
Vi er alle på det samme laget når det gjelder å redusere risiko i den brutale digitale verden. Sårbarhetene florerer, men alle sårbarheter er ikke software sårbarheter. Installasjoner, design og arkitektur vil inneha «as designed» sårbarheter der mennesker har gjort, og ikke gjort, ting som er lite heldige for den helhetlige sikkerheten.
Her er artikkelen NCSC ga ut 15. mai 2024 rettet mot fjernaksess for virksomheter som er underlagt sikkerhetsloven:
Essensen i artikkelen er at mange hendelser har skyldtes sårbarheter på SSLVPN og WebVPN produkter, og at man derfor burde fase ut disse med annen teknologi. Man skal erstatte teknologi med teknologi. Vel. Joda. Jada. Men….
Hva er problemet?
Software sårbarheter har vært med oss lenge, og ingenting tyder på at de vil forsvinne med det første. Noen ganger tas man på senga av nulldagssårbarheter som på det tidspunktet ikke har en løsning, annet enn kanskje en «workaround». Og dette gjelder uansett teknologi, SSL, TLS, SSLVPN, WebVPN, IPsec, IKE, v1 eller v2, osv.
- IKE sårbarheten i Zyxel som rammet dansk energisektor
- Her er sårbarheten i IKE.
- Siste sårbarhet i Checkpoint VPN, inkludert IPsec
- Her er det sårbarheter i flere elementer, inkludert IPsec. HelseCERT har gitt ut en veldig alvorlig melding rundt denne sårbarheten som kan få store konsekvenser, selv om man kjører IPsec med IKEv2.
- CVE-2024-3400 sårbarheten i Palo Alto Networks GlobalProtect
- Her er det sårbarhet i OS som kan misbrukes via SSL/TLS, selv når man kjører IPsec og SSLVPN ikke er i bruk. Og det er jo litt av problemet.
I tillegg så er det en utfordring at “alle” benytter SSL/TLS for fjernaksess på en eller annen måte. Always-On VPN løsninger benytter TLS i etableringen av kommunikasjon, for autentisering og uthenting av konfigurasjon, så man blir ikke kvitt SSL/TLS spøkelset. I tillegg benyttes det mye jumpserver metodologi i form av en mellomtjener, som ofte er tilgjengelig direkte fra internet, og dette bruker også SSL/TLS.
Om man sier at SSL/TLS skal bort (jada, NCSC sier SSLVPN/WebVPN, men hvordan differensiere, og hva er poenget med å anbefale å gå bort fra det om man ikke skal ta alt?) så sitter vi igjen med få alternativer. Site to site VPN med IKE vil fungere uten TLS, men da snakker vi ikke brukerpålogging, og skulle det være en “løsning”, vil brukerne måtte logge på et annet sted, og da kanskje med Always-On VPN. Bite seg selv i halen….
Uansett løsning og teknologi vil man ha sårbarheter, det vil komme nye sårbarheter inkludert nulldagssårbarheter. Det er forskjell på teknologier og løsninger, så man skal ikke neglisjere valg, som at Windows Always-On VPN var anbefalt av NCSC, men så fjernet de det (bra). Det er stor forskjell på administrasjon av løsninger, og er det vanskelig å administrere, blir det gjerne vanskeligere å gjøre det bra og sikkert. (Jeg leste litt om konfigurasjon av Windows Always-On, å fysja…. )
Så hva kan man gjøre?
Proaktiv og preventiv sikkerhet.
Å bytte teknologi med teknologi er ikke å endre status quo i nevneverdig grad. Vi må atter igjen starte med menneskene, vår kompetanse rundt trusselbilde OG teknologi, bevissthet og tiltak. Vi MÅ anta at teknologien vi har er sårbar, har sårbarheter og vil få nye sårbarheter.
Spørsmålet er hva man gjør med nettopp det? Om mennesker begynner å anta nettopp slike sårbarheter, og deretter bygger bedre forsvarsevner inne i datasystemene, med utvidet grad av segmentering, bedre patcherutiner på «innsiden» (som ofte får lavere oppmerksomhet fordi det ikke er direkte tilgjengelig fra internett), utvidet bruk av MFA internt, logging, overvåking, og mer, så vil man bygge et forsvar som er mye mer robust NÅR en sårbarhet i SSL, TLS, IPsec, IKE, eller annet blir misbrukt og uvedkommende faktisk kommer seg på innsiden, i brannmuren, på portalen, på webserveren, mailserveren, eller annet.
Bare VG testen alene vil avdekke et viktig sårbart element, ved at utgående kommunikasjon fra angrepet teknologi er mulig, som var viktig i angrepet på IKE sårbare Zyxel brannmurer i Danmark, dette var også nødvendig for å utnytte siste sårbarhet i Palo Alto Networks GlobalProtect VPN løsningen, og vel egentlig i de aller fleste suksessfulle angrep der ute. Adressér denne sårbarheten så raskt som mulig, og fjernaksess, systemer og løsninger vil umiddelbart være mye mindre sårbare, selv med en nulldagssårbarhet.
Assume Breach –> Least Privilege
Om mennesker snur på tankesettet fra å tenke sikkerhet fra utsiden og inn, til å fokusere på verdiene og bygge sikkerhet nærmere disse, vil man begynne å tenke sikkerhet fra innsiden og ut, og da endrer alt seg. Dette handler om mennesker MYE mer enn teknologi.
Litt som å øke passord fra 8 til 16 tegn
Er det å fokusere på bytte av teknologi litt som å øke passord lengde og kompleksitet, istedenfor å fokusere på Multi Faktor Autentisering? Det blir litt bedre, men man løser liksom ikke det egentlige problemet NÅR passord er på avveie.
Til NCSC
Fortsett det gode arbeidet. Det er viktig å kjenne til teknologiene og mulighetene der ute, for det er mye bra hyllevare som markedet allerede bruker og som ofte er integrert i løsninger. Microsoft er liksom “legitimt” å anbefale, fordi “alle” bruker det, men ofte er det ikke gode tekniske løsninger, selv om de har IKEv2, og da er det skummelt om myndighetene anbefaler det slik at ledelse pusher på bruk av dette. Det er nok en grunn til at veldig få benytter nettopp denne teknologien, selv om den er “enkelt” tilgjengelig.
Kom veldig gjerne med anbefalinger for gode installasjoner som burde etterleves (dere har skrevet litt om det i artikkelen), med god tilgangskontroll (kanskje også anbefale FIDO2 ettersom vi her snakker om virksomheter som er underlagt sikkerhetsloven), skape god synlighet, logging, overvåking, validering av enhet ved tilgang, anerkjent endepunktsikkerhet (kanskje opp mot MITRE ATT&CK FRAMEWORK), Just in Time policy, Least Privilege policy, og mer.
Konklusjon
Fjernaksess er nødvendig og viktig, spesielt for rask tilgang, som er en del av sikkerheten. Valg av teknologi og løsning skal og kan ikke være tilfeldig, og det er store forskjeller. Start med risikovurdering, identifiser sårbarheter og adressér disse med gode tiltak, så vil til og med en SSLVPN løsning kunne bli ganske sikker, og en IPsec løsning kan bli ganske usikker uten godt arkitekt arbeid. Hva er en IPsec løsning verdt uten MFA, med svak segmentering på innsiden og en liberal policy? Uten god sikkerhet trenger man ikke engang en software sårbarhet for å være alvorlig sårbar, uansett teknologi.
Ikke la teknologien bli en sovepute, brett opp ermene og gjør et godt sikkerhet og design arbeid, så kan dere sove bedre om natta.

Leave a Reply