Capire come un sistema può essere attaccato aiuta a difenderlo, ma la cybersecurity non si riduce alla scelta di un programma. Nel dialogo con InMarvinWeTrust affrontiamo sicurezza delle infrastrutture, dipendenze software e verifiche periodiche partendo da una domanda della community sul lavoro del sistemista.

Luca chiede se Marvin utilizzi competenze di hacking nella propria attività o si limiti a una forma di difesa attiva. La risposta porta il confronto verso un tema più ampio: 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 tra hacker e criminale informatico. Nella sua interpretazione, essere hacker significa essere curiosi di capire la tecnologia, anche cercando dove possa rompersi. Non considera utile aggiungere sempre l’aggettivo “etico” per separare quella curiosità dalla criminalità.

È una posizione sul linguaggio e sull’identità professionale. Nell’uso comune si incontra comunque l’espressione ethical hacking per indicare attività di verifica autorizzate. Il punto pratico è l’autorizzazione: conoscere una tecnica non dà automaticamente il diritto di applicarla ai sistemi di qualcun altro.

Per chi difende un’infrastruttura, ragionare sugli obiettivi e sui percorsi possibili di un attaccante può aiutare a individuare debolezze prima che diventino incidenti. Questa conoscenza deve tradursi in scelte di protezione, non soltanto in dimostrazioni spettacolari.

Gli strumenti citati hanno compiti differenti

Nel confronto compaiono Snort, Suricata, Nginx e CrowdSec. Marvin si presenta anche come ambassador di CrowdSec in Italia: è un’affiliazione dichiarata nella conversazione, da tenere distinta da una valutazione indipendente dei prodotti.

Non trattiamo questi nomi come una classifica e non eseguiamo una prova comparativa. Il loro richiamo serve a mostrare che esistono componenti con cui costruire soluzioni di difesa, anche nel mondo aperto.

La scelta non può però partire dall’accumulo. Un’infrastruttura ha bisogno di sapere che cosa viene osservato, chi interpreta gli avvisi e come si interviene. Aggiungere un prodotto senza chiarire queste responsabilità può aumentare la complessità più della capacità di risposta.

Antivirus e protezione degli endpoint: evitare scorciatoie

Nel parlato usiamo espressioni molto nette contro l’idea che basti installare un antivirus. Il messaggio utile riguarda l’insufficienza di una difesa affidata a un solo strumento, non l’inutilità di ogni protezione antimalware.

Non ricavo quindi dal dialogo l’indicazione di disattivare le difese esistenti o di scartare automaticamente un prodotto perché gratuito. La CISA include antivirus e firewall aggiornati tra le misure di protezione dei dati. Questi strumenti devono essere inseriti in un insieme di controlli adeguato al sistema e ai rischi.

Nella conversazione io stesso collego il tema allo studio che sto portando avanti in cybersecurity e intelligenza artificiale. Il punto che condivido con Marvin è soprattutto culturale: bisogna imparare a ragionare sulla sicurezza, oltre a conoscere i nomi delle applicazioni.

Un microservizio esposto non finisce con la pubblicazione

Per rendere concreto il problema torno al mio campo, lo sviluppo software. Immagino un microservizio raggiungibile da Internet: se viene progettato o configurato male, può esporre funzioni e dati che avremmo dovuto proteggere.

Marvin aggiunge un aspetto importante: il difetto non deve essere intenzionale. Possiamo incorporare una libreria, utilizzare codice altrui e poi trascurare gli aggiornamenti, oppure continuare a dipendere da un progetto che non viene più mantenuto.

Qui parlare genericamente di “backdoor” rischia di confondere situazioni diverse. Una vulnerabilità involontaria, una configurazione errata e un accesso nascosto deliberatamente introdotto non sono la stessa cosa. Hanno però in comune la necessità di capire dove si trovi il problema e come ridurne l’impatto.

Il debito tecnico e quello di sicurezza possono crescere mentre il servizio continua apparentemente a funzionare. Per questo la manutenzione non è un’attività da ricordare soltanto quando qualcosa si rompe.

Penetration test e vulnerability assessment si completano

Un passaggio centrale riguarda le verifiche. Marvin critica l’uso del penetration test come una fotografia da esibire una volta e poi dimenticare. Preferisce sottolineare il valore di valutazioni ripetute delle vulnerabilità e di obiettivi di correzione nel tempo.

La distinzione va mantenuta senza trasformarla in “i penetration test non servono”. La guida NIST SP 800-115 tratta più tecniche di esame e valutazione della sicurezza, compresi scansioni e penetration test, con impieghi e limiti differenti.

Un test di penetrazione può verificare come determinate debolezze siano sfruttabili in uno scenario autorizzato. Una valutazione delle vulnerabilità può contribuire a identificarle, ordinarle e seguirne la gestione. Entrambe hanno un perimetro; nessuna dimostra che un sistema resterà sicuro per sempre.

Nel dialogo compaiono esempi di cicli trimestrali o semestrali. Sono esempi organizzativi, non una frequenza adeguata a qualunque azienda. Una vulnerabilità critica su un servizio esposto può richiedere attenzione molto prima del controllo pianificato.

Il risultato utile non è soltanto il rapporto finale: è una sequenza di responsabilità, priorità, interventi e verifiche delle correzioni effettuate.

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

Marvin propone un gioco: tra un produttore che dichiara problemi noti e uno che promette di non averne, quale ispira più fiducia?

La discussione mette in evidenza il valore della trasparenza. Sapere quali versioni siano coinvolte, quali mitigazioni esistano e come arrivino gli aggiornamenti permette di prendere decisioni concrete. La semplice promessa di perfezione non offre queste informazioni.

Non significa, però, scegliere automaticamente il prodotto con più vulnerabilità pubblicate. Numero, gravità, esposizione e capacità di risposta vanno letti insieme. Né l’assenza di segnalazioni pubbliche dimostra da sola che il produttore non faccia test.

L’idea che porto via dalla conversazione è considerare la sicurezza un lavoro continuativo. Capire i sistemi, formare le persone, aggiornare le dipendenze e verificare i miglioramenti conta più della ricerca di uno strumento capace di rassicurarci una volta per tutte.