Elemzési szabályok hibaelhárítása a Microsoft Sentinelben
Ez a cikk bemutatja, hogyan kezelhetők a Microsoft Sentinel ütemezett elemzési szabályainak végrehajtásával kapcsolatos bizonyos problémák.
Probléma: Nem jelennek meg események a lekérdezési eredményekben
Ha az eseménycsoportozás úgy van beállítva, hogy minden eseményhez riasztást aktiváljon, előfordulhat, hogy a későbbi időpontban megtekintett lekérdezési eredmények hiányoznak, vagy eltérnek a várttól. Előfordulhat például, hogy egy lekérdezés eredményeit egy későbbi időpontban tekinti meg egy kapcsolódó incidens vizsgálatakor, és a vizsgálat részeként úgy dönt, hogy visszatér a lekérdezés korábbi eredményeihez.
A rendszer automatikusan menti az eredményeket a riasztásokkal. Ha azonban az eredmények túl nagyok, a rendszer nem menti az eredményeket, és nem jelenik meg adat a lekérdezés eredményeinek újbóli megtekintésekor.
Azokban az esetekben, amikor betöltési késés van, vagy a lekérdezés az összesítés miatt nem determinisztikus, a riasztás eredménye eltérhet a lekérdezés manuális futtatásával megjelenített eredményétől.
A probléma megoldásához, ha egy szabály rendelkezik ezzel az eseménycsoportozási beállítással, a Microsoft Sentinel hozzáadja az OriginalQuery mezőt a lekérdezés eredményeihez. Íme a meglévő Lekérdezés mező és az új mező összehasonlítása:
| Mezőnév | Contains | A lekérdezés futtatása ebben a mezőben találatok... |
|---|---|---|
| Lekérdezés | A riasztás ezen példányát létrehozó esemény tömörített rekordja. | A riasztás ezen példányát létrehozó esemény; legfeljebb 10 kilobájt. |
| OriginalQuery | Az eredeti lekérdezés az elemzési szabályban leírtak szerint. | A lekérdezés futtatásának időkeretének legújabb eseménye, amely megfelel a lekérdezés által meghatározott paramétereknek. |
Más szóval az OriginalQuery mező úgy viselkedik, mintha a Lekérdezés mező az alapértelmezett eseménycsoportozási beállítás alatt viselkedik.
Probléma: Egy ütemezett szabály nem lett végrehajtva vagy a nevéhez hozzá lett adva, hogy AUTO DISABLED (automatikusan letiltva)
Ritkán fordul elő, hogy egy ütemezett lekérdezési szabály nem fut, de előfordulhat. A Microsoft Sentinel a hibákat átmeneti vagy állandóként sorolja be a hiba konkrét típusa és az ahhoz vezető körülmények alapján.
Átmeneti hiba
Átmeneti hiba olyan körülmény miatt következik be, amely ideiglenes, és hamarosan visszatér a normál állapotba, és ekkor a szabály végrehajtása sikeres lesz. Néhány példa a Microsoft Sentinel átmenetiként besorolt hibáira:
- A szabály-lekérdezések futtatása túl sokáig tart, és időtúllépést igényel.
- az adatforrások és a Log Analytics, illetve a Log Analytics és a Microsoft Sentinel közötti Csatlakozás tivitási problémák.
- Minden más új és ismeretlen hiba átmenetinek minősül.
Átmeneti hiba esetén a Microsoft Sentinel az előre meghatározott és folyamatosan növekvő intervallumok után is megpróbálja újra végrehajtani a szabályt egy pontig. Ezt követően a szabály csak a következő ütemezett időpontban fog újra futni. Egy szabályt átmeneti hiba miatt soha nem lehet automatikusan felcserélni.
Állandó hiba – automatikusan dedukált szabály
Az állandó hiba a szabály futtatását lehetővé tevő feltételek megváltozása miatt következik be, amely emberi beavatkozás nélkül nem térhet vissza a korábbi állapotukhoz. Az alábbiakban néhány példát láthat az állandóként besorolt hibákra:
- A cél-munkaterület (amelyen a szabály-lekérdezés működött) törölve lett.
- A céltáblát (amelyen a szabály lekérdezése működött) törölték.
- A Microsoft Sentinel el lett távolítva a cél-munkaterületről.
- A szabály lekérdezése által használt függvény már nem érvényes; vagy módosították vagy eltávolították.
- A szabály lekérdezésének egyik adatforrására vonatkozó engedélyek módosultak (lásd a példát).
- A szabály lekérdezésének egyik adatforrása törölve lett.
Ha előre meghatározott számú, azonos típusú és azonos szabályú, egymást követő állandó hiba történik, a Microsoft Sentinel nem próbálja végrehajtani a szabályt, és a következő lépéseket is végrehajtja:
- Letiltja a szabályt.
- Hozzáadja az "AUTO DISABLED" (AUTOMATIKUS LETILTÁS) szavakat a szabály nevének elejéhez.
- Hozzáadja a hiba okát (és a letiltást) a szabály leírásához.
A szabálylista név szerinti rendezésével egyszerűen meghatározhatja az automatikusan deduktálható szabályok jelenlétét. Az automatikusan dedukált szabályok a lista tetején vagy közelében találhatók.
Az SOC-kezelőknek rendszeresen ellenőrizniük kell a szabálylistát az automatikusan dedukált szabályok meglétéről.
Állandó hiba az erőforrás-ürítés miatt
Egy másik típusú állandó hiba egy helytelenül összeállított lekérdezés miatt következik be, amely miatt a szabály túlzott számítási erőforrásokat használ fel, és azzal a kockázattal jár, hogy a rendszer teljesítménycsökkenést okoz. Amikor a Microsoft Sentinel azonosítja az ilyen szabályt, ugyanazt a három lépést kell elvégeznie a többi állandó hibatípus esetében– letiltja a szabályt, az "AUTOMATIKUS LETILTVA" előtagot a szabály nevére írja, és hozzáadja a hiba okát a leíráshoz.
A szabály újbóli engedélyezéséhez meg kell oldania a lekérdezés azon problémáit, amelyek miatt túl sok erőforrást használ. A Kusto-lekérdezések optimalizálásának ajánlott eljárásait az alábbi cikkekben találhatja meg:
- Ajánlott lekérdezési eljárások – Azure Data Explorer
- Naplólekérdezések optimalizálása az Azure Monitorban
További segítségért tekintse meg az Kusto lekérdezésnyelv Microsoft Sentinelben való használatát segítő hasznos forrásokat.
Végleges hiba az előfizetések/bérlők közötti hozzáférés elvesztése miatt
Az egyik konkrét példa arra, hogy egy adatforrás engedélyváltozása (lásd a listát) állandó hiba esetén a Microsoft biztonsági megoldásszolgáltatója (MSSP) esetére vonatkozik, vagy bármely más olyan forgatókönyvre, amikor az elemzési szabályok előfizetések vagy bérlők között kérdeznek le.
Elemzési szabály létrehozásakor a rendszer egy hozzáférési engedély jogkivonatot alkalmaz a szabályra, és azzal együtt menti. Ez a jogkivonat biztosítja, hogy a szabály hozzáférhessen a szabály lekérdezése által hivatkozott táblákat tartalmazó munkaterülethez, és hogy ez a hozzáférés akkor is megmaradjon, ha a szabály létrehozója elveszíti a hozzáférést az adott munkaterülethez.
Van azonban egy kivétel: ha olyan szabály jön létre, amely más előfizetésekben vagy bérlőkben lévő munkaterületekhez fér hozzá, például az MSSP esetében, a Microsoft Sentinel további biztonsági intézkedéseket tesz az ügyféladatokhoz való jogosulatlan hozzáférés megakadályozása érdekében. Az ilyen típusú szabályok a szabályt létrehozó felhasználó hitelesítő adataival rendelkeznek, nem pedig független hozzáférési jogkivonattal. Ha a felhasználó már nem fér hozzá a másik bérlőhöz, a szabály nem működik.
Ha előfizetések közötti vagy bérlők közötti forgatókönyvben üzemelteti a Microsoft Sentinelt, és ha az egyik elemzője vagy mérnöke elveszíti a hozzáférést egy adott munkaterülethez, a felhasználó által létrehozott szabályok nem fognak működni. Állapotfigyelési üzenet jelenik meg az "erőforráshoz való elégtelen hozzáférésről", és a szabály a korábban ismertetett eljárásnak megfelelően automatikusan fel lesz osztva.
Következő lépések
További információkért lásd:
- Oktatóanyag: Incidensek vizsgálata a Microsoft Sentinellel
- Navigálás és incidensek kivizsgálása a Microsoft Sentinelben – előzetes verzió
- Adatok osztályozása és elemzése entitások használatával a Microsoft Sentinelben
- Oktatóanyag: Forgatókönyvek használata automatizálási szabályokkal a Microsoft Sentinelben
Emellett megtudhatja, hogyan használhat egyéni elemzési szabályokat a Nagyítás egyéni összekötővel való monitorozása során.