Anche il software e gli applicativi mediante i quali vengono trattati dati personali devono essere conformi ai principi di privacy by design: in questi casi, una delle “garanzie” che viene sovente individuata è l’effettuazione e la documentazione delle tecniche e dei cosiddetti controlli OWASP per la qualità del codice.
Indice degli argomenti
Tecniche OWASP per la qualità del codice e GDPR
A conferma di ciò è sufficiente un’attente lettura del GDPR. Il Regolamento UE 2016/679 relativo alla privacy e alla protezione dei dati personali, infatti, fra i vari adempimenti richiede alle organizzazioni rispettare il principio della “privacy by design” o di “protezione dei dati fin dalla progettazione”.
Citando l’art. 25 comma 1 del GDPR: “Tenendo conto dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’ambito di applicazione, del contesto e delle finalità del trattamento, come anche dei rischi aventi probabilità e gravità diverse per i diritti e le libertà delle persone fisiche costituiti dal trattamento, sia al momento di determinare i mezzi del trattamento sia all’atto del trattamento stesso il titolare del trattamento mette in atto misure tecniche e organizzative adeguate, quali la pseudonimizzazione, volte ad attuare in modo efficace i principi di protezione dei dati, quali la minimizzazione, e a integrare nel trattamento le necessarie garanzie al fine di soddisfare i requisiti del presente regolamento e tutelare i diritti degli interessati”.
In pratica, i titolari del trattamento non dovrebbero introdurre nuove operazioni di trattamento o lanciare sul mercato servizi se questi non risultano, fin dalla progettazione, conformi alle disposizioni in materia di privacy e data protection.
Per questo motivo, sempre più organizzazioni che esternalizzano la realizzazione di software o affidano a terzi trattamenti informatici di dati personali, richiedono ai loro fornitori e responsabili del trattamento adeguate garanzie sulla sicurezza degli applicativi come, appunto, quelle fornite dai controllo OWASP.
Anche l’AGID, l’Agenzia per l’Italia Digitale, al fine di rilasciare alle aziende le qualificazioni per SaaS (Software as a Service) e CSP (Cloud Service Provider), necessarie a offrire servizi informatici alle pubbliche amministrazioni, richiede agli attuali (o futuri) fornitori della PA di eseguire i controlli OWASP sul codice.
Da qui l’attenzione sempre crescente verso il framework OWASP e tutti i tool che stanno facendo il loro ingresso sul mercato per aiutare sviluppatori e manager nella verifica della stabilità e sicurezza dei software, oltre che diffondere una cultura che stenta a diventare un pilastro nella continua evoluzione dell’informatica.
Cos’è l’OWASP e qual è il suo scopo
L’Open Web Application Security Project è un progetto open-source nato nel 2001 con lo scopo di diffondere la cultura della qualità del codice nelle fasi di sviluppo di un software. Negli anni, la community OWASP ha prodotto articoli, metodologie, documenti e tool per supportare gli sviluppatori nella realizzazione di software e applicazioni sicure.
Recentemente, l’OWASP ha indicato le 10 principali minacce che possono comprometterne la sicurezza. Tra le più importanti compare la famiglia delle “code injection” (SQL Injection, LDAP injection o CRLF injection) ovvero quando l’attaccante tenta di forzare l’inserimento di stringhe di codice eseguibile all’interno dell’applicativo.
Tutti possono accedere al materiale messo a disposizione dal sito ufficiale. La Community OWASP ha redatto delle linee guida per lo sviluppo sicuro degli applicativi web, grazie alla collaborazione di moltissimi professionisti del settore.
I controlli OWASP sul codice sono annoverati tra le best practice riconosciute a livello internazionale nell’ambito della prevenzione di vulnerabilità di sicurezza e, se applicati correttamente, possono ridurre di considerevolmente il rischio di data breach (violazioni dei dati) causati da eventuali incidenti informatici favoriti dalla scarsa qualità del codice di software e applicazioni.
L’adozione dei controlli OWASP però, oltre a essere considerata una best practice facoltativa, in alcuni contesti sta progressivamente diventando un requisito obbligatorio. L’entrata in vigore del GDPR ha accelerato questo processo.
L’OWASP pubblica e aggiorna periodicamente una guida ai controlli sul codice dalla metà degli anni 2000. La guida è giunta alla versione 4 (pubblicata nel 2014), ma il gruppo di volontari, composto da decine di specialisti di programmazione e cybersecurity, sta lavorando alla versione 5 (è possibile trovare maggiori informazioni e seguire gli aggiornamenti all’indirizzo su GitHub).
Quali sono i principi dell’OWASP
Entriamo nel dettaglio cercando di analizzare tutti i principi che propone il framework OWASP. Partendo da quello che forse è il più banale ma più importante, ovvero che la sicurezza è un processo, complesso e costante nel tempo, e non un prodotto.
È sicuramente molto comodo sia per una questione di costi che per una semplificazione del processo, pensare che uno scanner di vulnerabilità e un firewall garantiscano una efficace e rapida protezione contro la quasi totalità delle vulnerabilità.
Così non è. Infatti, i software utilizzati per i vulnerability assessment sono soltanto il primo gradino di una scala che va percorsa in tutta la sua profondità per garantire livelli di sicurezza adeguati.
L’OWASP propone la sostituzione del vecchio concetto di correzione della singola vulnerabilità tramite patch, senza andare ad indagare approfonditamente la causa di quella vulnerabilità. La sicurezza viene analizzata ed integrata nel ciclo di vita del software (SDLC – Software Development Life Cycle) per evitare il propagarsi e ripetersi di vulnerabilità all’interno di un’applicazione.
Integrare l’analisi della sicurezza nell’SDLC ci collega ad un altro principio dell’OWASP e del buon senso, ovvero che scovare un bug all’inizio del ciclo di vita del software permette una soluzione più rapida e meno costosa lavorando ad un livello di complessità inferiore (test early and test often).
La domanda, a questo punto, nasce spontanea: se non esiste lo strumento universale per trovare le vulnerabilità, cosa si deve utilizzare?
Esistono moltissimi prodotti, commerciali e open source, che possono aiutare lo specialista ad automatizzare moltissime attività e velocizzarle. In questo contesto è importante capire esattamente cosa possono e non possono fare i singoli strumenti scelti per evitare che vengano utilizzati in modo errato o incompleto. È importante, utilizzando diversi software e strumenti, tenere traccia dei risultati e dei test effettuati per sviluppare delle metriche che permettano allo specialista di tracciare la tendenza al miglioramento della sicurezza dell’applicazione analizzata.
La metrica deve permettere allo specialista o al team coinvolto nelle analisi di verificare che il numero delle vulnerabilità scende proseguendo nelle analisi. Il progetto OWASP Metrics fornisce alcune metriche standard per supportare il processo di analisi senza arenarsi nel difficile compito di ricavare delle metriche personalizzate da zero.
Se le metriche aiuteranno a verificare il costante miglioramento della salute del software in tutto il ciclo di sviluppo, la documentazione dei risultati dei test passo per passo, permetterà di tenere traccia di tutte le verifiche effettuate e di condividere con tutti gli attori coinvolti nello sviluppo lo stato dell’arte delle verifiche di sicurezza.
Le tecniche OWASP per la qualità del codice: programma di test
L’obiettivo di questo articolo non è e non può essere sicuramente quello di entrare nel dettaglio degli 87 controlli indicati nella versione 4 della guida OWASP e che verranno ulteriormente incrementati con l’uscita della nuova versione.
Lo scopo è infatti è quello di fornire al lettore alcuni dettagli su cosa sia il framework OWASP, riportando una panoramica su quattro tecniche di test che possono essere utilizzate nella costruzione di un processo di verifica della qualità del codice.
- Manual Inspections & Reviews. Le Manual Inspections & Reviews sono condotte utilizzando la documentazione a supporto del software o coinvolgendo direttamente gli sviluppatori e gli ideatori della struttura architetturale del software. La tecnica prevede la raccolta di informazioni su processi, servizi e tecnologie utilizzati, ai fini di quantificare la probabilità che emergano problemi di sicurezza ed effettuare i relativi controlli. Tale tecnica è importante per comprendere a fondo se le persone coinvolte nello sviluppo hanno compreso e implementato il processo di sicurezza durante la progettazione e lo sviluppo del software. Tra i vantaggi di questa tecnica si considera il fatto che non richieda un programma a supporto, può essere applicata a varie situazioni ed è particolarmente flessibile. Coinvolge tutto il team e si effettua tendenzialmente già all’inizio del ciclo di vita dello sviluppo del software con tutti i vantaggi che comporta l’approccio del “test early test often”, di cui abbiamo parlato in precedenza. Sicuramente alcuni dei punti deboli di tale tecnica sono dati dal fatto che l’implementazione richiede molto tempo, non sempre il materiale a supporto (manuali, commenti, schemi) è disponibile e l’inesperienza di chi conduce le verifiche può portare all’inefficacia delle stesse.
- Modellazione delle minacce. La modellazione si pone come obiettivo quello di aiutare i progettisti a pensare quali possano essere le minacce che le loro applicazioni potrebbero dover affrontare. Può essere vista come una valutazione del rischio per le applicazioni. Il consiglio, anche in questo caso, è di sviluppare un modello di minacce ad inizio SDLC, seguendo preferibilmente l’approccio proposto dallo standard NIST 800-30 (National Institute of Standard and Technology) che prevede:
- la scomposizione dell’applicazione tramite verifica manuale del codice per comprendere il funzionamento del sistema e le sue sotto funzionalità;
- la definizione e classificazione delle risorse suddividendole in beni materiali e immateriali e classificandole per importanza aziendale;
- valutare tutte le potenziali vulnerabilità, tecniche, operative e gestionali;
- valutare le potenziali minacce mettendosi dal punto di vista del potenziale attaccante del sistema;
- creare una strategia di mitigazione del rischio, sviluppando controlli per attenuare le minacce ritenute realisticamente probabili dopo gli step di analisi precedenti.
La guida OWASP delinea la metodologia di modellazione delle minacce seguendo i passaggi del NIST e può essere utilizzata come modello di riferimento per testare le applicazioni informatiche.
- Source Code Review. Per revisione del codice si intende il processo di verifica manuale del codice sorgente di un’applicazione alla ricerca dei problemi di sicurezza. Moltissime tipologie di vulnerabilità non possono essere riscontrate con gli altri metodi. Tutti gli specialisti in sicurezza informatica sono concordi nell’affermare che non vi è nessuna tecnica migliore del cercare di identificare direttamente nel codice sorgente le vulnerabilità. Tramite l’analisi del codice sorgente, il tester esamina ogni singola riga di codice del software e classifica con precisione ogni eventuale tipologia di vulnerabilità riscontrata. Esempi di vulnerabilità difficili da riscontrare con le altre tecniche, ma che possono essere individuate con la source code review sono ad esempio i problemi di concorrenza delle risorse, problemi sulla crittografia e problemi di controllo degli accessi; i trojan o gli easter egg, i malware o altre tipologie di codice dannoso. Sicuramente è una tecnica di analisi particolarmente completa e approfondita e veloce, che richiede però specialisti di sicurezza altamente qualificati entrando molto nello specifico della singola linea di codice sorgente.
- Il penetration testing. Il penetration testing (o pentesting) di un applicativo è una tipologia di tecnica attiva attraverso la quale Il tester tenta di forzare l’accesso allo stesso, simulando un attacco da parte di un hacker (da qui il termine ethical hacker o white hacker) e mettendo il sistema sotto stress. Esistono due principali categorie di pentesting:
- Il whitebox test. Il tester dispone delle credenziali di un normale utente (quindi non credenziali da amministratore) e ha il compito di capire fino a dove un normale utente ha la possibilità accedere a sezioni dell’applicazione al di fuori dei permessi garantiti alla sua tipologia di utenza o sezioni non ad accesso pubblico;
- Il blackbox test. Il tester non è in possesso di alcuna informazione se non l’url dove è pubblicato l’applicativo. È a carico del tester riuscire ad accedere all’applicazione sfruttando tutte le tecniche possibili per acquisire anche le credenziali e forzare l’accesso (ad esempio con attacchi di tipo brute force). Le credenziali possono essere recuperate direttamente o con tecniche di social engineering, scam o phishing, inducendo in errore l’utente che fornirà direttamente a sua insaputa le credenziali all’attaccante.
Nello svolgimento dei pentest, il tester ha il compito di sfruttare tutte le falle che rendono vulnerabile la sicurezza dell’applicativo. Dal momento che gli applicativi vengono utilizzati in specifici ecosistemi (es. sistemi operativi) o si appoggiano a funzioni e risorse esterne (es. database o web server), il tester può utilizzare le sue conoscenze per sfruttare eventuali falle dei sistemi e dei servizi che dialogano con esso per effettuare un accesso fraudolento simulato.
Conclusioni
Per concludere, tutte le organizzazioni che si occupano di sviluppo software e applicativi non possono più prescindere dal conoscere e padroneggiare le tecniche e i controlli OWASP. In particolar modo, se le soluzioni software progettate da tali società sono poi vendute a grandi player o a pubbliche amministrazioni.
In ogni modo, parafrasando Eoin Keary, membro dell’OWASP Global Board, se anche le piccole realtà e gli sviluppatori freelance conoscessero e applicassero le tecniche OWASP, “il mondo sarebbe un luogo dove i software non sicuri sarebbero l’anomalia e non la norma”. E in un mondo del genere, i rischi di violazione dei dati (data breach) sarebbero notevolmente ridotti, con enormi benefici per i diritti e le libertà delle persone.
