Sicurezza tramite segretezza

La sicurezza tramite segretezza, traduzione dell'inglese security through obscurity, è un principio che si basa sull'assunto che tenere segreto il funzionamento interno di un sistema o di un componente lo renda più sicuro, dato che un eventuale attaccante avrebbe maggiore difficoltà nella scoperta di eventuali falle del sistema stesso. Un sistema o componente che fa affidamento sulla segretezza può avere vulnerabilità di sicurezza teoriche o reali, ma i suoi proprietari o progettisti ritengono che se i difetti non sono noti, ciò renderà più difficile la riuscita di un attacco. Nascondere la serratura della porta di casa in modo che sia difficile per un eventuale ladro trovarla è un esempio di scelta che si basa su questo principio.

La sicurezza tramite segretezza è il cardine di alcuni strumenti di protezione, come ad esempio la proprietà intellettuale o del segreto di Stato. Viceversa, in altri, essa è considerata una pratica da evitare, come la crittografia, la sicurezza informatica o le serrature.

Uno dei primi avversari della sicurezza tramite la segretezza fu il fabbro Alfred Charles Hobbs, che nel 1851 dimostrò al pubblico come si potevano scassinare le serrature più avanzate e che, in risposta alle preoccupazioni sul fatto che le serrature potevano avere difetti, che le potevano rendere più vulnerabili ai criminali, dichiarava: "I ladri sono molto appassionati nella loro professione e sanno già molto più di quanto possiamo insegnare loro." [1] C'è poca letteratura formale sulla questione della sicurezza tramite la segretezza. In crittografia esiste un principio opposto (detto principio di Kerckhoffs), che afferma che il progettista di un sistema deve presumere che l'attaccante conosca il sistema alla perfezione, con l'unica eccezione della chiave crittografica. Un parallelo illuminante può essere quello di una normale serratura meccanica, con azionamento ben conosciuto ma apribile solo con la chiave giusta. Un'altra contro-argomentazione è che mantenere "nascosto" l'interno potrebbe migliorare la sicurezza a breve termine, ma a lungo termine dovrebbero essere considerati solo i sistemi che sono stati pubblicati e analizzati. Steve Bellovin commentò:[2]

«Il tema della sicurezza attraverso l'oscurità si presenta frequentemente. Penso che gran parte del dibattito avvenga perché la gente fraintende il problema. Credo sia utile ritornare al secondo principio di Kerckhoffs, spiegato come 'Il sistema non deve richiedere segretezza e può essere rubato dal nemico senza causare problemi', su http://petitcolas.net/fabien/kerckhoffs/. Kerckhoffs non diceva 'pubblica tutto' né 'tieni tutto segreto'; piuttosto, diceva che il sistema dovrebbe essere sicuro anche se il nemico ne ha una copia. In altre parole: progetta il tuo sistema assumendo che i tuoi avversari lo conoscano in dettaglio. (Un ex funzionario del National Security Center della NSA mi disse che l'ipotesi standard era che il numero seriale 1 di ogni nuovo dispositivo fosse consegnato al Cremlino.) Dopo di ciò, però, non c'è niente di sbagliato nel cercare di mantenerlo segreto - è un altro ostacolo che il nemico deve superare. (Un ostacolo che gli inglesi incontrarono quando attaccavano il sistema tedesco Enigma era semplice: non conoscevano la mappatura tra i tasti della tastiera e l'ingresso all'array di rotori.) Ma non fare affidamento sulla segretezza del sistema.»

Ad esempio, in una discussione sulla segretezza e l'apertura dei sistemi di Comando e Controllo nucleare:

«I benefici della riduzione della probabilità di una guerra accidentale erano considerati superiori ai possibili benefici della segretezza. Questa è una reincarnazione moderna del principio di Kerckhoffs, presentato per la prima volta nel diciannovesimo secolo, secondo cui la sicurezza di un sistema dovrebbe dipendere dalla sua chiave, e non dal suo design che rimane segreto.[3]»

È un concetto agli antipodi della filosofia alla base dell'open source, la quale sostiene invece che, grazie alla vasta collaborazione della comunità, le falle possono venir scoperte più facilmente e altrettanto rapidamente corrette, con il risultato di rendere il sistema intrinsecamente più sicuro.

In un contesto accademico-giuridico, Peter Swire ha descritto un possibile compromesso tra la nozione secondo cui "la sicurezza attraverso la segretezza è un'illusione" e la nozione militare secondo cui "le labbra sciolte affondano le navi"[4] e ha pure descritto il modo in cui la concorrenza influenza la tendenza a rivelare[5]. Il principio della sicurezza attraverso la segretezza era più generalmente accettato nel lavoro di crittografia nei giorni in cui essenzialmente tutti i crittografi ben informati erano impiegati da agenzie di intelligence nazionali, come la National Security Agency.

Ora che i crittografi lavorano spesso nelle università, dove i ricercatori pubblicano molti o addirittura tutti i loro risultati, e analizzano pubblicamente i design di altri, o nell'industria privata, dove i risultati sono controllati più spesso da brevetti e copyright piuttosto che dalla segretezza, l'argomentazione ha perso un po' della sua precedente popolarità. Un esempio è PGP, il cui codice sorgente è pubblicamente disponibile a chiunque, ed è generalmente considerato come un crittosistema di livello militare. Ci sono storie contrastanti sull'origine di questo termine. I fan del sistema Incompatible Timesharing System (ITS) del MIT affermano che è stato coniato in opposizione agli utenti di Multics in fondo al corridoio, per i quali la sicurezza era molto più un problema che non su ITS. All'interno della cultura ITS il termine si riferiva, in modo auto-schernente, alla scarsa copertura della documentazione e segretezza di molti comandi, e all'atteggiamento secondo il quale un turista, nel momento in cui aveva capito come creare problemi, in generale si era lasciato sfuggire l'impulso di crearne, perché si sentiva parte della comunità.

Critiche

modifica

La sicurezza tramite segretezza è scoraggiata e non raccomandata dagli enti normativi. Il National Institute of Standards and Technology (NIST) negli Stati Uniti sconsiglia espressamente questa pratica: "La sicurezza del sistema non dovrebbe dipendere dalla segretezza dell'implementazione o dei suoi componenti." [6] Tuttavia, il NIST afferma anche: "Per i server che interfacciano il mondo esterno, riconfigurare i banner di servizio per non segnalare il tipo e la versione del server e del sistema operativo, se possibile. (Questo scoraggia gli aggressori inesperti e alcune forme di malware, ma non impedirà ai più abili aggressori di identificare il server e il tipo di sistema operativo.)"

  1. ^ Randall Stross, Theater of the Absurd at the T.S.A., su The New York Times. URL consultato il 5 maggio 2015.
  2. ^ Steve Bellovin, Security through obscurity, in Risks Digest, June 2009.
  3. ^ (EN) Ross Anderson, Security Engineering: A Guide to Building Dependable Distributed Systems, New York, John Wiley & Sons, Inc., 2001, p. 429, ISBN 0-471-38922-6.
  4. ^ Peter P. Swire, A Model for When Disclosure Helps Security: What is Different About Computer and Network Security?, in Journal on Telecommunications and High Technology Law, vol. 2, 2004, SSRN 531782.
  5. ^ Peter P. Swire, A Theory of Disclosure for Security and Competitive Reasons: Open Source, Proprietary Software, and Government Agencies, in Houston Law Review, vol. 42, January 2006, SSRN 842228.
  6. ^ Guide to General Server Security (PDF), su nvlpubs.nist.gov, National Institute of Standards and Technology, July 2008. URL consultato il 2 ottobre 2011.
  NODES
INTERN 3
Note 1