measures ssdlc
Informazioni sulle varie misure di sicurezza da implementare per un SDLC o SSDLC sicuro:
Con la rapida crescita della tecnologia, anche le minacce alla sicurezza di pirateria informatica e furto di dati protetti sono aumentate di conseguenza. Quindi, non c'è dubbio che la crescita della tecnologia sta gettando sfide ai produttori di software per garantire che il loro software sia forte e robusto contro le minacce alla sicurezza e le vulnerabilità.
Un prodotto software non può essere rilasciato, anche se funziona perfettamente per la funzionalità prevista a meno che non dimostri di essere altamente protetto e soddisfi gli standard di sicurezza e privacy specificati e regolamentati, in particolare in settori come Difesa, Finanza e Sanità che coinvolgono dati personali e finanziari .
Non ci si può permettere di avere un difetto di sicurezza nel prodotto quando viene distribuito, sia esso di gravità alta o media. Quindi è molto essenziale proteggere il software e i dati da qualsiasi tipo di attacco, minacce dannose, vulnerabilità e garantire l'affidabilità del software per l'utente finale.
A differenza del nostro tradizionale sviluppo del software, il test nell'ultima fase dopo che l'intero software è stato sviluppato non è più efficace. Con l'implementazione del concetto Agile, DevOps e ShiftLeft, è essenziale eseguire i test all'inizio e in ogni fase del ciclo di vita dell'applicazione.
Detto questo, la sicurezza del software non può essere costruita o nemmeno testata nell'ultima fase e quindi deve essere costruita in ogni fase per garantire la totale sicurezza del software.
Cosa imparerai:
Misure di sicurezza per SSDLC
Di seguito sono elencati i vari mezzi di misure relative alla sicurezza che possono essere implementati durante il ciclo di vita dello sviluppo del software al fine di garantire Secure SDLC o SSDLC e, per quanto possibile, i difetti non possono essere portati avanti alla fase successiva.
Le varie analisi e valutazioni della sicurezza in cui la sicurezza deve essere costruita nelle fasi SDLC sono.
- Fase dei requisiti
- Fase di pianificazione
- Fase di architettura e progettazione: Valutazione del rischio per la sicurezza basata sul progetto.
- Fase di sviluppo: Secure Code Analysis, un'analisi statica del codice per la sicurezza.
- Fase di implementazione: Analisi dinamica del codice, un test di sicurezza delle applicazioni.
- Test - Fase di pre-distribuzione: Penetration Testing e Analisi delle Vulnerabilità.
# 1) Fase dei requisiti
- In primo luogo, al fine di garantire che le misure di sicurezza necessarie siano integrate nel software, Requisiti specifici relativi alla sicurezza devono essere chiaramente acquisiti durante la fase dei requisiti con sufficienti dettagli e risultati attesi.
- Pur identificando i casi d'uso tipici e gli scenari aziendali, una chiara serie di Casi d'uso e scenari relativi alla sicurezza a scopo di verifica devono essere identificati al fine di acquisire le caratteristiche di sicurezza e progettare scenari di test di sicurezza.
Di seguito sono riportati alcuni esempi di esempio che illustrano i requisiti espliciti relativi alla sicurezza che possono essere acquisiti.
Sec-Req-01: Il sistema deve disporre di misure di autenticazione in tutti i gateway e punti di ingresso.
Sec-Req-02: Il sistema deve implementare l'autenticazione tramite una schermata di accesso sicura.
Sec-Req-03: I DATI PERSONALI devono essere crittografati a riposo.
# 2) Fase di pianificazione
Ad un livello elevato, ma non solo limitato a questi, i seguenti punti devono essere trattati nella fase di pianificazione.
siti Web che ti consentono di scaricare video di YouTube
- Un forte, Team di sicurezza dedicato , funzionante al di fuori del PMO (project management office) del team del programma, composto da Responsabile della sicurezza, architetti della sicurezza, tester della sicurezza essere formati per svolgere e gestire in modo imparziale tutte le attività legate alla sicurezza del programma. Per ciascuno di questi ruoli, sono definiti un chiaro RnR (ruoli e responsabilità) e RACI.
- Qualunque escalation, ambiguità relative alle questioni di sicurezza devono essere gestite dal PSO (Product Security Officer) in modo che il team di sicurezza funzioni senza intoppi e aiuti a prendere le giuste decisioni.
- Un robusto Strategia di test di sicurezza specificare come implementare i requisiti relativi alla sicurezza, come, quando e cosa testare, quali strumenti dovrebbero essere utilizzati in ogni fase, deve essere identificato.
- È obbligatorio coinvolgere il Punto di contatto per la sicurezza per tutte le discussioni tecniche / di revisione relative al programma in modo che il team di sicurezza sia a conoscenza di eventuali modifiche che avvengono al programma.
# 3) Architettura e fase di progettazione
Prestare maggiore attenzione agli aspetti di sicurezza nella fase di progettazione durante la fase di progettazione aiuterà a prevenire i rischi per la sicurezza ea ridurre considerevoli sforzi nelle modifiche alla progettazione successive nell'SDLC.
Durante la progettazione del software e dell'infrastruttura su cui verrà ospitato il software, tutto è possibile Implementazioni di progettazione della sicurezza devono essere ben progettati con il coinvolgimento degli architetti della sicurezza.
Eventuali ambiguità e conflitti tra gli aspetti funzionali e non funzionali del design e dell'architettura devono essere risolti attraverso sessioni di brainstorming che coinvolgono gli stakeholder giusti.
Durante questa fase, una valutazione dettagliata del rischio per la sicurezza del prodotto, che a volte viene anche chiamata 'Valutazione statica' deve essere effettuato dal team di esperti di sicurezza.
Valutazione del rischio per la sicurezza include una revisione dei programmi dal punto di vista della sicurezza nella fase di progettazione / architettura preliminare per identificare i difetti relativi alla sicurezza dal punto di vista della progettazione e di conseguenza sollevare il prodotto Rischi per la sicurezza al team di progetto per affrontarli ed evitare di entrare nella fase successiva.
Queste valutazioni vengono eseguite sulla base delle linee guida, degli standard e dei controlli di sicurezza aziendale / industriale delineati in tali documenti. Per esempio. UXW 00320, UXW 030017
Durante la valutazione del rischio per la sicurezza del prodotto:
come aprire il file jar con l'ambiente di runtime java
- Requisiti, funzionalità, storie degli utenti e relativi documenti di progettazione vengono esaminati, in base ai dettagli, agli artefatti condivisi dal team di progetto, Per esempio. Documenti di progettazione (HLDD e LLDD). Le valutazioni comportano anche discussioni con i membri del team di progetto interessati in caso di assenza di documenti o per chiarire eventuali dubbi.
- Le lacune vengono identificate durante la mappatura dei requisiti di sicurezza del programma rispetto agli standard stabiliti e ad altre best practice. A volte vengono sviluppati anche modelli di minaccia basati sulle lacune individuate.
- Queste lacune sono identificate come potenziali rischi per la sicurezza che includono anche il suggerimento di possibili mitigazioni per l'implementazione, vengono sollevati e gestiti.
- Una volta che queste mitigazioni sono state implementate dal team di progetto, vengono verificate per la chiusura tramite casi di test appropriati progettati dal team di System Test.
- La matrice di gestione del rischio, che fornisce la tracciabilità, è preparata per tenere traccia di questi rischi. L'approvazione e la firma con il rischio residuo saranno prese dal Security Architect e dal PSO.
I modelli di minaccia tipici identificati nella fase di progettazione sono correlati alla convalida dell'input, alla gestione di audit / log, alle configurazioni e alle crittografie. L'identificazione dei rischi include l'attacco di vulnerabilità come password deboli, attacchi semplici di forza bruta, ecc.
Le revisioni tipiche includono i rischi relativi all'accesso ai dati personali, all'accesso agli audit trail, alla whitelist di entità, alla pulizia dei dati e all'attività di cancellazione.
Gli scenari di test di esempio includono:
- Vulnerabilità di overflow del buffer: Per garantire che, eseguendo manualmente il fuzzing dei parametri, non dovrebbe essere possibile rallentare il server e forzare il server a non rispondere (Denial of Service).
- Sanificazione dei dati: Per garantire che venga eseguita un'adeguata sanificazione dei dati per ogni input e output in modo che l'aggressore non possa iniettare e archiviare il contenuto dannoso nel sistema.
# 4) Fase di sviluppo
Analisi del codice sicura è un Valutazione del codice statico metodo utilizzato per valutare il Codice di sicurezza delle varie funzionalità del software utilizzando uno strumento di scansione automatizzato. Esempio: Fortificare.
Questa analisi viene eseguita su ogni check-in / build del codice per scansionare il codice generato per le minacce alla sicurezza. Questa valutazione viene generalmente eseguita a livello di User Story.
- Fortify scansioni tramite plug-in deve essere installato sui computer dello sviluppatore.
- Fortify deve essere integrato con il modello di build.
- La scansione automatizzata verrà eseguita su tutte le build su base giornaliera.
- Il risultato della scansione verrà analizzato dal team di sicurezza per falsi positivi.
- I difetti identificati da questa valutazione vengono rilevati e gestiti fino alla chiusura, in modo che le infiltrazioni siano minimizzate / azzerate al livello successivo.
Gli scenari di test di esempio includono:
- Per garantire che i dati sensibili non vengano inviati in testo normale durante la trasmissione dei dati.
- Per garantire una trasmissione sicura dei dati, le API rivolte verso l'esterno devono essere distribuite su un canale HTTPS.
# 5) Fase di implementazione
Analisi dinamica del codice non è altro che Application Security Testing, che è anche chiamato test OWASP (Open Web Application Security Project). La Vulnerability Analysis and Penetration Testing (VAPT) deve essere eseguita nella fase di implementazione / test.
Questa analisi valuta i file binari e alcune configurazioni di ambiente e rafforza ulteriormente il codice per i requisiti di sicurezza.
Come parte di questa analisi, il Comportamento dinamico o le funzionalità di varie caratteristiche dei programmi vengono analizzate per le vulnerabilità legate alla sicurezza. I casi d'uso previsti e gli scenari aziendali vengono utilizzati anche per eseguire l'analisi dinamica del codice.
Questa attività viene eseguita su Build di prova utilizzando vari strumenti di sicurezza con un approccio automatizzato e manuale.
- Gli strumenti HP WebInspect, Burp Suite, ZAP e SOAP UI vengono generalmente utilizzati per controllare le vulnerabilità rispetto ai database di vulnerabilità standard ( Esempio: OWASP Top 10 )
- Questa attività, tuttavia, è principalmente automatizzata, a causa di alcune limitazioni degli strumenti, potrebbe essere necessario del lavoro manuale per valutare i falsi positivi.
- Idealmente, questa operazione viene eseguita in un ambiente separato (System Testing Environment), in cui viene distribuito il software pronto per il test.
- Le vulnerabilità devono essere sollevate e portate alla chiusura con le mitigazioni suggerite.
I modelli di minaccia tipici identificati durante questa analisi sono correlati alla convalida dell'input, all'autenticazione interrotta e alla gestione delle sessioni, all'esposizione dei dati sensibili, XSS e alla gestione delle password.
Gli scenari di test di esempio includono,
- Gestione delle password: Per garantire che le password non siano memorizzate in testo normale nei file di configurazione o in qualsiasi parte del sistema.
- Perdita di informazioni di sistema: Per garantire che le informazioni di sistema non vengano trapelate in nessun momento, le informazioni rivelate da printStackTrace potrebbero aiutare l'avversario da un piano di attacco.
# 6) Test - Fase preliminare all'implementazione
Test di penetrazione , Pen Test in breve e Infra VAPT (Analisi delle vulnerabilità e Penetration Testing) , è il test olistico in piena regola con soluzione completa e configurazioni (inclusa la rete) che è idealmente fatto in un ambiente di pre-produzione o simile alla produzione.
Ciò viene eseguito principalmente per identificare le vulnerabilità del database e delle vulnerabilità del server insieme a qualsiasi altra vulnerabilità. Questa è l'ultima fase del test di sicurezza che verrebbe condotta. Quindi questo include anche la verifica dei difetti e dei rischi segnalati in precedenza.
- Strumenti come Nessus, Nmap, HP Web Inspect, Burp Suite, ZAP disponibili sul mercato vengono utilizzati per eseguire il test Pen.
- Durante questo test viene eseguita la scansione delle applicazioni web utilizzando strumenti automatizzati e sfruttamento per ulteriori verifiche. Il test viene eseguito per simulare il comportamento del vero attaccante e quindi può includere anche alcuni test negativi.
- Vulnerabilità dell'infrastruttura la valutazione include la scansione, l'analisi e la revisione della configurazione della sicurezza dell'infrastruttura (reti, sistemi e server) per identificare le vulnerabilità e verificare la resilienza contro gli attacchi mirati.
- Questa operazione viene eseguita in un ambiente di pre-produzione o simile alla produzione, in cui il software pronto per la distribuzione viene testato e quindi simula l'ambiente in tempo reale.
- Le vulnerabilità vengono identificate utilizzando sia scanner che tecniche manuali per eliminare i falsi positivi. Inoltre, durante i test manuali verranno eseguiti scenari di business in tempo reale.
- Verrà prodotto un report finale sull'intera analisi della sicurezza che viene eseguita per l'intero programma, evidenziando lo stato delle voci ad alto rischio, se presenti.
Gli scenari di test di esempio includono,
- Per garantire che i metodi HTTP vulnerabili non siano abilitati.
- Per garantire che le informazioni sensibili degli altri utenti non siano visibili in chiaro sulla rete.
- Per garantire che la convalida per il caricamento dei file sia implementata per evitare il caricamento di un file dannoso.
Riepilogo tabellare per SSDLC
La tabella seguente riassume i diversi aspetti dell'analisi della sicurezza spiegati sopra.
Fase SDLC | Analisi chiave eseguita | Cosa viene fatto esattamente in queste valutazioni | Ingresso | Strumenti utilizzati | Produzione |
---|---|---|---|---|---|
Requisiti | Per garantire che i requisiti di sicurezza vengano acquisiti in modo efficiente. | I requisiti vengono analizzati. | Documenti dei requisiti / User story / Funzionalità | Manuale | I requisiti di sicurezza sono integrati nelle specifiche dei requisiti. |
Pianificazione | Team di sicurezza da istituire Strategia di test di sicurezza preparata. | Squadra identificata e costituita. Strategia preparata, rivista e approvata con gli stakeholder. | Nessuno | Manuale | Configurazione del team di sicurezza con RnR e RACI definiti. Documento sulla strategia del test di sicurezza firmato. |
Design | Valutazione del rischio per la sicurezza | Revisione dei documenti relativi al programma per identificare i difetti di sicurezza. Discussione con il team. I rischi vengono identificati e vengono suggeriti quelli di mitigazione. | Documenti relativi al progetto: HLDD, LLDD. | Revisione manuale | Rischi di progettazione identificati. Matrice di gestione del rischio con mitigazioni suggerite. |
Sviluppo | Analisi del codice sicuro (valutazione statica) | Gli scanner di sicurezza sono collegati ai computer dello sviluppatore. Strumento di sicurezza integrato con il modello di build. | Codice sviluppato | Automatizza gli scanner (Fortify). Triage manuale dei falsi positivi. | Difetti del codice protetti. Matrice di gestione del rischio con mitigazioni. |
Implementazione | Analisi dinamica del codice (valutazione dinamica) | Test di sicurezza dell'applicazione eseguito. | Costruzione testata in unità Ambiente di test dedicato | Strumenti di test di sicurezza (HP WebInspect, Suite Burp, ZAP Triage manuale dei falsi positivi. | Difetti dinamici dell'analisi del codice. Matrice di gestione del rischio con mitigazioni. |
Test / pre-distribuzione | Pen Test, Infra VAPT | Penetration test e Infra VAPT utilizzando scenari in tempo reale. Verifica dei rischi / difetti segnalati in precedenza. | Pronto per distribuire build. Pre-produzione o produzione come l'ambiente. | Strumenti di test di sicurezza (Nessus, NMAP, HP WebInspect) Triage manuale dei falsi positivi. | Matrice di gestione del rischio con mitigazioni. Rapporto finale sul test di sicurezza con lo stato del rischio. |
Conclusione
Pertanto, con l'implementazione di tutti questi aspetti relativi alla sicurezza integrati nelle varie fasi dell'SDLC, aiuta l'organizzazione a identificare i difetti di sicurezza nelle prime fasi del ciclo e consente all'organizzazione di implementare mitigazioni appropriate, evitando così il Difetti di sicurezza ad alto rischio nel sistema live.
Lo studio mostra anche che la maggior parte dei difetti di sicurezza sono indotti nel software durante la fase di sviluppo, cioè durante il Fase di codifica , in cui la codifica non ha curato sufficientemente tutti gli aspetti di sicurezza, per qualsiasi motivo.
Idealmente, nessuno sviluppatore vorrebbe scrivere un codice errato che comprometta la sicurezza. Pertanto, al fine di guidare gli sviluppatori su come scrivere un software sicuro, il tutorial in arrivo copre Migliori pratiche e linee guida di codifica per gli sviluppatori, per garantire una migliore sicurezza del software.
Speriamo che questo tutorial su Secure SDLC o SSDLC sia stato utile !!
Lettura consigliata
- Fasi, metodologie, processi e modelli di SDLC (Software Development Life Cycle)
- 10 migliori strumenti di test per la sicurezza delle app mobili nel 2021
- 19 potenti strumenti di penetration test utilizzati dai professionisti nel 2021
- Linee guida per i test di sicurezza delle app mobili
- Test di sicurezza di rete e migliori strumenti di sicurezza di rete
- Test di sicurezza (una guida completa)
- I 4 migliori strumenti di test di sicurezza open source per testare l'applicazione Web
- Guida al test di sicurezza delle applicazioni Web