A04:2021 – Insecure Design ⚓︎

Fattori⚓︎

CWEs corrispondenti	Tasso di incidenza Max	Tasso di incidenza Medio	Sfruttabilità pesata	Impatto Medio	Copertura Max	Copertura media	Occorrenze Totali	CVE Totali
40	24.19%	3.00%	6.46	6.78	77.25%	42.51%	262,407	2,691

Panoramica⚓︎

Una nuova categoria per il 2021 si concentra sui rischi legati ai difetti di progettazione e di architettura, con un appello per un maggiore uso del threat modeling, dei design pattern sicuri e delle architetture di riferimento. Come comunità dobbiamo andare oltre lo "spostamento a sinistra" nel processo di sviluppo per svolgere attività preliminari che sono fondamentali per i principi di Secure by Design. Le Common Weakness Enumerations (CWEs) incluse sono CWE-209: Generation of Error Message Containing Sensitive Information, CWE-256: Unprotected Storage of Credentials, CWE-501: Trust Boundary Violation, and CWE-522: Insufficiently Protected Credentials.

Descrizione⚓︎

Insecure design è un'ampia categoria che rappresenta diverse debolezze, espressa come "progettazione inefficace o mancante dei controlli di sicurezza". Il design insicuro non è la fonte di tutte le altre categorie di rischio nella Top 10. Design insicuro e implementazione insicura sono differenti. Distinguiamo tra difetti di progettazione e difetti di implementazione per un motivo: hanno cause e rimedi diversi. Un design sicuro può ancora avere difetti di implementazione che portano a vulnerabilità che possono essere sfruttate. Un design insicuro non può essere corretto da un'implementazione perfetta, poiché per definizione, i controlli di sicurezza necessari non sono mai stati creati per difendersi da attacchi specifici. Uno dei fattori che contribuiscono al design insicuro è la mancanza di un profilo di rischio aziendale inerente al software o al sistema che viene sviluppato, e quindi il fallimento nel determinare quale livello di security design è richiesto.

Requisiti e gestione delle risorse⚓︎

Raccogliere e negoziare i requisiti di business per un'applicazione con l'azienda, compresi i requisiti di protezione relativi a riservatezza, integrità, disponibilità e autenticità di tutte le risorse di dati e la logica di business prevista. Prendete in considerazione quanto sarà esposta la vostra applicazione e se avete bisogno della segregazione dei tenants (oltre al controllo degli accessi). Compilare i requisiti tecnici, compresi i requisiti di sicurezza funzionali e non funzionali. Pianificare e negoziare il budget che copre tutte le attività di progettazione, costruzione, test e funzionamento, comprese quelle di sicurezza.

Secure Design⚓︎

Il secure design è una cultura e una metodologia che valuta costantemente le minacce e assicura che il codice sia progettato e testato in modo robusto per prevenire attacchi conosciuti. La fase di threat modeling dovrebbe essere integrata nelle sessioni di perfezionamento (o attività simili); prestare particolare attenzione ai cambiamenti nei flussi di dati e nel controllo degli accessi o altri controlli di sicurezza. Nello sviluppo della user story determinare il flusso corretto e gli stati considerati invalidi, assicurarsi che siano ben compresi e concordati dalle parti responsabili e interessate. Analizzare i presupposti e le condizioni per i flussi attesi e non attesi, assicurarsi che siano ancora accurati e auspicabili. Determinare come convalidare i presupposti e applicare le condizioni necessarie per i comportamenti corretti. Assicurarsi che i risultati siano documentati nella user story. Imparare dagli errori e offrire incentivi positivi per promuovere i miglioramenti. La progettazione sicura non è né un add-on né uno strumento che si può aggiungere al software.

Secure Development Lifecycle⚓︎

Il software sicuro richiede un ciclo di vita di sviluppo sicuro, una qualche forma di modello di progettazione sicuro, una metodologia paved road, una libreria di componenti sicura, strumenti e threat modeling. Rivolgetevi agli specialisti della sicurezza all'inizio di un progetto software per tutto il progetto e la manutenzione del vostro software. Considerate di sfruttare il OWASP Software Assurance Maturity Model (SAMM) per aiutare a strutturare i vostri sforzi di sviluppo del software sicuro.

Come prevenire⚓︎

Stabilire e utilizzare un ciclo di vita di sviluppo sicuro con i professionisti di AppSec per aiutare a valutare e progettare la sicurezza e i controlli relativi alla privacy
Stabilire e utilizzare una libreria di design pattern sicuri o componenti pronti all'uso
Usare il threat modeling per i componenti di autenticazione più critici, il controllo dell'accesso, logica di business e flussi chiave
Integrare il linguaggio e i controlli di sicurezza nelle user stories
Integrare i controlli di plausibilità ad ogni livello della vostra applicazione (dal frontend al backend)
Scrivere test unitari e di integrazione per convalidare che tutti i flussi critici siano resistenti al modello di minaccia rappresentato. Compilare i casi d'uso e i casi di uso improprio per ogni livello della vostra applicazione.
Segregare i tier su livelli di sistema e di rete a seconda delle esigenze di esposizione e protezione.
Segregare i tenant in modo robusto by design in tutti i tier.
Limitare il consumo di risorse per utente o servizio

Esempi di scenari d'attacco⚓︎

Scenario #1: Un flusso per il recupero delle credenziali potrebbe includere "domande e risposte", che è proibito da NIST 800-63b, OWASP ASVS e OWASP Top 10. Domande e risposte non possono essere attendibili come prova di identità in quanto più di una persona può conoscere le risposte, ed è per questo che sono state proibite. Tale codice dovrebbe essere rimosso e sostituito con un design più più sicuro.

Scenario #2: Una catena di cinema permette sconti per prenotazioni di gruppo e ha un massimo di quindici partecipanti prima di richiedere un pagamento. Gli attaccanti potrebbero svolgere il threat modeling di questo flusso e testare se possono prenotare seicento posti in tutti i cinema in una volta sola con poche richieste, causando una massiccia perdita di incassi.

Scenario #3: Il sito di e-commerce di una catena di negozi non ha protezione contro i bot gestiti da scalper che comprano schede video di fascia alta per rivenderle su siti di aste online. Questo crea una terribile pubblicità per i produttori di schede video e i proprietari di catene di vendita al dettaglio e il perdurare del cattivo sangue con appassionati che non possono acquistare queste schede in nessun modo. Un'attenta progettazione anti-bot e regole di logica di dominio, come gli acquisti effettuati entro pochi secondi dalla disponibilità, potrebbero identificare gli acquisti non autentici e respingere tali transazioni.