Di necessità virtù!
Abbiamo bisogno di SDL? Dipende!
Sicuramente ci sono dei prodotti a cui una spruzzata di SDL non fa per nulla male:
· Sistemi operativi
· Database
· Server (email, ftp, etc)
· E-commerce
· Applicazioni per il business (line-of-business)
Insomma, tutte le applicazioni che trattano dati sensibili.
Quando si considera di applicare SDL a un prodotto di tipo line-of-business è importante capire l’impatto negativo che si può avere se i dati venissero letti, modificati o cancellati.
Ancora no!
Un’aspetto importante a cui SDL da una parte principale è capire quando un progetto non è pronto per la distribuzione; e in quel caso rimandarne la produzione.
Quando bisogna rimandare una produzione:
· I bugs di sicurezza, sono inacettabili e abbiamo bisogno di molto più tempo per sistemarli
· È evidente che una feature non è sufficentemente sicura e che non lo sarà mai. Bisognerà decidere se rimuoverla
· Viene scoperta una vulnerabilità ancora non catalogata (che culo). Bisogna decidere se portare il tutto in produzione o trovare la soluzione al problema.
· Il Final Security Review (FSR) fallisce.
Costi di produzione
Qualsiasi azienda prima di mettere adottare una filosofia cerca di capirne i costi di produzione.
Una domanda ovvia alla quale dovremmo rispondere è “Quanto costa adottare SDL nei nostri processi di sviluppo”.
Purtroppo non esiste una risposta specifica. Dipende.
I fattori che fanno variare il costo d’adozione dell’SDL sono:
· Iniziare un nuovo progetto adottando subito una filosofia SDL mantiene bassi i costi di produzione.
· Utilizzare SDL su un’applicazione “legacy code” (i vecchi applicativi, quando ancora la sicurezza non veniva presa in considerazione) è molto espansivo.
· Il primo rilascio in SDL paghera i costi in termini di: tempi, schedulazione azioni, etc
· SDL è facile da applicare a linguaggi che producono codice “managed”: C#, VB.NET, Java.
Ciò non significa che sono dei linguaggi sicuri ma che offrono un buon livello di sicurezza.
· Piuttosto che sistemare una feature con evidenti problemi di sicurezza, è meno costoso eliminarla se non necessaria.
· Avere degli ottimi tools che ricercano problemi di sicurezza fanno diminuire i costi rispetto ad una ricerca manuale (almeno per un 80% dei problemi)
· Un’applicazione con evidenti problemi di sicurezza avrà un costo di gestione elevato rispetto ad abbandonarne il supporto e prepararsi ad una nuova applicazione.
· Code review, tools e testing troveranno un bel pò di problemi quindi il tutto sarà più veloce e meno costoso.
Come va il progetto?
Come possiamo capire in che direzione sta andando il nostro progetto e se lo stiamo realmente sviluppando con una logica sicura?
Di seguito un elenco un elenco che ci aiuterà a seguire il nostro progetto:
· Controllare spesso il modello delle minacce stilato, e controllare non solo se sono presenti ma che effettivamente non inficiano il nostro software.
· Monitorare il livello e i tipi di bug di sicurezza trovati durante il desing, lo sviluppo e il testing,
· Controllare l’impatto di un nuovo tipo di vulnerabilità scoperto.
Tags: SDL