Nel mondo della cybersecurity aziendale si parla sempre più spesso di automazione, eppure è la figura dell’Ethical Hacker a fare la differenza quando si tratta di capire se una vulnerabilità rilevata da un tool rappresenta davvero un rischio concreto. Scanner di vulnerabilità, piattaforme di exposure management, tool di penetration testing automatizzato, dashboard di rischio, controlli continui, report generati in tempo reale. Tutti strumenti utili, spesso indispensabili, soprattutto quando l’obiettivo è ottenere una prima fotografia tecnica dell’esposizione di un’infrastruttura.

Il problema nasce quando questi strumenti vengono scambiati per un vero test di intrusione.

Un vulnerability assessment automatizzato può individuare software obsoleti, porte esposte, configurazioni deboli, certificati scaduti, CVE note e servizi pubblicati in modo non corretto. Ma un attaccante reale non si limita a leggere l’output di uno scanner. Osserva, interpreta, combina informazioni, sfrutta ambiguità operative, abusa di processi aziendali e cerca percorsi non lineari.

Ethical Hacker: il fattore umano che fa la differenza

È qui che entra in gioco l’Ethical Hacker: non come semplice operatore di tool, ma come figura capace di ragionare come un attaccante, mantenendo metodo, autorizzazione, tracciabilità e obiettivi difensivi. La differenza tra “trovare vulnerabilità” e “dimostrare un rischio reale” è spesso tutta qui.

Il limite strutturale degli strumenti automatici

Gli strumenti automatici lavorano molto bene quando il problema è noto, classificabile e tecnicamente rilevabile. Se un server espone una versione vulnerabile di un servizio, se una web application presenta un header mancante, se una libreria JavaScript è obsoleta o se un protocollo debole è ancora abilitato, lo scanner può segnalarlo con buona precisione.

Ma molte vulnerabilità critiche non si presentano in modo così evidente.

Un tool può rilevare una SQL injection banale. Molto più difficilmente comprenderà che un processo di approvazione interna può essere aggirato modificando una sequenza di richieste. Può identificare un form di login, ma non sempre capirà che il reset password consente di prendere controllo di account privilegiati in condizioni specifiche. Può testare parametri, cookie e sessioni, ma fatica a valutare il contesto reale in cui quei meccanismi vengono usati.

La logica di business non è una CVE. È fatta di flussi, ruoli, autorizzazioni implicite, eccezioni operative, scorciatoie introdotte nel tempo, integrazioni con sistemi esterni e comportamenti umani. Per questo non può essere valutata solo con un motore automatico.

Quando la creatività umana trova ciò che lo scanner non vede

Un esempio tipico riguarda le catene di autenticazione. In un’applicazione aziendale, lo scanner può confermare che il login utilizza HTTPS, che i cookie hanno flag corretti, che non ci sono vulnerabilità note nei componenti e che le password rispettano criteri minimi. Report apparentemente pulito.

Un Ethical Hacker, invece, può analizzare il flusso completo: registrazione, login, cambio password, recupero credenziali, MFA, gestione sessione, cambio email, ruoli applicativi, inviti utente, API richiamate dal frontend. In questa analisi può emergere che un utente standard riesce a modificare un identificativo nel traffico API e ad accedere a funzioni riservate ad amministratori. Oppure che il secondo fattore viene richiesto solo nel frontend, ma non realmente validato lato server per alcune chiamate.

Lo scanner non ha “capito” il modello autorizzativo. L’Ethical Hacker sì.

Un altro caso frequente riguarda le piattaforme B2B con workflow approvativi: ordini, scontistiche, autorizzazioni, ticket, documenti, dati cliente. Tecnicamente l’applicazione può risultare solida. Nessuna vulnerabilità evidente. Nessuna iniezione. Nessun componente critico.

Poi un test manuale dimostra che un utente può modificare il prezzo finale di una richiesta, riaprire una pratica già approvata, accedere a documenti di un’altra azienda cambiando un ID o approvare un’operazione con un ruolo non previsto. In quel momento la vulnerabilità non è più “tecnica” in senso stretto. È una falla di processo con impatto economico, legale e reputazionale.

Il falso senso di sicurezza dei report automatici

Uno dei rischi maggiori dell’automazione è il falso senso di sicurezza. Un report con molte spunte verdi può essere rassicurante, ma non necessariamente rappresenta il livello reale di esposizione. Al contrario, può indurre l’azienda a credere che l’ambiente sia stato testato in profondità quando in realtà sono stati verificati solo controlli standardizzati.

Questo accade spesso anche nelle infrastrutture Microsoft 365, Active Directory, VPN, firewall, servizi cloud e applicazioni esposte. Un tool può segnalare configurazioni deboli, ma non sempre ricostruisce il percorso di attacco completo.

Un attaccante non ragiona per singola vulnerabilità. Ragiona per catena.

Un account con privilegi limitati, una mailbox poco protetta, una regola di forwarding, un’app registration sovra-autorizzata, un gruppo dimenticato, una condivisione SharePoint troppo ampia e una policy MFA applicata male possono sembrare problemi separati. Messi insieme, possono diventare un percorso realistico verso l’esfiltrazione di dati o l’escalation dei privilegi.

L’Ethical Hacker serve proprio a questo: collegare i punti.

Automated testing e penetration test non sono la stessa cosa

Il punto non è demonizzare i tool automatici. Sarebbe un errore. Sono strumenti fondamentali per scalare i controlli, ridurre il rumore, monitorare l’esposizione, identificare vulnerabilità note e mantenere una baseline di sicurezza.

Il problema è considerarli equivalenti a un penetration test professionale.

Un test automatizzato risponde alla domanda: “ci sono vulnerabilità note o configurazioni deboli rilevabili in modo standardizzato?” Un penetration test risponde a una domanda più profonda: “un attaccante motivato, con tempo e competenze, riuscirebbe a compromettere dati, identità, processi o sistemi critici?”

Sono due domande diverse. La prima è utile. La seconda è strategica.

Il valore dell’Ethical Hacker nelle aziende moderne

L’Ethical Hacker porta nel processo una capacità che nessun motore automatico possiede pienamente: il giudizio contestuale.

Sa distinguere tra una vulnerabilità formalmente critica ma difficilmente sfruttabile e una debolezza apparentemente minore che, nel contesto specifico dell’azienda, può aprire una breccia significativa. Sa adattare il test quando un percorso si chiude. Sa interpretare comportamenti anomali. Sa valutare l’impatto reale, non solo il punteggio CVSS.

Soprattutto, sa comunicare il rischio. Un elenco di vulnerabilità non basta al management. Serve spiegare cosa può succedere, quali dati sono coinvolti, quali processi possono essere compromessi, quali sistemi sono esposti e quali remediation hanno priorità. Un buon penetration test non produce solo un report tecnico: produce consapevolezza operativa.

NIS2, governance e responsabilità: perché il tema è attuale

Con l’evoluzione normativa e l’attenzione crescente alla resilienza cyber, le aziende non possono più limitarsi a dimostrare di avere strumenti installati. Devono dimostrare di avere processi efficaci, controlli coerenti e capacità di identificare vulnerabilità prima che vengano sfruttate.

In questo scenario, affidarsi solo a strumenti automatici è una scelta debole. L’automazione aiuta a mantenere continuità. Il test manuale aiuta a verificare profondità, logica e impatto reale.

La Direttiva NIS2 spinge proprio in questa direzione: gestione del rischio, misure tecniche e organizzative, responsabilità del management, continuità operativa, supply chain, incident handling e verifica della postura di sicurezza. Per questo una checklist strutturata può aiutare le aziende a capire dove si trovano e quali aree devono rafforzare.

Formare competenze, non solo acquistare strumenti

La sicurezza non si compra solo aggiungendo piattaforme. Si costruisce anche formando persone capaci di interpretare scenari complessi.

Un team tecnico che conosce le metodologie di ethical hacking è più efficace anche quando usa strumenti automatici, perché sa leggerne i risultati in modo critico. Sa validare i falsi positivi, riconoscere i falsi negativi, approfondire gli indizi e trasformare un controllo superficiale in un’analisi utile.

Questo è particolarmente importante per chi si occupa di infrastrutture, identità digitali, cloud, Microsoft 365, Active Directory, applicazioni web e ambienti ibridi. In questi contesti, molte compromissioni non derivano da una singola vulnerabilità spettacolare, ma dalla combinazione di configurazioni permissive, credenziali esposte, ruoli eccessivi, MFA incompleto e processi non governati.

Conclusione

I test automatizzati sono necessari, ma non sufficienti.

Rappresentano una componente importante di un programma di sicurezza moderno, ma non possono sostituire l’analisi manuale, il pensiero laterale e la capacità di contestualizzare il rischio. La sicurezza reale non nasce da un report generato automaticamente, ma dalla capacità di capire se una debolezza tecnica può diventare un incidente concreto.

L’Ethical Hacker resta quindi una figura centrale. Non perché lavora senza strumenti, ma perché sa usarli senza esserne prigioniero. Non perché trova solo vulnerabilità, ma perché dimostra percorsi di attacco. Non perché produce un elenco di problemi, ma perché aiuta l’azienda a capire dove è realmente esposta e come ridurre il rischio in modo prioritario.

In cybersecurity, la differenza tra teoria e trincea è questa: il tool esegue controlli, l’Ethical Hacker costruisce scenari. E sono gli scenari, non le semplici vulnerabilità isolate, a determinare il rischio reale per l’azienda.