La sicurezza informatica in azienda comincia dalla conoscenza dei propri sistemi, dagli aggiornamenti e dalla possibilità di recuperare i dati. Nella conversazione con InMarvinWeTrust affrontiamo questi aspetti partendo da casi concreti: vulnerabilità nelle dipendenze, backup mai verificati e piccole reti senza un responsabile informatico interno.

Il filo del confronto è semplice: installare uno strumento di sicurezza non sostituisce un metodo. Marvin porta l’esperienza di chi deve mantenere operativi i sistemi; io gli chiedo di tradurre i passaggi tecnici anche per chi non svolge questo mestiere.

Kali Linux non sostituisce le competenze

Una domanda della chat contrappone il lavoro reale del sistemista all’immaginario televisivo dell’hacker. Marvin conosce e utilizza Kali Linux, ma richiama l’importanza di sapere che cosa si sta facendo.

Racconto il caso di una persona che aveva installato Kali sul portatile e incontrato problemi nell’uso quotidiano. Il punto non è ridicolizzare chi comincia: è scegliere uno strumento coerente con l’attività.

Va precisata una semplificazione del dialogo: Kali può essere installata sul disco. Non è obbligatorio utilizzarla esclusivamente in modalità live. È però una distribuzione specializzata nei test di sicurezza, non la scelta suggerita dagli stessi sviluppatori per chi cerca un normale ambiente desktop o sta imparando Linux. La documentazione ufficiale di Kali chiarisce questa destinazione.

Una distribuzione specialistica acquista senso dentro un laboratorio e un’attività autorizzata. Il suo nome, da solo, non rende più sicuro il computer e non dimostra competenza professionale.

Aggiornamenti e stabilità: il rischio di lasciare tutto fermo

La conversazione passa dai ricordi di Compiz e delle personalizzazioni grafiche a un problema attuale: che cosa intendiamo per sistema stabile?

Un computer che continua ad avviarsi può comunque contenere componenti vulnerabili. Marvin osserva che rimandare indefinitamente gli aggiornamenti non equivale a proteggere l’infrastruttura. D’altra parte, aggiornare in produzione richiede valutazione, prove adeguate e una possibilità di ripristino.

La scelta non si riduce a “toccare tutto” oppure “non cambiare mai niente”. Serve conoscere quali componenti sono presenti, quali problemi li riguardano e quanto siano esposti nell’ambiente reale.

Quando una vulnerabilità viene resa pubblica, non nasce necessariamente quel giorno. Poteva già esistere nel software. Questo, però, non dimostra che fosse già sfruttata: esistenza della falla, disponibilità di una correzione e attacchi osservati sono informazioni differenti.

Log4j: quando una dipendenza coinvolge molti servizi

Marvin ricorda le festività trascorse a intervenire sui server durante l’emergenza Log4j del dicembre 2021. È un episodio personale che rende visibile il lavoro dietro un aggiornamento urgente: individuare applicazioni interessate, coordinare interventi e verificare il funzionamento dei servizi.

Il caso riguarda Log4j 2 e le vulnerabilità documentate da Apache, non qualsiasi applicazione Java o qualsiasi server web. La ricostruzione della Apache Software Foundation permette di distinguere le segnalazioni e le correzioni di quel periodo.

Nel video vengono richiamati anche problemi relativi a XZ, sudo e SSH. Non vanno fusi in un’unica vulnerabilità né estesi a tutte le distribuzioni: versioni, configurazioni e condizioni di sfruttamento fanno la differenza. Il caso XZ, per esempio, riguardava una compromissione di specifici rilasci, non l’intera storia del progetto.

Software aperto e manutenzione: la trasparenza è un vantaggio, non una garanzia

La possibilità di esaminare il codice e contribuire alle correzioni è un elemento che apprezziamo nell’open source. Non significa che ogni componente sia controllato continuamente da un numero sufficiente di persone.

Anche la valutazione di un fornitore deve andare oltre il marchio. Conta come gestisce le segnalazioni, comunica gli aggiornamenti e mantiene i prodotti che l’azienda sta utilizzando. Le considerazioni critiche espresse da Marvin su produttori non nominati restano il suo racconto professionale: non consentono di attribuire una specifica negligenza a un’azienda identificabile.

Una correzione tecnica utile riguarda il punteggio delle vulnerabilità: il CVSS arriva a 10, anche nella versione 4.0. Il riferimento informale a “15 su 15” non descrive quella scala. Le specifiche di FIRST riportano l’intervallo corretto.

Backup: il controllo decisivo è riuscire a ripristinare

Marvin insiste su un problema meno spettacolare di un attacco dimostrativo: aziende che non proteggono adeguatamente i dati o non verificano le copie disponibili.

Un backup è utile quando permette di recuperare ciò che serve, nel momento in cui serve. Occorre quindi sapere quali dati include, dove si trova e chi sa eseguire il ripristino. Il semplice messaggio di completamento non risponde a tutte queste domande.

Nel dialogo compaiono GDPR e NIS2 come esempi della crescente attenzione alla gestione del rischio. Non sono norme intercambiabili, né impongono automaticamente gli stessi obblighi a qualsiasi piccola attività. La direttiva NIS2 include continuità operativa e gestione dei backup tra le misure previste per i soggetti interessati; l’applicabilità va valutata nel quadro normativo pertinente.

Il riferimento del video a una prova annuale non va trasformato in una frequenza universale sufficiente. La periodicità deve avere senso rispetto ai sistemi, ai cambiamenti e alle esigenze di recupero.

Una piccola azienda da dove può iniziare?

Luca propone un caso preciso: un microserver, due o tre computer Windows e nessun IT manager. Marvin risponde partendo dall’inventario e, quando mancano competenze interne, dall’aiuto di un professionista.

L’hardening consiste nel rafforzare la configurazione dei sistemi riducendo esposizioni e funzioni non necessarie. Nel video compaiono esempi accessibili: valutare il firewall del singolo computer, la cifratura del disco e i servizi avviati senza una necessità operativa.

Non sono interruttori da modificare alla cieca. Prima bisogna capire che cosa usa davvero l’attività, quali dipendenze esistono e quali conseguenze avrebbe un cambiamento. Spegnere un servizio sconosciuto può interrompere il lavoro anziché migliorarlo.

La domanda successiva è ancora più radicale: quel server serve davvero? Per alcune realtà un servizio gestito può semplificare posta, autenticazione e condivisione dei documenti. In altri casi restano esigenze che giustificano un’infrastruttura propria. Il cloud sposta parte della gestione; non elimina responsabilità, configurazioni e necessità di recuperare i dati.

Credenziali e conseguenze degli incidenti

Marvin racconta di incontrare password conservate in file di testo o fogli di calcolo. La battuta sui CSV serve a evidenziare il problema, non a suggerire quel metodo di archiviazione. Ordinare meglio un elenco non lo rende protetto.

Il ragionamento si allarga ai dati di clienti e fornitori: un incidente può coinvolgere molte persone esterne all’azienda colpita. Nel video si cita anche un caso di documenti sottratti nel settore alberghiero, senza identificarlo con precisione. Non ne ricavo cifre o dettagli tecnici non verificabili. Il rischio di frodi d’identità è il tema; possedere una copia di un documento non garantisce automaticamente la possibilità di ottenere qualunque contratto.

Allo stesso modo, il paragone del cybercrimine con una “terza economia mondiale” non è una misura affidabile degli incassi criminali: stime dei danni, ricavi illeciti e prodotto interno lordo non sono grandezze equivalenti.

Il messaggio operativo rimane concreto: conoscere l’infrastruttura, assegnare responsabilità, correggere le esposizioni e provare il recupero. La sicurezza prende forma in queste attività ripetute, molto prima di una dimostrazione spettacolare.