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.