Segui La portabilità delle regole di rilevamento è la pratica di scrivere e gestire la logica di rilevamento delle minacce in modo che possa essere spostata tra piattaforme SIEM, EDR e XDR senza una riscrittura completa.
Cosa succede alle mie regole di rilevamento quando migro a una nuova piattaforma SIEM?
Le regole scritte nel linguaggio di query nativo di una piattaforma non viaggiano. SPL rimane in Splunk. KQL rimane in Microsoft Sentinel. YARA-L rimane in Google SecOps. Quando si migra, queste regole devono essere riscritte o tradotte per la piattaforma di destinazione.
La fedeltà della traduzione dipende dalla struttura, non dalla coppia di lingue. Due assi di degradazione decidono cosa sopravvive.
Asse 1: mappatura dei campi. Le tassonomie dei campi di origine (CIM, ASIM, ECS, OCSF, Sysmon-native, vendor-native) si mappano in modo incompleto. Un campo non mappato o rinominato restringe o rompe silenziosamente la regola.
Asse 2: semantica delle strutture. La semantica di aggregazione e delle finestre temporali, la logica di sequenza o transazione, il dialetto regex e le funzioni di tipo eval/lookup/join hanno spesso solo analoghi parziali sulla piattaforma di destinazione. Questo asse porta la quota di riscrittura.
Sigma Le regole Sigma sono progettate per la traduzione. Vengono autored una volta e tradotte per backend tramite pySigma, sigma-cli, o Uncoder.
La traduzione non è conservazione. Ogni regola tradotta richiede ancora una validazione specifica per il backend contro i campi analizzati della destinazione prima di essere ritenuta affidabile. Una traduzione sintatticamente corretta può fare riferimento a campi che la nuova piattaforma non popola mai.
L’instradamento della pipeline di telemetria è un meccanismo separato. Instradare un flusso di log a una nuova destinazione non trasferisce la logica di rilevamento che vi è in esecuzione sopra. SPL rimane SPL indipendentemente da dove finiscono i log.
Qual è la differenza tra regole di rilevamento specifiche per il fornitore e agnostiche al fornitore?
Una regola specifica del fornitore è una risorsa della piattaforma. Una regola agnostica al fornitore è una risorsa del team.
| Dimensione | SPL (Splunk) | KQL (Microsoft Sentinel) | YARA-L (Google SecOps) | Sigma |
|---|---|---|---|---|
| Funziona nativamente su | Splunk | Microsoft Sentinel | Google SecOps | Nessun diretto. Traduce per tutti e tre più IBM QRadar, Elastic, CrowdStrike e altri. |
| Spostarlo richiede | Riscrittura nel linguaggio di destinazione | Riscrittura nel linguaggio di destinazione | Riscrittura nel linguaggio di destinazione | Traduzione tramite pySigma/sigma-cli o Uncoder, quindi validazione della mappatura dei campi |
| Chi lo possiede | Il deployment di Splunk | Lo spazio di lavoro Sentinel | Il tenant SecOps | Il tuo team, nel controllo di versione |
| Costo multi-piattaforma | Scrivi N copie | Scrivi N copie | Scrivi N copie | Traduce una volta per backend, valida una volta per backend |
La differenza di costo emerge alla migrazione e nell’operazione multi-piattaforma. La logica di rilevamento agnostica al fornitore rimane portabile su tutto il tuo stack.
Come migro il contenuto di rilevamento da Splunk a Microsoft Sentinel?
Sei passi. Questa è una delle coppie di lingue più difficili perché SPL e KQL differiscono sul modello dei dati, la denominazione dei campi e la semantica delle funzioni.
- Inventario delle regole SPL. Esporta ogni ricerca salvata, allerta e ricerca di correlazione. Registra le dipendenze del modello di dati di ciascuna regola (sourcetype, indice, nomi dei campi).
- Classifica per tipo di costrutto. Ordina le regole in tre gruppi: logica di selezione semplice (trasporta pulita), dipendente dalla mappatura dei campi (trasporta con lavoro di mappatura) e logica di correlazione/statale (aspettati una riscrittura manuale).
- Traduci tramite Sigma. Converte le regole SPL in Sigma, quindi traduce Sigma in KQL usando pySigma con il backend di Microsoft Sentinel, sigma-cli o Uncoder. Questo gestisce la sintassi. Non gestisce la mappatura dei campi.
- Mappa i campi contro lo schema Sentinel. Allinea i nomi dei campi CIM agli equivalenti ASIM. Microsoft documenta il loro schema su learn.microsoft.com. Ogni campo nella regola tradotta deve risolvere un nome di colonna nella tabella di destinazione.
- Testa sulle tabelle Sentinel. Esegui ogni regola tradotta su dati effettivamente ingeriti. Mantieni un evento di test per regola per poter verificare la corrispondenza dopo qualsiasi modifica dello schema.
- Esegui il cambio con una finestra di esecuzione parallela. Esegui entrambe le piattaforme sulle stesse fonti di log. Confronta l’output degli allarmi. Ritira la versione SPL solo dopo che la versione KQL emette allarmi sugli stessi eventi.
Prima di cambiare, mappa le regole implementate su entrambe le piattaforme su MITRE ATT&CK tecniche e confronta le due mappe, in modo tale che una tecnica che la migrazione scarta emerga prima del cambio, non dopo; l’Audit MITRE ATT&CK di SOC Prime mappa le rilevazioni e le fonti dati implementate ad ATT&CK come servizio. maps deployed detections and data sources to ATT&CK as a service.
Migrando una libreria di regole? Esplora il Prime Architect di SOC Prime per la traduzione di regole cross-platform, la ricerca delle minacce e i flussi di lavoro di ingegneria del rilevamento. Contatta le Vendite
Quali sono le migliori pratiche per tradurre i linguaggi di query come SPL in KQL?
Traduci la logica, non la sintassi. Una porta carattere per carattere produce regole fragili che fanno riferimento a campi che la destinazione potrebbe non popolare.
- Mappa i campi contro lo schema di destinazione. Non assumere che i nomi dei campi siano trasferibili. CIM di Splunk e ASIM di Sentinel sono contratti diversi. Lo sforzo di migrazione risiede nella mappatura tra loro.
- Mantieni un evento di test per regola. Un evento noto come dannoso abbinato a uno noto come innocuo. Se la regola tradotta non corrisponde al malvagio e non rifiuta l’innocuo, qualcosa si è rotto nella traduzione.
- Rivedi tutto ciò che il traduttore segnala. I traduttori automatici gestiscono bene la logica di selezione semplice. Le regole di correlazione, le funzioni proprietarie e le aggregazioni complesse richiedono una revisione umana.
- Nomina i tuoi strumenti. per la traduzione di regole cross-platform, la ricerca delle minacce e i flussi di lavoro di ingegneria del rilevamento. traduce Sigma in 65 lingue di rilevamento, migra tra linguaggi di query nativi come SPL e KQL, applica preset di mappatura dei campi per l’ambiente a cui ti connetti, e distribuisce da un repository di regole governato in una piattaforma di destinazione supportata. Il software open-source Uncoder IO copre il passaggio di traduzione e può essere eseguito in modalità self-hosted (sorgente su GitHub). Nessuno dei tre elimina la validazione della mappatura dei campi.
Esempio: una semplice regola di creazione di processi che traduce EventCode=4688 e New_Process_Name (CIM di Splunk) in EventID == 4688 e NewProcessName (tabella SecurityEvent di Sentinel). Stesso fatto, nome di campo diverso per contratto piattaforma.
Il carattere jolly ancorato a fine di SPL diventa un operatore endswith in KQL. Questa coppia funziona perché è una corrispondenza di campo su singolo evento. Le regole di correlazione non si traducono in modo pulito.
Quanto tempo richiede migrare una libreria di regole e cosa lo determina?
Tre driver determinano lo sforzo.
Numero di regole. Più regole, più cicli di validazione. Ogni regola tradotta necessita di un test contro i dati ingeriti della destinazione.
Campi personalizzati e dipendenze del modello dati. Le regole che fanno riferimento a campi specifici del fornitore, estrazioni personalizzate o tabelle di lookup richiedono un lavoro di mappatura per campo. Più personalizzazioni nel sorgente, più lavoro manuale nella migrazione.
Sforzo di validazione. Ogni regola tradotta deve essere validata contro i campi analizzati della piattaforma di destinazione. Una traduzione sintatticamente corretta può fallire silenziosamente se lo schema di destinazione non popola il campo di riferimento.
La consegna onesta di una valutazione della migrazione è una classificazione per regola: trasporta pulita, trasporta con lavoro di mappatura o richiede una riscrittura manuale. Una stima temporale singola per l’intera libreria rappresenta male la distribuzione dello sforzo.
Come si evita il lock-in la prossima volta?
Tre pratiche.
- Autore in Sigma. Scrivi logica di rilevamento agnostica al fornitore fin dall’inizio. Le regole Sigma si traducono in ogni principale SIEM, EDR e piattaforma XDR. Il contenuto di rilevamento già disponibile in Sigma, come le regole Sigma in SOC Prime’s Core, mantiene la libreria portabile fin dalla prima regola.
- Mantieni la logica nel controllo di versione. Conserva le tue regole di rilevamento in Git insieme alle mappature dei campi e agli eventi di test per ogni backend di destinazione. Le regole viaggiano con il team, non con la piattaforma.
- Traduci al momento del deploy. Utilizza pySigma, sigma-cli o Uncoder per generare query native della piattaforma al momento del deployment. La fonte rimane portabile. L’output compilato è usa e getta.
Questa separazione significa che una migrazione della piattaforma cambia l’obiettivo della traduzione, non la logica di rilevamento.
L’instradamento della telemetria tramite una pipeline è lo stesso che trasferire i rilevamenti?
No. Una pipeline di telemetria (Cribl e strumenti simili) muove dati. Non muove la logica di rilevamento.
Instradare un flusso di log da Splunk a Microsoft Sentinel tramite una pipeline consegna gli eventi a una nuova destinazione. Le regole SPL che giravano su quegli eventi in Splunk non seguono. SPL rimane SPL. La logica di rilevamento deve ancora essere tradotta o riscritta per la piattaforma di destinazione.
Il routing della pipeline risolve il problema della consegna dei dati. La portabilità del rilevamento risolve il problema della traduzione della logica. Sono indipendenti. Un team che instrada la telemetria a un nuovo SIEM senza portare i propri rilevamenti ha dati in un nuovo posto e nessuna regola da abbinare.
L’eccezione è una pipeline che esegue i rilevamenti da sola: Prime Detect di SOC Prime applica le regole in Sigma al livello della pipeline prima del SIEM, e la sua edizione open-source è su GitHub.
Dove questo non tiene
Non tutto si traduce, anche con Sigma. Quattro classi di costrutti richiedono riscritture manuali sulla piattaforma di destinazione.
- Logica di correlazione e statale. Aggregazione di conteggio e valore, sequenza temporale, correlazione multi-evento. Sigma ha aggiunto tipi di regole di correlazione nella sua specifica v2, ma il supporto backend varia per backend di pySigma. La pianificazione rispetto all’esecuzione in streaming cambia anche ciò che una regola può esprimere.
- Funzioni proprietarie. Transazione Splunk, espressioni eval, arricchimento basato su lookup, macro. Gli analoghi in KQL sono parziali.
- Alcuni schemi di aggregazione. I costrutti threshold-over-window e i modelli stats … by … span= si traducono in modo non uniforme tra le piattaforme.
- Riferimenti ai campi contingenti allo schema. La stessa regola di process_creation di Sigma finisce su un campo diverso a seconda della pipeline. Su Sysmon è Image. Su Splunk Windows Security è New_Process_Name. La traduzione è corretta solo contro lo schema effettivamente distribuito.
Questi costrutti sono dove la classificazione per regola conta di più. Aspettati che richiedano una convalida manuale e, in molti casi, una riscrittura da zero.
Lista di controllo per la preparazione della migrazione
[ ] Inventario completo delle regole esportato (ricerche salvate, allerta, ricerche di correlazione)
[ ] Ogni regola classificata: trasporta pulita / trasporta con mappatura / riscrittura richiesta
[ ] Tabella di mappatura dei campi costruita: schema sorgente verso schema destinazione
[ ] Versioni Sigma delle regole portabili create e conservate nel controllo di versione
[ ] Strumenti di traduzione selezionati (pySigma/sigma-cli, Uncoder, o entrambi)
[ ] Coppie di eventi di test create per regola (uno noto come dannoso, uno noto come innocuo)
[ ] Regole tradotte validate contro le tabelle di destinazione con dati effettivamente ingeriti
[ ] Regole di correlazione e statali identificate per riscrittura manuale
[ ] Funzioni proprietarie catalogate (transazione, eval, lookup, macro)
[ ] Finestra di esecuzione parallela definita: entrambe le piattaforme ingurgitando le stesse fonti
[ ] Criteri di confronto dell'output degli allarmi documentati
[ ] Piano di rollback definito: condizioni per tornare alla piattaforma sorgente
FAQ
Cosa succede alle mie regole di rilevamento quando migro a una nuova piattaforma SIEM?
Le regole native della piattaforma non viaggiano. SPL, KQL, e YARA-L devono essere riscritte o tradotte per la piattaforma di destinazione. Una regola autored in Sigma è tradotta una volta per backend, e ogni regola tradotta richiede comunque una validazione contro i campi analizzati di destinazione. La logica di correlazione, logica statale, funzioni proprietarie e alcuni schemi di aggregazione non si traducono in modo chiaro.
Come migro il contenuto di rilevamento da Splunk a Microsoft Sentinel?
Inventaria le regole SPL, classificale per tipo di costrutto, traducci tramite Sigma con pySigma o Uncoder, mappa i campi dallo schema di Splunk allo schema di Sentinel, testa ogni regola su dati effettivamente ingeriti da Sentinel, quindi esegui il cambio con una finestra di esecuzione parallela prima di ritirare la versione SPL. Microsoft documenta lo schema di Sentinel su learn.microsoft.com.
Qual è la differenza tra regole di rilevamento specifiche per il fornitore e agnostiche al fornitore?
Una regola specifica del fornitore è una risorsa della piattaforma su cui funziona. Una regola agnostica al fornitore creata in Sigma è una risorsa del team, conservata nel controllo di versione e tradotta per backend. La differenza di costo è evidente nella migrazione e nell’operazione multi-piattaforma.
Il routing della telemetria tramite una pipeline rende i miei rilevamenti portabili?
No. Una pipeline di telemetria sposta i dati a una nuova destinazione. Non muove la logica di rilevamento che ci si eseguiva sopra. SPL rimane SPL ovunque i log atterrino, quindi le regole necessitano ancora di traduzione o riscrittura.
Quali sono le migliori pratiche per tradurre un linguaggio di query come SPL in KQL?
Traduci la logica, non la sintassi. Mappa ogni campo contro lo schema di destinazione, mantieni un evento di test noto come dannoso e uno noto come innocuo per regola, e rivedi tutto ciò che il traduttore segnala, perché le regole di correlazione e le funzioni proprietarie necessitano di revisione umana. pySigma, sigma-cli, e Uncoder gestiscono la traduzione Sigma, e nessuno di loro elimina la validazione della mappatura dei campi.
Valuta la tua copertura SIEM esistente e crea un piano per la tua transizione utilizzando Prime Hunt. Prime Hunt esamina tutte le tue regole SIEM, identifica le lacune e ti traccia un percorso verso una copertura completa – un lavoro critico prima di una migrazione SIEM.
