Schrijf detectieregels

De logica van een detectieregel is de SQL die bepaalt waar het naar zoekt. Deze pagina legt uit hoe regels werken, hoe je een benadering kiest voor veelvoorkomende detectiepatronen, en hoe je een regel kunt scopen naar het juiste datavenster. Voor de UI-stappen om een regel te maken, zie Detectieregels maken en beheren.

Hoe detectieregels werken

Elke detectieregel in Lakewatch wordt volgens een schema uitgevoerd. Wanneer een regel draait, voert het je detectie-SQL uit over een tijdsvenster en genereert het een signaal voor elke match. Je schrijft de volledige query, inclusief de FROM clausule, zodat een regel tabellen kan joinen, een hele tabel kan scannen of aggregaten kan berekenen. Een geplande detectieregel draait op een SQL-warehouse dat je beschikbaar stelt. Zie Een detectiegegevensopslag instellen.

Je stelt het schema van een regel in en berekent de berekening wanneer je het maakt. Zie Detectieregels maken en beheren.

Een benadering kiezen

Deze tabel koppelt veelvoorkomende detectiepatronen aan hoe je elk patroon opstelt:

Beperk regels binnen een tijdsbereik

Beperk waar mogelijk een regel tot een relevant tijdsbereik in plaats van een hele tabel te scannen. Gebruik de IN_TIMERANGE functie om dat venster te definiëren, en laat de run de grenzen leveren:

SELECT *
FROM process_activity
WHERE IN_TIMERANGE(<event_time>)
  AND activity_id = 1
  AND endswith(lower(process.name), '\\hashcat.exe')

Vervang <event_time> door de TIMESTAMP kolom of expressie om te filteren.

IN_TIMERANGE(<event_time>) geeft waar terug wanneer een gebeurtenis binnen het effectieve tijdbereik van de huidige run valt. Het bereik is half open: een gebeurtenis waarvan de tijdstempel gelijk is aan het begin van het venster wordt meegenomen, maar een gebeurtenis die gelijk is aan het einde wordt uitgesloten. Dit voorkomt dat een eindpunt gedeeld wordt tussen niet-overlappende vensters. Een niet-nul extend_lookback zorgt er opzettelijk voor dat opeenvolgende vensters overlappen. Signaaldeduplicatie regelt herhaalde signalen van overeenkomende rijen. Je schrijft de begin- en eindtijden niet zelf in de SQL. In plaats daarvan levert Lakewatch het bereik op basis van hoe de query draait:

• Voor een geplande run begint het basisvenster op het eerder geplande uitvoeringstijdstip en eindigt het op het huidige geplande uitvoeringstijdstip. Dit tijdsvenster wordt niet beïnvloed door planningsvertragingen. Om rekening te houden met innamevertraging, zie Het venster uitbreiden met extend_lookback.
• Op de querypagina (die je kunt gebruiken om een regel te ontwikkelen) selecteer je het venster met de datum/tijd-kiezer. Omdat SQL die op de querypagina is geschreven zelf het tijdbereik niet bevat, kan het als detectieregel ongewijzigd worden ingezet.

Vergroot het venster met extend_lookback

IN_TIMERANGE(<event_time>) filteren op de gebeurtenistijd, maar logs bereiken de tabel vaak enkele minuten nadat het evenement plaatsvindt. Een rij kan na afloop landen van de run waarvan het venster de evenementtijd al heeft afgedekt, en latere runs scannen nieuwe evenementtijden, waardoor er een dekkingskloof ontstaat. extend_lookback, een optionele per-regel instelling, verschuift het begin van het venster naar achteren, zodat elke run een deel van de oudere gebeurtenistijd opnieuw scant en rijen opvangt die sinds de laatste run zijn aangekomen. Het verschuivt alleen de vroegste grens. De laatste tijdslimiet blijft op de momenteel geplande uitvoeringstijd. Stel het in op een duur zoals 30s, 10m, of 2h. Het venster dat een ingeplande regel scant is de schemafrequentie plus extend_lookback:

Overlappende runs kunnen dezelfde rij meerdere keren selecteren. Houd signaaldeduplicatie ingeschakeld en kies een deduplicatievenster dat de periode bestrijkt waarin een rij opnieuw geselecteerd kan worden. Een langere terugkijk verlengt het deduplicatievenster niet automatisch. Vermijd het toevoegen van veranderende waarden zoals CURRENT_TIMESTAMP() aan het SQL-resultaat uitsluitend voor de boekhouding, omdat gewijzigde resultaatrijen geen duplicaten zijn. Zie Signaaldeduplicering.

Als je het niet instelt extend_lookback, hanteert Lakewatch standaard 15 minuten. De meeste zakelijke bronnen leveren binnen enkele minuten, maar weinig garanderen een bovengrens, dus de standaardinstelling vangt gebruikelijke vertragingen op zonder enige afstemming.

Om extend_lookback in de UI in te stellen, voer je naast de detectie-SQL een duur in Extend lookback in. Gebruik geordende dag-, uur-, minuten- en secondenwaarden, zoals 15m of 1h30m. Laat het leeg om de standaard 15 minuten te gebruiken, of voer 0s in om de extensie uit te schakelen. De instelling heeft alleen effect als je SQL IN_TIMERANGE gebruikt.

Kies de juiste tijdkolom

Een gebeurtenistijdkolom gecombineerd met extend_lookback is de juiste aanpak voor bijna elke regel. Schat de innamevertraging van je bron in en stel extend_lookback zo in dat deze wordt afgedekt, of vertrouw op de standaard 15 minuten voor bronnen die snel leveren.

Als de innamelatentie van een bron zo variabel is dat geen enkele extend_lookback deze betrouwbaar dekt, kun je in plaats daarvan de regel op basis van de innametijd toepassen. Op tabellen die door een Lakewatch-databron zijn geproduceerd, registreert de lw_meta.ingestion_time-kolom wanneer Lakewatch elke rij na ingestie heeft geschreven, zodat een venster erboven niet wordt beïnvloed door leveringsvertragingen:

WHERE IN_TIMERANGE(lw_meta.ingestion_time)

Grijp hiernaar alleen als gebeurtenistijd plus extend_lookback niet volstaat. Elke run dekt dan een vaste hoeveelheid innametijdstip in plaats van de gebeurtenistijd, zodat de eigen tijdstempel van een event buiten het nominale venster van de run kan vallen, wat tijdsgebonden aggregaties kan vertekenen. Probeer het eerst op te lossen met event time.

Vermijd ankeren aan NOW() of CURRENT_TIMESTAMP()

Een veelgebruikt patroon stelt het venster handmatig in op basis van de huidige systeemtijd:

-- Avoid this
WHERE time BETWEEN CURRENT_TIMESTAMP() - INTERVAL 24 HOUR AND CURRENT_TIMESTAMP()

Dit werkt voor een routine-uitvoering, maar kan problemen veroorzaken:

• Gemiste of dubbel getelde gegevens: Een venster zoals "het laatste uur" is verankerd aan het moment waarop de run wordt afgevuurd, niet aan de tijdslice die het moest bestrijken. Als een run van 3:00 wordt uitgesteld tot 3:12, scant deze 2:12–3:12, laat een gat van 2:00–2:12 over, en kan het overlappen met de volgende run. IN_TIMERANGE leidt het venster af van de geplande slice, zodat een vertraagde run geen opening achterlaat. Overlap tussen geplande runs komt voort uit extend_lookback. Zie Vergroot het venster met extend_lookback.
• Planningswijzigingen: Als je een regel verandert van elke 15 minuten naar elke 30 minuten, is een hardcoded INTERVAL 15 MINUTES fout totdat je eraan denkt deze te bewerken. Met IN_TIMERANGE volgt het venster het schema.
• Re-windowing: Een gemiste periode invullen, opnieuw afspelen na een datafix, of een nieuwe regel previewen op oudere data passen allemaal dezelfde regel toe over een ander venster. Een query die aan NOW() is vergrendeld kan dat niet doen zonder handmatige bewerkingen.
• Reproduceerbaarheid: Met dezelfde grenzen scant IN_TIMERANGE bij elke uitvoering dezelfde rijen, zodat de resultaten herhaalbaar zijn. Een query gekoppeld aan NOW() verschuift bij elke uitvoering.

Reserveer NOW() en CURRENT_TIMESTAMP() voor gevallen waarin je aan de werkelijke tijd moet refereren, zoals het berekenen van hoe oud een gebeurtenis is ten opzichte van het huidige moment.

Verwijs naar het venster van de uitvoering met TIMERANGE_NOW()

Als je een "nu"-waarde nodig hebt die rekening houdt met het venster van de run in plaats van de systeemklok, gebruik TIMERANGE_NOW(). Het geeft de geplande uitvoeringstijd van de run terug en valt terug naar de werkelijke huidige tijd wanneer er geen venster is ingesteld (bijvoorbeeld op de querypagina). Gebruik het om met de hand een venster te bouwen dat IN_TIMERANGE niet kan uitdrukken, zoals het verspringen van het venster of het scannen van twee niet-aangrenzende perioden in één run:

Deze predicaten gebruiken vaste offset van TIMERANGE_NOW(). Het wijzigen van het schema verandert hun intervalliteralen niet. extend_lookback verbreedt deze handmatig gespecificeerde vensters niet, omdat het alleen de beheerde startgrens verandert die door IN_TIMERANGE wordt gebruikt.

Deze tabel vat samen wanneer elke functie gebruikt moet worden: