Una cosa che noto, parlando con sviluppatori e persone che fanno AOM sulle macchine, è la mancata percezione del software di terze parti, come un pericolo per la sicurezza della propria applicazione.

Prendiamo, per esempio, l’ultima vulnerabilità grave legata al framework Struts2. Tutte le applicazioni J2EE, basate sulla versione vulnerabile di Struts2, non importa quanto sviluppate in modo sicuro, non importa quanti penetration test avessero subito, potevano essere bucate.

Mica male, direi.

Il vostro codice vive all’interno di un vero e proprio ecosistema. Se una delle componenti dell’ecosistema ha un problema, tutto il sistema, compreso il vostro codice, eredita quel problema.

Il ciclo di vita di un’applicazione, quindi, non può mancare di una corposa fase di gestione delle vulnerabilità. Periodicamente, deve essere fatto un assessment dei problemi di tutte le parti in gioco, devono essere messe in ordine di severità e devono essere stabilite delle priorità di intervento.

E’ inutile investire in un ciclo di vita sicuro del software, se poi lascio il mio codice in esecuzione su software obsoleti e vulnerabili. Attenzione, ho parlato di gestione della vulnerabilità, non gestione degli incidenti. Nonostante qualche storyteller voglia farci credere che siano la stessa cosa, sono distanti come il giorno e la notte.

Un opensource io vorrei

Il più grande problema dell’opensource sono proprio le persone che lo amano ciecamente. Mi spiego meglio. Diventare un fanboy di una tecnologia, anche se vale per qualsiasi cosa in questo mondo, fa perdere obbiettività. Una persona non obbiettiva è una persona che non è lucida. Una persona non lucida parla per stereotipi, aumentando solo il rumore di fondo.

Linux, e più in generale, l’opensource sono più sicuri, è una fregnaccia. Avere il codice di NginX a disposizione, non implica automaticamente che:

• sia sicuro
• qualcuno faccia delle code review.

Se io quindi sto gestendo un portale, che usa NginX come web server e io penso di essere al sicuro, perché uso software opensource, posso richiedere una licenza gold di venditore di caciotte e pere bollite.

Opensource può essere più sicuro perché il codice è a disposizione. Diventa più sicuro se qualcuno da una mano ai maintainer dei vari progetti, per trovare bug e vulnerabilità.

Proprio ieri guardavo l’andamento dei dati delle vulnerabilità di un sistema RedHat 6.nontelodico. Se lasciamo che il nostro software diventi obsoleto, ci portiamo a casa almeno una trentina di issue di security l’anno. Si, ci sono anche su Linux, vedo che il paraocchi non l’avete ancora tolto, allora…

Gestione delle vulnerabilità e postura aziendale

Per avere una buona postura aziendale in campo security, o cybersecurity, o sicurezza cibernetica, il passo obbligato è quello di censire l’elenco delle vulnerabilità dei vostri asset, dare una priorità di intervento, agire e mitigare i rischi portati dal software di terze parti, reiterare il processo all’infinito.

Questo vale anche per le librerie delle nostre applicazioni web.

Il check più corposo che fa, ad esempio, dawnscanner è proprio sulle vulnerabilità delle gemme incluse nel bundle di un’applicazione Rails, Sinatra, Padrino e presto Hanami.

Sto lavorando su Owasp Orizon, per introdurre lo stesso tipo di controllo sulle librerie incluse in un Jar, War o Ear.

Avere un report periodico che ci dica le vulnerabilità che la nostra applicazione web eredita da una libreria che neanche sapevamo di avere, perché magari è una dipendenza di una dipendenza di una libreria opensource che utilizziamo, è vitale al giorno d’oggi.

Gestire il ciclo di vita del codice, includendo la parte di gestione delle vulnerabilità, rende migliore la security posture della mia azienda, scopo ultimo se vogliamo parlare realmente di supporto cybersecurity alla PMI.

Off by one

Sulla differenza tra gestione dell’incidente e gestione della vulnerabilità, ci torno con il Monday Blues di questa settimana.

In pillole, quello che dovete fare oggi per migliorare la vostra postura aziendale sui temi di cybersecurity è:

• creare e mantenere un asset inventory che comprenda server, applicazioni web e applicazioni mobile
• scegliere uno strumento per il vulnerability assessment e, periodicamente, manutenere un elenco delle vulnerabilità del software installato a bordo dei vostri server
• utilizzare periodicamente un software per la code review che controlli la vulnerabilità A9 - Insecure della Top 10 Owasp
• definite delle priorità di intervento e agite per mettere in sicurezza l’ecosistema delle vostre applicazioni
• reiterate all’infinito

Se avete dubbi su quale strumento utilizzare o come mettere in piedi questo processo di gestione della vulnerabilità, scrivete a paolo@codiceinsicuro.it o lasciate un commento.

Enjoy it!