Ontdek de kracht van AI en automation met Cisco Hypershield

Transcript

Welkom, iedereen. Welkom bij dit webinar over HyperShield, het tweede dat we tot nu toe hebben gehad. We volgen de reis van HyperShield. Voordat we beginnen, ben ik Lars Erik Braatveit. Ik ben de leider op het gebied van cyberbeveiliging hier in Noorwegen.

Hypershield

Ik heb het genoegen gehad om hands-on ervaring op te doen met HyperShield terwijl het zich ontwikkelt. We werken dus nauw samen met Cisco, in alle Conscia landen, eigenlijk. We hebben dus wat praktijkervaring opgedaan en zijn erg enthousiast over het product. En op dit moment wacht ik met veel spanning op de nieuwe switch met DPU-ondersteuning, die HyperShield helemaal naar de switch zal verplaatsen. We krijgen een vroege veldproef in Conscia.

Dus misschien gaan we de volgende keer dieper in op hoe we dat op hardware niveau doen. Bij mij zijn Jeroen en Christian, van Cisco, die vooral aan het woord zullen zijn. Dus ik ga een hele snelle intro doen.

Allereerst de huishouding.

Hopelijk kan iedereen me horen. Als je me niet kunt horen, kun je hopelijk met de visuele afbeelding begrijpen waar het over gaat.

Je bent gedempt zoals normaal bij alle webinars. Als je vragen hebt, schrijf ze dan in de vraag en antwoord. Christian zal dat in de gaten houden en ervoor zorgen dat die vragen beantwoord worden. En natuurlijk wordt dit webinar opgenomen. Dus als we klaar zijn met het verwerken van de video, krijg je een link en kun je die delen met je vrienden en familie en iedereen die geïnteresseerd is in HyperShield. Dus, ga uit je dak.

Gewoon een paar woorden. Als het je gelukt is om aan dit webinar deel te nemen en geen klant te zijn, dan is deze slide iets voor jou. Dit is Conscia in één oogopslag.

Toen we voor het laatst het HyperShield-webinar hadden, denk ik dat ik net heb aangekondigd dat we een bedrijf in het VK hadden overgenomen en dat we naar het VK zijn gegaan. En sindsdien zijn we uitgebreid naar Ierland en ook naar België. Conscia is dus een bedrijf dat groeit. We zijn een pan-Europees bedrijf.

We hebben uitstekende mensen in heel Europa, en dat verandert maandelijks.

Zoals u kunt zien, hebben we tevreden klanten. We hebben tevreden werknemers. We werken aan de zeer, zeer missiekritieke infrastructuur van en met onze klanten. We hebben echt grote, coole projecten. Ons bedrijf is erg technisch. Zoals u kunt zien, bestaat meer dan de helft van ons bedrijf uit engineers en analisten. Het is dus een goede plek om te vertoeven, voor iedereen die geïnteresseerd is in technologie.

Een paar woorden over onze technologiestrategie.

Velen van jullie zullen Conscia het meest kennen vanwege onze netwerkexpertise en vooral onze expertise op het gebied van Cisco netwerken.Velen van jullie zullen Conscia het meest kennen vanwege onze netwerkexpertise en vooral onze expertise op het gebied van Cisco netwerken.

Maar onze strategie richt zich ook op het gebied van cyberbeveiliging. En je zou zeggen dat HyperShield waarschijnlijk geassocieerd wordt met cyberbeveiliging, maar ook een beetje met hybride cloud.

Dus we hebben het over beide. En dan hebben we natuurlijk observability. Je zou dus in staat moeten zijn om te observeren wat er aan de hand is en om daarnaar te handelen.

Om dit mogelijk te maken, werken we natuurlijk samen met onze strategische technologiepartners. En op dit moment is onze belangrijkste strategische partner, Cisco, hier, en dit is natuurlijk waar we het over gaan hebben.

Dus daarmee ben ik klaar. Jeroen en Christian, het woord is aan jullie. Dus ik stop met delen, en jullie kunnen het gewoon overnemen.

Ja. Goedemorgen, iedereen.

Bedankt voor je deelname aan dit spannende webinar.

Mijn naam is Christian Heinel. Ik ben de technische leider op het gebied van beveiligingsoplossingen voor Noord-Europa hier bij Cisco.

Samen met mij neemt Jeroen het over een paar seconden over, en we gaan aan de slag. Als je, zoals Lars Erik net zei, als je vragen hebt, gebruik dan het Q&A-panel. Je vindt het aan de rechterkant, onderaan op het paneel en schrijf ze daar op. Sommige daarvan kan ik direct beantwoorden, en andere zullen we in de presentatie opnemen, zodat iedereen het antwoord en het antwoord op die vragen kan begrijpen. Dus heel erg bedankt voor je deelname, en geniet van de show. Over naar jou, Jeroen.

Goedemorgen iedereen. Bedankt dat je me hebt ontvangen. Dus mijn naam is Jeroen. Ik ben een Technical Marketing Engineer (TME), wat betekent dat ik een technische pet en een marketingpet draag. Vandaag draag ik voornamelijk mijn technische hoed.

We zullen een update geven over HyperShield en geven tegen het einde enkele live demo’s.

Dus we zullen zien hoe dat werkt.

Dus daarmee gaan we meteen aan de slag. De agenda voor vandaag is dus dat we de architectuur kort zullen bespreken. We zullen het hebben over de updates die we hebben, voor zover het de verschillende pakketten betreft. We zullen opnieuw een kort overzicht geven van het policymodel dat we gebruiken.

We zullen eBPF positioneren en waar we het gebruiken. We zullen het hebben over AI en de digitale-twin. En op dat moment zal ik daadwerkelijk overschakelen, de gedistribueerde exploit-protection en autonome segmentatie overslaan voor een zeer korte update over de HyperShield API. En dan gaan we naar de live demo waarin ik zal laten zien waar we vandaag staan met betrekking tot autonome segmentatie en gedistribueerde exploit-protection.

Zoals gezegd, stel gerust vragen in de vragen en antwoorden.

We zullen proberen ze live te beantwoorden, wanneer we de kans hebben.

Een van de dingen die nieuw is sinds de vorige keer dat we over HyperShield spraken, is dat Cisco nu de meeste, zo niet alle beveiligingstools onder de paraplu en visie van de zogenaamde hybride mesh-firewall positioneert.

Wat dat specifiek betekent voor HyperShield is dat, in eerste instantie niet zo veel, maar wat in de nabije toekomst in feite best veel zal blijken te betekenen. In welke context? Nou, vanaf de eerste dag was HyperShield een vooraanstaand voorbeeld van beveiliging en cloudbeheer, net als ons platform voor beveiligingscontrole, dat is gebaseerd op de cloud. En het voordeel van het feit dat je een vooraanstaand burger bent, is dat er onder de nieuwe visie van een hybride mesh-firewall nu een stap wordt gezet om steeds meer toe te voegen met als doel bijna alles toe te voegen, van een beveiligingsportfolio dat op dit platform is aangesloten. Dat betekent dat al deze tools, in plaats van individuele hulpmiddelen te zijn, ze zullen met elkaar kunnen communiceren. Ze zullen in staat zijn om configuratie, gegevens, gebeurtenissen en al die dingen uit te wisselen die we kunnen bereiken, een heilige graalvisie van een volledige mesh-integratie via dit enkele gemeenschappelijke platform.

Dus als we dan dieper in HyperShield duiken, zien we enkele updates sinds de laatste keer dat we spraken. De twee belangrijkste doelen zijn natuurlijk nog steeds autonome segmentatie en exploitbescherming, maar we hebben nu ook zone firewalling toegevoegd, wat voornamelijk mogelijk wordt gemaakt door de slimme switch waarover we het zo meteen zullen hebben.

We hebben nog steeds dezelfde doelen wat betreft workload en network-enforcement. We hebben dus een combinatie van enforcers die zich kunnen bevinden in het besturingssysteem waarop uw toepassingen worden uitgevoerd.

Tegenwoordig zijn dat de meeste Linux-distributies die niet ouder zijn dan vijf tot acht jaar. En dan komt ook Windows binnenkort. Microsoft bevindt zich dus in de laatste fase om dat uit te brengen. Dus binnen een paar weken, hooguit een paar maanden, is dat er.

En vanuit het oogpunt van het netwerk hebben we ook de mogelijkheid om daar enkele enforcers in te zetten. Aanvankelijk was er alleen de op VM gebaseerde enforcers. Dus in feite een virtuele machine die u op strategische locaties kunt inzetten om te beginnen met netwerkgebruik en security policy enforcement.

En nu, sinds Amsterdam, hebben we ook onze eerste, smart (slimme) switch aangekondigd, wat in wezen een op DPU gebaseerde switch is waarbij we het beste van twee werelden combineren, zowel van Cisco Silicon voor hoogwaardige pakketverzending als vervolgens DPU’s waar we vervolgens kunnen beginnen met het introduceren van extra mogelijkheden, waarbij HyperShield de eerste van die mogelijkheden is.

Slimme switches

De coole schoonheid van, het wereldwijd beheerde en lokaal geforceerde, wordt nu versterkt met deze slimme switch. Want als je nadenkt over de slimme switches, geven ze ons bijvoorbeeld een hardware platform waar we het segmentatiepolicy kunnen afdwingen. Dat kun je nu laten uitdelen.

Want waar je die slimme switches ook gaat introduceren, je hebt nu op hardware gebaseerde enforcementpoints, wat je natuurlijk het voordeel geeft van, één hardware en twee, begin je een meer gedistribueerde toepassing van de diensten te introduceren. Vandaag richten we ons uiteraard op HyperShield-beveiligingsdiensten.

Maar met dit gedistribueerde karakter, brengt deze hybride aard ook een nieuwe uitdaging met zich mee, namelijk dat als je in eerste instantie overgaat van een gecentraliseerde veiligheidsnormen naar een gedistribueerd handhavingsmodel, je een managementlaag nodig hebt die in staat is om met deze gedistribueerde aard van het model om te gaan, wat voor HyperShield natuurlijk geen probleem is, want zo is HyperShield in de eerste plaats gebouwd, juist, om zoals een enkel globaal controlplane en vervolgens een gedistribueerd dataplane in de vorm van al deze verschillende enforcers.

Een ding om op te merken is dat HyperShield tegenwoordig voornamelijk een op SaaS gebaseerd aanbod is. We hebben verschillende stappen ondernomen om een begin te maken met het onderzoeken van wat het zou betekenen of wat we zouden moeten doen, voor een on-prem-versie. Een officiële tijdlijn is hier niet voor. Daar is nog geen routemap voor. Ik wilde gewoon met je delen dat dit iets is waar we naar zijn gaan kijken. Dus ik denk dat dat op een bepaald moment in de toekomst ook een realiteit zal worden.

Dus dat is ongeveer het grote plaatje. Laten we nu dus gaan inzoomen op enkele van de interessantere aspecten van HyperShield en hoe we dit allemaal kunnen realiseren. Dus om te beginnen, als we naar de enforcers gaan kijken, is het misschien goed om ook wat tijd te besteden aan de onderliggende technologie die we gebruiken, via Isovalent. De vorige keer hadden we het dus al over eBPF.

Veel van de mogelijkheden van HyperShield zijn eigenlijk gebaseerd op Isovalent capaciteiten. Vandaag is dat vooral het Tetragon, onderdeel van het Isovalent, aanbod, maar in de nabije toekomst zullen er nog veel meer zijn.

Kubernetes

En een ding dat ik misschien wil updaten over de slides is dat de overlap op Kubernetes maar een klein beetje lijkt te zijn, maar Kubernetes is eigenlijk ons belangrijkste doel. Dus het feit dat er overlap is, betekent precies dat.

HyperShield is super blij om in Kubernetes-omgevingen te spelen. En eerlijk gezegd is het zelfs de gemakkelijkste en meest gebruiksvriendelijke om in te zetten, omdat we alle typische Kubernetes-constructies van nature gebruiken. Dus de manier om dit te bekijken is dat Tetragon de hoeksteen is van de daadwerkelijke op het besturingssysteem gebaseerde endpoint enforcer van HyperShield.

En dankzij die technologie hebben we eigenlijk een soort abstractielaag om mee om te gaan. eBPF en de mogelijkheden die eBPF ons biedt, zowel vanuit het oogpunt van runtime-beveiliging als vanuit het oogpunt van netwerkbeveiliging, waarbij segmentatie natuurlijk de belangrijkste use-case is. En daar bovenop, met HyperShield, bieden we een hele hoop automatisering, schaalvergroting, enkelvoudig policy beheer, enzovoort.

Als u er om wat voor reden dan ook voor kiest om niet voor HyperShield te kiezen en u zich wilt concentreren op de open source, een pure open source-technologie, de technologie die vandaag ook volledig op prem draait, dan kunt u voorlopig bij Aizawell en Enterprise blijven. En dan kun je er op een gegeven moment altijd voor kiezen om naar HyperShield te gaan.

We proberen die reis zo naadloos mogelijk te laten verlopen, idealiter zonder enige moeite.

Dus als we dan inzoomen op de daadwerkelijke enforcers, dan hebben we natuurlijk de endpoint Enforcer, die draait in het besturingssysteem waar uw workloads zich bevinden. Dat is het fundamentele startpunt voor HyperShield om te beginnen met het verkrijgen van inzichten en informatie over uw omgeving. Je zou ervoor kunnen kiezen om alleen slimme switches in te zetten en dat zou kunnen werken maar dan ben je gedwongen om enkel handmatig de policies door te voeren.

Want als je alleen de slimme switches zou gebruiken, is dat perfect mogelijk, maar Hypershield zou geen bron van informatie hebben om erachter te komen hoe je omgeving eruitziet en als gevolg daarvan te beginnen met het voorstellen van het wapenen tegen exploits en te beginnen met het suggereren van segmentatie. Dus als je ervoor kiest om endpoint agents niet actief te hebben, is dat prima.

Het enige gevolg is dat je dan de policy handmatig moet definiëren. Nu kan het handmatig implementeren van policy een beetje moeilijker klinken dan het in werkelijkheid is, omdat HyperShield volledig API-toegankelijk is. Alles wat u met HyperShield kunt doen, wordt ook via de API weergegeven.

Dus als u al een automatiseringspijplijn of een CICD-pijplijn hebt om uw beveiligingspolicy af te handelen, is het heel eenvoudig om te beginnen met het aansluiten van HyperShield’s, best-enforcers, de slimme switch, de VM, en op een gegeven moment, als u daarvoor kiest, natuurlijk ook deze agenten. De manier waarop deze middelen werken, ze zijn eigenlijk extreem light-weight. De belangrijkste reden waarom we deze agenten hebben, is dat we iets nodig hebben dat de agent in staat stelt te beseffen hoe het zichzelf moet configureren, welke policy op deze agent moet worden toegepast.

Tegelijkertijd hebben we ook een manier nodig om de lokale informatie te delen met de HyperShield-controller. En dat doen we via de graph-construct.

En tot slot, en dit is heel belangrijk om te beseffen op de endpoints, dat de daadwerkelijke enforcement van de policy, ook wel de dataplane, rechtstreeks in de kernel gebeurt vanwege eBPF. De agent draait vandaag dus slechts om de vijftien minuten om te draaien, een nieuwe versie van zijn local-graph te maken, zoals een nieuwe momentopname van de omgeving, de local-graph, te delen met de controller en vervolgens ook vanaf de controller te controleren of er een aanvullende policy moet worden geïmplementeerd.

En als die klus eenmaal is geklaard, zal de agent de komende vijftien minuten weer niets doen. Alles wordt in de kernel gedaan.

Dan de netwerkgebaseerde enforcer. Een redelijk eenvoudig stukje technologie, maar tegelijkertijd behoorlijk krachtig omdat het een van de vele enforcers is die je vrijwel overal in je omgeving kunt gaan introduceren omdat het een VM is. En wat dan nieuw is, is de slimme switch.

De slimme switch is dus gebaseerd op Cisco Silicon One voor de hardcore packet forwarding. En dan hebben we meerdere DPU aan de Silicon One-chip gekoppeld, zodat we, optioneel, verkeer naar de DPU kunnen omleiden om vervolgens interessante dingen in de DPU te doen. In de context van de presentatie van vandaag betekenen interessante dingen in de DPU natuurlijk Hypershield.

De manier waarop dit werkt, is dat wanneer de switch opstart, deze DPU’s worden gedetecteerd, en dan kun je ervoor kiezen om die DPU’s zo te configureren dat ze verkeer ontvangen op per VRF. We kunnen er dus per VRF voor kiezen om verkeer om te leiden, specifiek naar een DPU of naar veel DPU’s. En dan zal binnen de DPU de HyperShield-agent actief zijn.

Het wordt geconfigureerd zoals het zou zijn als een netwerk enforcer. Het zou verbinding maken met het HyperShield-controlplane. Het zou al het netwerkpolicy ontvangen dat nodig is, enforce en alles is gedaan.

Dus vanuit het oogpunt van implementatie, zoals het zou werken, doe je ongeveer vier, vijf regels configuratie op de switch, zodat de switch weet hoe de DPU’s naar het management moeten verbinden naar de controlplane, een call-home, voor het besturen van HyperShield. Vanaf dat moment beheert u de HyperShield-instanties die binnen de DPU draaien vanaf het HyperShield-controlplane.

Dus waarom DPU?

Ik denk dat dat redelijk duidelijk is. Er zijn tegenwoordig dus verschillende soorten hardware platforms waarop je daadwerkelijk software kunt gebruiken. De CPU bestaat al een hele tijd. NPU, dat is precies wat bijvoorbeeld de Silicon one-chip is.

Het is net als een netwerkverwerkingseenheid. Het is bijvoorbeeld een stuk hardware dat speciaal is gebouwd om daadwerkelijk pakketten door te sturen. En dan, vrij recent, zijn zowel GPU als DPU in een stroomversnelling terechtgekomen. GPU zit meer in de op hyperparallelle AI gebaseerde workloads, enzovoort.

En dan beginnen we nu een DPU stijging te zien, omdat ze steeds meer geïnteresseerd raken, of interessant als platform om daadwerkelijk software te gaan implementeren die nog wat verbeteringen nodig heeft om daadwerkelijk meer softwarepakketten te kunnen verwerken, een snel genoeg tempo om daadwerkelijk alles bij te kunnen houden wat de netwerkbox zou moeten verwerken.

Nu zal in eerste instantie een heel specifiek type klant geïnteresseerd zijn in deze slimme switches. De reden hiervoor is dat als je kijkt naar wat we tegenwoordig met HyperShield kunnen doen, het in wezen dubbele segmentatie is. Toch?

Als ik het versimpel en segmentatie toepas op security niveau, maak je in feite een stateful, layer four access list. Dat is in wezen wat er gebeurt op de securityslaag.

Het is duidelijk dat er veel meer aan de hand is in het totaalbeeld. Maar in de enforcer, in de DPU, dat is in wezen wat we doen. We zoeken uit wat de policy is dat we moeten afdwingen en we enforcen het.

Voor welk type scenario is de slimme switch tegenwoordig zinvol? Het is duidelijk dat de hoeveelheid mogelijkheden die ik binnen de DPU ga inzetten enorm zal toenemen, wat ook betekent dat het voor steeds meer klanten aantrekkelijk zal worden. Maar tegenwoordig zijn deze slimme switches vooral geschikt voor implementaties waarbij je een bepaald niveau van netwerksegmentatie nodig hebt, meestal vanwege regelgeving, vanwege de wet, vanwege verzekeringsredenen, enzovoort, wat meestal betekent dat het een financiële klant is, waarbij een merkbaar minimum segmentatieniveau nodig is voor al hun verkeer, wat meestal betekent dat al het verkeer dat het netwerk-fabric binnenkomt, wordt gestuurd. een enorm, kolossaal cluster van firewalls en dan verder naar de bestemming.

Een van de nadelen hiervan is dat in de eerste plaats uw cluster van firewalls groot genoeg moet zijn, in de eerste plaats om alle pieken in het netwerkvolume op te vangen. Dat betekent ook dat je dikke firewalls hebt, die meestal niet de goedkope zijn. En tegelijkertijd doen deze dure firewalls gewoon segmentatie, in feite geavanceerd beheer van de netwerk toegangscontrole.

Dus vanuit een waardepropositie is het niet zo aantrekkelijk, maar het is een must. Het is een verplicht selectievakje om aan te vinken.

Voor dat soort toepassingen is deze slimme switch eigenlijk best interessant omdat je nu een gedistribueerde hardware-enforcing-laag hebt. Je kunt de handhaving dus daadwerkelijk verdelen, waardoor je dichter bij de resource kunt handhaven. U hoeft geen verkeer om te leiden naar een set firewalls en u hebt hoe dan ook een netwerkinfrastructuur. U voegt nu dus gewoon de segmentatiemogelijkheid rechtstreeks toe aan uw hardware, networking-fabric en u hoeft geen verkeer om te leiden naar de firewalls.

Je hoeft die firewalls niet te beheren, enzovoort. Dat is de waardepropositie van de hardwarelaag. De waardepropositie van HyperShield is dat, zoals ik al zei, dit nu in plaats van een enkel cluster voor segmentatiehandhaving, meestal een cluster van firewalls, nu gedistribueerde fabric is. Je hebt een manier nodig om ervoor te zorgen dat het centrale policy daadwerkelijk in het hele fabric wordt gehandhaafd.

Maar zoals ik al zei, nogmaals, HyperShield doet dit, vrijwel buiten de gebaande paden. Dus dat is voor de enforcers.

Christian, heb je tot nu toe nog vragen?

Ja. Ik zie dat er eBPF op de agenda staat, maar we kunnen deze nu gebruiken om op adem te komen.

Martin vraagt dus om eBPF-ondersteuning voor Windows Server-edities. Verwachten we dat reeds beschikbare versies openstaan voor die nieuwe eBPF-ondersteuning, of zullen toekomstige versies van Windows eBPF-ondersteuning bieden?

Yep. Ik heb hier dus nog geen officiële bevestiging van gezien, maar ik verwacht dat Windows-10 en hoger en Windows Server-2019 en hoger de eBPF-capaciteit zullen krijgen.

Dank je wel. Martin, laat het ons weten als we je vraag niet hebben beantwoord. Dank je wel. Jeroen, ga verder.

Dus een korte omweg om nog eens het policy model te benadrukken dat we gebruiken in HyperShield. De belangrijkste reden waarom we de manier waarop we in ieder geval Cisco en waarschijnlijk een grotere netwerkindustrie introduceren, een nieuw policy model, is simpelweg omdat het niet meer alleen om policy en verkeer gaat.

We willen beide segmentatie op microscopisch niveau uitvoeren, zoals op intraprocesniveau, op library niveau waarbij processen worden geladen. Maar tegelijkertijd willen we hetzelfde policy ook kunnen gebruiken voor alle andere HyperShield-functionaliteiten, zoals exploitbescherming. Het is dus duidelijk dat we een taal of een policy beschrijvend, beschrijvend model nodig hebben dat al deze dingen kan doen.

Tegelijkertijd moet dat model ook leesbaar en begrijpelijk zijn voor zowel mens als machine. Dus de manier waarop we bij dit model zijn terechtgekomen, is dat we iets hebben hergebruikt dat AWS een tijdje geleden onder de cedar taal heeft uitgebracht, en het is in wezen het parkmodel, principalprincipal, actie, resource met de optionele voorwaarde. De manier waarop dit werkt, is de principal in wezen je resource, de resource je bestemming, en de actie is wat de principal probeert te doen met die resource. Zodra we daar een match voor hebben, passen we het effect toe. En optioneel is er een voorwaarde.

Dus laat me dit misschien doen met een voorbeeld dat meestal wat logischer is.

We hebben bijvoorbeeld dit beveiligingslek van een paar maanden geleden, waarbij SSH een kwetsbaarheid heeft zodra een kwetsbare versie van de XE-bibliotheek wordt geladen. Dus dan zou je kunnen zeggen, in menselijke taal, SSH alleen toestaan om een niet-kwetsbare versie van de XE-bibliotheek te laden. Zoals je dat in een HyperShield-policy zou omschrijven, is dat terwijl je principal de SSH-daemon is, de resource deze bibliotheek is. De actie is als, dit proces probeert die bibliotheek te laden.

Vervolgens hebben we een voorwaarde ingevoerd die zegt: kijk. We voldoen alleen aan deze regel als we aan elkaar voldoen, een bibliotheekversie die kwetsbaar is. We weten dus dat vijf zes nul en vijf zes één kwetsbaar zijn voor dit specifieke, CVE. En wat we dan als effect gaan doen, is blokkeren en blokkeren. Zo zou je dit verwoorden, een wereldwijd HyperShield-policy. Dat is ook wat je als velden zou moeten invoeren als je de API zou gebruiken.

Je moet bijvoorbeeld een object maken dat u vervolgens aan de principal kunt toewijzen. Je moet een object aanmaken dat u aan de resource hebt toegewezen. Je kiest de laadbibliotheek als actie. Je zet de conditionals als versie, een string voor die specifieke bibliotheek, en dan kies je als effect block and lock.

Dus dat is precies wat er zou gebeuren. Zoals u al begrijpt, hebben we tegenwoordig endpoints die verschillende Linux-distributies gebruiken waar we mogelijk, dit soort dingen, het policy zoals dit, dat gebaseerd is op eBPF. Voor netwerksegmentatie hebben we niet alleen de endpoints, maar ook de VM, en daarvoor hebben we de slimme switch. In de nabije toekomst zullen we ook Windows hebben.

Deze globale policy zal dus natuurlijk worden vertaald in verschillende implementaties.

Aan de rechterkant hebben we dus bijvoorbeeld de vertaling naar de eBPF-implementatie die we via Tetragon krijgen. Tetragon kan dus als invoer een zeer leesbaar YAML-bestand gebruiken dat precies beschrijft wat we beschrijven in het Hypershield-policy, dat vervolgens door Tetragon wordt omgezet in een echt eBPF-traceringspolicy. Er zijn dus verschillende abstractielagen, maar het mooie is dat we als mens en als programmeur of als automatiseringsingenieur hiermee werken, HyperShield-policy-model, principiële actiebron, optionele voorwaarde. Zodra we een match hebben, passen we het effect toe. Heel eenvoudig dus.

Laten we nu dus een kleine opfrissing van eBPF doen. Dus allereerst, hoe werken besturingssystemen?

Nou, we hebben zoiets nodig dat een kernel heet. Omdat anders alle verschillende toepassingen de vrije hand zouden hebben om de verschillende fysieke resources te gebruiken, zoals CPU, tijd, geheugen, toegang tot opslag, toegang tot het netwerk. Ze zouden kunnen beginnen en de volledige netwerkpoort in beslag nemen, wat natuurlijk niet is wat we willen.

In plaats daarvan hebben we iemand nodig die voor wet en orde zorgt, en dat is wat we de kernel noemen. De kernel zal dus een CPU-planner hebben om zo eerlijk mogelijk de CPU-tijd toe te wijzen aan elk van de applicaties, zodat de applicaties niet met elkaar kunnen starten vanaf de CPU en andere bronnen, enzovoort.

Wanneer een toepassing nu om CPU-tijd vraagt, toegang tot geheugen vraagt, wanneer het een bestand wil lezen, noemen we dat een systemcall. En dat zullen de aanroepen zijn die de applicatie naar de kernel doet.

Nu is eBPF een kernelfunctie. Dit is belangrijk. Ik, ik en ik denk dat ik dit de laatste keer ook heb benadrukt.

Het is een kernelfeature. We gebruiken een bestaande kernelfunctie. We veranderen de eigenlijke kernelcode niet.

De kernelcode waarmee deze tijd eindigt, denk ik, is waarschijnlijk een van de meest complexe stukjes code die er zijn. Het is dus duidelijk dat we niet willen beginnen met het introduceren van wijzigingen in de code die complex en te cruciaal zijn voor het systeem. Je maakt een fout, de kernel ontploft en het hele systeem sterft.

Er zijn in het verleden voorbeelden geweest van wat de gevolgen kunnen zijn als je direct begint met het wijzigen van de kernelcode. Nu eBPF, de manier waarop het werkt, is dat het een kernelfunctie is.

En wat doet de functie? Hiermee kun je miniprogramma’s rechtstreeks aan de kernel geven die de kernel in de kernel zal laten draaien. Dus die miniprogramma’s zullen niet in de gebruikersruimte draaien.

Ze worden niet in de gebruikerslaag uitgevoerd. Ze draaien rechtstreeks in de kernel en zijn gebaseerd op gebeurtenissen. Dat betekent dat zolang de gebeurtenis die dit miniprogramma activeert niet plaatsvindt, het enige dat dit programma doet is een paar kilobytes kernelgeheugen verbruiken, en dat is alles.

En telkens wanneer zich een gebeurtenis voordoet die gekoppeld is aan dat programma, zal de kernel het eBPF-programma uitvoeren en dan verder werken. Wat kunnen we nu doen? Waarom is dit zo geweldig? Ten eerste hebben we nu inzicht in bijna alles wat de kernel kan zien.

En tegelijkertijd kunnen we ook kernel beslissingen beïnvloeden. Dus elke keer als de kernel zegt: OK.

Ik ga dit pakket doorsturen, je kunt nu nog steeds bijvoorbeeld toegangscontrole doen. Je kunt zeggen dat deze pakketten zijn toegestaan, deze pakketten zijn niet toegestaan.

Je kunt zelfs pakketmanipulatie doen. Dus je kunt bijvoorbeeld zeggen, nou ja, dit is een VXLAN-Fabric. We beginnen met het toevoegen of verwijderen van VXLAN-headers of GRE-headers of wat dan ook.

En dit is waar je misschien, voor mensen met Kubernetes-ervaring, dit is een van de redenen waarom dit, vooral in Kubernetes-omgevingen, zo interessant is. Dus natuurlijk, netwerkfiltering, observabiliteit, sec-netwerkbeveiligingspolicy, dat allemaal kunnen we allemaal doen.

Dus dat is het mooie van eBPF. Tegelijkertijd is eBPF buitengewoon performant. Dus ik denk dat ik dit de vorige keer al zei, dus ik ga redelijk snel.

Als je naar het ergste geval kijkt, is dat meestal iets dat lijkt op het samenstellen van een groot programma. Dus hier compileren we een echte kernel, die ongeveer één punt vijf miljoen syscalls activeert, kernel gebeurtenissen. En vergeet niet dat eBPF door gebeurtenissen wordt aangedreven. Dus elke keer dat er een kernelgebeurtenis plaatsvindt, is dat een potentieel moment waarop een eBPF-programma moet draaien.

Dus wat we toen hebben gedaan, is dat we onze basislijn hebben genomen. We meten de tijd die nodig is om de kernel te compileren, en dan introduceren we een eBPF-programma dat zegt dat voor elke afzonderlijke Cisco, elke afzonderlijke kernelgebeurtenis, de onbewerkte gegevens van die gebeurtenis naar het hoofdgeheugen worden geschreven. En dan zien we dat, ja, de rekentijd stijgt met één punt vijf, één punt zes procent. En vergeet niet dat dit een worst case scenario is.

En de typische werking van een systeem is dat er geen punt vijf miljoen Cisco’s zullen zijn over een periode van vijfhonderd tot zeshonderd seconden. Dit lijkt echt op een rampscenario.

In het echte leven zal de impact van het gebruik van eBPF dus een stuk minder zijn. En dan zou je kunnen zeggen, nou ja, in het hoofdgeheugen dumpen en niet alleen de gegevens manipuleren, de gebeurtenis, dat is eenvoudig. Laten we het dus een beetje interessanter maken. En allereerst worden de onbewerkte gegevens nu gecompileerd en gestructureerd in een JSON-gegevensstructuur.

En in plaats van naar het hoofdgeheugen te schrijven, herschrijf je naar schijf. En dan zien we dat de totale compilatietijd met twee punten vijf tot twee punten zes procent stijgt. En nogmaals, dit is nogal intensief.

Dus voor elke Cisco verzamelen we alle informatie, compileren we alle informatie in een JSON-gegevensstructuur en herschrijven deze vervolgens naar schijf. Dat toont dus maar weer aan dat we zelfs in een rampscenario minder dan twee punten vijf, twee punten zeven procent invloed zien op de totale CPU-tijd.

Dus ik hoop dat, dat illustreert dat het vanuit performance oogpunt moeilijk is om eBPF te verslaan. Tegelijkertijd is eBPF extreem veilig. Dus mensen zouden kunnen denken, nou, als we beginnen met het uitvoeren van scripts in de kernel en we voegen huidige functionaliteit toe aan de kernel, omzeilen we dan niet in de eerste plaats alle beveiligingscontroles met de kernel?

Het antwoord daarop is natuurlijk nee. Wij, de mensen die eBPF bouwen en onderhouden, zijn door de overname van Isovalent naar Cisco gekomen. Ze zijn eigenlijk slim genoeg om te beseffen dat we er natuurlijk voor gaan zorgen dat dat nooit gebeurt.

Dus eerst en vooral, wanneer een eBPF is, geprogrammeerd, een script wordt gecompileerd, voordat we het aan de kernel overdragen, gaat het door een verifier om er zeker van te zijn dat, kijk, geen van die dingen, geen van die overtredingen kunnen gebeuren. Die scripts mogen niets doen wat een ander programma niet zou mogen doen.

En in feite zijn ze vanuit een bepaald oogpunt zelfs nog veiliger omdat we extra hardening uitvoeren voordat we het programma uitvoeren. We voeren het programma dan zelfs uit in een zeer beperkte geïsoleerde uitvoeringsomgeving. Alleen vooraf goedgekeurde datastructuren kunnen dus worden gelezen.

Alleen vooraf goedgekeurde acties kunnen worden uitgevoerd of gewijzigd. Het is dus een extreem gecontroleerde en extreem hardened en veilige omgeving waarin eBPF-scripts kunnen worden uitgevoerd.

Cool. Heb je nog vragen over eBPF voordat ik verder ga?

Tot nu toe niets, Jeroen. Dus ik laat het je weten.

Oké. Uitstekend. Cool. In deze tijd kan een presentatie dus niet compleet zijn zonder over AI te praten.

Wat ik zal proberen te doen is twee vragen beantwoorden. Welk type AI gebruiken we en waarom? En waar wordt het gebruikt en wat is de output en wat is het eindresultaat van AI in de eerste plaats?

Dus om daarover te praten, moet ik eerst wat tijd besteden aan, praten over graphs. Je zult weten wat een graph is. Het zijn een aantal knooppunten die vervolgens worden verbonden met, met lijnen.

En die regels laten in feite zien welke bron welke resource gebruikt of afhankelijk is van welke resource. Dus dat is in wezen een graph. Niets bijzonders.

Waarom gebruiken we graphs in cyberbeveiliging? Nou, er zijn veel redenen. Maar in HyperShield is het eigenlijk de kerngegevensstructuur die we gebruiken om om te gaan met de enorme hoeveelheid gegevens die nu voor ons beschikbaar is. Want denk aan alle gegevens die je al genereert met alleen je beveiligingstools. Als IT-afdeling ga je waarschijnlijk nog meer data genereren.

Door nu dus een tool toe te voegen die geschikt is voor eBPF, wordt in feite elke afzonderlijke Cisco, elke afzonderlijke gebeurtenis in het besturingssysteem nu ook een datapunt. Dus dat kan een lawine zijn die gewoon overloopt, al je gegevensontvangers. Dus we doen een eerste laag om dit te begrijpen.

Dus in plaats van een ruwe dump van al deze datapunten te hebben, gaan we ze in feite in een graph structureren. Het leuke van de graph is dat het de gegevens in feite een stuk beter leesbaar maakt, zowel voor een mens als voor een machine. Dus dat is, nogmaals, een grote win-win situatie om graphs te gebruiken.

Bovendien stelt het ons ook in staat om de hoeveelheid gegenereerde gegevens die we daadwerkelijk moeten delen, naar het controlplane te condenseren. Er zijn tegenwoordig dus een heleboel voordelen. Een belangrijk punt dat ik ook wil benadrukken over de graph is dat mensen soms beginnen te spelen met HyperShield, en ze zien een screenshot, en ze zeggen, nou, hier is niets nieuws aan.

Dus, ik bedoel, we hebben vandaag en dan graphs gezien en de graphs die ik kan zien, dat is allemaal heel eenvoudig. Het belangrijkste om te beseffen is dat elke weergave van de graph die u daadwerkelijk kunt zien in de grafische gebruikersinterface van HyperShield, in de eerste plaats slechts een klein deel is van de werkelijk beschikbare gegevens. En ten tweede is het niet hoe we de graph weergeven of visualiseren, visueel voor een mens wat belangrijk is. Het is wat er in de graph staat en hoe de graph door HyperShield als systeem wordt gebruikt.

Dus de manier waarop we de graph eigenlijk opbouwen, is dat het een op ontologie gebaseerde graph is.  Dat betekent dus dat elk gegevenspunt in de graph meerdere labels zal hebben die uitleggen wat dit ding is, juist, wat erg belangrijk is voor zowel, nogmaals, een mens als voor de machine.

Want als je voor een mens naar de graph gaat kijken, dan kun je zien welke gegevens erin staan. Het is de gegevens die worden beschreven. Dit is dit. Dit is een proces. Dit is een bestandsnaam. Dit is een gelezen bestand. Dit is een omkering van het pad. Al die dingen zitten erin.

En wat de agent dan vandaag doet, is ongeveer een kwartier. Dat het interval waarschijnlijk zal veranderen en/of door de gebruiker kan worden geconfigureerd. Elke vijftien minuten maakt hij een momentopname van de omgeving die hij kan zien.  Wat kan hij zien? Uiteraard draaien alle applicaties op dat specifieke besturingssysteem.

Het maakt dus een grafische weergave van de lokale weergave van dat specifieke besturingssysteem en stuurt die graph vervolgens naar het HyperShield-controlplane, waar we dan een merge service hebben die een globaal beeld van uw omgeving maakt op basis van al deze individuele graphs. Op een bepaald moment in de toekomst zullen we ook de netwerkenforcers, dus de VM en de slimme switch, toestaan om iets te gaan bouwen dat lijkt op een graph. Het zal duidelijk een stuk minder gedetailleerd zijn, want het enige dat die enforcers kunnen zien, zijn netwerkstromen. Maar we onderzoeken ook of we die informatie over de netwerkstroom kunnen gebruiken om bij te dragen aan de algemene inhoud van wat beschikbaar is in de graph.

Om bijvoorbeeld vanuit netwerkoogpunt een op graphs gebaseerde weergave te hebben van wat er gaande is op de locatie waar enforcer toevallig draait.

Dus waarom gebruiken we AI?  Nou, als je kijkt naar de enorme hoeveelheid informatie die we nu krijgen van al deze agenten, als je kijkt naar de enorme hoeveelheid CVE’s die elke tijdseenheid worden gepubliceerd, als mens, kunnen we het natuurlijk niet bijhouden.

Dus waar en waar en hoe gebruik je AI vandaag in HyperShield? Nou ja, eigenlijk in een heel specifiek deel van HyperShield. En dat deel is het stukje dat naar al deze kwetsbaarheidsinformatie kijkt die wordt gepubliceerd en vervolgens uitzoekt hoe we daadwerkelijk kunnen beginnen met het maken van beschermingsmaatregel voor die dingen.

Dus wat die AI doet, heeft twee belangrijke gegevensbronnen als invoer nodig. De eerste grote gegevensbron is uiteraard een CVE-database die Kana ons ter beschikking heeft gesteld.

Dus nu AI zich bewust wordt van elke bekende kwetsbaarheid, doen we een aantal dingen. We zoeken uit hoe we kunnen detecteren dat die CVE’s in uw omgeving aanwezig zijn, en we zoeken uit hoe we een beschermingsmaatregel kunnen creëren voor die CVE. Wat is een beschermingsmaatregel? Ik zei toch dat ik, meestal met mijn technische pet op, de term beschermingsmaatregel zou gebruiken.

Dat is mijn marketingpet. Dus wat betekent een beschermingsmaatregel in werkelijkheid? Nou, het is niets meer dan de marketingterm voor een eBPF-script. Wat is er zo speciaal aan het eBPF-script?

Het doel van het eBPF-script is om te voorkomen dat een aanvaller misbruik maakt van de CVE in uw omgeving.  Dus als de CVE bijvoorbeeld over de omkering van het pad gaat, wordt de omkering van het pad voorkomen. Als de CVE u toestaat om een externe code uit te voeren, wordt de uitvoering van de externe code voorkomen zodra dit eBPF-script is geladen in de kernel waarop die toepassing draait.

En dat is de sleutel.  Het enige wat we doen is een eBPF-script introduceren, en de CVE kan niet langer worden misbruikt door een aanvaller. Dat betekent dat we de software helemaal niet aanraken. U hoeft geen software-updates, softwarepatches, softwarewijzigingen of iets dergelijks uit te voeren.

Nu is het maken van dit eBPF-script echter makkelijker gezegd dan gedaan. Om te beginnen hebben we een systeem nodig dat idealiter automatisch, zodra deze nieuwe CVE wordt uitgebracht, een eBPF-script kan maken dat voorkomt dat een aanvaller misbruik maakt van die CVE.

Nu zijn er vele manieren waarop u daadwerkelijk kunt voorkomen dat een code op afstand wordt uitgevoerd.  Maar hoe komen we erachter wat de juiste manier is? Er zijn een paar dingen.

Allereerst controleren we automatisch of na het implementeren van het eBPF-script een exploit van die specifieke CVE natuurlijk niet meer werkt.  Er zijn veel manieren om dit te voorkomen, en dit is waar Talos om de hoek komt kijken. Talos beschikt over een enorme hoeveelheid data. En ten tweede heeft de Talos-organisatie een grote groep superslimme, zeer ervaren beveiligingsprofessionals. Dus hoe helpt Talos ons? Ze doen een paar dingen. Allereerst bouwen ze een steeds groter geheel op van wat wij grondwaarheden noemen.

Grondwaarheden zijn in feite wat de juiste manier is om dit soort aanvalsvectoren te voorkomen. Omdat er veel CVE’s zijn, is de aanvalsfactor hetzelfde.  Een of andere vorm van het uitvoeren van een binair bestand, een of andere vorm van pad omkering.

Dus voor al die aanvalsvectoren geeft Talos ons, nou ja, ons, de AI, de juiste manier om dat type aanvalsvector te voorkomen.  Zodat de HyperShield AI dat daadwerkelijk kan gebruiken als een manier om te valideren dat wat het ook bedenkt of berekent als een voorstel om de kwetsbaarheid daadwerkelijk te voorkomen, de juiste is.

Het tweede dat Talos doet, is dat we voor alle beschermingsmaatregel die we hebben, relatief gezien al weten hoe we automatisch kunnen verifiëren dat het schild goed is in het voorkomen dat de CVE wordt uitgebuit. Maar er is nog een tweede ding dat voor ons erg belangrijk is om te valideren, en dat is proberen ervoor te zorgen dat het schild de werking van de applicatie in de eerste plaats niet zal verhinderen.  Dus en dat is niet triviaal, want we weten niet wat de toepassing zou kunnen zijn.

Er zijn een heleboel open source-applicaties die vrij vaak worden gebruikt in de industrie, maar er zijn ook een heleboel closed source en een heleboel, op maat gemaakte, applicaties van eigen bodem waarvan we niet weten wat de applicatie wel of niet zal doen. Dus dat is nogal lastig waar we nog steeds mee bezig zijn.

En dat is ook de reden waarom als je kijkt naar HyperShield vandaag, we zo’n twintig, zevenentwintig verschillende CVE’s hebben waartegen we ons vandaag kunnen beschermen, ook al zitten we op een bibliotheek van honderden, waarschijnlijk zelfs duizenden schilds, die bijna klaar zijn voor gebruik.  De laatste fase die we nog aan het doen zijn, is uitzoeken of alles in orde is voordat we je daadwerkelijk toegang geven tot die schilds.

Dus dat is waar we vandaag zijn.

Natuurlijk is dit gewoon goed om te weten. Je hebt misschien gehoord van Cisco CSDL, Cisco Secure Development Life Cycle, wat een heleboel verplichte regels en procedures is waaraan iedereen bij Cisco die code schrijft, zich aan moet houden.  Wachtwoorden dus niet hard coderen, wel, invoervalidatie, al die dingen.

We hebben nu ook een vergelijkbaar raamwerk voor dat alles, elk technisch team bij Cisco dat machine learning- en AI-modellen gebruikt. Dus nogmaals, de juiste manier om dat te doen, zijn regels en voorschriften om ervoor te zorgen dat er nooit sprake is van kruisbestuiving, dat we AI nooit trainen op klantgegevens en al die dingen.

Daar hebben we dus ook een heel team dat gespecialiseerd is in alles wat met ML en AI te maken heeft en dat er vervolgens voor gaat zorgen dat alle technische groepen bij Cisco zich gedragen zoals ze zich moeten gedragen, goed, en AI verantwoordelijk gebruiken.

Cool. Dan is het volgende, om snel over digital twin te praten. Christian, heb je nog vragen voordat ik verder ga?

Nee. We zijn klaar om te gaan. Dank je wel.

Uitstekend.

Dus jullie kennen allemaal Digital Twin. Het is in wezen een manier om het systeem nog steeds te vertrouwen na wat ik je net heb uitgelegd.  Ik heb je nu uitgelegd dat, met name voor de bescherming tegen gedistribueerde exploits, veel van de acties die je uiteindelijk zou ondernemen, daadwerkelijk worden berekend en gegenereerd door een AI.

Dus waarom zou je het in hemelsnaam vertrouwen? Digital twin is onze poging om de AI een kans te geven om je ervan te overtuigen dat wat het voorstel je ook voorstelt logisch is, niet alleen logisch is in de context dat dit schild geschikt is voor deze kwetsbaarheid, maar dit schild ook geschikt is voor die kwetsbaarheid in je omgeving met alles wat jouw omgeving uniek maakt. Jouw unieke hardware, software, verkeerspatronen, alles.

Dus de manier waarop we dat doen, is dat de digitale tweeling dit schild of dit policy, of deze nieuwe softwareversie in uw omgeving in uw enforcer zal valideren.  Dus als je overal veel enforcers hebt, worden deze dingen bij al die enforcers gecontroleerd.

En dan genereren we een rapport dat u daadwerkelijk vertelt, kijk. Dit is wat er zou gebeuren op basis van wat we in uw omgeving hebben gezien als u ervoor kiest om dit policy, dit schild, deze segmentatie te implementeren, we zullen updaten, enzovoort.  En, eigenlijk zal ik je dit ook live laten zien, maar ik moet je wel een paar dingen vertellen.

Allereerst is deze betrouwbaarheidsscore niet hoe zeker de AI ergens van is. Dit is een meetbaar aantal tests dat is geslaagd. En als we zeggen dat wanneer we je laten zien dat deze test geslaagd is, hoef je niet zomaar in één woord te geloven. We vertellen je eigenlijk precies waarom we denken dat het is aangenomen, zodat je het ermee eens of oneens kunt zijn.

We zien bijvoorbeeld dat het minimum, de maximale gemiddelde CPU, dat het verschil is tussen het actieve dataplane en wat de digitale tweeling heeft getest.  En dan zeggen we, wat ons betreft, als het binnen de vijf procent ligt, we het als geslaagd beschouwen. Maar als je om wat voor reden dan ook zin hebt, nee.

Het verschil mag niet meer dan één procent bedragen. Nogmaals, u hebt de gegevens om uw eigen beslissing te nemen en zelf te beslissen of u het eens of oneens bent met elk van deze individuele testresultaten.  Maar nogmaals, ik zal je dit over een minuut ook live laten zien.

Laat me de tijd bijhouden. Oké. We zijn keurig op tijd.

Zo en ook vandaag zijn we wat beperkt in de herziening van het netwerkpolicy. Dus op dit moment is het enige dat je kunt zien het verschil in het aantal treffers tussen het primaire en het secundaire dataplane.

In de nabije toekomst willen we bijvoorbeeld ook gegevens in IPFIX- of NetFlow-stijl openbaar maken. Dus je kunt zien dat pakketten die zich anders gedragen tussen primair en secundair of primair en schaduw, ze kunnen zeggen: Over welk verkeer hebben we het?  Dus dat om je dat extra detailniveau te geven.

Cool. En voordat we overschakelen naar, heb ik, zoals je kunt zien, de exploitbeveiliging van die segmentatie overgeslagen, omdat ik in plaats van slides een live demo ga proberen. Laat me het dus snel hebben over de API.

Dus als we kijken hoe de architectuur eruitziet.  Dus we hebben SCC als het platform waarop het HyperShield-controlplane draait. Dat is ook waar je naartoe zou navigeren als je wilt, zie bijvoorbeeld de HyperShield-gebruikersinterface, die ik je zo meteen laat zien.

Maar als u met het HyperShield-beheerplan wilt praten, krijgt u van SCC de manier waarop u zich met de API zou authenticeren.  Dus als je al bezig bent met automatiseren tegen SCC, kun je gewoon hetzelfde token gebruiken, je API-token van je SCC-gebruiker, en dat gebruik je om te authenticeren. Dat is dus al een indicatie dat, kijk, de beveiliging van de cloud als een veelgebruikt plan hiervoor geen marketinggedoe is.  Dit is eigenlijk ook de manier waarop we dingen implementeren in de back-end. Dus ook al hebben we een speciaal HyperShield-controlplane en al die dingen, de manier waarop je ermee omgaat, de bestemming, ja, er zal het specifieke HyperShield API-endpoint zijn, maar niet het SCC-endpoint. Maar alle authenticatie verloopt via de gebruikelijke SCC-bits.

Dus natuurlijk geldt zowel de schikking als de documentatie.

Ik ben ook bijna begonnen met het publiekelijk implementeren of op zijn minst vrijgeven van enkele voorbeelden. Ik zal je enkele voorbeeldscripts laten zien. Dus dat is bijvoorbeeld een weergave van een leeg OpenShift-cluster. Dat geeft je ook al een idee van hoeveel gegevens er eigenlijk in de graph zitten.  Dit is een leeg cluster.

Voor degenen onder u die hebben gespeeld met verschillende soorten open Kubernetes-distributie, dan weet u dat OpenShift veel extra mogelijkheden heeft, wat zich vertaalt in veel extra proceslocaties die overal worden uitgevoerd. Nu is de manier waarop dat werkt in wezen relatief eenvoudig.  Dus het script is eigenlijk het grootste deel gewoon het opzetten van alles.

Je maakt een importaanvraag. U maakt uw URL, een operatie-ID, een API-token. Ik heb zelfs een tenantsbevestiging dat ik meerdere tenants heb, dus ik kan gewoon de naam van de tenant geven en dan pak ik het token van die tenant.

En eigenlijk is het enige dat je doet een simulatie van de gegevens, gewoon mooi afgedrukt aan de rechterkant. Dus aan de rechterkant is het volgende hoe de werkelijke graph er onder de motorkap uitziet.  Dus je kunt zien toen ik het zei, dit is een ontologiegraph.

Wat bedoel ik? Nou, dat is ook CSCO colon, sommige tabellen.  Dit is bijvoorbeeld een hostnaam. Dit is de apparaat-ID. Dit is de fout opsporingsinformatie, enzovoort. Dat zijn aanvullende gegevens die aan elk van deze knooppunten in de graph worden toegevoegd.

Een ander voorbeeld: je kunt het schild opsommen. Dus nogmaals, ik denk dat het hetzelfde is, maar je bent van. Dus laat me alle beschermingsmaatregel zien die we hebben ingezet. En dan zul je binnenin herkennen dat het effect zal zijn.

Niet toestaan. Je zult het principal, de actie hebben. Je hebt de resource. Je hebt de voorwaarden, etcetera, etcetera.  Dus al die dingen waar we het eerder over hadden, staan ook in de API.

Oké. Dit is dus  HyperShield UI, onderdeel van SCC. Dus het enige wat ik deed, was naar Defense Orchestrator gaan, dat nu is omgedoopt tot SCC. Laten we nu naar HyperShield gaan, en laten we beginnen met het bekijken van het policy.

Zoals je kunt zien, is er een Draft en een tabblad History. Wat dat betekent is onder Draft, dat is waar je kunt zien dat dit het daadwerkelijke policy is dat is gepusht. In het ontwerpstadium is dit het geval als u begint met het opstellen van aanvullend policy dat nog niet is getest of naar productie is gebracht, dat is waar dit zal zijn. En dan kun je onder de History alle verschillende implementaties zien die je hebt gemaakt of wijzigingen die je in het verleden hebt aangebracht in je actieve policy.

En het mooie is dat als we dan kijken naar een van die policy maatregelen, die in het verleden zijn gebeurd, we nog steeds het testrapport kunnen zien.  Zo kunnen we bijvoorbeeld zien dat als we naar beneden gaan, we in feite één policy hebben toegevoegd. We hebben een policy toegevoegd dat als belangrijkste app-service app-service als resource DB-service als actie-ICMP heeft.

Actie betekent dus een ICMP-verbinding tot stand brengen en vervolgens, als gevolg, permit en alert. En wat u dan kunt zien, is dat we als onderdeel van de testbeoordeling daadwerkelijk kunnen zien, kijk, dit zijn de verschillen, in de flow-age. Dit is een verschil in latentie. Dit verschil in geheugengebruik, enzovoort.

En je kunt zien, zoek naar degenen die binnen de drempel staan voor succes, we zeggen in het verleden. En voor anderen zeggen we: oké. Kijk. We hebben een beoordeling nodig.

Een van de dingen die we nog steeds een beetje moeten opschonen, is dat als we nieuw policy invoeren, we niet echt iets hebben om tegen te meten.  Waar meten we dan tegen? Meten we de totale latentie van de totale pakketverwerking af? Kijken we naar het verschil voor die specifieke pakketten? Dat zijn dingen die nog steeds aan het afstemmen zijn, dus daarom zie je soms nog steeds van tijd tot tijd grappige cijfers.

En dan zeggen we ook, kijk, we hebben verschillende labels.  Dus we zeggen dat we geslaagd zijn, we hebben gefaald, we hebben misschien wilt u dit beoordelen, of dit is iets waarvan we zeker willen dat u het beoordeelt. En dit is ook iets dat we binnenkort zullen behandelen, want als we een nieuw policy introduceren, is er niets om mee te vergelijken.

Dus als we dan een bepaald aantal vergelijken met NA, zullen we waarschijnlijk alleen de behoeften beoordelen als het aantal treffers voor het nieuwe nummer nul is. Want als de waarde nul is, betekent dit dat ofwel uw policy geen zin heeft omdat er geen verkeer is dat overeenkomt met het verkeer, ofwel dat u de test uitvoert wanneer dat verkeer niet plaatsvond. Dus misschien wilt u uw test opnieuw uitvoeren als u zeker weet dat het policy correct is op het moment dat het verkeer daadwerkelijk zichtbaar is.

Dus dat is in wezen de mens die een handleiding maakt, policy, juist, en dat is wat we vandaag doen, voor de VM-handhaver en de slimme switch.

In de release van april hebben we waarschijnlijk voor het eerst een policy dat automatisch door het systeem wordt gegenereerd.

Dus laat me dan overschakelen naar een andere tenant waar ik je nog wat andere dingen kan laten zien.

Dus als we dan naar mijn tenant gaan, voor het TME-team, laat me je dan het eerste stukje automatische segmentatie zien, wat we anomaliedetectie noemen. Dus als we dan gaan kijken wat de workloads zijn die we hebben, en standaard wordt er een kaart gebruikt. Als de kaart te groot is, zal hij je vertellen, kijken. Je moet filteren naar iets dat kleiner is. Dus als ik het bijvoorbeeld reduceer tot de open applicatie van 5G die ik heb uitgevoerd, dan wordt het scherm daadwerkelijk weergegeven.  Dus als we nu naar de lijst gaan en naar containers gaan, en hier kun je al zien dat er daadwerkelijk een exploiteerbare host is, maar we zullen binnenkort de demo van de exploitbescherming doen. Als we dan bijvoorbeeld gaan kijken naar de verschillende containers die het volhouden.

Baselining.

Ik heb het net eerder gecontroleerd. Oké. Daar gaan we dan. Dus we bekijken hier de pods, het Kubernetes-cluster. U kunt dus zien dat er standaard iets in de baselining wordt opgenomen.

Baselining is de modus die we gaan gebruiken zodra we deze implementeren. Zoals je je kunt voorstellen, betekent baselining dat we doorgaan met het opbouwen van het gedrag van een applicatie. Wat is nu het gedrag wat Hypershield betreft? Weet je nog dat ik zei dat we de gegevensstructuur van de graph echt voor bijna alles gebruiken.

We gebruiken de graph zelfs voor gedrag. Hoe kun je nu het gedrag van een applicatie beschrijven?  Dat is nogal uitdagend om te doen. Maar omdat we een grafische weergave van de toepassing hebben, wat betekent dat deze toepassing deze processen, deze containers, deze pods is, worden deze bibliotheken geladen. Het is het openen van deze stopcontacten. Het ontvangt verkeer van hier en hier. Dit zijn de processen die tijdelijk worden uitgevoerd.

Dat alles hebben we in de graph. En dan maken we elk kwartier een nieuwe versie van de graph. Dus als we dit zo’n vier uur laten draaien, dan hebben we zo’n zestien snapshots. En dat geeft ons een op tijd gebaseerd beeld van het systeem. En deze tijdreeks graphs, dat is een manier om gedrag te beschrijven. Dat is dus wat we opbouwen tijdens de baselining.

Zodra we gaan scannen, beginnen we daadwerkelijk met het detecteren van afwijkingen ten opzichte van de basislijn. En deze zijn eigenlijk heel subtiel. Dus wat ik hier bijvoorbeeld doe, is voor deze specifieke front-end port, het enige wat ik heb gedaan was een kube kuttle krijgt omgevingsvariabelen. Dat is het enige wat ik heb gedaan. Dus zelfs als je vraagt om de omgevingsvariabelen te dumpen, als dat nog nooit eerder was gebeurd, zal het dit als een anomalie detecteren.

Verschillende voorbeelden, ik denk dat we hier bijvoorbeeld een op Java gebaseerde anomalie zullen hebben. Dus hier zie je het echt. Kijk. We hebben inkomende en uitgaande verbindingen met het Java-proces gedetecteerd, die we nog nooit eerder hebben gezien.

Een van de dingen die we daadwerkelijk gaan doen, in de komende release en meer informatie geven, want op dit moment is het nog steeds ja. Het is gedetailleerd. We hebben het over een heel specifiek proces. We hebben het over inkomend, uitgaand. Maar we hebben nog niet het volledige beeld van die anomalieën. Dus voor elk van de anomalieën hebben we een beeld van iets dergelijks, een grafische weergave die alles laat zien wat specifiek is voor de anomalie.

Maar onder segmentatie kun je dan ook bijvoorbeeld deze weergave hebben. Vandaag is het enige dat we kunnen doen, oké. Laten we zeggen dat dit geen abnormaal gedrag is. Dit is goed gedrag, in dat geval zouden we erkennen, wat zou betekenen dat we dit gedrag aan de basislijn gaan toevoegen.

In de release van april zullen we de mogelijkheid hebben om de andere beslissing te nemen, juist, waarbij je zegt, nou, dit is eigenlijk niet oké. Dit is ik ben niet, dit is slecht gedrag. Genereer policy. En dan is het policy dat u genereert misschien, nou ja, dit is eigenlijk heel slecht gedrag. Laten we het gaan blokkeren. Of misschien zijn ze dat, we willen dieper kijken, en dan heb je bijvoorbeeld een policy dat zegt dat je voorlopig nog steeds toestemming geeft, maar een waarschuwing stuurt en vastlegt, informatie over de gebeurtenissen.

De release van april zal dus de eerste release zijn waarin we daadwerkelijk het eerste stukje automatische segmentatie krijgen, juist, waar we daadwerkelijk, op basis van de informatie die we leren en de dingen die we zien, kunnen beginnen met het voorstellen van daadwerkelijk segmentatiepolicy. Deze aanpak voor anomaliedetectie is de benadering van onderop om automatische segmentatie in te stellen. Kort daarna hebben we een top-down benadering van segmentatie, waarbij we daadwerkelijk beginnen met het voorstellen van echte macro segmentatie zones en vervolgens steeds meer en meer en meer en meer en meer gaan verfijnen.

Wat ik vandaag ook wilde laten zien, is de detectie van kwetsbaarheden. Dus gedistribueerde exploitbescherming. Dus wat ik vandaag in mijn lab heb gedaan, is in feite een kwetsbare HTTPD-container geïmplementeerd, die kwetsbaar is voor deze specifieke kwetsbaarheid. Het zal het detecteren. En dan zal het eigenlijk zeggen: kijk. Dit is het schild dat we voorstellen om daadwerkelijk te gaan voorkomen dat dit gebeurt, wordt uitgebuit. Dus zodra ik voor Deploy Shield kies, en dit is waar het niet altijd even gemakkelijk is om een live demo te doen, kun je zien dat het tot vijftien minuten kan duren. Waarom duurt het zo lang? Nou, weet je nog toen ik de agent stuurde, deed het niet veel. Elke vijftien minuten maakt het een lokale graph en deelt deze met het controlplane.

En tegelijkertijd, wanneer het met het controlplane communiceert, vraagt het ook: heb je een bijgewerkt policy voor mij? Daarom staat in dit bericht dat het tot een kwartier kan duren, want als een paar seconden voordat ik op het inzetschild klikte, is ingecheckt, dan duurt het nog een kwartier voordat we inchecken. Dus een van de dingen waar ik eigenlijk op voortbouw, is het doen van een diepgaande opname waarbij je me daadwerkelijk kunt zien inloggen op de poort.

Ik zal het doen met Metasploit, ik zal de kwetsbaarheid uitbuiten om deze ex te laten zien dat deze kwetsbaarheid er echt is. Dan gaan we het schild inzetten. En zodra het schild is aangegeven als geïmplementeerd, zullen we proberen de Metasploit-exploit opnieuw uit te voeren om aan te tonen, kijk, deze exploit werkt nu niet meer.

Maar omdat het zo’n vijftien minuten duurt, is het niet zo eenvoudig om te doen in een labomgeving of in een demo-omgeving. Dus dat is zo’n beetje mijn demo. Dus daarmee zal ik de sessie van vandaag afsluiten.

Dus heel erg bedankt.