Cosa significa secure by design?

Secure by design è il principio secondo cui un prodotto, hardware o software, viene progettato e costruito per essere sicuro fin dalla base, non rattoppato dopo il rilascio con correzioni aggiunte a posteriori, quando una scelta architetturale sbagliata è già stata fatta e cambiarla costa molto più tempo e denaro. Al suo fianco c'è un principio gemello, secure by default, che riguarda invece la configurazione con cui il prodotto arriva al cliente: non le scelte di progettazione, ma cosa è attivo il primo giorno, prima che qualcuno tocchi un pannello di amministrazione. I due principi sono stati promossi congiuntamente da CISA, l'agenzia statunitense per la cybersicurezza, nella guida pubblicata nel 2023, firmata da decine di produttori software, e sono oggi richiamati come requisiti essenziali di cybersicurezza dal Cyber Resilience Act per i prodotti con elementi digitali venduti nell'Unione Europea.

Leggi anche: Cyber Resilience Act (CRA) · Regolamento UE che impone requisiti di cybersicurezza obbligatori ai prodotti con elementi digitali: SBOM, notifica vulnerabilità, marcatura CE.

Progettazione contro configurazione: la differenza netta

Secure by design riguarda le decisioni prese a monte, quando si disegna l'architettura: quali protocolli usare, come isolare i componenti, come gestire i permessi tra servizi, come minimizzare la superficie d'attacco fin dal modello dei dati. Secure by default riguarda invece lo stato con cui il prodotto viene consegnato al cliente: se l'autenticazione a più fattori è già attiva o va accesa a mano, se le porte non necessarie sono chiuse o aperte per comodità, se una password predefinita esiste ancora da qualche parte. Un prodotto può avere un'architettura solida e uscire comunque con una configurazione debole, ed è per questo che i due principi vanno trattati insieme, non come sinonimi intercambiabili: uno è una qualità del progetto, l'altro è una qualità della prima esperienza d'uso.

Un esempio enterprise

Un fornitore di software collaborativo per grandi organizzazioni può consegnare la propria piattaforma con l'autenticazione a più fattori obbligatoria per ogni account amministrativo, log di accesso attivi di default e nessuna porta di gestione esposta pubblicamente senza configurazione esplicita. È l'esatto opposto di un prodotto che nasce con la sicurezza opzionale disattivata di default, magari per non complicare l'onboarding, e che lascia al singolo cliente la responsabilità di accorgersi del rischio e attivare le protezioni. Con il primo prodotto il cliente meno attento resta comunque protetto; con il secondo, la sicurezza dipende da quanto è competente e diligente chi installa il prodotto, ed è una scommessa che le grandi organizzazioni non possono permettersi di fare su centinaia di fornitori diversi.

Perché conta per chi decide

Rimediare a un difetto architetturale dopo il rilascio costa ordini di grandezza in più rispetto a progettarlo bene da subito: un problema di isolamento tra servizi scoperto in produzione spesso richiede una riscrittura, non una patch. Sotto il Cyber Resilience Act, inoltre, la sicurezza fin dalla progettazione non è più solo una buona pratica ma un requisito legale per chi vende prodotti con elementi digitali nell'UE, con responsabilità che ricadono sul produttore. Va distinto dalla privacy by design dell'articolo 25 del GDPR, un principio adiacente ma non equivalente: quello riguarda la protezione dei dati personali fin dalla progettazione del trattamento, questo riguarda la sicurezza tecnica del prodotto nel suo complesso. Nella pratica quotidiana, il principio prende forma nel DevSecOps, che integra i controlli di sicurezza nella pipeline di rilascio; ma la decisione di progettare il prodotto per essere sicuro viene prima, ed è una scelta architetturale, non uno strumento da aggiungere alla pipeline.