Sunday, October 4, 2009

SDL (Parte 3: Ho bisogno di SDL?)v

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.

No comments:

Post a Comment