Gestire Sophos XDR Custom Detection e Suppression Rules

In Security Operations > Rules si gestiscono regole di detection personalizzate e Suppression Rules. Le prime creano detections da eventi normalizzati; le seconde marcano tempestivamente come soppresse le detections corrispondenti. Entrambe modificano il processo d’indagine e richiedono una condizione approvata, delimitata con precisione e un responsabile.

La guida Cases e regole Classic spiega la vista Classic, ancora diversa. I suoi vincoli Super Admin, quantitativi o di 20 minuti non si trasferiscono a Security Operations.

Prima di creare una regola

Definire scopo, fonte, schema, corrispondenze attese e casi esclusi intenzionalmente. Con eventi storici appropriati in Data Lake Search verificare che la condizione sia sensata. Un test approvato usa un account dedicato o altri dati autorizzati; non si genera attività dannosa reale.

Una corrispondenza nella ricerca storica non prova lo stesso effetto in una regola attiva. I motori differiscono e alcuni campi arricchiti nascono solo dopo. L’accettazione richiede quindi una corrispondenza e una mancata corrispondenza attese. Prima di cambiare, documentare query, nome, descrizione, severity, stato di attivazione e risultati precedenti.

Creare una Custom Detection Rule

Creare prima una query Advanced Search adatta in Security Operations > Data Lake Search, diretta a eventi normalizzati di uno schema appropriato. Poi:

1. Copiare il testo verificato e aprire Security Operations > Rules.
2. Scegliere Create Rule sopra la tabella Custom Rules.
3. Inserire la query in Rule Criteria.
4. Specificare un Name chiaro, Mitre Attack Categories adatte e una Description comprensibile.
5. Selezionare una severity motivata e creare con Create Rule.

Una nuova Custom Rule è attiva subito dopo la creazione. Approvazione e responsabile devono quindi essere definiti prima. È un comportamento diverso dal nuovo Custom Parser. Non attivare in produzione una condizione illimitata per fare esperimenti.

Lo streaming non è una ricerca salvata

Le Custom Rules operano su dati in streaming. I campi primitivi non ricevono automaticamente i valori predefiniti che possono essere presenti dopo nel Data Lake. Le condizioni NULL devono quindi considerare valori realmente assenti. I pattern glob non sono supportati; sono limitati anche costrutti regex come backreference, pattern ricorsivi, assertion arbitrarie a larghezza zero di tipo look-around e codice incorporato. Un’espressione Search funzionante non diventa senza verifica una regola garantita.

Campi logici come @user possono espandersi nei campi dello schema scelto. Una regola corrisponde però a un solo schema. Alcuni campi aggiunti successivamente non sono disponibili: ad esempio hostname, arricchimenti geo/blacklist per auth/netflow/dns_query e WHOIS nello schema DNS. Verificare i campi esatti nel contesto della regola, senza sostituirli con campi Search dal nome simile.

Circuit breaker e responsabilità del cliente

Le Custom Rules possono produrre al massimo 5.000 detections all’ora o 100.000 in 24 ore. Se il limite è superato, il circuit breaker disattiva la regola e Sophos avvisa l’autore via e-mail. Restringere poi l’ambito; non riattivare la regola invariata. Un flusso d’allarmi interrotto può quindi significare una regola disattivata, non rischi risolti.

I Cases generati automaticamente dalle regole cliente sono customer-managed e non avviano automaticamente un’indagine MDR. Gli schemi Antivirus, Email, NIDS e Thirdparty descrivono anche is_custom_alert=true: questi Custom Alerts sono assegnati al tenant per la gestione, non alla coda del servizio MDR; la severity non cambia. Questo non esclude globalmente ogni record Custom Parser da MDR. Creare e validare i parser spiega la normalizzazione precedente.

Mantenere la suppression volutamente circoscritta

La suppression serve per ripetizioni legittime confermate, non per nascondere attività inspiegata. Le regole tenant valgono solo nel tenant; quelle Global sono gestite da Sophos e in sola lettura. Documentare i dubbi su una regola globale e chiarirli attraverso il normale supporto.

Una detection soppressa riceve presto questo stato, prima di poter avviare response automatizzate successive. Playbook o isolamento host possono quindi non partire. Prima dell’approvazione deve essere chiaro quale attività legittima venga riconosciuta e quale reazione di sicurezza sia deliberatamente impedita.

Creare suppression da una query

1. Verificare la condizione su detections esistenti in Data Lake Search.
2. Scegliere Create Rule in Security Operations > Rules > Suppression Rules.
3. Inserire la condizione in Rule Criteria.
4. Usare See potential matches with current data come anteprima di plausibilità.
5. Impostare nome, descrizione e stato di risoluzione, poi creare con Create Rule.

Anche le nuove regole di suppression sono attive per impostazione predefinita. Ambito, approvazione e ripristino devono precedere Create Rule.

In alternativa aprire una detection specifica e Actions > Create Suppression Rule. Selezionare consapevolmente le entities precompilate; più condizioni sono unite con AND. Eseguire l’escape appropriato dei caratteri speciali regex inseriti manualmente. Non dedurre una suppression universale da una sola corrispondenza attesa.

Perché anteprima e regola attiva possono differire

L’anteprima usa Advanced Search su detections concluse e arricchite. La suppression agisce durante la loro creazione. Campi come enrichment_details, status e case non sono disponibili; per valori terzi usare lo schema evento thirdparty, non third_party_details. Tutti i criteri devono essere veri contemporaneamente al momento della suppression. Un record finale può combinare condizioni precedentemente vere solo separatamente.

See potential matches non garantisce quindi l’effetto. Dopo creazione, modifica, attivazione o disattivazione attendere almeno dieci minuti prima di valutare. Le detections generate subito dopo un change non sono un test affidabile del nuovo stato.

IPv4-CIDR è possibile in suppression, benché Detection Search non supporti la ricerca CIDR. Verificare prima la query senza intervallo, poi adattarla alla regola. Gli indirizzi IPv6 possono essere confrontati in forma normalizzata; IPv6-CIDR e IPv4-mapped IPv6 non sono attualmente supportati dalla suppression. Non trasferire senza verifica la sintassi degli intervalli firewall.

Verificare, documentare e ripristinare

Un clic sul nome mostra criteri e dettagli. Se vi sono corrispondenze negli ultimi sette giorni appaiono conteggio, ultima corrispondenza e andamento. Per suppression, History mostra anche le modifiche. Un grafico assente può semplicemente indicare che l’evento adatto non si è verificato.

Le detections da Custom Rules si includono con Custom Detections nella lista. Le detections soppresse già triagate diventano visibili con Triaged Detections; dai dettagli si può aprire una ricerca pertinente. La verifica copre corrispondenze e mancate corrispondenze attese, schema/fonte e response desiderata o volutamente assente.

Enabled attiva o disattiva una regola. Archive la disattiva e rimuove dalla lista predefinita. Showing Archived Rules permette di aprirla; Restore la ripristina disattivata. Non attivare una regola ripristinata senza nuova accettazione. Per suppression resta da considerare la latenza documentata anche nella disattivazione.

Se l’accettazione fallisce, disattivare solo la propria regola interessata e controllare lo stato precedente documentato. Cases, export o detections soppresse già creati non scompaiono automaticamente. Se necessario si possono aggiungere detections soppresse ai Cases e cambiarne l’etichetta. Non disabilitare protezioni globali o regole altrui per far riuscire il test.

La consegna operativa comprende fonte/schema, criteri e versione, autore, approvazione, prove positive/negative, severity/risoluzione, attivazione, monitoraggio circuit breaker e data di revisione. L’accettazione delle integrazioni resta necessaria: una regola silenziosa non ripara una fonte dati assente.