Splunk-észlelési szabályok migrálása a Microsoft Sentinelbe

A Splunk-észlelési szabályok olyan biztonsági információk és eseménykezelési (SIEM) összetevők, amelyek összehasonlítják a Microsoft Sentinel elemzési szabályait. Ez a cikk azokat a fogalmakat ismerteti, amelyek azonosítják, összehasonlítják és migrálják őket a Microsoft Sentinelbe. A legjobb módszer az, ha a SIEM migrálási felületével kezdjük, amely a beépített (OOTB) elemzési szabályokat azonosítja, amelyek automatikusan lefordíthatóak.

Ha át szeretné migrálni a Splunk Megfigyelhetőség üzembe helyezését, tudjon meg többet arról, hogyan migrálhat a Splunkból az Azure Monitor-naplókba.

Naplózási szabályok

A Microsoft Sentinel gépi tanulási analitikát használ a magas megbízhatóságú és végrehajtható incidensek létrehozásához. Egyes meglévő Splunk-észlelések redundánsak lehetnek a Microsoft Sentinelben, ezért ne migrálja őket vakon. Tekintse át ezeket a szempontokat a meglévő észlelési szabályok azonosításakor.

• Ügyeljen arra, hogy olyan használati eseteket válasszon, amelyek indokolják a szabálymigrálást, figyelembe véve az üzleti prioritást és a hatékonyságot.
• Ellenőrizze, hogy ismeri-e a Microsoft Sentinel-szabálytípusokat.
• Ellenőrizze, hogy ismeri-e a szabály terminológiát.
• Tekintse át az elavult szabályokat, amelyek nem rendelkeznek riasztásokkal az elmúlt 6–12 hónapban, és állapítsa meg, hogy továbbra is relevánsak-e.
• Kiküszöbölheti azokat az alacsony szintű fenyegetéseket vagy riasztásokat, amelyeket rendszeresen figyelmen kívül hagy.
• Erősítse meg a csatlakoztatott adatforrásokat, és tekintse át az adatkapcsolati módszereket. A Microsoft Sentinel Analytics megköveteli, hogy az adattípus jelen legyen a Log Analytics-munkaterületen egy szabály engedélyezése előtt. Az adatgyűjtési beszélgetések újbóli megtekintése az észlelni kívánt használati esetek adatmélységének és szélességének biztosítása érdekében. Ezután a SIEM migrálási felületével győződjön meg arról, hogy az adatforrások megfelelően vannak leképezve.

Szabályok migrálása

Miután azonosította a migrálni kívánt Splunk-észleléseket, tekintse át az áttelepítési folyamat alábbi szempontjait:

• Hasonlítsa össze a Microsoft Sentinel OOTB-elemzési szabályainak meglévő funkcióit az aktuális használati esetekkel. A SIEM migrálási felületével megtekintheti, hogy mely Splunk-észlelések lesznek automatikusan OOTB-sablonokká konvertálva.
• Olyan észlelések fordítása, amelyek nem igazodnak az OOTB-elemzési szabályokhoz. A Splunk-észlelések automatikus lefordításának legjobb módja a SIEM migrálási felülete.
• További algoritmusokat fedezhet fel a használati esetekhez olyan közösségi erőforrások feltárásával, mint például az SOC Prime Threat Detection Marketplace.
• Az észlelések manuális fordítása, ha a beépített szabályok nem érhetők el, vagy nem lesznek automatikusan lefordítva. Hozza létre az új KQL-lekérdezéseket, és tekintse át a szabályok leképezését.

További információkért tekintse meg az észlelési szabályok migrálásának ajánlott eljárásait.

Szabálymigrálási lépések

1. Ellenőrizze, hogy minden áttelepítendő szabályhoz rendelkezik-e tesztelési rendszerrel.

   1. Készítsen elő egy érvényesítési folyamatot a migrált szabályokhoz, beleértve a teljes tesztelési forgatókönyveket és szkripteket.

   2. Győződjön meg arról, hogy csapata hasznos erőforrásokkal rendelkezik a migrált szabályok teszteléséhez.

   3. Győződjön meg arról, hogy a szükséges adatforrások csatlakoztatva vannak, és tekintse át az adatkapcsolati módszereket.

2. Ellenőrizze, hogy az észlelések OOTB-sablonokként érhetők-e el a Microsoft Sentinelben:

   • A SIEM migrálási felületével automatizálhatja az OOTB-sablonok fordítását és telepítését.

     További információ: A SIEM migrálási felületének használata.

   • Ha olyan eseteket használ, amelyek nem tükröződnek az észlelésekben, hozzon létre szabályokat a saját munkaterületéhez OOTB-szabálysablonokkal.

     A Microsoft Sentinelben nyissa meg a Content Hubot.

     Az Analytics-szabálysablonok tartalomtípusának szűrése.

     Keresse meg és telepítse/frissítse az egyes tartalomközpont-megoldásokat vagy önálló elemzési szabálysablonokat.

     További információ: Veszélyforrások észlelése beépítetten.

   • Ha olyan észlelésekkel rendelkezik, amelyekre nem vonatkoznak a Microsoft Sentinel OOTB-szabályai, először próbálja ki a SIEM migrálási felületét az automatikus fordításhoz.

   • Ha sem az OOTB-szabályok, sem az SIEM-migrálás nem fordítja le teljesen az észlelést, hozza létre manuálisan a szabályt. Ilyen esetekben a következő lépésekkel hozhatja létre a szabályt:

     1. Azonosítsa a szabályban használni kívánt adatforrásokat. Az adatforrások és adattáblák közötti leképezési tábla létrehozásával azonosíthatja a lekérdezni kívánt Microsoft Sentinel-táblákat.

     2. Azonosítsa az adatokban a szabályokban használni kívánt attribútumokat, mezőket vagy entitásokat .

     3. Azonosítsa a szabályfeltételeket és a logikát. Ebben a szakaszban érdemes lehet mintaként megtalálni a szabálysablonokat a KQL-lekérdezések létrehozásához.

        Fontolja meg a szűrőket, korrelációs szabályokat, aktív listákat, referenciakészleteket, figyelőlistákat, észlelési rendellenességeket, összesítéseket stb. Az örökölt SIEM-hez megadott hivatkozásokkal megtudhatja , hogyan képezheti le legjobban a lekérdezés szintaxisát.

     4. Azonosítsa az eseményindító feltételt és a szabályműveletet, majd hozza létre és tekintse át a KQL-lekérdezést. A lekérdezés áttekintésekor fontolja meg a KQL optimalizálási útmutató erőforrásait.

3. Tesztelje a szabályt minden releváns használati esettel. Ha nem adja meg a várt eredményeket, tekintse át és szerkessze a KQL-t, és tesztelje újra.

4. Ha elégedett, fontolja meg a migrált szabályt. Szükség szerint hozzon létre egy forgatókönyvet a szabályművelethez. További információért lásd: A fenyegetésekre való reagálás automatizálása a Microsoft Sentinel forgatókönyveivel.

További információ az elemzési szabályokról:

• Egyéni elemzési szabályok létrehozása a fenyegetések észleléséhez. A riasztások csoportosításával csökkentheti a riasztások kifáradását egy adott időkereten belül előforduló riasztások csoportosításával.
• Adatmezők leképezése a Microsoft Sentinel entitásaihoz annak érdekében, hogy az SOC mérnökei entitásokat definiálhassanak a vizsgálat során nyomon követhető bizonyítékok részeként. Az entitásleképezés lehetővé teszi az SOC-elemzők számára, hogy kihasználják az intuitív [vizsgálati gráf] (investigation-cases.md#use-the-investigation-graph-to-deep-dive) előnyeit, amelyek csökkenthetik az időt és az erőfeszítést.
• Vizsgálja meg az incidenseket UEBA-adatokkal, példaként arra, hogyan lehet bizonyítékokat használni az incidensek, riasztások és az incidens előnézeti paneljén egy adott incidenshez társított könyvjelzők felszínre hozására.
• Kusto lekérdezésnyelv (KQL), amellyel írásvédett kérelmeket küldhet a Log Analytics-adatbázisnak az adatok feldolgozásához és az eredmények visszaadásához. A KQL más Microsoft-szolgáltatások is használható, például Végponthoz készült Microsoft Defender és Application Insights.

Szabály terminológiája összehasonlítása

Ez a táblázat segít tisztázni a Microsoft Sentinelben Kusto lekérdezésnyelv (KQL) alapuló szabály fogalmát a keresési feldolgozási nyelven (SPL) alapuló Splunk-észleléshez képest.

Szabályminták leképezése és összehasonlítása

Ezekkel a mintákkal összehasonlíthatja és megfeleltethet szabályokat a Splunktól a Microsoft Sentinelig különböző helyzetekben.

Gyakori keresési parancsok

lookup parancs: KQL-példa

Users 
| where UserID in ((externaldata (UserID:string) [
@"https://storageaccount.blob.core.windows.net/storagecontainer/users.txt" 
h@"?...SAS..." // Secret token to access the blob 
])) | ... 

stats parancs: KQL-példa

Sales 
| summarize NumTransactions=count(), 
Total=sum(UnitPrice * NumUnits) by Fruit, 
StartOfMonth=startofmonth(SellDateTime) 

mstats parancs: KQL-példa

T | summarize count() by price_range=bin(price, 10.0) 

transaction parancs: SPL-példa

sourcetype=MyLogTable type=Event
| transaction ActivityId startswith="Start" endswith="Stop"
| Rename timestamp as StartTime
| Table City, ActivityId, StartTime, Duration

transaction parancs: KQL-példa

let Events = MyLogTable | where type=="Event";
Events
| where Name == "Start"
| project Name, City, ActivityId, StartTime=timestamp
| join (Events
| where Name == "Stop"
| project StopTime=timestamp, ActivityId)
on ActivityId
| project City, ActivityId, StartTime, 
Duration = StopTime – StartTime

A szerializált sorkészlet egy oszlopának munkamenet-kezdési értékeinek kiszámítására használható row_window_session() .

...| extend SessionStarted = row_window_session(
Timestamp, 1h, 5m, ID != prev(ID))

eventstats parancs: SPL-példa

… | bin span=1m _time
|stats count AS count_i by _time, category
| eventstats sum(count_i) as count_total by _time

eventstats parancs: KQL-példa

Íme egy példa az utasításra join :

let binSize = 1h;
let detail = SecurityEvent 
| summarize detail_count = count() by EventID,
tbin = bin(TimeGenerated, binSize);
let summary = SecurityEvent
| summarize sum_count = count() by 
tbin = bin(TimeGenerated, binSize);
detail 
| join kind=leftouter (summary) on tbin 
| project-away tbin1

Íme egy példa az utasításra make_list :

let binSize = 1m;
SecurityEvent
| where TimeGenerated >= ago(24h)
| summarize TotalEvents = count() by EventID, 
groupBin =bin(TimeGenerated, binSize)
|summarize make_list(EventID), make_list(TotalEvents), 
sum(TotalEvents) by groupBin
| mvexpand list_EventID, list_TotalEvents

anomalydetection parancs: SPL-példa

sourcetype=nasdaq earliest=-10y
| anomalydetection Close _ Price

anomalydetection parancs: KQL-példa

let LookBackPeriod= 7d;
let disableAccountLogon=SignIn
| where ResultType == "50057"
| where ResultDescription has "account is disabled";
disableAccountLogon
| make-series Trend=count() default=0 on TimeGenerated 
in range(startofday(ago(LookBackPeriod)), now(), 1d)
| extend (RSquare,Slope,Variance,RVariance,Interception,
LineFit)=series_fit_line(Trend)
| extend (anomalies,score) = 
series_decompose_anomalies(Trend)

Gyakori eval parancsok

case(X,"Y",…) SPL-példa

case(error == 404, "Not found",
error == 500,"Internal Server Error",
error == 200, "OK")

case(X,"Y",…) KQL-példa

T
| extend Message = case(error == 404, "Not found", 
error == 500,"Internal Server Error", "OK") 

if(X,Y,Z) KQL-példa

iif(floor(Timestamp, 1d)==floor(now(), 1d), 
"today", "anotherday")

isint(X) KQL-példa

iif(gettype(X) =="long","TRUE","FALSE")

isstr(X) KQL-példa

iif(gettype(X) =="string","TRUE","FALSE")

like(X,"y") példa

… | where field has "addr"

… | where field contains "addr"

… | where field startswith "addr"

… | where field matches regex "^addr.*"

min(X,…) KQL-példa

min_of (expr_1, expr_2 ...)

…|summarize min(expr)

…| summarize arg_min(Price,*) by Product

mvfilter(X) KQL-példa

T | mv-apply Metric to typeof(real) on 
(
 top 2 by Metric desc
)

mvjoin(X,Y) KQL-példa

strcat_array(dynamic([1, 2, 3]), "->")

relative time(X,Y) KQL-példa

let toUnixTime = (dt:datetime)
{
(dt - datetime(1970-01-01))/1s 
};

replace(X,Y,Z) KQL-példa

replace( @'^(\d{1,2})/(\d{1,2})/', @'\2/\1/',date)

strptime(X,Y) KQL-példa

format_datetime(datetime('2017-08-16 11:25:10'),
'HH:mm')

time() KQL-példa

format_datetime(datetime(2015-12-14 02:03:04),
'h:m:s')

tostring(X,Y)

Sztringként megadott X mezőértéket ad vissza.

• Ha a szám értéke X egy szám, X akkor a program sztringértékre újraformálja.
• Ha X logikai érték, X akkor a program újraformázva lesz a logikai értékre TRUE vagy FALSEa .
• Ha X szám, akkor a második argumentum Y nem kötelező, és lehet hex (hexadecimálisra konvertálja X ), commas ( X vesszővel és két tizedesjegygel formázza), vagy duration (másodpercek alatt konvertálja X az időformátumot olvasható időformátumra: HH:MM:SS).

tostring(X,Y) SPL-példa

Ez a példa a következőt adja vissza:

foo=615 and foo2=00:10:15:

… | eval foo=615 | eval foo2 = tostring(
foo, "duration")

urldecode(X) SPL-példa

urldecode("http%3A%2F%2Fwww.splunk.com%2Fdownload%3Fr%3Dheader")

Gyakori stats parancsok – KQL-példa

Következő lépések

Ebben a cikkben megtanulta, hogyan képezheti le a migrálási szabályokat a Splunkból a Microsoft Sentinelbe.