Er volgt nog een ingekorte versie van deze dag, maar om iedereen te laten delen in wat Elastic op deze dag met de bezoekers gedeeld heeft, heb ik zo goed mogelijk alle presentaties die ik bezocht heb hier beschreven. Dat ik dit item niet onder "evenementen" maar "security" schaar, komt omdat we (als het goed is?) met zijn allen weten dat security "vooral nu" belangrijk is. Met AI worden bugs uit 2004 die al jaren in code rondzwerven ineens zichtbaar en bruikbaar voor misbruik. Wordt met AI toolkits gebouwd die ransomware op jouw pc kan installeren zonder dat je het door hebt. Waarbij security-incidenten zo snel kunnen gaan, dat je nog bezig bent met de eerste aanval, maar er inmiddels al 2 nieuwe aanvallen (succesvol) uitgevoerd zijn.
Dit is waar Elastic deze editie de focus op legt. Wat voor hun niet nieuw is, want ze zijn hier al een tijd mee bezig. Er wordt (terecht) gepronkt met het feit dat Elastic dit jaar als beste bij de AV Comparitives EPR Test uit de bus kwam. Daarbij werden 50 multi-stage aanvallen gestopt en ook waren er geen false alerts. In 2025 waren ze ook al de beste, prolongatie van de titel dus. Ik heb even gekeken waar deze gegevens te vinden zijn. Het artikel op de site van Elastic kun je hier lezen. Daarbij wordt verwezen naar deze pagina van av-comparatives.org. Daar hoort deze PDF bij. Daar staat inderdaad een score van 100% malware protection test en 0 false alarms. Ik maak hier wel even de opmerking bij dat het hier om "business software" gaat. In de lijst erboven gaat het over een algemene test, daar zit Elastic met Kaspersky en Bitdefender op de 1e plaats, waarbij 399 malware-zaken gedetecteerd zijn, maar 1 is er doorheen geglipt. En Elastic heeft 12 false alarms gegeven.
Dat is geen schande. Maar het geeft wel aan hoe goed het is dat Elastic (en ook de andere partijen) zich focussen op security en proberen om hun software steeds beter te maken.
9.05 - 9.20 CEO Ash Kulkarni
Ash neemt ons mee in de ontwikkelingen. Elastic doet dat altijd goed. Zo had je de periode dat AI meer gebruiksvriendelijker werd, ook in Elastic werd AI toegevoegd om te helpen/informatie/tips te geven over zaken. Over wat voor data het is wat je nu bekijkt, wat bepaalde zaken betekenen.
Het credo van deze editie is dat AI niet alleen meer je hulpje bij vragen is, maar ook zelf (meer) acties kan/mag uitvoeren. We zien de evolutie van neurolinguïstische netwerken, waarbij het doel was om “te begrijpen”, daarna Q&A, dus waarbij je respons belangrijk is, hierna komen Agents die “dingen voor je kunnen doen”, wat gevolgd wordt door harnesses, de orchestratie om die agents binnen de perken te houden, dat ze niet andere websites plat gaan leggen naar aanleiding van een vraag van jou. Daarop volgt nu de agentic systems, hier is het sleutelwoord “coordinate”.
De bottleneck is volgens Elastic nog steeds de context. De modellen zijn getraind met algemene data, maar het gaat jou om “jouw” data waarmee gewerkt moet worden.
Die context tussen aan de ene kant models, agents, harnesses en workflows en aan de andere kant apps, databases, object stores en telemetry kan door Elastic geleverd worden door er als een soort brug tussen te zitten. Je hebt de datastore, daar worden semantische indexen op gemaakt (die AI ready zijn), het retrieval blok (pak de juiste context erbij), models en agents – pas de juiste intelligentie toe en zet uiteindelijk context om in actie.
9.22 - 9.40 Elasticsearch as the context infrastructure for AI, Uri Cohen, VP Product Management
Om 9.31 uur komt Uri Cohen op het podium, de Vice President Product Management.
We zien het overzicht van allemaal soorten data, waarbij Elastic ze in een geschikt formaat kan opslaan. Uri introduceert iets nieuws, de Columnar Mode. Dit is een optimalisatie ten opzichte van de “Document Mode”. In die mode heb je data soms in meerdere kopieën beschikbaar, wat ervoor zorgt dat veel schijfruimte/geheugen nodig is. Maar bij sommige data is dat niet nodig en kun je deze dus als een soort tabel-structuur opslaan.
We zitten vaak bij Elastic in het eigen ecosysteem, maar er komt nu ES|QL Data Federation. Waarmee je in een query niet alleen je eigen logdata kunt filteren, maar ook een AWS S3 container – koppelingen met externe data dus.
Een volgende slide toont iets waar ik nog verder in moet duiken.
Dat is namelijk ook een nieuwe feature. Het Vector Database project type. Hiermee heb je hybride search. Enterprise-kwaliteit. Voorspelbaar prijskaartje. Out of de box optimalisatie. Ook bij het groeien van je data blijft dit goed werken. En een native GPU inference met Jina AI modellen. Jina kwam volgens mij vorig jaar al ter sprake, die heeft Elastic toen overgenomen.
Je hebt hier de Elastic Inference Service. Dit draait serverless, in de cloud. Je hebt modellen die tekst-only zijn, maar ook multimodal, dus voor tekst, afbeeldingen en meer.
Ook nieuw is de introductie van Jina OCR. Dus niet alleen dat je handgeschreven teksten met OCR omgezet worden naar tekst die we digitaal kunnen gebruiken, maar dat met AI ook geïnterpreteerd kan worden.
En in de komende release(s) komen veel meer nieuwe zaken. Kibana die hele mooie/coole weergaves kan tonen. Jina AI. Streams voor het uitwisselen van data. Workflows.
Uri kan ook trots melden dat in het 2026 overzicht van Gartner zij bovenaan in het “Magic Quadrant” van Enterprise AI Search staan. In datzelfde kwadrant staan Glean Technologies en Google.
10.02 - 10.20 Logs. Metrics. AI SRE. Luca Wintergerst
Ash introduceert de volgende spreker, Luca Wintergerst. Hij toont de Elastic Observability Solution.
Hier wordt getoond wat “de concurrentie doet” en wat ze niet goed doen. Dat op maat gemaakte metrieken soms de helft van de totaalfactuur opleveren. Dat alle data in RAM geladen wordt en je bij een “spike” het systeem down gaat. Dat per signaal je aparte opslag hebt, waardoor je data in silo’s zit, in de ene de logs, in de andere metrieken, traces in een andere. Terwijl je bij het interpreteren van de data eigenlijk alles nodig hebt en je dus in de spagaat moet om alles weer bij elkaar te krijgen.
Elastic probeert het niet op die manier aan te pakken, dus wel een combinatie van die data. Binnen Elastic Observability. De schaalbare fundering waar columnar storage, ES|QL, vector search en RAG onder valt. Het blok context en kennis, waar knowledge indicators, runbooks en documenten en incident historie in zit. Dan het blok Agentic Operation waarbinnen de Elastic AI Agent, Workflows, Skills, Anomaly detection en Significant Events zitten.
We zien streams, hoe die data van inputs (Kubernetes, Prometheus RW) door kan zetten naar de “bak” logs-kubernetes of “errors-stream”, maar ook door naar een s3 archief.
Hierna volgt een overzicht van verbeteringen in versie 8.17+. De reductie van opslag met 70% ten opzichte van de standaard Elasticsearch. 50% TCO reductie voor langdurige retentie van logs. Columnar Mode is nog in preview, deze is 3.5x sneller dan het huidige zoeken. Elastic Search 9.4 waar aan gewerkt wordt gebruikt LuceneSource DOC partitionering, wat 3x sneller is, met de Skipper competitive iterator een versnelling van 11x, de Swiss hashtables die 1.4x sneller gaan en wildcard query rewrite die 3.3x sneller is. Het totaalplaatje is dat de query’s rond de 40% sneller zijn sinds januari 2026.
Ook wordt Elastic naast de concurrenten gehouden, Prometheus, ClickHouse, Mimir waarbij de scores van Elastic beter zijn.
Elastic is druk aan het bouwen geweest. Hierdoor is Ingest nu OTel-native, ondersteunt het Prometheus (met remote write), Elastic Agent doet nu ook OTel Collection.
Het uitvoeren van Query’s, kan nu met native PromQL in Kibana. In Discover kun je door jet metrieken heen, met ES|QL TS command. Elasticsearch kan nu als backend voor Grafana ingezet worden. Het onderdeel “onderzoek” bevat ondersteuning voor AWS, Kubernetes en daar komt nog meer bij. Je hebt dashboards, alerts, SLOs, ML Jobs. Agent Skills, MCP app en tools. En Agentic Workflows.
In de volgende slide zien we hoe het alarm “Checkout seems broken” actief wordt. Op basis van de metrieken, traces en logs wordt aan de AI Agent gevraagd “wat is hier aan de hand?”. Deze kan “zien” dat er een CPU spike was, dat er op de gateway time-outs optraden. En dat het erg lijkt op incident X wat eerder voorgekomen is en gedocumenteerd is – en ook de fix bevat. Dus niet afhankelijk van de kennis van die ene medewerker die al jaren bij je bedrijf werkt en “het toevallig nog weet”, maar op basis van je eigen data.
Nog een nieuwe feature. Namelijk “Elastic nightshift AI SRE”. Je AI medewerker die problemen opspoort, ze oplost of aan jou laat zien wat de fix zou kunnen zijn – waarbij jij bepaalt of het goed is. We zien hier de blokken Detection – Investigation – Remediation.
9.42 - 10.00 AlertZero: Introducing the SOC that never sleeps, Mike Nichols, James Spiteri
Om 10.22 uur introduceert Ash Mike Nichols en James Spiteri op het podium. Het programma loopt een beetje uit, want eigenlijk zou rond deze tijd deze sessie al afgelopen zijn.
Onderwerp is Elastic Security. Het eerste blok is SIEM. Elk “security-gerelateerd signaal” op 1 plaats, waar het lange tijd bewaard wordt. De logs, endpoints, cloud, identity. Met ES|QL je query’s uitvoeren. Met Detection Rules die openbaar op GitHub staan. Entity analytics: 1 record per persoon met een risico score. Attack discovery: alerts in, attacks out. Automatic Migration vanuit andere systemen, zoals Splunk, QRadar en Sentinel.
Het tweede blok is Elastic Defend. Hierbij heb je een agent van Elastic op het endpoint. Die jouw data verstuurt, maar ook deze detectie uitvoert. Voorkomt malware, ransomware, memory threats, malicious behaviour en blokkeert vulnerabilities.
Het reageert door hosts te isoleren, processen te beeindigen, het beschermen van cloud workloads.
Het derde blok is de Workflows en agents die ingebouwd zijn. Waardoor je niet nog een SOAR hoeft aan te schaffen. Elastic workflows: durable, versioned, human gates. De agent builder + security skills. Automatic Import bouwt de integratie op basis van een voorbeeld log. Elastic Inference Service: Elastic-hosted modellen.
Er zijn meer dan 2.000 detectieregels op Github, gratis te gebruiken, aan te passen, uit te voeren.
Een perfecte AV-Comparatives score, de false positives waar Elastic niet over struikelt, een score van 100% op alle onderdelen. Respect!
Het beoordelen van een alert, als je dat handmatig doet, dan komt dit rond de 30 minuten om te bepalen of iets een bedreiging is of niet. Met agents is dat inmiddels teruggebracht naar 3 minuten.
Elastic zegt dat je voor je defensie AI moet gebruiken. Hackers gebruiken AI en doen dat inmiddels met zoveel succes en snelheid dat jij ook “jouw” snelheid moet verbeteren. We zien een aantal voorbeelden;
Maart 2025: AI out-phishes elite human red teams. Hoxhunt.com/blog/ai-powered-phishing-vs-humans
November 2025: First AI orchestrated espionage campaign. Anthropic.com/research/disrupting-AI-espionage
Mei 2026: AI is now standard attacker tooling. Verizon 2026 DBIB, AI research met Anthropic.
En iets wat achter het scherm wegvalt, de 700 agents die 4.5 dag een aanval op Hugging Face uitvoerden.
De SIEM is essentieel geworden. We zien links de actoren, menselijke en machinale identiteiten, code en CI, netwerk, SaaS en email. Rechts zien we de vragen die dit oproept: “wie is er actief, is dit een mens of een machine/bot”, “wat beweegt er door ons netwerk heen”, “welke devices zijn geraakt door de aanval van agents die uitgevoerd is”.
We krijgen per jaar wat Elastic de afgelopen jaren met AI gedaan heeft. In 2023 was het de AI assistent. In 2024 de Attack Discovery. In 2025 de Automatic Migration, de Inference Service. In 2026 is dat de Agent Builder met skills. De Elastic Workflows. De MCP app. En de automated alert analysis flow.
De overkoepelende vraag die vanuit de klanten bij Elastic werd gesteld was “zorg dat we op Alert Zero uitkomen”. De IT-ers onder ons kennen het wel. Alle meldingen die je overdag krijgt. Hier gaat iets fout. Hier is het aantal requests “ineens” hoger. Hier gaat iets 2 minuten fout en daarna weer goed. De ene keer laat je iets liggen, de andere keer duik je er in en kom je tot de conclusie dat het uur onderzoek weggegooid is, omdat het een “non issue” was.
Met Alert Zero is Elastic de tool die al die waarschuwingen doorloopt. De “waarschijnlijk false positives” eruit filtert. De mogelijk echte meldingen met attack discovery aan elkaar gaat relateren. Voer acties uit in playbooks. En kom met nieuwe of aangepaste regels die “de human in the loop” kan beoordelen.
Alert Zero is de nieuwe agentic layer van Elastic die dit mogelijk moet maken. Je hebt de Triage Watch – beoordeel elk alert, voordat het jou lastig valt, Detection Watch – fix de regel, niet de symptomen, Hunt Watch – ga actief op zoek, Forensic Watch – diep onderzoek op basis van bedreigingen en exploits.
Elke watch is een groep agents die hun specifieke taak hebben. Je kunt per watch instellen hoe de interactie met jou moet zijn. Manual: je krijgt suggesties, maar jij bepaalt elke stap. Assisted: de agents voeren het onderzoek uit. Het sluiten van de melding en de uit te voeren actie, dat moet door jou worden beoordeeld. Supervised: classes die jij geaccordeerd hebben kunnen alles zonder interruptie uitvoeren. Jij kunt na de tijd nog wel de “undo-actie” uitvoeren.
Hierna volgt de demo. We zien het dashboard in de browser van Alert Zero. Hier kun je dus zien of er acties op jou staan te wachten.
Ash laat ons zien dat Elastic “Model agnostic” is. Je kunt dus andere modellen gebruiken, Fable, Opus, Sonnet, Haiku, Gemini, GPT, Jina.
Elastic heeft voor security partnerships gesloten met OpenAI en NVIDIA.
Je krijgt “out of the box” Observability integrations.
Daarna komt op het grote scherm iconen van alle partijen die gebruik maken van Elastic. Dat zijn er een hele hoop. Ik zie Shopify, Github, OTTO en veel meer.
Daarna komt Ash nog met een primeur: Elastic gaat samenwerken met de Formule 1, en dan met AUDI. Kiek, da’s mien merk! De officiële bekendmaking zou donderdag 22 oktober gedaan worden, dus ik heb even gewacht met het delen van dit blog.
Het is inmiddels 10.50 uur.
Ik weet niet wie er nu op het podium komt, Lusha die iets gaat vertellen over B2B sales intelligence met Elasticsearch en AWS of Norion Bank die het over Elastic en Azure gaan hebben. Ik ga namelijk naar de grote zaal (net als een groot deel van de andere bezoekers), want ik kan wel een kop koffie gebruiken.
10.46 - 11.01 Two builders, one stage: what it takes to scale technology that lasts, Ben van der Burg
Rond 11.20 uur loop ik nog even naar de Effectenbeurszaal en zie Ash en Ben van der Burg op het podium zitten, ze stellen vragen aan elkaar, titel van deze sessie is “two builders, one stage: what it takes to scale technology that lasts”. Zo maak ik toch nog even het laatste deel van deze sessie mee.
Hierna loop ik naar de Graanbeurszaal 2. Deze zit naast de Graanbeurszaal 1, deze is gescheiden door een dunne wand/gordijnen, dus het is silent disco tijd: koptelefoon op om de spreker te horen. Dat werkt perfect, alleen op het moment dat in de andere zaal geapplaudisseerd wordt, hoor je dat er mensen in die zaal zitten, want voor de rest hoor je niets.
11.50 - 12.20 How TomTom turned security data into an AI advantage, Graanbeurszaal 2
Om 11.50 start Fernando Spettoli, director of Cybersecurity van TomTom zijn presentatie. In het verleden zijn keys gegenereerd om toegang te geven tot clouddiensten / data-bronnen van TomTom. 23 stuks. Nooit geroteerd (lees: inactief gemaakt en vervangen door andere keys). Op dag 1 van het incident worden deze keys in bulk vanaf een gehuurde server actief gemaakt. Hiermee kan degene die dat doet toegang krijgen tot 3 accounts.
Op de derde dag worden met een source-control token die voor een aannemer bedoeld is 559 private repositories gekloond. Omdat die “private” zijn, is in het verleden de (foutieve) aanname gedaan dat het veilig is: dus in deze code staan secrets. En die zijn nu dus in het bezit van een partij die deze gegevens niet mag hebben. Binnen 18 minuten heeft die partij toegang tot de 2e cloud van TomTom.
Op de 5e dag worden secrets uit een keyvault 2x gelezen. Vanaf een externe host. Daarna geen activiteit meer gezien.
Op de 11e dag voert TomTom een Attack-Discovery-Driven Threat Hunting model uit – en komen tot de ontdekking dat deze activiteiten plaatsgevonden hebben – dus “pas” na 11 dagen.
Hierna volgt even het intro wat voor bedrijf TomTom is. We kennen het “allemaal”, in 2025 had TomTom 555 miljoen dollar aan omzet, er werken rond de 3.000 medewerkers en in deze branch zijn ze rond de 30 jaar actief.
Samenwerking met verschillende bedrijven die auto’s bouwen, VW Groep, BMW, Renault, Hyundai. Actief in tech en platforms met Microsoft, Uber en Lyft. En actief in mobiliteit en analytics, met Michelin, ANWB.
Je denkt bij TomTom aan “het route-bedrijf, wat jou van A naar B brengt”, maar het is dus voornamelijk een “data bedrijf”. Al die gegevens, applicaties werken met data en dat moet beschermd worden.
Miljoenen bestuurders vertrouwen op de data. TomTom draait op 2 clouds, Azure en AWS. Duizenden developers op Github. En er is maar 1 klein team wat zich bezig houdt met data, automatisering en het aanleveren van data.
Allemaal tools/integraties die hun data loggen en zorgen voor een soort “spoor” van telemetrie. Maar dat heb je dus niet centraal beschikbaar, het is verspreid. Entra ID, Microsoft 365, Defender XDR, AWS CloudTrail, Azure Activity, CrowdStrike Falcon, Prisma Access, Github Enterprise, Windows – MacOS – Linux.
TomTom kwam door dit incident erachter dat het model wat ze hanteerden niet afdoende was. Ze konden per dag maximaal 250 GB aan data verwerken op basis van het gesloten contract. Beperkte automatisering, alleen bij echte incidenten kon je meer acties uitvoeren. En zoals genoemd, maar 1 team wat “alles moest doen”.
Conclusie was dat TomTom niet haar zichtbaarheid in eigendom had en ook niet de controle daarvan in eigen beheer had. Dit moest anders.
Daarom is de keuze gemaakt voor Elastic. Met AI kun je door Triage een concept laten genereren. Met Attack Discovery kun je op basis van alle verschillende signalen een samenvatting laten genereren. En met ES|QL kan een analyst op een goede manier dieper in de data duiken.
De boel draait serverless. Geen clusters, geen capaciteitplanning, geen weekenden waarin “het systeem geüpgraded” moet worden en de boel tijdelijk plat ligt.
En de ervaring met Elastic was uitstekend. Mensen met kennis, met een goed plan kwamen. Op basis van een POC een definitieve oplossing gebouwd werd. Waarbij bevindingen redelijk snel ook in de producten van Elastic verwerkt werden (Elastic heeft hier dus ook voordeel van, omdat ze met echte bevindingen goede fixes kunnen doorvoeren waardoor elke klant daar weer voordeel van heeft).
De huidige situatie is dat TomTom met Elastic per dag 1 Terabyte aan data kan opslaan, er een threat-model aan gekoppeld heeft. De automatisering zorgt voor detectie, een case, wat door Tines doorgezet wordt naar Jira/PagerDuty.
De regels voor detectie zijn nu “detection as code”, staan in GIT, het PR kun je valideren en met Continuous Integration wordt het automatisch uitgerold.
Door Triage kun je nu binnen seconden op elke case een uitspraak hebben of iets wel of niet meer aandacht verdient.
En met de infrastructuur zijn nu ook de beperkingen weg.
Doordat Elastic nu acties uitvoert krijgt het team het rustiger. In het laatste kwartaal zijn 107.485 low alert meldingen automatisch gesloten. Geen enkel item daarvan bleek later een “true positive” te zijn die toch beoordeeld had moeten worden.
De Threat-IP matches die elke dag binnenkomen zijn van 865 teruggebracht naar 40 stuks.
De a-typische inlogs vanaf Microsoft 365 die elke dag binnenkomen zijn van 430 teruggebracht naar 36.
En de sign-in alerts die elk kwartaal “piepen”, is teruggebracht van 43.000 naar 1.350 meldingen.
We zien hoe een bepaald beslissingspad wordt geautomatiseerd, in dit geval het inloggen op Entra. Er zijn een aantal stappen, waarbij bepaalde voorwaardes voldoende zijn om de melding automatisch te sluiten. Een “normaal account” waarbij niet succesvol ingelogd is – niet interessant. Een succesvolle inlog van een device/locatie waarbij meerdere keren succesvol ingelogd is? Ook dat moet goed zijn, want dan was het de eerste keer wel als een risico gedetecteerd.
81 procent van de “risky sign-ins” zijn mislukte pogingen. De aanvaller is nooit binnen geweest. Besteed er dan geen tijd aan.
12.25 - 12.55 Leveraging AlertZero for Continuous Threat Hunting, Graanbeurszaal 2
Ik kan blijven zitten, want hierna volgt de presentatie van Kseniia Ignatovych over AlertZero. Titel is “Leveraging AlertZero for Continuous Threat Hunting”. Zij is senior security productmanager bij Elastic.
In de ochtend hebben we voor het eerst het woord “AlertZero” gehoord. Dit is een groep agents die actief voor jou aan threat hunting doen.
We hadden al dat bekende zaken supersnel geblokkeerd kunnen worden. Maar met de huidige AI-aanvallen komen we meer in het tijdframe dat we aangevallen worden met zaken die “niet bekend zijn”.
De eerste lijn van verdediging is het endpoint. Met Elastic Defend kun je automatische bescherming uitvoeren, waarbij je niet als persoon handmatig aan de slag hoeft te gaan. Voorbeelden hiervan zijn dat malware actief wordt, een Machine Learning qualifier stopt het uitvoeren van de malware. Of acties die uitgevoerd worden, bijvoorbeeld het side-loaden van een corrupte DLL in een applicatie die wel vertrouwd wordt kan voorkomen worden doordat Defend de verdachte acties detecteert, bij de eerste actie – en niet dat wij na 2 dagen denken: waarom is deze pc ineens zo traag? Het derde blok is de memory injection en ransomware. Met memory threat protection en canary files wordt voordat je hele systeem overgenomen is en al je bestanden geëncrypt zijn de actie afgebroken.
Ondersteuning is hierbij voor Windows, macOS, Linux en K8s.
Ook hier wordt genoemd wat vaker terugkomt, Elastic heeft bij de AV – Comparitives EPR Test 2026 de hoogste score behaald. Bitdefender en VIPRE zitten hier net onder.
Met AlertZero zorg je dat de SOC bottleneck (je medewerkers/team(s) kunnen maar zoveel doen) een minder groot probleem wordt, omdat veel zaken nu geautomatiseerd uitgevoerd kunnen worden.
Door het voorkomen van acties zorg je dat de hoeveelheid “alarmen” die afgaan een stuk lager zijn. Je medewerkers/team(s) kunnen zich dus richten op zaken die er echt toe doen.
Door “hunting” wordt actief je data gevalideerd, waardoor een potentieel lek gevonden kan worden voordat het echt gebruikt/misbruikt worden. Van een reactief proces – iemand is binnen, naar een actief proces – voorkom dat iemand binnen komt.
Hierna is het tijd voor de lunch. Dat heeft Elastic ook altijd goed voor elkaar. Glaasjes met stukjes kip, met vis, pasta. Drie kwartier de tijd, vorige jaren ontstonden er nog wel eens rijen voor de stands waar je eten kon krijgen, maar dat gaat dit jaar allemaal goed.
Tijdens de lunch hebben bepaalde leveranciers nog wat presentaties. Ik besluit om een kijkje te nemen bij de presentatie van AWS.
Gonesh Shenoy heeft de presentatie met de titel “From Blank IDE to Working AI Agent in 10 minutes”. Gebouwd op basis van Spec-Driven development met Kiro, Elastic MCP, Amazon Bedrock AgentCore.
Je geeft aan Kiro de requirements, hierna krijg je een ontwerp, hierna de taken. Kiro kan de data ophalen via de Elastic MCP server. Via ES|SQL wordt de data opgevraagd, geen directe toegang tot indexen. Met Amazon Bedrock AgentCore heb je een Strands agent en Claude op een serverless runtime. Hier wordt de data via de AgentCore API opgevraagd. Elke call naar Elastic en het model wordt getraceerd door AgentCore Observability. Deze traces kunnen ook weer naar Elastic gestuurd worden.
Wat Gonesh gebouwd heeft is een React web app, hij gebruikt een FastAPI service (validatie van input, een 60-seconden budget). Zijn voorbeeld is voor een verzekeringsagent, zodat die kan bepalen of iets verzekerd kan worden. In Elastic staan 500 historische polissen, 784 claims, 20 steden in Amerika en 6 ISO classes.
14.20 - 14.50 The Bug That Slept for Years – Shell, Effectenbeurszaal
Om 14.20 uur zit ik weer in de Effectbeurszaal. De presentatie wordt gegeven door Andréi Gutiérrez van Shell. Hij geeft ons een versimpelde weergave van hoe het systeem, waar ze een probleem mee hadden, in elkaar zit.
Er is een start-up applicatie, die zorgt voor de provisioning, dus aanmaken, inrichten, opstarten van de omgeving.
Een vault, waarin op een veilige manier secrets opgeslagen worden.
Identity, voor authenticatie en authorizatie in de applicaties.
Een database. Een broker, die zorgt voor communicatie tussen services. En de clients, de back-end gebruikers die via de broker gebruik maken van de services.
We krijgen een grafisch overzicht te zien, waarbij we zien dat productie ineens rode gebieden bevat. Geheugen en aantal database-connecties schieten door het plafond.
We zien de start-up applicatie die eigenlijk continu in het rood staat. Maar dat is “bekend”. De start-up service geeft elke keer een exceptie na opstarten en wordt dan na verloop van tijd afgesloten. Wat niet erg is, want dat gebeurt pas op het moment dat alle initiële taken uitgevoerd zijn en deze applicatie niets meer hoeft te doen. We zien hier nog wel iets anders, daar kom ik later op terug.
Er ontstaat een chaotisch proces om te achterhalen wat ervoor zorgt dat regio’s down gaan. Begrijpelijk, als developer heb je dat ook als een productie-omgeving piept en kraakt, het net om een klant gaat waarbij de site zijn beetje 24-7 online moet zijn en ook goede reactietijden moet leveren: wat is de oorzaak?
In het geval van Shell worden er een aantal theorieën geopperd.
De geografische theorie: Europa en APAC gaat onderuit, Amerika draait nog.
De infrastructuur theorie: er is een nieuwe infrastructuurleverancier. Is hij/zij de bron van deze problemen?
De omgevingstheorie: waarom alleen productie en niet test, acceptatie? DDos, EDoS of REA?
Door een aantal dashboards op te tuigen konden theorieën geëlimineerd worden. De bron bleek 1 IP te zijn. Het ligt niet aan het netwerk/infrastructuur. Na een tijdje gaat ook de boel in Amerika down. En er wordt bepaald “waarom” de boel plat gaat, omdat het systeem “hongerig voor resources” is.
Per deployment is het 1 IP wat de bron is. Dat geeft focus, het ligt aan de Startup, Broker, Vault of Identity.
En zo komen we op het punt dat de Startup als schuldige aangewezen wordt. Het onderdeel wat altijd al fouten gaf. Die fouten die al jaren genegeerd werden. Wat op het backlog stond, geen prioriteit had. En waarbij we nu dus ineens zien… dat die service geen fouten meer geeft! – dit is dus het punt waar ik op terug zou komen.
Een nieuwe developer wil graag helpen, ziet deze bug, lage prio, lage impact en ziet dat de oplossing simpel is. Voert het uit en het lijkt een succes te zijn. Of toch niet?
Shell test de theorie: kill de start-up applicatie. De resources worden weer vrijgegeven. Dus de tijdelijke oplossing is om de applicatie na een x periode automatisch te killen. De permanente oplossing wordt later uitgerold, de database-connecties moeten met een Singleton pattern opgezet worden. Nu werd voor elke query, vraag een eigen db-connectie opgezet, niet vrijgegeven.
Naast die fix heeft het ook gezorgd dat er meer/beter gemonitord wordt op metrieken, zodat toekomstige fouten/problemen eerder gedetecteerd worden.
De lessen hiervan zijn dat je goed met je resources om moet gaan, dat het fixen van een bug er ook voor kan zorgen dat bepaalde architectuurfouten naar boven drijven waardoor een (groter) probleem ontstaat. En observability is essentieel: als je niet weet wat er allemaal speelt, dan kun je “het” ook niet oplossen.
14.55 - 15.25 Elastic Security Labs Threat Command, Graanbeurszaal 2
Om 14.55 uur zit ik weer in Graanbeurszaal 2, wederom Kseniia Ignatovych, ze geeft een presentatie over Elastic Security Labs Threat Command.
Vroeger stonden hackers op je firewall te beuken om binnen te komen. Omdat die deur steeds beter beveiligd is, worden sneaky andere methoden gezocht. Onder andere het “mee liften” op zaken die jij al binnen je infrastructuur vertrouwt. Doordat veel software, apps afhankelijkheden hebben van andere codebibliotheken, komt dat mee bij installatie. Maar als die afhankelijkheid gehackt is en er “malicious code” in mee komt, dan heb je een probleem.
Kseniia laat 2 voorbeelden zien, de Obsidian breach – REF6598 en de Axios breach.
Obsidian is een applicatie on notities te maken. Het is geen kladblok, het is een hele mooie tool. Maar je kunt er ook plugins mee uitvoeren. Handig, maar in dit geval niet veilig. Hier werd een RAT (Remote Access Tool) met AI ondersteuning jouw systeem binnengesmokkeld.
Axios is een javascript HTTP codebibliotheek die ongeveer 100 miljoen x per week wordt gedownload. Iemand die meewerkte aan dit project heeft een versie gemaakt waarbij ook een RAT “backdoor” in je installatie doorgevoerd werd.
Security Labs Threat Command bestaat uit ongeveer 30 security experts uit Amerika, EMEA en de Pacific.
Discover: researchers en threat hunters. Doorspitten van logs, telemetrie om mogelijke patronen, campagnes te vinden, voordat die ellende kunnen veroorzaken. Sinds 2019 meer dan 200 artikelen over gepubliceerd.
Analyze: via reverse-engineering de originele code uitspitten, zodat er detectie logica gebouwd kan worden die de malware kan herkennen. Meer dan 60 ontdekkingen.
Bescherming: deel de regels met de rest van de wereld, zet bescherming op endpoints.
De items die hier genoemd worden zijn de AXIOS npm supply-chain RAT, PHANTOMPULSE, TCLBanker, MimicRAT, BadIIS SEO poisoning.
In het validate deel worden in een sandbox zaken getest. Meer dan 10.000 voorbeelden worden elke maand getest.
We krijgen de stappen te zien hoe de hack van Obsidian (PHANTOMPULSE) in zijn werk ging. Waarbij elke stap uitgevoerd werd “zoals die stap uitgevoerd had moeten/mogen worden”. Via Social Media / LinkedIn / Telegram werd verzocht zaken uit te voeren, een paar plugins. Dat was een hider plugin (om zaken te verbergen, iets wat je als normale developer ook zou willen kunnen doen, maar hier werd het gebruikt om “slechte dingen” te verbergen) en een shell plugin, waarmee bepaalde powershell-acties uitgevoerd konden worden. Ook hier, als normale developer die iets wil bouwen voor Obsidian een legitieme actie, bijvoorbeeld om data uit je ERP op te kunnen halen. Maar ook hier werd dit dus gebruikt voor “slechte dingen”.
Aan de ene kant heb je de versie op Mac, die download een script en voert acties uit. De andere kant is de Windows versie, deze voert wat Powershell-acties uit om een executable binnen te halen die acties uitvoert. Ik zeg “binnenhalen”, dit wordt allemaal in het geheugen ingeladen – dus geen bestand op schijf die gedetecteerd kan worden. Op de Mac werd met de scriptingtools van de Mac de actie uitgevoerd en werd een start-up entry toegevoegd, zodat ook na een herstart zaken weer ingeladen werden.
De reverse engineering van Elastic laat heel veel commentaar en structuur zien – het lijkt dus AI gegenereerd. Ook het achterliggende dashboard ziet er AI-isch uit.
Elastic zag dat PHANTOMPULSE geen vaste home-server had. Instructies worden uit een online wallet opgevraagd (blockchain) – die niemand offline kan halen. Maar geen controle wie het bericht plaatst. Dus iedereen (ook Elastic) kan een bericht erop zetten en elke geïnfecteerde machine sturen naar een online locatie die jij maar wilt.
Omdat een notitie-app volgens Elastic geen scripts zou moeten kunnen uitvoeren heeft Elastic Defend de boel geblokkeerd voordat PHANTOMPULSE opgestart kon worden.
De uitleg van Axios. Dit zat in versie 1.14.1 en 0.30.4 (legacy) met een dependency plain-crypto-js. Beide versies zijn binnen 39 minuten online gezet, de online beschikbaarheid was rond de 3 uur.
Elastic heeft binnen het uur bij Github Security Advisory een waarschuwing ingediend.
Hoe kon Elastic dit detecteren?
Ze zeggen wel eens, toeval bestaat niet, maar in onze technologie-business komt dit nog wel eens voor. Een onderzoeken bij Elastic had namelijk net een soort proof of concept gebouwd waarmee je package verschillen (diffs) kon bekijken, zoals een analist dat doet.
Bij npm CouchDB_changes feed, nieuwe versies sinds de laatste epoch, gefilterd op basis van de top 15.000 packages. Bij PyPI changelog_since_serial() -> new-release events only, gefilterd op dezelfde lijst van 15.000 packages.
In een middag gebouwd. Getest op een package in die week. De maandagavond erop werd Axios gedetecteerd.
Met Elastic Defend krijg je meer dan 2.000 beschermingsregels. Elke 2 weken (zo ongeveer) worden aanvullingen geleverd, geen product updates e.d. nodig. Het werkt met de EDR die je al hebt, Crowdstrike, Microsoft Defender, SentinelOne. Wordt geleverd met onderzoekshandleidingen – dat scheelt jou onderzoekstijd. En de dekking is gericht op gedrag, het blijft dus werken als bestandsnamen, hashes en infrastructuur verandert.
Even een paar linkjes om dit verhaal compleet te maken:
Research: elastic.co/security-labs
Rules: github.com/elastic/detection-rules
Artifacts: github.com/elastic/protections-artifacts
Monitor: github.com/elastic/supply-chain-monitor
De samenvattende afsluiting:
- Aanvallers maken misbruik van je vertrouwen, niet door deuren in te trappen. Dus door op gedrag te monitoren heb je de monitor die deze acties zou moeten kunnen detecteren.
- Een ontdekking van een hack is niet het eindpunt, pas als de hack gedetecteerd kan worden, in een set van regels zit, dan pas is de case afgerond.
- Dat Elastic dit goed doet, is onafhankelijk vastgesteld, door hun 2e jaar op rij als beste bij AV Comparitives uit de bus te komen: 50 multistage aanvallen gestopt, geen enkele false alert.
- Onderzoek en bescherming wordt publiekelijk gedeeld – het doel is om de wereld een stukje veiliger te maken.
Hierna een korte pauze. Even een cappuccino, een klein hapje wat een soort saucijzenbroodje lijkt, maar mushroom (paddenstoel) bevat. Lekker. Want na al die sessies wordt je wel een beetje duf.
16.05 - 16.35 SIEM: How we scaled Elasticsearch on Kubernetes, Graanbeurszaal 2
Om 16.00 uur zit ik weer in de Graabeurszaal, Sudhindra Sukumara en Ricardo Guijt staan op het podium. Namens het CJIB presenteren ze “From log store to SIEM, how we scaled Elasticsearch on Kubernetes without losing sleep”.
Op het scherm krijgen we de slide waar we het CJIB van kennen. Het innen van boetes (7.570.861 in 2025), waarbij ongeveer driekwart daarvan voor snelheid is. Het CJIB voert echter ook incasso’s uit voor andere overheidsinstanties. E-Tol, CAK, DUO en nog een aantal organisaties.
In 2021 is de opdracht gegeven om de monitoring op orde te krijgen, de Monitoring Centre of Excellence.
Bij het onderzoek bleek dat een aantal zaken niet goed waren.
Als er ergens iets niet goed ging, dan kwam dat niet altijd in de monitoring naar voren. Niet altijd werd er een vervolg aan een bevinding gegeven door de verantwoordelijke teams. En omdat niet alle details beschikbaar zijn is soms niet te bepalen bij welk domein een bepaald probleem hoort.
Ricardo is eerst als enige gestart met dit project. Na het uitwerken van het ontwerp van MCoE is er een POC van APM gekomen. Gevolgd door een POC van DEM. Rond dat tijdstip werken er 3 mensen aan. Na de aankoop van de tooling, de implementatie komt het verzoek om SIEM capaciteiten hieraan toe te voegen (inmiddels werken er 6 mensen aan dit project).
Gestart met Elasticsearch en Kibana, dat verplaatsen naar Kubernetes, hier de Fleet en Elastic Agent komt uiteindelijk Security & SIEM erbij.
De agents kunnen ook gebruikt worden om de security-data door te sturen. Sudhindra en Ricardo waren eerst een beetje angstig of het systeem dat wel aan kon, maar het bleek dat dit geen probleem was.
De configuratie is verschillend in te stellen. Want zo is er de 30 dagen retentie van observability logs (3 dagen hot, 30 dagen cold storage), voor security logs is dat een ander verhaal. Hot staat het 3 dagen, 60 dagen cold en in de frozen state staat het nog voor een jaar. Dus moet er een incident onderzocht worden van een half jaar geleden, dan kan dat.
Het team is gegroeid van 3 naar 8 medewerkers, van 3 clusternodes naar 101, data die per dag verwerkt wordt ligt rond de 1.6 TB (dat was 120 GB), 3.2 biljoen documenten die per dag verwerkt worden, in de logstore staat nu 140+ TB aan doorzoekbare informatie.
In het landschap staan nu meer dan 3.200 agents hun data te versturen, meer dan 70 teams (DevOps, platform en security), 300 miljoen query’s per dag, meer dan 700 detectieregels (waarvan meer dan 75 zelf gebouwd), rond de 99.9% beschikbaarheid (routine door frequente updates).
De samenvatting hiervan is:
- Bouw op een platform wat je al vertrouwt, in dit geval de Elastic stack en Kubernetes.
- Gebruik IaC (infrastructure as code), maar bekijk in elke situatie of het daar echt de manier is die gebruikt zou moeten worden, of dat dit een uitzondering is. Dus code waar het werkt, maar UI waar dat niet het geval is. Dat horen we ook in deze presentatie, er is ergens iets dat medewerkers gebruik van bepaalde zaken maken – die medewerkers zijn geen developers. Dus door in de GUI zaken te kunnen manipuleren, is de acceptatie en het gebruik belangrijker dan dat je alles in code wilt doen.
- Hou je aan de standaarden. ECS, intregraties die je standaard (gratis) bijgeleverd krijgt, de Elastic Agent.
- Bouw je eigen controles en beschermingsmaatregelen op punten waar de tools dat niet meer voor je kunnen doen.
We krijgen nog een voorbeeld. Zo werd iets gedetecteerd. Er was een tool “nolock.exe”, waarmee je scherm niet automatisch op schermbeveiliging sprong – want medewerkers vonden dat vervelend. Door de SIEM werd dit gedetecteerd en is dit met de medewerkers besproken.
16.40 - 17.10 The Agentic Endpoint: Modernizing DFIR, SOC Operations, Graanbeurszaal 2
Rond 16.40 uur wordt de laatste presentatie gegeven door Roxana Gheorghe, senior productmanager bij Elastic. Titel is “The agentic endpoint: modernizing DFIR, SOC operations and threat hunting”.
In de eerste sheet zien we wat er speelt, namelijk het dilemma van snelheid ten opzichte van context. Je hebt een incident, wilt dit snel oplossen, maar wat is de context?
Eerste stap is het alarm wat binnen komt, wat volgt is de Host triage (wat is er aan de hand), daarna de response en uiteindelijk de Post-mortem.
Uitdagingen hierbij zijn dat veel “artifacts” verspreid zijn over teveel tools. Duik je in de logging van de webserver, kijk je in de logging van de SQL-server, ga je in Zabbix kijken, ga je in je fouten-database kijken? Dat context-switchen zorgt ook dat je even je focus kwijt raakt, want je moet inloggen op andere systemen, zaken opstarten. En als alles opgelost is – vaak wordt er geen verslag geschreven, want het team moet door naar het volgende incident.
Dan volgt de uitleg waarom Elastic hier de oplossing kan zijn.
Met hot/warm/cold data tiering kun je de kosten beheersbaar houden, maar toch je volledige dataset query-en. Native vector search, VectorDB en ETL pipelines die in hetzelfde platform als je logs zitten. ECS (Elastic Common Scheme) zorgt ervoor dat proces.executable overal hetzelfde is. Soms heb je namelijk systemen waar zaken net iets anders genoemd worden, dan moet je na het doornemen van het resultaat je zelf nog bepaalde zaken tegen elkaar wegstrepen omdat ze hetzelfde zijn, maar met een andere naam aangegeven worden – dat lost Elastic voor je op.
Dit is ook noodzakelijk, omdat AI moet weten dat iets “hetzelfde is”.
DFIR staat voor Digital Forensics and Incident Response. Dat heeft Elastic centraal gebouwd. Met Osquery wordt het OS behandeld als een database. Query processen, sockets, gebruikers, browserhistorie, MFT, shimcache en prefetch.
Live respons met memory dumps.
Je kunt een host isoleren, zodat die geen andere hosts “infecteert”. Maar je kunt nog wel steeds query’s uitvoeren op die host. Elastic Defend knijpt de netwerktoegang, maar osquery blijft data verzamelen. En dat moet ook. Want als een “malicious script” hierna wat dingen gaat doen en het voor elkaar krijgt dat Elastic Defend de netwerktoegang weer opent, dan wil je dat wel weten.
Je krijgt een hele codebibliotheek voor forensisch onderzoek aangeleverd.
Roxana laat ons een demo zien, waarbij ransomware gedetecteerd is.
Ze deelt ook een aantal resources, waarmee je zelf aan de slag kunt gaan:
De demo zoals ze die liet zien: www.elastic.co/security-labs/blog/dfir-osquery-elastic-security
Elastic Security Labs: www.elastic.co/security-labs
Forensic Osquery packs: www.elastic.co/docs/solutions/security/investigate/osquery
Attack discovery documentation: www.elastic.co/docs/solutions/security