È eccitante come discipline diverse possano essere fuse per rendere i processi più efficienti. Nel 2009, è stato coniato il termine DevOps per affrontare gli attriti tra i team di Sviluppo e Operazioni. Di conseguenza, l’industria si è orientata verso la fusione dei due team in modo che il team di sviluppo fosse responsabile dell’intero ciclo, dalla scrittura del codice al rilascio in produzione. Naturalmente, chi potrebbe comprendere meglio le complessità se non le persone che le hanno sviluppate?
Dopo questa transizione, abbiamo visto funzionalità essere spedite rapidamente e il tempo di commercializzazione per le nuove funzionalità diminuire rapidamente. DevOps ha anche servito da base per molte altre pratiche come MLOps, DataOps, GitOps e indubbiamente ne sono emerse molte altre.
Oggi parleremo di una di queste pratiche che molti di voi potrebbero conoscere chiamata DevSecOps (Development Security Operations). Quindi, cos’è DevSecOps?
La sicurezza è stata tradizionalmente considerata un’aggiunta postuma, con team che inviavano le funzionalità in produzione prima e poi si affrettavano a implementare rimedi di sicurezza durante una revisione della sicurezza o un incidente. Con l’aumento degli attacchi informatici, delle catene di approvvigionamento e di altri attacchi sofisticati, l’industria ha rapidamente capito che, come lo sviluppo e le operazioni, la sicurezza dovrebbe far parte del processo. Dovrebbe essere incorporata nel ciclo di sviluppo il prima possibile perché affrontare la sicurezza in un secondo momento può essere costoso (sia dal punto di vista dell’architettura che delle operazioni).
Ora, discutiamo di come può essere applicato nelle varie fasi del nostro ciclo di vita dello sviluppo affinché il codice che stiamo spedendo non sia solo efficiente ma anche sicuro.
Di solito, il processo di spedizione di una funzionalità comprende:
- Sviluppo – dove la funzionalità viene costruita
- Distribuzione – dove gli artefatti vengono creati e preparati per la consegna
- Implementazione – dove la funzionalità viene rilasciata nell’ambiente di produzione
Discutiamo i passi che possiamo seguire per migliorare la postura di sicurezza della funzionalità che stiamo costruendo durante la fase di sviluppo.
Nella fase di sviluppo, una funzionalità passa attraverso una revisione del design, la codifica e poi una revisione della pull request. Come parte della revisione del design, il proprietario della funzionalità discute come sono i contratti API, che tipo di database stiamo utilizzando, strategie di indicizzazione, caching, esperienza utente, e così via (non è un elenco esaustivo). Nella cultura orientata alla sicurezza, è anche importante effettuare un’analisi delle minacce.
Esegui Analisi delle Minacce
Semplicementemettiamo la modellazione delle minacce è “il processo di identificazione delle vulnerabilità, di esecuzione di una valutazione del rischio e di implementazione delle mitigazioni raccomandate affinché la postura di sicurezza dei prodotti/delle organizzazioni non venga compromessa.”
Facciamo un esempio per capire questo. Immagina di sviluppare un’API che:
- Elenca i prodotti nel tuo catalogo prodotti.
- Cerca un prodotto o un tipo di prodotto.
GET /api/products?search=laptop
Un modello di minaccia può apparire in questo modo:
| functionality | vulnerability | risk assessment | recommended mitigation |
|---|---|---|---|
| Gli utenti non autenticati possono cercare prodotti | Gli attori delle minacce possono eseguire un attacco DDoS (Distributed Denial-of-Service), sopraffacendo il database e l’infrastruttura API | Alto – Può interrompere il servizio e ridurre la disponibilità | Utilizza un API Gateway o un limitatore di velocità per prevenire attacchi DDoS. |
| L’utente inserisce una stringa di query nel campo di ricerca | Può eseguire un attacco di SQL Injection come inserire “1=1” | Alto – L’attaccante può eliminare la tabella di produzione | Assicurati che vengano eseguite adeguate convalide/sanitizzazioni sull’input. |
| L’utente riceve i dettagli del prodotto | Esporre campi interni come ID del database, codici di stato e numeri di versione potrebbe fornire agli attaccanti informazioni critiche sulla struttura del database o del sistema sottostante. | Medio – L’attaccante può utilizzare queste implementazioni interne per effettuare attacchi come la raccolta di informazioni | Invia solo i dettagli necessari per l’utente. |
Queste sono alcune cose a cui possiamo pensare quando si guardano gli endpoint del prodotto. La cosa migliore è che non è necessario essere un esperto di sicurezza per riconoscere queste vulnerabilità.
Strumenti come i tool di modellazione delle minacce di Microsoft e OWASP Threat Dragons possono aiutare a identificarle.
Esempio di un Modello di Minaccia nel Microsoft Threat Modeling Tool
Vista di Analisi
La vista di analisi dello strumento di modellazione delle minacce mostra diversi attacchi che possono verificarsi sull’API.
La revisione del modello di minaccia con il proprio team può fungere da sessione di brainstorming per identificare e mitigare il maggior numero possibile di falle di sicurezza.
- Utilizzi crittografici deboli. Ad esempio, l’uso di SHA1 o MD5 è considerato debole. CA530 è un esempio di un avviso che C# crea quando vengono utilizzate funzioni di hash deboli nel codice.
- Attacchi di SQL injection. CA2100 è un esempio che verifica se il codice è suscettibile ad attacchi di injection
- Password hardcoded, meccanismi di autenticazione e autorizzazione deboli, e errori di configurazione dell’infrastruttura possono essere rilevati con analizzatori statici.
Esistono anche strumenti esistenti in questo settore. SonarQube, CodeQL, Analizzatore Roslyn, Controllo delle Dipendenze OWASP e Snyk offrono alcune ottime soluzioni in questo settore.
Integrare l’analisi statica nei processi di build è anche importante. Offre vantaggi come:
- Un’esperienza coerente nella rilevazione delle vulnerabilità per i tuoi sviluppatori.
- Migliora la postura di sicurezza del tuo servizio perché ogni distribuzione in produzione deve passare attraverso questi passaggi.
Revisioni del Codice da un Punto di Vista della Sicurezza
Anche se le revisioni del codice tradizionalmente si concentrano sull’identificazione degli errori e sul garantire le migliori pratiche, è importante valutarlo anche da un punto di vista della sicurezza inoltre. Considerando le implicazioni di sicurezza di ogni pull request, è possibile prevenire proattivamente future minacce e salvaguardare l’integrità della tua applicazione.
Conclusione
Per concludere, con la crescente sofisticazione nel panorama della cybersecurity, è importante considerare sicurezza nelle fasi iniziali invece di lasciarla per la fine. Come parte di ciò, incorpora la modellazione delle minacce e l’analisi statica automatizzata nel tuo ciclo di sviluppo regolare.
Negli articoli futuri, discuteremo quali pratiche di sicurezza possiamo integrare durante la distribuzione, che comporta la scansione delle immagini dei container, test di sicurezza delle applicazioni dinamiche (DAST) e la firma degli artefatti per proteggere il servizio dagli attacchi alla catena di approvvigionamento.
Source:
https://dzone.com/articles/building-security-into-design-phase