Ogni strumento vede la propria porzione di infrastruttura e genera i propri segnali. Un attacco, invece, attraversa più sistemi e si svolge nel tempo: spesso di notte, spesso con credenziali valide e strumenti legittimi, spesso senza lasciare tracce evidenti su un singolo dispositivo. Per coglierlo serve qualcuno che guardi in modo continuo, che sappia mettere insieme segnali provenienti da fonti diverse e che, quando qualcosa accade, sappia dire con chiarezza che cosa fare.

È il mestiere di un Security Operations Center. Negli ultimi anni, però, l'offerta di SOC gestiti si è moltiplicata e i messaggi si somigliano tutti: monitoraggio 24/7, rilevamento avanzato, e ora, immancabilmente, intelligenza artificiale. Per chi deve scegliere — un CISO, un responsabile IT, un partner che deve proporre il servizio ai propri clienti — diventa difficile capire dove stiano le differenze reali.

Questo articolo prova a renderle esplicite. Descrive che cos'è Orizon Oversight e come funziona; lo confronta con i due modelli che il mercato propone più spesso, il SOC costruito attorno a un EDR e il cosiddetto "AI SOC"; spiega perché, in Oversight, l'intelligenza artificiale è uno strumento nelle mani degli analisti e non un loro sostituto; e si sofferma sul punto che, a nostro avviso, pesa di più nella vita reale di un cliente: il momento successivo alla notifica di un incidente, quando non basta sapere che c'è un problema, ma serve sapere come risolverlo.

La catena di rilevamento si articola in alcuni passaggi, ciascuno con un ruolo preciso:

1. Raccolta. I dati arrivano da endpoint ed EDR, firewall e apparati di rete, server Windows e Linux, identity provider e directory, ambienti cloud e SaaS (ad esempio Microsoft 365, Google Workspace, AWS, Azure) e applicazioni di business. L'inoltro avviene tramite collector e meccanismi standard — syslog, API — senza richiedere di riprogettare la rete. La piattaforma integra in questo momento oltre 500 differenti vendor.
2. Normalizzazione. Eventi eterogenei vengono ricondotti allo schema aperto OCSF (Open Cybersecurity Schema Framework), così che un login su un firewall, un processo su un endpoint e un accesso a Microsoft 365 possano essere confrontati nello stesso linguaggio.
3. Security Data Lake. I dati vengono conservati e restano interrogabili, sia per l'operatività quotidiana sia per il threat hunting retrospettivo.
4. Correlazione e rilevamento. Motori di correlazione potenziati da AI e machine learning, con regole mappate sul framework MITRE ATT&CK e arricchimento da threat intelligence, fanno emergere i segnali rilevanti dal rumore.
5. Validazione e indagine. Ciò che l'AI rileva e correla viene verificato dagli analisti, che lo confermano, lo scartano o lo approfondiscono. Solo a quel punto diventa una attack story: la ricostruzione coerente di un attacco, dalla prima traccia all'ultimo passo osservato.
6. Consegna e risposta. Il cliente — o il partner che lo segue — riceve l'indagine con le evidenze e le raccomandazioni di mitigazione e remediation. Playbook automatici (SOAR) supportano arricchimento ed escalation; le azioni di contenimento sulle tecnologie integrate, come l'EDR, vengono eseguite secondo quanto concordato con il cliente.

Fin qui, la descrizione potrebbe adattarsi a più di un servizio sul mercato. Le differenze diventano evidenti quando si confronta Oversight con i due modelli di SOC che oggi il cliente incontra più spesso.

Il limite non sta nella qualità dell'EDR, ma nel suo perimetro. Un SOC basato su EDR vede dove c'è l'agente. E un attacco raramente vive solo sull'endpoint; spesso si svolge altrove, o transita altrove prima di arrivarci:

• l'identità: un accesso VPN o Microsoft 365 con credenziali valide rubate, o con un cookie di sessione sottratto da un infostealer, non genera necessariamente alcun evento sospetto su un endpoint gestito;
• l'e-mail: regole di inoltro create su una casella compromessa, messaggi di phishing interni inviati da un account legittimo;
• il perimetro: lo sfruttamento di una vulnerabilità su un firewall o su un gateway VPN avviene su un apparato su cui un agente EDR, di norma, non può essere installato;
• il cloud e le applicazioni: modifiche ai permessi in un tenant cloud, accessi anomali a un'applicazione di business;
• i dispositivi non gestiti: server legacy, sistemi OT, appliance, macchine di terzi.

C'è poi un secondo aspetto, meno tecnico ma rilevante: il SOC diventa dipendente da quel prodotto. Cambiare EDR significa, spesso, cambiare anche fornitore di SOC.

Oversight parte dal presupposto opposto. È agnostico rispetto alle tecnologie del cliente e non sostituisce l'EDR: ne estende il valore, integrandolo come una delle fonti — CrowdStrike, SentinelOne, Microsoft Defender, Sophos e altre — e correlandone la telemetria con quella di identità, e-mail, firewall, cloud e applicazioni in un unico Security Data Lake. L'EDR resta anche lo strumento con cui orchestrare il contenimento direttamente sull'endpoint. Per questo, alla domanda "abbiamo già un EDR, ci serve un SOC?", la risposta più corretta non è "sì, perché l'EDR non basta", ma "sì, perché il suo EDR diventa molto più utile quando qualcuno ne legge i segnali insieme a tutto il resto".

Oggi, però, avere l'AI non è più un elemento distintivo: quasi tutti la dichiarano. Conta piuttosto quale lavoro toglie davvero, e chi resta responsabile delle decisioni. Quando l'AI viene messa al centro del SOC, tendono a emergere tre problemi.

In Oversight l'intelligenza artificiale è uno strumento dato agli analisti, non un loro sostituto. Fa ciò che sa fare meglio e più velocemente di una persona: correla grandi volumi di eventi, raccoglie il contesto, ricostruisce le sequenze, svolge il lavoro ripetitivo di indagine. Ma ciò che l'AI rileva viene convalidato o verificato dagli analisti prima di diventare un'indagine consegnata al cliente, proprio perché l'AI può sbagliare. La decisione di sicurezza resta a una persona che ne ha la competenza e la responsabilità.

I tre modelli a confronto

Una sintesi necessariamente semplificata: le offerte di mercato variano, e il confronto va sempre verificato sul caso specifico.

Nel modello più diffuso, il SOC fa bene il proprio mestiere — rileva, qualifica, notifica — e poi consegna al cliente un alert o un ticket del tipo: "Rilevata attività sospetta sul server X. Consigliamo di isolare la macchina e avviare un'indagine." Da quel punto in poi il team IT del cliente, o il partner che lo assiste, è spesso solo: deve capire da dove è partito l'attacco, fin dove è arrivato, quali account e quali sistemi sono coinvolti e che cosa va corretto perché non si ripeta. Sono proprio le ore in cui le competenze scarseggiano e la pressione è massima.

Oversight è pensato per ridurre al minimo questo vuoto. Ciò che arriva al cliente non è un altro alert, ma un'indagine già istruita: la attack story, costruita con il supporto dell'AI e convalidata dagli analisti, che mette a disposizione di chi deve intervenire:

• la cronologia dell'attacco, passo per passo, con ciascun passaggio mappato sulle tecniche MITRE ATT&CK;
• le evidenze su cui si basa la ricostruzione, consultabili anche in autonomia con l'add-on DX Data Explorer;
• i sistemi coinvolti: host, account, indirizzi e servizi toccati, e ciò che invece risulta estraneo;
• perché è rilevante: la gravità, il potenziale impatto e la fase dell'attacco in cui ci si trova;
• le raccomandazioni di mitigazione e remediation: che cosa fare subito per contenere, che cosa correggere dopo, su quali sistemi, in quale ordine, e come verificare che l'intervento abbia avuto effetto.

La risposta resta nelle mani del partner o del cliente, che mantengono il controllo del proprio ambiente e decidono come e quando intervenire. Ma non partono da zero: partono da un piano d'azione già impostato.

Un esempio

Un caso illustrativo aiuta a rendere l'idea della differenza. Alle 02:14 un account utente si collega alla VPN aziendale da un indirizzo mai visto prima. Pochi minuti dopo, dallo stesso account, partono interrogazioni massive verso Active Directory; alle 02:31 su un file server viene eseguito uno script PowerShell che crea un'attività pianificata e tenta di interrompere il servizio di backup.

Una notifica tradizionale potrebbe limitarsi all'ultimo evento: esecuzione PowerShell sospetta su SRV-FILE-02, si consiglia verifica.

La attack story di Oversight collega invece i quattro passaggi in un'unica sequenza — accesso iniziale con credenziali valide, ricognizione, esecuzione, tentativo di compromettere la capacità di ripristino — e, dopo la verifica dell'analista, la accompagna con raccomandazioni di questo tipo:

• mitigazione immediata: isolare SRV-FILE-02 tramite l'EDR integrato, chiudere la sessione VPN attiva, bloccare l'indirizzo di origine;
• reset delle credenziali dell'account coinvolto e revoca delle sessioni attive, anche sui servizi cloud;
• rimozione dell'attività pianificata creata alle 02:31 e verifica di eventuali meccanismi di persistenza analoghi su altri sistemi;
• verifica dell'integrità dei backup prima di qualsiasi ripristino;
• revisione della policy di autenticazione VPN per il gruppo a cui appartiene l'account;
• controlli di verifica successivi, eseguibili anche dal cliente in DX Data Explorer, se attivo.

Esempio illustrativo, costruito a scopo esplicativo: contenuti e livello di dettaglio delle raccomandazioni dipendono dal tipo di incidente e dalle fonti integrate.

Per il cliente significa passare dal "che cosa facciamo adesso?" a un piano d'azione chiaro. Per il partner significa poter intervenire subito, con un perimetro di lavoro definito, invece di ricostruire l'incidente da zero.

DX Data Explorer: il cliente vede i propri dati

L'obiezione è nota: "se affido il monitoraggio a terzi, resto al buio". DX Data Explorer permette al cliente di interrogare in self-service lo stesso data lake su cui lavorano gli analisti: dall'alert al dato grezzo, con query strutturate, dashboard personalizzabili e dati esportabili, via browser con SSO e MFA.

Non sostituisce il SOC; lo rende verificabile. Il cliente può approfondire un evento, controllare le evidenze di un'indagine o produrre un'evidenza per un audit senza aprire un ticket e attendere una risposta. È l'add-on da proporre quando il cliente ha un team di sicurezza interno, o un CISO che non vuole dipendere da terzi per rispondere alle domande del proprio consiglio di amministrazione.

Cold Storage: la memoria a lungo termine dei log

L'obiezione, in questo caso, arriva più tardi: "quando serve ricostruire che cosa è successo, i log non ci sono più". È un problema strutturale, non una svista. La finestra "calda" di un SIEM — i dati immediatamente consultabili per la detection e l'indagine quotidiana — è costosa da mantenere, e per questo viene tenuta corta: spesso intorno ai 90 giorni. Ma un'indagine forense, una richiesta di un'autorità o un audit possono arrivare mesi o anni dopo l'evento, quando le evidenze non esistono più.

Cold Storage estende il ciclo di vita del dato oltre quella finestra. I log, una volta usciti dalla fase "calda", vengono trasferiti in un archivio "freddo" cifrato, senza appesantire — né far crescere di costo — l'ambiente di analisi attivo. Nello specifico:

• retention configurabile, con orizzonti fino a 36 mesi, da definire sulla base dei requisiti normativi e contrattuali dell'organizzazione;
• archivio cifrato e durevole, con controlli di integrità integrati;
• ripristino ed export on-demand: i dataset archiviati tornano in formato consultabile quando servono per un'indagine, oppure vengono esportati per un audit.

Il punto che merita di essere raccontato al cliente è proprio quello dell'integrità. Un log conservato ma alterabile ha un valore limitato: i controlli di integrità sono ciò che permette di dimostrare che i record non sono stati modificati, ed è questo a conferire loro valore probatorio davanti a un revisore, a un'autorità o in un contenzioso.

È l'add-on da proporre a chi ha obblighi di conservazione delle evidenze — perimetro NIS 2 o DORA, settori regolamentati, organizzazioni soggette ad audit periodici — e a chi, avendo già vissuto un incidente, sa quanto costa non poter ricostruire ciò che è successo. Funziona bene insieme a DX: Cold Storage conserva, DX consente di interrogare ciò che è stato conservato.

Dark Web Intelligence: oltre l'MFA

Il terzo add-on riguarda l'identità. Gli infostealer sottraggono non solo credenziali ma anche cookie di sessione già autenticati, che consentono di aggirare l'autenticazione a più fattori. Dark Web Intelligence monitora forum, marketplace e canali dell'ecosistema infostealer alla ricerca di credenziali e sessioni riconducibili all'organizzazione, filtrando i risultati sulle identità aziendali reali e consentendo di invalidare le sessioni e ruotare le credenziali prima che vengano usate. È disponibile in due livelli: una scansione mensile, adatta a esigenze di compliance e a organizzazioni a basso rischio, e un monitoraggio continuo 24/7 con remediation immediata.

Oversight porta le capacità di un SOC enterprise — monitoraggio 24/7, correlazione multi-sorgente, analisti che convalidano ogni rilevamento — a organizzazioni che non possono costruirne uno interno. Si distingue da un SOC basato su EDR perché vede oltre l'endpoint e ne estende il valore invece di dipenderne. Si distingue da un "AI SOC" perché l'intelligenza artificiale è uno strumento nelle mani degli analisti: toglie il lavoro ripetitivo, mentre la decisione resta umana. E, soprattutto, non si ferma all'allarme: consegna un'indagine già istruita, con le evidenze, i sistemi coinvolti e le raccomandazioni per la mitigazione e la remediation.

Per il partner non è "un altro servizio da vendere": è un servizio ricorrente che valorizza gli strumenti già presenti presso il cliente, lascia a lui il controllo della risposta e, a ogni incidente, gli offre un perimetro di intervento chiaro.

I prossimi passi sono concreti: una sessione di qualifica per censire asset e fonti di log; una dimostrazione della console, di una attack story e di una query live in DX; e la definizione del perimetro e delle procedure di escalation per l'onboarding.

Per saperne di più: orizon.one/oversight