Per molto tempo, la modalità principale di sviluppo software si è globalmente appoggiata sul concetto “basta che funzioni” e la maggior parte delle applicazioni (in particolare applicazioni web) sviluppatesi nel corso degli ultimi due decenni, non hanno tenuto conto di un aspetto che ad oggi risulta fondamentale: la sicurezza.
Se è vero che oggi abbiamo a disposizione una vastità di librerie, framework ed ecosistemi in grado di comunicare tra loro in modo efficiente e veloce, tutto questo ha portato anche all’aumento della cosiddetta “superficie di rischio” rispetto a eventuali attori malevoli.
Sebbene non sia la modalità più diffusa, l’attacco tramite vulnerabilità web resta una delle modalità sfruttate dagli attaccanti per inserirsi all’interno di un’infrastruttura o per rubare i dati sui quali si appoggia l’applicazione stessa.
Librerie o framework di terze parti obsoleti, codice sviluppato senza un concetto di “security by design”, architetture applicative mal progettate…sono solo alcuni degli aspetti che possono rendere particolarmente vulnerabili i software prodotti.
Secondo l’ultimo report di OWASP TOP 10, le prime posizioni delle vulnerabilità più sfruttate nei software, sono le seguenti:
- Broken Access Control: tipologia di vulnerabilità relativa a permessi non gestiti correttamente, a livello di utente o di accesso alle risorse.
- Cryptographic Failures: insieme delle vulnerabilità relative a modalità di cifratura deboli, mal applicate o applicate parzialmente.
- Injection: insieme delle vulnerabilità che permettono tramite l’injection di codice (ad esempio SQL) l’estrazione o la modifica di dati che normalmente non potrebbero essere modificati o esposti.
- Insecure Design: insieme delle vulnerabilità relative ad un design dell’applicazione essenzialmente insicuro, difficilmente correggibile se non tramite una riscrittura completa.
- Security Misconfiguration: insieme delle vulnerabilità causate da configurazioni errate, servizi/account non necessari lasciati attivi oppure configurazioni non sicure a livello di framework.
- Vulnerable and Outdated Components: vulnerabilità causate da componenti obsoleti a qualsiasi livello dell’applicazione (frontend, backend, database, etc..)
Come difendersi?
Dal punto di vista di chi sviluppa applicazioni software, è di fondamentale importanza che la genesi di una nuova applicazione parta dal concetto che la sua architettura deve riflettere il concetto di security by design.
Se non pensiamo l’applicazione fin dall’inizio per essere sicura, difficilmente quando sarà finita e rilasciata in produzione, riusciremo a renderla altrettanto solida con delle correzioni successive.
Architettura a parte, una strada efficace per poter gestire l’aspetto della cyber security nel ciclo di sviluppo, è quella di fare in modo che il processo stesso abbia in sé degli step obbligatori di convalida della security.
Monitorare o valutare?
Così come nella filiera di sviluppo, ci sono molto spesso delle fasi all’interno dei processi di compilazione che verificano l’integrità funzionale del codice (ad esempio, unit test o integration test), dovrebbero esserci analogamente dei passaggi altrettanto automatici che ne verificano la consistenza in termini di security.
Questi automatismi possono, ad esempio, verificare l’obsolescenza delle librerie di terze parti utilizzate (controllando se sono vulnerabili e hanno bisogno di essere aggiornate o sostituite) o anche che il codice, per come è scritto, non permetta gli attacchi di tipo più diffuso, come il Cross Site Scripting (XSS) o la SQL Injection.
Sfruttando un termine che si sta diffondendo in questo momento, si tratta di passare dal paradigma SDLC (Software Development Life Cycle) a quello del SSDLC (Secure Software Development Life Cycle).
L’idea quindi non è tanto e solo quella di svolgere saltuariamente assessment sul software, ma monitorare costantemente la sicurezza informatica del codice sviluppato in ogni fase che precede la release in produzione (preferibilmente in modo automatico).
Security nei software
È utile inoltre approcciare l’aspetto della security di un software, anche da un punto di vista più distaccato e agnostico, in modo da capire cosa potrebbe trovare un eventuale attaccante e quali sono i punti deboli del codice che possono essere sfuggiti durante il processo di sviluppo.
L’obiettivo è sempre quello di compensare la complessità di un’applicazione (o un ecosistema di applicazioni) con tecniche e procedure adeguate che coprano tutti gli aspetti relativi alla sicurezza e prevenire con l’adozione di sistemi di monitoraggio e risposta attivi H24 per bloccare sul nascere qualsiasi tentativo malevole.
In aggiunta a questi processi è necessario mantenere alta l’attenzione svolgendo periodicamente Penetration Test (PT) e Vulnerability Assesment (VA) sul software.
Se l’esito di questi test evidenzia delle vulnerabilità, dovranno essere naturalmente attuate le dovute correzioni con una priorità proporzionale alla gravità del problema rilevato.
Questo passaggio, è particolarmente importante nel caso in cui l’infrastruttura abbia subito un attacco, al fine di consolidare tutti i punti potenzialmente fragili prima del ripristino completo dell’infrastruttura.
Le attività di VA/PT possono essere richieste come requisito anche e soprattutto quando chi produce software è uno dei fornitori.
In fondo, anche questo è un esempio di supply chain, su cui normative come la NIS2 insistono giustamente molto affinché questo aspetto venga tutelato adeguatamente.
In conclusione…
Sviluppare software risulta spesso un’attività complessa che ormai non può più prescindere da un’attenzione particolare verso la sicurezza del codice sviluppato.
In sintesi, possiamo indicare questi come i tre pilastri di un buon progetto software:
- Prima di scrivere il codice di un prodotto nuovo, progettare un’architettura che sia solida e sicura by design.
- Inserire nel ciclo di sviluppo delle fasi di convalida obbligatorie che coprano gli aspetti fondamentali della sicurezza.
- Verificare periodicamente la sicurezza del software con attività di VA/PT.
Analisi di Paolo Leoni – Incident Response Specialist, CYBEROO