Az ütemezett elemzési szabályok betöltési késleltetésének kezelése

Bár a Microsoft Sentinel különböző forrásokból is betölthet adatokat, az egyes adatforrások betöltési ideje különböző körülmények között eltérő lehet.

Ez a cikk azt ismerteti, hogy a betöltési késleltetés milyen hatással lehet az ütemezett elemzési szabályokra, és hogyan háríthatja el őket a hiányosságok fedezésére.

Miért jelentős a késés?

Írhat például egy egyéni észlelési szabályt, amely úgy állítja be a Lekérdezés futtatása ésaz utolsó mezők keresési adatainak beállítását, hogy a szabály öt percenként fusson, és az utóbbi öt percben keressen adatokat:

Az utolsó mező keresési adatai egy visszakeresési időszakként ismert beállítást határoznak meg. Ideális esetben, ha nincs késés, ez az észlelés nem hagy ki eseményeket, ahogy az alábbi ábrán látható:

Az esemény a generált állapotban érkezik, és a visszatekintési időszak része.

Tegyük fel, hogy az adatforrás késik. Ebben a példában tegyük fel, hogy az esemény két perccel a létrehozása után lett betöltve. A késés két perc:

Az esemény az első visszatekintési időszakban jön létre, de az első futtatáskor nem kerül be a Microsoft Sentinel-munkaterületre. Amikor az ütemezett lekérdezés legközelebb fut, betölti az eseményt, de az időalapú szűrő eltávolítja az eseményt, mert több mint öt perccel ezelőtt történt. Ebben az esetben a szabály nem küld riasztást.

A késés kezelése

A probléma megoldásához ismernie kell az adattípus késését. Ebben a példában már tudja, hogy a késés két perc.

Saját adatai esetében a Kusto ingestion_time() függvénnyel megértheti a késést, és kiszámíthatja a TimeGenerated és a betöltési idő közötti különbséget. További információ: Betöltési késleltetés kiszámítása.

A késés meghatározása után a következő módon kezelheti a problémát:

• Növelje a visszatekintési időszakot. Az alapszintű megérzés azt jelzi, hogy a visszatekintési időszak méretének növelése segít. Mivel a visszatekintési időszak öt perc, és a késése két perc, a visszatekintési időszak hét percre állítása segít a probléma megoldásában. Például a szabálybeállításokban:

  

  Az alábbi ábra bemutatja, hogy a look-pack időszak most hogyan tartalmazza a kihagyott eseményt:

  

• A duplikáció kezelése. Csak a visszatekintési időszak növelése hozhat létre duplikációt, mivel a visszatekintő ablakok átfedésben vannak. Egy másik esemény például az alábbi ábrán látható módon jelenhet meg:

  

  Mivel az esemény TimeGenerated értéke mindkét visszatekintési időszakban megtalálható, az esemény két riasztást indít el. Meg kell találnia a módját, hogy megoldja a duplikációt.

• Társítsa az eseményt egy adott visszatekintési időszakhoz. Az első példában kihagyott eseményeket, mert az adatok nem fogyott be az ütemezett lekérdezés futtatásakor. Kiterjesztette a visszatekintőt az eseményre, de ez duplikációt okozott. Az eseményt a kiterjesztett ablakhoz kell társítania, hogy az tartalmazza azt.

  Ezt az eredeti szabály look-back = 5mhelyett a beállítással ingestion_time() > ago(5m)teheti meg. Ez a beállítás az eseményt az első visszatekintő ablakhoz társítja. Példa:

  

  A betöltési idő korlátozása mostantól csökkenti a visszatekintési időszakhoz hozzáadott két percet. Az első példában a második futtatási visszatekintési időszak most rögzíti az eseményt:

  

Az alábbi mintalekérdezés összefoglalja a betöltési késleltetéssel kapcsolatos problémák megoldását:

let ingestion_delay = 2min;
let rule_look_back = 5min;
CommonSecurityLog
| where TimeGenerated >= ago(ingestion_delay + rule_look_back)
| where ingestion_time() > ago(rule_look_back)

Az előző példában használt alábbi elemekről további információt a Kusto dokumentációjában talál:

• let utasítás
• ahol operátor
• ago() függvény

Betöltési késleltetés kiszámítása

Alapértelmezés szerint a Microsoft Sentinel ütemezett riasztási szabályai 5 perces visszatekintési időszakra vannak konfigurálva. Előfordulhat azonban, hogy minden adatforrás saját, egyéni betöltési késéssel rendelkezik. Több adattípus összekapcsolásakor ismernie kell az egyes adattípusok különböző késéseit a visszatekintési időszak megfelelő konfigurálásához.

A Microsoft Sentinel beépített munkaterület-használati jelentése tartalmaz egy irányítópultot, amely megjeleníti a munkaterületre áramló különböző adattípusok késését és késését.

Példa:

Következő lépések

További információk:

• Egyéni elemzési szabályok létrehozása fenyegetések észleléséhez
• Riasztás részleteinek testreszabása az Azure Sentinelben
• Az ütemezett elemzési szabályok sablonverzióinak kezelése az Azure Sentinelben
• Az állapotfigyelő munkafüzet használata
• Naplóadatok feldolgozási ideje az Azure Monitorban