La tentazione naturale spinge un produttore di tecnologie a creare soluzioni elaborate e dotate di “coolness”, cioè caratteristiche più complete e attrattive rispetto a quelle dei propri competitors. Ma aggiungere funzioni e “figaggine” portano inevitabilmente ad aggiungere complessità.

E la realtà operativa dimostra che la complessità è il nemico numero uno della sicurezza.

Infatti, ogni componente aggiuntivo, ogni funzionalità extra, ogni layer di sofisticatezza introduce nuove superfici di attacco e opportunità di errori.

Da questo punto di vista, la matematica è spietata: un sistema con 10 componenti che hanno ognuno il 99% di affidabilità ha un’affidabilità complessiva del 90%. Aggiungendo altri 10 componenti si scende all’81%. Quindi, la complessità non solo moltiplica i punti di vulnerabilità, ma rende anche più difficile identificarli, testarli e mantenerli nel tempo.

Un sistema complesso è, per definizione, un sistema più fragile. Pertanto, il principio KISS (Keep It Simple & Stupid) rappresenta una delle oggettività più controintuitive della sicurezza informatica: i sistemi più semplici sono quasi sempre più sicuri di quelli complessi.

Proviamo, quindi, a capire quali sono gli strumenti concreti per resistere alla tentazione di introdurre complessità, offrendo metodologie per valutare il rapporto rischio-beneficio di ogni componente aggiuntivo, framework per semplificare architetture esistenti senza perdere funzionalità essenziali e metriche per dimostrare al management che “meno” spesso significa “più sicuro”. E, paradossalmente, significa anche più economico nel lungo termine[1].

DRY: la ridondanza diventa vulnerabilità

Il principio DRY (Don’t Repeat Yourself) invita ad eliminare una delle cause più insidiose di vulnerabilità di sicurezza: il codice duplicato. Infatti, quando la stessa logica di validazione dell’input viene ripetuta in 15 punti diversi dell’applicazione, il rischio che uno di questi punti venga dimenticato durante un aggiornamento di sicurezza diventa statisticamente inevitabile.

Un esempio concreto: un sistema di e-commerce che implementa la validazione della carta di credito in tre moduli separati (checkout, account management, pagamenti ricorrenti) richiede tre aggiornamenti ogni volta che cambiano le regole di validazione dell’input. Dimenticarne uno significa creare involontariamente una backdoor. Sbagliarne uno significa dare tre opportunità diverse all’attaccante.

Invece, centralizzare questa logica in un singolo modulo condiviso elimina il rischio di dimenticarsi qualcosa e la manutenzione diventa più semplice.

Minimalismo informatico: meno codice, meno attacchi

Il minimalismo informatico applica la logica militare del “less is more” al software design. Ogni riga di codice non scritta è una vulnerabilità che non può esistere, ogni libreria non inclusa è una superficie di attacco che viene eliminata, ogni funzionalità non implementata è un vettore di exploit in meno.

Questa filosofia ribalta completamente l’approccio tradizionale che porta ad aggiungere più funzionalità per essere più competitivi.

I sistemi embedded critici applicano questo principio da decenni. Ad esempio, un sistema di controllo di volo contiene solo il codice strettamente necessario per la sua funzione primaria: niente web browser, niente player multimediale, niente WhatsApp né YouTube.

Questa riduzione drastica della superficie di attacco rende questi sistemi intrinsecamente più sicuri di qualsiasi sistema general-purpose, indipendentemente da quanti controlli di sicurezza vengano aggiunti successivamente.

Least Power: il linguaggio giusto per il compito giusto

La regola della Least Power suggerisce di scegliere e usare il linguaggio di programmazione meno potente tra tutti quelli che sono adatti al compito specifico.

Invece di usare un linguaggio Turing-complete per task semplici, è più sicuro utilizzare linguaggi domain-specific con capacità limitate. Un template engine che permette solo la sostituzione di variabili è intrinsecamente più sicuro di uno che permette esecuzione di codice arbitrario.

Questo principio si estende oltre i linguaggi di programmazione: configurazioni, policy, regole di firewall. Una regola che permette “tutto il traffico tranne quello esplicitamente bloccato” è più potente ma meno sicura di una che permette “solo il traffico esplicitamente autorizzato”. La potenza extra spesso si traduce in opportunità per comportamenti non previsti (e non tracciabili).

Worse is Better: quando il software “peggiore” è più sicuro

Il principio “Worse is Better”, nato nel mondo Unix, afferma che software con meno funzionalità può essere superiore a quello feature-rich. Un text editor che fa solo editing è più sicuro di uno che include web browser, email client e persino l’integrazione con i database.

Le funzionalità extra non solo aumentano la superficie di attacco, ma creano anche interdipendenze complesse che rendono difficile prevedere, controllare e manutenere il comportamento del sistema.

Questa filosofia spiega perché strumenti Unix semplici ma robusti continuano a dominare infrastrutture critiche: fanno una cosa sola, la fanno bene e sono facilmente integrabili in maniera modulare con altri strumenti specializzati.

Il risultato è un ecosistema più sicuro e manutenibile rispetto a monoliti all-in-one che tentano di fare tutto – e così si spiega anche il successo dei sistemi operativi con microkernel.

YAGNI: resistere alla tentazione del “cosa se”

“You Aren’t Gonna Need It” combatte una delle tendenze più pericolose nello sviluppo software: aggiungere funzionalità “per ogni evenienza”. I programmatori tendono a implementare soluzioni per ipotetici problemi futuri, creando codice che non viene mai utilizzato. Che però allarga la superficie di attacco! Questo codice dormiente spesso contiene vulnerabilità che rimangono nascoste fino a quando un attaccante non le scopre.

Un sistema di autenticazione che include il supporto futuro per 15 metodi di login diversi, ma oggi ne usa solo 2, ha implementato 13 vettori di attacco inutili che nessuno controllerà. Meglio implementare solo quello che serve adesso e aggiungere le funzionalità nel futuro, quando diventano effettivamente necessarie.

Il paradosso della sicurezza enterprise

I sistemi di classe enterprise spesso violano tutti questi principi simultaneamente: soluzioni complesse che tentano di risolvere ogni possibile fattispecie di problema o richiesta dell’utente, con funzionalità ridondanti che vengono implementate in modi leggermente diversi, utilizzando framework potentissimi per task che richiederebbero semplici script.

Il risultato sono piattaforme che costano milioni di euro da implementare e mantenere, ma rimangono vulnerabili ad attacchi elementari.

In questi casi, mi viene sempre in mente WordPress: molti usano un intero CMS, cioè un Content Management System con tanto di utenti e gestione dei permessi, database e operazioni sui file, plugin e altro codice di terze parti.

Tutto questo spesso per creare un semplice sito-vetrina o una landing-page che sarebbe stato più comodo e sicuro realizzare in linguaggio HTML statico.

La complessità di Classe Enterprise non nasce da necessità tecniche, ma da dinamiche organizzative: produttori che vendono le proprie feature lists, IT manager che preferiscono soluzioni “complete”, processi di procurement che premiano la ricchezza funzionale piuttosto che la robustezza.

Combattere questa tendenza richiede una leadership tecnica forte e metriche che valorizzino semplicità e affidabilità.

Implementare la semplicità: strategie pratiche

Applicare il principio KISS richiede disciplina e metodologie specifiche. Le sessioni di code review dovrebbero includere domande come «questa è la soluzione più semplice possibile?», «possiamo eliminare qualche componente senza perdere funzionalità essenziali?», «ogni dipendenza è davvero necessaria?». Le revisioni dell’architettura dovrebbero premiare quei design che riducono il numero di componenti mobili.

La semplicità deve essere un requisito esplicito, non un risultato accidentale. Questo significa definire metriche di complessità (numero di dipendenze, complessità ciclomatica/complessità condizionale, linee di codice), stabilire budget di complessità per ogni componente e implementare gates che impediscano l’accumulo di complessità ingiustificata.

Refactoring: incomincia a semplificare l’esistente!

Molte organizzazioni hanno sistemi complessi già in produzione, che quindi non possono essere riscritti da zero. Il refactoring orientato alla sicurezza può applicare i principi KISS gradualmente, cioè eliminando codice morto, consolidando logiche duplicate, sostituendo framework pesanti con alternative light e rimuovendo funzionalità non utilizzate.

Questo processo richiede metriche per misurare il miglioramento: riduzione della superficie di attacco, diminuzione dei tempi di security assessment, incremento nella velocità di patch deployment.

La semplicità non è un obiettivo estetico ma un risultato misurabile che si traduce in sicurezza operativa tangibile soprattutto quando ti serve giustificare il maggior costo e effort con i tuoi capi.

La semplicità è un vantaggio competitivo

Organizzazioni che riescono a mantenere la semplicità nei loro sistemi ottengono vantaggi competitivi duraturi: time-to-market più rapidi, costi operativi inferiori, minor downtime, conformità più facile da ottenere.

La sicurezza diventa un abilitatore del business piuttosto che un freno a mano, proprio perché i sistemi più anche semplici sono più facili da proteggere, ispezionare e scalare nel tempo.

Il principio KISS trasforma la sicurezza da un’attività reattiva (aggiungere protezioni a sistemi complessi) in un approccio proattivo (progettare sistemi intrinsecamente sicuri).

È una filosofia che richiede un cambiamento culturale, ma che ripaga attraverso sistemi più robusti, manutenibili, economici e sicuri.

[1] Il Manuale CISO Security Manager prepara alla certificazione CISSP e approfondisce metodologie per implementare principi di semplicità in architetture Enterprise, fornendo indicazioni pratiche per valutare e ridurre la complessità senza compromettere le funzionalità di business.