Secure by design 

Anni di sviluppo, numerosi tecnici e responsabili di processo coinvolti e centinaia di migliaia di euro investiti. Tuttavia, alla prima valutazione di sicurezza, emergono migliaia di vulnerabilità nel nostro programma che, pur essendo tecnicamente avanzato mostra significative debolezze quando sottoposto alle rigorose verifiche della certificazione di sicurezza.

Ma è sempre così?

Risposta: no, ma tenendo ovviamente conto della profondità del problema.

Security by design

“Security by design” (che potremmo tradurre con “sicurezza progettata fin dall’inizio”) è un approccio alla progettazione di sistemi, software, dispositivi e infrastrutture in cui la sicurezza viene integrata fin dalle fasi iniziali del progetto. L’idea centrale è che la sicurezza non debba essere aggiunta successivamente come un elemento accessorio, ma debba essere parte integrante del processo di sviluppo. La sicurezza è così un elemento prioritario al pari delle funzionalità dell’applicazione.
Tale approccio porta a ripensare, quindi, alle strategie di difesa, in modo che la sicurezza sia intrinseca by design. 

Gli standard

Ad oggi esistono numerosi standard, modelli o framework, stilati da diversi enti e organizzazioni, tutti con lo stesso obiettivo: definire un insieme di principi validi per costruire applicazioni sicure fin dalle fondamenta e che restino tali nel tempo.

Gli standard più noti sono:

• NIST con il SP 800-160 e con il Cybersecurity Framework
• OWASP con i Secure Design Principles (qui il cheatsheet e i Secure Coding Practices)
• ISO/IEC 27001 e ISO/IEC 27002, entrambi parlano in modo non specifico ma forniscono un quadro generale di sicurezza
• IEC 62443 un set di standard di sicurezza per l’ambito di automazione e sistemi di controllo

Per semplicità e completezza ci affideremo al modello stabilito dall’OWASP.

Cos’è l’OWASP?

L’OWASP è un progetto di utilità pubblica (open-source per chi è del settore) che ha lo scopo di dettare metodologie e linee guida per aumentare la sicurezza delle applicazioni informatiche. 

A prima vista può sembrare un agglomerato di elenchi, classifiche e principi che poco può aver a che fare con la parte edile di un applicativo. Anzi, induce a pensare di essere entrati in un dizionario colmo di sigle e termini astrusi volti a dare informazioni solo a chi già è introdotto alla materia. 

Quello che invece dovrebbe essere percepito è il forte bisogno di avere idee comuni e chiare a tema sicurezza informatica, dove generalmente viene diffusa ignoranza e confusione. 

Il problema

Chiarito il contesto approfondiamo la tematica principale:

Come posso progettare e sviluppare un’applicazione tenendo conto dei temi riguardanti la sicurezza?

Principi cardine dell’approccio security by design

Si possono evidenziare alcuni principi fondamentali dell’approccio “security by design”. Vediamoli di seguito.

1. Minimizzare la superficie d’attacco

Il primo paradigma di ogni prodotto che aspira ad una sicurezza adeguata è quello di minimizzare la facciata esterna e dunque ridurre l’area accessibile agli attaccanti del sistema. Può sembrare scontato, ma tra licenze d’implementazione, soluzioni temporanee per far funzionare il processo o, nel caso più innocuo, la condivisione di una semplice documentazione, accade spesso che gli sviluppatori si prendano libertà che possono aprire pericolose falle. Questo crea vulnerabilità che permettono a chiunque, anche con un semplice computer di compromettere gravemente la sicurezza del sistema.

La domanda da porci in fase di progettazione sarà dunque: se non serve al funzionamento dell’applicazione perché lasciare questa risorsa accessibile?

2. Zero trust

Il più semplice da capire ma il più difficile da applicare. Questo principio impone che in un ambiente tutte le entità non sono affidabili e/o degne di fiducia se non dopo aver verificato i loro privilegi. Detto ciò, si può giustamente comprendere il cruciale lavoro di controllo e monitoraggio votato al poter permettere un buon bilanciamento tra il continuo controllo e la fluidità delle varie operazioni.

3. Difesa in profondità

Per “difesa in profondità” si intende l’implementazione di più livelli di sicurezza per mitigare il rischio di una compromissione. Ciò vuol dire di non limitarsi ad affidare ad un singolo livello la protezione di un particolare flusso dell’applicazione ma, anzi, dare per scontato il caso in cui il primo livello non sia sufficiente e dunque prevedere una serie di controlli maggiori.

Ogni livello deve essere progettato per resistere agli attacchi anche in presenza di falle nei livelli superiori o addirittura inferiori.

Esempi possono includere firewall, autenticazioni multifattoriali e crittografia.

4. Gestione sicura degli errori

Questo principio implica che nello stato di errore dell’applicazione, ogni possibile situazione dev’essere sicura e prevista. Gli errori non devono dunque lasciare il sistema vulnerabile o aperto agli attacchi.

Un esempio potrebbe essere un sistema che nega l’accesso quando non è sicuro della validità dell’utente, piuttosto che concederlo.

5. Privilegio Minimo

Il paradigma del Privilegio Minimo stabilisce che ogni entità (utente, applicazione o processo) deve avere solamente i privilegi strettamente necessari per svolgere i suoi compiti. In questo modo si può ridurre il rischio di abusi o di danni accidentali.

Implementare questo principio richiede una gestione granulare delle autorizzazioni, limitando al minimo i permessi in base al ruolo e alle necessità operative e riducendo sensibilmente la superficie d’attacco.

Alcuni esempi classici sono la presenza di utenti “admin” o processi eseguiti con privilegi di amministratore. In questi casi la loro manomissione comporterebbe la totale perdita di controllo dell’ambiente.

6. Separazione delle competenze

Spesso confusa con il principio precedente, la separazione delle competenze prevede che funzioni critiche siano divise tra più entità o ruoli, in modo che nessuna di esse abbia un controllo completo e/o unico su tutte le fasi di un processo critico.

Scenari classici in cui si può vedere una vasta applicazione di tale separazione è l’ambito finanziario, dove spesso l’ente che autorizza i movimenti è diverso da quello che lo processa.

7. Separazione dei privilegi

La separazione dei privilegi raccomanda di dividere l’accesso privilegiato tra più utenti o processi, di modo che nessun singolo utente o processo abbia la totalità delle risorse disponibili.

Un caso pratico per quanto riguarda la separazione dei privilegi è l’utente “tutto-fare” che spesso risolve i problemi in lungo e in largo nelle aziende e che può dunque diventare un varco considerevole in caso di breccia.

8. Meccanismi minimi condivisi

Minimizzare la condivisione di risorse tra utenti o processi non correlati riduce il rischio di compromissione, poiché le risorse condivise rappresentano spesso un vettore di minacce.

Ogni entità deve disporre di meccanismi di accesso indipendenti e separati per evitare che un difetto presente in una risorsa possa essere sfruttato.

9. Semplicità dei meccanismi

“Keep it simple, stupid” l’obiettivo è dunque quello di semplificare i componenti di sicurezza riducendone la complessità in modo da limitarne il numero di vulnerabilità potenziali.

La semplicità aiuta a migliorare la trasparenza e la possibilità di revisione, dunque ridurre il rischio di errori o la manomissione da parte di malintenzionati.

10. Open Design

Questo concetto propone un approccio abbastanza diverso da quanto visto nella maggior parte degli ambienti. Si basa sull’idea che la sicurezza di un sistema non dipenda dal mantenere segreto il design ma piuttosto sull’effettiva robustezza dei suoi meccanismi di sicurezza.

Ciò non significa il dover pubblicare i propri dati ma invece assicurarsi che siano a prova di qualsiasi analisi.

11. Compromesso accettabile

Ogni sistema in fase di progettazione deve trovare il giusto bilanciamento tra protezione e usabilità. Il compromesso accettabile rappresenta il livello di rischio che l’organizzazione è disposta ad accettare in cambio di funzionalità e facilità d’uso.

12. Principio dell’anello debole

Il livello di sicurezza dell’applicazione è pari al livello del componente meno sicuro. Di conseguenza un’attenta analisi dovrebbe portare ad una consapevolezza dei livelli di sicurezza dei vari moduli e dunque incrementare uniformemente tale limite.

Conclusioni e raccomandazioni

Consapevoli del fatto che tra il dire e il fare c’è di mezzo una marea di situazioni e decisioni comprendiamo la difficoltà nel coprire tutti questi aspetti. Ciò nonostante, nell’approccio security by design il ruolo dell’esperto di sicurezza nel mondo dello sviluppo resta una posizione centrale in ogni suo aspetto. Piuttosto che renderlo una figura minacciosa, divisiva e dispensatrice di veti, sarebbe opportuno immergerlo nella fase creativa in modo da poterne sfruttare le conoscenze a pieno e costruire insieme un ambiente migliore da ogni punto di vista.