La sicurezza informatica assomiglia alle fondamenta di un edificio: dopo la costruzione puoi aggiungere tutti i rinforzi che vuoi, ma se le basi sono fragili, prima o poi crollerà tutto.
Eppure, troppe organizzazioni continuano a trattare la sicurezza come un accessorio da installare a sistema già funzionante, scoprendo solo successivamente quanto il taglio degli investimenti in sicurezza (che sembravano costi troppo alti) diventa un costo enormemente superiore già dopo i primi incidenti. Oltre alle visite di ispettori, auditors di clienti e fornitori, titoloni sui giornali.
Integrare la sicurezza fin dalla fase progettuale non è solo più efficace dal punto di vista tecnico, ma è anche economicamente più vantaggioso. Correggere una vulnerabilità di design durante lo sviluppo costa una frazione rispetto a patchare lo stesso problema in produzione, senza contare i costi indiretti: downtime, perdita di reputazione, sanzioni.
La sicurezza, dunque, è uno sport di squadra che coinvolge programmatori, sviluppatori, ingegneri, manutentori e utenti in ogni fase del ciclo di vita del sistema. Ed è uno sport di contatto: devi agire e devi lottare[1].
Anche i sistemi apparentemente non critici possono diventare un punto di appoggio per sferrare attacchi devastanti.
Un server di stampa mal configurato, un sistema di gestione presenze obsoleto, una telecamera di sicurezza con credenziali di default: tutto può trasformarsi in una testa di ponte per raggiungere i sistemi realmente critici.
Gli attaccanti non sono stupidi e non puntano direttamente al castello, col rischio di far scattare l’allarme e farsi puntare un faro addosso. Piuttosto cercano la porta di servizio meno sorvegliata della stalla e da lì aspettano pazientemente che entri qualcuno con le chiavi.
Questa situazione rende fondamentale applicare i criteri (almeno base) di sicurezza anche ai sistemi periferici, non per proteggere direttamente i loro dati, ma per evitare che diventino i punti di ingresso laterali.
Un approccio di questo tipo richiede una visione sistemica della sicurezza, dove ogni componente è parte di un ecosistema più ampio e interdipendente.
Il controllo degli accessi si basa su una relazione fondamentale tra soggetti e oggetti. Il soggetto è l’entità attiva che richiede accesso: un utente, un programma, un computer, un’intera organizzazione. L’oggetto è l’entità passiva a cui il soggetto vuole accedere: un file, una stampante, un database, ma può essere anche un utente o un processo. L’accesso definisce il tipo di interazione che viene permessa: lettura, scrittura, modifica, eliminazione, stampa, spostamento, backup.
Questa apparente semplicità nasconde una complessità esplosiva quando si considera che ogni soggetto può richiedere accesso a migliaia di oggetti diversi (anche automaticamente), con permessi specifici che cambiano nel tempo.
Un dipendente può aver bisogno di leggere un documento al mattino, modificarlo nel pomeriggio e di abbandonarlo per sempre dopo aver cambiato azienda il giorno dopo.
Gestire questa dinamicità senza compromettere la sicurezza o la produttività rappresenta una delle sfide centrali dell’IT.
I sistemi chiusi, come ad esempio l’ecosistema iCloud di Apple, utilizzano hardware e software proprietari con standard che non vengono divulgati pubblicamente.
Questa chiusura può offrire diversi vantaggi e gli attacchi devono essere personalizzati per ogni sistema, riducendo così la scalabilità delle minacce. Infatti, l’attaccante che sviluppa competenze generiche troverà meno bersagli adatti alle sue skill e troverà meno knowledge sharing nella comunità criminale.
I sistemi aperti, che sono progettati con standard di settore e API compatibili, presentano il panorama opposto. La loro prevedibilità li rende più vulnerabili agli attacchi standardizzati, ma sono anche più facilmente integrabili e verificabili.
La diffusione degli standard aperti crea economie di scala sia per i difensori che per gli attaccanti: sono disponibili più strumenti di difesa, ma vengono anche condivise più conoscenze offensive.
La chiusura di un sistema si configura essenzialmente come una tecnica di offuscamento (Security Through Obscurity) che i miei studenti CISSP conoscono bene: può scoraggiare i malintenzionati generalisti, ma non ferma gli attaccanti motivati e dotati di risorse.
La storia della sicurezza informatica è piena di sistemi “inviolabili” che poi si sono rivelati vulnerabili appena sono stati sottoposti ad analisi approfondita. Il reverse engineering, la decompilazione e il furto di codice sorgente possono vanificare qualsiasi strategia basata sulla segretezza.
La sicurezza reale di un sistema aperto dipende dall’implementazione di pratiche di codifica sicure e da strategie di defense-in-depth. Invece di affidarsi all’oscurità, questi sistemi costruiscono robustezza attraverso design sicuro, validazione rigorosa, monitoraggio continuo e risposta rapida alle minacce identificate.
Poi, eventualmente, l’offuscamento può essere applicato come ultimo step.
Le soluzioni open source espongono il codice sorgente al pubblico, permettendo ispezione e revisione da parte di auditor volontari che possono migliorare il prodotto nel tempo.
Questa trasparenza può permettere di identificare le vulnerabilità prima che vengano sfruttate, ma offre anche agli attaccanti la completa visibilità sui potenziali punti deboli.
Le soluzioni closed source nascondono codice sorgente e logiche interne, ma questa protezione può essere aggirata attraverso il reverse engineering, quando non il furto del codice sorgente.
Il dibattito tra questi approcci continua, ma la realtà operativa suggerisce che la qualità del design e dell’implementazione conta più della filosofia di distribuzione del codice.
I principi di progettazione sicura ci insegnano che la protezione efficace nasce dalle scelte architetturali fondamentali, non dalle patch applicate il giorno dopo.
Un sistema progettato con controlli degli accessi granulari, separazione dei privilegi, fail-safe defaults e defense-in-depth resisterà meglio agli attacchi rispetto a qualsiasi sistema rafforzato a posteriori.
Questa consapevolezza deve guidare ogni decisione tecnologica: dalla scelta dei fornitori alla definizione dei requisiti, dalla pianificazione dell’architettura alla formazione del team di sviluppo.
La sicurezza by design non è un costo aggiuntivo, ma è un investimento che ripaga nel lungo periodo attraverso incidenti con minor impatto, conformità normativa e fiducia degli stakeholder.
[1] Il Manuale CISO Security Manager prepara alla certificazione CISSP e esplora in dettaglio i principi di progettazione sicura e le metodologie per implementare il paradigma della security by design in organizzazioni di ogni dimensione, fornendo framework pratici per integrare la sicurezza in ogni fase del ciclo di sviluppo.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
Fabrizio Saviano
Source link
