Segui Ogni team di rilevamento conosce questo momento. Una regola viene scritta o scaricata, rivista, tradotta nel linguaggio di query del SIEM e distribuita. Lo stato indica abilitato, il conteggio delle regole aumenta e il rapporto di copertura diventa un po’ più verde.
Niente di tutto ciò ti dice se la regola rileverà l’attacco per cui è stata scritta. Una regola può essere ben scritta e comunque non trovare nulla perché la sua logica, i suoi dati o la sua traduzione divergono silenziosamente dalla realtà. E poiché una regola che non si attiva mai appare uguale a una regola senza nulla da catturare, il problema può rimanere nascosto a lungo.
Questo articolo spiega cosa separa una regola funzionante da una difettosa, dove solitamente le regole vanno male e cosa puoi fare con SOC Prime per dimostrare che una regola funziona prima che venga rilasciata e per mantenerla funzionante in seguito.
Cosa significa davvero “funzionante”
Una regola di rilevamento funzionante fa tre cose. Esprime la logica giusta per il comportamento che mira. Funziona su dati che contengono effettivamente quel comportamento. E viene scritta correttamente per la piattaforma su cui funziona. Se una qualsiasi di queste fallisce, la regola è difettosa, anche se è abilitata e non genera errori.
Questa struttura aiuta perché ogni fallimento ha una causa diversa e una correzione diversa:
- Problemi di logica vivono nella regola stessa. È troppo stretta per catturare le variazioni del comportamento, o così ampia che corrisponde all’attività normale.
- Problemi di dati vivono nell’ambiente. Gli eventi che la regola richiede non sono registrati, non raccolti o mancano i campi di cui la regola si basa.
- Problemi di traduzione vivono nel passaggio tra lingue. Il significato della regola cambia quando viene convertito nella sintassi delle query di una piattaforma.
La maggior parte delle squadre controlla attentamente la prima quando scrive una regola. La seconda e la terza sono dove le regole tendono a fallire senza che nessuno se ne accorga.
Dove le regole funzionanti vanno male
Logica che non corrisponde al comportamento. Una regola basata solo sul nome del file di uno strumento è facile da eludere rinominando il file. Una regola basata su un modello comune di linea di comando, senza filtraggio, può corrispondere agli amministratori tutto il giorno. Nessuno dei due errori è visibile al momento del rilascio. Il primo appare quando un attaccante lo supera, il secondo come rumore di allerta.
Dati che non ci sono. Una regola di creazione del processo che dipende dagli argomenti della linea di comando è inutile se la registrazione della linea di comando non è abilitata, perché l’evento arriva senza il campo. Lo stesso vale per una fonte di log che non è mai stata adottata o un agente che ha smesso di inviare. La regola viene eseguita secondo programma, non trova nulla e sembra sana.
Campi che significano cose diverse in luoghi diversi. Lo stesso concetto può avere nomi diversi tra i prodotti e anche i modelli di dati di diversi fornitori sono contratti separati. Splunk CIM e Microsoft Sentinel ASIM ne sono un buon esempio: un campo che esiste in uno potrebbe non esistere nell’altro. Un trasferimento carattere per carattere produce una regola che fa riferimento a campi che la destinazione non popola mai.
Traduzione che cambia significato. I traduttori automatici gestiscono bene la logica di selezione semplice, ma le regole di correlazione e le funzioni proprietarie di solito necessitano di revisione umana. Le piattaforme differiscono anche per il modo in cui trattano dettagli come la sensibilità al maiuscolo/minuscolo, i jolly e le espressioni regolari. Una regola può essere tradotta “con successo” e tuttavia comportarsi in modo diverso dall’originale.
Limiti della piattaforma che ritirano buone regole. I SIEM limitano quante regole possono funzionare. I team disabilitano regolarmente le regole funzionanti per fare spazio a quelle nuove, quindi la copertura si riduce senza che venga preso consapevolmente tale decisione.
Perché è importante
Ognuno di questi problemi lascia il conteggio delle regole e la dashboard invariati. Pertanto, i dati sulla copertura che contano le regole distribuite sovrastimano la protezione e la lacuna di solito emerge durante un incidente, quando qualcuno scopre che la regola che avrebbe dovuto attivarsi non avrebbe mai potuto.
C’è un secondo costo: una regola silenziosa è ambigua. Se nulla viene attivato, l’ambiente è pulito, la telemetria manca o la logica è sbagliata? Capirlo dopo significa controllare logica, dati e traduzione uno dopo l’altro. È molto più economico raccogliere prove in anticipo e tenerle aggiornate.
Come SOC Prime ti aiuta a dimostrare che una regola funziona
La convalida del rilevamento è davvero una catena di domande: di cosa ha bisogno questa regola, il mio ambiente la fornisce, la regola si comporta come previsto sui miei dati e, in caso negativo, cosa dovrebbe cambiare? SOC Prime supporta ogni passaggio.
Comprendere i requisiti di rilevamento
La convalida inizia prima di qualsiasi test. SOC Prime fornisce informazioni contestuali sui contenuti di rilevamento, inclusi il comportamento previsto, i requisiti di telemetria, la mappatura MITRE ATT&CK, potenziali falsi positivi e altri metadati. Questo offre agli ingegneri del rilevamento un punto di inizio per decidere se un rilevamento è applicabile al loro ambiente e quali prerequisiti devono essere in atto prima che venga testato. Una regola che richiede la registrazione della linea di comando, ad esempio, te lo dice subito, invece di lasciarti scoprirlo in seguito.
Valutare la telemetria disponibile
Una volta che sai di cosa ha bisogno una regola, la domanda successiva è se ce l’hai. Prime Hunt può aiutare i team a valutare la relazione tra i dati disponibili e la potenziale copertura di rilevamento. Data Audit analizza i dati di log disponibili e li mappa sul MITRE ATT&CK per identificare potenziali lacune di visibilità. Questo ti aiuta a determinare se una mancanza di copertura di rilevamento deriva da telemetria mancante piuttosto che da contenuti di rilevamento mancanti, che sono due problemi molto diversi con due soluzioni molto diverse.
Testare i rilevamenti sui dati organizzativi
Prime Hunt può anche eseguire scansioni di rilevamento sui dati degli ambienti connessi. Testare i rilevamenti sui dati effettivi ti dà prove di come il contenuto si comporta nel tuo ambiente, anziché affidarsi solo a una convalida teorica. I risultati delle scansioni aiutano a identificare i rilevamenti che producono corrispondenze pertinenti e a evidenziare quelli che necessitano di ulteriori indagini o regolazioni.
Indagare e migliorare la logica di rilevamento
Quando un rilevamento necessita di modifiche, SOC Prime fornisce capacità di ingegneria del rilevamento attraverso Prime Core e Prime Architect. Il contenuto di rilevamento può essere rivisto, personalizzato, tradotto e ottimizzato per l’ambiente di destinazione. Questo affronta le differenze nei schemi, le mappature dei campi, i linguaggi delle query e i requisiti specifici dell’ambiente senza trattare ogni rilevamento problematico come un nuovo compito di sviluppo.
In pratica, ciò significa:
- Traduci per la piattaforma su cui operi. Tutte le regole Sigma sulla piattaforma sono già tradotte in tutti i linguaggi e formati SIEM supportati, quindi puoi prendere la query per il tuo stack e distribuirla subito. Per qualsiasi contenuto personalizzato, o per le tue regole Sigma, usa lo spazio di lavoro di Traduzione in Prime Architect per convertirle nel linguaggio query nativo del tuo SIEM, EDR, XDR o data lake. Sigma resta la fonte, quindi una modifica fatta una volta può essere tradotta di nuovo anziché modificata manualmente su ciascuna piattaforma.
- Mappa tabelle, campi, e valori al tuo schema. Il Mappatura di Campi Personalizzata ti consente di definire profili che mappano le tue tabelle, campi e valori non standard ai valori predefiniti. Crea un profilo una volta, quindi applicalo ogni volta che distribuisci una regola o invii una query.
- Aggiungi filtri che si adattino al tuo ambiente. I filtri aggiungono condizioni alla logica di rilevamento prima della distribuzione per includere o escludere utenti, host o altri set di elementi specifici. Mantengono l’attività nota per essere benigna dal trasformare una buona regola in una rumorosa, senza riscrivere la regola stessa.
- Salva le impostazioni di distribuzione come preset. I preset memorizzano parametri come il periodo di query, la severità e lo stato della regola, in modo che le distribuzioni rimangano coerenti.
- Valida, ottimizza e affina. Lo spazio di lavoro di Traduzione valida e ottimizza anche i contenuti di rilevamento. Non sostituisce la revisione: controlla ogni campo rispetto allo schema di destinazione e osserva attentamente qualsiasi cosa contrassegnata, soprattutto la logica di correlazione e le funzioni specifiche della piattaforma. Quando un cambiamento va oltre la mappatura e i filtri, modifica direttamente il codice, traducilo di nuovo e salvalo nel tuo repository personalizzato come aggiornamento o nuova regola.
- Ricerca e regolazione con lo spazio di lavoro assistito dall’AI. Usalo per ricercare il comportamento a cui una regola mira e lavorare attraverso i cambiamenti alla sua logica. Gli ingegneri rimangono in controllo e revisionano ogni modifica prima che venga distribuita.
Identificare le lacune nella copertura
La convalida del rilevamento dovrebbe anche rispondere a cosa non viene rilevato. Data Audit in Prime Hunt fornisce un’analisi della copertura basata sia sulla telemetria disponibile sia sul contenuto di rilevamento. Questo aiuta i team a distinguere tra lacune causate da insufficiente visibilità e quelle causate da regole di rilevamento mancanti o non idonee. Tale distinzione informa la successiva azione di ingegneria: raccogliere più dati, affinare un rilevamento esistente o identificare e sviluppare contenuto di rilevamento aggiuntivo.
Continuare la convalida nel tempo
L’efficacia del rilevamento cambia al cambiare dell’ambiente e del contenuto di rilevamento. La convalida ricorrente con Prime Hunt consente ai team di rivalutare i rilevamenti rispetto ai dati attuali anziché affidarsi indefinitivamente a un risultato di convalida iniziale. Questo è particolarmente importante in ambienti dove le configurazioni di log, gli schemi dei dati, le infrastrutture o il contenuto di rilevamento cambiano frequentemente.
Prova invece di supposizioni
Una regola distribuita è un’affermazione. Una regola testata su dati reali è una prova. La differenza è facile da trascurare, perché entrambe sembrano uguali in un elenco di regole e entrambe rimangono silenziose fino all’arrivo di un attacco.
SOC Prime aiuta le squadre a colmare quella lacuna. Inizia con chiari requisiti di rilevamento e uno sguardo onesto alla telemetria disponibile, testa i rilevamenti sui tuoi dati, e ti dà gli strumenti per risolvere ciò che non si adatta. L’analisi della copertura mostra quindi se le restanti lacune richiedono più dati, una migliore sintonia o nuovo contenuto, e la convalida ricorrente mantiene la risposta aggiornata man mano che l’ambiente cambia. Inizia con le regole che contano di più e scopri quali si attiverebbero davvero.
