Il dibattito tra sistemi aperti e chiusi nella sicurezza informatica assomiglia alla discussione tra chi preferisce le porte blindate e chi i bunker segreti. Entrambi gli approcci hanno meriti e limiti, e spesso vengono integrati.
Ma la realtà degli attacchi dimostra che la vera sicurezza nasce da fattori molto più profondi della semplice visibilità o segretezza di un sistema.
I sistemi chiusi, come l’ecosistema Apple o IBM, utilizzano hardware e software proprietari con standard non divulgati pubblicamente. Questa architettura può scoraggiare gli attacchi dell’hacker di passaggio, perché richiede competenze specifiche e personalizzazione degli exploit per ogni target: un criminale informatico che sviluppa ransomware per Windows avrà difficoltà a riutilizzare le stesse tecniche su di un mainframe IBM proprietario.
Ma dall’altra parte, quel mainframe non scoraggerà un criminale che in un ransomware così specializzato per un sistema così costoso vede opportunità di profitto enormi rispetto ad un banale Windows 11.
Ecco, quindi, una guida pratica per navigare oltre il falso dilemma “aperto vs chiuso”, fornendo metodologie per valutare sistemi e fornitori basandosi su criteri di sicurezza sostanziali piuttosto che su filosofie tecnologiche, e sviluppando strategie di protezione efficaci indipendentemente dall’architettura sottostante[1].
Indice degli argomenti
L’economia degli attacchi: scalabilità vs specializzazione
La differenza fondamentale risiede nell’economia dell’attacco. I sistemi aperti permettono agli aggressori di sviluppare exploit che funzionano su milioni di installazioni identiche: è un investimento in ricerca e sviluppo che si ripaga su vasta scala.
Scoprire una vulnerabilità in Apache HTTP Server significa potenzialmente compromettere centinaia di migliaia di server web in tutto il mondo.
Invece, i sistemi chiusi richiedono investimenti specifici per ogni target, rendendo economicamente vantaggiosi solo attacchi mirati contro obiettivi di alto valore. È improbabile che criminali comuni investano mesi di reverse engineering per attaccare un sistema di controllo industriale proprietario, a meno che non sia critico per le infrastrutture strategiche o contenga informazioni estremamente preziose.
Tuttavia, potrebbero decidere di investire tempo e risorse per attaccare Mac OS X, perché è molto diffuso e chi può permettersi il costo di un computer Apple, più elevato rispetto ad un PC, probabilmente può anche permettersi anche di pagare un riscatto più alto.
La falsa sicurezza dell’offuscamento
L’offuscamento attraverso la segretezza (Security Through Obscurity) può fornire una protezione temporanea, ma non costituisce una sicurezza reale.
La storia dell’informatica è piena di sistemi inviolabili che si sono rivelati fragili appena sono stati sottoposti ad un’analisi approfondita. Ad esempio, il Content Scramble System (CSS) per i DVD, che era considerato impossibile da craccare, è stato violato da un teenager norvegese. Il sistema di sicurezza delle smart card per pay-TV, che era coperto dal segreto industriale, è stato compromesso da ricercatori accademici.
La segretezza può rallentare gli attaccanti, ma raramente li ferma definitivamente. Il reverse engineering, la decompilazione e persino il furto diretto del codice sorgente possono vanificare qualsiasi strategia basata esclusivamente sull’oscurità.
Peggio ancora, quando un sistema segreto viene compromesso, i difensori spesso non se ne accorgono immediatamente e non vengono avvisati, proprio perché mancano meccanismi di monitoraggio e validazione esterni.
Open source: la forza della trasparenza collettiva
I sistemi open source capovolgono completamente l’approccio: invece di nascondere il codice, lo espongono al pubblico per permetterne l’ispezione e il miglioramento continui.
Questa trasparenza può sembrare controintuitiva dal punto di vista della sicurezza, ma crea dinamiche positive che non vanno sottovalutate: migliaia di sviluppatori possono identificare vulnerabilità che sfuggirebbero a team interni, spesso ridotti e circoscritti.
La cosiddetta Legge di Linus, principio chiamato così in onore di Linux Torvalds, postula: «given enough eyeballs, all bugs are shallow» («dato un numero sufficiente di occhi, tutti i bug vengono a galla»). La Legge di Linus si applica alla sicurezza in modo particolare: più persone esaminano il codice, maggiore è la probabilità di identificare i problemi prima che vengano sfruttati malevolmente.
Protocolli come OpenSSL, nonostante bug occasionali come Heartbleed, beneficiano di un controllo continuo che li rende complessivamente più robusti degli omologhi protocolli proprietari.
Il paradosso della standardizzazione
Gli standard aperti creano un paradosso interessante: aumentano la superficie di attacco rendendo i sistemi più prevedibili, ma migliorano anche la sicurezza attraverso implementazioni mature e ben testate.
Il protocollo TLS è pubblico e quindi è perfettamente studiabile dagli attaccanti, ma proprio questa pubblicità ha permesso decenni di miglioramenti e hardening che lo rendono estremamente robusto.
Inoltre, la standardizzazione permette economie di scala che sono utilissime per la difesa: strumenti di sicurezza, training e best practice si possono condividere tra organizzazioni diverse.
Un amministratore esperto in sistemi Linux può applicare le sue competenze in migliaia di aziende, mentre l’expertise su sistemi proprietari rimane spesso limitata al fornitore originale.
Hybrid approach: il meglio di entrambi i mondi
Molte organizzazioni oggi adottano approcci ibridi che combinano strategicamente componenti aperti e chiusi. Utilizzando standard aperti per l’interoperabilità (HTTP, SQL, TCP/IP), è comunque possibile implementare logiche di business proprietarie per differenziarsi competitivamente.
Questo approccio permette di beneficiare della robustezza degli standard maturi, pur mantenendo la protezione della propria proprietà intellettuale.
La chiave è identificare quali componenti traggono vantaggio dalla trasparenza (protocolli di comunicazione, algoritmi crittografici, interfacce utente) e quali invece beneficiano della segretezza (algoritmi di trading proprietari, formule chimiche, processi produttivi specifici).
Defense in depth: oltre la dicotomia aperto/chiuso
La sicurezza reale nasce dall’implementazione di strategie defense-in-depth che non dipendono dalla segretezza dei singoli componenti. Un sistema veramente sicuro dovrebbe resistere agli attacchi anche se l’attaccante conosce perfettamente il suo funzionamento interno.
Questo principio, noto come Algoritmo di Kerckhoffs – su cui stresso i miei studenti CISSP – è fondamentale nella crittografia moderna e dovrebbe guidare anche la progettazione di sistemi complessi.
Le organizzazioni più sensibili alla sicurezza combinano controlli tecnici robusti, processi operativi disciplinati, formazione continua del personale e monitoraggio proattivo delle minacce.
In questo modo, la scelta tra sistemi aperti o chiusi diventa semplicemente una considerazione tattica piuttosto che strategica.
Partecipa alla community