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”.
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.
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