SecOps · Automatizálás
500 alertből 3: hogyan épül a triázs-pipeline, ami tényleg szűr
Lajkó Levente · 2026. augusztus 22. · 6 perc olvasás
Az alert-triázs az a folyamat, amely a beérkező biztonsági riasztásokról eldönti, hogy melyik igényel emberi vizsgálatot, és melyik zárható le automatikusan, dokumentált indoklással. A legtöbb biztonsági csapat ezt kézzel csinálja, és ott ez a nap legnagyobb időnyelője.
A weboldalamon szerepel egy állítás: ötszáz bejövő alertből három, amihez ember kell. Ezt az arányt nagy volumenű távközlési SecOps környezetben tanultam meg elérni, és érdemes pontosan érteni, mit jelent. Nem azt, hogy négyszázkilencvenhét riasztás a kukába megy. Azt, hogy négyszázkilencvenhétnek automatikusan előáll a válasza, naplózott indoklással, és háromnál kell az, amit gép nem tud: ítélőképesség.
Ez az írás azt szedi szét, hogyan épül fel ez a gyakorlatban. Nem termékfüggő: ugyanez a logika működik Splunk, Sentinel, Wazuh, Elastic vagy QRadar alatt, mert a triázs nem eszközkérdés, hanem tervezési kérdés.
A triázs nem erőforrás-probléma
Amikor egy csapat fuldoklik a riasztásokban, az első reflex mindig ugyanaz: több ember kell. Pedig a riasztások túlnyomó része nem döntés, hanem zaj, a zajt pedig nem elemzővel kell fogyasztatni, hanem a keletkezési pontján kell megfogni. Ha a triázs fáj, az szinte mindig azt jelenti, hogy a pipeline valamelyik lépcsője hiányzik.
Az öt lépcső, amin egy riasztás végigmegy
01
Szűrés még a SIEM előtt
A legtöbb zaj nem a detekciós szabályban keletkezik, hanem abban, hogy minden log válogatás nélkül bemegy a SIEM-be. A log-pipeline (syslog-ng, nxlog vagy bármi hasonló) már forrásnál szűr, normalizál és útvonalaz: ami sosem lesz detekció alapja, az ne a legdrágább tárolóban landoljon. Mellékhatásként a licencköltség is megszűnik a detektálás plafonja lenni.
02
Deduplikáció és korreláció
Egy port-szken nem ötszáz esemény, hanem egy. Az azonos forrásból, azonos mintával, rövid ablakon belül érkező riasztásokat a pipeline egyetlen esetté vonja össze, a kapcsolódó jelzéseket (ugyanaz a host, ugyanaz a fiók, ugyanaz az időablak) pedig egymás mellé teszi. Az elemző esetet kap, nem eseményfolyamot.
03
Dúsítás: a kontextus automatikus
Mielőtt ember ránéz, a riasztás magától megkapja a válaszokat a rutinkérdésekre: kié az eszköz, mi fut rajta, van-e ismert sérülékenysége, mit mond róla a threat intel, volt-e már ilyen eset, és az akkor mivel zárult. Ez a lépés önmagában megfelezi a triázs-időt, mert az elemző ideje eddig jórészt ezeknek a kézi kikeresésével ment el.
04
Szabály-alapú lezárás, naplózva
Amire a dúsítás után determinisztikus válasz adható, azt a pipeline zárja le: ismert karbantartási ablak, jóváhagyott kivétel, visszatérő hamis pozitív dokumentált okkal. A kulcsszó a naplózva: minden automatikus lezárás mellé odakerül, hogy mi zárta le és milyen adat alapján. Lezárás bizonyíték nélkül nem automatizálás, hanem szőnyeg alá söprés.
05
Ami marad, az döntés
A pipeline végén az marad, amihez tényleg ítélőképesség kell: az ismeretlen, a szokatlan, az összefüggő. Az elemző nem szűr, hanem dönt, és minden döntése visszacsatolás: amit hamis pozitívnak minősít, az szabályhangolási feladat lesz, nem örök háttérzaj.
Mit mérjetek, hogy tudjátok: működik
A triázs-pipeline nem egyszer megépülő dolog, hanem visszacsatolt rendszer. Négy szám mutatja meg, hogy jó irányba megy-e:
- Riasztás/eset arány: hány bejövő riasztásból lesz emberi vizsgálat. Ez a pipeline hatásfoka, és hétről hétre javulnia kell.
- Triázs-idő esetenként: mennyi idő telik el a riasztás beérkezése és az első érdemi döntés között. A dúsítás minőségét ez méri.
- Hamis pozitív arány szabályonként: nem összesítve, hanem szabályra bontva. Az összesített szám elrejti, hogy a zaj kilencven százalékát jellemzően egy tucat szabály termeli.
- Hangolási ritmus: hány szabály kapott módosítást az elmúlt hónapban. Ahol ez a szám tartósan nulla, ott a detekció nem érik, hanem öregszik.
Négy hiba, amit a legtöbb környezetben látok
Mindent beküldeni a SIEM-be
A leggyakoribb és legdrágább hiba. A SIEM-licenc volumenalapú, ezért ahol minden log bemegy, ott előbb-utóbb a költség dönti el, mi detektálható. A szűrésnek a forrásnál a helye.
Importált szabálykészlet hangolás nélkül
A gyári és közösségi detekciós szabályok kiindulópontnak jók, éles szolgálatra nem. Minden környezet más alapzajjal él. A szabály, amit bekapcsolás után senki nem hangol, nem detekció, hanem zajgenerátor.
Riasztás gazda nélkül
Ha egy riasztástípusnak nincs kijelölt felelőse és elvárt reakcióideje, akkor arra a riasztásra a szervezet hallgatólagosan azt mondta: nem érdekel. Akkor viszont ki se küldjük.
Automatikus lezárás bizonyíték nélkül
Az auditor első kérdése: honnan tudjátok, hogy amit a gép zárt le, azt jól zárta le? Ha a lezárás mellett nincs ott az ok és az adat, a válasz az, hogy nem tudjátok. Naplózott lezárással ugyanez a kérdés harminc másodperc alatt megválaszolható.
Mi köze ennek az audithoz
Ha a szervezet a NIS2 vagy az ISO 27001 hatálya alatt él, a triázs-pipeline mellékterméke legalább annyit ér, mint a fő terméke. Minden automatikus lezárás naplózott indoklással, minden emberi döntés nyomon követhetően: ez pontosan az a fajta bizonyíték, amit egy audit a detektálási és incidenskezelési kontrollokról kérni fog. Ahol a triázs kézi és dokumentálatlan, ott az audit előtt heteket megy el utólagos rekonstrukcióra. Ahol pipeline fut, ott a bizonyíték már készen áll.
A 24 órás incidensbejelentési határidő is innen nézve lesz tartható: bejelenteni csak azt lehet, amit észre is vettünk, észrevenni pedig azt, ami nem fullad bele az ötszáz riasztásba.
Lajkó Levente
Biztonsági mérnök, a PROFIX Security Engineering alapítója. Napközben országos távközlési szolgáltatónál csinál biztonsági operációt.
Ha a saját környezetetekben akarjátok ezt megépíteni: pontosan ezt csinálom megbízásra, a felméréstől a működő pipeline-ig. A részletek a security automatizálás oldalon, vagy beszéljük meg élőben.