ASIM-elemző létrehozása

15 perc

Az Advanced Security Information Model (ASIM) felhasználói egyesítő elemzőket használnak a lekérdezéseikben lévő táblanevek helyett, normalizált formátumban tekintik meg az adatokat, és a lekérdezésbe belefoglalják a sémához kapcsolódó összes adatot. Az elemzők egyesítése a forrásspecifikus elemzők használatával kezeli az egyes forrásadatok részleteit.

A Microsoft Sentinel számos adatforráshoz biztosít beépített, forrásspecifikus elemzőket. Ezeket a forrásspecifikus elemzőket a következő helyzetekben érdemes módosítani vagy fejleszteni:

Ha az eszköz ASIM-sémához illeszkedő eseményeket biztosít, de az eszköz és a vonatkozó séma forrásspecifikus elemzője nem érhető el a Microsoft Sentinelben.

Ha az eszközhöz rendelkezésre állnak ASIM-forrásspecifikus elemzők, de az eszköz az ASIM-elemzők által várttól eltérő módszerrel vagy formátumban küldi el az eseményeket. Például:

Előfordulhat, hogy a forráseszköz úgy van konfigurálva, hogy nem szabványos módon küldjön eseményeket.

Előfordulhat, hogy az eszköz verziója eltér az ASIM-elemző által támogatott verziótól.

Az eseményeket egy közvetítő rendszer gyűjtheti, módosíthatja és továbbíthatja.

Egyéni elemző fejlesztési folyamata

Az alábbi munkafolyamat az egyéni ASIM- és forrásspecifikus elemzők fejlesztésének magas szintű lépéseit ismerteti:

Mintanaplók gyűjtése.
Azonosítsa a forrásból küldött események által képviselt sémákat vagy sémákat.
A forráseseménymezők leképezése az azonosított sémákra vagy sémákra.
Fejlesszen ki egy vagy több ASIM-elemzőt a forráshoz. A forráshoz kapcsolódó összes sémához ki kell dolgoznia egy szűrőelemzőt és egy paraméter nélküli elemzőt.
Tesztelje az elemzőt.
Helyezze üzembe az elemzőket a Microsoft Sentinel-munkaterületeken.
Frissítse a megfelelő ASIM-egyesítési elemzőt az új egyéni elemzőre való hivatkozáshoz.
Az elemzőket az elsődleges ASIM-disztribúcióhoz is hozzá szeretné adni. A közreműködő elemzők az összes munkaterületen beépített elemzőként is elérhetővé tehetők.

Mintanaplók gyűjtése

A hatékony ASIM-elemzők létrehozásához reprezentatív naplókészletre van szükség, amely a legtöbb esetben megköveteli a forrásrendszer beállítását és a Microsoft Sentinelhez való csatlakoztatását. Ha nem érhető el a forráseszköz, a használatalapú felhőalapú szolgáltatások lehetővé teszik számos eszköz üzembe helyezését fejlesztési és tesztelési célokra.

Emellett a naplók szállítói dokumentációjának és mintáinak megkeresése segíthet felgyorsítani a fejlesztést és csökkenteni a hibákat a széles körű naplóformátum-lefedettség biztosításával.

A naplók reprezentatív készletének a következőket kell tartalmaznia:

Különböző eseményeredményeket tartalmazó események.
Események különböző válaszműveletekkel.
A felhasználónév, a gazdagépnév és az azonosítók, valamint az érték normalizálását igénylő egyéb mezők különböző formátumai.

Hozzárendelés

Az elemző fejlesztése előtt képezze le a forráseseményben vagy eseményekben elérhető információkat az azonosított sémára:

Képezz le minden kötelező mezőt, és lehetőleg az ajánlott mezőket is.
Próbálja meg a forrástól a normalizált mezőkre leképezni a rendelkezésre álló információkat. Ha nem érhető el a kijelölt séma részeként, fontolja meg a más sémákban elérhető mezők leképezését.
A forrásmezők értékeinek leképezése az ASIM által engedélyezett normalizált értékekre. Az eredeti érték egy külön mezőben van tárolva, például EventOriginalResultDetails.

Elemzők fejlesztése

Szűrőt és paraméter nélküli elemzőt is fejleszthet az egyes releváns sémákhoz.

Az egyéni elemző a Microsoft Sentinel-naplók lapon kifejlesztett KQL-lekérdezés. Az elemző lekérdezés három részből áll:

Szűrőelemzendő >> mezők

A releváns rekordok szűrése

A Microsoft Sentinel táblái sok esetben több típusú eseményt is tartalmaznak. Például:

A Syslog-tábla több forrásból származó adatokat tartalmaz.
Az egyéni táblák tartalmazhatnak egyetlen forrásból származó információkat, amelyek több eseménytípust is biztosítanak, és különböző sémákhoz illeszthetők.

Ezért az elemzőnek először csak a célséma szempontjából releváns rekordokat kell szűrnie.

A KQL-szűrés a where operátor használatával történik. Az 1. Sysmon-esemény például a folyamatlétrehozásról számol be, ezért normalizálva van a ProcessEvent sémával. A Sysmon event 1 esemény az Esemény tábla része, ezért a következő szűrőt használná:

Event | where Source == "Microsoft-Windows-Sysmon" and EventID == 1

Fontos

Az elemző nem szűrhet idő szerint. Az elemzőt használó lekérdezés egy időtartományt alkalmaz.

Szűrés forrástípus szerint egy figyelőlista használatával

Bizonyos esetekben maga az esemény nem tartalmaz olyan információt, amely lehetővé tenné bizonyos forrástípusok szűrését.

Az Infoblox DNS-események például Syslog-üzenetekként lesznek elküldve, és nehezen különböztethetők meg a más forrásokból küldött Syslog-üzenetektől. Ilyen esetekben az elemző a releváns eseményeket meghatározó források listájára támaszkodik. Ez a lista megmarad az ASimSourceType figyelőlistájában.

Az ASimSourceType figyelőlista használata az elemzőkben:

Adja meg a következő sort az elemző elején:

let Sources_by_SourceType=(sourcetype:string){_GetWatchlist('ASimSourceType') | where SearchKey == tostring(sourcetype) | extend Source=column_ifexists('Source','') | where isnotempty(Source)| distinct Source };

Adjon hozzá egy szűrőt, amely a figyelőlistát használja az elemzőszűrési szakaszban. Az Infoblox DNS-elemző például a következőt tartalmazza a szűrési szakaszban:

| where Computer in (Sources_by_SourceType('InfobloxNIOS'))

A minta használata az elemzőben:

Cserélje le a számítógépet annak a mezőnek a nevére, amely tartalmazza a forrás információját. Ezt a Syslogon alapuló elemzők számítógépként is megtarthatják.
Cserélje le az InfobloxNIOS-jogkivonatot egy tetszőleges értékre az elemzőhöz. Tájékoztassa az elemző felhasználókat, hogy a kiválasztott érték használatával frissíteniük kell az ASimSourceType figyelőlistát, valamint az ilyen típusú eseményeket küldő források listáját.

Szűrés elemzési paraméterek alapján

A szűrőelemzők fejlesztésekor győződjön meg arról, hogy az elemző elfogadja a megfelelő séma szűrési paramétereit az adott séma referenciacikkében leírtak szerint. Ha egy meglévő elemzőt használ kiindulási pontként, az biztosítja, hogy az elemző tartalmazza a megfelelő függvény-aláírást. A legtöbb esetben a tényleges szűrési kód is hasonló ugyanahhoz a sémához tartozó elemzők szűréséhez.

Szűréskor győződjön meg arról, hogy:

Szűrés fizikai mezőkkel végzett elemzés előtt. Ha a szűrt eredmények nem elég pontosak, az elemzés után ismételje meg a tesztet az eredmények finomhangolásához. További információ: szűrésoptimalizálás.
Ne szűrjön, ha a paraméter nincs definiálva, és továbbra is az alapértelmezett értékkel rendelkezik.

Az alábbi példák bemutatják, hogyan valósíthat meg szűrést egy sztringparaméter esetében, ahol az alapértelmezett érték általában "*", és egy listaparaméter esetében, ahol az alapértelmezett érték általában egy üres lista.

srcipaddr=='*' or ClientIP==srcipaddr
array_length(domain_has_any) == 0 or Name has_any (domain_has_any)

Szűrés optimalizálása

Az elemző teljesítményének biztosításához vegye figyelembe a következő szűrési javaslatokat:

A mezők elemzése helyett mindig a beépített mezőkre szűrjön. Bár néha egyszerűbb elemezett mezőkkel szűrni, ez jelentősen befolyásolja a teljesítményt.
Használjon optimalizált teljesítményt biztosító operátorokat. Különösen a ==, rendelkezik és kezdődik vele. Az olyan operátorok használata, mint a regex tartalma vagy egyezése, szintén jelentősen befolyásolja a teljesítményt.

Előfordulhat, hogy a teljesítményre vonatkozó javaslatok szűrése nem mindig könnyű követni. A használat például kevésbé pontos, mint a tartalmaz. Más esetekben a beépített mező (például a SyslogMessage) egyeztetése kevésbé pontos, mint egy kinyert mező, például a DvcAction összehasonlítása. Ilyen esetekben azt javasoljuk, hogy továbbra is előszűrje a teljesítményt optimalizáló operátort egy beépített mezőn, és ismételje meg a szűrőt pontosabb feltételekkel az elemzés után.

Például tekintse meg a következő Infoblox DNS-elemző kódrészletet. Az elemző először ellenőrzi, hogy a SyslogMessage mező rendelkezik-e az ügyfél szóval. A kifejezés azonban az üzenet egy másik helyén is használható, így a Log_Type mező elemzése után az elemző ismét ellenőrzi, hogy az ügyfél szó valóban a mező értéke volt-e.

Syslog | where ProcessName == "named" and SyslogMessage has "client"
…
      | extend Log_Type = tostring(Parser[1]),
      | where Log_Type == "client"

Elemzés

Miután a lekérdezés kiválasztotta a megfelelő rekordokat, előfordulhat, hogy elemeznie kell őket. Általában elemzésre van szükség, ha több eseménymezőt is közvetítenek egyetlen szövegmezőben.

Az elemzést végző KQL-operátorok alább láthatók, a teljesítményoptimalizálásuk szerint rendezve. Az első a legoptimalizáltabb teljesítményt nyújtja, míg az utolsó a legkevésbé optimalizált teljesítményt nyújtja.

Operator	Leírás
hasít	Tagolt értékek sztringjének elemzése.
parse_csv	A CSV (vesszővel tagolt értékek) sorként formázott értékek sztringjének elemzése.
Elemez	Több értéket elemezhet egy tetszőleges sztringből egy minta használatával, amely egyszerűbb, jobb teljesítményű minta vagy reguláris kifejezés lehet.
extract_all	Önálló értékeket elemez egy tetszőleges sztringből egy reguláris kifejezés használatával. extract_all hasonló teljesítménnyel rendelkezik az elemzéshez, ha az utóbbi reguláris kifejezést használ.
Kivonat	Egyetlen érték kinyerése tetszőleges sztringből reguláris kifejezéssel. A kivonat használata jobb teljesítményt nyújt, mint az elemzés vagy extract_all, ha egyetlen értékre van szükség. A kinyerés több aktiválásának ugyanazon a forrássztringen keresztüli használata azonban kevésbé hatékony, mint egyetlen elemzés vagy extract_all, ezért el kell kerülni.
parse_json	A JSON-ként formázott sztring értékeinek elemzése. Ha csak néhány értékre van szükség a JSON-ból, az elemzés, a kinyerés vagy a extract_all jobb teljesítményt nyújt.
parse_xml	Az XML-ként formázott sztring értékeinek elemzése. Ha csak néhány értékre van szükség az XML-ből, az elemzés, a kinyerés vagy a extract_all jobb teljesítményt nyújt.

A sztring elemzése mellett az elemzési fázis az eredeti értékek feldolgozását is szükségessé teheti, beleértve a következőket:

Formázás és típuskonvertálás. Előfordulhat, hogy a kinyerést követően a forrásmezőt úgy kell formázni, hogy illeszkedjen a célsémamezőhöz. Előfordulhat például, hogy egy dátumot és időt ábrázoló sztringet dátum/idő mezővé kell konvertálnia. Ezekben az esetekben hasznosak az olyan függvények, mint a todatetime vagy a tohex.
Értékkeresés. Előfordulhat, hogy a kinyerés után a forrásmező értékét le kell képezni a célsémamezőhöz megadott értékek készletére. Egyes források például numerikus DNS-válaszkódokat jelentenek, míg a séma a gyakoribb szöveges válaszkódokat adja meg. Az iff és a case függvények hasznosak lehetnek néhány érték leképezéséhez.

A Microsoft DNS-elemző például iff utasítással rendeli hozzá az EventResult mezőt az eseményazonosító és a válaszkód alapján, az alábbiak szerint:
```
extend EventResult = iff(EventId==257 and ResponseCode==0 ,'Success','Failure')
```
Több érték esetén használja az adattáblát és a keresőmezőt, ahogyan az ugyanabban a DNS-elemzőben is látható:
```
let RCodeTable = datatable(ResponseCode:int,ResponseCodeName:string) [ 0, 'NOERROR', 1, 'FORMERR'....];
...
 | lookup RCodeTable on ResponseCode
 | extend EventResultDetails = case (
 isnotempty(ResponseCodeName), ResponseCodeName,
 ResponseCode between (3841 .. 4095), 'Reserved for Private Use',
 'Unassigned')
```

Leképezési értékek

Sok esetben a kinyert eredeti értéket normalizálni kell. Az ASIM-ben például a MAC-címek kettőspontokat használnak elválasztóként, míg a forrás kötőjelekkel tagolt MAC-címet küldhet. Az értékek átalakításának elsődleges operátora a KQL-sztring, a numerikus és a dátumfüggvények széles halmaza mellett kiterjeszthető, amint azt a fenti Elemzés szakaszban is bemutatjuk.

Eset-, iff- és keresési utasítások használata, ha egy értékkészletet le kell képezni a célmező által megengedett értékekre.

Amikor minden forrásérték célértékre van leképezve, határozza meg a leképezést az adattábla operátorával, és keresse meg a leképezést. For example

let NetworkProtocolLookup = datatable(Proto:real, NetworkProtocol:string)[
        6, 'TCP',
        17, 'UDP'
   ];
    let DnsResponseCodeLookup=datatable(DnsResponseCode:int,DnsResponseCodeName:string)[
      0,'NOERROR',
      1,'FORMERR',
      2,'SERVFAIL',
      3,'NXDOMAIN',
      ...
   ];
   ...
   | lookup DnsResponseCodeLookup on DnsResponseCode
   | lookup NetworkProtocolLookup on Proto

Figyelje meg, hogy a keresés akkor is hasznos és hatékony, ha a leképezés csak két lehetséges értékkel rendelkezik.

Ha a leképezési feltételek összetettebbek, használja az iff vagy a case függvényeket. Az IFF függvény két érték leképezését teszi lehetővé:

| extend EventResult = 
      iff(EventId==257 and ResponseCode==0,'Success','Failure’)

Az esetfüggvény kétnál több célértéket támogat. Az alábbi példa bemutatja, hogyan kombinálhatók a keresések és a kis- és nagybetűk. A fenti keresési példa egy üres értéket ad vissza a DnsResponseCodeName mezőben, ha a keresési érték nem található. Az alábbi példa a keresési művelet eredményével bővíti azt, ha elérhető, és egyéb további feltételeket határoz meg.

| extend DnsResponseCodeName = 
      case (
        DnsResponseCodeName != "", DnsResponseCodeName,
        DnsResponseCode between (3841 .. 4095), 'Reserved for Private Use',
        'Unassigned'
      )

Mezők előkészítése az eredményhalmazban

Az elemzőnek elő kell készítenie a mezőket az eredményhalmazban, hogy a normalizált mezőket használhassa.

Az eredményhalmaz mezőinek előkészítéséhez a következő KQL-operátorok használhatók:

Operator	Leírás	Mikor érdemes használni egy elemzőben?
projekt átnevezése	Átnevezi a mezőket.	Ha egy mező szerepel a tényleges eseményben, és csak átnevezni kell, használja a projekt átnevezését. Az átnevezett mező továbbra is úgy viselkedik, mint egy beépített mező, és a mező műveletei sokkal jobb teljesítményt biztosítanak.
projekteltávol	Eltávolítja a mezőket.	Az eredményhalmazból eltávolítani kívánt mezőkhöz használjon projekteltávolálást. Azt javasoljuk, hogy ne távolítsa el az eredeti mezőket, amelyek nem normalizálódnak az eredményhalmazból, hacsak nem okoznak zavart, vagy nagyon nagyok, és teljesítménybeli következményekkel járhatnak.
projekt	Kijelöli a korábban létező vagy az utasítás részeként létrehozott mezőket, és eltávolítja az összes többi mezőt.	Nem ajánlott elemzőben való használatra, mivel az elemző nem távolíthat el más, nem normalizált mezőket. Ha el kell távolítania bizonyos mezőket, például az elemzés során használt ideiglenes értékeket, a project-away használatával távolítsa el őket az eredményekből.
Kiterjesztése	Aliasok hozzáadása.	A számított mezők létrehozásában betöltött szerepe mellett a kiterjesztő operátor aliasok létrehozására is használható.

Elemzési változatok kezelése

Az eseménystreamek eseményei sok esetben különböző elemzési logikát igénylő változatokat tartalmaznak. A különböző variánsok egyetlen elemzőben való elemzéséhez használjon feltételes utasításokat, például iff-et és esetet, vagy használjon egyesítő struktúrát.

Ha több változat kezelésére szeretné használni az egyesítést, hozzon létre egy külön függvényt minden egyes változathoz, és az egyesítő utasítással egyesítse az eredményeket:

let AzureFirewallNetworkRuleLogs = AzureDiagnostics
    | where Category == "AzureFirewallNetworkRule"
    | where isnotempty(msg_s);
let parseLogs = AzureFirewallNetworkRuleLogs
    | where msg_s has_any("TCP", "UDP")
    | parse-where
        msg_s with           networkProtocol:string 
        " request from "     srcIpAddr:string
        ":"                  srcPortNumber:int
    …
    | project-away msg_s;
let parseLogsWithUrls = AzureFirewallNetworkRuleLogs
    | where msg_s has_all ("Url:","ThreatIntel:")
    | parse-where
        msg_s with           networkProtocol:string 
        " request from "     srcIpAddr:string
        " to "               dstIpAddr:string
    …
union parseLogs,  parseLogsWithUrls…

Az ismétlődő események és a túlzott feldolgozás elkerülése érdekében győződjön meg arról, hogy az egyes függvények szűréssel kezdődnek, natív mezők használatával, csak az elemezni kívánt eseményeket. Szükség esetén az egyes ágaknál, az egyesítő előtt használja a projekteltávolálást is.

Elemzők üzembe helyezése

Az elemzők manuális üzembe helyezéséhez másolja őket az Azure Monitor naplólapjára, és mentse a lekérdezést függvényként. Ez a módszer a teszteléshez hasznos. További információ: Függvény létrehozása.

Nagyszámú elemző üzembe helyezéséhez javasoljuk az elemző ARM-sablonok használatát az alábbiak szerint:

Hozzon létre egy YAML-fájlt az egyes sémák megfelelő sablonja alapján, és foglalja bele a lekérdezést. Kezdje a sémához és az elemző típusához, szűréséhez vagy paraméter nélküli típusához kapcsolódó YAML-sablonnal.
A YAML-fájl ARM-sablonkonverterré alakításához használja az ASIM Yaml-sablonkonvertert.
Frissítés telepítésekor törölje a függvények régebbi verzióit a portál vagy a függvény törlése PowerShell-eszközzel.
A sablon üzembe helyezése az Azure Portal vagy a PowerShell használatával.

Összekapcsolt sablonok használatával több sablont is kombinálhat egyetlen üzembe helyezési folyamattal.

Folytatás