In un’ampia intervista condotta nel podcast specializzato CISO Series Podcast, autorevoli esponenti della sicurezza informatica si sono confrontati sulle profonde trasformazioni che l’integrazione dell’intelligenza artificiale sta portando nella gestione operativa aziendale.
Il dibattito, guidato dal produttore David Spark insieme all’ex CISO Steve Zalewski e a Varsha Agrawal, responsabile della sicurezza delle informazioni presso Prosper Marketplace, ha affrontato i temi cruciali del settore, dall’evoluzione dei flussi di lavoro tecnici fino alle dinamiche di governance con i consigli di amministrazione e al rapporto con i fornitori esterni.
Indice degli argomenti
L’illusione del tempo e la trasformazione del backlog di sicurezza
L’adozione delle nuove tecnologie all’interno dei reparti di sicurezza informatica ha aperto un dibattito fondamentale sul reale valore dell’automazione.
Spesso le aspettative legate agli incontri e ai summit dedicati all’intelligenza artificiale si scontrano con la realtà: i partecipanti cercano risposte concrete ma finiscono per imbattersi in generiche affermazioni sulla necessità che qualcun altro risolva le criticità strutturali.
La fine delle scuse operative di fronte alle capacità dell’intelligenza artificiale
Nell’analisi delle dinamiche lavorative, viene richiamata la posizione di Joshua Copeland di Crescendo, il quale sostiene: «La domanda non è quante persone possiamo tagliare, ma di cosa dovrebbe essere capace questo team ora che il tempo non è più un limite».
Per circa vent’anni, la presunta mancanza di tempo è servita da copertura per la mancata esecuzione delle attività all’interno dei team di sicurezza.
Come evidenziato da Agrawal, l’affermazione che non vi fosse tempo sufficiente evitava la necessità di prendere decisioni definitive sull’utilità o meno di determinati compiti. L’avvento dell’intelligenza artificiale elimina questa giustificazione, dato che la tecnologia consente di svolgere i compiti a una velocità prima impensabile.
Di conseguenza, l’accumulo di lavoro arretrato non può più essere considerato una conseguenza inevitabile dei limiti temporali. Ogni singolo elemento presente nel backlog impone oggi una scelta reale e consapevole sulla sua effettiva priorità e sul suo valore per l’organizzazione.
Dal ticket al codice: come cambia la gestione della vulnerabilità
Il modello tradizionale di gestione della sicurezza ha sempre previsto l’individuazione dei problemi, la creazione di un ticket da assegnare al backlog degli sviluppatori e l’attesa che questi ultimi decidessero quando applicare la correzione. Con le capacità attuali dell’intelligenza artificiale, questo flusso di lavoro è destinato a mutare radicalmente.
Agrawal definisce chiaramente il nuovo approccio richiesto ai professionisti della sicurezza: non si devono più generare semplicemente ticket da inserire nel backlog altrui, ma occorre fornire direttamente la correzione sotto forma di una pull request pronta per l’unione nel codice principale.
Questo passaggio riduce le sovrapposizioni e trasferisce la responsabilità dell’azione direttamente a chi individua la criticità, trasformando il ruolo dell’analista da segnalatore passivo a contributore attivo.
Oltre il backlog: ridefinire le competenze e l’efficienza dei team
L’eliminazione dei vincoli temporali grazie all’automazione non implica automaticamente l’espansione infinita delle liste di cose da fare.
Se da un lato è facile ipotizzare l’aggiunta di attività come il threat hunting o il red teaming nelle pianificazioni, dall’altro la vera sfida risiede nell’acquisizione di nuove capacità strategiche.
La gestione dello “slop” e il valore del dire no
Tra le competenze fondamentali per gestire un backlog moderno, la prima consiste nella capacità di rifiutare il lavoro superfluo. L’intelligenza artificiale è in grado di generare enormi quantità di contenuto e codice spazzatura, definito “slop”, in pochissimo tempo. Senza un controllo rigoroso, il rischio è di sovraccaricare le strutture di verifiche inutili.
La seconda competenza cruciale consiste nel prendersi la responsabilità della decisione finale. Gli strumenti automatizzati possono proporre soluzioni e costruire architetture, ma l’essere umano rimane il punto focale a cui spetta l’approvazione delle scelte strategiche.
In quest’ottica, il team di sicurezza non deve limitarsi a gestire il volume del backlog, ma deve agire da garante della qualità e della pertinenza di ciascun intervento.
Bilanciare efficienza ed efficacia con il modello human-in-the-loop
Zalewski evidenzia una distinzione fondamentale tra i concetti di efficienza ed efficacia nell’ambito dei processi operativi. L’efficienza riguarda l’eliminazione di compiti noiosi e ripetitivi, che nell’attuale generazione di strumenti automatizzati può arrivare a coprire dal 40% al 60% delle attività quotidiane svolte da un responsabile della sicurezza.
Tuttavia, l’efficacia risiede nella creatività e nelle intuizioni umane applicate alla risoluzione dei problemi. Mantenere un modello che veda l’essere umano integrato nel ciclo operativo (“human-in-the-loop”) permette di liberare risorse mentali dai processi complessi ma ripetitivi.
Negli ambienti di Security Operations Center (SOC), l’intelligenza artificiale viene già utilizzata per effettuare il triage primario degli avvisi di livello 1. La transizione in corso mira a comprendere in quali contesti la tecnologia possa operare in autonomia e quando sia invece indispensabile l’intervento umano per guidare la decisione strategica.
Dipendenza dai fornitori e intelligenza artificiale: una scelta di fiducia o di sicurezza?
La gestione dei processi tecnologici implica una riflessione profonda sui rapporti con i fornitori esterni e sul rischio di rimanere vincolati alle loro soluzioni.
Citando Gary Pearson di Verbix, la questione centrale viene sintetizzata con chiarezza: «Il pericolo non è mai stato la tecnologia in sé; è quanta parte del business cedi al fornitore i cui incentivi non coincidono con i tuoi.».
Le criticità del vendor lock-in nell’era dei modelli generativi
Il fenomeno del vendor lock-in non riguarda solamente gli aspetti contrattuali o la proprietà dei dati, ma coinvolge il flusso di lavoro, il modello informativo e l’esperienza utente modellati sulla tabella di marcia del fornitore.
Nelle aziende di software tradizionale è possibile stimare i costi di transizione analizzando prodotti e listini stabili. Al contrario, nel settore dell’intelligenza artificiale le condizioni mutano costantemente: i modelli vengono aggiornati di frequente, la fatturazione passa da licenze per utente al consumo di token e la permanenza sul mercato degli stessi fornitori non è garantita nel lungo periodo.
Agrawal sottolinea come sia impossibile accettare preventivamente termini contrattuali futuri non ancora definiti. L’obiettivo delle organizzazioni deve essere la capacità costante di riconsiderare le proprie scelte nel tempo.
L’impatto dei flussi di lavoro sulle competenze del personale
Un elemento spesso trascurato nelle valutazioni dei rischi di terze parti riguarda l’assuefazione delle persone agli strumenti utilizzati. Il vero vincolo operativo risiede nelle abitudini consolidate dal personale e nella formazione ricevuta per utilizzare un determinato strumento. Cambiare fornitore comporta un costo elevato in termini di riqualificazione delle risorse umane e di riorganizzazione dei processi interni.
Sul piano della valutazione tecnologica, Zalewski osserva che i concetti di intelligenza artificiale e fiducia sono incompatibili tra loro. Non è possibile riporre fiducia cieca nei sistemi automatizzati, ma occorre sviluppare sicurezza (confidence) nell’addestramento e nella conoscenza dei loro limiti operativi. La tecnologia si limita a produrre risposte convincenti; di conseguenza, la supervisione deve stabilire con precisione il raggio d’azione concesso all’algoritmo.
La governance del consiglio di amministrazione e la vendita di soluzioni cyber
Il dialogo tra i responsabili della sicurezza e i consigli di amministrazione soffre frequentemente di incomprensioni strutturali.
David Nolan, CISO di Tremont, ha espresso chiaramente questo divario affermando: «Chiunque dica di sì, o si sbaglia o sta cercando di venderti qualcosa.», in risposta alla domanda se fosse possibile garantire con certezza l’assenza di violazioni informatiche.
Il superamento delle dashboard a semaforo
L’utilizzo esteso di report grafici basati sui colori rosso, giallo e verde ha generato una falsa sensazione di controllo nei consigli di amministrazione. Agrawal spiega che questo modello, originariamente mutuato da altre funzioni aziendali come la finanza e la gestione progetti per semplificare le presentazioni, si è rivelato un limite: i semafori verdi tendono a chiudere le conversazioni e ad azzerare le domande di approfondimento.
I dirigenti sono stati abituati a un ruolo passivo. La soluzione non risiede nell’insegnare la gestione operativa al consiglio, ma nel fornire una conoscenza linguistica sufficiente per valutare i rischi reali.
Il compito del CISO è presentare i rischi in termini di impatto aziendale ed economico, ponendo il consiglio di fronte a scelte chiare: finanziare le misure di mitigazione oppure firmare la formale accettazione del rischio residuo.
In merito agli scenari di crisi in cui si debba scegliere tra il rilascio rapido di un sistema privo di adeguate protezioni o il blocco delle attività aziendali per mancata conformità, la priorità rimane la trasparenza sulle responsabilità.
Zalewski rileva che fare ostruzionismo rigido può esporre la sicurezza all’accusa di bloccare l’innovazione, mentre la corretta formalizzazione dei rischi consente di far comprendere al business le reali conseguenze delle proprie decisioni commerciali.
Ciò che i CISO chiedono realmente ai fornitori del settore
Nel rapporto con i fornitori di soluzioni di sicurezza, emerge una forte insoddisfazione verso chi si limita a segnalare ulteriori problemi senza offrire strumenti risolutivi. Con organizzazioni che gestiscono già decine di strumenti differenti all’interno del proprio stack, i responsabili della sicurezza cercano partner capaci di farsi carico di un problema e di risolverlo in modo concreto.
Agrawal evidenzia che le proposte commerciali presentate a metà del ciclo contrattuale o di budgeting incontrano forti ostacoli operativi. Presso Prosper Marketplace, la pianificazione del budget avviene nel quarto trimestre, rendendo quello il momento idoneo per valutare nuove soluzioni al momento del rinnovo dei contratti esistenti.
Inoltre, i fornitori devono comprendere l’uso effettivo che gli ingegneri fanno degli strumenti sul campo. Zalewski osserva che spesso gli utenti adattano i prodotti a esigenze pratiche diverse da quelle previste in fase di progettazione: i produttori non dovrebbero contestare l’utilizzo improprio da parte del cliente, ma modificare il prodotto per renderlo più efficace nello svolgimento di quella specifica funzione.
La capacità di governare la tecnologia e i processi di sicurezza rimane strettamente legata all’esperienza pratica sul campo, come richiamato in chiusura da Agrawal: «Il miglior consiglio per un CISO: mettete in produzione qualcosa che porti il vostro nome. Non potete governare chi costruisce se non siete mai stati costruttori voi stessi.».
Partecipa alla community