Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime e Analisi Vulnerabilità
Il DLP funziona quando protegge dati classificati su canali selezionati con regole proporzionate. Fallisce quando monitora tutto. Il confine tra sicurezza e sorveglianza non lo traccia il prodotto: lo traccia il progetto.
Il CISO aveva tutto pronto: progetto approvato, budget stanziato, vendor selezionato. Mancava solo l’ultimo passaggio. Poi il progetto è arrivato al tavolo con le rappresentanze dei lavoratori e, come accade spesso, la discussione ha smesso di parlare di dati e ha iniziato a parlare di controllo.
Quando in azienda si nomina un sistema di Data Loss Prevention, la reazione è quasi sempre la stessa: “state installando il Grande Fratello”. Ma un DLP non nasce per sorvegliare le persone. Nasce per identificare, monitorare e proteggere dati sensibili lungo canali specifici: endpoint, email, dispositivi rimovibili, stampa, servizi cloud, traffico web.
Se progettato male, però, può diventare invasivo. Non perché “veda tutto” per magia, ma perché qualcuno gli ha assegnato un perimetro troppo ampio, policy confuse, eccezioni assenti e finalità poco definite. Monitorare in modo indiscriminato ogni file copiato su USB significa avvicinarsi alla sorveglianza. Monitorare solo file classificati come riservati, su canali selezionati e con regole proporzionate, significa proteggere il dato. La differenza non sta nel prodotto, ma nella progettazione.
Il punto più delicato è il monitoraggio dei dati in uso e in transito: clipboard, operazioni sui file, upload, allegati, copia verso supporti esterni. A seconda della configurazione, l’agent può raccogliere telemetria che l’utente non percepisce immediatamente. È questo che il CISO deve saper spiegare: quali dati vengono osservati, per quali finalità, con quali limiti e con quali garanzie.
Troppo spesso le aziende partono dal prodotto invece che dal problema. Comprano la piattaforma, installano gli agent, attivano le regole e solo dopo si pongono la domanda che avrebbe dovuto aprire il progetto: quali dati proteggere, dove si trovano, chi li usa e attraverso quali canali transitano. Se la risposta è “tutto”, nella pratica la risposta è “niente”.
Un DLP serio non parte dal blocco indiscriminato. Parte dalla Data Discovery, dalla classificazione e dalla proporzionalità. NIST non tratta il DLP come control family autonoma, ma le sue capacità si appoggiano a controlli come AC-4, SC-7, SI-4, SC-28 e ad altri controlli contestuali. Il NCCoE richiama la necessità di identificare i dati sensibili e proteggerli dalla perdita di riservatezza. Senza questo lavoro il DLP diventa rumoroso per i falsi positivi e cieco per i falsi negativi: dati non classificati che escono senza che nessuno se ne accorga.
A quel punto il sindacato non sta ostacolando la cybersecurity. Sta reagendo a un progetto che somiglia più a controllo che a protezione.
In Italia questo passaggio non si gestisce con slogan. L’articolo 4 dello Statuto dei Lavoratori impone garanzie precise quando uno strumento comporta la possibilità di controllo a distanza dell’attività lavorativa. Nel caso di un DLP endpoint, la qualificazione dipende dalla configurazione concreta, dai dati raccolti, dalle finalità perseguite e dal livello di intrusività. Il GDPR impone lo stesso rigore: finalità determinate, minimizzazione, protezione dei dati fin dalla progettazione. Proprio per questo il CISO da solo non basta. Servono DPO, Legal, HR, operations e business owner: distribuire un agent è relativamente semplice; progettare un DLP proporzionato e difendibile no.
Il problema non è il DLP. Il problema è il DLP comprato come prodotto e non progettato come sistema. Quello improvvisato genera conflitto. Quello progettato bene protegge davvero.
