Loggkvarhållningsplaner i Microsoft Sentinel
Det finns två konkurrerande aspekter av logginsamling och kvarhållning som är viktiga för ett lyckat program för hotidentifiering. Å ena sidan vill du maximera antalet loggkällor som du samlar in, så att du får så omfattande säkerhetstäckning som möjligt. Å andra sidan måste du minimera kostnaderna för inmatning av alla dessa data.
Dessa konkurrerande behov kräver en logghanteringsstrategi som balanserar datatillgänglighet, frågeprestanda och lagringskostnader.
I den här artikeln beskrivs kategorier av data och de kvarhållningstillstånd som används för att lagra och komma åt dina data. Den beskriver även de loggplaner som Microsoft Sentinel erbjuder dig att skapa en strategi för logghantering och kvarhållning.
Viktigt!
Loggtypen Tilläggsloggar finns för närvarande i FÖRHANDSVERSION. Se kompletterande användningsvillkor för Förhandsversioner av Microsoft Azure för ytterligare juridiska villkor som gäller för Azure-funktioner som är i betaversion, förhandsversion eller på annat sätt ännu inte har släppts i allmän tillgänglighet.
Microsoft Sentinel är nu allmänt tillgängligt på Microsofts plattform för enhetliga säkerhetsåtgärder i Microsoft Defender-portalen. Mer information finns i Microsoft Sentinel i Microsoft Defender-portalen.
Kategorier av inmatade data
Microsoft rekommenderar att du klassificerar data som matas in i Microsoft Sentinel i två allmänna kategorier:
Primära säkerhetsdata är data som innehåller kritiskt säkerhetsvärde. Dessa data används för proaktiv övervakning i realtid, schemalagda aviseringar och analys för att identifiera säkerhetshot. Data måste vara lättillgängliga för alla Microsoft Sentinel-upplevelser nästan i realtid.
Sekundära säkerhetsdata är kompletterande data, ofta i utförliga loggar med hög volym. Dessa data har ett begränsat säkerhetsvärde, men de kan ge ökad rikedom och kontext till identifieringar och undersökningar, vilket hjälper till att skapa en fullständig bild av en säkerhetsincident. Det behöver inte vara lättillgängligt, men bör vara tillgängligt på begäran efter behov och i lämpliga doser.
Primära säkerhetsdata
Den här kategorin består av loggar som har ett kritiskt säkerhetsvärde för din organisation. Primära säkerhetsdata kan beskrivas av följande användningsfall för säkerhetsåtgärder:
Frekvent övervakning. Hotidentifieringsregler (analys) körs på dessa data med jämna mellanrum eller nästan i realtid.
Jakt på begäran. Komplexa frågor körs på dessa data för att köra interaktiv, högpresterande jakt på säkerhetshot.
Korrelation. Data från dessa källor korreleras med data från andra primära säkerhetsdatakällor för att identifiera hot och skapa attackberättelser.
Regelbunden rapportering. Data från dessa källor är lättillgängliga för kompilering till regelbundna rapporter om organisationens säkerhetshälsa, både för säkerhets- och allmänna beslutsfattare.
Beteendeanalys. Data från dessa källor används för att skapa baslinjebeteendeprofiler för dina användare och enheter, så att du kan identifiera beteenden som misstänkta.
Några exempel på primära datakällor är loggar från antivirus- eller företagsidentifierings- och svarssystem (EDR), autentiseringsloggar, spårningsloggar från molnplattformar, hotinformationsflöden och aviseringar från externa system.
Loggar som innehåller primära säkerhetsdata bör lagras med hjälp av analysloggplanen som beskrivs senare i den här artikeln.
Sekundära säkerhetsdata
Den här kategorin omfattar loggar vars individuella säkerhetsvärde är begränsat men som är viktiga för att tillhandahålla en heltäckande vy över en säkerhetsincident eller ett intrång. Dessa loggar är vanligtvis stora och kan vara utförliga. Användningsfallen för säkerhetsåtgärder för dessa data omfattar följande:
Hotinformation. Primära data kan kontrolleras mot listor över indikatorer för kompromiss (IoC) eller indikatorer för angrepp (IoA) för att snabbt och enkelt identifiera hot.
Ad hoc-jakt/utredningar. Data kan efterfrågas interaktivt i 30 dagar, vilket underlättar avgörande analys för hotjakt och undersökningar.
Storskaliga sökningar. Data kan matas in och sökas i bakgrunden i petabyteskala, samtidigt som de lagras effektivt med minimal bearbetning.
Sammanfattning via sammanfattningsregler. Sammanfatta loggar med stora volymer i aggregerad information och lagra resultatet som primära säkerhetsdata. Mer information om sammanfattningsregler finns i Aggregera Microsoft Sentinel-data med sammanfattningsregler.
Några exempel på sekundära dataloggkällor är åtkomstloggar för molnlagring, NetFlow-loggar, TLS/SSL-certifikatloggar, brandväggsloggar, proxyloggar och IoT-loggar. Mer information om hur var och en av dessa källor ger säkerhetsidentifieringar värde utan att behövas hela tiden finns i Loggkällor som ska användas för inmatning av extraloggar.
Loggar som innehåller sekundära säkerhetsdata bör lagras med hjälp av tilläggsloggplanen (nu i förhandsversion) som beskrivs senare i den här artikeln.
För ett alternativ som inte är en förhandsversion kan du använda Grundläggande loggar i stället.
Logghanteringsplaner
Microsoft Sentinel tillhandahåller två olika logglagringsplaner, eller typer, för att hantera dessa kategorier av inmatade data.
Analysloggplanen är utformad för att lagra primära säkerhetsdata och göra dem enkla och ständigt tillgängliga med höga prestanda.
Planen för tilläggsloggar är utformad för att lagra sekundära säkerhetsdata till mycket låg kostnad under långa tidsperioder , samtidigt som den ger begränsad tillgänglighet.
En tredje plan, Grundläggande loggar, är föregångaren till tilläggsloggplanen och kan användas som ersättning för den medan tilläggsloggplanen förblir i förhandsversion.
Var och en av dessa planer bevarar data i två olika tillstånd:
Det interaktiva kvarhållningstillståndet är det ursprungliga tillstånd som data matas in i. Det här tillståndet ger olika åtkomstnivåer till data, beroende på planen, och kostnaderna för det här tillståndet varierar kraftigt, beroende på planen.
Det långsiktiga kvarhållningstillståndet bevarar äldre data i sina ursprungliga tabeller i upp till 12 år, till extremt låg kostnad, oavsett plan.
Mer information om kvarhållningstillstånd finns i Hantera datakvarhållning på en Log Analytics-arbetsyta.
I följande diagram sammanfattas och jämförs dessa två logghanteringsplaner.
Plan för analysloggar
Planen för analysloggar håller data i interaktivt kvarhållningstillstånd i 90 dagar som standard, vilket är utökningsbart i upp till två år. Med det här interaktiva tillståndet, även om det är dyrt, kan du köra frågor mot dina data på ett obegränsat sätt, med höga prestanda, utan kostnad per fråga.
När den interaktiva kvarhållningsperioden är slut hamnar data i det långsiktiga kvarhållningstillståndet, samtidigt som de finns kvar i den ursprungliga tabellen. Den långsiktiga kvarhållningsperioden definieras inte som standard, men du kan definiera att den ska pågå i upp till 12 år. Det här kvarhållningstillståndet bevarar dina data till extremt låg kostnad, i regelefterlevnad eller i interna principsyften. Du kan bara komma åt data i det här tillståndet genom att använda ett sökjobb eller återställa för att hämta begränsade uppsättningar data till en ny tabell i interaktiv kvarhållning, där du kan använda de fullständiga frågefunktionerna.
Plan för tilläggsloggar
Planen för extraloggar behåller data i interaktivt kvarhållningstillstånd i 30 dagar. I hjälpplanen har det här tillståndet mycket låga kvarhållningskostnader jämfört med Analysplanen. Frågefunktionerna är dock begränsade: frågor debiteras per gigabyte data som genomsöks och är begränsade till en enda tabell och prestandan är betydligt lägre. Även om dessa data fortfarande är i interaktivt kvarhållningstillstånd kan du köra sammanfattningsregler på dessa data för att skapa tabeller med aggregerade sammanfattningsdata i analysloggplanen, så att du har de fullständiga frågefunktionerna för dessa aggregerade data.
När den interaktiva kvarhållningsperioden är slut hamnar data i det långsiktiga kvarhållningstillståndet och finns kvar i den ursprungliga tabellen. Långsiktig kvarhållning i tilläggsloggplanen liknar långsiktig kvarhållning i analysloggplanen, förutom att det enda alternativet för att komma åt data är med ett sökjobb. Återställning stöds inte för tilläggsloggplanen.
Grundläggande loggplan
En tredje plan, som kallas Grundläggande loggar, har liknande funktioner som planen för extra loggar, men till en högre interaktiv kvarhållningskostnad (men inte lika hög som analysloggplanen). Även om den extra loggplanen förblir i förhandsversion kan grundläggande loggar vara ett alternativ för långsiktig kvarhållning till låg kostnad om din organisation inte använder förhandsversionsfunktioner. Mer information om den grundläggande loggplanen finns i Tabellplaner i Azure Monitor-dokumentationen.
Relaterat innehåll
En mer djupgående jämförelse av loggdataplaner och mer allmän information om loggtyper finns i Översikt över Azure Monitor-loggar | Tabellplaner.
Information om hur du konfigurerar en tabell i tilläggsloggplanen finns i Konfigurera en tabell med hjälpplanen på Log Analytics-arbetsytan (förhandsversion).
Mer information om kvarhållningsperioder – som finns i planer – finns i Hantera datakvarhållning på en Log Analytics-arbetsyta.