Driva Sophos XDR Custom Detection och Suppression Rules

Under Security Operations > Rules hanteras egna detectionregler och Suppression Rules. Detectionregler skapar nya detections från normaliserade händelser; suppressionregler markerar passande detections som undertryckta tidigt i processen. Båda ändrar den löpande utredningen och kräver ett godkänt, snävt avgränsat villkor samt en ansvarig.

Guiden för Cases och Classic-regler förklarar den fortfarande avvikande Classic-vyn. Dess Super Admin-, mängd- eller 20-minuterskrav överförs inte till Security Operations.

Före en egen regel

Bestäm först syfte, källa, schema, förväntade träffar och avsiktligt uteslutna fall. Kontrollera med lämpliga historiska händelser i Data Lake Search att villkoret är meningsfullt. Ett godkänt test använder ett separat konto eller andra godkända testdata; verklig skadlig aktivitet genereras inte.

En träff i historisk sökning bevisar inte samma effekt i en körande regel. Sökmotor och regelmotor skiljer sig; vissa berikade fält uppstår först senare. Acceptans omfattar därför både förväntad träff och förväntad icke-träff. Före ändring dokumenteras fråga, namn, beskrivning, severity, aktiveringsstatus och tidigare träffar.

Skapa en Custom Detection Rule

Skapa först en lämplig Advanced Search-fråga under Security Operations > Data Lake Search. Den ska träffa normaliserade händelser i ett passande schema. Därefter:

1. Kopiera den kontrollerade frågan och öppna Security Operations > Rules.
2. Välj Create Rule ovanför tabellen Custom Rules.
3. Klistra in frågan i Rule Criteria.
4. Ange ett tydligt Name, lämpliga Mitre Attack Categories och en begriplig Description.
5. Välj sakligt motiverad severity och skapa med Create Rule.

En ny Custom Rule är påslagen efter att den skapats. Godkännande och ansvarig måste därför finnas före. Detta är en annan standard än för en ny Custom Parser. Aktivera inte ett obegränsat sökvillkor i produktion för att experimentera.

Streaming är ingen sparad sökning

Custom Rules arbetar med streamingdata. Primitiva fält får inte automatiskt de standardvärden som senare kan finnas i Data Lake. NULL-villkor måste därför hantera faktiskt saknade värden. Globmönster stöds inte; även regexkonstruktioner som backreferences, rekursiva mönster, godtyckliga look-aroundliknande zero-width assertions och inbäddad kod är begränsade. Presentera inte ett fungerande Search-uttryck som en garanterat fungerande regel utan kontroll.

Logiska fält som @user kan expandera till fälten inom valt schema. En regel matchar däremot bara ett schema. Vissa fält som läggs till senare är inte tillgängliga: exempelvis hostname, geo-/svartlisteberikning för auth/netflow/dns_query och WHOIS i DNS-schemat. Kontrollera de nödvändiga fälten i aktuell regelkontext, inte genom att ersätta dem med liknande Search-fält.

Circuit breaker och kundansvar

Custom Rules får skapa högst 5 000 detections per timme eller 100 000 inom 24 timmar. Vid överskridande stänger circuit breakern av regeln och Sophos mejlar författaren. Begränsa därefter omfånget; slå inte på den oförändrade regeln igen. Ett stoppat larmflöde kan alltså betyda avstängd regel, inte lösta risker.

Cases som automatiskt skapas av kundregler är customer-managed och utlöser ingen automatisk MDR-utredning. Scheman Antivirus, Email, NIDS och Thirdparty beskriver också is_custom_alert=true: sådana Custom Alerts skickas till tenanten för egen hantering i stället för MDR-tjänstens kö; severity ändras inte. Det utesluter inte generellt varje Custom Parser-post från MDR. Skapa och validera parsers förklarar föregående normalisering.

Håll suppression avsiktligt snäv

Suppression är till för bekräftade legitima upprepningar, inte för att dölja oförklarad aktivitet. Tenantregler gäller endast egen tenant; Global-regler hanteras av Sophos och är skrivskyddade. Dokumentera frågor om en global regel och klargör dem via den vanliga supportvägen.

En undertryckt detection får statusen tidigt, innan den kan utlösa efterföljande automatiserad response. Därmed kan exempelvis playbooks eller värdisolering utebli. Före godkännande måste det vara klart vilken legitim aktivitet som matchas och vilken säkerhetsreaktion som avsiktligt förhindras.

Skapa suppression från en fråga

1. Kontrollera villkoret mot befintliga detections i Data Lake Search.
2. Välj Create Rule under Security Operations > Rules > Suppression Rules.
3. Ange villkoret i Rule Criteria.
4. Använd See potential matches with current data som rimlighetskontroll i förhandsgranskningen.
5. Ange namn, beskrivning och önskad resolutionsstatus och skapa med Create Rule.

Nya suppressionregler är också påslagna som standard. Omfång, godkännande och återgång måste därför vara klara före Create Rule.

Alternativt öppnas en specifik detection och Actions > Create Suppression Rule. Välj förifyllda entities medvetet; flera villkor kombineras med AND. Escapa manuellt angivna regexspecialtecken korrekt. Härled ingen universell suppression från en enda förväntad träff.

Varför förhandsgranskning och körande regel kan skilja sig

Förhandsgranskningen använder Advanced Search på färdiga, berikade detections. Suppression körs under skapandet. Fält som enrichment_details, status och case är otillgängliga; för tredjepartsvärden används händelseschemat thirdparty, inte third_party_details. Alla kriterier måste vara sanna tillsammans vid suppressionstillfället. En färdig post kan kombinera villkor som tidigare bara var sanna separat.

See potential matches är därför ingen effektgaranti. Vänta minst tio minuter efter att en regel skapats, redigerats, aktiverats eller avaktiverats innan resultatet bedöms. Detections direkt efter ändringen är inget tillförlitligt test av det nya tillståndet.

IPv4-CIDR fungerar i suppression trots att Detection Search inte stöder CIDR-sökning. Kontrollera frågan utan intervall först och anpassa den sedan för regeln. IPv6-adresser kan jämföras normaliserat; IPv6-CIDR och IPv4-mapped IPv6 stöds för närvarande inte i suppression. Överför inte okontrollerat brandväggens syntax för nätintervall.

Kontrollera effekt, dokumentera och återgå

Ett klick på regelnamnet visar kriterier och detaljer. Om träffar förekommit under senaste sju dagarna visas antal, senaste träff och förlopp. För suppression visar History även ändringshistorik. Ett saknat diagram kan helt enkelt betyda att passande händelse inte inträffat.

Inkludera detections från Custom Rules med Custom Detections i listan. Undertryckta, redan triagerade detections blir synliga med Triaged Detections; en passande sökning kan öppnas från regeldetaljer. Kontrollera förväntade träffar och icke-träffar, schema/källa och avsedd eller medvetet utebliven response.

Enabled slår på eller av en regel. Archive stänger av och tar bort den från standardlistan. Öppna arkiverade regler med Showing Archived Rules; Restore återställer dem avstängda. Aktivera inte en återställd regel utan ny acceptans. Ta även vid avstängning av suppression hänsyn till dokumenterad fördröjning.

Om acceptansen misslyckas stängs endast den egna berörda regeln av och tidigare dokumenterat läge kontrolleras. Redan skapade Cases, exporter eller undertryckta detections försvinner inte automatiskt. Undertryckta detections kan vid behov läggas till Cases och få sin etikett ändrad. Stäng inte av en global skyddsfunktion eller någon annans regel för att få det egna testet att passa.

Driftöverlämning omfattar källa/schema, kriterier och version, författare, godkännande, träff-/icke-träffunderlag, severity/resolution, aktiveringsstatus, circuit-breakerövervakning och granskningsdatum. Integrationsacceptans är en förutsättning: en tyst regel reparerar ingen saknad datakälla.