Segui Le operazioni di rilevamento multi-tenant sono la pratica di gestire una sorgente di logica di rilevamento vendor-agnostica, tradotta e regolata per ciascun tenant, così un registro di clienti che utilizzano diverse piattaforme SIEM rimane coerente, regolabile e riportabile da un’unica fonte governata.
Un MSSP che gestisce il rilevamento per dozzine di tenant affronta una domanda strutturale: ogni cliente riceve una propria copia di ogni regola di rilevamento o una singola fonte governata si traduce e si adatta per ciascun tenant? La risposta determina il costo operativo, la precisione del reporting della copertura e se una modifica alla logica condivisa si propaga immediatamente o si accumula in un backlog di patch manuali.
Questa pagina copre il livello di contenuto di rilevamento di quel modello: una fonte di logica di rilevamento vendor-agnostica, gestita centralmente, tradotta e regolata per ciascun tenant. Hunters opera al livello di analisi e operazioni, una piattaforma alternativa a SOC e SIEM per MSSP e fornitori di MDR. ContraForce opera al livello di gestione dei casi e workflow di consegna, orientato alla suite di sicurezza Microsoft (Microsoft Sentinel e Defender XDR). La fonte del contenuto di rilevamento descritta qui si trova a monte, fornendo la logica di rilevamento vendor-agnostica che i livelli di esecuzione, investigazione e reporting consumano.
Ambito: piattaforme SIEM (Splunk, Microsoft Sentinel, Google SecOps, Elastic Security, CrowdStrike). L’EDR come target di distribuzione è fuori ambito fino a quando il supporto per piattaforma non è verificato.
Un MSSP è anche un’entità regolata a pieno titolo. Il Regolamento di Esecuzione della Commissione (UE) 2024/2690, in vigore dal 7 novembre 2024, stabilisce i requisiti di monitoraggio e registrazione (sezione 3.2 dell’Allegato) per i fornitori di servizi di sicurezza gestiti sotto NIS2. L’obbligo di fornire prove del MSSP stesso, non solo dei suoi tenant, guida come il contenuto di rilevamento viene governato e riportato.
Come può un SOC multi-tenant mantenere la logica di rilevamento coerente tra gli ambienti dei clienti che usano diverse piattaforme SIEM?
Scrivi la logica di rilevamento una volta in un formato vendor-agnostico (Sigma). Traducila per il SIEM di ciascun tenant. Gestisci la fonte centralmente.
Il manufatto base condiviso
La base è un unico manufatto di logica di rilevamento. La sua condizione logica viene valutata contro uno schema comune e normalizzato anziché contro i campi di log grezzi di un tenant. Questo è ciò che rende la stessa regola portatile su Splunk, Microsoft Sentinel, Google SecOps, Elastic, e CrowdStrike senza riscrivere la logica di rilevamento stessa.
La normalizzazione mappa campi specifici della fonte a quello schema condiviso preservandone il significato. Una regola scritta contro il campo normalizzato auth.result significa la stessa cosa indipendentemente da quale provider di identità ha prodotto l’evento: auth.result si risolve in {successo, fallimento, sfida} per un contratto semantico nominato, non in base a ciò che l’IdP del cliente chiama il campo.
L’overlay per tenant
Ogni tenant ottiene un overlay. L’overlay porta la mappatura dei campi che traduce i campi sorgenti grezzi di quel tenant nello schema normalizzato condiviso, e i parametri di tuning (soglie, finestre temporali, esclusioni di rumore) adattati all’ambiente di quel tenant. Base e overlay sono versionati separatamente.
Un aggiornamento logico alla base si propaga a ogni tenant il cui overlay mappa i campi richiesti. Un cambiamento di tuning all’overlay di un tenant tocca solo quel tenant.
Condiviso versus specifico per tenant
Cosa rimane condiviso: la condizione della logica di rilevamento, le definizioni del contratto semantico da cui dipende la logica, il MITRE ATT&CK tag tecnico, e la versione e la cronologia delle modifiche.
Cosa è specifico per tenant: la mappatura dei campi da grezzi a normalizzati, lo stato di convalida del contratto in fase di runtime (pass o fail valutato in base al flusso di eventi reale del tenant, non una proprietà statica della regola), la traduzione del target di piattaforma, e i parametri di tuning.
Come gestisci il contenuto di rilevamento attraverso dozzine di ambienti clienti senza forkarlo per cliente?
Un manufatto governato per rilevamento, non un fork per cliente.
Forkare il file delle regole per cliente significa mantenere copie indipendenti di ciò che dovrebbe essere un unico manufatto governato. Una correzione logica o un nuovo aggiornamento della tecnica di evasione deve essere riaffermato manualmente in ogni fork. I fork divergono e la singola cronologia delle modifiche versione sparisce.
Quando un revisore o un cliente chiede chi ha cambiato questa regola, quando e perché, la risposta deve tracciare a una sola timeline. Copie divergenti che possono o meno riflettere la stessa correzione lasciano quella domanda senza risposta. Ciò è un fallimento della governance e del controllo delle modifiche, e mina direttamente la traccia delle evidenze su cui gli auditor fanno affidamento.
Il modello base-plus-overlay mantiene un manufatto governato:
| Livello | Contenuti | Ambito |
|---|---|---|
| Base (condivisa) | Condizione della logica di rilevamento, definizioni del contratto semantico/temporale/di correlazione, tag tecnico MITRE ATT&CK, versione e cronologia delle modifiche | Tutti i tenant |
| Overlay (per tenant) | Mappatura dei campi da grezzi a normalizzati, traduzione del target di piattaforma, soglie, finestre temporali, esclusioni di rumore | Un tenant |
Una modifica alla logica di base si propaga per costruzione. Solo la mappatura e il tuning restano locali. Questo è la disciplina Detection-as-Code applicata alle operazioni multi-tenant: le modifiche alle regole sono versionate, riviste e tracciate come manufatti di codice. L’automazione del deployment porta la base aggiornata ad ogni tenant il cui overlay la supporta.
Il versionamento del contratto governa la base. Le modifiche devono essere versionate e le modifiche sostanziali richiedono un nuovo ID del contratto, quindi ogni tenant riceve un percorso di aggiornamento riconciliabile anziché una rottura silenziosa.
SOC Prime lavora con gli MDR per progettare operazioni di ingegneria del rilevamento dalle rilevazioni SIEM alla riduzione del volume SIEM con Prime Detect.
Come si regola per cliente senza rompere la regola condivisa?
Regola nell’overlay. La regola di base rimane fissa.
L’overlay porta la configurazione specifica del tenant in due parti.
Mappatura dei campi. I prodotti sorgente di ogni tenant nominano lo stesso fatto in modo diverso nel log grezzo, quindi l’overlay traduce quei campi grezzi nello schema normalizzato condiviso. La mappatura deve soddisfare indipendentemente lo stesso contratto semantico che ogni altro tenant condivide.
Un fallimento concreto mostra perché questo è importante. L’overlay di un tenant mappa il risultato “MFA in sospeso” del suo provider di identità sul valore normalizzato “fallimento” invece che su “sfida.” La logica di rilevazione bypass MFA condivisa, che cerca un accesso riuscito senza un evento di sfida precedente, non vede mai un valore “sfida” per quel tenant. Ogni accesso riuscito viene segnalato come un bypass: un massiccio falso positivo per quel tenant, mentre la regola identica è corretta per ogni altro tenant il cui overlay mappa correttamente l’enum.
La regola non è mai cambiata. Il fallimento è interamente nell’overlay, un errore nell’overlay che si maschera come un bug nella regola.
Parametri di tuning. Tolleranze temporali di correlazione per collegare eventi correlati, finestre di timeout sess e periodi di grazia per sequenze di autenticazione, e esclusioni di rumore. Una tolleranza impostata troppo stretta perde correlazioni reali. Se impostata troppo larga, unisce eventi non correlati. Queste finestre potrebbero richiedere regolazione per tenant a causa delle caratteristiche di sincronizzazione dell’orologio e latenza di quel tenant.
La condizione della logica di rilevamento della regola di base, valutata contro i campi normalizzati, non cambia mai per un singolo tenant. Lo stato di convalida del contratto deve essere valutato per tenant a runtime, non assunto dalla regola o dal tipo di sorgente.
Come posso riportare la copertura di rilevamento MITRE ATT&CK a ciascun cliente quando ogni cliente ci invia fonti di log diverse?
Calcola la copertura per tenant rispetto al proprio set di tecniche prioritizzate. Non riportare mai un unico numero di libreria tra i tenant. Il metodo completo di misurazione è descritto nella pagina associata sulla misurazione della copertura di rilevazione MITRE ATT&CK.
Modello di copertura:
Copertura (tenant) = tecniche in cui [telemetria valida E regola distribuita E regola dimostrata a fuoco] diviso per il conteggio delle tecniche prioritizzate di quel tenant.
Quando una tecnica conta come coperta
Una tecnica conta come coperta solo quando tutte queste condizioni sono soddisfatte:
- Telemetria valida per questo tenant. La fonte dati richiesta è raccolta, attivamente ingestendo, passando i contratti semantici, temporali e di correlazione, e soddisfacendo gli SLO di qualità (tasso di nullità, freschezza). Tutto ciò è valutato rispetto al flusso di eventi reale di questo tenant, non a un default di tipo sorgente.
- Regola distribuita e mappata alla tecnica. Un fatto d’inventario Detection-as-Code: quale regola esiste, quale tag MITRE ATT&CK porta, la sua versione.
- La regola ha la prova di attivazione. Baselining del tasso di attivazione, eventi canarino, o convalida di test atomici che mostrano che la regola produce avvisi su attività reale o emulata. Un tag tecnico senza un record di attivazione è un’etichetta, non una prova.
Il denominatore è il proprio sottogruppo prioritizzato di tecniche ATT&CK di quel tenant, mai la matrice completa di ATT&CK. Mai la dimensione della libreria di regole del fornitore. ATT&CK techniques. Never the full ATT&CK matrix. Never the vendor’s rule-library size.
Segnalazione degli stati di divario
Segnala gli stati di divario distintamente, mai come un numero collassato:
| Stato | Significato | Rimedi |
|---|---|---|
| VALIDO | Tutti i controlli superati, regola distribuita, prova di attivazione su file | Coperto alla data del report |
| INVALIDO | Sorgente richiesta non raccolta o non ingestata | Abilitazione della sorgente o riparazione dell’ingestione |
| DEGRADATO | Sorgente raccolta ma contratto o SLO di qualità fallente | Mappatura, parser, o correzione dello schema |
| Divario di contenuto | Telemetria valida, nessuna regola mappata alla tecnica | Sviluppo del contenuto |
Non collassare INVALIDO e DEGRADATO in un unico numero di “divario”. Modi di fallimento diversi richiedono rimedi diversi e producono conversazioni diverse con i clienti.
Segnala con una data. La copertura è nel tempo puntuale.
Cosa fa il riutilizzo dei contenuti al margine e al carico di formazione degli analisti?
Il riutilizzo dei contenuti tra i tenant converte il costo di ingegneria del rilevamento per cliente in un costo condiviso e ammortizzato. Quando la logica di rilevamento di base è redatta una volta e tradotta per tenant, il costo ingegneristico si diffonde tra i clienti.
Margine. Ogni tenant che esegue la base condivisa evita ore incrementali di ingegneria del rilevamento. Il miglioramento del margine è strutturale. Il programma partner MDR di SOC Prime stima il risparmio a 4000 ore annue su ricerca di minacce e codifica del contenuto di rilevamento. puts the saving at 4K hours per year on threat research and detection content coding.
Carico di formazione. Una metodologia Detection-as-Code. Uno schema normalizzato. Un set di semantiche dei contratti. Gli analisti si integrano rispetto al modello condiviso piuttosto che rispetto a librerie di regole per cliente con naming divergente, struttura, e intento. Quando un analista si sposta dalla coda di un tenant a un’altra, la logica di rilevamento, lo schema, e i contratti sono già familiari.
L’obiezione onesta. Il contenuto di rilevamento condiviso non cancella la differenziazione MSSP. La differenziazione si sposta su tuning, risposta, e reporting. Gli overlay specifici per tenant, i runbook di risposta, e i report orientati al cliente sono gli ambiti in cui si mostra il valore dell’MSSP. Un prospetto che sente “contenuto condiviso” e pensa “commoditizzato” deve vedere esattamente dove risiede il lavoro personalizzato.
Driver regolatorio. L’obbligo di prove del MSSP stesso sotto NIS2, tramite il Regolamento di Esecuzione della Commissione (UE) 2024/2690, richiede prove di monitoraggio e registrazione da parte del MSSP stesso, non solo dai suoi tenant. Il modello condiviso ammortizza quella produzione di prove.
Dove questo non vale
Il modello base-plus-overlay assume che la regola di base sia scritta contro uno schema normalizzato che ogni prodotto sorgente del tenant possa soddisfare. Il modello si rompe nelle seguenti condizioni.
- Prodotti sorgente che non emettono dati richiesti. Diversi prodotti sorgente, o diverse versioni dello stesso prodotto, possono non emettere per nulla una componente di dati richiesta. Nessun overlay può risolvere un campo strutturalmente assente. Questo è un divario INVALIDO, rimediato tramite abilitazione o aggiornamento della sorgente.
- Disponibilità della sorgente. Un tenant non ha integrato una fonte di log richiesta, o la sua ingestione è cessata. La regola, la mappatura, e il tuning possono essere tutti corretti, e le tecniche interessate rimangono scoperte fino a quando la sorgente riprende a fluire.
- Mancanza di tolleranza di correlazione. La tolleranza temporale predefinita condivisa può perdere correlazioni reali per un tenant con una sincronizzazione dell’orologio o latenza insolita. Il tuning per tenant delle finestre di correlazione è richiesto, non opzionale.
- Modelli di minaccia unici o vincoli di residenza dei dati. Un tenant con un profilo di minaccia genuinamente unico può richiedere una logica di rilevamento personalizzata che la base condivisa non contiene. Un vincolo che proibisce di condividere gli artefatti della logica di rilevamento attraverso confini organizzativi ha lo stesso effetto.
- L’isolamento del tenant è non negoziabile. Il modello condivide la LOGICA di rilevamento tra i tenant (testo della regola, definizioni dei contratti). Non condivide mai dati del tenant, cache di arricchimento, stato di allerta o risultati di convalida attraverso un confine di tenant. Qualsiasi architettura in cui le ricerche di arricchimento di un tenant o la coda di allerta si riversano in quella di un altro è per design un incidente a priorità uno. La condivisione della logica e dei dati sono affermazioni diverse.
Lista di controllo del modello operativo multi-tenant
Autore e governa la regola di base
- Logica di rilevamento redatta in un formato vendor-agnostico (Sigma) contro uno schema normalizzato e definito dal contratto
- Regola di base separata dall’overlay del tenant: la logica di rilevamento, le definizioni dei contratti, il tag MITRE ATT&CK e la cronologia delle versioni rimangono condivisi
- Overlay per tenant porta solo mappatura dei campi, traduzione della piattaforma e parametri di tuning, versionati separatamente dalla base
- Le modifiche alla regola di base si propagano a ogni tenant per costruzione
- La cronologia delle modifiche traccia una timeline governata per regola di base, con i cambiamenti degli overlay tracciati per tenant
- Versionamento dei contratti applicato: modifiche sostanziali portano un nuovo ID del contratto
Valida mappatura e traduzione della piattaforma
- Le mappature dei campi soddisfano lo stesso contratto semantico per ogni tenant, con convalida del contratto eseguita a runtime contro il flusso di eventi reale di ogni tenant
- Traduzione della piattaforma validata per ogni SIEM target (Splunk, Microsoft Sentinel, Google SecOps, Elastic Security, CrowdStrike)
Calcola la copertura per tenant
- Copertura calcolata per tenant rispetto al proprio set prioritario di tecniche ATT&CK
- Il numeratore di copertura richiede telemetria valida, regola distribuita e regola dimostrata a fuoco, tutte vere insieme
- Gli stati di divario distinti: VALIDO, INVALIDO (sorgente mancante), DEGRADATO (sorgente presente, convalida fallente) e divario di contenuto (telemetria valida, nessuna regola mappata)
Correggi, isola e riporta
- Tolleranze temporali di correlazione riviste per tenant per il fit della sincronizzazione dell’orologio e latenza
- Il tuning viene regolato nell’overlay, mai forking la regola di base
- Isolamento tenan mantenuto: nessun dato condiviso, cache di arricchimento, stato di allerta o risultati di convalida attraverso confini dei tenant
- La copertura viene riportata con una data, per tenant, mai come un numero di libreria attraverso il libro
- L’obbligo di prove regolatorie del MSSP stesso (Regolamento di Esecuzione NIS2 2024/2690) affrontato insieme agli obblighi dei tenant
- Formazione degli analisti allineata alla metodologia Detection-as-Code condivisa, schema normalizzato e semantica dei contratti
FAQ
Come può un SOC multi-tenant mantenere la logica di rilevamento coerente tra gli ambienti dei clienti che usano diverse piattaforme SIEM?
Scrivi la logica di rilevamento una volta in Sigma, un formato vendor-agnostico, e traducila per il SIEM di ciascun tenant. Un modello base-plus-overlay mantiene la logica di rilevamento condivisa e la mappatura delle tecniche MITRE ATT&CK in un unico manufatto governato, mentre l’overlay di ciascun tenant porta la mappatura dei campi, la traduzione della piattaforma e i parametri di tuning per quell’ambiente. Questo ambito riguarda le piattaforme SIEM (Splunk, Microsoft Sentinel, Google SecOps, Elastic, CrowdStrike). L’EDR come target di distribuzione è fuori ambito fino a quando il supporto per piattaforma non è verificato.
Come posso riportare la copertura di rilevamento MITRE ATT&CK a ciascun cliente quando ogni cliente ci invia fonti di log diverse?
Calcola la copertura per tenant rispetto al proprio set di tecniche ATT&CK prioritizzate, mai come un numero di libreria intero attraverso il libro. Una tecnica conta come coperta solo quando la telemetria è valida per quel tenant, una regola è distribuita e mappata alla tecnica, e la regola ha la prova di attivazione. Riporta quattro stati di divario distinti: VALIDO, INVALIDO (sorgente mancante), DEGRADATO (sorgente raccolta ma convalida fallente), e divario di contenuto (telemetria valida, nessuna regola mappata). Ogni report di copertura porta una data.
Il contenuto di rilevamento condiviso cancella la differenziazione di un MSSP?
Il contenuto di rilevamento condiviso sposta dove risiede la differenziazione. Il valore distintivo dell’MSSP si sposta sul tuning specifico per tenant, sui runbook di risposta e sul reporting della copertura orientato al cliente. Gli overlay dei tenant, i playbook di risposta e l’analisi della copertura per tenant sono i luoghi in cui l’esperienza dell’MSSP si mostra a ciascun cliente.
