Risk assessment per lo sviluppo sicuro del software: come lo facciamo, in dettaglio

In Intesys, siamo consapevoli sia dell’impatto determinante del software sul business aziendale, sia delle innumerevoli minacce che lo circondano. Non a caso, su queste pagine abbiamo affrontato più volte il tema dello sviluppo sicuro del software, sottolineando quanto faccia parte del nostro DNA. Oggi, ci concentriamo e approfondiamo il tema del risk assessment.

Cosa significa risk management nei progetti software?

Il nostro approccio alla sicurezza delle applicazioni si basa su paradigmi innovativi come Defense in Depth e Security by Design. Quest’ultimo, in particolare, mira a integrare misure tecniche di sicurezza, ma anche metodologiche e di processo, in ogni fase del ciclo di vita del software (SDLC). In questo modo, possiamo realizzare soluzioni che soddisfano sfidanti requisiti funzionali e prestazionali, ma che sono anche resilienti rispetto a un vero e proprio ecosistema di minacce.

Il terreno su cui ci muoviamo è quello del risk management, un pilastro di ogni progetto software, nonché una delle principali responsabilità del project manager. Nel contesto dello sviluppo applicativo, il concetto di rischio non è infatti limitato alla sicurezza del software, e quindi a tutti i fattori esterni e interni che la minacciano, ma abbraccia tutti quegli elementi che possono causare deviazioni rilevanti rispetto agli obiettivi iniziali del progetto, siano essi legati a tempistiche, costi o qualità del deliverable finale. Tra i rischi rientrano quindi ritardi nelle scadenze, stime di costo imprecise, carenza di risorse e turnover di competenze chiave.

I security risk meritano però un’attenzione particolare, e soprattutto richiedono delle competenze altamente specializzate per essere indirizzati in modo corretto. In progetti di una certa dimensione, riteniamo quindi più che opportuna la presenza di un ruolo dedicato, il Software Security Manager (SSM), che si occupa – tra l’altro – di eseguire l’analisi dei rischi e di identificare i requisiti di sicurezza per i singoli progetti. In Intesys, l’SSM è una risorsa chiave per la buona riuscita delle nostre attività.

Leggi il nostro documento metodologico di Sviluppo Software Sicuro:

Risk assessment: lo sviluppo sicuro del software parte da qui

In un progetto software, la gestione del rischio, questa volta di qualsiasi natura, si suddivide in due macro-processi: il risk assessment e il risk control. A sua volta, il primo (di cui ci occupiamo in questa sede) consta di tre attività chiave:

1. L’individuazione dei rischi;
2. L’analisi dei rischi;
3. Lo scoring e definizione delle priorità d’intervento;

Il risk assessment è determinante per lo sviluppo sicuro del software. Riteniamo infatti che non possa esistere un’applicazione sicura in termini assoluti, ma solo ed esclusivamente in forma relativa alle minacce concretamente esistenti, che a loro volta dipendono dal contesto, dal tipo di applicazione e dalle tecnologie adottate, ma anche dall’azienda, dai suoi obiettivi e dal settore in cui opera. Al di là di alcune misure base di protezione, che adottiamo in qualsiasi progetto software, le soluzioni più evolute vanno valutate caso per caso sulla base dell’ecosistema delle minacce, della probabilità che si concretizzino e delle conseguenze attese. È un’attività molto complessa, che richiede appunto delle competenze ad hoc e una corposa fase di analisi, ma è anche l’unica strada possibile per far sì che il risultato finale bilanci perfettamente performance, funzionalità e sicurezza, nonché tempi e costi.

Individuazione delle minacce: il metodo STRIDE

La prima fase di un risk assessment finalizzato allo sviluppo di codice sicuro è l’individuazione e la modellazione delle minacce (threat modeling). Data la vastità del tema e la sua evoluzione pressoché quotidiana, bisogna affidarsi a un framework, o meglio a un modello di riconosciuta efficacia. Nel nostro caso, adottiamo il modello STRIDE, di cui abbiamo già parlato in un precedente articolo sul tema sistema informatico sicuro e che suddivide le minacce in sei dimensioni o categorie:

Perché, e soprattutto come analizziamo il rischio

Al di là di STRIDE, un aspetto su cui vogliamo soffermarci è la metodologia che adottiamo per analizzare il rischio e per costruire la matrice impatto-probabilità.
Questa fase, che di fatto corrisponde al secondo e al terzo punto del processo di risk assessment descritto precedentemente, è essenziale perché ci permette di comprendere quali siano le misure di sicurezza (livelli medio e alto) cui attingere dalle nostre Linee Guida per lo Sviluppo di Software Sicuro (LGSSS) e applicare poi in concreto.

Consulta le nostre Linee Guida per lo Sviluppo di Software Sicuro (LGSSS)

Come calcoliamo, dunque, la probabilità che un rischio si concretizzi, ovvero che si verifichi l’evento dannoso? Come giungiamo alla conclusione che esso abbia un indice basso, medio o alto di verificarsi? La competenza e l’esperienza su diversi progetti hanno un ruolo molto importante in tal senso, ma anche qui c’è bisogno di un framework di valore a cui riferirsi, come la OWASP Risk Rating Methodology.

Secondo questa metodologia, la probabilità che si verifichi l’evento si calcola in due fasi: prima, identificando chi potrebbe avere interesse e capacità a concretizzarla, ovvero il Gruppo dei Threat Agent, e poi assegnando dei punteggi (da 1 a 3) a diversi TAF, ovvero a dei Threat Agent Factor. In particolare, a:

• Il livello di competenza tecnica necessaria per concretizzare la minaccia;
• La motivazione che spinge il Gruppo a procedere;
• Le opportunità disponibili;
• La dimensione del Gruppo di Threat Agent.

Una semplice somma dei valori numerici attribuiti nell’analisi determina l’effettiva probabilità (bassa, media o alta) che l’evento, e quindi la minaccia, si verifichino.

L’altra dimensione fondamentale della matrice di risk assessment è l’impatto della minaccia. Lo calcoliamo in modo analogo al precedente, ovvero assegnando un valore (da 1 a 3) alle possibili conseguenze dell’attacco su 4 dimensioni specifiche, sommando poi i valori e distribuendo il risultato su tre livelli di rischio (basso, medio, alto). Le quattro dimensioni sono:

• Perdita di profitto;
• Danno reputazionale;
• Sanzioni e spese legali;
• Costi di ripristino.

Alla fine, è sufficiente riportare l’esito nella matrice per ottenere il livello generale di rischio per ogni minaccia STRIDE, da cui deriviamo non solo le misure tecniche da adottare, ma anche la priorità di intervento.

E questo è solo l’inizio per lo sviluppo sicuro del software

L’analisi dei rischi di sicurezza, come anticipato, non è un’attività fine a sé stessa, ma va integrata in un ciclo di vita che consideri la sicurezza del software come elemento costitutivo. Questo ci ha portato a standardizzare i processi di sviluppo, ad adottare il più possibile l’automazione, a condurre analisi statiche del codice e, cosa tutt’altro che secondaria, ad applicare le nostre Linee Guida per lo Sviluppo di Software Sicuro in modo sartoriale e non standardizzato. In fondo, un risk assessment ben fatto serve esattamente a questo: a capire cosa serve davvero e ad applicarlo tempestivamente, nella certezza di non disperdere tempo e budget su attività a scarso valore.