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.

Falsi positivi e falsi negativi: due facce dello stesso problema

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.

L’EDR è fondamentale. Ma è pensato per tutti, non per te

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: cucire l’EDR sulla tua azienda

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.

Halo: come Certego rende la detection su misura

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.