{"id":31852,"date":"2019-10-31T21:43:30","date_gmt":"2019-10-31T18:43:30","guid":{"rendered":"https:\/\/prohoster.info\/blog\/strah-i-nenavist-devsecops\/"},"modified":"2019-10-31T21:43:30","modified_gmt":"2019-10-31T18:43:30","slug":"strah-i-nenavist-devsecops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/strah-i-nenavist-devsecops","title":{"rendered":"Paura e odio per DevSecOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Avevamo 2 analizzatori di codice, 4 strumenti per test dinamici, le nostre creazioni e 250 script. Non \u00e8 che tutto questo fosse necessario nel processo attuale, ma dato che ho iniziato a implementare il DevSecOps, bisogna andare fino in fondo.<\/p>\n

\"Paura
\n
\nFonte<\/a><\/noindex>. Gli autori dei personaggi: Justin Roiland e Dan Harmon.<\/i><\/p>\n

Che cos'\u00e8 il SecDevOps? E il DevSecOps? Quali sono le differenze? Sicurezza delle applicazioni: di cosa si tratta? Perch\u00e9 l'approccio classico non funziona pi\u00f9? A tutte queste domande risponde Yuri Shabalin<\/b> da\u00a0Swordfish Security. <\/b>Yuri risponder\u00e0 dettagliatamente a tutto e analizzer\u00e0 i problemi del passaggio dal modello classico di Sicurezza delle Applicazioni al processo DevSecOps: come affrontare correttamente l'integrazione del processo di sviluppo sicuro nel processo DevOps senza rompere nulla, come superare le fasi principali dei test di sicurezza, quali strumenti possono essere utilizzati, in cosa si differenziano e come configurarli correttamente per evitare insidie.
\n<\/a><\/noindex>
\n

\r\n \"Guarda\r\n
<\/div>\r\n <\/div><\/center>
\nSul relatore:<\/b> Yuri Shabalin \u00e8 <\/b>Chief Security Architect presso Swordfish Security<\/b>. Responsabile dell'implementazione dell'SSDL, dell'integrazione generale degli strumenti di analisi delle applicazioni in un'unica ecosistema di sviluppo e test. 7 anni di esperienza nella sicurezza informatica. Ha lavorato in Alfa-Bank, Sberbank e in Positive Technologies, che sviluppa software e fornisce servizi. Relatore a conferenze internazionali ZerONights, PHDays, RISSPA, OWASP.<\/p>\n

Sicurezza delle applicazioni: di cosa si tratta?<\/h2>\n

\nSicurezza delle applicazioni<\/b>\u00a0\u2014 \u00e8 un ramo della sicurezza che si occupa della sicurezza delle applicazioni. Non riguarda l'infrastruttura o la sicurezza di rete, ma specificamente ci\u00f2 che scriviamo e su cui lavorano gli sviluppatori: si tratta dei difetti e delle vulnerabilit\u00e0 dell'applicazione stessa.<\/p>\n

Direzione SDL o SDLC<\/a><\/noindex>\u00a0\u2014 Ciclo di vita dello sviluppo della sicurezza<\/b>\u00a0\u2014 sviluppato dalla Microsoft. Nello schema, c'\u00e8 il modello canonico dell'SDLC, il cui obiettivo principale \u00e8 coinvolgere la sicurezza in ogni fase dello sviluppo, dai requisiti al rilascio e al go-live. Microsoft ha capito che ci sono troppi bug nel mercato, in aumento, e c'era bisogno di fare qualcosa, e ha proposto questo approccio, che \u00e8 diventato canonico.<\/p>\n

\"Paura
\n
\nLa Sicurezza delle Applicazioni e l'SSDL non mirano a scoprire vulnerabilit\u00e0, come comunemente si pensa, ma a prevenire la loro comparsa. Con il tempo, l'approccio canonico di Microsoft \u00e8 stato migliorato e sviluppato, con un'immersione pi\u00f9 profonda e dettagliata.<\/p>\n

\"Paura
\n
\nIl SDLC canonico \u00e8 fortemente dettagliato in diverse metodologie: OpenSAMM, BSIMM, OWASP. Le metodologie sono diverse, ma, in generale, simili.<\/p>\n

Modello di Maturit\u00e0 per la Sicurezza Integrata<\/h3>\n

\nMi piace di pi\u00f9 BSIMM<\/b>\u00a0\u2014 Modello di Maturit\u00e0 per la Sicurezza Integrata<\/a><\/noindex>. La base della metodologia \u00e8 la suddivisione del processo di Sicurezza delle Applicazioni in 4 domini: Governance, Intelligence, SSDL Touchpoints e Deployment. In ogni dominio ci sono 12 pratiche, presentate sotto forma di 112 attivit\u00e0.<\/p>\n

\"Paura
\n
\nOgni attivit\u00e0 delle 112 ha 3 livelli di maturit\u00e0<\/b>: iniziale, intermedio e avanzato. Tutte le 12 pratiche possono essere studiate per sezioni, selezionando gli aspetti pi\u00f9 importanti per te, approfondendo come implementarli e aggiungendo gradualmente elementi, ad esempio, analisi statica e dinamica del codice o code review. Redigi un piano e lavora tranquillamente nell'ambito dell'implementazione delle attivit\u00e0 selezionate.<\/p>\n

Perch\u00e9 DevSecOps<\/h2>\n

<\/p>\n

DevOps \u00e8 un grande processo globale in cui \u00e8 necessario prendersi cura della sicurezza.<\/p><\/blockquote>\n

\nInizialmente DevOps<\/b><\/a><\/noindex> si prevedeva il controllo della sicurezza. Nella pratica, il numero di team di sicurezza era molto inferiore rispetto ad oggi, e agivano non come partecipanti al processo, ma come organo di controllo e supervisione che impone requisiti e verifica la qualit\u00e0 del prodotto alla fine del rilascio. Questo \u00e8 un approccio classico, in cui i team di sicurezza erano separati dallo sviluppo e non partecipavano al processo.<\/p>\n

\"Paura
\n
\nIl problema principale risiede proprio nel fatto che la sicurezza informatica \u00e8 separata dallo sviluppo. Di solito, si tratta di un certo contorno di sicurezza informatica con 2-3 strumenti grandi e costosi. Ogni sei mesi arriva il codice sorgente o un'applicazione da controllare, e una volta all'anno vengono eseguiti test di penetrazione<\/a><\/noindex>. Questo porta al risultato che le tempistiche di rilascio si allungano, e agli sviluppatori vengono scaricate una quantit\u00e0 enorme di vulnerabilit\u00e0 dagli strumenti automatizzati. \u00c8 impossibile gestirle e risolverle, perch\u00e9 i risultati dei precedenti sei mesi non sono stati analizzati, e ora ci sono nuovi problemi.<\/p>\n

Nel processo di lavoro della nostra azienda vediamo che la sicurezza in tutti i settori e industrie comprende che \u00e8 giunto il momento di allinearsi e operare con lo sviluppo come un unico meccanismo - in\u00a0Agile<\/b><\/a><\/noindex>. La paradigma DevSecOps si adatta perfettamente alla metodologia di sviluppo agile, all'implementazione, supporto e partecipazione in ogni rilascio e iterazione.<\/p>\n

\"Paura
\n<\/p>\n

Transizione a DevSecOps<\/h2>\n

\nLa parola pi\u00f9 importante nel Ciclo di Vita dello Sviluppo della Sicurezza \u00e8 \u00abprocesso\u00bb<\/b>. Devi capire questo prima di pensare di acquistare strumenti.<\/p>\n

\u00c8 insufficiente semplicemente integrare gli strumenti nel processo DevOps; \u00e8 fondamentale l'interazione e la comprensione tra i partecipanti al processo.<\/p><\/blockquote>\n

<\/p>\n

Le persone sono pi\u00f9 importanti degli strumenti<\/h3>\n

\nSpesso la pianificazione di un processo di sviluppo sicuro inizia con la selezione e l'acquisto di uno strumento, e termina con tentativi di integrare lo strumento nel processo corrente, che rimangono tali. Questo porta a conseguenze sfortunate, poich\u00e9 ogni strumento ha le proprie peculiarit\u00e0 e limitazioni.<\/p>\n

Un caso comune \u00e8 quando il dipartimento di sicurezza sceglie uno strumento buono e costoso, con ampie funzionalit\u00e0, e si presenta agli sviluppatori per integrarlo nel processo. Ma non funziona: il processo \u00e8 strutturato in modo tale che le limitazioni dello strumento gi\u00e0 acquistato non si adattano all'attuale paradigma.<\/p>\n

Inizia descrivendo quale risultato desideri e come dovrebbe apparire il processo. Questo aiuta a comprendere i ruoli dello strumento e della sicurezza nel processo.<\/p><\/blockquote>\n

<\/p>\n

Comincia con ci\u00f2 che \u00e8 gi\u00e0 in uso<\/h3>\n

\nPrima di acquistare strumenti costosi, dai un'occhiata a ci\u00f2 che hai gi\u00e0. Ogni azienda ha requisiti di sicurezza che devono essere rispettati nello sviluppo, ci sono controlli, penetration test - perch\u00e9 non trasformare tutto questo in una forma comprensibile e utile per tutti?<\/p>\n

Di solito i requisiti sono un grosso documento cartaceo che giace su uno scaffale. C'era un caso in cui ci siamo recati in un'azienda per esaminare i processi e abbiamo chiesto di mostrare i requisiti di sicurezza per il software. Il professionista che se ne occupava ha cercato a lungo:<\/p>\n

\u2014 Ora, da qualche parte nelle note c'era il percorso dove si trova questo documento.<\/i><\/p>\n

Alla fine abbiamo ricevuto il documento dopo una settimana.<\/p>\n

Per requisiti, controlli e altro, crea una pagina, ad esempio su\u00a0Confluence<\/b>\u00a0\u2014 \u00e8 comodo per tutti.<\/p>\n

\u00c8 pi\u00f9 facile riformattare ci\u00f2 che gi\u00e0 esiste e usarlo come punto di partenza.<\/p><\/blockquote>\n

<\/p>\n

Utilizza i Security Champions <\/h3>\n

\nDi solito, in una media azienda con 100-200 sviluppatori lavora un esperto di sicurezza che svolge diverse funzioni e non riesce fisicamente a controllare tutto. Anche se si impegna al massimo, da solo non pu\u00f2 controllare tutto il codice generato dallo sviluppo. Per tali casi \u00e8 stato sviluppato un concetto - Security Champions<\/b><\/a><\/noindex>.<\/p>\n

I Security Champions sono persone all'interno del team di sviluppo che sono interessate alla sicurezza del vostro prodotto.<\/p><\/blockquote>\n

\"Paura
\n
\nIl Security Champion \u00e8 un punto di accesso nel team di sviluppo e un evangelista della sicurezza in un'unica persona.<\/p>\n

Di solito, quando un esperto di sicurezza entra in un team di sviluppo e indica un errore nel codice, riceve una risposta stupita:<\/p>\n

\u2014 E lei chi \u00e8? La vedo per la prima volta. Va tutto bene per me\u2014 il mio Senior ha approvato durante il code review, possiamo andare avanti!<\/i><\/p>\n

Questa \u00e8 una situazione tipica, perch\u00e9 c'\u00e8 molta pi\u00f9 fiducia nei confronti dei Senior o semplicemente dei colleghi con cui uno sviluppatore interagisce costantemente nel lavoro e nel code review. Se invece dell'esperto di sicurezza \u00e8 il Security Champion a segnalare un errore e le sue conseguenze, la sua parola avr\u00e0 pi\u00f9 peso.<\/p>\n

Inoltre, gli sviluppatori conoscono meglio il loro codice rispetto a qualsiasi esperto di sicurezza. Per una persona che ha almeno 5 progetti nello strumento di analisi statica, di solito \u00e8 difficile ricordare tutte le sfumature. I Security Champions conoscono il loro prodotto: come interagisce e cosa guardare per prima cosa\u2014 sono pi\u00f9 efficaci.<\/p>\n

Quindi, prendete in considerazione l'idea di implementare i Security Champions e ampliare l'influenza del team di sicurezza. Anche per il champion stesso \u00e8 utile: sviluppo professionale in un nuovo campo, ampliamento della visione tecnica, potenziamento delle abilit\u00e0 tecniche, di gestione e di leadership, aumento del valore di mercato. \u00c8 un elemento di ingegneria sociale, i vostri \"occhi\" nel team di sviluppo.<\/p>\n

Fasi di testing<\/h2>\n

\nLa paradigma 20 su 80<\/a><\/noindex>\u00a0afferma che il 20% degli sforzi produce l'80% del risultato. Questo 20% sono le pratiche di analisi delle applicazioni che possono e devono essere automatizzate. Esempi di tali attivit\u00e0 sono l'analisi statica\u2014 SAST<\/b>, l'analisi dinamica\u2014 DAST,<\/b> e\u00a0controllo Open Source<\/b>. Spiegher\u00f2 in dettaglio le attivit\u00e0 e gli strumenti, quali peculiarit\u00e0 incontriamo di solito durante la loro implementazione nel processo e come fare le cose nel modo giusto.<\/p>\n

\"Paura
\n<\/p>\n

Problemi principali degli strumenti<\/h3>\n

\nMetter\u00f2 in evidenza i problemi attuali per tutti gli strumenti che richiedono attenzione. Li analizzer\u00f2 in dettaglio, in modo da non ripetermi ulteriormente.<\/p>\n

Tempo lungo di analisi. <\/b>Se dalla commit al rilascio in produzione ci vogliono 30 minuti per tutti i test e la compilazione, allora i controlli sulla sicurezza informatica richiederanno un giorno. Quindi, nessuno rallenter\u00e0 il processo. Tieni presente questa caratteristica e trai le conclusioni.<\/p>\n

Alto livello di False Negative o False Positive. <\/b>Tutti i prodotti sono diversi, tutti utilizzano framework diversi e il proprio stile di scrittura del codice. Su diverse basi di codice e tecnologie, gli strumenti possono mostrare diversi livelli di False Negative e False Positive. Pertanto, guarda cosa mostra precisamente\u00a0la vostra<\/b> azienda e per<\/b> le vostre<\/p>\n

applicazioni un buon e affidabile risultato.<\/b>Nessuna integrazione con gli strumenti esistenti.<\/p>\n

Guarda gli strumenti dal punto di vista delle integrazioni, rispetto a ci\u00f2 che gi\u00e0 utilizzi. Ad esempio, se hai Jenkins o TeamCity, controlla l'integrazione degli strumenti proprio con questo software, e non con GitLab CI, che non usi. <\/b>Mancanza o eccessiva complessit\u00e0 di personalizzazione.<\/p>\n

Se lo strumento non ha API, a cosa serve? Tutto ci\u00f2 che \u00e8 possibile fare nell'interfaccia dovrebbe essere accessibile tramite API. Idealmente, lo strumento dovrebbe avere la possibilit\u00e0 di personalizzare i controlli. <\/b>Nessuna Roadmap per lo sviluppo del prodotto. Roadmap<\/a><\/noindex> Lo sviluppo non sta fermo, utilizziamo sempre nuovi framework e funzionalit\u00e0, riscriviamo il vecchio codice in nuovi linguaggi. Vogliamo essere certi che lo strumento che acquisteremo supporter\u00e0 nuovi framework e tecnologie. Quindi \u00e8 importante sapere che il prodotto ha uno sviluppo reale e corretto.<\/p>\n

Caratteristiche del processo<\/h3>\n

\nOltre alle caratteristiche degli strumenti, considera anche le peculiarit\u00e0 del processo di sviluppo. Ad esempio, ostacolare lo sviluppo \u00e8 un errore comune. Vediamo quali altre caratteristiche dovrebbero essere considerate e su cosa deve prestare attenzione il team di sicurezza.<\/p>\n

Per non ritardare i tempi di sviluppo e di rilascio, crea diverse regole<\/b> e diversi show stoppers\u00a0<\/b>\u2014 criteri di arresto del processo di compilazione in presenza di vulnerabilit\u00e0 \u2014 per diversi ambienti.<\/b>Ad esempio, comprendiamo che il ramo attuale va in ambiente di sviluppo o UAT, quindi non ci fermiamo e non diciamo:<\/p>\n

\u2014 Avete delle vulnerabilit\u00e0 qui, non potrete andare avanti!<\/i><\/p>\n

In questa fase \u00e8 importante informare gli sviluppatori che ci sono problemi di sicurezza a cui vale la pena prestare attenzione.<\/p>\n

La presenza di vulnerabilit\u00e0 non \u00e8 un ostacolo per i test successivi<\/b>: manuali, di integrazione o manuali. D'altra parte, dobbiamo in qualche modo migliorare la sicurezza del prodotto e fare in modo che gli sviluppatori non trascurino ci\u00f2 che la sicurezza trova. Quindi, a volte procediamo in questo modo: nella demo, quando viene rilasciato nell'ambiente di sviluppo, informiamo semplicemente lo sviluppo:<\/p>\n

\u2014 Ragazzi, avete dei problemi, per favore fateci caso.<\/i><\/p>\n

Nella fase UAT mostriamo nuovamente gli avvisi sulle vulnerabilit\u00e0, e nella fase di uscita in produzione diciamo:<\/p>\n

\u2014 Ragazzi, abbiamo avvertito pi\u00f9 volte, non avete fatto nulla \u2014 non vi lasceremo uscire con questo.<\/i><\/p>\n

Parlando di codice e dinamica, \u00e8 necessario mostrare e avvisare sulle vulnerabilit\u00e0 solo delle funzionalit\u00e0 e del codice che sono stati appena scritti in questa funzionalit\u00e0. Se lo sviluppatore ha spostato un pulsante di 3 pixel e noi gli diciamo che ha un\u2019iniezione SQL e che deve correggerlo urgentemente, non \u00e8 corretto. Guardate solo ci\u00f2 che \u00e8 scritto ora e il cambiamento che arriva nell'applicazione.<\/p>\n

Supponiamo che abbiamo un certo difetto funzionale: ovvero come l'applicazione non dovrebbe funzionare: il denaro non viene trasferito, non c'\u00e8 transizione alla pagina successiva cliccando sul pulsante o il prodotto non viene caricato. I difetti di sicurezza<\/b>\u00a0\u2014 sono difetti simili, ma non in relazione al funzionamento dell'applicazione, ma alla sicurezza. <\/p>\n

Non tutti i problemi di qualit\u00e0 del software sono problemi di sicurezza. Ma tutti i problemi di sicurezza sono legati alla qualit\u00e0 del software. Sherif Mansour, Expedia.<\/p><\/blockquote>\n

\nPoich\u00e9 tutte le vulnerabilit\u00e0 sono difetti simili, devono trovarsi l\u00e0 dove si trovano tutti i difetti di sviluppo. Quindi dimenticate i report e i terribili PDF che nessuno legge.<\/p>\n

\"Paura
\n
\nQuando lavoravo in un'azienda che si occupava di sviluppo, ho ricevuto un report dagli strumenti di analisi statica. L'ho aperto, sono rimasto scioccato, ho fatto un caff\u00e8, ho sfogliato 350 pagine, l'ho chiuso e sono tornato a lavorare. Grandi report sono report morti<\/b>. Di solito non vanno da nessuna parte, le email vengono eliminate, dimenticate, perse o il business dice che accetta i rischi.<\/p>\n

Cosa fare? I difetti confermati che abbiamo trovato vengono semplicemente trasformati in una forma utile per lo sviluppo, ad esempio, li accumuliamo nel backlog di Jira. I difetti vengono prioritizzati e risolti in base all'ordine di priorit\u00e0 insieme ai difetti funzionali e ai difetti dei test.<\/p>\n

Analisi statica - SAST<\/h2>\n

\n\u00c8 l'analisi del codice per identificare vulnerabilit\u00e0<\/b>, ma non \u00e8 la stessa cosa di SonarQube. Non controlliamo solo in base a modelli o stili. Durante l'analisi vengono applicati vari approcci: basati sull'albero delle vulnerabilit\u00e0, su\u00a0DataFlow<\/a><\/noindex>, sull'analisi dei file di configurazione. Questo \u00e8 tutto ci\u00f2 che riguarda direttamente il codice.<\/p>\n

Vantaggi dell'approccio<\/b>: identificazione delle vulnerabilit\u00e0 nel codice in una fase iniziale dello sviluppo<\/b>, quando non ci sono ancora ambienti e strumenti pronti, e\u00a0possibilit\u00e0 di scansione incrementale<\/b>: scansione della porzione di codice che \u00e8 cambiata, e solo della funzionalit\u00e0 che stiamo attualmente sviluppando, il che riduce il tempo di scansione.<\/p>\n

Contro<\/b>\u00a0\u2014 \u00e8 l'assenza di supporto per i linguaggi necessari.<\/p>\n

Integrazioni necessarie, <\/b>che dovrebbero esserci negli strumenti, secondo il mio parere soggettivo:<\/p>\n