In due articoli precedenti (WAPT: l’approccio blackbox e La sicurezza nelle applicazioni Web) abbiamo introdotto gli strumenti per valutare la sicurezza delle applicazioni Web. In questo articolo andremo invece ad analizzare i principi di redazione di un piano di rischio relativo all’ambito informatico.
Il rischio in ambito informatico è un concetto legato alla probabilità che un evento possa influenzare negativamente il business per cui un’infrastruttura è stata realizzata. La definizione di un piano di rischio nell’ambito web è un’operazione complessa e articolata, che prevede una profonda conoscenza del tipo di business trattato dalle web application, delle vulnerabilità e delle classi di attacco.
L’analisi e la stesura del piano di rischio non possono essere sviluppate secondo i tradizionali criteri e fattori di cui tiene conto la “security governance”, limitando la considerazione dell’analisi della frequenza e della quantità di rischi avvenuti in precedenza, ritenendo opportuno orientare il modello di rischio al business e non all’incidentalità.
Molte aziende possiedono una classificazione dei loro asset, in modo da formalizzare quali siano gli asset prioritari nel loro business. Nel caso in cui queste priorità non siano formalizzate è compito della direzione aziendale definirle.
La valutazione dei rischi dovrebbe essere un’operazione ciclica e continuativa, tale da permettere una definizione delle priorità in concretezza con l’evoluzione del business nel tempo.
RISCHIO = Probabilità di rischio * impatto sul business
Nell’identificazione della probabilità di rischio le due componenti principali sono i fattori legati alla vulnerabilità e alle figure che potrebbero sfruttare la vulnerabilità:
- Facilità di scoperta della vulnerabilità (è possibile individuarla con sistemi di scansione automatizzata?)
- Facilità di attacco (dispendioso in termini di tempo? Richiede skills elevati? Quante aree della struttura devono venire coinvolte per portare a termine l’attacco? Sono presenti tools per lo sfruttamento della vulnerabilità riscontrata? Numero di attaccanti necessari?)
- Appetibilità del dato (dati economici, dati industriali, dati personali, dati giudiziari, dati sensibili)
L’impatto sul business è caratterizzato invece da un risvolto tecnico e uno funzionale
Impatto tecnico – compromissione dell’integrità o della confidenzialità del dato
- Numero di asset coinvolti?
- L’attacco è tracciabile ai fini della sicurezza?
- Quanto tempo è necessario dedicare al ripristino dell’infrastruttura dopo l’attacco?
Impatto funzionale – danno finanziario, perdita di immagine, mancanza di segretezza, diffusione di dati personali relativi a terzi
- Sono stati trasferiti fondi economici?
- Ha impedito le vendite per un periodo considerevole?
- Ha reso impossibile l’accesso all’applicazione web in un momento cruciale per il business aziendale?
- L’attacco ha un risvolto economico nelle quotazioni aziendali?
- Sono stati acquisiti piani di produzione coperti da segreto?
- Espone l’azienda a richieste di risarcimento da parte di terzi per violazione della privacy?
Una volta definito il rischio nella probabilità e nell’impatto sugli asset rispetto alle vulnerabilità di ogni classe di attacco (code injection, source code disclosure, special characters insertions, ssi, xxs, bypassing authentication schema, bypassing authorization schema, path traversal, command injection, crittanalisi, denial of service, man in the middle, etc), è necessario assegnare un risk rating alle singole casistiche identificate durante le fasi di test. Questa operazione permetterà al gruppo di sviluppo di correggere le vulnerabilità riducendo il tempo di risoluzione tramite un indirizzamento prioritario per criticità. I valori da assegnare dovranno essere rappresentativi e chiara espressione della condizione di sicurezza dell’applicazione, ad esempio (null, low, medium, hight, critical), o tramite una scala di valori compresi in un range limitato e ben definito (1-5, 1-10).
Si renderà necessario archiviare i risultati di ogni WAPT su un database di “versioning”, inserendo:
- nome del tester
- data di verifica
- nome e versione dell’applicazione testata
- versione del report
- tools impiegati per l’analisi
- procedura dettagliata per la riproduzione di ogni evento rilevante ai fini della sicurezza rilevato
- report breve contenente link, variabile vulnerabile, tipo di vulnerabilità e attacco per il gruppo di sviluppo ed il cliente.
Il rischio nell’area business è ciò che giustifica un investimento nella sicurezza. Spesso valutazioni superficiali e poco tecniche, sottovalutano il danno arrecato in termini di immagine rispetto ai propri clienti o le proprie responsabilità nei casi in cui del materiale contenente dati personali venga reso pubblico, andando incontro a spese maggiori a incidente avvenuto.
Note sull’autore: Saverio Rizza lavora nel settore IT di un noto service provider occupandosi dell’analisi statica del codice di applicazioni enterprise. È docente di linguaggi web oriented. Ha svolto attività spaziando dai vulnerability assessment and mitigation alla scrittura di pattern di sviluppo sicuro.
