Inzio del progetto
All’inizio di un progetto bisogna seguire pochi ma importanti passi:
· Determinare se l’applicazione è coperta dal SDL
· Dichiarare un Security Advisor
· Creare un team di Security Leadership
· Creare il processo di bug-tracking, security e privacy bug
· Creare una bug bar
Utilizzare una procedura SDL non può far altro che creare benefici per il
software da sviluppare.
Comunque i software che incontrano uno o più dei seguenti criteri, ottengono
maggior beneficio:
· Utilizzano o creano dati di business: email, database etc
· Salvano, processano o comunicano personally identifiable
information (PII): dati finanziari, medici, dati sensibili, etc
· Software sempre online: instant messaging ...
· Software prodotto per andare online: browser ...
· Software esposto all’online: giochi, servizi mobili
· Prodotti con updates automatici
Nominare un responsabile che guiderà il team tramite i processi SDL,
puntando all’ottenimento del Final Security Review (vedremo nei prossimi
capitoli cos’è).
La scelta di tale figura dipende molto da come la tua azienda è strutturata.
Se l’azienda ha già un security team allora si potrebbe riutilizzare la figura
presente in quel team oppure la più capace di quel team.
È importante che la figura abbia ottime capacità nei processi di managment
dei progetti e, ovviamente, sulla sicurezza.
I suoi compiti saranno:
· Testa di ponte tra il team di sviluppo e il team della sicurezza
· Gestire i meeting di SDL con il team di sviluppo
· Gestire il design a il threat-model con il team di sviluppo
· Analisi e suddivisione dei bug di sicurezza e privacy
· Security Sounding Board
· Preparare il team di sviluppo all’FSR
· Lavorare con security team esterni
Prima della creazione del processo SDL, la comunicazione tra il gruppo di
produzione e quello della sicurezza sarà alquanto arduo. Il Security Advisor
sarà il punto di contatto del gruppo di sviluppo.
Facendone parte del gruppo di sviluppo e al tempo stesso avendo le
conoscente acquisite sulla sicurezza potrà far da traduttore tra le due aree.
Prima che lo sviluppo parta bisogna presentare gli obbiettivi e i punti chiavi
del processo SDL. Sarà al massimo una presentazione di un’ora.
Il Security Advisor dovrà parlare con il team di sviluppo riguardo il design e
dell’architettura scelta.
Dovrà controllare se:
· L’applicazione ha una piccola o inesistente superfice d’attacco
· L’applicazione usa le appropriate best practices di sviluppo
· Segue il secure design
· Il threat model è completo e riflette come il sistema si difende
· C’è un sistema appropriato di testing
I bug di sicurezza e privacy dovranno essere evidenziati durante il processe
di sviluppo e correttamente suddivisi e trattati.
Il Security Advisor indirizzerà le domande di sicurezza e privacy, ed eventuali
idee al team di sviluppo.
Dovrà anche incoraggiare ad avere e proporre nuove idee.
In Microsoft questo flusso di idee è gestito nella seguente maniera:
È un compito fondamentale dell’Advisor, ovvero esser sicuri che l’FSR sia
coperto al 100% e che tutti i fondamenti dell’SDL siano stati gestiti.
Se qualcuno d’esterno vi avverte di un bug sul vostro software, non preoccupatevi.
Quest’informazione vi farà risparmiare un sacco di tempo.
Questo team si occupa della comunicazione tra i vari team, schedulazione delle
attività etc.
I task del team includono:
· Regolare comunicazione al team di sviluppo sui bugs di sicurezza e la
privacy trovati
· Comunicazione su aggiornamenti riguardo privacy e sicurezza
Sembra solamente una montagna di parole ed email da scrivere ma, in realtà,
per grossi progetti software questo processo è ottimo per tener aggiornati i teams
su privacy e sicurezza.
È importantissimo che i bug di sicurezza e privacy vengano tracciati correttamente.
Ecco come:
· Effetto bug sicurezza/privacy
· Causa bug sicurezza/privacy
Questi, a loro volta, avranno dei valori predefiniti, effetti:
· Non ci interessa
· Spoofing
· Tampering
· Repudiation
· Information Disclosure
· Information Disclosure (privacy)
· Denial of Service
· Elevation of Privilege
· Attack Surface Reduction
Cause:
· Non ci interessa
· Buffer Overflow or Underflow
· Arithmetic Error (ex: integer overflow)
· SQL/Script Injection
· Directory Traversal
· Race Condition
· Cross-Site Scripting
· Cryptographic Weakness
· Weak Authentication
· Weak Authorization/Inappropriate ACL
· Ineffective Secret Hiding
· Resource Consumption (DoS)
· Incorrect/No Error Message
· Incorrect/No Pathname Canonicalization
· Other
Bug Bar
Bisognerà decidere che tipo di bugs si andranno a fixare durante lo
sviluppo del progetto.
Definire una Bug Bar ci chiarisce su cosa dobbiamo fixare, cosa
verrà parzialmente risolto e cosa potremmo lasciare stare.