Sicurezza delle applicazioni (REV. 1)

[Ripubblico l'articolo già uscito in novembre sulla sicurezza a livello
applicativo, grazie anche ai suggerimenti di Fabrizio Monteleone del DNV
Italia]

Quasi sempre è difficile trovare correttamente documentati i requisiti di
sicurezza delle applicazioni. Anche senza voler imporre un modello
waterfall, i troppi esempi di incidenti collegabili allo sviluppo non ben
controllato suggeriscono di documentarli in maniera coerente. Ho riscontrato
spesso la scarsità di idee su "quali requisiti considerare".

Alcuni standard (come la ISO/IEC 15408 "Common Criteria") presentano
metodologie e specifiche molto dettagliate. La ISO/IEC 15408 è una norma
divisa in 3 parti per un totale di circa 650 pagine. Sicuramente, in molte
situazioni è troppo onerosa.

La metodologia OWASP (http://www.owasp.org/) è invece orientata alle applicazioni e
ai servizi web. E' comunque consigliabile la sua lettura anche a chi si
occupa di altre tipologie di applicazioni.

Si propone qui di seguito un ulteriore ma breve elenco di requisiti da
consierare, basati sui punti dell'allegato A della ISO/IEC 27001:
- i requisiti legali applicabili
- le necessità di capacity a livello tecnologico: potenza, spazio disco e
banda di rete dedotte dal numero di utenti previsti e dalla mole di dati che
saranno coinvolti dalla loro operatività)
- le necessità di disponibilità dell'applicazione, anche in modo da disporre
delle risorse necessarie al momento del go live
- i meccanismi crittografici (inclusa la loro configurazione) da prevedere
per la connessione degli utenti e degli amministratori di sistema
- le connessioni con altre applicazioni in modo da prevedere gli opportuni
meccanismi di comunicazione sicura
- i meccanismi di identificazione e autenticazione per utenti e
amministratori (userid e password? con quali regole di complessità,
scadenza, modalità di modifica da parte degli utenti, ripristino, eccetera?)
- i meccanismi di autorizzazione per gli accessi ai dati (controllo accessi,
gestione dei ruoli e profili utente)
- i meccanismi di log (login, logout, azioni degli utenti)
- le modalità di validazione degli input (controllo dei campi di input),
degli output (messa a disposizione delle opportune query) e della loro
corretta elaborazione (con quadrature o report periodici)
- il processo di gestione del patching
- gli impatti sui sistemi di backup e sul Business Continuity Management
(impatti sui sistemi del sito di Disaster Recovery e sulle procedure di
gestione degli incidenti) in modo da aggiornarli opportunamente
- gli impatti sul service desk, in modo da aggiornare gli operatori e i loro
strumenti
- gli impatti sulla configurazione dei firewall
- gli impatti sui sistemi di monitoraggio e discovery, anche per
riconfigurarli opportunamente
- il ruolo dei fornitori, in modo da controllarli in modo adeguato

Accanto a questi requisiti più tecnici, è opportuno riflettere sulle
modalità di controllo dello sviluppo. Tra queste:
- "normali" procedure di project management: modalità di comunicazione tra
le parti interessate, pianificazione, attribuzione responsabilità per i
diversi deliverable, tempistiche per lo sviluppo e per il testing, verifiche
e riesami periodici, ...
- regole di codifica sicura (basate sulle best practices esistenti)
- regole per il debugging
- modalità di separazione delle funzioni tra i soggetti che analizzano,
progettano, codificano, testano, portano in esercizio...