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

Microsoft Sentinel-adatok összesítése összefoglaló szabályokkal (előzetes verzió)

  • Cikk
  • A következőre érvényes::
    Microsoft Sentinel in the Azure portal, Microsoft Sentinel in the Microsoft Defender portal

A Microsoft Sentinel összefoglaló szabályaival összesíthet nagy adatkészleteket a háttérben, hogy zökkenőmentesebb biztonsági műveletekhez használhassa az összes naplózási réteget. Az összegző adatok előre le lesznek állítva az egyéni naplótáblákban, és gyors lekérdezési teljesítményt biztosítanak, beleértve az alacsony költségű naplószintekből származó adatokon futtatott lekérdezéseket is. Az összefoglaló szabályok segíthetnek optimalizálni az adatokat a következőkre:

  • Elemzések és jelentések, különösen nagy adathalmazok és időtartományok felett, a biztonsági és incidenselemzéshez, a havi vagy éves üzleti jelentésekhez stb.
  • Költségmegtakarítás a részletes naplókon, amelyeket akár csak egy kevésbé költséges naplószinten is megőrizhet, és összegzett adatokként csak elemzési és jelentéskészítési Elemzési táblába küldhető.
  • Biztonság és adatvédelem az összesített megosztható adatok adatvédelmi adatainak eltávolításával vagy elrejtésével, valamint a nyers adatokkal rendelkező táblákhoz való hozzáférés korlátozásával.

Az összesítő szabály eredményeinek elérése Kusto lekérdezésnyelv (KQL) használatával az észlelési, vizsgálati, vadászati és jelentéskészítési tevékenységek között. Használjon összefoglaló szabályeredményeket hosszabb időszakokra a korábbi vizsgálatokban, a vadászatban és a megfelelőségi tevékenységekben.

Az összefoglaló szabály eredményei külön táblákban vannak tárolva az Analytics-adatcsomagban , és ennek megfelelően kerülnek felszámításra. Az adatcsomagokról és a tárolási költségekről további információt a Log Analytics-munkaterület használati mintáin alapuló táblázatcsomag kiválasztása című témakörben talál .

Fontos

Az összefoglaló szabályok jelenleg előzetes verzióban érhetők el. A Microsoft Azure Előzetes verzió kiegészítő használati feltételeiben további jogi feltételeket talál, amelyek a bétaverzióban, előzetes verzióban vagy más módon még nem általánosan elérhető Azure-funkciókra vonatkoznak.

A Microsoft Sentinel általánosan elérhető a Microsoft egyesített biztonsági üzemeltetési platformján a Microsoft Defender portálon. Előzetes verzióként a Microsoft Sentinel elérhető a Defender portálon Microsoft Defender XDR vagy E5 licenc nélkül. További információ: Microsoft Sentinel a Microsoft Defender portálon.

Előfeltételek

Összefoglaló szabályok létrehozása a Microsoft Sentinelben:

Javasoljuk, hogy a szabály létrehozása előtt kísérletezzen az összefoglaló szabály lekérdezésével a Naplók lapon. Ellenőrizze, hogy a lekérdezés nem éri-e el vagy nem éri-e el a lekérdezési korlátot, és ellenőrizze, hogy a lekérdezés létrehozza-e a kívánt sémát és a várt eredményeket. Ha a lekérdezés közel van a lekérdezési korlátokhoz, érdemes lehet kisebbet binSize használni a kevesebb adat tárolónkénti feldolgozásához. A lekérdezést úgy is módosíthatja, hogy kevesebb rekordot adjon vissza, vagy távolítsa el a nagyobb kötettel rendelkező mezőket.

Összefoglaló szabály létrehozása

Hozzon létre egy új összefoglaló szabályt egy adott nagy adatkészlet dinamikus táblába való összesítéséhez. Konfigurálja a szabály gyakoriságát annak meghatározásához, hogy az összesített adatkészlet milyen gyakran frissül a nyers adatokból.

  1. Az Azure Portal Microsoft Sentinel navigációs menüjében, a Konfiguráció területen válassza az Összefoglaló szabályok (előzetes verzió) lehetőséget. A Defender portálon válassza a Microsoft Sentinel > konfigurációs > összefoglaló szabályai (előzetes verzió) lehetőséget. Példa:

    Képernyőkép az Azure Portal Összefoglaló szabályok lapjáról.

  2. Válassza a + Létrehozás lehetőséget, és adja meg a következő adatokat:

    • Név. Adjon meg egy értelmes nevet a szabálynak.

    • Leírás. Adjon meg egy opcionális leírást.

    • Céltábla. Adja meg azt az egyéni naplótáblát, amelyben az adatok összesítve vannak:

      • Ha a Meglévő egyéni naplótáblát választja, jelölje ki a használni kívánt táblát.

      • Ha az Új egyéni naplótáblát választja, adjon meg egy értelmes nevet a táblának. A teljes táblanév a következő szintaxist használja: <tableName>_CL.

  3. Javasoljuk, hogy engedélyezze a SummaryLogs diagnosztikai beállításait a munkaterületen az előzményfuttatások és hibák láthatóságának érdekében. Ha a SummaryLogs diagnosztikai beállításai nincsenek engedélyezve, a rendszer kérni fogja, hogy engedélyezze őket a Diagnosztikai beállítások területen.

    Ha a SummaryLogs diagnosztikai beállításai már engedélyezve vannak, de módosítani szeretné a beállításokat, válassza a Speciális diagnosztikai beállítások konfigurálása lehetőséget. Amikor visszatér az Összegzés szabály varázsló lapjára, a beállítás részleteinek frissítéséhez mindenképpen válassza a Frissítés lehetőséget.

    Fontos

    A SummaryLogs diagnosztikai beállításai további költségekkel járnak. További információ: Diagnosztikai beállítások az Azure Monitorban.

  4. Válassza a Tovább elemet : Az összefoglaló logika > beállítása a folytatáshoz.

  5. Az Összegző logika beállítása lapon adja meg az összegző lekérdezést. Ha például a Google Cloud Platformról szeretne tartalmat lekérni, a következőt érdemes megadnia:

    GCPAuditLogs
| where ServiceName == 'pubsub.googleapis.com'
| summarize count() by Severity

    További információkért tekintse meg a minta összefoglaló szabályforgatókönyveit és Kusto lekérdezésnyelv (KQL) az Azure Monitorban.

  6. Az Előnézeti eredmények lehetőséget választva megjelenítheti a konfigurált lekérdezéssel gyűjtött adatok példáját.

  7. A Lekérdezés ütemezési területén adja meg a következő részleteket:

    • Milyen gyakran szeretné futtatni a szabályt?
    • Akár azt szeretné, hogy a szabály bármilyen késleltetéssel fusson, percek alatt
    • Ha azt szeretné, hogy a szabály elinduljon

    Az ütemezésben meghatározott időpontok az timegenerated adatok oszlopán alapulnak

  8. Válassza a Tovább elemet: Áttekintés + Mentés létrehozása>> az összefoglaló szabály végrehajtásához.

A meglévő összefoglaló szabályok az Összefoglaló szabályok (előzetes verzió) lapon jelennek meg, ahol áttekintheti a szabály állapotát. Minden szabály esetében válassza a sor végén található beállítások menüt az alábbi műveletek végrehajtásához:

  • A szabály aktuális adatainak megtekintése a Naplók lapon, mintha azonnal futtatta volna a lekérdezést
  • A kijelölt szabály futtatási előzményeinek megtekintése
  • Tiltsa le vagy engedélyezze a szabályt.
  • A szabálykonfiguráció szerkesztése

Szabály törléséhez jelölje ki a szabálysort, majd válassza a Törlés lehetőséget a lap tetején található eszköztáron.

Feljegyzés

Az Azure Monitor az API-n vagy az Azure Resource Monitor-sablonon keresztül is támogatja az összefoglaló szabályok létrehozását. További információ: Összefoglaló szabály létrehozása vagy frissítése.

Mintaösszegző szabályforgatókönyvek

Ez a szakasz áttekinti az összefoglaló szabályok Microsoft Sentinelben való létrehozásának gyakori forgatókönyveit, valamint az egyes szabályok konfigurálására vonatkozó javaslatainkat. További információt és példákat a Kiegészítő naplók betöltéséhez használható összefoglaló szabályok használata segédnaplókkal (mintafolyamattal) és naplóforrásokkal című témakörben talál.

Rosszindulatú IP-cím gyors megkeresése a hálózati forgalomban

Forgatókönyv: Ön fenyegetésvadász, és a csapat egyik célja, hogy azonosítsa azokat a példányokat, amikor egy rosszindulatú IP-cím egy aktív incidens hálózati forgalmi naplóiban kommunikált az elmúlt 90 napban.

Kihívás: A Microsoft Sentinel jelenleg naponta több terabájtnyi hálózati naplót használ be. Gyorsan át kell lépnie rajtuk, hogy megtalálja a rosszindulatú IP-cím egyezéseit.

Megoldás: A következők végrehajtásához javasoljuk az összefoglaló szabályok használatát:

  1. Hozzon létre egy összefoglaló adatkészletet az incidenshez kapcsolódó ip-címekhez, beleértve a SourceIP, DestinationIP, MaliciousIP, RemoteIP, minden fontos attribútumot, például IPType, FirstTimeSeenés LastTimeSeen.

    Az összefoglaló adatkészlettel gyorsan kereshet egy adott IP-címet, és szűkítheti az IP-cím helyét. Ezt akkor is megteheti, ha a keresett események több mint 90 nappal ezelőtt történtek, ami meghaladja a munkaterület megőrzési idejét.

    Ebben a példában úgy konfigurálja az összegzést, hogy naponta fusson, hogy a lekérdezés minden nap új összegző rekordokat adjon hozzá, amíg el nem jár.

  2. Hozzon létre egy olyan elemzési szabályt , amely kevesebb mint két percig fut az összefoglaló adathalmazon, és gyorsan befúrja az adott időtartományba, amikor a rosszindulatú IP-cím kommunikál a vállalati hálózattal.

    Ügyeljen arra, hogy legalább öt perces futási időközöket konfiguráljon a különböző összegző hasznos adatok méretének megfelelően. Ez biztosítja, hogy az eseménybetöltés késleltetése esetén se csökken a veszteség.

    Példa:

    let csl_columnmatch=(column_name: string) {
summarized_CommonSecurityLog
| where isnotempty(column_name)
| extend
    Date = format_datetime(TimeGenerated, "yyyy-MM-dd"),
    IPaddress = column_ifexists(column_name, ""),
    FieldName = column_name
| extend IPType = iff(ipv4_is_private(IPaddress) == true, "Private", "Public")
| where isnotempty(IPaddress)
| project Date, TimeGenerated, IPaddress, FieldName, IPType, DeviceVendor
| summarize count(), FirstTimeSeen = min(TimeGenerated), LastTimeSeen = min(TimeGenerated) by Date, IPaddress, FieldName, IPType, DeviceVendor
};
union csl_columnmatch("SourceIP")
    , csl_columnmatch("DestinationIP") 
    , csl_columnmatch("MaliciousIP")
    , csl_columnmatch("RemoteIP")
// Further summarization can be done per IPaddress to remove duplicates per day on larger timeframe for the first run
| summarize make_set(FieldName), make_set(DeviceVendor) by IPType, IPaddress

  3. Futtasson egy későbbi keresést vagy korrelációt más adatokkal a támadási történet befejezéséhez.

Riasztások létrehozása a hálózati adatok fenyegetésintelligencia-egyezéséről

Riasztásokat hozhat létre a fenyegetésintelligencia-egyezésekkel kapcsolatban a zajos, nagy mennyiségű és alacsony biztonsági értékű hálózati adatokkal szemben.

Forgatókönyv: Létre kell készítenie egy elemzési szabályt a tűzfalnaplókhoz, hogy azok megfeleljenek a rendszer azon tartományneveinek, amelyeket egy fenyegetésintelligencia-tartománynévlistával kerestek fel.

A legtöbb adatforrás nyers napló, amely zajos és nagy mennyiségű, de alacsonyabb biztonsági értékkel rendelkezik, beleértve az IP-címeket, az Azure Firewall-forgalmat, a Forgalom letiltását stb. A teljes mennyiség körülbelül 1 TB naponta.

Kihívás: A különálló szabályok létrehozásához több logikai alkalmazásra van szükség, ami további beállítási és karbantartási többletterhelést és költségeket igényel.

Megoldás: A következők végrehajtásához javasoljuk az összefoglaló szabályok használatát:

  1. Összefoglaló szabály létrehozása:

    1. Bővítse ki a lekérdezést, hogy kinyerje a kulcsmezőket, például a forráscímet, a célcímet és a célportot a CommonSecurityLog_CL táblából, amely a CommonSecurityLog és a Kiegészítő csomag.

    2. Végezzen belső kereséseket az aktív fenyegetésintelligencia-mutatókon a forráscímünkkel való egyezések azonosításához. Ez lehetővé teszi, hogy ismert fenyegetésekkel hivatkozzon az adatokra.

    3. A projekt releváns információi, beleértve a létrehozott időt, a tevékenység típusát és a rosszindulatú forrás IP-címeket, valamint a céladatokat. Adja meg a lekérdezés futtatásának gyakoriságát, valamint a céltáblát, például a MaliciousIPDetection értéket. A táblázatban szereplő eredmények elemzési szinten vannak, és ennek megfelelően kerülnek felszámításra.

  2. Riasztás létrehozása:

    Létrehoz egy elemzési szabályt a Microsoft Sentinelben, amely a MaliciousIPDetection tábla eredményei alapján riasztásokat küld. Ez a lépés kulcsfontosságú a proaktív fenyegetésészlelés és incidenskezelés szempontjából.

Mintaösszegző szabály:

CommonSecurityLog_CL​
| extend sourceAddress = tostring(parse_json(Message).sourceAddress), destinationAddress = tostring(parse_json(Message).destinationAddress), destinationPort = tostring(parse_json(Message).destinationPort)​
| lookup kind=inner (ThreatIntelligenceIndicator | where Active == true ) on $left.sourceAddress == $right.NetworkIP​
| project TimeGenerated, Activity, Message, DeviceVendor, DeviceProduct, sourceMaliciousIP =sourceAddress, destinationAddress, destinationPort

Összefoglaló szabályok használata kiegészítő naplókkal (mintafolyamat)

Ez az eljárás egy mintafolyamatot ír le az összefoglaló szabályok kiegészítő naplókkal való használatára, egy ARM-sablonon keresztül létrehozott egyéni kapcsolat használatával a CEF-adatok Logstashból való betöltéséhez.

  1. Egyéni CEF-összekötő beállítása a Logstashből:

    1. Helyezze üzembe a következő ARM-sablont a Microsoft Sentinel-munkaterületen, hogy létrehozhasson egy egyéni táblát adatgyűjtési szabályokkal (DCR) és egy adatgyűjtési végponttal (DCE):

      Üzembe helyezés az Azure-ban

    2. Jegyezze fel a következő részleteket az ARM-sablon kimenetéből:

      • tenant_id
      • data_collection_endpoint
      • dcr_immutable_id
      • dcr_stream_name

    3. Hozzon létre egy Microsoft Entra-alkalmazást, és jegyezze fel az alkalmazás ügyfél-azonosítóját és titkos kódját. További információ : Oktatóanyag: Adatok küldése az Azure Monitor-naplókba a Logs Ingestion API-val (Azure Portal).

    4. Használja a mintaszkriptet a Logstash konfigurációs fájljának frissítéséhez. A frissítések úgy konfigurálják a Logstash-t, hogy CEF-naplókat küldjenek az ARM-sablon által létrehozott egyéni táblába, és átalakítják a JSON-adatokat DCR formátumba. Ebben a szkriptben mindenképpen cserélje le a helyőrző értékeket a korábban létrehozott egyéni tábla és Microsoft Entra-alkalmazás saját értékeire.

  2. Ellenőrizze, hogy a CEF-adatok a várt módon haladnak-e a Logstashból. A Microsoft Sentinelben például lépjen a Naplók lapra, és futtassa a következő lekérdezést:

    CefAux_CL
| take 10

  3. A CEF-adatokat összesítő összefoglaló szabályok létrehozása. Példa:

    • Aggodalomra okot adó keresési incidens (IoC) adatai: Adott IoC-k keresése összesített összegző lekérdezések futtatásával egyedi előfordulásokat eredményez, majd csak azokat az előfordulásokat kérdezi le a gyorsabb eredmények érdekében. Az alábbi példa egy példát mutat be arra, hogyan hozhat létre egyedi Source Ip hírcsatornát más metaadatokkal együtt, amelyeket aztán használhat az IoC-keresésekhez:

      // Daily Network traffic trend Per Destination IP along with Data transfer stats 
// Frequency - Daily - Maintain 30 day or 60 Day History. 
  Custom_CommonSecurityLog 
  | extend Day = format_datetime(TimeGenerated, "yyyy-MM-dd") 
  | summarize Count= count(), DistinctSourceIps = dcount(SourceIP), NoofByesTransferred = sum(SentBytes), NoofBytesReceived = sum(ReceivedBytes)  
  by Day,DestinationIp, DeviceVendor

    • Az anomáliadetektálások összegzési alapkonfigurációjának lekérdezése. Ahelyett, hogy nagy előzményidőszakokon , például 30 vagy 60 napon keresztül futtatja a lekérdezéseket, javasoljuk, hogy az adatokat egyéni naplókba töltse be, majd csak a lekérdezések összegzési alapadatait, például az idősor-anomáliadetektálásokhoz. Példa:

      // Time series data for Firewall traffic logs 
let starttime = 14d; 
let endtime = 1d; 
let timeframe = 1h; 
let TimeSeriesData =  
Custom_CommonSecurityLog 
  | where TimeGenerated between (startofday(ago(starttime))..startofday(ago(endtime))) 
  | where isnotempty(DestinationIP) and isnotempty(SourceIP) 
  | where ipv4_is_private(DestinationIP) == false 
  | project TimeGenerated, SentBytes, DeviceVendor 
  | make-series TotalBytesSent=sum(SentBytes) on TimeGenerated from startofday(ago(starttime)) to startofday(ago(endtime)) step timeframe by DeviceVendor

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

A KQL-ről további információt a Kusto lekérdezésnyelv (KQL) áttekintésében talál.

Egyéb erőforrások:

Kapcsolódó tartalom