Introduzione alla metodologia OpenSAMM

Introduzione alla metodologia OpenSAMM
Fra la miriade di progetti realizzati dalla community di OWASP (Open Web Application Security
Project) uno di quelli più interessanti e innovati è sicuramente OpenSAMM (Software Assurance
Maturity Model). Il progetto oltre a essere tra i principali nel sito OWASP ha anche un suo sito
ufficiale (http://www.opensamm.org/).
Figura 1. Link al progetto OpenSAMM sulla home page OWASP
Che cosa è SAMM
SAMM nasce come un modello di framework che supporti le aziende nella realizzazione di un
processo di sviluppo sicuro del software che integri al suo interno attività mirate ad aumentare
il livello di sicurezza del software intervenendo durante tutto il suo ciclo di sviluppo.
In linea di massima i principali obiettivi di un processo di Secure SDLC (Software Development Life
Cycle) sono i seguenti:
•
•
mitigare i rischi legati alle possibili problematiche dovute allo sviluppo insicuro del codice
ridurre i costi per gli interventi di correzione delle criticità di sicurezza intervenendo già
nelle fasi iniziali del processo di creazione del software (come riportato indicativamente dai
moltiplicatori della tabella sottostante)
Errori
Architetturali
Errori di
Programmazione
Errori di
Integrazione
Scoperti
nella fase di
design
Scoperti
nella fase di
sviluppo
Scoperti
nella fase di
debugging
Scoperti
nella fase di
integrazione
Scoperti in
produzione
X1
X3
X3
X5
X10
X1
X3
X5
X10
X1
X5
Tabella 1. Costi per gli interventi di correzione delle criticità di sicurezza
Da definizione degli stessi creatori di SAMM i punti di forza principali del progetto sono i seguenti:
•
•
•
•
Fornire uno strumento di valutazione degli attuali processi di
security già presenti nell’organizzazione
Costruire un programma di software security bilanciato nelle
differenti interazioni / fasi del SDLC
Avere uno strumento per poter misurare in modo concreto
l’evoluzione nel tempo del programma
Definire le attività di security da integrare nei processi aziendali e
fornire metriche per misurarne l’efficacia della loro applicazione
Cosa differisce SAMM da altri framework / metodologie
Sul mercato sono presenti diversi progetti noti di metodologie / modelli / framework di SSDLC.
Alcuni progetti condividono con SAMM la necessità di fornire uno strumento di misurazione della
maturità di processo e permettere la sua evoluzione nel tempo (ad esempio BSIMM - Building
Security In Maturity Model), altri sono più incentrati sulle attività da integrare ai processi di sviluppo
(ad esempio i Cigital’s touchpoints), altri ancora nel fornire strumenti per la gestione dei processi
(ad esempio Microsoft SDL).
Ogni progetto può avere ha pro e contro in base al contesto dove viene calato, in generale questo
perché sono spesso orientati a tipi di sviluppo diversi (ad esempio Microsoft SDL è più adatto per
lo sviluppo di programmi stand-alone), esula però dagli obbiettivi di questo articolo il voler
comparare i diversi modelli ad oggi presenti sul mercato.
In generale una delle caratteristiche vincenti del framework SAMM è la sua flessibilità, tutte le sue
indicazioni sono di alto livello e permettono principalmente la possibilità di applicarlo:
•
•
•
a diverse realtà (piccole, medie, grandi organizzazioni)
a diversi processi di SDLC (waterfall, spirale, rad, personalizzato, etc.)
a processi di sviluppo complesso (con differenti progetti e business unit) o a progetti spot
Oltre alla flessibilità, SAMM, grazie al fatto di non essere legato a vendor ed essere un progetto
open source permette:
•
•
il supporto da un ampia comunità di contributori (OWASP) sia per gli aggiornamenti dello
stesso che per la buona compatibilità con eventuali progetti futuri (ad esempio il mapping
con la ISO / IEC 27304)
evitare i classici possibili problemi di “vendor lock-in”
Figura 2. La classificazione delle Security Practices da integrare nel proprio SDLC
Le pratiche di sicurezza suggerite dal framework
Le pratiche di sicurezza da tradurre in attività da integrare nel SSDLC sono raggruppabili nei
seguenti 4 macro gruppi:
1) Pratiche di Governance. Sono incentrate sui processi e le regole con cui l'organizzazione
gestisce l’attività di sviluppo software nel suo complesso. I sotto-gruppi proposti sono:
•
•
•
Strategy & Metrics: processi comuni per l’analisi dei dati o la realizzazione di metriche per
la classificazioni dei dati.
Policy & Compliance: attività inerenti alla gestione delle policy interne o di settore,
eventuali conformità / standard di mercato o legislativi.
Education & Guidance: attività di formazione per il personale coinvolto nei processi di
sviluppo applicativo, guide e materiale formativo per uso interno all’azienda e da fornire ai
fornitori.
Rientrano in questa categoria attività come l’analisi dei rischi finalizzata alla classificazione e
alla valutazione dei rischi legati alle applicazioni, l’analisi delle policy e delle leggi a cui essere
conformi, la gestione dei processi di formazione per il personale coinvolto nel SDLC.
2) Pratiche di Construction. Sono incentrate sui processi di organizzazione precedenti alla fase
di sviluppo quali ad esempio la raccolta dei requisiti, il product management o l’analisi
architetturale. I sotto-gruppi proposti sono:
•
•
•
Threat Assessment: attività svolte con l’intento di identificare e mappare i possibili attacchi
per agevolare l’individuazione dei possibili rischi e agevolarne il trattamento.
Security Requirements: attività attuate per promuovere l’inserimento di requisiti di
sicurezza all’interno delle specifiche dell’applicazione.
Secure Architecture: attività con lo scopo di inserire controlli di sicurezza nella fase di
processo dell’architettura applicativa e nella scelta delle tecnologie da utilizzare.
In questa sezione rientrano attività quali il threat modeling, la definizione dei requisiti di
sicurezza applicativa e le policy interne sull’architettura applicativa da rispettare.
3) Pratiche di Verification. Sono incentrate sui processi relativi al controllo sullo sviluppo sicuro
delle applicazioni. I sotto-gruppi proposti sono:
•
•
•
Design Review: attività di revisione dei processi di design delle applicazioni.
Code Review: attività di revisione del codice.
Security Testing: attività di verifica sulle applicazioni in esercizio.
Attività da integrare in questo gruppo sono ad esempio la revisione del codice (automatica o
manuale), la programmazione nel tempo di attività di verifica di tipo penetration test o di attività
atte a revisionare le scelte di design applicativo.
4)
Pratiche di Deployement. Sono incentrate sui processi di gestione, manutenzione e
distruzione delle applicazioni in esercizio. I sotto-gruppi proposti sono:
•
•
•
Vulnerability Management: attività con il fine di gestire la presenza di vulnerabilità emerse
da attività di verifica interne o esterne.
Environment Hardening : processi e attività volte all’implementazioni e all’effettuazioni di
controlli sui sistemi in cui verranno messe in esercizio le applicazioni sviluppate.
Operational Enablement: attività improntate al trasferimento delle nozioni di sicurezza agli
utenti delle applicazioni per non invalidare l’intero processo di SSDLC.
Fanno parte di questa categoria attività quali “l’environment hardening”, la realizzazione di
piani di mantenimento e di patching management, il monitor degli attacchi e la costruzione di
procedure di gestione degli incidenti.
Il livello di maturità
OPEN SAMM prevede per ognuna delle famiglie sopra
descritte tre livelli di maturità differenti. La differenza fra
un livello e l’altro è specifico per ogni singola pratica (e
per la relativa traduzione in specifiche attività), tuttavia in
linea generale i vari livelli possono essere riassunti come
descritto nella tabella seguente:
Livello Descrizione
Livello Descrizione
Punto di partenza implicito (nessuna attività è
0
messa in pratica)
Inserimento base di attività ad hoc per la
1
sicurezza delle applicazioni.
Aumento dell’efficienza e/o dell’efficacia delle
2
attività.
Completo dominio delle possibili attività di
3
sicurezza integrabili.
Tabella 2. Descrizione del possibile livello di maturità
Nella figura a destra è visibile un grafico di esempio che
descrive un ipotesi di “roadmap” del processo di
SecureSDLC da implementare in 5 differenti fasi.
Il grafico descrive gli obiettivi del livello di maturità da
raggiungere in ogni fase (righe verticali) sulle diverse
aree di applicazione (righe orrizzontali).
Una volta definita la roadmap, oltre alla definizione delle
attività con cui raggiungere gli obiettivi proposti, è
importante impostare i parametri per la verifica del
raggiungimento del livello di maturità impostato.
Ad esempio per valutare il raggiungimento del livello 1
del gruppo “Education & Guidance” (che prevede
l’esecuzione di corsi di formazione al personale coinvolto
nel SDLC) si potrebbero usare le seguenti metriche:
• Almeno il 50% degli sviluppatori ha seguito un
corso di sviluppo sicuro del codice OWASP
• Tutti i project manager hanno seguito un corso
introduttivo alla sicurezza applicativa
Figura 3. Esempio di possibile roadmap
Considerazioni finali
SAMM è uno strumento decisamente utile da adottare all’interno delle organizzazioni che
vogliono definire e monitorare nel tempo il loro processo di SSDLC. La sua particolare
flessibilità permette di poter facilmente adottarlo a situazioni ed esigenze molto diverse fra loro.
La formalizzazione molto ad alto livello delle pratiche da integrare nel SDLC aziendale, non
supporta la traduzione delle stesse in attività di sicurezza puntuali. Per definire queste attività
è quindi necessaria un’analisi a parte che abbia come fine la scelta delle attività da integrare per
rispettare gli obiettivi scelti che meglio si adattino al processo di sviluppo esistente.
Alessandro Gai – Senior Security Advisor @ Mediaservice.net