L’evoluzione delle minacce informatiche e l’integrazione di sistemi automatizzati stanno mettendo in discussione la sostenibilità economica dei SOC e il valore attribuito alla figura del detection engineer.
Negli ultimi anni, la necessità di sviluppare logiche su misura per identificare attività malevole ha spinto i compensi dei professionisti senior oltre i 200.000 dollari all’anno.
L’ingresso degli agenti basati su intelligenza artificiale sta tuttavia modificando l’equilibrio dei costi e dell’operatività. In un’analisi approfondita emersa dal podcast Defense in Depth, condotto dal produttore David Spark con il CISO di Dolby Yaron Levi e l’ospite Adrian Ludwig, CSO di Rippling, esperti del settore si sono interrogati sul destino del detection engineer e sulla riorganizzazione dei team di sicurezza informatica.
Indice degli argomenti
La crisi del modello tradizionale e l’accumulo di rumore nei log
Il dibattito sull’efficienza economica dei reparti di rilevamento parte dalle osservazioni di Caleb Sima di Whiterabbit, secondo cui il modello finanziario attuale è compromesso. Sima osserva che «Un senior detection engineer progetta, sviluppa e perfeziona la logica utilizzata per identificare le attività malevole all’interno di una rete. Il loro stipendio supera spesso i 200.000 dollari. Oggi, tuttavia, l’AI è in grado di svolgere la maggior parte del loro lavoro». Questo scenario fa prevedere una contrazione della dimensione delle squadre di lavoro e del panorama dei vendor specializzati.
A valutare criticamente il lavoro svolto negli ultimi due decenni è lo stesso Levi, che esprime un giudizio netto sulle architetture difensive tradizionali: «ritengo che il modo in cui abbiamo gestito la detection nel nostro settore negli ultimi vent’anni sia stato un fallimento. Speriamo che con l’AI, se non altro, falliremo meno». Secondo Levi, le cause di questo insuccesso sono strutturali e riguardano sia la preparazione del personale sia la gestione delle fonti dati: «Il primo è che la maggior parte dei difensori non ha la minima idea di come lavorino gli attaccanti. Nessuna. Non sanno come operano. […] Il secondo problema è che cerchiamo di migliorare la detection intasando il sistema con più rumore di fondo, continuando a inviare sempre più dati».
La conseguenza diretta di questo approccio è un uso inefficiente delle risorse umane. Riferendosi al sovraccarico di lavoro che affligge gli analisti, Manny di Spectrum Security dichiara: «L’attuale modello è del tutto insostenibile. Oggi costringiamo le nostre persone più brillanti a spendere il 70% del loro tempo nella ‘zona grigia’ (the messy middle), cercando di conciliare i comportamenti delle minacce con la realtà dei log e le vecchie logiche SIEM».
Dalla gestione della sintassi alla direzione degli agenti
L’automazione dei compiti ripetitivi impone una revisione delle mansioni quotidiane del detection engineer. Manny prospetta una ristrutturazione del ruolo, affermando che il team del futuro «Non sarà un team ridotto all’osso composto da due sole persone. Sarà un team completo di professionisti della sicurezza che sono passati dal ruolo di meccanici a quello di conduttori. Dirigeranno una flotta di agenti per gestire la zona grigia della sintassi e del tuning, liberando la larghezza di banda necessaria per affrontare la frontiera degli avversari».
Per Ludwig, il lavoro del detection engineer deve spostarsi verso la risoluzione strutturale dei problemi: «quando si verifica un incidente, dobbiamo risolverlo, chiuderlo correttamente, comunicare con il cliente e così via, e poi avviare una discussione approfondita e significativa su cosa abbia causato quell’incidente e se sia necessario apportare modifiche strutturali, architettoniche o procedurali per evitare che si ripeta». Ludwig evidenzia come un agente intelligente possa eseguire il backlog grooming e calcolare i costi operativi causati dagli incidenti non gestiti.
Il confine tra compiti automatizzabili e attività ad alto valore aggiunto viene tracciato anche da Adam Goss di Gravwell Security. Citando l’esempio di Google, che ha automatizzato il 99% del triage su 15 anni di infrastruttura “detection as code”, Goss precisa: «Scrivere regole contro TTP (tattiche, tecniche e procedure) note è la parte automatizzabile. Generare nuove ipotesi su tecniche emergenti senza precedenti storici è ciò per cui i detection engineer vengono effettivamente pagati, e questo divario non si colma nemmeno con il miglioramento dell’automazione del triage».
Il vincolo sulle risorse come incentivo all’automazione
Sul fronte del personale, la scelta tra il taglio degli organici e l’investimento tecnologico genera pareri contrastanti. Mike McCabe di Cloud Security Partners mette in guardia contro i tagli affrettati: «Assisteremo a un’accelerazione degli attacchi basati su AI contro ogni centimetro della superficie di attacco. Il vostro team attuale non sarà sufficiente. Perché allora tagliare il personale per risparmiare denaro, invece di ottenere una percentuale maggiore di copertura e migliorare i tempi di risposta agli alert?».
Ludwig ritiene invece che la vera spinta verso l’efficienza derivi dall’imposizione di limiti rigidi: «Sono fermamente convinto che la vera fonte di innovazione sia quasi sempre un vincolo, una limitazione». Spiegando la strategia adottata all’interno della propria organizzazione, Ludwig chiarisce: «L’approccio che stiamo adottando nella mia organizzazione, ad esempio, è quello di stabilire artificialmente che non assumeremo nessuno per un certo periodo. Usiamolo come esperimento mentale. Di fronte a questa restrizione, come possiamo automatizzare ogni singola attività ripetitiva? Come possiamo diventare più efficienti del 5% tra tre settimane e del 10% tra pochi mesi?». Secondo il CSO di Rippling, la tendenza diffusa ad assumere più personale o acquistare nuovi strumenti ha spesso ostacolato l’ottimizzazione dei processi esistenti.
Levi compara l’attuale transizione verso l’intelligenza artificiale all’avvento del Cloud avvenuto tra il 2009 e il 2010, quando si temeva la scomparsa degli ingegneri di rete e del personale IT. Levi ricorda come quell’infrastruttura abbia invece moltiplicato le opportunità lavorative e accresciuto la domanda di competenze specialistiche.
Rilevazione delle anomalie e limiti dei modelli linguistici
L’impiego dei modelli linguistici di grandi dimensioni (LLM) presenta limiti specifici quando applicato all’analisi dei comportamenti di rete. Chris Tillet di Palo Alto Networks rileva: «Questa logica si applica agli attacchi noti. Tuttavia, i Large Language Models non gestiscono bene l’anomaly detection. Non tutte le anomalie sono malevole, ma la maggior parte degli eventi malevoli è anomala».
Levi nota come l’identificazione delle anomalie sia resa complessa dalla mancanza di parametri di riferimento aziendali, poiché «nessuno ha un inventario completo di ciò che è considerato ‘normale’ all’interno della propria organizzazione». Per illustrare la necessità del fattore umano e dell’immaginazione nelle attività difensive, Levi richiama il capitolo 8 del rapporto ufficiale sulla strage dell’11 settembre, intitolato Il sistema lampeggiava rosso: «La conclusione della commissione fu che si trattò di un ‘fallimento dell’immaginazione’ (failure of imagination). Non sono riusciti a immaginare cosa sarebbe potuto accadere. Questo vale per quasi tutti gli attacchi a sorpresa della storia. Abbiamo bisogno di persone che sappiano usare l’immaginazione per consentirci di prepararci e gestire al meglio le minacce».
Dal punto di vista storico e statistico, Jordan Patapoff di Rivian evidenzia come l’automazione non abbia mai eliminato drasticamente le professioni intellettuali in tempi brevi: «Storicamente, l’automazione non ha mai eliminato l’80% di una categoria di professionisti della conoscenza qualificati nel giro di 5 anni. […] Nella cybersecurity, in particolare, il personale è cresciuto di pari passo con l’adozione di nuovi strumenti: SIEM, SOAR, EDR hanno aumentato, anziché eliminare, il numero di analisti». A conferma di ciò, Spark richiama uno studio del Ponemon Institute, dal quale emerge che l’implementazione dell’automazione richiede un incremento iniziale dell’organico per la fase di configurazione e gestione.
La riorganizzazione delle competenze nel team di sicurezza
La trasformazione operativa richiede nuove capacità relazionali all’interno dei reparti tecnici. Anatoly di AC Consulting descrive la struttura ideale per un team ad alte prestazioni: «Direi che il mio team ideale sarà composto da due ingegneri più un esperto di comunicazione e influenza. È necessario essere in grado di guidare i cambiamenti e ottenere risultati concreti, ed è proprio qui che molti ingegneri falliscono: nell’influenzare l’azienda per cambiare le cose».
Ludwig concorda con il modello basato su piccoli nuclei operativi, richiamando l’approccio “two in a box” utilizzato in Atlassian, e paragona la gestione degli agenti AI alla prima esperienza dirigenziale di un tecnico: «ascoltavo i singoli ingegneri operativi, persone che non hanno mai gestito un team umano in vita loro, e ho pensato che stanno attraversando la stessa identica transizione che vive un professionista quando diventa un manager per la prima volta: ‘Cosa voglio che facciano queste persone o questi agenti? Quali informazioni devono fornirmi per rendermi più intelligente di quanto non sia già singolarmente?’».
Controllo delle decisioni automatizzate e bilanciamento tra efficienza e mantenimento delle capacità
Questo cambio di paradigma incide anche sulle modalità di visualizzazione dei dati. Spark evidenzia il tramonto del vecchio modello basato su un’unica interfaccia visiva (il cosiddetto “single pane of glass”), spiegando che la sintetizzazione delle informazioni è ora affidata ai modelli linguistici che analizzano il contesto e mostrano le priorità operative in modo dinamico.
Infine, Levi invita a mantenere il controllo critico sulle decisioni automatizzate: «non possiamo esternalizzare completamente i nostri pensieri e il nostro pensiero critico alla macchina». Levi avverte sui rischi del calo di attenzione legato all’uso continuativo degli strumenti sintetici: «gli esseri umani sono pigri. Se ti abitui a generare codice o contenuti in questo modo e continui a farlo ripetutamente, alla fine rischi di perdere la tua competenza». L’evoluzione del detection engineer passa quindi attraverso un costante bilanciamento tra l’efficienza degli agenti e il mantenimento delle capacità di analisi autonoma.
Partecipa alla community