Nella moderna concezione dei servizi erogati sulla rete molti presupposti sono radicalmente cambiati rispetto a qualche lustro fa. L’avvento delle grandi reti aziendali negli anni ’90 e, successivamente, di Internet hanno modificato lo scenario della sicurezza dei servizi e delle applicazioni a supporto. Ma chi sviluppa e pubblica applicazioni sulla rete, se ne è accorto? Ha compreso come deve necessariamente cambiare il ciclo di vita del software (SDLC – Software Development Life-Cycle) nell’era moderna?

L’altissimo livello di potenzialità e complessità raggiunto dalle applicazioni moderne, in particolare quelle orientate al web, comporta inevitabilmente un notevolissimo aumento dei rischi di sicurezza ad esse associati. La maggior parte delle applicazioni è composta da diversi piccoli moduli, siano essi routine, programmi, pagine JSP, pagine ASP, ecc. Ognuno di questi moduli esegue funzioni critiche, agendo spesso direttamente sui dati fondamentali delle società e dei loro clienti. E ogni modulo, se non opportunamente sviluppato, è potenzialmente veicolo di azioni non controllate e fraudolente. Ma come limitare questi rischi di sicurezza?

Firewall, sistemi di anti-intrusione, sistemi proxy e application gateway danno certamente un senso di sicurezza piuttosto percettibile. L’averli è ormai fatto imprescindibile in qualsiasi ambiente tecnologico di una certa criticità e complessità. Ma possono essi arginare tutti i rischi di sicurezza inerenti un errato criterio di sviluppo delle applicazioni? La risposta è presto data. Tutti gli strumenti sopra citati garantiscono che l’accesso alle applicazioni avvenga esclusivamente mediante i canali e le porte di comunicazione di rete previsti. Ma quando il canale e la porta di comunicazione sono quelli previsti?

Quando si ha accesso ad un’applicazione di rete, via Internet (con un normale browser http) o via Intranet (telnet, 3270, http, client-server, ecc.), significa che tutti i controlli fisici, perimetrali e di rete ci hanno garantito l’accesso e ci è consentito interagire ed operare con l’applicazione in tutte le sue componenti pubblicate. A questo punto entra in gioco la qualità dell’applicazione e il suo livello di sicurezza. Tutti gli errori di programmazione, gli errati controlli, le variabili non correttamente dimensionate, i moduli non protetti, gli accessi diretti alla base dati, le funzioni di interrogazione di dati critici e sensibili, sono tutti rischi più che reali per la stragrande maggioranza delle applicazioni esistenti. Sfruttare tali “buchi di sicurezza”, può consentire diverse azioni malevole, dal semplice “denial of service” (tipo buffer overflow, blocco del database, ecc.) fino ai più pericolosi accessi indesiderati, furti di dati sensibili (anagrafe, carte di credito, dati industriali e commerciali), cancellazione di base dati e ottenimento di credenziali amministrative sull’applicazione, sul database o sul sistema che li ospita.

Sempre più aziende, quasi tutte all’estero, tendono a creare un ciclo di vita del software che integri al suo interno un processo di sicurezza che implementi determinati controlli in ogni singola fase, dalla scrittura della prima riga di codice fino alla pubblicazione dei servizi. Il ciclo di vita del software viene generalmente diviso in cinque fasi: Define (definizione dei servizi da erogare), Design (disegno dell’applicazione), Develop (sviluppo dell’applicazione), Deploy (pubblicazione sulla rete) e Maintenance (manutenzione dell’applicazione). Un processo di sicurezza integrato nel ciclo di vita del software prevede altrettante fasi di verifica per ottenere un’applicazione il più sicura possibile: Secure Design, Manual Inspections and Reviews, Threat Modeling, Code Review e Application Penetration Testing. Andiamo a vedere in che cosa consistono.

Secure Design: la conoscenza dei principi di sicurezza da adottare nello sviluppo del software è il primo fondamentale passo per garantire l’implementazione dei controlli di sicurezza al fine di minimizzare e proteggere la superficie di attacco e introdurre specifici meccanismi di sicurezza nel disegno del software.
Manual Inspections and Reviews: l’ispezione accurata delle linee guida adottate dalla società che sviluppa il codice ha il fine di garantire che i corretti standard e le politiche di sicurezza siano stati adeguatamente recepiti ed implementati dal team di sviluppo applicativo.
Threat Modeling: è il processo di “modellazione” delle possibili minacce che potrebbero affliggere l’applicazione. Questo processo di modellazione consente di comprendere i rischi potenziali del software e verificare se si dispone di adeguati metodi per contrastarli.
Code Review: è forse il passo cruciale del SDLC. La revisione del codice, che consiste in un test di tipo “white box” (chi effettua il test ha infatti la conoscenza completa dell’applicazione), consente di verificare l’intero codice applicativo riga per riga alla ricerca di errori di programmazione, possibili vulnerabilità e rischi associati. Può essere realizzato con l’ausilio di strumenti software opportunamente selezionati e configurati, ma la parte preponderante viene eseguita rigorosamente a mano.
Application Penetration Testing: è l’ultimo, ma non meno importante, controllo di sicurezza sull’applicazione sviluppata prima del rilascio in esercizio. E’ un test di tipo “black box” (chi effettua il test non conosce nulla del software da testare) ed ha lo scopo di individuare eventuali ulteriori problematiche di sicurezza con un punto di vista esterno, tipicamente quello di eventuali attaccanti presenti sulla rete. Spesso e volentieri il test di penetrazione applicativa diventa automaticamente un vero e proprio Code Review, grazie a vulnerabilità (anche piuttosto diffuse) che consentono di ottenere, dall’esterno e senza alcun controllo, l’intero codice dell’applicazione coinvolta.

Quanto sopra riportato può facilmente far comprendere quanto importante stia diventando lo sviluppo di applicazioni sicure, in particolare per quelle aziende che forniscono software e servizi applicativi a società bancarie, finanziarie, assicurative e tutte le altre realtà che devono gestire dati critici, sensibili e personali. Sull’onda di questa innovazione nella sicurezza applicativa, cambieranno ben presto anche i contratti: sarà sempre più frequente, infatti, che le aziende che acquistano e usufruiscono di software richiedano specifiche clausole, certificazioni e assicurazioni sul livello di sicurezza del software, i controlli e le metodologie di sviluppo adottate dai fornitori.

Per il momento l’argomento comincia a riscaldarsi all’estero, soprattutto per quanto riguarda le grandi società produttrici di software, mentre in Italia, pur essendo sempre più lesti nell’approcciare le nuove tecnologie, siamo invece ancora molto molto lenti nell’apprenderne e contrastare i relativi rischi.

Ettore Guarnaccia