Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Viktigt
Anpassade identifieringar är nu det bästa sättet att skapa nya regler i Microsoft Sentinel SIEM-Microsoft Defender XDR. Med anpassade identifieringar kan du minska kostnaderna för inmatning, få obegränsade identifieringar i realtid och dra nytta av sömlös integrering med Defender XDR data, funktioner och reparationsåtgärder med automatisk entitetsmappning. Mer information finns i Anpassade identifieringar är nu det enhetliga sättet att skapa identifieringar i Microsoft Defender XDR.
Microsoft Sentinel analysregler meddelar dig när något misstänkt inträffar i nätverket. Ingen analysregel är perfekt, och det kommer sannolikt att uppstå några falska positiva resultat som måste hanteras. Den här artikeln beskriver hur du hanterar falska positiva identifieringar, antingen med hjälp av automatisering eller genom att ändra regler för schemalagd analys.
Falska positiva orsaker och förebyggande åtgärder
Även i en korrekt byggd analysregel härrör falska positiva identifieringar ofta från specifika entiteter som användare eller IP-adresser som ska undantas från regeln.
Vanliga scenarier är:
- Normala aktiviteter av vissa användare, vanligtvis tjänsteprinciper (automatiserade identiteter som används av applikationer och tjänster), visar ett mönster som verkar misstänkt.
- Avsiktlig säkerhetsgenomsökning som kommer från kända IP-adresser identifieras som skadlig.
- En regel som exkluderar privata IP-adresser bör också undanta vissa interna IP-adresser som inte är privata.
Den här artikeln beskriver två metoder för att undvika falska positiva resultat:
- Automationsregler skapar undantag utan att ändra analysregler.
- Ändringar av schemalagda analysregler tillåter mer detaljerade och permanenta undantag.
I följande tabell beskrivs egenskaperna för varje metod:
| Metod | Karakteristiska |
|---|---|
| Automatiseringsregler |
|
| Ändringar av analysregler |
|
Lägga till undantag med automatiseringsregler (endast Azure Portal)
Följande procedur beskriver hur man lägger till en automationsregel när du ser en falsk positiv-incident. Den här proceduren stöds endast i Azure Portal.
Om Microsoft Sentinel registreras i Defender-portalen skapar du automatiseringsregler från grunden baserat på information om din incident. Mer information finns i Automatisera hotsvar i Microsoft Sentinel med automatiseringsregler.
Lägga till en automationsregel för att hantera ett falskt positivt resultat:
I Microsoft Sentinel under Incidenter väljer du den incident som du vill skapa ett undantag för.
I fönstret incidentinformation på sidan väljer du Åtgärder > Skapa automatiseringsregel.
I sidofältet Skapa ny automatiseringsregel kan du eventuellt ändra det nya regelnamnet för att identifiera undantaget, i stället för bara aviseringsregelnamnet.
Under Villkor kan du också lägga till fler Analytics-regelnamnatt tillämpa undantaget på. Välj listrutan som innehåller namnet på analysregeln och välj fler analysregler i listan.
Sidofältet visar de specifika entiteterna i den aktuella incidenten som kan ha orsakat det falska positiva resultatet. Behåll de automatiska förslagen eller ändra de föreslagna villkoren för att finjustera undantaget. Du kan till exempel ändra ett villkor på en IP-adress så att det gäller för ett helt undernät.
När du är nöjd med villkoren rullar du nedåt i sidofönstret för att fortsätta definiera vad regeln gör:
- Regeln har redan konfigurerats för att stänga en incident som uppfyller undantagskriterierna.
- Du kan behålla den angivna stängningsorsaken som den är, eller så kan du ändra den om en annan orsak är lämpligare.
- Du kan lägga till en kommentar till den automatiskt stängda incidenten som förklarar undantaget. Du kan till exempel ange att incidenten kommer från en känd administrativ aktivitet.
- Som standard är regeln inställd på att upphöra automatiskt efter 24 timmar. Den här förfallotiden kan vara det du vill ha och minskar risken för falska negativa fel. Om du vill ha ett längre undantag anger du Regelns förfallotid till en senare tid.
Du kan lägga till fler åtgärder om du vill. Du kan till exempel lägga till en tagg i incidenten, eller så kan du köra en spelbok för att skicka ett e-postmeddelande eller ett meddelande eller synkronisera med ett externt system.
Välj Använd för att aktivera undantaget.
Lägg till undantag genom att ändra analysregelfrågor
Du kan också implementera undantag genom att ändra analysregelfrågan. Du kan inkludera undantag direkt i regeln, eller helst, när det är möjligt, använda en referens till en visningslista. Du kan sedan hantera undantagslistan i visningslistan.
Ändra frågan
Detaljerade anvisningar om hur du använder guiden Analysregler för att skapa och redigera analysregler finns i Skapa anpassade analysregler för att identifiera hot.
Om du vill redigera befintliga analysregler väljer du Automation på den Microsoft Sentinel vänstra navigeringsmenyn. Välj den regel som du vill redigera och välj sedan Redigera längst ned till höger för att öppna guiden Analysregler.
Om du vill implementera ett undantag i en typisk regelingress kan du lägga till ett villkor som where IPAddress !in ('<ip addresses>') i början av regelfrågan. Den här raden exkluderar specifika IP-adresser från regeln.
let timeFrame = 1d;
SigninLogs
| where TimeGenerated >= ago(timeFrame)
| where IPAddress !in ('10.0.0.8', '192.168.12.1')
...
Den här typen av undantag är inte begränsad till IP-adresser. Du kan exkludera specifika användare med hjälp UserPrincipalName av fältet eller exkludera specifika appar med hjälp AppDisplayNameav .
Du kan också exkludera flera attribut. Om du till exempel vill exkludera aviseringar från IP-adressen 10.0.0.8 eller användaren user@microsoft.comanvänder du:
| where IPAddress !in ('10.0.0.8')
| where UserPrincipalName != 'user@microsoft.com'
Om du vill skapa ett mer specifikt undantag när det är tillämpligt, och minska risken för falskt negativa resultat, kan du kombinera attribut. Följande undantag gäller endast om båda värdena visas i samma avisering:
| where IPAddress != '10.0.0.8' and UserPrincipalName != 'user@microsoft.com'
Exkludera undernät
Exkludering av IP-intervall som används av en organisation kräver undernätsundantag. I följande exempel visas hur du exkluderar undernät.
Operatorn ipv4_lookup är en berikningsoperator, inte en filtreringsoperator. Raden where isempty(network) utför faktiskt filtreringen genom att endast behålla händelser vars IP-adress inte matchar någon undernätspost.
let subnets = datatable(network:string) [ "111.68.128.0/17", "5.8.0.0/19", ...];
let timeFrame = 1d;
SigninLogs
| where TimeGenerated >= ago(timeFrame)
| evaluate ipv4_lookup(subnets, IPAddress, network, return_unmatched = true)
| where isempty(network)
...
Använda visningslistor för att hantera undantag
Du kan använda en visningslista för att hantera listan över undantag utanför själva regeln. I förekommande fall har den här lösningen följande fördelar:
- En analytiker kan lägga till undantag utan att redigera regeln, vilket bättre följer SOC:s metodtips.
- Samma visningslista kan gälla för flera regler, vilket möjliggör central undantagshantering.
Att använda en visningslista liknar att använda ett direkt undantag. Använd _GetWatchlist('<watchlist name>') för att anropa visningslistan:
let timeFrame = 1d;
let logonDiff = 10m;
let allowlist = (_GetWatchlist('ipallowlist') | project IPAddress);
SigninLogs
| where TimeGenerated >= ago(timeFrame)
| where IPAddress !in (allowlist)
...
Du kan också filtrera undernät med hjälp av en visningslista. I den föregående undantagskoden för undernät kan du till exempel ersätta undernätsdefinitionen med en visningslista datatable :
let subnets = _GetWatchlist('subnetallowlist');
För mer information om Kusto-operatorerna och funktionerna som används i undantagsfrågorna, se Kusto-dokumentationen:
- let-instruktion
- where-operator
- projektoperator
- datatable-operator
- utvärdera plugin-operatorn
- ago() funktion
- isempty()-funktionen
- ipv4_lookup plugin-program
Mer information om KQL finns i översikten över Kusto-frågespråk (KQL).
Andra resurser:
Exempel: Hantera undantag för Microsoft Sentinel lösning för SAP-program®
Den Microsoft Sentinel lösningen för SAP-program® innehåller funktioner som du kan använda för att undanta användare eller system från att utlösa aviseringar.
Exkludera användare. Använd funktionen SAPUsersGetVIP för att:
- Anropa taggar för användare som du vill undanta från att utlösa aviseringar. Tagga användare i SAP_User_Config visningslista med asterisker (*) som jokertecken för att tagga alla användare med en angiven namngivningssyntax.
- Lista specifika SAP-roller och/eller profiler som du vill undanta från att utlösa aviseringar.
Exkludera system. Använd funktioner som stöder parametern SelectedSystemRoles för att fastställa att endast specifika typer av system utlöser aviseringar, inklusive endast produktionssystem , endast UAT-system eller båda.
Mer information finns i Microsoft Sentinel lösning för SAP-programdatareferens®.
Relaterat innehåll
Mer information finns i: