Nel precedente articolo La sicurezza è minimalista abbiamo introdotto il modello organizzativo “a cipolla” come il più adatto per affrontare lo sviluppo di software “sicuro”.Passiamo qui ad esaminare gli interventi da effettuare sul ciclo di sviluppo del software.

Le contromisure

Abbiamo già in precedenza menzionato la necessità dell’adozione di contromisure applicative. Si tratta di un argomento di scottante attualità, in quanto la maggior parte delle moderne tecniche di data breach sono centrate proprio sulla loro violazione.

Una panoramica sulla tipologia, l’incidenza e l’impatto di questo tipo di minacce è riportata nel portale web dell’Open Web Application Security Project (OWASP), un progetto open-source che dal 2001 si pone l’obiettivo di realizzare linee guida, strumenti e metodologie per migliorare la sicurezza delle applicazioni. Il suo progetto più conosciuto è noto come OWASP TopTen, una classifica dei 10 rischi maggiormente rilevanti per la sicurezza delle applicazioni web, la cui validità è riconosciuta a livello globale da tutte le principali community di sviluppatori.

La classifica, aggiornata ogni 3-4 anni utilizzando i più autorevoli rapporti sulle modalità e dinamiche dei data breach registrati su scala mondiale, consente di mettere a fuoco i principali rischi connessi allo sviluppo dei moderni applicativi e di seguire le variazioni temporali della loro incidenza e rilevanza.

Top 10 Web Application Security Risk: 2017 vs 2021 (fonte: OWASP)

Ciascuno dei rischi classificati viene trattato in modo esaustivo in una sezione apposita del sito, che ne descrive:

• gli aspetti salienti (overview & description),
• i principali scenari di attacco (example attack scenarios),
• le misure preventive (how to prevent)
• i riferimenti dei casi registrati (references).

L’adozione di contromisure volte a minimizzare la probabilità e l’impatto delle minacce descritte nella OWASP Top Ten è universalmente considerata il primo passo verso una realizzazione del software sicuro. Tuttavia,è fondamentale che queste attività vengano effettuate durante tutto il ciclo di vita del software: dall’analisi preliminare ai necessari processi di controllo e monitoraggio da implementare dopo il rilascio in produzione, includendo le metodologie di sviluppo vere e proprie.

Prima dello sviluppo

Le decisioni a tema security by design da prendere nella fase preliminare di un progetto IT sono particolarmente importanti, in quanto possono avere un impatto determinante sui tempi, sui costi, e dunque sulla fattibilità dello stesso. Tra queste, è opportuno ricordare le seguenti:

• Strategia di sviluppo. Confrontare i requisiti richiesti da OWASP con il know-how interno aziendale consente di determinare se è opportuno procedere a uno sviluppo interno (in-house)o avvalersi di un fornitore esterno (outsourcing).
• Scelta del fornitore e degli asset. Nel caso in cui si decida di avvalersi di uno o più fornitori esterni dotati di proprie risorse software e hardware, è fondamentale che chi si occuperà della selezione degli stessi (procurement) abbia le capacità di svolgere i controlli del caso per garantire il rispetto degli standard di sicurezza previsti, sia a livello di requisiti (bandi di gara) che dal punto di vista contrattualistico (SLA e penali).
• Composizione del team di sviluppo. Conoscere anzitempo le vulnerabilità da affrontare risulta fondamentale per mettere in piedi un team di sviluppo dotato del know-how adeguato a garantire il successo del progetto, ottimizzando il rapporto rischi/costi/benefici.
• Definizione dei processi. Oltre all’aspetto prettamente implementativo, la maggior parte dei progetti IT prevede un insieme più o meno ampio di processi collaterali, quali:
  • le policy che regolano l’attività degli utenti e degli operatori (registrazione, primo accesso, formazione, interfaccia utente, user experience),
  • gli eventuali requisiti di system integration, tipicamente previsti nel caso in cui l’applicativo faccia parte di un ecosistema di micro servizi più ampio.

La corretta definizione di ciascuno di questi aspetti richiede una valutazione dei rischi e delle vulnerabilità che tenga conto delle principali minacce note.

• Cost-Analysis. Ultimo, ma non certo per importanza, è l’aspetto legato alla corretta valutazione dei costi del progetto, che non può prescindere da una piena consapevolezza dell’aggravio degli investimenti OPEX (spese operative) e CAPEX (spese di capitale) necessari per garantire le misure tecniche e organizzative descritte in ciascuno dei punti precedenti.

Durante lo sviluppo

L’adozione di un modello orientato alla sicurezza a partire dalla progettazione deve necessariamente prevedere anche una serie di attività da effettuare, processi da attuare e controlli da garantire durante la fase di sviluppo, tra cui:

• Controllo del codice sorgente. Il complesso di attività noto come source control management (SCM) rappresenta un pilastro fondamentale della sicurezza informatica applicata allo sviluppo software, in quanto garantisce il rispetto dei criteri di integrità, disponibilità e confidenzialità del codice sorgente, favorendo allo stesso tempo la piena tracciabilità delle operazioni e la collaborazione tra sviluppatori.
• Testing. La buona pratica di prevedere un robusto processo di test durante lo sviluppo per ciascun dei requisiti progettuali dell’applicazione è uno degli aspetti più sottovalutati dai project manager e dal team di sviluppo, spesso per motivazioni legate alla mancanza di tempo o di budget. L’adozione di una rigorosa strategia di testing rappresenta a tutt’oggi il modo più efficace per individuare e correggere bug e difetti del codice prima che questo venga rilasciato in produzione, garantendo notevoli vantaggi in termini di sicurezza, affidabilità, resilienza e soprattutto migliore confidenza nell’applicazione e miglior livello di soddisfazione generale del cliente.
• Logging. Il logging è la capacità di un applicativo di registrare eventi, errori ed altre attività e rendere disponibili tali registrazioni in tempo reale all’interno di un output più o meno strutturato. Le funzionalità di logging sono essenziali per comprendere il comportamento del software in produzione e diagnosticare eventuali malfunzionamenti o problemi di performance in modo diverso e complementare a quanto avviene durante le attività di testing.
• Monitoring. La realizzazione di un sottosistema di monitoraggio per l’applicazione sviluppata o l’adozione di una piattaforma di monitoraggio commerciale consente di avere una visibilità in tempo reale del funzionamento dell’applicativo, sia in fase di test che durante il funzionamento in produzione. Il monitoring rappresenta uno strumento cruciale per ridurre il tempo di risposta in caso di anomalie funzionali e prestazionali, sia segnalate dal fallimento dei test che da errori o warning presenti nei log prodotti dall’applicazione.

Dopo lo sviluppo

Le attività da svolgere durante l’esercizio dell’applicativo non sono meno importanti di quelle descritte in precedenza. Rivestono particolare importanza, in aggiunta alla gestione continuativa dei processi di logging & monitoring messi a punto durante lo sviluppo:

• Patching. Mantenere aggiornati i sistemi, le librerie e le componenti di terze parti utilizzati dall’applicazione con le ultime patch di sicurezza fornite dal produttore, così da ridurre l’impatto delle vulnerabilità note.
• Penetration Testing. Eseguire con regolarità dei test di penetrazione (PenTest) utilizzando strumenti, tecniche e metodologie simili a quelle comunemente utilizzate dagli hacker, in modo da identificare eventuali vulnerabilità del sistema. Questi testdevono essere effettuati da aziende specializzate principalmente su ambienti di staging separati, in modo da non rischiare di compromettere l’integrità e la disponibilità dell’ambiente di produzione.
• Feedback. Raccogliere i feedback degli utenti che utilizzano attivamente il servizio, con il duplice obiettivo di individuare le vulnerabilità di sicurezza non rilevate (o non rilevabili) dai test interni e di sensibilizzare gli stessi sull’importanza di aderire alle buone pratiche di sicurezza indispensabili per il funzionamento del servizio.

(*) MS Azure Certified Security Engineer, Microsoft MVP for Cloud & Datacenter Management and Developer Technologies, autore di libri di informatica. Attualmente ricopre il ruolo di CTO per un gruppo aziendale che opera nel campo dei servizi assicurativi.

https://www.key4biz.it/sviluppare-la-sicurezza-parte-iii/484578/