Spostamento a sinistra: SDLC sicuro spiegato

Il 2 aprile 2020 abbiamo ospitato il nostro webinar "Shift Left: Secure SDLC Explained", in cui il nostro esperto di sicurezza del software Tim Hemel ha discusso i vantaggi dello 'shifting left': affrontare la sicurezza all'inizio del processo. Abbiamo ricevuto molte domande, alle quali Tim ha risposto volentieri e che abbiamo riportato di seguito. Se ha ancora delle domande, la preghiamo di contattare cybersecurity@bureauveritas.com.

QandA

Pratiche di sicurezza

È necessario applicare una difesa di sicurezza personalizzata per ogni applicazione?
Ogni applicazione è diversa, quindi la risposta sarebbe 'sì'. D'altra parte, ci sono molte applicazioni simili e possiamo riutilizzare molte strategie di difesa in queste applicazioni. Le applicazioni all'interno di un'organizzazione differiscono soprattutto per la loro funzionalità, e questo significa che avranno requisiti di sicurezza diversi. Se i team si specializzano in determinate tecnologie, le loro applicazioni saranno simili da un punto di vista tecnologico, e a livello architettonico la sicurezza sarà molto simile. All'inizio la maggior parte delle minacce e delle difese sembreranno nuove, ma man mano che si cresce in questo processo di sviluppo sicuro, si inizieranno a vedere le somiglianze e a farle crescere in soluzioni standardizzate per il proprio ambiente, che si possono riutilizzare. Questo le permette di fare sicurezza più velocemente e di avere spazio per fare più sicurezza.

Abbiamo bisogno di strumenti di terze parti personalizzati per i nostri security testing? Ad esempio, per una particolare applicazione abbiamo iniziato la nostra analisi del codice con Checkmarx e la volta successiva lo facciamo con un'applicazione open source?
È una domanda difficile a cui rispondere, dipende dalle circostanze. Se vuole sapere qual è l'impatto del cambio di strumento invece di utilizzare sempre lo stesso strumento, il primo problema che vedo è che sarebbe più difficile confrontare i risultati di test diversi. D'altra parte, credo che dovrebbe provare a eseguire più strumenti e vedere quale funziona meglio per lei. Naturalmente, può eseguire più strumenti sullo stesso codice e confrontarli. La valutazione di uno strumento è una storia complessa. Non si tratta solo dei risultati di uno strumento, ma anche dei costi, delle possibilità di integrazione e della facilità d'uso. Se ci concentriamo sui risultati dello strumento, è difficile valutare uno strumento. Si vuole che lo strumento fornisca il maggior numero possibile di risultati, ma devono essere anche risultati utili. Senza ulteriori competenze e test manuali, è difficile dire se lo strumento ha segnalato tutte le debolezze e le vulnerabilità. È possibile aumentarne alcune tramite la personalizzazione, ad esempio, delle regole di scansione, ma per il resto dovrà fidarsi dello strumento. Le scoperte di sicurezza mancate sono invisibili. I falsi positivi, invece, sono molto visibili. Se vogliamo ridurli, rischiamo di perdere alcuni risultati effettivi, ma dover elaborare molti falsi positivi è un lavoro che non vogliamo fare. Una via d'uscita da questo dilemma è quella di eseguire uno strumento con meno regole, in modo da avere meno risultati, ma almeno utili. Poi, una volta ogni tanto, esegua lo strumento con tutte le regole ed elabori tutti i risultati. Utilizzi il feedback per mettere a punto le regole per i test regolari.

Dobbiamo avere le stesse pratiche di sicurezza per tutte le nostre applicazioni, o possiamo averne di diverse per ogni applicazione, ad esempio per ridurre l'impatto finanziario di queste pratiche?
Il vantaggio di un insieme standard di pratiche di sicurezza è che è chiaro cosa fare e facile da valutare. Allo stesso tempo, per alcune applicazioni, l'esecuzione di tutte queste pratiche potrebbe essere più costosa del necessario. Pertanto, dobbiamo trovare una via di mezzo. Cerchi di standardizzare il maggior numero possibile di pratiche, ma veda dove è necessario concentrarsi. Alcune applicazioni traggono maggiori benefici dalla modellazione precoce delle minacce, mentre altre hanno più bisogno di secure code review e security testing, perché hanno un design stabile. Può anche variare l'intensità delle pratiche. Ad esempio, per le applicazioni web con un profilo di rischio più basso, può eseguire un test contro OWASP ASVS di livello 1, mentre le applicazioni a rischio più elevato avranno bisogno di un test di livello 2. Vogliamo ottenere il miglior valore di sicurezza entro i nostri limiti di budget e dobbiamo spendere le nostre risorse in modo saggio. Pertanto, bisogna considerare il rischio dell'applicazione, il suo stato di sviluppo e valutare quali pratiche apportano i maggiori benefici.

Nel webinar non ha parlato dell'implementazione sicura, come viene gestita in azienda?
L'OWASP SAMM menziona l'implementazione sicura, quindi è sicuramente qualcosa a cui prestare attenzione. Purtroppo abbiamo dovuto essere selettivi sulle pratiche da discutere nel webinar. SAMM consiglia di automatizzare il processo di distribuzione per eliminare la principale causa di problemi di sicurezza: gli errori umani. Queste pratiche sono simili a ciò che facciamo in un modo di lavorare DevOps e possiamo imparare molto da DevOps. Naturalmente, dovrà comunque assicurarsi che ciò che distribuisce automaticamente sia sicuro: un ambiente protetto con un'installazione sicura del suo software.

Dovrebbe quindi testare anche gli strumenti automatizzati per la distribuzione?
Con la distribuzione automatizzata, ha delegato il suo processo al software. Se prima gli operatori con intenzioni malevole avevano tutto il potere di abusare del sistema, ora tali attacchi richiedono di abusare del software di distribuzione. Si tratta di una barriera in più, ma se gli insider malintenzionati sono una minaccia realistica, deve tenerne conto e sottoporre il suo software di distribuzione allo stesso controllo del software che sta distribuendo.

È questo il primo passo verso il devsecops se un'organizzazione lavora in devops? E quali passi sono necessari per passare a devsecops?
Se legge la letteratura DevOps, come il Progetto Phoenix, scoprirà che la "sicurezza incorporata" è sempre stata parte di DevOps. SecDevOps e DevSecOps sono fondamentalmente la stessa cosa, ma con maggiore enfasi sulla sicurezza. Ma in realtà, molte delle tecniche di DevOps si applicano anche alle pratiche di sicurezza. Si possono eliminare i colli di bottiglia e migliorare le comunicazioni tra sviluppo, operazioni e sicurezza nello stesso modo in cui si migliorano quelle tra sviluppo e operazioni. Può applicare tecniche come la 'mappatura del flusso di valore' per identificare i problemi di flusso e modificare le pratiche di sicurezza, ad esempio spostandole più a sinistra. La creazione di una cultura di collaborazione è ancora più importante quando entra in gioco la sicurezza, perché spesso vediamo i risultati della sicurezza come critiche. Molte persone nella comunità della sicurezza purtroppo hanno ancora una mentalità poco collaborativa, ma spero che questo cambi.

Formazione

Perché la formazione delle persone sulla codifica sicura non è sufficiente?
Non tutti i problemi di sicurezza nelle applicazioni sono legati a un codice insicuro. Come descrive Gary McGraw nel suo libro "Software Security - Building Security In", Microsoft ha riferito che oltre il 50% dei problemi di sicurezza durante la sua famosa spinta alla sicurezza (https://www.wired.com/2002/01/bill-gates-trustworthy-computing/) erano il risultato di problemi architetturali e non di codice. Pertanto, non si tratta solo di codifica sicura, ma anche di progettazione e requisiti sicuri.

Organizzazione del team

Ha bisogno di un hacker nel suo team?
Ovviamente dipende dalla definizione di 'hacker'. Deve essere in grado di identificare e prevenire i bug di sicurezza, ma non necessariamente di exploitarli con le tecniche più avanzate. In alcuni casi, avrà bisogno di queste conoscenze, ma nella maggior parte dei casi è più efficace individuare un potenziale problema e risolverlo, piuttosto che stabilire realmente l'exploit di un potenziale attacco. Per questo, non è necessario sapere come scrivere exploit zero-day e altri fantasiosi trucchi da hacker. Quindi le conoscenze di cui abbiamo bisogno nel nostro team non sono necessariamente conoscenze da hacker. La conoscenza della programmazione è importante per capire come risolvere i problemi. Molte persone con le competenze di hacking discusse sopra non hanno queste conoscenze. È più facile insegnare a uno sviluppatore come individuare e prevenire i problemi di sicurezza che insegnare a un hacker come programmare. Pertanto, direi che avere un hacker nel suo team non è necessario. Tuttavia, sapere cosa può fare un hacker e capire come funziona in pratica è un esercizio di awareness molto utile. Le dà un'idea della facilità di exploit di alcuni problemi e quindi del rischio che potrebbe correre. Quindi, acquisire un po' di 'mentalità da hacker' può essere utile. Il consiglio di "pensare come un hacker" suona bene, ma non funziona bene nella pratica. Adam Shostack lo paragona al pensare come uno chef professionista (https://adam.shostack.org/blog/2008/09/think-like-an-attacker/). Prima di poter cucinare un buon piatto in modo coerente, è necessario avere esperienza e conoscenza. Come sviluppatori, non abbiamo tempo o interesse per questo. Ciò non significa che non possiamo imparare a sviluppare in modo sicuro, ma solo che dobbiamo imparare in un modo che si adatti al nostro modo di lavorare.

Il master SCRUM può svolgere il ruolo di campione di sicurezza?
Ciò che è importante nel ruolo di campione della sicurezza è garantire la disponibilità di conoscenze sulla sicurezza e avere qualcuno responsabile di portare avanti il processo. Il compito di uno SCRUM master è quello di facilitare il processo di sviluppo e di eliminare qualsiasi ostacolo. Quindi, per questa parte dei compiti del campione di sicurezza, un master SCRUM sarebbe una buona scelta. Non è necessario affidare tutti i compiti del campione di sicurezza a una sola persona. Può assegnarli a più persone o addirittura renderli un esercizio a turni. Chiunque indossi il cappello della sicurezza in questo sprint, dovrà mantenere la sicurezza. Questo renderà la sicurezza una responsabilità condivisa. Come può vedere, ci sono molti modi per gestire questo aspetto e, purché si assicuri che i compiti del campione vengano svolti, scelga quello che funziona nella sua organizzazione.

Un campione di sicurezza può lavorare in un team diverso da quello di sviluppo del software?
L'ideale sarebbe che il campione lavorasse il più possibile a stretto contatto con il team, e se può farlo da un team diverso, non vedo problemi. A volte si vede un team dedicato alla sicurezza del software che aiuta più team contemporaneamente. È un modo per utilizzare in modo ottimale la carenza di campioni di sicurezza. Il team può avere degli 'orari d'ufficio' per aiutare i team e assisterli nelle attività di sicurezza, come il Threat Modeling.

Se l'azienda è abbastanza grande, è opportuno avere un "Dipartimento dei campioni della sicurezza" (una sorta di Dipartimento di eccellenza)?
In effetti, nel libro 'Secure Software - Building Security In', Gary McGraw suggerisce di creare un dipartimento di questo tipo, chiamato 'secure software group'. Per le piccole organizzazioni, un reparto separato può essere costoso, quindi in seguito è stato introdotto il concetto di campione di sicurezza. Ora stiamo scoprendo che la domanda di specialisti della sicurezza ha superato l'offerta, e dobbiamo trovare il modo di scalare la disponibilità di questa competenza. Un modo è avere un gruppo di sicurezza del software. Un altro modo è quello di avere nei team membri che svolgono attività di sicurezza con un livello di competenza inferiore, e che gli esperti lavorino su questioni più impegnative. In altre parole, si crea una gerarchia di competenze.

Standard e Quadri

Perché ha scelto OWASP SAMM?
Mi piace la struttura, perché si adatta bene alle fasi di sviluppo del software. In ognuna delle fasi di sviluppo possiamo commettere diversi errori e SAMM suggerisce le pratiche corrispondenti per prevenirli. Dalla versione 2, è maturato molto e credo che fornisca una struttura praticabile. Si noti che SAMM parla solo del processo di sviluppo, ossia del tipo di attività che potrebbe svolgere, ma non le dice in dettaglio come svolgerle effettivamente.

Supponiamo di seguire un processo di sviluppo sicuro e maturo. Come possiamo misurare/dimostrare il livello di sicurezza di questo software? Poiché il SAMM di OWASP parla solo del processo, abbiamo bisogno di qualcosa di diverso per misurare la sicurezza del software stesso. Nel 2014, ho fatto un tentativo in tal senso. Abbiamo pubblicato il "Framework Secure Software", un documento che aiutava gli sviluppatori di software a rendere il loro software più sicuro e a dimostrare quanto fosse sicuro il loro software. Al centro di questo documento c'erano pratiche come i requisiti di sicurezza, il Threat Modeling, il codice sicuro e il testing. L'idea centrale è quella di tenere traccia delle minacce che ci si può aspettare dal proprio software, di come mitigarle e di come verificare che la mitigazione funzioni. Rendendo la sicurezza visibile in questo modo, può conoscere lo stato della sicurezza in qualsiasi momento del processo di sviluppo e sapere anche quando è sufficiente. Questo rende anche la sicurezza più gestibile. Dovrà comunque personalizzare le pratiche, a seconda del tipo di applicazione, delle tecnologie, dell'ambiente e del profilo di rischio. Per le applicazioni web, ad esempio, ci piace seguire l'ASVS di OWASP, perché copre molti potenziali errori di sicurezza. Per altri tipi di applicazioni, come quelle mobili o desktop, sarà necessario adottare standard diversi o creare elenchi propri.

Se ha altre domande, ci contatti all'indirizzo cybersecurity@bureauveritas.com.