Logboekretentieplannen in Microsoft Sentinel
Er zijn twee concurrerende aspecten van het verzamelen en bewaren van logboeken die essentieel zijn voor een succesvol programma voor detectie van bedreigingen. Aan de ene kant wilt u het aantal logboekbronnen dat u verzamelt maximaliseren, zodat u de meest uitgebreide beveiligingsdekking mogelijk hebt. Aan de andere kant moet u de kosten die worden gemaakt door de opname van al die gegevens minimaliseren.
Deze concurrerende behoeften vereisen een strategie voor logboekbeheer die de toegankelijkheid van gegevens, queryprestaties en opslagkosten in balans brengt.
In dit artikel worden categorieën gegevens en de bewaarstatussen besproken die worden gebruikt voor het opslaan en openen van uw gegevens. Ook worden de logboekplannen beschreven die Microsoft Sentinel u biedt om een strategie voor logboekbeheer en -retentie te bouwen.
Belangrijk
Het logboektype Hulplogboek bevindt zich momenteel in PREVIEW. Zie de aanvullende gebruiksvoorwaarden voor Microsoft Azure Previews voor aanvullende juridische voorwaarden die van toepassing zijn op Azure-functies die bèta, preview of anderszins nog niet beschikbaar zijn.
Microsoft Sentinel is nu algemeen beschikbaar in het geïntegreerde Microsoft Security Operations-platform in de Microsoft Defender-portal. Zie Microsoft Sentinel in de Microsoft Defender-portal voor meer informatie.
Categorieën opgenomen gegevens
Microsoft raadt aan om gegevens die zijn opgenomen in Microsoft Sentinel te classificeren in twee algemene categorieën:
Primaire beveiligingsgegevens zijn gegevens die kritieke beveiligingswaarde bevatten. Deze gegevens worden gebruikt voor realtime proactieve bewaking, geplande waarschuwingen en analyses om beveiligingsrisico's te detecteren. De gegevens moeten in bijna realtime beschikbaar zijn voor alle Microsoft Sentinel-ervaringen.
Secundaire beveiligingsgegevens zijn aanvullende gegevens, vaak in uitgebreide logboeken met grote volumes. Deze gegevens hebben een beperkte beveiligingswaarde, maar kunnen extra rijkdom en context bieden voor detecties en onderzoeken, waardoor het volledige beeld van een beveiligingsincident kan worden getekend. Het hoeft niet direct beschikbaar te zijn, maar moet indien nodig en in de juiste doses toegankelijk zijn.
Primaire beveiligingsgegevens
Deze categorie bestaat uit logboeken die kritieke beveiligingswaarde voor uw organisatie bevatten. Primaire beveiligingsgegevens kunnen worden beschreven in de volgende use cases voor beveiligingsbewerkingen:
Frequente bewaking. Regels voor detectie van bedreigingen (analyse) worden met regelmatige intervallen of in bijna realtime uitgevoerd op deze gegevens.
Opsporing op aanvraag. Complexe query's worden uitgevoerd op deze gegevens om interactieve, krachtige opsporing van beveiligingsrisico's uit te voeren.
Correlatie. Gegevens uit deze bronnen zijn gecorreleerd met gegevens uit andere primaire beveiligingsgegevensbronnen om bedreigingen te detecteren en verhalen over aanvallen te bouwen.
Regelmatige rapportage. Gegevens uit deze bronnen zijn direct beschikbaar voor het compileren in regelmatige rapporten van de beveiligingsstatus van de organisatie, zowel voor beveiliging als voor algemene besluitvormers.
Gedragsanalyse. Gegevens uit deze bronnen worden gebruikt om basislijngedragsprofielen te bouwen voor uw gebruikers en apparaten, zodat u het gedrag van uitval als verdacht kunt identificeren.
Enkele voorbeelden van primaire gegevensbronnen zijn logboeken van antivirus- of EDR-systemen (Enterprise Detection and Response), verificatielogboeken, audittrails van cloudplatforms, feeds voor bedreigingsinformatie en waarschuwingen van externe systemen.
Logboeken met primaire beveiligingsgegevens moeten worden opgeslagen met behulp van het analyselogboekplan dat verderop in dit artikel wordt beschreven.
Secundaire beveiligingsgegevens
Deze categorie omvat logboeken waarvan de afzonderlijke beveiligingswaarde beperkt is, maar essentieel zijn voor een uitgebreide weergave van een beveiligingsincident of schending. Deze logboeken zijn meestal groot en kunnen uitgebreid zijn. De use cases voor beveiligingsbewerkingen voor deze gegevens zijn onder andere:
Informatie over bedreigingen. Primaire gegevens kunnen worden gecontroleerd op lijsten met Indicators of Compromise (IoC) of Indicators of Attack (IoA) om snel en eenvoudig bedreigingen te detecteren.
Ad-hoc opsporing/onderzoeken. Gegevens kunnen 30 dagen interactief worden opgevraagd, waardoor cruciale analyse voor opsporing en onderzoeken van bedreigingen wordt vergemakkelijkt.
Grootschalige zoekopdrachten. Gegevens kunnen op petabyteschaal op de achtergrond worden opgenomen en doorzocht, terwijl ze efficiënt worden opgeslagen met minimale verwerking.
Samenvatting via samenvattingsregels. Samenvatting van logboeken met grote volumes in geaggregeerde informatie en sla de resultaten op als primaire beveiligingsgegevens. Zie Microsoft Sentinel-gegevens aggregeren met samenvattingsregels voor meer informatie over samenvattingsregels.
Enkele voorbeelden van secundaire gegevenslogboekbronnen zijn logboeken voor toegang tot cloudopslag, NetFlow-logboeken, TLS/SSL-certificaatlogboeken, firewalllogboeken, proxylogboeken en IoT-logboeken. Zie Logboekbronnen die moeten worden gebruikt voor opname van hulplogboeken voor meer informatie over hoe elk van deze bronnen waarde biedt voor beveiligingsdetecties zonder dat u ze altijd nodig hebt.
Logboeken met secundaire beveiligingsgegevens moeten worden opgeslagen met behulp van het hulplogboekplan (nu in preview) dat verderop in dit artikel wordt beschreven.
Voor een niet-preview-optie kunt u in plaats daarvan Basislogboeken gebruiken.
Logboekbeheerplannen
Microsoft Sentinel biedt twee verschillende logboekopslagplannen of -typen voor deze categorieën opgenomen gegevens.
Het plan voor analyselogboeken is ontworpen om primaire beveiligingsgegevens op te slaan en deze eenvoudig en voortdurend toegankelijk te maken bij hoge prestaties.
Het plan hulplogboeken is ontworpen voor het opslaan van secundaire beveiligingsgegevens tegen zeer lage kosten gedurende lange tijd, terwijl beperkte toegankelijkheid nog steeds mogelijk is.
Een derde plan, Basislogboeken, is de voorafgaande van het hulplogboekplan en kan worden gebruikt als vervanging voor het plan, terwijl het hulplogboekplan in preview blijft.
Elk van deze plannen behoudt gegevens in twee verschillende statussen:
De interactieve bewaarstatus is de initiële status waarin de gegevens worden opgenomen. Met deze status kunnen verschillende toegangsniveaus tot de gegevens worden toegestaan, afhankelijk van het plan en de kosten voor deze status variëren sterk, afhankelijk van het plan.
De langetermijnretentiestatus bewaart oudere gegevens in de oorspronkelijke tabellen tot 12 jaar, tegen extreem lage kosten, ongeacht het plan.
Zie Gegevensretentie beheren in een Log Analytics-werkruimte voor meer informatie over retentiestatussen.
In het volgende diagram worden deze twee logboekbeheerplannen samengevat en vergeleken.
Plan voor analyselogboeken
Het plan voor analytics-logboeken bewaart gegevens standaard gedurende 90 dagen in de interactieve bewaarstatus, die maximaal twee jaar kan worden uitgebreid. Met deze interactieve status kunt u op onbeperkte wijze query's uitvoeren op uw gegevens, met hoge prestaties, zonder kosten per query.
Wanneer de interactieve bewaarperiode afloopt, worden gegevens in de langetermijnretentiestatus geplaatst, terwijl ze in de oorspronkelijke tabel blijven. De langetermijnretentieperiode is niet standaard gedefinieerd, maar u kunt deze definiëren tot maximaal 12 jaar. Deze bewaarstatus behoudt uw gegevens tegen extreem lage kosten, voor naleving van regelgeving of interne beleidsdoeleinden. U kunt alleen toegang krijgen tot de gegevens in deze status door een zoektaak te gebruiken of te herstellen om beperkte gegevenssets op te halen in een nieuwe tabel in interactieve retentie, waar u de volledige querymogelijkheden kunt gebruiken.
Plan voor hulplogboeken
Het plan Hulplogboeken bewaart gegevens gedurende 30 dagen in de interactieve bewaarstatus. In het hulpplan heeft deze status zeer lage bewaarkosten in vergelijking met het Analytics-plan. De querymogelijkheden zijn echter beperkt: query's worden in rekening gebracht per gigabyte aan gescande gegevens en zijn beperkt tot één tabel en de prestaties zijn aanzienlijk lager. Hoewel deze gegevens de interactieve bewaarstatus hebben, kunt u samenvattingsregels op deze gegevens uitvoeren om tabellen met geaggregeerde, overzichtsgegevens te maken in het analyselogboekplan, zodat u de volledige querymogelijkheden voor deze geaggregeerde gegevens hebt.
Wanneer de interactieve bewaarperiode afloopt, worden gegevens in de langetermijnretentiestatus geplaatst, die in de oorspronkelijke tabel blijft. Langetermijnretentie in het hulplogboekplan is vergelijkbaar met langetermijnretentie in het analyselogboekplan, behalve dat de enige optie voor toegang tot de gegevens is met een zoektaak. Herstellen wordt niet ondersteund voor het hulplogboekplan.
Basislogboekenplan
Een derde plan, ook wel Basic-logboeken genoemd, biedt vergelijkbare functionaliteit als het hulplogboekplan, maar met een hogere interactieve retentiekosten (hoewel niet zo hoog als het analyselogboekplan). Hoewel het plan voor hulplogboeken in preview blijft, kunnen basislogboeken een optie zijn voor langetermijnretentie met lage kosten als uw organisatie geen preview-functies gebruikt. Zie Tabelplannen in de Documentatie van Azure Monitor voor meer informatie over het basislogboekplan .
Gerelateerde inhoud
Voor een uitgebreidere vergelijking van logboekgegevensplannen en meer algemene informatie over logboektypen, raadpleegt u het overzicht van Azure Monitor-logboeken | Tabelplannen.
Zie Een tabel instellen met het hulpplan in uw Log Analytics-werkruimte (preview) als u een tabel wilt instellen in het hulplogboekplan.
Zie Gegevensretentie beheren in een Log Analytics-werkruimte voor meer informatie over bewaarperioden( die in verschillende plannen bestaan).