Capire come un sistema può essere attaccato aiuta a difenderlo, ma la cybersecurity non si riduce alla scelta di un programma. Con InMarvinWeTrust siamo finiti su sicurezza delle infrastrutture, dipendenze software e verifiche periodiche, partendo da una domanda della community.

Luca chiede se Marvin usi competenze di hacking nel proprio lavoro o si limiti a una difesa attiva. La risposta porta lontano: conoscere il funzionamento dei sistemi, i loro limiti, e il modo in cui possono essere messi alla prova.

Hacker, curiosità e responsabilità

Marvin insiste sulla distinzione fra hacker e criminale informatico. Per lui essere hacker significa essere curiosi di capire la tecnologia, anche cercando dove si rompe, e non trova necessario aggiungere ogni volta l'aggettivo «etico».

È una posizione sul linguaggio e sull'identità professionale. Nell'uso corrente l'espressione ethical hacking indica le verifiche autorizzate, e il punto pratico è tutto lì: conoscere una tecnica non ti dà il diritto di applicarla ai sistemi di qualcun altro.

Per chi difende un'infrastruttura, ragionare sugli obiettivi e sui percorsi di un attaccante serve a trovare le debolezze prima che diventino incidenti. Quella conoscenza deve diventare protezione, non una dimostrazione spettacolare.

Gli strumenti citati fanno lavori diversi

Compaiono Snort, Suricata, Nginx e CrowdSec. Marvin si presenta anche come ambassador di CrowdSec in Italia: è un'affiliazione dichiarata, e va tenuta distinta da una valutazione indipendente dei prodotti.

Non è una classifica e non è un confronto: sono nomi che mostrano quali componenti esistano per costruire difese, anche nel mondo aperto.

La scelta però non può nascere dall'accumulo. Un'infrastruttura ha bisogno di sapere che cosa viene osservato, chi legge gli avvisi e come si interviene. Aggiungere un prodotto senza chiarire queste tre cose aumenta la complessità più della capacità di risposta.

Antivirus e protezione degli endpoint: niente scorciatoie

Nel discorso usiamo toni molto netti contro l'idea che basti installare un antivirus. Il messaggio giusto è che una difesa affidata a un solo strumento non basta — non che ogni protezione antimalware sia inutile.

Quindi no: non sto dicendo di disattivare le difese esistenti né di scartare un prodotto perché è gratuito. La CISA include antivirus e firewall aggiornati fra le misure di protezione dei dati. Vanno inseriti in un insieme di controlli adeguato al sistema e ai rischi che corre.

Collego il tema anche allo studio che sto portando avanti su cybersecurity e intelligenza artificiale. Il punto che condivido con Marvin è culturale: imparare a ragionare sulla sicurezza conta più che imparare i nomi delle applicazioni.

Un microservizio esposto non finisce con la pubblicazione

Per rendere concreta la cosa torno al mio campo. Immagina un microservizio raggiungibile da Internet: progettato o configurato male, espone funzioni e dati che dovevano restare protetti.

Marvin aggiunge il pezzo importante: il difetto non deve essere intenzionale. Basta incorporare una libreria, usare codice altrui e trascurare gli aggiornamenti, oppure continuare a dipendere da un progetto che nessuno mantiene più.

Qui parlare genericamente di «backdoor» confonde. Una vulnerabilità involontaria, una configurazione sbagliata e un accesso nascosto di proposito sono tre cose diverse, anche se condividono la necessità di capire dove sta il problema e come limitarne l'impatto.

Debito tecnico e debito di sicurezza crescono mentre il servizio continua a funzionare benissimo. È per questo che la manutenzione non è un'attività da ricordarsi quando qualcosa si rompe.

Penetration test e vulnerability assessment si completano

Marvin critica l'uso del penetration test come fotografia da esibire una volta e poi archiviare. Preferisce valutazioni ripetute delle vulnerabilità e obiettivi di correzione nel tempo.

La distinzione è giusta, ma non diventi «i penetration test non servono». La guida NIST SP 800-115 tratta più tecniche di esame e valutazione, scansioni e penetration test compresi, con impieghi e limiti diversi.

Un test di penetrazione verifica come certe debolezze siano sfruttabili in uno scenario autorizzato. Una valutazione delle vulnerabilità aiuta a identificarle, ordinarle e seguirne la gestione. Entrambe hanno un perimetro, e nessuna dimostra che un sistema resterà sicuro.

Compaiono esempi di cicli trimestrali o semestrali. Sono esempi organizzativi, non una cadenza valida per tutti: una vulnerabilità critica su un servizio esposto non aspetta il controllo pianificato.

Il risultato utile non è il rapporto finale. È la sequenza: responsabilità, priorità, intervento, verifica che la correzione abbia funzionato.

Un elenco di vulnerabilità può essere un segno di trasparenza

Marvin propone un gioco: fra un produttore che dichiara i problemi noti e uno che promette di non averne, di chi ti fidi?

La trasparenza vale molto. Sapere quali versioni sono coinvolte, quali mitigazioni esistono e come arrivano gli aggiornamenti ti permette di decidere. Una promessa di perfezione non ti dà nessuna di queste informazioni.

Detto questo, non si sceglie il prodotto con più vulnerabilità pubblicate. Numero, gravità, esposizione e capacità di risposta si leggono insieme. E l'assenza di segnalazioni pubbliche non dimostra che qualcuno stia facendo dei test.

L'idea che mi porto via è che la sicurezza è un lavoro continuo. Capire i sistemi, formare le persone, aggiornare le dipendenze e verificare i miglioramenti conta più di qualunque strumento che prometta di rassicurarti una volta per tutte.