Foto da una sessione di analisi condotta con l’ausilio dell’AI Claude, utilizzata per il parsing e la fase di triage dell’output generato dal tool Nikto durante un vulnerability assessment su di una webapp target di un mio cliente (un software gestionale scritto in PHP).

Come da videata, l’enumerazione delle vulnerabilità mostra una superficie di attacco tutt’altro che trascurabile: misconfigurazioni multiple, header di sicurezza mancanti e potenziali vettori di exploitation a livello applicativo (per motivi di privacy ho oscurato l’IP pubblico associato al dominio corrispondente al sito web del cliente che mi ha commissionato l’assessment).

Ogni evidenza segnalata da Nikto — successivamente validata/contestualizzata tramite l’analisi assistita da Claude — ha trovato conferma in fase di verifica manuale, dandomi la possibilità di riscontrare la reale sfruttabilità delle issue individuate e non un semplice “rumore” di fondo da falsi positivi, come spesso accade con gli scanner automatici. Il tutto è confluito nel report di assessment finale, consegnato al referente del cliente, fino a quel momento non completamente consapevole dell’effettiva cyber(in)security posture della propria infrastruttura web.

Chi ha una solida preparazione in ambito Cybersecurity (reti, sistemi operativi, protocolli, scripting, ethical hacking, un minimo di reverse engineering) possiede alcune competenze tecniche chiave che gli permettono di integrare l’AI nelle proprie analisi:

• comprende il perché degli eventi e del loro accadimento, non solo “il cosa”. Sa spiegare perché un pattern di traffico è anomalo, non si limita a leggere un alert. Conosce il TCP/IP abbastanza da capire se uno strano beaconing è DNS tunneling o solo un client mal configurato.
• sa validare (o smontare) l’output dell’AI. Se un tool basato su LLM gli comunica “questo è un malware”, sa verificare gli hash, l’entropia del file, il comportamento in sandbox, e giudicare se la conclusione regge.
• riconosce i falsi positivi e i falsi negativi con criterio scientifico: non si fida ciecamente di un punteggio di rischio generato automaticamente, ma lo contestualizza.
• è in grado di analizzare la situazione anche quando il software in uso non copre il caso: in un incidente informatico reale, spesso i tool non hanno visto “quella” combinazione specifica prima, serve appunto comprendere i sistemi sottostanti per costruire un’ipotesi realistica.
• ha intuito per le anomalie sottili: un attacker avanzato come un APT lascia tracce minime e non standard, ma solo chi sa o è davvero in grado di capire come funzionano i sistemi nota quando “qualcosa non torna”.

Viceversa, chi usa l’AI in modalità “bovina”, senza farsi troppe domande:

• è in grado di osservare una dashboard, ma spesso di non comprendere realmente cosa c’è sotto. Segue playbook e tool di output senza sapere perché quel passaggio esista.
• Non riesce a distinguere un’allucinazione dell’AI da una corretta analisi – gli LLM possono generare spiegazioni plausibili ma sbagliate (per esempio possono attribuire un comportamento benigno a una tecnica MITRE ATT&CK a caso, solo perché “suona giusto”).
• È vulnerabile ad evasion mirate. Un attacker consapevole che un certo SOC usa l’AI generativa per il triage potrebbe forgiare attacchi informatici che sfruttano proprio i bias del modello (prompt injection nei log, testo ingannevole nei nomi dei processi, ecc..).
• Fatica nell’incident response reale: quando si lavora sotto pressione, dovendo analizzare tanti sistemi compromessi con tempistiche limitate possono venire a mancare le fondamenta per prendere decisioni razionali ma tempestive senza qualcuno che gliele suggerisca oltre all’AI (e se nel frattempo l’analista dovesse terminare i token a sua disposizione?).
• Diventa un collo di bottiglia, non un facilitatore: l’AI dovrebbe agevolare chi sa già cosa cercare, ma senza solide basi, un analista SOC semplicemente sposta la fiducia dall’esperienza umana al modello LLM, con un netto peggioramento in termini di affidabilità delle analisi stesse.

L’AI adottata nel campo della sicurezza informatica dovrebbe fungere da agevolatore di competenze, non da sostituto di formazione indispensabilmente pregressa. Un analista SOC che si rispetti dovrebbe usare l’AI con la dovuta consapevolezza per:
– ridurre il rumore (triage di migliaia di alert)
– accelerare la correlazione tra eventi
– generare ipotesi da verificare con celerità.

Senza solide basi tecnico-scientifiche, l’AI diventa solo una sorta di scatola magica a cui si delegano in maniera temeraria le analisi — ma delegare un giudizio critico è sempre pericoloso: gli attacker sono avversari attivi che si adattano, non un problema statico che un LLM può risolvere una volta per tutte.

In sintesi: la differenza non è tanto tra “chi usa l’AI e chi no”, ma tra chi sa quando fidarsi di un’AI e quando no — e questo si apprende solo con l’esperienza e con una doverosa formazione continua (passata, presente e futura).