Cinque leader del settore dell’application security si pronunciano in merito ai processi di business e agli imperativi necessari per ottenere una migliore sicurezza applicativa.

Oggi la sicurezza applicativa interessa praticamente tutte le sfaccettature della sicurezza delle informazioni, eppure molte aziende hanno ancora grosse difficoltà nell’implementare programmi di sicurezza applicativa che siano sostenibili e che offrano benefici misurabili per il proprio business. La generale separazione fra i requisiti della sicurezza aziendale e gli obiettivi di profitto impartiti dal business ai team di sviluppo può provocare conflitti insormontabili fra i team di sicurezza e di sviluppo, con i responsabili di business troppo pronti a schierarsi il più delle volte dalla parte degli sviluppatori a causa della smania di fare soldi.

Questo è il motivo principale per cui la sicurezza applicativa si riduce spesso a qualche semplice rattoppo di tipo tecnologico, nel migliore dei casi limitato alla top ten OWASP. Il segreto del successo consiste nell’adottare politiche intelligenti, nell’educare e nel delegare le figure di sviluppo applicativo, nonché nel sostegno dei processi di business senza causare interruzioni al flusso di lavoro quotidiano.

Ecco, quindi, i dieci comandamenti che portano ad un’efficace attuazione della sicurezza applicativa.

1.  Attua la sicurezza applicativa alla stessa velocità del business

Non c’è nulla di peggio per la sicurezza applicativa che la dimostrazione di arroganza dell’esperto che si rivolge agli sviluppatori o ai responsabili di business per dire che è necessario re-ingegnerizzare completamente i loro processi per motivi di sicurezza – dice Bill Pennington, Chief Strategy Officer di WhiteHat Security. “Devi conoscere bene il ritmo e la cadenza del tuo business e devi adattare di conseguenza le soluzioni di sicurezza” – dice Pennington – “altrimenti non otterrai l’implementazione di alcunché”.

Egli racconta quindi l’aneddoto relativo ad un cliente che una volta fu avvicinato da un consulente di sicurezza il quale disse a sviluppatori e responsabili di business che era necessario sottoporre a penetration test completo tutto il codice applicativo prima del passaggio in produzione, un’attività che avrebbe richiesto ogni volta l’aggiunta di cinque giorni di lavoro supplementari al processo. Il responsabile capo della linea di business disse che loro spedivano il codice ogni mercoledì e il consulente ribadì che il business non avrebbe più potuto farlo. Ma il responsabile di business disse perentorio: “No, noi spediamo il codice ogni mercoledì ed è lei che deve adattarsi alle modalità con le quali la sua azienda o i suoi clienti fanno affari”.

Uno dei modi migliori per iniziare a comprendere il concetto è quello di studiare ed immedesimarsi nel modo di lavorare degli sviluppatori prima di emettere decreti prescrittivi – dice Chris Eng, Vice President della ricerca di Veracode. “Impara come lavora la struttura di sviluppo così potrai essere di aiuto senza diventare troppo dirompente.” – dice Eng – “Ad esempio, se essi usano la metodologia di sviluppo Agile-Scrum, impara come questa funziona e cerca di individuare i punti in corrispondenza dei quali ha più senso introdurre la sicurezza”.

2. Non progettare la sicurezza

Sponsorizzare la pratica di progettare la sicurezza delle applicazioni potrebbe sicuramente avere una certa risonanza nelle riunioni di progetto, ma John Jacott, direttore delle soluzioni di sicurezza di Coverity, tende invece a smontare un po’ questa mentalità. “Gran parte delle applicazioni che ho visto sono raramente frutto di un progetto vero e proprio. Esse nascono e crescono a fronte di metodi di sviluppo come Agile o Waterfall.” – dice Jacott – “Ciò che va fatto è dimostrare e far comprendere spesso e bene agli sviluppatori le conseguenze di uno scarso livello di sicurezza e fare in modo che essi comincino a pensarci su”.

Jackott ritiene che molti architetti di sicurezza risultano infine inefficaci perché puntano a gestire e controllare anche i più piccoli dettagli. “Essi non delegano i propri compiti, pertanto non consentono agli sviluppatori di creare applicazioni più sicure per conto proprio” – afferma Eng, concordando sul fatto che formare ed educare sui temi di sicurezza singoli individui-chiave nei team di sviluppo comporterebbe un risultato di gran lunga migliore. “È l’unico modo per far scalare e diffondere la sicurezza in una grande azienda: scovare i leader in ambito tecnico o architetturale ed addestrarli ad individuare gli schemi di attacco e gli errori di sviluppo più comuni”.

3. Fai evolvere i tuoi metodi di test

Il test delle applicazioni costituisce la base sulla quale sono costruite solide pratiche di sicurezza applicativa. Se le metodologie sulle quali sono costruite le verifiche di sicurezza sono traballanti, l’intera struttura risulterà instabile. “Mantieniti costantemente aggiornato con le più recenti tassonomie e classificazioni, perché esse tendono a riflettere gli aspetti più importanti nel campo delle minacce di sicurezza” – dice Eng – “ad esempio, se la checklist che usi per il tuo penetration test è stata definita sulla base della Top Ten OWASP del 2007, molto probabilmente è il caso di aggiornarla”.

Eng suggerisce tre principali attività attorno alle quali le aziende al passo coi tempi dovrebbero organizzare i propri test:

• La prima, e più importante, attività consiste nella creazione di un inventario o catalogo delle applicazioni e nella loro classificazione in base alla criticità che rivestono per il business aziendale, con l’obiettivo di misurare i rispettivi rischi durante le attività di verifica.
• Poi, le aziende dovrebbero realizzare un’analisi del codice e degli oggetti su tutte le applicazioni ad alto e medio rischio in fase di sviluppo, dando priorità alla mitigazione delle vulnerabilità di impatto medio e alto, ben prima che queste applicazioni vadano in produzione.
• Infine, le aziende dovrebbero adottare strumenti per l’individuazione di tutte le applicazioni web esistenti nel perimetro e realizzare una scansione dinamica prima dell’autenticazione, dando nuovamente maggiore priorità alla mitigazione delle vulnerabilità di livello medio e alto rilevate durante il processo.

4. Non sorprendere i team di sviluppo

Nessuno ama le sorprese, in particolare gli sviluppatori che sono obbligati a sospendere un passaggio in produzione a fronte di test di sicurezza di cui non conoscevano l’esistenza, afferma Jacott. “Ogni controllo come, ad esempio, un vulnerabilità assessment o un penetration test deve essere ben pubblicizzato, possibilmente sponsorizzato dal più alto livello di responsabilità (es. CSO o CEO) ed essere ben compreso ed accettato” – continua Jacott – “Se non ottieni la piena accettazione è solo colpa tua, perché non stai usando il loro stesso linguaggio. Un test a sorpresa è solo punitivo”.

Se le sorprese della sicurezza prendono i team di sviluppo alla sprovvista, quantomeno li spingono ad adottare pratiche più sostenibili di sviluppo sicuro nelle fasi preliminari del processo. In altre parole, è opportuno cercare di aiutare i team di sicurezza e di sviluppo ad imparare dai propri errori in futuro.

“Secondo il mio parere personale, quando ciò accade può diventare uno strumento molto potente all’interno dell’azienda per dire: a noi piacerebbe realizzare test di sicurezza prima oppure in varie modalità per garantire la sicurezza fin dall’inizio e prevenire grandi sorprese” – dice Diana Kelley, application security strategist di IBM – “Se riusciamo ad accettare questo e continuiamo ad adottarlo nel tempo, otterremo meno sorprese durante i test di pre-produzione e potremo ottenere applicazioni molto più robuste in produzione”.

5. Verifica anche le applicazioni in produzione

Secondo Pennington, i test di sicurezza applicativa non devono arrestarsi al processo di collaudo ed esistono tre ragioni principali che dovrebbero spingere le aziende a verificare regolarmente il livello di sicurezza delle applicazioni che sono già in produzione:

• Innanzitutto, molte delle applicazioni sono state rilasciate in produzione ben prima che la pratica del security testing venisse intrapresa in azienda.
• In secondo luogo, le applicazioni spesso appaiono di gran lunga diverse in produzione rispetto a come apparivano in fase di collaudo: “Oggi abbiamo in gestione circa 13.000 siti web e solo il 10% di questi ha un ambiente di collaudo speculare alla produzione,” – afferma Pennington – “tanto che dobbiamo ancora trovare vulnerabilità coincidenti con entrambi gli ambienti”.
• Infine, ancora più importante, la conoscenza e la cognizione di come scovare e sfruttare le vulnerabilità cambia nel tempo (e sempre più rapidamente, n.d.r.): “Se effettuo la scansione del codice in collaudo oggi, ottengo di conoscere solamente ciò che oggi posso conoscere,” – afferma Pennington – “poi, dopo una settimana spunta qualche folle e così abbiamo un nuovo modo di sfruttare vulnerabilità di SQL Injection che prima non conoscevamo”.

6. Non permettere che i framework sostituiscano il buon senso

I framework sono uno strumento estremamente valido per gli sviluppatori ed offrono anche ottime soluzioni per supportare l’implementazione della sicurezza applicativa. Ma in qualsiasi strumento potrebbero esserci delle trappole, afferma Ken Pickering, development manager di security intelligence per Core Security. “Il fatto che la gente adotti dei framework è fantastico, perché essi apportano molte precauzioni di sicurezza e possono proteggere contro attacchi di SQL injection e altre minacce del genere” – afferma Pickering – “ma molte persone non si preoccupano di aggiornare i loro framework così come aggiornano le applicazioni e questi grossi framework spesso comportano dei difetti”.

Non è raro che i framework producano rilevanti backdoor a causa di problemi nella gestione dei permessi utente: “Molte persone scrivono API REST o integration point nei loro database e mi accorgo che la metà delle volte questi sono semplicemente spalancati.” – continua Pickering – “Per quanto indirizzino i loro sforzi sugli input dell’interfaccia utente, forzando tutto a livello di SPRING data, si attaccheranno molto probabilmente a qualche framework REST perché così è più facile garantire l’accesso ai dati saltando molti permessi utente. In molte situazioni questo rappresenta una specie di backdoor”.

7. Rappresenta le vulnerabilità nel giusto contesto

Quando un test di sicurezza indica inevitabilmente delle vulnerabilità, i professionisti della sicurezza non fanno un gran favore a sé stessi se spingono per la mitigazione di tutte le esposizioni rilevate con la stessa priorità. “Non dare per scontato che tutte le vulnerabilità di un certo tipo siano equivalenti,” – avverte Eng – “la sicurezza non va considerata in maniera avulsa; piuttosto è meglio valutare le vulnerabilità nel contesto appropriato. Esistono molte sfumature di grigio nella determinazione dell’importanza di un rilievo di sicurezza ed è sempre meglio non generare allarmi così, per abitudine”.

I professionisti della sicurezza dovrebbero agire in qualità di consulenti, non come autoritari controllori che si preoccupano solo di imporre mitigazioni. Ciò significa soprattutto che essi devono fornire informazioni obiettive ed oggettive sulle vulnerabilità esistenti, insieme ad adeguata documentazione in merito alla gravità e al possibile impatto. “Lascia che sia il responsabile di business a chiamarti e che sia ritenuto responsabile qualora decidesse di non considerare il tuo parere in tema di sicurezza” – dice Eng.

8. Limita l’accesso ai dati reali

I saldi principi del controllo accessi non sono solo qualcosa che gli sviluppatori dovrebbero provare ad inserire nelle proprie applicazioni, ma sono anche qualcosa con cui essi devono convivere e lavorare nell’ambiente di sviluppo – afferma Pickering. “È un problema particolarmente spinoso perché, pur riguardando principalmente il business, ha comunque un impatto di tipo tecnico” – continua Pickering, avvertendo che la pratica di consentire agli sviluppatori il pieno accesso in chiaro ai dati reali della clientela durante le fasi di sviluppo comporta una vera e propria ondata di rischi per l’azienda. “C’è sempre stata un abisso fra i generatori dei contenuti e gli addetti alle infrastrutture, perciò mantenere aggiornati i diritti di accesso e assicurare una loro corretta gestione è sempre stato un grosso problema”.

9. Usa i Web Application Firewall in maniera strategica

I Web Application Firewall (WAF) sono spesso accompagnati da una pessima fama nel mondo della sicurezza applicativa, poiché vengono considerati dai più come una mera pezza inefficace per tamponare pratiche scorrette di sviluppo software. Pennington dice di essere giunto nel tempo a considerare i WAF come strumenti preziosi, a patto però di utilizzarli in maniera strategica: “Non li considero come una specie di scatola magica che una volta introdotta risolve tutti i problemi, bensì come un semplice punto di controllo”.

Ad esempio, se un’azienda ha consegnato del software applicativo che è ormai in produzione e successivamente scopre una vulnerabilità di SQL Injection che non era stata rilevata durante le fasi di collaudo, diventa impraticabile chiedere agli sviluppatori di apportare una modifica che risolva il problema. “Si tratta di interrompere il business, bloccare il flusso di lavoro e provocare così la mancata consegna di quella funzionalità da milioni o miliardi di dollari, assumendosene la responsabilità.” – afferma Pennington – “Ma se hai a disposizione un web application firewall, puoi attivare al volo una regola che blocchi gli attacchi di SQL Injection, mitigando temporaneamente l’esposizione di sicurezza, e quindi dire agli sviluppatori di risolvere la vulnerabilità del software con la prossima release entro un mese o due al massimo”.

10. Non biasimare gli sviluppatori

Sarebbe certamente facile per i team di sicurezza dare la colpa agli sviluppatori – dice Jacott – ma non è questa la giusta via per ottenere applicazioni sicure. “Molti addetti alla sicurezza delle informazioni amano accusare gli sviluppatori, sostenendo che sono stupidi e non sanno quello che fanno.” – dice Pennington – “Devi lavorare con loro con spirito di collaborazione, è così che raggiungi l’obiettivo in un più ampio contesto di business e riesci a consegnare il software applicativo in tempo”.

Più riuscirai a guadagnare supporto politico e a farti amici gli sviluppatori durante il percorso, maggiori saranno le probabilità di successo – dice Jacott – che ha sprecato troppo tempo nel ruolo di antagonista prima di comprendere ed imparare quanto sia più facile giocare secondo le regole degli sviluppatori. “Ora ho intenzione di rimboccarmi le maniche e di non pormi al di fuori, ma diventare uno di loro, un membro del team, integrando la sicurezza nel loro processo e portando così una soluzione ai loro problemi, senza diventare un problema nella loro soluzione” – conclude.

Fonte: Dark Reading – Ericka Chickowsky

Ettore Guarnaccia