TL;DR (too long, don’t read)
• Update je Elastic producten naar 9.2.0 zodat je weer bij bent.
• Met BBQ (Better Bit Quantization) heb je betere compressie, scheelt veel diskspace!
• Het A-CORN algoritme is 5x sneller bij filteren vectoren.
• Vectors worden uit _source verwijderd, wat 63% schijfruimte scheelt.
• DiskBBQ zorgt voor minder RAM-belasting.
• Elastic werkt nu samen met JINA (https://jina.ai)
• Elastic Agent Builder, AI in Elastic, ziet er cool uit.
• Workflows in Elastic, niet alleen monitoring, maar ook preventief acties uitvoeren.
• Zaken die alleen in de cloud beschikbaar waren, komen beschikbaar via Cloud Connected.
• Je kunt nu 28 gratis modules doorlopen op www.elastic.co/training
• Problemen met inlezen van je IIS Logs? Met Streams zou dat simpel opgelost moeten worden.
• Via Github kun je de detection-rules zien: github.com/elastic/detection-rules.
• Elastic heeft nu ook een bug-bounty programma voor die detection-rules: www.elastic.co/security-labs/behavior-rule-bug-bounty
• Interessante sessie van KPN door Jesse Helder
• De slides kun je hier bekijken!
• CEO Ash Kulkarni doet het ook altijd prima op het podium, dus als je tijd hebt, lees dan toch maar even het volledige verslag hieronder door 😊
Elastic houdt ieder jaar hun evenement, ElasticON, in de Beurs van Berlage in Amsterdam. Ik ben daar in 2022 en 2023 geweest.
ElasticON is gratis te bezoeken, Elastic is groot supporter van open-source.
Op een bepaald punt zijn er wel commerciële activiteiten gestart, er waren klanten die daar blij mee waren, juist omdat de producten van Elastic “bedrijfskritisch” zijn en ze hier graag een betaald ondersteuningscontract voor wilden tekenen. Op het moment dat je problemen hebt, ben je niet afhankelijk van vrijwilligers die het oplossen, maar kun je contact opnemen en wordt het voor je gefixt. En Elastic zal ook geld moeten verdienen, anders kun je geen bedrijf runnen.
Ik ben de afgelopen jaren alleen maar “gebruiker” van hun producten geweest, Kibana voor het makkelijk kunnen filteren in IIS-logs (de site wordt traag: je ziet een dikke spike qua verkeer uit Azië wat de oorzaak is) en APM: wat gebeurt er allemaal in code, zijn al die database-query’s echt nodig?
Ik rij via de Afsluitdijk, omdat ik op dinsdag vanuit AFAS Live via de Afsluitdijk naar huis terug gereden ben, wist ik dat er nog steeds wat onderhoud gepleegd wordt en de snelheid dus zo nu en dan wordt afgeremd. Van eerdere ritjes wist ik nog dat het rond Purmerend altijd ophoopt qua verkeer. En als je bij Amsterdam rijdt, daar is het sowieso druk. Dus 5.00 uur opstaan, 6.15 uur rij ik in de auto richting Amsterdam.
Bij Purmerend is het inderdaad weer druk, maar rond 8.10 uur staat mijn auto in parkeergarage Q-Park Nieuwendijk. Altijd wat krap qua plekken, dus even een goede plek uitgezocht, zodat ik aan het eind van de middag redelijk simpel weer wegrijden kan.
Via wat steegjes naar het Damrak, bij de Mc Donalds een cappuccino, mensen kijken. Rond 8.40 uur loop ik naar de Beurs van Berlage, waarbij ik eerst nog even bij “de beurs” kijk (ik ben vaker over het Damrak gelopen, maar had daar nog nooit gekeken) en heb ook even een foto gemaakt van de stier die voor dit pand staat.
Jeroen Berckenkamp, de vice-president voor Elastic in Nederland heet ons welkom. Daarna start het programma.
Forge the Future: What’s New, What’s Next
CEO Ash Kulkarni komt op het podium. De term “AI” valt, want inmiddels wordt AI “overal” gebruikt. Er zijn verschillende aspecten. Zo heb je de “ondersteunende AI”, de assistent, co-pilot, die jou als gebruiker/developer helpt om vraagstukken op te lossen. Of het proces waarbij AI in de lead is en waarbij mensen de laatste schakel zijn, reviewen of de conclusies en voorgestelde acties correct zijn en uitgevoerd kunnen worden.
Elastic is erop gebouwd om het AI tijdperk te ondersteunen. Want Elastic werkte altijd al met “big data” en gaf jou de mogelijkheid om door de bomen het bos te zien. Met AI erbij kan dat het nog een stuk inzichtelijker/beter werkbaar maken.
We krijgen de term “Context Engineering met Elastic Search en AI”. In het Elastic Platform heb je Ingestion (lever je data aan), Processing (verwerken van die data), Storage (opslag), Search (zoeken), AI en ML (kunstmatige intelligent, machine learning), visualisatie en nu ook (dit is volgens mij nieuw) AI agents en workflows.
Je hebt de VectorDB voor opslag, de hybride zoekmachine, MCP tools (dankzij mijn collega Jeroen Smink was die term voor mij niet meer onbekend, een soort API zodat AI ook toegang heeft), agents en LLM observabiilty.
Hierna de uitspraak dat Elastic Search en AI “de beste oplossing voor context engineering is”, omdat opslag en zoeken efficiënt uitgevoerd wordt, het meest relevante resultaat aangeleverd wordt en omdat je het met elke tool kunt uitvoeren.
Om dat te kunnen staven zijn er nieuwe zaken te melden. Want je krijgt natuurlijk “steeds meer data” en zoals je vroeger “een snellere pc” kocht om met je programma’s te kunnen werken, zo is ook de onderliggende structuur van Elastic aangepast om goed met diskruimte om te kunnen gaan en ook snel te kunnen blijven zoeken.
Zo is er nu BBQ (Better Binary Quantization). Hiermee wordt je data ongeveer 32x kleiner door slimmere compressie. Ook scheelt dit 95% aan geheugen en CPU verbruik. Ook interessant voor de mensen die zich druk maken over “sustainability”. De ranking is beter bij 9/10 datasets dan float32. BBQ staat nu trouwens standaard aan, dus je maakt meteen gebruik van deze verbeteringen.
Er wordt nu gebruik gemaakt van het ACORN algoritme. Dit is 5x sneller dan het filteren op vector query’s.
Uit _source worden de vectors verwijderd. Dit scheelt 63% in opslag. En het indexeren is hierdoor 40% sneller.
En je hebt nog DiskBBQ, hierdoor worden de requirements voor RAM lager (dus met een iets minder state-of-the-art machine kun je nu ook goede performance halen) en je hebt 3 tot 5 snellere indexering ten opzichte van HNSW BBQ.
Elastic werkt samen met Jina AI om nog beter te worden.
Ook met alle tools “zijn we er nog niet”. Want zoals Ash zegt, je kunt data filteren, groeperen, maar uiteindelijk moet er iets mee gebeuren.
Er is nu Elastic Agent Builder. Je kunt je eigen agent maken die met jouw Elastic data werkt. Je kunt onder andere gebruik maken van Elastic MCP tools om de antwoorden relevant te maken.
James Spiteri, directeur product-management bij Elastic laat zien wat je met de Elastic Agent kan doen. Hij laat het voorbeeld zien van iemand die een afspraak met een klant heeft, daarbij de financiële gegevens snel kan opvragen en ook het type belegger wat deze klant is.
Ash laat zien dat Elastic zich aan open standaarden houdt. Zo werkt Elastic met OpenTelemetry, heeft hier Elastic Distributions of OpenTelemetry (EDOT) voor gemaakt en dat ook weer terug geleverd aan de community.
Het volgende deel gaat over de AI powered SOC met Elastic Security. SOC staat trouwens voor Security Operations Centre. Elastic heeft voor 2025 weer een Global Threat Report uitgewerkt, is hier online te vinden.
De bevindingen zijn:
- In 32% van de gevallen wordt nadat malware op Windows geïnstalleerd is meteen “online” de rest van de malware gedownload om het systeem te ontregelen.
- Rond de 60% van de aanvallen richten zich op 3 doelen: initiële toegang, zorgen dat de malware actief blijft en vervolgens toegang krijgen tot inloggegevens.
- Elastic ziet een 15% toename in “algemene aanvallen”, die waarschijnlijk met AI opgebouwd zijn (oftewel, met AI is cybercrime “minder moeilijk” te plegen)
- 1 van de 8 malware-voorbeelden waren er op uit om browserdata te stelen.
Het Elastic-platform biedt de mogelijkheid om het AI-ondersteunde SOC van jouw organisatie te worden.
Ash licht dat toe, Elastic heeft een datastore die geoptimaliseerd is voor “threat hunting”, heeft de AI tools om te detecteren en te onderzoeken en heeft nu workflow automatisering, waardoor je dus ook bescherming en herstel kunt bieden.
Het werd hier al genoemd, Elastic Workflows. Na alle detectie en samenvattingen zullen er ook acties uitgevoerd moeten worden. En dat kan nu hiermee.
We krijgen een demo. Je ziet dat er 8 bevindingen zijn. Daar kun je zelf in duiken. Maar met Attack discovery kun je dat laten samenvatten, zo zien we dat er een Multi-stage Sodinokibi Ransomware Attack gaande is. Er kan automatisch een case aangemaakt worden. Voor dit issue kan automatisch een Slack-kanaal aangemaakt worden, de persoon die “dienst” heeft wordt automatisch toegevoegd en de samenvatting van alle bevindingen kun je daar ook meteen in delen. Voorbeeld wat Ash geeft is dat je eerst een lijst met 1.000 onderdelen hebt, maar na de filtering houdt je er “nog” maar 9 over.
We zien een voorbeeld van een query waarin gevraagd wordt “kun je de top 10 van processen die door administrator uitgevoerd worden laten zien”. In die lijst zien we bekende zaken, maar ook Q3C7N1V8.exe. Je kunt meteen de vraag stellen “wat is dat voor programma”? We krijgen als resultaat dat dit een Trojan is, met bijbehorende informatie. In de demo is een eigen type agent gebruikt, namelijk de “Hunting Agent”. Met bijvoorbeeld de VirusTotal integratie kun je zaken laten scannen.
Je hebt verschillende implementaties van Elastic. In Elastic Cloud (of in een andere cloud), maar ook “on-premise”. Als je dat hebt, dan mis je bepaalde cloud-onderdelen, zoals AutoOps. Maar.. daar is nu een nieuwe dienst voor. Je kunt je data “on-prem” hebben, maar met Cloud Connected kun je meta-data naar de cloud sturen en alsnog bepaalde acties die anders niet beschikbaar waren nu wel aan je werkset toevoegen.
Elastic Cloud Serverless is beschikbaar bij AWS, Google Cloud en Microsoft Azure. Is beschikbaar in 20+ regio’s over de wereld. Bij zulke plaatjes zie je altijd lege plekken in Zuid Amerika en Afrika.
En als je meer wilt weten/leren over Elastic, dan zijn er nu 28 gratis modules te volgen.
Nog wat weetjes, Amsterdam bestaat 750 jaar, maar Elky (de mascotte van Elastic) bestaat 15 jaar.
Klanten van Elastic zijn onder andere het ministerie van Defensie, die bezig zijn geweest met een sharepoint-koppeling en dat ook weer terug geleverd hebben aan de community. KPN gebruikt Elastic om klanten en hun zelf te beschermen.
ElasticON wordt wereldwijd gehouden, in totaal in 12 steden.
Bij een LLM wordt Rainbow Sprinkles genoemd (maar online kan ik daar niets over vinden).
Ik zie bij de producten Nagios genoemd worden, iets wat in het verleden bij een oud werkgever van mij gebruikt werd.
Met streams kun je logs beter inlezen (de verschillende velden eruit filteren). Daarbij wordt de grok processor gebruikt, dit zit in versie 9.2.
Iets wat we al wisten, als een security-issue gevonden wordt, wordt steeds sneller daar misbruik van gemaakt, het probleem met Log4J kon even duren om opgelost te worden, maar zou dat nu weer optreden, dan moet je al bijna binnen 5 minuten een fix daarvoor kunnen doorvoeren..
10.00 – 10.30 PAUZE
We hebben een half uurtje pauze. Even een bakje, daarna weer terug naar de zaal voor de volgende sessies.
Chat van Ash met Steven Schuurman
Er staan 2 krukken op het toneel, Ash interviewt Steven Schuurman, oud CEO van Elastic. Elastic is in het verleden door hem en Shay Banon opgericht. Op Wikipedia wordt ook nog Simon Willnauer genoemd. Ik kende Steven niet, dus hoewel deze sessie niet technisch is, is het toch interessant om te horen hoe de organisatie ontstaan is. Steven hoeft zich niet meer druk te maken over geld, als ik Wikipedia mag geloven.
Inmiddels heeft Elastic rond de 4.000 werknemers en 1.7 biljoen omzet. Er zouden bepaalde regels gelden (betrekking op open-source? ) die in de broncode staan (zouden er nu 6 zijn?). Kijken of ik dat nog kan vinden.
Michael Rambold, chief technologist bij AWS
Zijn praatje gaat over hoe AWS en Elastic met generatieve AI kunnen werken. Deze sessie was voor mij niet zo interessant.
Chat van Ash met Dimitri van Zantvliet
Deze sessie was wel interessant. Dimitri is CISO van de Nederlandse Spoorwegen. Ze waren gisteren (29 oktober 2025, verkiezingsdag) alert op verstoringen van hun systemen. Ze zijn 2 jaar geleden al eens gehackt (of er werden pogingen gedaan). Ten tijde van de NAVO-top in Den Haag was er ook sprake van extra alertheid. De hele dag leek het rustig te blijven, maar net toen de medewerkers naar huis zouden gaan, het was rond 17.00 uur, viel de DNS van Microsoft uit. Om 16.57 uur was de NS-app niet meer te gebruiken. Ook medewerkers van de NS konden hun eigen apps ook niet meer gebruiken. En dan wordt het kritisch. Rond 19.00 uur is de beslissing genomen en de actie uitgevoerd om zelf de DNS in beheer te nemen. Daarbij zit je met TLS e.d., maar hiermee was de dag gered. Als dit namelijk niet gelukt was, dan was het besluit genomen om te stoppen met het laten rijden van de treinen. Vorige week was AWS de klos, bij TRES zien we dat RTR de laatste tijd problemen heeft, dus het lijkt een collectief probleem te zijn wat steeds vaker voorkomt.
Dimitri is 35 jaar geleden in de IT gestart, door PLC’s te programmeren. De inventaris van de NS is uitgebreid, zo heb je 60 jaar oude treinen met hun automatisering, maar ook Kubernetes-systemen, neurale netwerken om onderhoud te voorspellen. Zo draait er al heel lang een soort “AI” binnen de treinen, dat zit in een afgeschermde box, dat kan niet communiceren met de cloud, want dat zou teveel kosten.
Ash vraagt hoe het zit met bijvoorbeeld social engineering, waarbij je dus alert moet blijven op phisingmails. Dimitri reageert hierop met “hoe kan het, dat die mails nog steeds door onze filters heen glippen?”. En inderdaad, dat is natuurlijk ook zo. Je zou verwachten dat met AI je al een soort voorselectie zou kunnen doen van mails om die eruit te halen. De NS heeft een aantal jaren geleden een datalek gehad, dat kwam door een leverancier. Mensen die bij de NS aan de slag willen, daarbij wordt natuurlijk gekeken naar certificeringen, CISM, CEA, maar ook naar motivatie en “learning by life”.
Architecting the SOC of the future: Overcome data deluge and hidden threats
Deze presentatie wordt gegeven door Mike Nichols, VP, Product Management / Security Product Lead Elastic. Hij was eigenaar van Endgame, dat bedrijf is overgenomen door Elastic. Mike begint met een aantal slides met getallen, daar hou ik wel van;
- In 16% van de “lekken” is vijandige AI ingezet
- Grootste deel daarvan zit in “social engineering”, 37% voor zulke overtuigende phishing mails dat iedereen erin zou tuinen en 35% voor deepfake impersonificatie.
- Schaduw AI als een groot intern risico, de medewerker die met ChatGPT werkt en daar ook de security-tokens in deelt. De bijdrage qua datalekken is 20%. Deze incidenten kosten ook nog eens meer geld, 670.000 dollar bovenop de kosten van de lek.
- Grote oorzaak is gebrek aan “bestuur”. 97% van de AI gerelateerde lekken traden op in organisaties die geen goede AI toegangscontroles hadden en/of geen formele regels hiervoor opgesteld hadden.
Op de volgende slide toont Mike de case van Anthropic, die het LLM Claude heeft gemaakt. Ze zijn op een situatie gestuit waar Claude werd “misbruikt” om niet legitieme acties uit te voeren. Waarbij deze zelf mocht bepalen welke data “het meest waardevolle zou zijn”. Even gezocht, het artikel kun je hier nalezen.
En ze hebben een rapport hierover uitgebracht (PDF).
Met deze interne en externe bedreigingen door AI is de conclusie van Mike dat we ons niet druk moeten maken over AI rechten/permissies, maar we moeten ons druk maken over AI beveiliging.
We krijgen een overzicht van Elastic Defend. Daar zien we verschillende soorten preventie, “malicious behaviour”, “memory threat”, “ransomware”, “malware” en wat andere zaken zoals endpoint visibility, live instrumentation en endpoint response.
Op de volgende slide zien we verschillende beschermingszaken, die allen voor Windows werken, de meeste onderdelen werken ook op Linux, macOS en Kubernetes.
Elastic heeft op Github hun “open detection rules” staan. Dat zijn er meer dan 1.600. Bij een eerdere editie van Elastic werd dit ook al genoemd, zelf ook nog eens kijken of we daar wat mee kunnen doen. De repository is hier te vinden (en de regels staan in de rules map).
Security is ook een community-ding bij Elastic, dus je hebt de bovenstaande repo, er is een Slack-kanaal (700+ dagelijks actieve leden) en discussieforums met 3000+ dagelijkse actieve deelnemers.
Ook meldt Mike dat er een bug bounty programma is voor detection rules. Bij het zoeken kom ik uit op dit artikel, daar wordt verwezen naar de pagina op hackerone met meer uitleg.
Explorations in ESQL
Volgende spreker is Jesse Helder van KPN. Een senior SOC analist. Monitoring bij KPN is uitdagend, veel verschillend materiaal, verschillende generaties. Zowel “on premise” als “in de cloud”.
Leveranciers die hun producten als “eigendom” beschouwen, dus monitoring e.d. (open standaarden) niet ondersteunen, waardoor monitoring moeilijk/moeilijker wordt. KPN zit natuurlijk met Nederlandse wetten betreffende de veiligheid van telecommunicatie en er zijn compliance regels die vanuit de Europese Unie gelden voor KPN.
We zien vervolgens een soort weergave van hoe KPN dit ingesteld heeft. Via gedrag, logs en verkeer zaken monitoren, via tools zoals End Point Protection, Syslog, Event Log, Audit Log, Radius, IDS, Netflow deze data naar de Event Bus sturen, die het beschikbaar maakt voor SIEM, Analytics, Forensics (al deze 3 items staan aangegeven als Elastic), wat samengevoegd KPN SOC de data geeft die ze nodig hebben.
Data komt vanuit het Linux syslog, Linux auditd, Windows events, Firewall logs, Radius Logs, TACACS logs en nog veel meer locaties. Dat levert ongeveer 40.000.000.000 logs per dag op, ongeveer 32 TB per dag. Via pipelines wordt data verzameld en verwerkt. KPN heeft ongeveer 460 SIEM regels die de validatie doen.
Wat Jesse daarna doet vind ik helemaal top, hij geeft namelijk een paar overzichten van ESQL statements.
- DNS beaconing, daarmee zie je dat bepaalde software een soort “phone home” actie uitvoert. Malware, maar ook “normale applicaties” zie je dat doen.
- Zo kunnen we zien hoe KPN monitort op alle USER-directories in Windows. En als daar “ineens” een executable staat te draaien onder de systeem-user op het systeem, dan is het een grote kans dat het malware is. Het Red Team (wat voor testen juist probeert binnen te dringen in de eigen systemen) vond deze regel erg irritant, want dit heeft veel van hun acties kunnen voorkomen.
- Ook zien we iets met timing. Als er een nieuwe user is, die maar 5 minuten actief is, dat is verdacht.
- En we zien een soort join waarmee Jesse kon valideren dat een bepaald signaal niet een “false positive” was. Als een bepaalde actie werd uitgevoerd, dan begonnen alarmen te klinken. Maar door die bepaalde actie als een soort “exclude” in de query te plaatsen krijgt hij alleen nog maar een alarm als er echt wat aan de hand is.
12.25 – 13.30 LUNCH
Ook met de lunch heeft Elastic het altijd prima voor elkaar. Er komen flink wat mensen uit de zalen die wat willen eten. Op meerdere plaatsen, wat glaasjes met stukjes kip, een stukje vis of wat anders. Het personeel van de Beurs van Berlage die regelmatig de boel aanvult. Top!
The road towards enterprise observability at TVH
Een Belgische spreker, Thibaut Vandenbussche werkte vroeger bij Elastic, nu een jaar bij TVH, de onderdelenspecialist, dus heb je zaken nodig voor je tractor, vorkheftruck, hoogwerker, dan is dit het bedrijf waar je moet zijn.
Meer dan 5.000 werknemers, meer dan 9.000 leveranciers, actief in meer dan 170 landen, meer dan 82.000 klanten, ik meende rond de 90 distributiepunten. Een heel stuk warehousing dus. Orders, facturen, opslag magazijn, uitgifte. Allemaal zaken die inzichtelijk moeten zijn. Tot 2017 werkte dat allemaal met een eigen ERP systeem, waarbij iedereen zijn eigen monitoring en logging heeft. En kennis vaak bij “die ene vaste werknemer” zit. Tussen 2017 en 2021 worden acties uitgevoerd op dat ERP systeem om real-time metrieken en logging inzichtelijk te maken, en nog wat zaken voor de warehouses. Tussen 2021 en 2025 komen er e-commerceplatformen bij en wordt “traces” op Elastic Cloud geïntroduceerd. Na 2025 moet er een “observability platform” komen, de combinatie van business en IT om problemen te voorkomen of om ze in ieder geval snel op te lossen.
Thibaut geeft het voorbeeld van een Canadees warehouse. Het was al laat, (daar was het vroeg door het tijdverschil), niets werkte daar meer. Ook de handhelds niet. Iedereen ging daar bellen en in de eigen systemen zoeken: kun je zien wat er aan de hand is? Na 2 uren geen oplossing werd Thibaut gebeld: kun jij een oorzaak zien? Binnen 2 minuten had Thibaut het gevonden, een bepaalde routeringsregel was verwijderd. Dat was ook zichtbaar, maar het was niet zichtbaar dat dit een “essentieel onderdeel van het bedrijf” was.
Elke dag gaat er ongeveer 2.5 TB over de lijn. TVH is overgegaan naar een Enterprise licentie. Dat kost wat meer, maar die licentie biedt de mogelijkheid om je data in “frozen state” te plaatsen. Je hebt de data nog, maar het is niet direct opvraagbaar. Voor oude data is dat vaak goed genoeg. Daarmee kon dan weer bespaard worden op data in de “hot state”, waardoor er toch bespaard kon worden.
Semantics and scale: Elasticsearch vector database enhancements
Sander Philipse, de team lead van de Search afdeling van Elastic geeft deze presentatie. Hij legt eerst nog even uit wat een “vector database” is.
Heb je in normale tabel alleen rijen en kolommen, met vectoren kun je met allemaal extra dimensies werken, waardoor je veel betere resultaten krijgt.
Vervolgens naar de vooruitgang bij Elastic. Eerst had je “alleen tekst en metadata”. Vervolgens had je “semantic search”, waarbij ook de intentie van de vraag wordt begrepen, ook eigen type vectoren ingezet kunnen worden. Het vervolg hierop is de hybride implementatie. Met verschillende methoden zoeken (oa. ESQL). En nog een kopje “managed multi-modal”, waaronder tekst en afbeelding in een vector geplaatst worden, tekst, audio en video in een vector geplaatst worden en meer. Maar bij deze staat “future”, waarbij de toekomst volgens mij niet heel ver meer is.
De Elastic Inference Service (EIS), een managed service voor LLM’s. Je betaalt per token. Beschikbaar op Elastic Cloud, dat is zowel hosted als serverless (serverless is recent toegevoegd). Als je “on-prem” werkt, dan kan dit later via de Cloud Connected mode (maar nu nog niet).
Better Binary Quantization (BBQ) was ook al bij Ash ter sprake gekomen. Elastic heeft dit gedoneerd aan Apache Lucene, dus waarschijnlijk gaan andere producten hier ook hun voordeel van hebben. Hiermee is minder geheugen nodig bij vector zoekacties en bij gelijksoortige data zorgt het voor een sneller resultaat.
A-CORN wordt gebruikt om in “graph zoeken” de aantal kandidaten in te perken waardoor er sneller resultaten teruggegeven kunnen worden.
Door vectors uit je _source data te verwijderen (wordt in versie 9.2.0 automatisch gedaan) heb je minder schijfruimte nodig en wordt je snapshot-grootte ook een stuk kleiner. We zien een voorbeeld van een dataset die eerst 52.3 GB groot is en na deze actie 19.3 GB
Disk-BBQ (ook beschikbaar in 9.2.0) zorgt dat data beter geordend wordt, waardoor er sequentiële IO acties gedaan kunnen worden en er geen “random acties” uitgevoerd hoeven worden. Het maakt HNSW (graph) indexing af.
We zien vervolgens grafieken van verbeteringen bij Elastic. Zo is vectorsearch van 440 naar 680 gegaan, de boolean query van 110 naar 185, benchmarking ten opzichte van de concurrentie.
In de laatste slide wordt verwezen naar de site en de Github-locatie.
From SLO breach to root cause: AI for modern observability
Panagiotis Moustafellos, een engineer bij Elastic, geeft de volgende presentatie. Wat zijn de uitdagingen met AI, welke problemen kunnen wel (en welke niet) met AI opgelost worden, onderzoek naar een incident en het oplossen daarvan. De analyse van de diagnostistiek en het uitval. SLO Health en de on-call handover. En zijn oproep om vandaag je AI assistent aan te zetten.
Panagiotis geeft het voorbeeld van Elastic zelf. Na een “reguliere update” die op de andere systemen probleemloos was doorgevoerd, ging het fout. Veel spikes. Dat was volgens mij rond 15.00 uur. Eerst had 30% er last van, maar omdat de oorzaak niet gevonden kon worden is uiteindelijk de beslissing genomen om alles offline te halen. Dus nu is 100% van je klanten getroffen. Rond 19.00 uur leek alles weer goed en werden langzaam maar zeker zaken weer opgestart. Tot 21.00 uur, de boel gaat weer bijna down. In alle uren heeft Kibana een soort backlog opgebouwd wat nu allemaal nog uitgevoerd wordt en het eigen systeem bijna onderuit haalt. Dit was een incident in 2019, er was nog geen AI, dus het was veel zoeken en proberen.
Op dit blog van Elastic kun je nalezen wat er gebeurde en wat er aan de hand was.
Panagiotis toont ons de pijnpunten van een SRE (Site Reliability Engineer). Lijkt wel op DevOps.
Het onderzoeken en oplossen van het probleem. Het zoeken en beoordelen is vaak traag en wordt verstoord door “ruis”.
De analyse van de diagnostische gegevens en fouten. Door al die logregels spitten, om maar een eerste hypothese te vormen.
De overdracht naar je collega’s, doorgeven wat je gedaan hebt, wat er aan de hand is, wat jouw bevindingen zijn. Waarschijnlijk komt niet alles (goed) over.
We zien hoe AI bij deze punten kan helpen, maar ook niet alles oplost. AI kan detecteren dat er wat aan de hand is, kan je een samenvatting geven. Maar het is niet 100% zeker dat AI jou de enige echte oorzaak van het probleem aanlevert. Misschien is het wel een neven-effect wat AI als oorzaak aanwijst.
Elastics Classic ML toolkit kan je helpen, vat voor je samen wat er in die miljoenen logregels staat. Elastics heeft een aantal tools die met GenAI ondersteund worden zoals Streams, hiermee haal je makkelijk gegevens uit datastromen, kun je data partitioneren, automatisch visualisaties en dashboards maken. AI Assistant, helpt SRE’s door het aanmaken van regels, beoordeling en onderzoek. In de toekomst komt Elastic met het product AI Investigations. Een tool die ervoor moet zorgen dat de bron van de problemen sneller opgespoord kan worden, tips geven wat je volgende stap zou moeten zijn, vervolgvragen stellen en acties uitvoeren.
We zien SQL (de normale query’s die je uitvoert), ESQL (SQL++, dus ook query’s op “ongestructureerde data”, performant (dus gericht op snelheid), geïntegreerde machine-learning. En piped query languages, dat gaat over “ongestructureerde data”, heeft een pipeline syntax.
Dan komt er nog een slide met een overzicht van SLA, SLO en SLI. Dat zijn termen die ik uit Zabbix ken. Ik ging er vanuit dat de SLO gelijk was aan de SLA die TRES aan klanten belooft. Maar dat lijkt niet zo te zijn. De SLA is 99.7%. De SLO is het doel waarmee de SRE de SLA verdedigt, dus die zou 99.79% kunnen zijn. En SLI is de waarde die het pakket op dit moment heeft.
In de laatste slide krijgen we de call to action. Je kunt je eigen LLM aanleveren. Maar ook het Elastic Managed LLM gebruiken. Of de classic ML.
15.10 – 15.40 PAUZE
Even een break. Ik zie een banner in de zaal staan die mooi laat zien hoe het zou kunnen dat je “de hele dag gebruik maakt van Elastic”. ’s Morgens The Telegraph lezen, het weer bekijken via Met Office, vuilnis bij de weg zetten, wat opgehaald wordt door renewi. En zo door tot ’s avonds een filmpje kijken bij Sky.
Accelerate Threat Intelligence by including Attack Discovery
Arnold van Wijnbergen geeft een presentatie over security. Arnold is op Github te vinden en op LinkedIn.
Veel voorkomende uitdagingen bij het oplossen van het onder vuur liggen zijn, data omzetten naar iets wat je kunt doen (je ziet al die logs, maar wat moet je nou doen?), het missen van relevante context (ik zie dit, maar wat gebeurt hier eigenlijk?) en de time lag in aflevering. Onze Kibana is over het algemeen redelijk bij, maar als je een systeem hebt, waarbij je “laatste data” altijd 5 minuten oud is, dan mis je wat er de afgelopen 5 minuten gebeurd is.
Hierna komt de slide voor implementatie van detectie voor IOC’s. Nee, dit staat niet voor International Olympic Committe, maar Indicators Of Compromise. Met de Elastic Stack kun je Thread Intelligence toevoegen (tabel logs-ti_*) en met detection rules een indicatie krijgen of er wat speelt.
Met Threat Intelligence kun je “bekende zaken” matchen en daar actie op ondernemen. Maar in het huidige tijdperk zijn vooral de “onbekende acties” steeds relevanter om te onderzoeken. Daar kan AI een rol in spelen. Daar kun je Threat Discovery voor gebruiken.
Tip van Arnold om in een “air-gapped locatie” qua AI model een goed getraind en recent model te gebruiken, bijvoorbeeld van Mistral.
En, met RAG, voed je model met interne intelligentie.
AI powered autosuggest
Mijn laatste sessie van deze dag. Arian Stolwijk, developer bij Giftomatic en Coen Baars, de CTO/Co-Founder van Giftomatic vertellen hoe zij Elastic gebruiken voor het zoeken op hun website.
Het gaat hier over de SmartSearchBox, een AI ondersteund zoekveld voor cadeaukaarten. Nu ben ik “the day after” naar de website gegaan: giftomatic.nl en nu ben ik aan het zoeken… waar ik die zoek-optie kan vinden. Want ik zie het nergens?
Na wat zoeken kom ik uit op deze pagina, maar die lijkt niet te werken.
Als developer was deze laatste sessie niet heel interessant, maar over het algemeen was het een zeer geslaagde dag. Nieuwe features van Elastic gehoord, het is duidelijk geworden dat als je nog een “oude versie van Elastic draait”, je zo snel mogelijk moet updaten naar 9.2.0, mede vanwege de betere disk-usage (minder schijfruimte nodig) en de verbetering qua snelheid. En ook dat we eigenlijk meer dingen met security moeten doen. Want Elastic kan veel, heel veel. Maar dan moet de interface wel “snappy” werken, anders laat je het product links liggen. En dat is zonde.
Het kan zijn dat je zaken wilt faken of testen. Dat werd ook bij een aantal demo’s gedaan. Daarbij werd Atomic Red Teaming genoemd, even gezocht en volgens mij deze site.
Via Reddit uit op deze Github-repo van The Zoo.