Questo sito web utilizza cookie tecnici e, previo Suo consenso, cookie di profilazione, nostri e di terze parti. Chiudendo questo banner, scorrendo questa pagina o cliccando qualunque suo elemento acconsente all'uso dei cookie. Leggi la nostra Cookie Policy per esteso.OK

Cyber security, i cinque passi per uno sviluppo applicativo sicuro

pittogramma Zerouno

Cyber security, i cinque passi per uno sviluppo applicativo sicuro

21 Dic 2015

di Nicoletta Boldrini

Per rinforzare e rendere più sicure le applicazioni è fondamentale seguire 5 step e creare un ambiente dove prevenzione e remediation alle vulnerabilità diventano un tutt’uno con lo sviluppo software. Amy DeMartine, senior analyst di Forrester, spiega come creare un ambiente di sicurezza responsive lungo tutto il ciclo di vita delle applicazioni.

La crescita esplosiva e l’aumento della complessità di siti eCommerce, applicazioni mobile e la diffusione costante delle soluzioni di Internet of Things (IoT) stanno creando non pochi problemi sul fronte della sicurezza per via delle vulnerabilità che progetti, soluzioni e servizi di questo tipo portano con sé. Ne sono convinti molti It professional intervistati recentemente da Forrester in tema di cybersecurity [interviste dalle quali è emerso un report che si presta ad essere più che altro una guida per i manager delle aree Infrastructure&Operations (I&O): “Five steps to reinforce and harden application security” – ndr]; Joshua Corman, Cto di Sonatype e fondatore della software house Rugged Software/Rugged DevOps, solo per citarne uno, ha sottolineato la necessità di cooperazione tra team Security & Risk (S&R) e It manager I&O ribadendo il fatto che, nel contesto odierno, “l’Internet of everithing significa Internet delle ‘cose hackerabili’” [l’intervento di Joshua Corman “Continuous acceleration: why continuous everything requires a supply chain approach” è visibile su YouTube https://www.youtube.com/watch?v=0mUN3RppEHE – ndr].

Nel report di Forrester, la senior analyst Amy DeMartine ribadisce più volte come i team S&R non siano in grado, da soli, di coprire tutte le vulnerabilità che i nuovi progetti It e le nuove esigenze di digital business generano. Nella visione dell’analista, infatti, “le persone del reparto It che tradizionalmente si sono sempre occupate di infrastrutture e operations sui sistemi devono oggi supportare attraverso meccanismi di automazione e integrazione le security practice all’interno di una ‘continuous delivery pipeline’, aumentando la visibilità lungo tutte le interconnessioni digitali che avvengono tra hardware, software, servizi web e customer data”.

Come costruire un responsive security environment

Per riuscire in ciò, i professionisti I&O devono creare un ambiente di sicurezza ‘responsive’. Cinque gli step che Forrester suggerisce per questo percorso.

  1. Rimuovere le ‘inconsistenze’ e creare un ‘conto’ dei materiali. Secondo quanto emerso dall’ultimo report ‘HP Security Research Cyber Risk 2015’ [info: http://www8.hp.com/us/en/software-solutions/cyber-risk-report-security-vulnerability/ – ndr], il 47% delle applicazioni web ha al suo interno file non protetti per via dei problemi legati alle microconfigurazioni dei web server [le percentuali sono stime che riflettono i dati analizzati dai laboratori di sicurezza HP incrociati con le community ‘open source intelligence’ e i laboratori di montoring real-time dei cyber attacks – ndr]. Il primo step da affrontare sarebbe dunque quello di creare un sistema web server in cooperazione tra I&O e S&R team per eliminare tutte le problematiche di vulnerabilità spesso riconducibili, scrive DeMartine, a microservizi non necessari (servizi inconsistenti che continuano a girare sui web server ma che non sono riconducibili ad alcuna applicazione perché nel frattempo queste ultime sono cambiate, sono state aggiornate, ecc.) o al cattivo mantenimento di user Id e password. “Quando si applica un modeling approfondito di tutte le applicazioni (tenendo conto quindi di database, network firewall, servizi e microservizi di supporto nonché ovviamente di tutte le componenti delle applicazioni stesse) – descrive l’analista – si riesce ad avere un vero e proprio ‘conto’ dei materiali, ossia una lista di tutti i componenti e subcomponenti chiamati in causa per far girare l’applicazione”. I benefici ottenibili lavorando con un approccio di questo tipo (chiamato appunto ‘application modeling’) sono diversi: riduzione del mean-time-to-repair (utilizzando tool di configuration management che tengano traccia di tutte le modifiche non solo dell’applicazione ma di tutti i sistemi che la supportano); utilizzo limitato di software per l’analisi delle vulnerabilità di terze parti (se si ha buona visibilità su com’è composta l’applicazione e quali sono le sue interazioni con tutti i sistemi It non è necessario integrare ulteriori strumenti); rapida rimozione dei ‘difetti’ che possono generare vulnerabilità.
  2. Limitare e rinforzare l’accesso ai sistemi e ai network device; monitorare i cambiamenti. Le vie principali per rubare dati sono sostanzialmente due: o vi sono delle vulnerabilità che lasciano aperte delle brecce, soprattutto a livello di network e sistemi, oppure ci sono persone che con dolo rubano i dati all’interno della propria azienda. In questo caso la via di risoluzione è una sola: lavorare a livello infrastrutturale per bloccare tutti gli accessi non autorizzati monitorando costantemente network e traffico sui sistemi. “Non solo – avverte DeMartine – i team di infrastrutture e quelli della sicurezza dovrebbero lavorare insieme per stabilire policy e tool dedicati al monitoraggio, in particolare dedicati all’analisi del comportamento delle applicazioni, per verificare in tempo reale eventuali cambiamenti prima che questi si traducano in vulnerabilità”.
  3. Assistere i team di Security&Risk sul fronte intrusion detection & response. Non si tratta di ‘mettersi a fare un altro mestiere’, si legge nel report di Forrester, ma di abilitare sistemi infrastrutturali e tool tecnologici in grado di supportare le politiche di sicurezza. “Le infrastrutture hanno un ruolo determinante nella prevenzione (e nella risposta) delle intrusioni perché possono avere il controllo di tutto lo stack tecnologico e fornire alert ed informazioni utili ai team di sicurezza di fronte ad anomalie legate, per esempio, ad un utilizzo non comune delle Cpu, al numero di transazioni rilevate dai sistemi, ecc.”, scrive DeMartine. “Un sistema di controllo che parte dalle infrastrutture accelera il mean-time-to-detection (il tempo di localizzazione di vulnerabilità o di un attacco) nonché il tempo di risposta (che in molti casi può anche essere automatizzata) e, cosa molto importante, riduce il range dei falsi allarmi di sicurezza (grazie ai controlli incrociati tra team infrastrutturali e team di security)”.
  4. ‘Loggare’ quanto più possibile. “Sia gli I&O professional sia i team di S&R utilizzano ‘briciole di pane’ quando investigano sulle problematiche di vulnerabilità – sottolinea in modo provocatorio l’analista di Forrester -; diventa perciò di importanza critica riuscire a massimizzare tutte le capacità e le funzionalità di logging e auditing lungo l’intero ambiente It”. Analizzare le fonti di tutti i dati così come il ‘conto’ dei materiali di ciascuna applicazione e sistema e monitorarne ogni minimo cambiamento diventa indispensabile; dal punto di vista tecnologico, suggerisce Forrester, gli Ara – Application Release Automation tool devono diventare parte integrante dei processi di audit sui sistemi; è fondamentale poi che vi siano sistemi di Automate Change Tracking e dashboard condivise tra I&O e S&R team.
  5. Creare uno stack di application security tool.
Figura 1: Augment the life cycle with security tools – Fonte: Forrester, Five Steps To Reinforce And Harden Application Security

Seguendo i passi precedenti si arriva al punto cruciale del percorso, la creazione di un vero e proprio stack tecnologico incentrato sulla sicurezza delle applicazioni. “Non è pensabile proteggere le applicazioni lungo tutto il loro ciclo di vita, a partire dallo sviluppo, attraverso una sola tecnologia e senza metodologia – riporta in conclusione DeMartine -; per riuscire ad indirizzare correttamente una protezione efficace delle applicazioni, soprattutto nei contesti web, cloud, mobile e di digitalizzazione di servizi e processi di oggi, diventa cruciale e prioritario scoprire le vulnerabilità (e porvi rimedio) quando, lungo il ciclo di vita della soluzione, è ancora poco costoso e poco rischioso poterlo fare: nella fasi di sviluppo e testing”.

E per comporre lo stack, queste le tecnologie cui gli I&O professional dovrebbero porre attenzione (figura 1): – Static application security testing (Sast), tool che esaminano il codice binario e il codice di programmazione delle applicazioni senza ‘mandare in esecuzione’ l’applicazione (ossia senza la necessità di farla girare sui sistemi nei processi di testing);

Dynamic application security testing (Dast), sistemi che permettono di osservare in dettaglio come si comporta l’applicazione quando è in funzione per scovarne imperfezioni o vulnerabilità prima che si prosegua con lo step di sviluppo successivo;

Fuzz testing tool, sistemi che analizzano le vulnerabilità sul fronte di protocolli network, application data e input location (sempre durante i cicli di testing applicativo);

Hybrid analysis tool, si tratta di tecnologie di testing per la sicurezza delle applicazioni che integrano funzionalità di Instrumented application security testing (Iast) e Runtime application security testing (Rasp) utili per ridurre i falsi positivi e i falsi negativi generalmente evidenziati dai sistemi Dast;

Vulnerability assessment tool, sistemi utili a rendere visibili eventuali criticità a livello di sistema operativo, configurazione dei sistemi, microconfigurazioni dei web server e delle altre architetture con cui l’applicazione in sviluppo dovrà interagire una volta messa in produzione;

Penetration testing tool, tecnologie utili a ‘validare’ l’assessment delle vulnerabilità perché mostrano come potrebbero avvenire gli attacchi simulando la penetrazione nei sistemi e nelle applicazioni aziendali;

Software composition analysis (SCA) tool, tecnologie che consentono di analizzare le building block applicative per scovare vulnerabilità all’interno, per esempio, delle librerie, dei componenti open source o dei vari ‘blocchi’ di software che compongono l’applicazione.

Nicoletta Boldrini

Giornalista

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

LinkedIn

Twitter

Whatsapp

Facebook

Link

Articolo 1 di 3