Ebbene si, alla fine ci si arriva: il rilascio!

Ovviamente quello che indicherò a breve vale per tutti i rilasci: Alpha, Beta, CTP, etc.

Si parte dalla parte di Planning, in cui si analizzano tutte le varie implicazioni legate alla privacy dei dati (come anche nelle fasi precedenti) e si compila il SDL Privacy Questionnarie.

Anche qui la comunicazione riveste un ruolo chiave: il Security Advisor deve avere un dialogo con il team di sviluppo su alcuni punti che potrebbero essere fonte di problemi in futuro, e si deve avere una chiara guida di deploy ben documentata.
Comprende questo anche una review a livello di implicazioni legali.
In questo momento si può anche preparare una lista di FAQ dei problemi più comuni che il team di supporto dovrà ris0lvere.

Per quanto riguarda invece la parte tecnica, ovviamente si deve disabilitare qualunque tipo di tracing/debugging, e soprattutto si deve creare un Emergency Response Plan per quanto riguarda la reazione e la risoluzione di possibili problematiche.
Nell’ERP si deve definire uno schedule di patching a seguito di situazioni di attacco che sia scollegato da eventuali Service Pack, in modo da essere il più pronti possibile in caso di grosse vulnerabilità (ricordiamo che in SDL comunicazione, training e planning rappresentano una grossa fetta del tempo speso).

Infine si può passare alla Final Security Review.
Si deve rivedere tutto il processo di sviluppo, i vari threat model che potrebbero essere applicati, validare i risultati dei tool automatici legati alla sicurezza, controllare i possibili problemi di sicurezza che sono stati rimandati o rigettati per la release attuale.
Si deve essere in grado di rimuovere le vulnerabilità dai prodotti, in sostanza. Se ci sono eccezioni vanno sottoposte al Security Advisor per una ulteriore analisi.

Il risultato finale può essere:

• Superata
• Superata con eccezioni (le eccezioni vanno riviste e pianificate)
• Escalation

Le prime due si commentano da sole, mentre l’ultima rappresenta un fallimento.
In SDL non è possibile raggiungere compromessi, quindi se il risultato è “Escalation”, la FSR fallisce ed il software non viene rilasciato ma rimandato al team di sviluppo per correzioni. Period.

In questo modo abbiamo affrontato anche l’ultima sezione di SDL

Test, test ed ancora test. Su questo si basa la fase di Verification, atta a garantire che il codice prodotto rispetti i requisiti di sicurezza definiti nelle fasi precedenti.

On top troviamo la verifica di integrità dei dati passanti nel nostro software. Perchè questo? Tempo fa scrivevo di questo assioma fondamentale di SDL:

“Customers will be empowered to control the collection, use, and distribution of their personal information. ”

Quindi i dati devono rispettare i crismi di confidenzialità ed integrità definiti dal team, senza eccezioni.

Dopo di che vi è tutta la fase di test e verifica mediante tool, che vale per ogni singolo componente della nostra soluzione. Per valutare il tutto si definisce una Security Bar che verrà poi “riempita” con i dati dello STRIDE, quelli dei tool utilizzati (MiniFuzz, Application Verifier, log di verifica del DDK, quando necessario) e quelli dei vari test “convenzionali”.

A seguito di questo si passa alla fase di Security Push, ossia il momento in cui si valuta il risultato della Security Bar, e si pianificano i possibili interventi da compiere (hotfix, piuttosto che scrivere documentazione). Il Security Push necessità di un training, sugli aspetti di analisi che verranno utilizzati nella fase stessa.
E’ un momento che porta diversi benefici al team, in quanto si può rivalutare la superficie di attacco che ha il nostro software, ad esempio.

Nel prossimo post vedremo il meccanismo di Release.

Prima o poi il codice andrà scritto, e quale migliore occasione della fase implementativa?

In questa fase oltre ad, ovviamente, implementare la soluzione software, si deve tener conto di alcune best practice durante la scrittura del codice (qui una lista esauriente, “Estabilish and Follow Best Practices for Development”) e soprattutto, su questo vorrei porre l’accento, la comunicazione che deve essere presente in ogni momento.

Ad esempio, quanta importanza diamo alla documentazione? In SDL è di fondamentale importanza, in quanto ogni dettaglio è improntato alla security e tutto il team deve esserne al corrente.

SDL si basa su una formula quasi…“matematica”:

SD³+C

dove SD sta per:

• Secure by Design
• Secure by Default
• Secure in Deployment

e la C, che sta per Communications.

La comunicazione rappresenta una componente fondamentale di SDL, in ogni sua fase. Dal rapporto con il Security Advisor fino al manuale per l’utente finale.

Altro esempio: un membro del team riesce a risolvere una problematica. Come si procede? Si documenta la issue e, se necessario, si scrive un piccolo tool “ad uso interno” rendendolo disponibile al resto del gruppo.

Può sembrare banale, ma in *tantissimi* team (io non li definirei così, but…) si continua a giocare a “Io ho i segreti e me li tengo stretti”…

Dunque, la comunicazione rappresenta una componente fondamentale di SDL. Nella prossima fase (Verification) vedremo ancora una volta come la comunicazione è fortemente presente.

Alla prossima!