I sistemi informatici falliscono. Non è una questione di “se”, ma di “quando” e soprattutto di “come” il tuo sistema fallirà.
La differenza tra un’organizzazione preparata e una vulnerabile risiede proprio nella capacità di progettare sistemi che falliscano in modo sicuro, sacrificando funzionalità o prestazioni per preservare la sicurezza degli asset critici. A pensarci bene, è una filosofia che adotta il punto di vista opposto alla business continuity e dell’uptime a tutti i costi.
Nel mondo fisico, la priorità va sempre alla protezione delle persone. Una porta di emergenza che si blocca durante un incendio rappresenta un fallimento catastrofico, indipendentemente da quanto sia sicura per prevenire furti. Al contrario, nel mondo digitale la priorità va agli asset digitali (con alcune eccezioni come i sistemi medici o di controllo industriale): dati, sistemi, informazioni riservate.
Questo cambiamento di priorità richiede logiche di progettazione completamente diverse, adottando metodologie pratiche che aiutino i responsabili della sicurezza a progettare sistemi che degradino in modo controllato durante i guasti, bilanciando continuità operativa con protezione degli asset critici e sviluppando procedure di fail secure che trasformino i fallimenti inevitabili in opportunità per dimostrare la robustezza dell’architettura di sicurezza[1].
Indice degli argomenti
Exception handling: prevedere l’imprevedibile
La gestione programmatica degli errori rappresenta la prima linea di difesa contro i fallimenti insicuri.
Il costrutto try-catch permette ai programmatori di anticipare potenziali errori e di definire comportamenti sicuri quando questi si verificano. Invece di lasciare che un’applicazione si blocchi improvvisamente esponendo informazioni sensibili o stati inconsistenti, il codice può gestire l’errore in modo controllato.
Un esempio pratico: un sistema di e-commerce che non riesce a elaborare un pagamento può semplicemente mostrare un messaggio di errore generico all’utente, registrare i dettagli tecnici nei log interni e inviare una notifica al team di supporto. L’alternativa – un crash che espone dettagli del database o lascia transazioni in stati intermedi – crea vulnerabilità di sicurezza e problemi di integrità dei dati.
Input sanitization: la prima barriera di difesa
La sanificazione dell’input opera come un filtro intelligente tra il mondo esterno non controllato e la logica interna dell’applicazione.
Ogni dato proveniente dall’esterno come password, email, campi di form, parametri URL, deve essere validato per lunghezza, formato, caratteri permessi e range di valori accettabili. Non è paranoia, ma è semplicemente matematica: ogni input non validato aggiunge un potenziale vettore di attacco e amplia statisticamente il rischio di successo per l’attaccante.
Una validazione efficace richiede l’approccio whitelist piuttosto che blacklist: invece di cercare di bloccare tutti i possibili input maligni (è pressoché impossibile), si definisce precisamente cosa è permesso e si rifiuta tutto il resto. Un campo email deve contenere esattamente caratteri alfanumerici, un simbolo @ e pochi altri simboli specifici, niente di più. Qualsiasi deviazione deve essere respinta indipendentemente da quanto creativa possa sembrare.
Il dizionario del fallimento: fail-soft, fail-secure e le loro sfumature
La terminologia del fallimento sicuro può confondere, ma ogni termine descrive comportamenti specifici che hanno implicazioni di sicurezza precise.
Fail-soft significa che il sistema è danneggiato ma non è completamente bloccato: può continuare a funzionare in modalità degradata. Un esempio classico è un’applicazione che va in crash mentre il sistema operativo continua a funzionare normalmente.
Fail secure e fail safe rappresentano filosofie opposte che dipendono dal contesto. Nel mondo fisico, fail safe coincide con fail open: se la serratura di emergenza si rompe, la porta deve aprirsi per permettere l’evacuazione. Nel mondo digitale, fail secure spesso coincide con fail closed: se il firewall va in crash, è preferibile bloccare tutto il traffico piuttosto che permettere accessi non controllati.
Il paradosso del caveau
Non tutti i sistemi fisici seguono la regola del fail open. Un caveau bancario che si apre automaticamente in caso di guasto della serratura creerebbe problemi di sicurezza enormi. In questi casi si preferisce fail-closed con controlli compensativi: sistemi di comunicazione di emergenza, protocolli di sblocco manuale, monitoraggio continuo.
L’obiettivo è mantenere la sicurezza primaria implementando vie di fuga alternative.
Questa logica si applica anche ai sistemi digitali più critici. Un firewall perimetrale può essere configurato per bloccare tutto il traffico in caso di malfunzionamento, accettando anche l’interruzione del business pur di preservare la sicurezza.
Però, l’implementazione richiede sistemi di monitoraggio esterni al firewall stesso che rilevino immediatamente il guasto e attivino procedure di ripristino rapide.
La raccomandazione IETF: precisione terminologica per evitare ambiguità
L’Internet Engineering Task Force raccomanda di evitare il termine “fail safe” quando si discute esclusivamente di sistemi digitali, proprio per prevenire la confusione con la sicurezza fisica delle persone. Quando in gioco ci sono la salute e la vita umana, è meglio essere precisi…
Quindi, nel mondo digitale è più preciso parlare di fail secure o fail open/fail closed, cioè quei termini che si focalizzano specificamente sulla sicurezza informatica che non hanno implicazioni sulla “safety” umana.
Questa distinzione terminologica non è pedanteria accademica, ma si tratta di una necessità pratica. Quando si progettano sistemi che gestiscono sia aspetti digitali che fisici come sistemi di controllo industriale, dispositivi medici, infrastrutture critiche, la confusione tra safety e security può avere conseguenze drammatiche.
Il trade-off tra business continuity vs security
La scelta tra fail open e fail closed riflette le priorità strategiche dell’organizzazione.
Un’azienda che si basa su un e-commerce può preferire che il sito rimanga accessibile anche con alcuni controlli di sicurezza degradati, accettando rischi limitati pur di continuare a vendere. Al contrario, una banca può preferire che le transazioni online si blocchino completamente se i sistemi antifrode vanno offline, eventualmente anche sacrificando i ricavi nel breve termine.
Queste decisioni richiedono analisi approfondite di rischio e business impact, che coinvolgono sia il management tecnico che quello di business.
Non esistono risposte universalmente corrette: ogni organizzazione deve trovare il proprio equilibrio basandosi sul proprio livello approvato di tolleranza al rischio, sul proprio modello di business e sul proprio contesto normativo.
La provocazione: accettare il fallimento come un requisito di design
Progettare il fallimento sicuro richiede un cambio di mentalità: non si tratta di aggiungere controlli di sicurezza a sistemi esistenti, ma di considerare le modalità di fallimento come requisiti di design primari.
Ogni componente del sistema deve avere comportamenti di fallimento definiti, testati e documentati.
Questo approccio si estende oltre il codice: procedure operative, escalation, comunicazioni di emergenza, ripristino.
Un sistema che fallisce in modo sicuro non è solo una questione tecnica, ma è un risultato di design completo che considera persone, processi e tecnologie in modo integrato.
Partecipa alla community