Cisco har nettopp annonsert sin nyeste sikkerhetsløsning: Cisco Hypershield! Det har vært mange spørsmål i den forbindelse, og det kan jeg faktisk forstå. Det er ikke snakk om en lekker ny boks i standard 19″ 2U-format som vi skrur opp i rackskapet vårt. Det er en uvanlig størrelse vi her har med å gjøre – bestående av flere relativt nye teknologier og en ny måte å tenke på. Så i stedet for å prøve å koke det ned til et enkelt ord, la meg starte med begynnelsen…
Det var en gang
Det var en gang da brannmurer var en fysisk boks med to – maksimalt tre – grensesnitt. De snille menneskene var koblet internt, de onde hackerne på utsiden – og så kanskje en MailGateway eller webserver på en DMZ.
De passet veldig godt inn i datidens IT-arkitektur, der maskinene og dataene våre var på innsiden – det var det vi måtte beskytte med brannmuren vår.
Etter hvert som ting utviklet seg fant vi ut at det ikke bare fantes onde mennesker på utsiden, det var også kunder der ute som vi ville ha med inn i butikken. WebShops og selvbetjening på nett ga stor rasjonaliseringsgevinst.
Dette gjorde imidlertid også at brannmuren ble skjøvet litt lenger inn i selskapet, slik at de interne systemene kunne segmenteres etter behov. Systemer med kundetilgang, forretningspartnere og ulike interne enheter, som klienter og servere, ble separert på egne brannmurgrensesnitt slik at trafikken mellom dem kunne kontrolleres.
Det var også en tid da en applikasjon vanligvis kjørte på en og samme maskin. Ja, kanskje flere applikasjoner kjørte på samme maskin. Fil- og utskriftsserver, AD og DNS har tidligere vært sett på samme server. Det var heller ikke unaturlig å se en SMTP-server (post mellom selskaper) og en IMAP-server (klienttilgang til mail) på samme fysiske maskin.
Brannmuren satt i midten av det hele og du kunne ved hjelp av IP-adresser og portnumre styre tilgangen til disse applikasjonene.
Det er ikke sånn lenger
Med bruken av sky og containere kom mikrotjenester. Dette betyr at alle funksjonene og tjenestene som tidligere var i applikasjoner som tidligere nevnte e-postserver, nå vises som mikrotjenester. SMTP-tjenesten og IMAP-tjenesten din kjører i separate containere, og de er ikke nødvendigvis på samme maskin. De kan være spredt over flere servere, til og med ulike datasentre i ulike deler av verden.
Men det verste er at det med stor sannsynlighet er flere containere som kjører samme tjeneste av hensyn til skalering og redundans – noe som gjør at du aldri vet hvor funksjonene befinner seg. De beveger seg rundt – dynamisk… Jeg tror ikke lenger noen vil heve et øyenbryn hvis jeg forteller dem at jeg – akkurat nå – sender og mottar e-postene mine i Frankfurt, men leser dem fra en IP-adresse som tilhører et datasenter i Irland .
Men hvor etterlater det vår gode gamle brannmur? Hvor plasserer du brannmuren din slik at trafikken kan kontrolleres, og hvordan konfigurerer du den når du ikke vet hvor applikasjonene og funksjonene dine befinner seg?
Et paradigmeskifte
Vi står overfor et paradigmeskifte, og jeg tror at vi etter hvert må innse at til tross for clusterteknologi og NG-funksjoner, klarer ikke vår gode gamle trofaste brannmur helt å følge med lenger. Cisco har klokt sett i retning sky- og containerverdenen, og de har anskaffet seg ny teknologi som de har satt sammen på en ny og frisk måte.
Det er i hovedsak 3 teknologier som vi skal få vite litt mer om i fremtiden. La oss starte med en rask titt på: eBPF.
eBPF
extended Berkeley Packet Filter er en teknologi der du dynamisk kan injisere funksjoner i en OS-kjerne uten å måtte kompilere den på nytt. Det er ikke et program som kjører på toppen av kjernen slik vi kjenner den, men i kjernen som en del av den. Dette betyr at du med et veldig lite fotavtrykk kan kjøre funksjonene dine og få direkte tilgang til alle systemanrop samt kjernens ressurser og informasjon. Du får dermed tilgang til informasjon om aktive prosesser og biblioteker på maskiner. Du kan se og kontrollere tilgangen til CPU, RAM, disk og – vel, alle nettverkspakker både inn og ut av maskinen – men også til og fra den enkelte prosessen og dermed applikasjonen.
eBPF har mange små triks i ermet. Blant annet er det mulighet for at du kan lage dine egne «tags» som du også kan bruke, og dermed slipper du å bekymre deg for IP-adresser og portnumre i det hele tatt. I tillegg kan du ikke bare tillate eller blokkere trafikk, du kan også omdirigere – for eksempel til en proxy – hvis det er ønskelig.
eBPF kommer fra Open Source-verdenen og har blitt brukt i årevis for å støtte skyleverandørenes forretningsmodell. Selv om vi «i gamle dager» la flere applikasjoner og tjenester på samme maskin, har nok CPU-en vært inaktiv i over 80 prosent av tiden og disken har bare vært halvfull. Og det er nettopp denne «sløsingen med ressurser» som ligger til grunn for skyleverandørenes forretningsmodell. Husk at de ikke selger CPUer, men CPU-sykluser. Ikke disker, men diskplass.
For at denne modellen skal holde vann har det naturlig nok vært nødvendig å kunne kontrollere prosesser og ressurser. Det ville ikke vært så bra hvis en kundes prosess kunne drepe en annen kundes, eller hvis du kunne lese eller skrive til en annen kundes minne eller disk.
eBPF er svaret på dette problemet – og det kan også gi oss svar på en rekke spørsmål om systemanrop, aktive prosesser, biblioteker og ressurser. Vi kan også benytte oss av all denne informasjonen og alternativene.
Husker du Log4J i desember 2021? Her ble det avdekket en sårbarhet i et mye brukt bibliotek. Vi var mange som brukte juleferien på å løpe rundt fra maskin til maskin for å finne ut om de var sårbare. Vi hadde rett og slett ikke oversikten. Med eBPF er du godt stilt. Nå har vi denne informasjonen, og vi kan kanskje også gjøre avbøtende kontroller som forhindrer katastrofen. I denne sammenheng er julehøytiden sikret i fremtiden.
Se for deg tusenvis av små baby-brannmurer som snakker sammen i ett stort eBPF-domene. Alle dine workloads, og i fremtiden også dine nettverksenheter, vil delta i ett og samme domene. Vi får nå innsikt i kjernen og muligheten til å lage brannmur basert på IP-adresser og portnumre, men også prosesser, biblioteker og ressursbruk og belastning.
Vi kan i vårt nye regelverk definere at en prosess på en workload i en del av verden må snakke med en prosess på en workload i den andre delen av verden – ja, faktisk vil det ikke være noen grunn i det hele tatt å sende IP-pakkene ut gjennom nettverket hvis mottakerprosessen ikke kjører i det hele tatt! «Vel, det er bare på workloadene våre, hva med nettverksenhetene?» – spør du sikkert – og takk for det!
Strategisk samarbeid
Cisco har et strategisk samarbeid med Nvidia. Du kjenner dem sikkert som produsenter av høyytelses grafikkort til din gamer-PC og deres GPUer (grafikkbehandlingsenhet) som er i en egen klasse. Samme firma leverer også DPUer (Data Processing Unit – SmartNIC) med samme høye ytelse og er nettverkskortets svar på GPUer. Det er allerede DPUer i flere av Ciscos enheter, men fremover vil det nok være mer regel enn unntak.
I tillegg til å være utrolig raske, har de en liten funksjon som inntar en betydelig plass i Ciscos annonsering: Dual-Path-teknologi. Her er en som har satt seg ned og tenkt nøye!
Teknologien innebærer i utgangspunktet at all data sendes til to (2) dataplan. Den ene er i produksjon og den andre dropper bare pakkene. MEN vi måler hele tiden hva resultatet ville blitt for pakkene i vår «testbane». Vi kan dermed prøve ut nye regler, lappe og til og med oppgradere brannmuren vår – «on the fly». Hvis alt ser bra ut, så bytter vi bare over til det andre dataplanet og kaller det: produksjon.
Innebygd testmiljø – hva er det du ikke liker? Jeg vet ikke hvor mange ganger jeg har sittet i en mørk kjeller og bare håpet at alle applikasjoner fungerer etter brannmuroppgraderingen min. Å ja, nevnte jeg at disse DPUene er bygget for å ta del i ditt nye eBPF-domene – voila – brannmur hvor som helst!
Kunstig intelligens
Ja, jeg vet at flere lesere nå himler med øynene og gjør et grep for å lukke nettleseren, men vent litt…
Ja, ChatGPT kan ta feil, og jeg vet at du må respektere denne nye teknologirevolusjonen, men for å være ærlig er jeg ikke på langt nær så redd for AI som jeg er for RHS (Real Human Stupidity). Dessuten er AI allerede en del av hverdagen vår – enten du liker det eller ikke!
Jeg tror at hvis du som leser har nådd dette punktet, så er sjansen for at du er eier av en smarttelefon godt over gjennomsnittet. Hvis det er tilfelle, så tenker jeg også at det kan være en stund siden det fysiske utbrettbare Europakartet i bilen er oppdatert – og kanskje leseren aldri har prøvd å sitte ved spisebordet med disse kartene da årets selvkjørende ferie måtte planlegges. Ikke bra. Her er mange av oss som legger alle eggene i AI-kurven: CarPlay – Maps – Toscana – Kjør!
Når alle passasjerenes oppmerksomhet er rettet mot neste is-stopp, neste toalett på ruten eller det faktum at du snorker før bilen i det hele tatt har forlatt innkjørselen – tar jeg imot all hjelp jeg kan få fra teknologien.
AI kan virkelig gjøre noe her – med mange målepunkter i form av de andre førerne, deres hastighet, veiforløpet, kombinert med ekstern «intelligens» som informasjon om ulykker, veiarbeid og kanskje til og med værforhold. I tillegg kommer historisk «big data» og avanserte algoritmer – ja, da blir vi guidet rundt køer og ulykker og vi kommer faktisk fram til Italia hvert eneste år.
Selv om jeg hadde tilgang til alle disse dataene – ville jeg aldri vært i stand til å behandle alt manuelt – og absolutt ikke i sanntid. Jeg er en stor fan!
I gamle dager satt vi også og samlet informasjon om applikasjoner, portnumre, trusler og sårbarheter og formet sikkerhetsoppsettet og brannmurregler etter informasjonen vi kunne se. Det var bare en langsom, manuell prosess. Nå har vi mye mer informasjon tilgjengelig – takket være eBPF, workloads, big data og intelligens. Ja, faktisk har vi så mye informasjon at det vil være umulig for en brannmuradministrator å få oversikt og håndtere alle disse dataene. Derfor ber vi om hjelp fra AI… og som en klok mann sa: «AI er et uttrykk for noe du ennå ikke stoler helt på – etterpå kaller vi det automatisering».
I fremtiden vil vi bruke AI til å definere regelsettene våre. Vi må kanskje godkjenne dem først, men med all informasjonen vi har tilgjengelig, kan de gjøres mye mer detaljerte og dynamiske.
Tenk deg at du har en prosess på en maskin som en gang i måneden vil kommunisere med en prosess på en annen maskin. Det kan være vår lønnskjøring. Begge maskinene er en del av sikkerhetsdomenet ditt og når det gjelder eBPF vet vi at de to prosessene kjører. Vi vet også når kommunikasjonen skal skje og hvilke data det dreier seg om m.m. Systemet vil derfor kunne lage en brannmurregel på både maskiner og på alle nettverksenheter underveis, som beskriver at denne kommunikasjonen, med de respektive dataene, er tillatt. Man kunne kanskje til og med tenke seg at regelen blir tidsbestemt, slik at den kun trer i kraft én gang i måneden – og med de IP-adressene som er gyldige til det gitte tidspunktet. Alle andre maskiner, prosesser, IP-adresser, data o.s.v. vil aldri oppfylle disse kriteriene og kommunikasjonen vil derfor ikke være tillatt. Man kan hevde at hvis én prosess ikke kjører, så er det ingen grunn til å åpne alle brannmurene våre.
Jeg vet at dette er et forenklet eksempel og du har all rett til å stille spørsmål ved saken, men faktum er at vi har mye informasjon og telemetri som vi kan bruke for å, på en intelligent måte, bygge regler som passer situasjonen.
eBPF, DPUer i nettverksutstyr og AI
Vel, det er tre ting: eBPF, DPUer i nettverksutstyr og AI. Dette er IT-arkitekturens svar på «kinderegget» og det er disse tre byggeklossene som trengs for å løse fremtidens (dagens) brannmuroppgave og mer:
Segmentering
Oppgaven som brannmuren ble opprettet for å løse. Vi snakker ikke «bare» stateful brannmur, men også med NG-funksjoner og rett inn i kjernen av våre workloads. Regler kan også baseres på elementer som prosesser, biblioteker og ressursforbruk. Dette gjør at vi kan «brannmure» mange flere steder, og det passer mye bedre til den nye verdenen, som også er mye mer distribuert. Videre gir det håp om at vi faktisk kan nå målet vårt med vår mikrosegmentering i vårt eget datasenter.
Administrasjon og vedlikehold
Ved hjelp av AI og Dual-DataPath kan vi faktisk oppgradere både funksjoner, patcher og regler mens vi er i drift. Vi slipper å vente på «servicevinduer» og sitte med livet i hendene og håpe at applikasjonene virker etterpå – DET ER TESTET!
Sårbarhetshåndtering
Med sanntidsintelligens og innsikt i workloadenes konfigurasjon, er effektiv sårbarhetsstyring mulig – time to mitigate er betydelig redusert.
Til slutt – generering og vedlikehold av regler
«Up-to-date-regler» som er testet og klare for godkjenning – og når vi har bygget opp tillit til systemet – kaller vi det automatisering.
OK – 2 av den takk!
Hold an litt. Cisco har forpliktet seg til en reise som vil ta oss til et bedre sted. De har nylig kjøpt opp noen teknologibedrifter som må være med på å legge skinnene foran det fremadstormende toget:
Isovalent
Isovalent er skyens og ikke minst kubernetes sitt svar på Cisco, slik vi kjenner dem fra «den gamle nettverksverdenen», og de har kun 4 taster på tastaturet: e-B-P-F. De er derfor ikke fremmede for kubernetes-brukere, hvor de har en absolutt dominerende posisjon. Men strategien går utover det. DPU-ene er bare det første steget. I morgen: hvilken som helst sky-VM, serverløs funksjon, DB o.s.v.! På denne måten kan du også få disse funksjonene inn i ditt eget eBPF-domene med dine egne regler.
Splunk
Mange av oss kjenner Splunk fra SIEM-verdenen, men jeg lurer på om ryktene er sanne og at de kommer med noe avansert AI. Husk at selskapet ble bygget på ML (Machine Learning) og AI helt fra begynnelsen.
Et betydelig samarbeid med Nvidia samt en hel rekke andre oppkjøp og samarbeidsavtaler setter Cisco i en posisjon til å påta seg oppgaven. Det blir en reise – og første stopp kommer nok før heller enn senere. Det går rykter om en eBPF Agent på markedet allerede i sommer, og da vil toget fortsette til neste plattform. Så du bør ikke forvente et fullt operativt system i inneværende interrail-sesong. Og du må fortsette å ta vare på systemene dine, oppdatere brannmurene dine, interessere deg for trusler og sårbarheter – alt som vanlig. Du bør heller ikke vente på nye investeringer på sikkerhetsområdet, det er rett og slett for farlig. Cisco ønsker tross alt ikke å konkurrere med seg selv, og vi kan regne med en smidig overgang – både teknisk og kommersielt.
Men du må begynne å bli vant til ideen. Lær om AI – bruk den og følg utviklingen. Les deg opp på eBPF og se mulighetene. Spør leverandørene dine om temaet og tenk på om din organisasjon og dine prosesser kan omfavne den nye teknologien. Toget kommer – ingen tvil om det. Spørsmålet er bare når du går ombord…
