Cisco har netop annonceret deres seneste sikkerhedstiltag: Cisco Hypershield!
Der har været mange spørgsmål i den forbindelse, og det kan jeg faktisk godt forstå. Der er da heller ikke tale om en ny fin kasse i et vanligt 19” 2U format som vi skruer op i vores rackskab. Det er en uvant størrelse, vi står med her – bestående af flere, forholdsvis, nye teknologier og en ny måde, at tænke problemet på. Så i stedet for at prøve at stoppe det ned i et enkelt ord, så lad mig starte ved begyndelsen…
På Conscia Sikkerhedsfestival i juni 2024, havde vi Craig Connors, VP & CTO Security hos Cisco, på keynote-scenen, for at præsentere Ciscos nyeste skud på stammen; Hypershield. Se interviewet med fra dagen her
Der var engang hvor firewalls var en fysisk kasse med to – max tre – interfaces. De gode og rare mennesker var tilkoblet det interne, de onde, modbydelige hackere på ydersiden – og så måske en MailGateway eller Webserver på et DMZ.
De passede rigtig godt ind i datidens IT-arkitektur, hvor vores maskiner og data befandt sig på indersiden – det var jo det, vi skulle beskytte med vores firewall.
Efterhånden som tingene udviklede sig fandt vi ud af, at der ikke kun var onde mennesker på ydersiden. Derude var også kunder, som vi ønskede at få ind i butikken. Marketing, WebShops og Selfservice flyttede på nettet med en stor rationaliseringsgevinst til følge.
Det betød dog også at firewall’en blev skubbet lidt længere ind i virksomheden, så man kunne segmentere de interne systemer efter behov. Systemer med kundeadgang, samarbejdspartnere og forskellige interne enheder, som klienter og servere, blev adskilt på hver sit firewall-interface, så man kunne kontrollere trafikken mellem disse.
Det var også en tid, hvor en applikation typisk kørte på én og samme maskine. Ja, måske kørte der flere applikationer på samme maskine. Fil- og print-server, AD og DNS er før set på samme server. Det var heller ikke unaturligt at se en SMTP-server (mail mellem virksomheder) og en IMAP-server (klienters adgang til mails) på samme fysiske maskine.
Firewall’en sad i midten af det hele og man kunne, ved hjælp af ip-adresser og port-numre, kontrollere adgangen til disse applikationer.
Sådan er det ikke mere. Med tilkomsten af cloud og containers kom micro-services. Det betyder, at alle de funktioner og services, der før har ligget i applikationer som f.eks føromtalte mail-server, nu optræder som micro-services. Din SMTP-service og IMAP-service kører i hver sin container, og de ligger ikke nødvendigvis på samme maskine. De kan ligge spredt ud over flere servere, ja, endog forskellige datacentre i forskellige verdensdele.
Men det værste er, at der, med stor sandsynlighed, er flere containere, der kører samme service af hensyn til scalering og redundans – hvilket betyder, at man aldrig ved hvor, funktionerne befinder sig. Skidtet flytter rundt – dynamisk… Jeg tror ikke længere, der er nogen, der vil løfte på øjenbrynet, hvis jeg fortæller, at jeg – lige nu – sender og modtager mine mails i Frankfurt, men læser dem fra en ip-adresse tilhørende et datacenter i Irland.
Men hvor stiller det vores gode gamle firewall? Hvor sætter man sin firewall, så trafikken kan kontrolleres, og hvordan konfigurerer man den, når man ikke ved hvor, ens applikationer og funktioner befinder sig?
Vi står over for et paradigmeskifte og jeg tror, at vi efterhånden må indse, at på trods af cluster-teknologi og NG-features, så kan vores gode gamle trofaste brandmur ikke helt følge med mere.
Cisco har klogt kigget i retning af cloud- og container-verden, og man har anskaffet sig noget ny teknologi som man har sat sammen på en ny og frisk måde.
Der er i hovedtræk 3 teknologier som vi kommer til at sætte os lidt mere ind i i fremtiden. Lad os starte med et hurtigt kig på: eBPF.
extended Berkeley Packet Filter er en teknologi, hvor man kan dynamisk inject’e funktioner i en OS-kerne uden at skulle recompilere den. Det er ikke et program, der kører oven på kernen, som vi kender det, men I kernen som en del af denne. Det betyder, at man med meget lille foot print kan afvikle sine funktioner og få direkte adgang til alle systemkald samt kernens ressourcer og informationer. Du får således adgang til information om aktive processer og libraries på maskiner. Du kan se og kontrollere adgange til CPU, RAM, disk og – nåh ja – alle netværkspakker både ind og ud af maskinen – men også til og fra den enkelte proces og dermed applikation.
eBPF har en masse små tricks i ærmet. Bl.a. er der mulighed for, at man kan oprette sine egne ”tags”, som man også kan bruge, og dermed behøver man slet ikke at bekymre sig om ip-adresser og portnumre. Derudover kan man ikke kun tillade eller blokere trafik, man kan også redirecte – f.eks til en proxy – skulle det være ønskeligt.
eBPF kommer fra Open Source-verden og er i årevis brugt til at understøtte cloud-providernes forretningsmodel. Selv om vi, ”i gamle dage”, lagde flere applikationer og services på samme maskine, så har CPU’en formodentligt stået stille i over 80 procent af tiden og disken har kun været halvt fuld. Og det er netop dette ”ressourcespild”, der ligger til grund for cloud-providernes forretningsmodel. Husk på, at de ikke sælger CPU’er, men CPU-cycles. Ikke diske, men diskplads.
For at denne model holder vand, har der naturligvis været brug for at kunne kontrollere processer og ressourcer. Det ville jo ikke være så godt, hvis én kundes proces kunne slå en anden kundes ihjel, eller hvis man kunne læse eller skrive til en anden kundes memory eller disk.
eBPF er svaret på denne problemstilling – og samme kan også give os svar på en række spørgsmål om systemkald, aktive processer, libraries og ressourcer.
Alle disse informationer og muligheder kan vi også benytte os af. Dels kan vi kontrollere hvad det enkelte work load må, men tænk på hvad vi kan bruge alle informationerne til.
Husker du Log4J i december 2021? Her viste der sig en sårbarhed i et meget udbredt library. Der var mange af os, der brugte vores juleferie på at løbe rundt fra maskine til maskine for at finde ud af, om de var sårbare. Vi havde simpelthen ikke overblikket. Med eBPF er du anderledes godt stillet. Nu har vi disse informationer, og vi kan måske ovenikøbet lave mitigerende kontroller, der hindrer katastrofen. I den sammenhæng er juleferien sikret i fremtiden.
Forestil dig tusindvis af små baby-firewalls som snakker sammen i ét stort eBPF-domain. Alle dine workloads, og fremadrettet også dine netværksenheder, vil deltage i ét og samme domain. Vi får nu, qua vores indsigt i kernen, mulighed for at lave firewalling baseret på, ikke bare ip-adresser og port-numre, men også processer, libraries samt ressourcebrug og -belastning.
Vi kan, i vores nye regelsæt, definere at en proces på et work load i den ene del af verden må tale med en proces på et work load i den anden del af verden – ja, faktisk vil der slet ikke være nogen grund til at sende ip-pakkerne ud gennem netværket, hvis modtager-processen slet ikke er kørende!
”Jamen det er jo kun på vores workloads, hvad med netværksenhederne?” – spørger du nok – og tak for det!
Cisco har et strategisk samarbejde med Nvidia. Dem kender du nok som producenter af high-performance grafikkort til din gamer-pc og deres GPU’er (graphics processing unit) der er i særklasse. Samme firma leverer også DPU’er (Data Processing Unit – SmartNIC) med samme høje performance og er netværkskortets svar på GPU’er. Der sidder allerede DPU’er i flere af Ciscos enheder, men fremadrettet vil det nok være mere reglen end undtagelsen.
Ud over at være utrolig hurtige – så har de en lille feature, som indtager en væsentlig plads i Ciscos annoncering: Dual-Path-technology. Her er der nogen, der har sat sig ned og tænkt sig om!
Teknologien går i store træk ud på, at alle data sendes til to (2) data planes. Det ene er i produktionen og det andet dropper bare pakkerne. MEN vi måler hele tiden på, hvad der ville ha’ været resultatet for pakkerne i vores ”test-path”. Vi kan dermed prøve nye regler af, patche, ja endda opgradere vores firewall – ”on the fly”. Hvis alt ser godt ud, så skifter vi bare over på det andet data plane og kalder det: produktion.
Indbygget testmiljø – what’s not to like? Jeg ved ikke hvor mange gange, jeg har siddet i en mørk kælder og bare håbet på, at alle applikationer virker efter min firewall-opgradering.
Nåh ja, fik jeg sagt, at de her DPU’ere er bygget til at tage del i dit nye eBPF-domain – vupti vupti – firewall anywhere!
Artificial Intelligence – ja, jeg ved godt, at flere læsere nu himler med øjnene og gør antræk til at lukke browseren, men vent lige et øjeblik…
Ja, ChatGPT kan tage fejl, og jeg ved godt, at man skal have respekt for denne nye teknologirevolution, men sandt at sige, så er jeg ikke nær så bange for AI som jeg er for RHS (Real Human Stupidity). Desuden så er AI allerede en del af vores hverdag – like it or not!
Jeg tænker, at hvis man som læser er nået hertil, så er chancerne for at man er indehaver af en smartphone pænt over middel. Hvis det er tilfældet, så tænker jeg også, at det måske er lidt siden, at det fysiske fold-ud Europakort i bilen er blevet opdateret – og måske har læseren aldrig prøvet at sidde ved spisebordet med disse landkort, når årets kør-selv-ferie skulle planlægges. Nej vel. Her er vi mange, der lægger alle æggene i AI-kurven: CarPlay – Maps – Toscana – Kør!
Når alle pasageres opmærksomhed er rettet imod en is der er lovet, det næste toilet på strækningen eller, at man snorksover inden bilen overhovedet har forladt indkørslen – så tager jeg imod alt den hjælp jeg kan få fra teknologien.
Her kan AI virkelig noget – med mange målepunkter i form af de andre bilister, deres hastighed, vejens forløb kombineret med ekstern ”intelligence” som informationer om ulykker, vejarbejde og måske endda vejrforhold. Hertil historiske ”big-data” og avancerede algoritmer – ja, så bliver vi ledt uden om kø og uheld og vi når faktisk til Italien hvert år.
Selv om jeg havde adgang til alle disse data – så ville jeg aldrig kunne behandle dem alle manuelt – og slet ikke i real-time. Jeg er kæmpe fan!
I gamle dage sad vi også og indsamlede informationer om applikationer, portnumre, trusler og sårbarheder og formede vores sikkerheds-setup og firewall-regler efter de informationer, vi kunne overskue. Det var bare en langsommelig, manuel proces.
Nu har vi så en masse mere information til rådighed – qua eBPF, work loads, big data og intelligence. Ja, faktisk har vi så meget information, at det vil være umuligt for en firewall-administrator at overskue- og forholde sig til alle disse data. Derfor beder vi om hjælp ved AI… og som en klog mand sagde: ”AI er et udtryk for noget man endnu ikke har helt tillid til – derefter bliver det bare automatisering”.
Vi vil i fremtiden bruge AI til at definere vores regelsæt. Det kan godt være, at vi skal godkende dem i starten, men med alt den information vi har til rådighed, kan de gøres langt mere granulerede og dynamiske.
Forestil dig, at du har en proces på en maskine, der én gang om måneden vil kommunikere med en proces på en anden maskine. Det kunne være vores lønkørsel. Begge maskiner er en del af dit security-domain og qua eBPF ved vi, at de to processer er kørende. Vi ved også, hvornår kommunikationen skal foregå og hvilke data, der er tale om mm. Systemet vil derfor kunne lave en firewall-regel på begge maskiner samt på alle netværksenheder undervejs, der beskriver, at denne kommunikation, med de respektive data, er tilladt. Man kunne måske endog forestille sig, at reglen vil være tidsbestemt, så det kun er én gang om måneden, den træder i kraft – og med de IP-adresser, der er gældende på det givne tidspunkt. Alle andre maskiner, processer, IP-adresser, data osv. vil aldrig opfylde disse kriterier, og kommunikationen vil derfor ikke være tilladt. Man kunne argumentere for, at hvis den ene proces ikke er kørende, så er der ingen grund til at åbne alle vores firewalls.
Jeg ved godt, at dette er et simplificeret eksempel, og du er i din gode ret til at sætte spørgsmålstegn ved casen, men sagen er, at vi har rigtig mange informationer og telemetri, som vi kan udnytte til, på en intelligent måde, at bygge regler, som passer til situationen.
eBPF, DPU’er i netværksudstyr og AI
Jamen, det er jo hele tre ting: eBPF, DPU’er i netværksudstyr og AI.
Dette er IT-arkitekturens svar på ”kinderægget” og det er disse tre byggesten, der skal til for at løse fremtidens (nutidens) firewall-opgave … og mere til:
Segmentering
Opgaven som firewallen er skabt til at løse. Vi snakker ikke ”bare” statefull firewall, men også med NG features og helt ind i kernen på vores workloads. Regler kan ligeledes være baseret på elementer som processer, libraries og ressourceforbrug. Dét og den distribuerede arkitektur betyder dels, at vi kan ”firewalle” mange flere steder, og det passer langt bedre til den nye verden, som også er langt mere distribueret. Desuden giver det håb om, at vi faktisk kan komme i mål med vores micro-segmentering i vores eget datacenter.
Administration og vedligeholdelse
Med hjælp fra AI og Dual-DataPath kan vi faktisk opgradere både funktioner, patches og regler, mens vi er i drift. Vi skal ikke vente på ”servicevinduer” og sidde med livet i hænderne og håbe på, at applikationerne virker bagefter – DET ER TESTET!
Sårbarhedshåndtering
Med realtime intelligence og indsigt i workloads konfiguration er det muligt med effektiv sårbarshåndtering – time to mitigate er væsentligt reduceret.
Endelig – generering og vedligeholdelse af regler:
”Up-to-date-regler” der er testet og klar til godkendelse – og når vi har oparbejdet tillid til systemet – så kalder vi det for automatisering.
OK – 2 af dem tak!
Hold your horses. Cisco har commitet sig til en rejse, der skal tage os til et bedre sted. Man har opkøbt teknologi-virksomheder, der skal lægge sporene ud foran det fremad-buldrene tog.
Isovalent
Isovalent er skyens- og ikke mindst kubernetes’ svar på Cisco, som vi kender dem fra den ”gamle netværks-verden”, og de har kun 4 taster på tastaturet: e-B-P-F. De er derfor ikke fremmede for kubernetes brugere, hvor de har en absolut dominerende position. Men strategien rækker ud over det. DPU’erne er kun første skridt – i morgen: enhver cloud VM, serverless function, DB etc.! Dermed kan du også få disse funktioner ind i dit eget eBPF domain … med dine egne regler.
Splunk
Splunk er vi mange, der kender fra SIEM-verden, men mon ikke rygterne taler sandt, og at de kommer med noget avanceret AI. Husk på, at firmaet er bygget på ML (Machine Learning) og AI helt fra starten.
Et betydende samarbejde med Nvidia samt en hel række andre opkøb og samarbejdsaftaler sætter netop Cisco i stand til at løfte opgaven.
Det vil være en rejse – og første stop kommer nok før end siden. Der rygtes en eBPF-Agent på markedet allerede her til sommer, og derefter kører toget så igen frem mod næste perron.
Du skal altså ikke forvente et færdigkørende system i indeværende interrail-sæson. Og du skal forsat passe på dine systemer, opdatere dine firewalls, interessere dig for trusler og sårbarheder – alt sammen som du plejer. Du skal heller ikke vente med nye investeringer på sikkerhedsområdet, det er simpelthen for farligt. I øvrigt vil Cisco jo ikke konkurrere med sig selv, og vi kan regne med, at der sker en glidende overgang – både teknisk og kommercielt.
Men… du skal begynde at vænne dig til tanken. Lær om AI – brug det og følg udviklingen. Læs op på eBPF og se mulighederne. Spørg dine leverandører om emnet, og tænk over om din organisation og din processer kan favne den nye teknologi. Toget kommer – ingen tvivl om det. Spørgsmålet er bare, hvornår du står på…
På Conscia Sikkerhedsfestival i juni 2024, havde vi Craig Connors, VP & CTO Security hos Cisco, på keynote-scenen, for at præsentere Ciscos nyeste skud på stammen; Hypershield. Se interviewet fra dagen her:
