Technische Samenvatting: Parser-vrije Query's op Beveiligingslogs

Probleemstelling

Beveiligingsanalisten doorzoeken routinematig systeemlogs om bedreigingen op te sporen en incidenten te onderzoeken, maar de diversiteit aan logformaten vormt een aanzienlijke knelpunt. Hoewel logs goedkoop te produceren zijn, zijn ze duur in gebruik omdat elke bron (firewalls, authenticatiediensten, endpoint-agents) zijn eigen semi-gestructureerde formaat hanteert.

De industriestandaard benadering omvat het bouwen van per-bron parsers om logs te normaliseren naar gestructureerde schema's (bijv. OCSF) voordat analyse plaatsvindt. Hoewel krachtig, vereist dit voortdurende engineeringinspanning om parsers te onderhouden naarmate formaten evolueren; Google SecOps onderhoudt bijvoorbeeld ongeveer 1.000 actieve parsers met meer dan 200 updates per maand. Omgekeerd vermijdt het overslaan van parsing en het direct doorzoeken van ruwe bestanden met tools zoals grep of ad-hoc scripts onderhoudskosten, maar verlegt dit de last naar de analist. Deze handmatige aanpak vereist diepgaande kennis van specifieke berichtvarianten en heeft moeite met het uitdrukken van complexe, meerregelige temporale query's (bijv. "vind gebruikers die binnen 60 seconden vanaf twee verschillende IP-adressen zijn ingelogd"), die toestand, groepering en aggregatie vereisen.

Beide benaderingen falen om dezelfde reden: ze vereisen voorafgaande kennis van de syntaxis en semantiek van de bronlog. Gestructureerde pijplijnen coderen dit in parsers, terwijl workflows met ruwe tekst de analist dwingen dit handmatig te reconstrueren.

Methodologie: Het Sieve-systeem

De auteurs presenteren Sieve, een systeem dat uitvoerbare query-code genereert uit beveiligingsvragen in natuurlijke taal zonder vooraf gebouwde parsers of genormaliseerde schema's. Sieve werkt door een Large Language Model (LLM) te gronden met lichtgewicht, automatisch geëxtraheerde logformaat-context.

Overzicht van de Pijplijn

Sieve werkt in vier fasen:

1. Prompt-construktie: Het systeem assembleert een prompt die de query in natuurlijke taal, het pad naar het logbestand en een "contextstrategie" bevat (voorbeelden van logsjablonen of ruwe regels). Het bevat ook beperkingen (bijv. code moet Python of Bash zijn, geen netwerk-/bestandschrijvingen) en een specificatie voor de uitvoer.
2. Codegeneratie: Een LLM (voornamelijk Gemini 3.1 Pro Preview of OpenAI GPT-5.4) wordt één keer per query aangeroepen om een zelfstandig Python- of Bash-script te genereren. Het model krijgt de instructie om code in een JSON-wrapper terug te geven om betrouwbare extractie te garanderen.
3. Gezandbakde uitvoering: De gegenereerde code wordt uitgevoerd in een subproces zonder netwerktoegang en met beperkte bestandsysteemrechten. Het is onderhevig aan veiligheidscontroles (het afwijzen van eval, exec, rm, enz.) en validatie van het uitvoerformaat.
4. Herstelmechanisme: Als de uitvoering mislukt, het script een uitzondering gooit of het uitvoerformaat wordt geschonden, wordt het foutbericht teruggevoerd naar de LLM voor een nieuwe poging. Tot vier pogingen zijn toegestaan.

Contextstrategieën

Om de LLM te gronden in het specifieke logformaat, evalueert Sieve vijf strategieën om context te bieden:

• Matroesjka-sjablonen: Gebruikt een offline LLM-pijplijn om hoogwaardige semantische sjablonen te genereren met naamgevingsvelden als placeholders.
• Drain3: Een streamende parser die sjablonen met generieke wildcards in één doorgang extraheren.
• Frequentiegebaseerde sjablonemaker: Een lichtgewicht, heuristisch algoritme (geïnspireerd door IPLoM) dat tokens normaliseert, groepeert op lengte en variabele posities identificeert om sjablonen in minder dan tien seconden te produceren zonder LLM-aanroepen.
• Willekeurige steekproef: Biedt 100 willekeurig bemonsterde logregels zonder expliciete sjablonen.
• Geen context: Biedt slechts één voorbeeldregel, vertrouwend op de vooraf getrainde kennis van het model.

Het systeem behandelt de LLM als een compiler: het genereert één keer de extractielogica, en het resulterende script wordt deterministisch uitgevoerd met normale programsnelheid over de volledige log.

Belangrijkste Bijdragen

1. Sieve-pijplijn: Een open-source systeem voor door LLM ondersteunde query's op ruwe beveiligingslogs dat uitvoerbare code genereert uit natuurlijke taal, waarbij slechts één LLM-aanroep per query nodig is gevolgd door deterministische uitvoering.
2. Benchmarks: Een nieuwe benchmark bestaande uit 133 beveiligingsquery's over 5 logtypen (Linux Audit, SSH, cron, Puppet, DHCP). De query's variëren van eenvoudige filters (Klasse 1–2) tot complexe meerregelige correlaties die temporale vensters en toestandgebonden aggregatie omvatten (Klasse 3–4). Ground truth-antwoorden worden voor alle query's verstrekt.
3. Verkenning van de ontwerpruimte: Een evaluatie van contextstrategieën, uitvoeringstalen (Python versus Bash) en modelfamilies om de optimale configuratie voor logquery's te bepalen.
4. Vergelijkingen met baselines: Een vergelijking met een menselijke baseline (analisten die binnen 10 minuten naïeve grep/Python-scripts schrijven) en een geautomatiseerde gestructureerde parsing-pijplijn (Matroesjka).

Experimentele Resultaten

De evaluatie werd uitgevoerd op 133 query's over 5 logtypen.

• Prestaties versus menselijke baseline: Sieve komt overeen met menselijke prestaties op eenvoudige filterquery's, maar presteert aanzienlijk beter dan handmatige scripting op complexe query's. Op complexe werklasten (detectie van brute-force-aanvallen, identificatie van sessie-anomalieën, correlatie van gebeurtenissen over verschillende events) verlaagt Sieve het gemiddelde foutpercentage van 0,34 (mens) naar 0,10, een reductie van ongeveer 3,6×. De grootste winsten werden waargenomen bij taken die het parsen van tijdstempels vereisen, het samenvoegen van gebeurtenissen op gedeelde identificatoren en het onderhouden van toestand in rollende vensters.
• Prestaties versus gestructureerde parsing: Op eenvoudige filterwerklasten bereikt Sieve (met de lichtgewicht Drain3-context) een macro F1-score van 0,981, wat binnen de ruis ligt van de Matroesjka-gestructureerde parsing-pijplijn (0,999). Dit demonstreert dat door LLM gegenereerde code de nauwkeurigheid van volledig geparseerde representaties kan benaderen zonder de offline-parsergeneratiefase.
• Contextstrategie: De keuze van de sjabloonbron is minder belangrijk dan verwacht. Een eenvoudige, frequentiegebaseerde sjablonemaker (die in seconden draait zonder LLM-aanroepen) produceerde statistisch niet te onderscheiden resultaten van de hooginspannende Matroesjka-sjablonen. De kritieke factor is dekking van berichtvarianten in plaats van de sofisticatie van de sjabloonrepresentatie.
• Taalkeuze: Python is de superieure standaard voor complexe query's. Hoewel Bash vergelijkbaar presteert op eenvoudige filters, faalt het aanzienlijk bij toestandgebonden temporale query's (bijv. zagen complexe DHCP-query's een daling van 0,815 F1 in Python naar 0,446 in Bash) vanwege beperkingen in het hanteren van datastructuren en tijdstempel-aritmetiek.
• Modelrobuustheid: De pijplijn is overdraagbaar tussen modelfamilies (Gemini 3.1 Pro en GPT-5.4), hoewel GPT-5.4 in deze specifieke configuratie lagere prestaties vertoonde op complexe toestandgebonden taken.

Betekenis en Claims

Het artikel beweert dat Sieve de kloof overbrugt tussen de uitdrukkingskracht van gestructureerde logquery's en de directheid van werken met ruwe bestanden. De primaire betekenis ligt in het aantonen dat door LLM gegenereerde code kan dienen als een just-in-time queryplan dat de noodzaak voor continu parseronderhoud elimineert terwijl de nauwkeurigheid van gestructureerde analyse behouden blijft.

De auteurs betogen dat Sieve bijzonder waardevol is voor de "lange staart" van analistenquery's die buiten het genormaliseerde schema van een SIEM vallen, of voor ad-hoc onderzoeken waar tijdsdruk het bouwen van een parser onmogelijk maakt. Door de kosten te verschuiven van continue engineering (onderhoud van parsers) naar een beperkte kost per query (één LLM-aanroep + deterministische uitvoering), biedt Sieve een schaalbaar alternatief voor de "eerst normaliseren, later query's" architectuur. De resultaten suggereren dat voor complexe beveiligingsonderzoeken geautomatiseerde codegeneratie niet alleen haalbaar is, maar ook superieur aan handmatige scripting, mits het systeem voldoende logformaat-context krijgt.