Owasp Capitolo 4: i rischi legati alla progettazione e alle falle architetturali delle applicazioni
Al quarto posto troviamo una new entry freschissima. Questa particolare categoria, pone la propria attenzione sulla necessità di analizzare i rischi legati alla progettazione e alle falle architetturali, invitando all’adozione di tecniche di threat modeling, pattern per la progettazione sicura e architetture di riferimento. Spostare quindi l’attenzione e dare maggiore enfasi a una fase di pre-scrittura del codice, per implementare il concetto di Secure By Design.
La progettazione insicura è una categoria molto ampia, e contiene svariate vulnerabilità, che possono essere riassunte come assenza di controlli di sicurezza a livello progettuale. C’è una differenza sostanziale fra progettazione insicura e implementazione insicura. Le cause alla radice di questi due elementi e i relativi rimedi sono molto diversi fra loro. Un design insicuro non può essere in alcun modo fixato da una implementazione perfetta, proprio perché non sono mai stati creati i necessari controlli di sicurezza per difendersi da uno specifico tipo di attacco. Uno dei fattori che maggiormente contribuisce alla progettazione insicura, è la mancata profilazione e analisi del rischio a cui l’azienda/applicazione è esposta, e quindi l’incapacità di determinare che livello di sicurezza risulta necessario a livello di progettazione.
È necessario dunque in fase progettuale, raccogliere e negoziare i requisiti dell’applicativo con l’azienda stessa, compresi i requisiti di protezione che riguardano la confidenzialità, integrità e disponibilità dei dati e degli asset. Valutare il grado di esposizione dell’applicativo e se è necessaria una suddivisione dei tenant (in caso di multitenancy vanno implementati ulteriori controlli di accesso). Insomma un’attenta pianificazione che vada a valutare e toccare tutti i punti e possa essere messa a budget in maniera precisa e comprensiva di tutti gli aspetti, anche quelli di sicurezza.
Il codice di un applicativo va scritto tenendo a mente tutte le potenziali minacce a cui ci esponiamo, e garantire che il codice sia robusto e testato per prevenire le metodologie di attacco note. Diventa dunque fondamentale avere ben chiaro il concetto di threat modeling, e tale analisi deve essere implementata a livello di sessioni di perfezionamento (refinement sessions).
Come difendersi?
- Con professionisti di Application Security, stabilire i lifecycle di sviluppo dell’applicativo per progettare gli adeguati controlli di sicurezza e privacy
- Stabilire e usare un insieme di pattern di sviluppo sicuro, o componenti già testati e scritto in questa ottica
- Fare uso del threat modeling per le autenticazioni critiche, controllo accessi, logiche aziendali e flussi primari
- Integrare linguaggio di sicurezza e controlli nello storico degli utenti
Integrare controlli di plausibilità ad ogni layer dell’applicativo (dal frontend al backend) - Scrivere le unità e i test di integrazione, per validare che ogni flusso critico sia resistente al threat model. Creare degli use-case e dei misuse-case per ogni livello dell’applicativo
- Separare logicamente ogni livello del sistema e della rete in base al grado di esposizione e di protezione richiesti
- Stabilire una forte segregazione dei tenant su tutti i livelli
- Limitare l’uso di risorse per servizio e/o utente.
