Un`introduzione - Master Sicurezza

Sicurezza Applicativa: Un’introduzione
Roma, 23 Giugno 2011
Copyright © 2011 Euery S.r.l. All rights reserved.
The information contained in this document may change without notice, and may have been altered or changed if you have received it from a source other than Euery S.r.l. All information provided in this
document is provided "AS IS" with all faults without warranty of any kind, either expressed or implied. To the fullest extent permissible pursuant to applicable law, Euery S.r.l. disclaims all warranties,
expressed or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Euery S.r.l. be liable for any damages whatsoever, including direct, indirect,
incidental, consequential, or special damages, arising from the use or dissemination hereof, even if Euery S.r.l. authorized representative have been advised of the possibility of such damages. No part
of this document shall be reproduced, republished, uploaded, posted, transmitted, or distributed by any means without written permission from Euery S.r.l.
Agenda dell’incontro
Mercato di Riferimento
Concetti di Application Security
Cicli di sviluppo software (SDLC)
Cicli di sviluppo software security oriented (SSDLC)
Threat Modeling
Penetration Testing
Penetration Testing: Demo
Secure Code Review
Secure Code Review: Demo
Secure Programming
www.euery.com
Relatori
Antonio Parata:
Co-fondatore della società di ricerca e sviluppo
software “Euery”.
Laureato presso la facoltà di “Ingegneria
Informatica” del Politecnico di Milano.
È in possesso della certificazione professionale
CSSLP (Certified Secure Software Lifecycle
Professional).
Co-autore della OWASP Testing Guide v.2 e v.3
e ricercatore attivo nel campo della Software
Security.
Per anni è stato Security Auditor presso il centro
operativo di sicurezza (SOC) di una nota
compagnia di telecomunicazioni.
www.euery.com
Francesco Beatino:
Co-fondatore della società di ricerca e sviluppo
software “Euery”.
Ha frequentato la facoltà di “Sicurezza dei
Sistemi e delle Reti Informatiche” presso il Polo
Didattico e di ricerca di Crema.
E’ stato Technical Member del progetto
internazionale di ricerca Honeynet.org e
Technical Editor per la rivista polacca Hakin9.
È in possesso della certificazione professionale
CEH (Certified Ethical Hacker).
Per anni è stato Security Analyst e Security
Service Manager presso il centro operativo di
sicurezza (SOC) di una nota compagnia di
telecomunicazioni.
È stato co-responsabile della rubrica
“Vulnerabilità” della rivista italiana “ICT Security
Magazine”.
Mercato di Riferimento
Secondo la fonte Gartner, anche in considerazione delle contromisure adottate negli ultimi anni per il
controllo degli accessi alla infrastruttura e la messa in protezione dei dati, negli ultimi tempi oltre il 75%
degli attacchi sono stati indirizzati direttamente verso le applicazioni , causando gravi danni di immagine e
pesanti perdite finanziarie;
Gli obiettivi degli attacchi sono le vulnerabilità che si celano all’interno delle applicazioni software;
Le vulnerabilità applicative sono quasi sempre presenti anche perché fino ad ora le politiche di qualità del
software ed i relativi investimenti si sono concentrate soprattutto sulla correzione delle difettosità funzionali
e sulle performance delle logiche applicative, trascurando l’attuazione di pratiche di progettazione e
programmazione che garantiscono la sicurezza del codice.
www.euery.com
Mercato di Riferimento II
Le vulnerabilità applicative vengono continuamente introdotte dagli stessi team di sviluppo interni alle
aziende, dai fornitori, dalle soluzioni open-source: alcuni analisti affremano che il 64% degli sviluppatori
non sono confidenti di poter scrivere applicazioni sicure (fonte: Microsoft Developer Research);
Il numero delle tipologie di attacchi cresce in maniera esponenziale: dalle circa 2500 identificate nel 2000,
si è passati ad oltre 50000 nel 2009 e continuamente se ne scoprono delle nuove (fonte: CERT);
www.euery.com
Riflessioni
Quanto costa corregere i problemi?
Errori Architetturali
Errori di Codifica
Errori di Integrazione
www.euery.com
Scoperti in fase di
Disegno
Scoperti in fase di
Codifica
Scoperti in fase di
Integrazione
Scoperti in fase
Collaudo
Scoperti in fase di
Produzione
1x
5x
10x
20x
30x
1x
10x
20x
30x
1x
10x
15x
Sicurezza applicativa: Cenni storici
La pratica di sviluppare applicazioni software capaci di operare
correttamente anche in condizioni di attacco da parte di agenti di
minaccia esterni viene definita Software Security.
Il primo libro e testo accademico ad esprimersi sull’argomento apparve
nel 2001 e fu una chiara dimostrazione dell’ interesse e dello studio della
tematica da parti di sviluppatori, software architect ed esperti di sicurezza
informatica la cui attenzione fino a quel momento rimaneva concentrata
su firewall, intrusion detection e sistemi antivirus.
Una vera e propria rivoluzione di pensiero quindi. Il testo si chiamava
Building Secure Software.
www.euery.com
Sicurezza applicativa: Cenni storici (II)
La comunità blackhats, nel contempo, percepì la reale possibilità di portare con successo attacchi
informatici alle applicazioni.
Da qui l’inizio della diffusione delle prime e fondamentali best practices in materia di sicurezza
applicativa, le prime tra tutte riconducibili ad una buona ingegnerizzazione del software, una piena
comprensione delle minaccie più comuni, compresi i difetti propri dei linguaggi di programmazione, ma
soprattutto una considerazione della problematica fin dalle prime fasi del ciclo di sviluppo.
www.euery.com
Sicurezza applicativa: Principi
Secure By Default
L’applicazione software dovrebbe utilizzare caratteristiche di sicurezza di default: ad esempio, l’abilitazione
automatica di meccanismi di costruzione di password complesse piuttosto che procedure di rinnovo delle stesse
secondo una scadenza di natura temporale.
Least Privilege
Il principio nasce dall’esigenza di limitare eventuali danni derivanti, ad esempio, da condizioni di errore, incidenti
di sicurezza o utilizzo non autorizzato dell’applicazione software.
Alla base dell’assioma la raccomandazione che gli utenti – così come le stesse applicazioni – siano in possesso
di un insieme minimo di privilegi richiesti per l’esecuzione delle proprie attività lavorative inibendo così eventuali
accessi, seppur involontari, a funzionalità critiche dell’applicativo piuttosto che al file system o base di dati.
Defence In Depth
Il principio del Defence In Depth asserisce che dove un controllo dovrebbe essere equilibrato al rischio, più
controlli contemporanei ma che contrastino lo stesso rischio in maniera diversa costituiscono di certo la soluzione
ottimale. Nel campo del Secure Coding tale principio può essere, ad esempio, così contestualizzato: un controllo
di auditing centralizzato può essere efficacemente unito al requisito di tracciare la totalità degli accessi degli
utenti.
www.euery.com
SDLC: Software Development Life Cycle
Il criterio con cui una metodologia di sviluppo o un
modello di processo scompongono l'attività di
realizzazione di applicazioni software in sottoattività fra
loro coordinate viene definito ciclo di vita del software.
www.euery.com
Attività SDLC
Quasi tutti i modelli di ciclo di vita del software prevedono una scomposizione del processo di sviluppo in
attività e sottoattività.
www.euery.com
SDLC: Analisi
La fase di analisi, che costituisce lo studio preliminare sul contesto in cui il prodotto software dovrà inserirsi
quindi sulle caratteristiche che dovrà esibire, ed eventualmente su costi e aspetti logistici della sua
realizzazione.
La fase può essere scomposta in sottoattività quali, ad esempio, analisi e modellazione del dominio
applicativo, analisi di fattibilità ed analisi dei requisiti.
www.euery.com
SDLC: Progetto
La fase di progetto, durante la quale, in funzione dei requisiti esposti in fase di analisi, vengono definite le
linee essenziali della struttura dell’applicazione da realizzare.
www.euery.com
SDLC: Implementazione
La fase di implementazione, ovvero la realizzazione concreta del progetto. L'implementazione ha lo scopo
di attuare la soluzione.
www.euery.com
SDLC: Collaudo
Obiettivo della fase è la misurazione di quanto il sistema realizzato soddisfi i requisiti stabiliti nella fase di
analisi, quindi valutarne la correttezza rispetto alle specifiche.
www.euery.com
SDLC: Manutenzione
Include tutte le attività di modifica del software successive alla fase di rilascio quali ad esempio, correzione
dei difetti, porting su diversi ambienti operativi o estensione delle funzionalità.
www.euery.com
SSDLC: Secure Software Development Life Cycle
Si definisce SSDLC (Secure Software Development Life Cycle) un ciclo di vita sicuro del software atto a
considerare ed implementare opportune attività di sicurezza nel corso di tutte le sue fasi: analisi,
progettazione, sviluppo, test e manutenzione.
www.euery.com
Sicurezza all’interno del SSDLC (I)
Analisi: analisi dei requisiti di sicurezza, analisi dei rischi, identificazione delle minacce, analisi delle
probabilità di impatto delle minacce, casi di Abuso e UML per la sicurezza del software, linee guida
sull'usabilità del software, analisi tradizionale nel SDLC;
Progetttazione: analisi dei rischi, UML per la sicurezza del software, linee guida sull'usabilità del software,
progettazione tradizionale nel SDLC;
Sviluppo: programmazione sicura del codice, test di sicurezza basati sull'analisi dei rischi, analisi statica
del codice, sviluppo tradizionale nel SDLC;
Test: analisi dei rischi, penetration test (approccio blackbox o code review), mitigazione dei rischi, test
tradizionali nel SDLC;
Manutenzione: analisi dei rischi, penetration test, manutenzione tradizionale nel SDLC.
www.euery.com
Sicurezza all’interno del SSDLC (II)
www.euery.com
Sicurezza all’interno del SSDLC (III)
www.euery.com
SSDLC: Alcuni esempi
Alcuni famosi esempi di cicli di sviluppp software orientati alla sicurezza sono rappresentati da:
SDL (Secure Software Development Lifecycle)
CLASP (Comprehensive Lightweight Application Security Process)
www.euery.com
SDL (I)
Uno dei programmi di maggiore successo nato dall'iniziativa Trustworthy computing di Microsoft è
sicuramente il Security Development Lifecycle (SDL), il rigoroso processo di programmazione sicura
che interessa i principali e più esposti software Microsoft.
Da quando nel 2004 il processo è divenuto obbligatorio, le applicazioni e i sistemi operativi di Redmond
hanno subito una forte riduzione delle vulnerabilità: Windows Vista, nel primo anno dopo il suo rilascio
ufficiale ha visto ridurre del 45% il numero di vulnerabilità scoperte e corrette rispetto a Windows XP (66
contro 119), mentre per un prodotto critico nelle applicazioni Web come Sql Server, la riduzione dei bug
di sicurezza è stato di ben 91%.
www.euery.com
SDL (II)
www.euery.com
SDL (III)
Punti focali del processo SDL sono, senz’altro, costituiti dalla creazione di un modello di minacce (threat
modeling), l’uso di strumenti di analisi statica del codice, revisioni tecniche ed attività di verifica del
codice.
www.euery.com
CLASP
Il modello CLASP (Comprehensive, Lightweight Application Security Process) fornito dal progetto OWASP
fornisce un approccio strutturato all’integrazione di attività di sicurezza all’interno di ogni fase di un normale
ciclo di sviluppo software.
Tale processo è definito mediante cinque prospettive di alto livello chiamate viste.
www.euery.com
Capability Maturity Model
Il Capability Maturity Model Integration è uno standard dei requisti di processo aziendali, sviluppato dal
Carnegie Mellon University. È l'erede del CMM, sviluppato dal 1987 al 1997.
E’ un modello che indica ventidue Aree di processi aziendali (Process area) strutturate su cinque livelli,
ognuna con i propri obiettivi generici (Generic Goal) e specifici (Specific Goal).
Gli obiettivi generici e specifici sono implementati da una sequenza temporale di attività generiche (Generic
practice) e specifiche (specific practice), che hanno determinate tipologie di output (tipical work product).
www.euery.com
SSE-CMM
L’ SSE-CMM (Systems Security Engineering-Capability Maturity Model) è uno specifico modello di
processo - adottato come standard ISO/IEC 21827 oltre che standard de facto nel settore - utilizzabile per
migliorare e valutare la capacità di ingegnerizzazione, circa gli aspetti legati alla sicurezza del software,
all’interno di un’organizzazione.
Il modello deriva dal Capability Maturity Model Integration ossia uno standard dei requisti di processo
aziendali, sviluppato dal Carnegie Mellon University e promosso dall'Ufficio del Segretario della Difesa
USA (OSD), dal SEI e dall'Associazione Industriale per la Difesa Nazionale.
www.euery.com
SAMM
Software Assurance Maturity Model (SAMM) è un framework open - i cui autori ne permettono e ne
favoriscono quindi il libero studio e l'apporto di modifiche – sviluppato al fine di supportare le organizzazioni
nella formulazione di strategie relative alla sicurezza del software.
Caratteristica del framework è la flessibilità con cui è stato definito che lo rende particolarmente adattabile
tanto dalle piccole aziende, quanto dalle medie e grandi organizzazioni, slegandosi completamente, e nel
comtempo, dallo specifico stile di sviluppo adottato.
www.euery.com
SAMM (II)
!
www.euery.com
BSIMMv2
Il Building Security In Maturity Model è un modello sviluppato con lo scopo di supportare la corretta
pianificazione e governo di iniziative di sicurezza legate alle applicazioni software.
BSIMM è strutturato in 110 attività ripartite sui 12 campi del Software Security Framework (SSF), a sua
volta suddiviso in tre livelli di maturità.
www.euery.com
Threat Modeling
La modellazione delle minacce è il processo di valutazione e documentazione dei rischi associati alla
sicurezza di un particolare sistema e/o applicazione software.
Il processo di modellazione può essere adottato per determinare un elemento denominato “Threat
Profile“ associato all’applicazione, ovvero lo scenario non fidato in cui l’applicativo dovrà essere
eseguito.
Mediante l’adozione di opportune tecniche quali, ad esempio, l’identificazione degli entry point, ovvero
i punti di accesso all’applicazione, Privilege Boundaries e Threat Tree è possibile identificare strategie
di mitigazione efficaci per contrastare potenziali minacce a cui potrebbe essere soggetta
l’applicazione.
www.euery.com
Threat Modeling (II)
La modellazione delle minacce permette, inoltre, di giustificare l’introduzione o l’eliminazione di
eventuali feature all’interno dell’applicazione oltre che governare, al fine di proteggere gli asset
dell’applicazione, l’introduzione di nuove policy o pratiche di sicurezza all’interno del sistema.
www.euery.com
Threat Modeling: Modellazione del sistema
Identificazione delle minacce: Il primo aspetto è relativo all’identificazione delle minacce associate, ad
esempio, all’applicazione oggetto della modellazione. Tale fase può essere realizzata mediante l’utilizzo
di Data Flow Diagrams (DFD) piuttosto che diagrammi UML.
L’adozione di tali diagrammi consente l’identificazione, infatti, della totalità dei punti di ingresso
all’applicazione quali, ad esempio, sorgenti di dati esterni, eventuali Application Program Interface (API),
piuttosto che Web Services e/o interfacce utente.
www.euery.com
Threat Modeling: Comprensione delle minacce
Al fine di identificare correttamente le possibili minacce associate ad ogni singolo punto di ingresso
dell’applicazione è fondamentale comprendere le relative azioni ed implicazioni di sicurezza che
potrebbero affliggere il sistema oggetto di modellazione a fronte di un’ eventuale violazione.
www.euery.com
Threat Modeling: Categorizzazione delle minacce
La categorizzazione delle minacce di sicurezza può essere ottenuta mediante l’adozione di un modello
denominato STRIDE sviluppato da Microsoft.
STRIDE è l'acronimo che riunisce la gamma dei rischi per la protezione a cui può essere soggetta
l'applicazione.
Le sei categorie di rischi (Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service,
and Elevation of privilege) consentono di identificare le vulnerabilità ed i possibili vettori di attacco nelle
applicazioni.
www.euery.com
Threat Modeling: Possibili mitigazioni
Al fine di determinare il rimedio associato ad una minaccia identificata è possibile generare un
diagramma ad albero denominato Threat Tree.
www.euery.com
Threat Modeling: Un esempio
www.euery.com
Threat Modeling Tool (Microsoft)
www.euery.com
Penetration Testing
Il Penetration Test, chiamato anche “Security Probe”, è un attività riconducibile ad un’indagine
sperimentale sulla sicurezza di un computer, di una rete piuttosto che di un’applicazione software con lo
scopo di individuare vulnerabilità che potrebbero essere sfruttate da un utente malintenzionato per
ottenere accessi non autorizzati.
www.euery.com
Penetration Testing (II)
Varie tipologie:
Black Box: Nessuna informazione sul sistema;
Gray Box: Minime informazioni sul sistema. Ad esempio architettura di base ed account alla sezione
autenticata disponibili.
White Box: Pieno accesso alle informazioni sul sistema. Spesso ingloba anche attività di Bug Hunting
attraverso una secure code review.
www.euery.com
Penetration Testing: Fasi
Profilazione dell’applicazione, identificazione di pagine o sezioni critiche, identificazione di eventuali
componenti di terze parti installati;
Esecuzione di una prima scansione attraverso tools automatici e studio delle vulnerabilità identificate;
Analisi manuale delle vulnerabilità identificate e delle sezioni considerati critiche;
Exploiting delle vulnerabilità per confermarne la presenza;
Valutazione dell’impatto delle vulnerabilità e stesura report.
www.euery.com
Penetration Testing: Considerazioni
Le applicazioni scritte in PHP risultano in media più vulnerabili rispetto alle controparti scritte in J2EE e
ASP .NET (vuoi anche perché sono le più diffuse);
Spesso i PT si risolvono attraverso l’identificazione di applicazioni di gestione erroneamente accessibili
(ad es. phpmyadmin) oppure attraverso delle password deboli (ad es. root, toor, r00t, password,
123456);
Sfruttamento di vulnerabilità note sugli applicativi installati (ad es. utilizzo di CMS vulnerabili)
www.euery.com
Penetration Testing: Un esempio
Vulnerabilità di SQL Injection
dump della tabella utenti (username e MD5 password);
Brute forcing MD5 tramite rainbow tables
password dell’utente (s3cr3t);
Accesso alla parte autenticata del sito;
Errore logico nel caricamento di file
upload di un file con estenzione .php;
Esecuzione di codice remoto con utente Apache;
Kernel vulnerabile
Run Exploit
www.euery.com
Download exploit da exploit-db
root
Penetration Testing
DEMO
www.euery.com
Secure Code Review (I)
Scopo principale dell’attività di Secure Code Review è l’analisi, automatica e manuale, del codice
sorgente di un’applicazione software al fine di individuarne eventuali vulnerabilità di sicurezza.
www.euery.com
Secure Code Review (II)
Possibili bug, con conseguenti ripercussioni sulla sicurezza del software, possono riguardare, ad esempio:
blocchi try/catch/finally/switch vuoti;
codice morto quali variabili locali, parametri o metodi inusati;
costrutti if/while vuoti;
espressioni o classi esageratamente complesse, contenenti if non necessari o cicli annidati;
codice duplicato, tipicamente frutto di cut and paste.
www.euery.com
Secure Code Review: Strategie di analisi
Diverse strategie di analisi del codice
Data-flow: scelta una certa variabile si esegue solo il codice interessato da quest’ultima cercando di
individuarne le vulnerabilità;
Control-flow: scelto un componente lo si analizza riga per riga cercando di individuarne le
vulnerabilità.
www.euery.com
Terminologia (I)
Per avere un maggior livello di dettaglio e per evitare che uno stesso termine sia usato in letteratura con
significati diversi, il glossario IEEE [IEEE90] propone le seguenti definizioni:
Un malfunzionamento o guasto (failure) è un funzionamento di un programma diverso daquanto
previsto dalla sua specifica;
Un difetto o anomalia (fault) è la causa di un malfunzionamento;
Un errore (error) è l’origine di un difetto.
www.euery.com
Terminologia (II)
Si definisce Sink Point il punto in cui qualora un’eventuale input malevolo dovesse essere processato si
avrebbero potenziali problemi di sicurezza;
Si definisce Entry Point l’indirizzo di memoria corrispondente a un punto nel codice che è inteso come la
destinazione di un "salto lungo" (long jump), sia esso interno o esterno;
E’ detto Taint Input l’input considerato malevolo;
Si definiscono Punti di Filtering i punti in cui l’input “taint” diventa “non taint”.
www.euery.com
Desk Check
Il modo più elementare di effettuare un controllo statico è basato sull’analisi informale del codice, condotta
“a mano” – in inglese desk check – o mediante l’ausilio di strumenti automatici.
Le tecniche più comuni per effettuare questo tipo di controlli statici sono l’ispezione ed il walkthrough.
Entrambi hanno lo scopo di trovare e denunciare dei difetti senza però che il revisore si sostituisca al
progettista o al programmatore, a cui comunque rimane il compito di scoprire l’errore e correggere il codice.
www.euery.com
Desk Check (II)
La principale differenza fra ispezione e walkthrough risiede nel tipo di errori che la tecnica si prefigge di
scoprire.
Il walkthrough è inteso come un’esecuzione simulata del codice e porta generalmente a scoprire difetti
originati da errori algoritmici;
L’ispezione ha invece, di norma, obiettivi ristretti e prestabiliti: poiché i difetti sono raggruppabili in
categorie è plausibile che un controllo ottenga migliori risultati se concentrato su un solo tipo di difetti.
www.euery.com
Analisi statica supportata da strumenti
Oltre al desk check, è possibile eseguire una verifica statica usando opportuni strumenti.
Da un punto di vista teorico, avere un prova formale della correttezza di un programma, ottenuta a partire
dall’analisi del codice, corrisponde all’esecuzione su tutti i possibili insiemi di dati d’ingresso.
Diverse le teorie di analisi statica che approssimano la prova formale “ideale”:
Model checking (controllo sul modello)
Esecuzione simbolica
Analisi statica in compilazione
www.euery.com
Testing (I)
Il test di sistema è la più canonica delle attività di validazione che valuta ogni caratteristica di qualità del
prodotto software nella sua completezza, avendo come documento di riscontro i requisiti dell’utente.
Le tecniche più adottate per i test sul sistema sono basate su criteri funzionali.
Gli obiettivi dei controlli sono mirati a esercitare il sistema sotto ben determinati aspetti alcuni dei quali
verranno illustrati di seguito.
www.euery.com
Testing (II)
Facility Test (test delle funzionalità): È il più intuitivo dei controlli, quello cioè che mira a controllare che
ogni funzionalità del prodotto stabilita nei requisiti sia stata realizzata correttamente.
Security Test: Cercando di accedere a dati o a funzionalità che dovrebbero essere riservate, si controlla
l’efficacia dei meccanismi di sicurezza del sistema.
www.euery.com
Testing (III)
Usability Test: Con questo controllo si vuole valutare la facilità d’uso del prodotto da parte dell’utente
finale.
È una valutazione su una delle caratteristiche di un prodotto software fra le più soggettive.
Il controllo deve prendere in esame oltre al prodotto anche tutta la documentazione che lo accompagna e
deve tener conto del livello di competenza dell’utenza e delle caratteristiche operative dell’ambiente d’uso
del prodotto.
www.euery.com
Testing (IV)
Performance Test: È un controllo mirato a valutare l’efficienza di un sistema soprattutto rispetto ai tempi di
elaborazione e ai tempi di risposta. È un tipo di controllo critico per quelle categorie di prodotti, come ad
esempio i sistemi in tempo reale, per le quali ai requisiti funzionali si aggiungono rigorosi vincoli temporali.
Storage Use Test: È ancora un controllo legato all’efficienza di un sistema, ma mirato alla richiesta di
risorse – la memoria in particolare – durante il funzionamento, e ha implicazioni sull’ambiente operativo
richiesto per poter installare il sistema.
www.euery.com
Test Mutazionale
Una strategia diversa è rappresentata dal test mutazionale.
La tecnica si applica incongiunzione con altri criteri di test: nella sua formulazione è prevista infatti
l’esistenza, oltre al programma da controllare, anche di un insieme di test già realizzati.
La strategia prevede di introdurre modifiche controllate nel programma originale.
Le modifiche riguardano in genere l’alterazione del valore delle variabili e la variazione delle condizioni
booleane.
www.euery.com
Test di Regressione
La strategia ha l’obiettivo di controllare se, dopo una modifica apportata per una necessità di sviluppo, il
software è regredito, se cioè siano stati introdotti dei difetti non presenti nella versione precedente alla
modifica.
La strategia consiste nel riapplicare al software modificato i test progettati per la sua versione originale e
confrontare i risultati.
www.euery.com
Secure Code Review e Testing a confronto
Sono attività del tutto complementari che utilizzate in modo congiunto hanno un forte effetto sinergico
nell’incrementare la sicurezza del software.
Sono complementari perché:
Il Testing individua misconfigurazioni ed errori del codice;
Il testing individua errori logici nell’applicazione oltre che errori implementativi;
Non permette di capire quale sia la root cause;
Non ha piena visibilità del funzionamento dell’applicazione;
La code review identifica tutti gli errori presenti nel codice;
Permette di individuare anche alcuni errori logici (errata implementazione di algoritmi crittografici, etc
…);
Permette di capire quale è la root-cause di una data vulnerabilità;
Ha una totale visibilità del funzionamento dell’applicazione.
www.euery.com
Secure Code Review
DEMO
www.euery.com
Secure Programming (I)
Tra gli aspetti più importanti quando si vuole adottare un SSDLC;
Il primo passo è rendere gli sviluppatori consci dell’importanza di sviluppatore codice sicuro;
Il secondo passo è adottare delle linee guida per lo sviluppo di codice sicuro e di affiancare a ciò l’utilizzo
di framework o librerie che aiutino a scrivere codice più sicuro.
www.euery.com
Secure Programming (II)
Un esempio:
Boolean isAdmin = true;
try
{
If (username.equals(“admin”) && password.equals(“password”))
isAdmin = true;
else
isAdmin = false;
}
Catch {}
DoAdminOperation(isAdmin);
Non rispetta il principio di Fail Securely.
www.euery.com
Domande?
www.euery.com