Speciális keresési lekérdezési ajánlott eljárások

Cikk
04/26/2024

Érintett szolgáltatás:

Microsoft Defender XDR

Ezeket a javaslatokat alkalmazva gyorsabban kaphat eredményeket, és elkerülheti az időtúllépéseket összetett lekérdezések futtatásakor. A lekérdezési teljesítmény javítására vonatkozó további útmutatásért olvassa el a Kusto-lekérdezések ajánlott eljárásait.

A CPU-erőforráskvóták ismertetése

A méretétől függően minden bérlő rendelkezik hozzáféréssel a speciális veszélyforrás-keresési lekérdezések futtatásához lefoglalt CPU-erőforrások meghatározott mennyiségéhez. A különböző használati paraméterekkel kapcsolatos részletes információkért olvassa el a speciális veszélyforrás-keresési kvótákról és használati paraméterekről szóló cikket.

A lekérdezés futtatása után láthatja a végrehajtási időt és az erőforrás-használatot (Alacsony, Közepes, Magas). A Magas érték azt jelzi, hogy a lekérdezés több erőforrást használt a futtatáshoz, és javítható az eredmények hatékonyabb visszaadása érdekében.

Azoknak az ügyfeleknek, akik rendszeresen futtatnak több lekérdezést, nyomon kell követnie a használatot, és alkalmazniuk kell a cikkben található optimalizálási útmutatót a kvóták vagy használati paraméterek túllépése miatti fennakadások minimalizálása érdekében.

Tekintse meg a KQL-lekérdezések optimalizálását bemutató cikket, amely a lekérdezések fejlesztésének néhány leggyakoribb módját ismerteti.

Általános optimalizálási tippek

Új lekérdezések méretezése – Ha azt gyanítja, hogy egy lekérdezés nagy eredményhalmazt ad vissza, először mérje fel a számláló operátorral. Használjon korlátot vagy szinonimát take a nagy eredményhalmazok elkerüléséhez.
Szűrők korai alkalmazása – Időszűrők és egyéb szűrők alkalmazásával csökkentheti az adatkészletet, különösen az átalakítási és elemzési függvények használata előtt, például sztring(), replace(), trim(), toupper(), vagy parse_json(). Az alábbi példában a extractjson() elemzési függvényt akkor használja a rendszer, ha a szűrési operátorok csökkentették a rekordok számát.
```
DeviceEvents
| where Timestamp > ago(1d)
| where ActionType == "UsbDriveMount"
| where DeviceName == "user-desktop.domain.com"
| extend DriveLetter = extractjson("$.DriveLetter", AdditionalFields)
```
A has beats tartalmaz – Ha el szeretné kerülni a szavakon belüli sztringrészek szükségtelen keresését, használja a operátort a hascontainshelyett. A sztringoperátorok ismertetése
Keresés adott oszlopokban – Egy adott oszlopban kell keresnie ahelyett, hogy teljes szöveges kereséseket futtat az összes oszlopban. Ne használja az parancsot * az összes oszlop ellenőrzéséhez.
Kis- és nagybetűk megkülönböztetése a sebesség szempontjából – A kis- és nagybetűket megkülönböztető keresések pontosabbak és általában hatékonyabbak. A kis- és nagybetűket megkülönböztető sztringoperátorok, például has_cs a és contains_csa neve általában a kifejezéssel végződik _cs. A kis- és nagybetűket megkülönböztető egyenlőség operátort == is használhatja a =~helyett.
Elemzés, ne nyerje ki – Amikor csak lehetséges, használja az elemzési operátort vagy egy elemzési függvényt, például parse_json(). Kerülje a sztringoperátort matches regex vagy a extract() függvényt, amelyek mindegyike reguláris kifejezést használ. Tartsa fenn a reguláris kifejezés használatát összetettebb forgatókönyvek esetén. További információ a függvények elemzéséről
Táblák szűrése nem kifejezések – Ne szűrjön számított oszlopra, ha táblázatoszlopra szűrhet.
Nincs három karakteres kifejezés – Ne hasonlítsa össze vagy szűrjön három vagy kevesebb karaktert tartalmazó kifejezések használatával. Ezek a kifejezések nincsenek indexelve, és az egyezésük több erőforrást igényel.
Szelektív kivetítés – Az eredmények érthetőbbé tétele úgy, hogy csak a szükséges oszlopokat vetít ki. Az egyes oszlopok kivetítése az összekapcsolási vagy hasonló műveletek futtatása előtt szintén segít a teljesítmény javításában.

Az `join` operátor optimalizálása

Az illesztési operátor két tábla sorait egyesíti a megadott oszlopok értékeinek egyeztetésével. Ezekkel a tippekkel optimalizálhatja az operátort használó lekérdezéseket.

Kisebb tábla balra – Az join operátor az illesztésutasítás bal oldalán lévő táblában lévő rekordokat a jobb oldali rekordokhoz hasonlítja. Ha a kisebb táblát a bal oldalon használja, kevesebb rekordot kell egyeztetni, ami felgyorsítja a lekérdezést.

Az alábbi táblázatban a bal oldali táblázatot DeviceLogonEvents úgy csökkentjük, hogy csak három adott eszközt fedjen le, mielőtt fiókazonosítók alapján IdentityLogonEvents csatlakozna hozzá.
```
DeviceLogonEvents
| where DeviceName in ("device-1.domain.com", "device-2.domain.com", "device-3.domain.com")
| where ActionType == "LogonFailed"
| join
    (IdentityLogonEvents
    | where ActionType == "LogonFailed"
    | where Protocol == "Kerberos")
on AccountSid
```
Használja az inner-join ízt – Az alapértelmezett illesztési íz vagy az innerunique-join deduplikálja a bal oldali táblázat sorait az illesztési kulccsal, mielőtt visszaadna egy sort minden egyezéshez a jobb oldali táblázathoz. Ha a bal oldali tábla több olyan sort tartalmaz, amelynek értéke megegyezik a join kulcséval, a rendszer deduplikálja ezeket a sorokat, hogy minden egyes egyedi értékhez egyetlen véletlenszerű sort hagyjon.

Ez az alapértelmezett viselkedés fontos információkat hagyhat ki a bal oldali táblából, amelyek hasznos betekintést nyújtanak. Az alábbi lekérdezés például csak egy adott mellékletet tartalmazó e-mailt jelenít meg, még akkor is, ha ugyanazt a mellékletet több e-mail-üzenettel küldte el:
```
EmailAttachmentInfo
| where Timestamp > ago(1h)
| where Subject == "Document Attachment" and FileName == "Document.pdf"
| join (DeviceFileEvents | where Timestamp > ago(1h)) on SHA256
```
Ennek a korlátozásnak a megoldásához a inner-join ízt alkalmazzuk úgy, hogy a kind=inner bal oldali táblázat összes sorát egyező értékekkel jeleníti meg a jobb oldalon:
```
EmailAttachmentInfo
| where Timestamp > ago(1h)
| where Subject == "Document Attachment" and FileName == "Document.pdf"
| join kind=inner (DeviceFileEvents | where Timestamp > ago(1h)) on SHA256
```
Rekordok összekapcsolása egy időablakból – A biztonsági események vizsgálatakor az elemzők az ugyanabban az időszakban előforduló kapcsolódó eseményeket keresik. Ugyanez a megközelítés akkor is előnyös, ha join csökkenti az ellenőrizendő rekordok számát.

Az alábbi lekérdezés a rosszindulatú fájl fogadásától számított 30 percen belül ellenőrzi a bejelentkezési eseményeket:
```
EmailEvents
| where Timestamp > ago(7d)
| where ThreatTypes has "Malware"
| project EmailReceivedTime = Timestamp, Subject, SenderFromAddress, AccountName = tostring(split(RecipientEmailAddress, "@")[0])
| join (
DeviceLogonEvents
| where Timestamp > ago(7d)
| project LogonTime = Timestamp, AccountName, DeviceName
) on AccountName
| where (LogonTime - EmailReceivedTime) between (0min .. 30min)
```
Időszűrők alkalmazása mindkét oldalon – Még ha nem is vizsgál egy adott időablakot, az időszűrők alkalmazása a bal és a jobb oldali táblákon is csökkentheti a rekordok számát az ellenőrzéshez és a teljesítmény javításához join . Az alábbi lekérdezés mindkét táblára vonatkozik Timestamp > ago(1h) , így csak az elmúlt óra rekordjait kapcsolja össze:
```
EmailAttachmentInfo
| where Timestamp > ago(1h)
| where Subject == "Document Attachment" and FileName == "Document.pdf"
| join kind=inner (DeviceFileEvents | where Timestamp > ago(1h)) on SHA256
```
Teljesítménymutatók használata – Az operátorral kapcsolatos join tippek használatával utasíthatja a háttérrendszert a terhelés elosztására az erőforrás-igényes műveletek futtatásakor. További információ a csatlakozással kapcsolatos tippekről

Az elosztási tipp például segít javítani a lekérdezési teljesítményt, ha a táblákat nagy számosságú kulccsal – sok egyedi értékkel rendelkező kulccsal – illeszti össze, például az AccountObjectId alábbi lekérdezésben:
```
IdentityInfo
| where JobTitle == "CONSULTANT"
| join hint.shufflekey = AccountObjectId
(IdentityDirectoryEvents
    | where Application == "Active Directory"
    | where ActionType == "Private data retrieval")
on AccountObjectId
```
A szórási tipp segít, ha a bal oldali táblázat kicsi (legfeljebb 100 000 rekord), és a jobb oldali táblázat rendkívül nagy. Az alábbi lekérdezés például olyan e-maileket próbál összekapcsolni, amelyek a táblában EmailUrlInfo hivatkozásokat tartalmazó összes üzenettel rendelkeznek:
```
EmailEvents
| where Subject in ("Warning: Update your credentials now", "Action required: Update your credentials now")
| join hint.strategy = broadcast EmailUrlInfo on NetworkMessageId
```

Az `summarize` operátor optimalizálása

Az összegző operátor összesíti egy tábla tartalmát. Ezekkel a tippekkel optimalizálhatja az operátort használó lekérdezéseket.

Eltérő értékek keresése – A használatával summarize általában olyan egyedi értékeket kereshet, amelyek ismétlődőek lehetnek. Szükségtelen lehet olyan oszlopok összesítésére használni, amelyek nem rendelkeznek ismétlődő értékekkel.

Bár egyetlen e-mail több esemény részét is képezheti, az alábbi példa nem hatékony, summarize mert az egyes e-mailek hálózati üzenetazonosítója mindig egyedi feladói címmel rendelkezik.
```
EmailEvents
| where Timestamp > ago(1h)
| summarize by NetworkMessageId, SenderFromAddress
```
Az summarize operátor könnyen lecserélhető a-ra project, ami potenciálisan ugyanazokat az eredményeket eredményezi, miközben kevesebb erőforrást használ fel:
```
EmailEvents
| where Timestamp > ago(1h)
| project NetworkMessageId, SenderFromAddress
```
Az alábbi példa a hatékonyabb használatát szemlélteti summarize , mivel egy feladói címnek több különböző példánya is lehet, amelyek ugyanarra a címzett címre küldenek e-mailt. Az ilyen kombinációk kevésbé eltérőek, és valószínűleg duplikáltak.
```
EmailEvents
| where Timestamp > ago(1h)
| summarize by SenderFromAddress, RecipientEmailAddress
```
A lekérdezés elosztása – Bár summarize az ismétlődő értékeket tartalmazó oszlopokban a legjobban használják, ugyanezek az oszlopok nagy számossággal vagy nagy számú egyedi értékkel is rendelkezhetnek. Az join operátorhoz hasonlóan a elosztási tippetsummarize is alkalmazhatja a feldolgozási terhelés elosztásához, és növelheti a teljesítményt, ha nagy számosságú oszlopokon dolgozik.

Az alábbi lekérdezés a különböző címzettek e-mail-címeinek megszámlálására szolgál summarize , amelyek nagy szervezetekben több százezer példányban futtathatók. A teljesítmény javítása érdekében a következőt hint.shufflekeytartalmazza:
```
EmailEvents
| where Timestamp > ago(1h)
| summarize hint.shufflekey = RecipientEmailAddress count() by Subject, RecipientEmailAddress
```

Lekérdezési forgatókönyvek

Egyedi folyamatok azonosítása folyamatazonosítókkal

A folyamatazonosítókat (PID-ket) a Windows újra felhasználja, és újra felhasználja az új folyamatokhoz. Önmagukban nem szolgálhatnak egyedi azonosítóként adott folyamatokhoz.

Egy adott gépen lévő folyamat egyedi azonosítójának lekéréséhez használja a folyamatazonosítót a folyamat létrehozási idejével együtt. Folyamatok adatainak összekapcsolásakor vagy összesítésekor adja meg a gépazonosító (vagy DeviceIdDeviceName) oszlopait, a folyamatazonosítót (ProcessId vagy InitiatingProcessId) és a folyamat létrehozási idejét (ProcessCreationTime vagy InitiatingProcessCreationTime)

Az alábbi példalekérdezés megkeresi azokat a folyamatokat, amelyek több mint 10 IP-címet érnek el a 445-ös (SMB) porton keresztül, esetleg fájlmegosztásokat keresnek.

Példa lekérdezésre:

DeviceNetworkEvents
| where RemotePort == 445 and Timestamp > ago(12h) and InitiatingProcessId !in (0, 4)
| summarize RemoteIPCount=dcount(RemoteIP) by DeviceName, InitiatingProcessId, InitiatingProcessCreationTime, InitiatingProcessFileName
| where RemoteIPCount > 10

A lekérdezés úgy összegzi a InitiatingProcessId és InitiatingProcessCreationTime a függvényt, hogy egyetlen folyamatot tekintsen meg anélkül, hogy több folyamatot is ugyanazzal a folyamatazonosítóval kevert volna össze.

Lekérdezési parancssorok

A feladatok végrehajtásához számos módon lehet parancssort létrehozni. Egy támadó például hivatkozhat egy képfájlra elérési út nélkül, fájlkiterjesztés nélkül, környezeti változók vagy idézőjelek használatával. A támadó módosíthatja a paraméterek sorrendjét, vagy több idézőjelet és szóközt is hozzáadhat.

Ha tartósabb lekérdezéseket szeretne létrehozni a parancssorok körül, alkalmazza az alábbi eljárásokat:

Azonosítsa az ismert folyamatokat (például net.exe vagy psexec.exe) úgy, hogy a fájlnévmezőkben megfelelteti azokat ahelyett, hogy magára a parancssorra szűrne.
Parancssori szakaszok elemzése a parse_command_line() függvénnyel
Parancssori argumentumok lekérdezésekor ne keressen pontos egyezést több egymáshoz nem kapcsolódó argumentumhoz egy bizonyos sorrendben. Ehelyett használjon reguláris kifejezéseket, vagy használjon több különálló tartalmaz operátort.
A kis- és nagybetűket nem megkülönböztető egyezések használata. Például a , a és contains a helyett használja =~a , ina és contains_csa ==parancsot. in~
A parancssori eltömítési technikák mérséklése érdekében fontolja meg az idézőjelek eltávolítását, a vesszők szóközökre cserélését, valamint több egymást követő szóköz egyetlen szóközzel történő cseréjét. Vannak összetettebb rejtjelkészítési technikák, amelyek más megközelítéseket igényelnek, de ezek a finomhangolások segíthetnek a gyakoriak kezelésében.

Az alábbi példák különböző módszereket mutatnak be az "MpsSvc" tűzfalszolgáltatás leállításáhoznet.exe fájlra irányuló lekérdezés létrehozására:

// Non-durable query - do not use
DeviceProcessEvents
| where ProcessCommandLine == "net stop MpsSvc"
| limit 10

// Better query - filters on file name, does case-insensitive matches
DeviceProcessEvents
| where Timestamp > ago(7d) and FileName in~ ("net.exe", "net1.exe") and ProcessCommandLine contains "stop" and ProcessCommandLine contains "MpsSvc"

// Best query also ignores quotes
DeviceProcessEvents
| where Timestamp > ago(7d) and FileName in~ ("net.exe", "net1.exe")
| extend CanonicalCommandLine=replace("\"", "", ProcessCommandLine)
| where CanonicalCommandLine contains "stop" and CanonicalCommandLine contains "MpsSvc"

Adatok betöltése külső forrásokból

Ha hosszú listákat vagy nagy táblákat szeretne beépíteni a lekérdezésbe, használja az externaldata operátort egy adott URI-ból származó adatok betöltéséhez. Txt, CSV, JSON vagy más formátumú fájlokból is lekérhet adatokat. Az alábbi példa bemutatja, hogyan használhatja a MalwareBazaar (abuse.ch) által biztosított kártevő-SHA-256 kivonatok széles listáját az e-mailek mellékleteinek ellenőrzéséhez:

let abuse_sha256 = (externaldata(sha256_hash: string)
[@"https://bazaar.abuse.ch/export/txt/sha256/recent/"]
with (format="txt"))
| where sha256_hash !startswith "#"
| project sha256_hash;
abuse_sha256
| join (EmailAttachmentInfo
| where Timestamp > ago(1d)
) on $left.sha256_hash == $right.SHA256
| project Timestamp,SenderFromAddress,RecipientEmailAddress,FileName,FileType,
SHA256,ThreatTypes,DetectionMethods

Sztringek elemzése

Különböző függvények használhatók az elemzést vagy átalakítást igénylő sztringek hatékony kezelésére.

Karakterlánc	Funkció	Használati példa
Parancssorok	parse_command_line()	Bontsa ki a parancsot és az összes argumentumot.
Görbék	parse_path()	Bontsa ki egy fájl vagy mappa elérési útjának szakaszait.
Verziószámok	parse_version()	Egy legfeljebb négy szakaszból és szakaszonként legfeljebb nyolc karakterből álló verziószám dekonstruálható. Az elemzett adatok segítségével hasonlítsa össze a verzió korát.
IPv4-címek	parse_ipv4()	IPv4-cím átalakítása hosszú egész számmá. Az IPv4-címek konvertálása nélküli összehasonlításához használja a ipv4_compare() parancsot.
IPv6-címek	parse_ipv6()	Konvertáljon egy IPv4- vagy IPv6-címet a canonical IPv6 jelöléssé. Az IPv6-címek összehasonlításához használja a ipv6_compare()-t.

Az összes támogatott elemzési függvényről további információt a Kusto-sztringfüggvényekről szóló témakörben olvashat.

Megjegyzés:

Előfordulhat, hogy a cikkben szereplő táblák némelyike nem érhető el Végponthoz készült Microsoft Defender. Kapcsolja be a Microsoft Defender XDR, hogy több adatforrással keressen fenyegetéseket. A speciális veszélyforrás-keresési munkafolyamatokat Végponthoz készült Microsoft Defender-ról Microsoft Defender XDR-ra helyezheti át a speciális veszélyforrás-keresési lekérdezések áttelepítése Végponthoz készült Microsoft Defender.

Tipp

Szeretne többet megtudni? Lépjen kapcsolatba a Microsoft biztonsági közösségével a technikai közösségünkben: Microsoft Defender XDR Tech Community.

Megosztás a következőn keresztül:

Speciális keresési lekérdezési ajánlott eljárások

A CPU-erőforráskvóták ismertetése

Általános optimalizálási tippek

Az `join` operátor optimalizálása

Az `summarize` operátor optimalizálása

Lekérdezési forgatókönyvek

Egyedi folyamatok azonosítása folyamatazonosítókkal

Lekérdezési parancssorok

Adatok betöltése külső forrásokból

Sztringek elemzése

Visszajelzés

További források

Megosztás a következőn keresztül:

Speciális keresési lekérdezési ajánlott eljárások

A CPU-erőforráskvóták ismertetése

Általános optimalizálási tippek

Az join operátor optimalizálása

Az summarize operátor optimalizálása

Lekérdezési forgatókönyvek

Egyedi folyamatok azonosítása folyamatazonosítókkal

Lekérdezési parancssorok

Adatok betöltése külső forrásokból

Sztringek elemzése

Kapcsolódó témakörök

Visszajelzés

További források

Az `join` operátor optimalizálása

Az `summarize` operátor optimalizálása