Oggi praticamente ogni organizzazione ha un EDR. Eppure i SOC continuano ad annegare in migliaia di notifiche al giorno, e gli attaccanti più abili continuano a passare. Come è possibile, se la tecnologia di rilevamento non è mai stata così avanzata?

La risposta non è “hai scelto l’EDR sbagliato”. L’EDR, quasi sempre, è efficiente. Il punto è un altro: un EDR è costruito per funzionare bene ovunque e su qualunque azienda e, proprio per questo, non è calibrato sul tuo contesto specifico.

Per capire perché, partiamo da due parole che ogni team di sicurezza conosce fin troppo bene.

Una regola di rilevamento può sbagliare in due modi opposti.

Il falso positivo è l’allarme che scatta su un’attività in realtà legittima: uno script dell’IT, un gestionale datato, un processo interno un po’ insolito. Preso singolarmente sembra innocuo. Il problema è il volume: quando le notifiche inutili si accumulano, l’analista finisce per abituarsi al rumore. E un SOC sommerso di rumore, paradossalmente, diventa più cieco — perché il segnale vero si confonde tra mille non-eventi.

Il falso negativo è l’opposto: l’attività malevola che non genera alcun allarme. È l’errore silenzioso, quello che si scopre quando ormai è tardi. Può emergere quando un comportamento ostile assomiglia da vicino alle attività legittime di quello specifico ambiente: senza regole calate sul contesto, un segnale debole ma significativo rischia di passare inosservato.

Falsi positivi e falsi negativi sembrano problemi diversi, ma hanno la stessa radice: una regola che non conosce il tuo ambiente. Troppo rumorosa dove le tue attività legittime la attivano per sbaglio, troppo permissiva dove l’attaccante riesce a confondersi con la tua normalità. Ridurre l’uno senza far esplodere l’altro non è una questione di “alzare o abbassare una soglia”: è una questione di conoscere il contesto.

Gli EDR sono una tecnologia imprescindibile. Sono sviluppati da grandi player globali della cybersecurity, coprono in modo efficace le minacce note e gli scenari più comuni, e rappresentano il punto di partenza fondamentale di qualsiasi strategia di difesa.

Ed è proprio questa universalità ad aprire lo spazio per fare un passo in più. Quelle regole di rilevamento sono progettate per adattarsi a decine di migliaia di organizzazioni diverse, in ogni settore e in ogni Paese. Per funzionare ovunque, partono da un riferimento comune: l’azienda “standard”. Solo che l’azienda standard non esiste.

Ogni organizzazione ha una propria normalità:

• uno stack tecnologico, applicazioni verticali e tooling interno che, fuori contesto, possono sembrare attività sospette;
• processi di business che generano comportamenti del tutto legittimi ma “rumorosi”;
• un profilo di rischio e una superficie d’attacco unici.

Una regola pensata per un ospedale difficilmente sarà altrettanto efficace in un’azienda manifatturiera. E persino due aziende dello stesso settore espongono superfici diverse, a seconda degli strumenti, delle configurazioni e della maturità dei processi IT. Ciò che è anomalo in un’organizzazione è perfetta routine in un’altra.È questa la ragione per cui una regola generica, pensata per lo scenario standard, produce contemporaneamente troppo rumore e troppi punti ciechi.

A questo si aggiunge un aspetto pratico: gran parte della logica di rilevamento nativa funziona in modalità black-box — vedi che un allarme è scattato, o non è scattato, ma non puoi entrare nel dettaglio della sua logica né adattarla in profondità alle tue esigenze reali.

Un EDR è come un abito di ottima qualità comprato in taglia standard. Ti sta, ti copre, fa il suo lavoro. Ma se vuoi che ti calzi davvero, qualcuno deve prenderti le misure e cucirlo su di te. Quella sartoria, nella cybersecurity, ha un nome: Detection Engineering.

La Detection Engineering è la disciplina che parte dalle regole standard dell’EDR e le potenzia, adatta e personalizza sul contesto reale di ogni organizzazione. Non sostituisce l’EDR: lo cala sulle specifiche esigenze del cliente, trasformando una protezione “di serie” in una protezione su misura.

Ma come si adattano, nella pratica, le regole standard? Il presupposto è l’accesso al dato telemetrico dell’EDR. Ogni agente raccoglie dagli endpoint una grande quantità di telemetria grezza — processi, connessioni di rete, eventi su file e registro, attività degli utenti. Andare oltre gli alert preconfezionati e accedere direttamente a questi dati permette di scrivere e inserire regole di detection costruite proprio su quella telemetria. È così che il flusso di alert smette di essere solo standard e diventa ottimizzato e performante.

In concreto significa:

• creare regole di rilevamento personalizzate, modellate su architettura, tecnologie e rischi peculiari dell’azienda;
• dare un significato ai segnali deboli, riconoscendo comportamenti che hanno senso solo in quel preciso ambiente;
• correlare più eventi tra loro, perché spesso non è il singolo segnale a raccontare un attacco, ma la loro sequenza;
• integrare intelligence di contesto, comprese indicazioni specifiche per il mercato di riferimento, che i feed globali tendono a sottopesare.

La Detection Engineering non è un’attività “una tantum”. È un processo continuo: ogni regola viene progettata, messa in produzione, osservata sul campo, affinata e — quando serve — sostituita. Le minacce evolvono, l’ambiente cambia, e una detection che non viene mantenuta invecchia in fretta, diventando silenziosamente cieca o silenziosamente rumorosa. Ogni incidente gestito, in questo approccio, diventa un’occasione per rendere il rilevamento più preciso il giorno dopo.

Il risultato è tangibile su tre fronti:

• alert più affidabili, perché aderenti al contesto reale dell’azienda;
• meno rumore e più focus, con un SOC libero di concentrarsi sui segnali che contano;
• tempi di risposta più rapidi, perché un attacco intercettato presto è un attacco contenuto presto.

È esattamente questo lo strato che separa un MDR che si limita a inoltrare gli allarmi del vendor da un MDR che fa davvero la differenza.

Tutto ciò che abbiamo descritto vale per qualsiasi EDR e qualsiasi organizzazione. Resta la domanda pratica: dove avviene, concretamente, questa personalizzazione?

In Certego è il ruolo di Halo, la piattaforma di Detection Engineering. Halo rende la telemetria grezza degli endpoint direttamente accessibile e analizzabile, superando i limiti delle logiche black-box di terze parti. Su quei dati, i team di Detection Engineering e Security Operations di Certego possono:

• accedere alla telemetria completa degli endpoint, per analisi che vanno ben oltre i rilevamenti standard;
• scrivere e affinare regole di detection personalizzate, calibrate sul contesto specifico del cliente;
• correlare eventi multipli e aggregarli in un unico alert rilevante, abbattendo il rumore;
• applicare IOC e regole specifiche per il contesto e il mercato italiano, alimentati dalla ricerca proprietaria di Cyber Threat Intelligence.

Halo è nativamente integrata con PanOptikon®, la piattaforma di Unified Security Operations su cui converge l’intero ciclo di vita dell’incidente, e con il team SecOps che valida ogni allarme prima di portarlo all’attenzione del cliente. Il risultato di questa filiera, in un caso enterprise reale su dodici mesi di osservazione, è la traduzione operativa di tutto il discorso: da miliardi di eventi grezzi a poche centinaia di incidenti realmente gestiti, con una riduzione dei falsi positivi superiore al 94%.

Non è l’EDR che cambia. È ciò che gli costruisci intorno.