{"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 il 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 che tutto questo fosse necessario nel processo attuale, ma una volta iniziato a implementare il DevSecOps, bisogna andare fino in fondo.<\/p>\n

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

Cosa \u00e8 SecDevOps? E DevSecOps? Quali sono le differenze? Sicurezza delle applicazioni: di cosa si tratta? Perch\u00e9 l'approccio classico non funziona pi\u00f9? Queste sono tutte domande a cui Yuri Shabalin<\/b> di\u00a0Swordfish Security. <\/b>Yuri risponder\u00e0 a tutto e analizzer\u00e0 le problematiche della transizione 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 fondamentali di 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 \"Riproduci\r\n
<\/div>\r\n <\/div><\/center>
\nSul relatore:<\/b> Yuri Shabalin \u00e8 <\/b>Chief Security Architect presso Swordfish Security<\/b>. Si occupa dell'implementazione di 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 come ZerONights, PHDays, RISSPA, OWASP.<\/p>\n

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

\nSicurezza delle Applicazioni<\/b>\u00a0\u00e8 una branca della sicurezza che si occupa della sicurezza delle applicazioni. Non si riferisce all'infrastruttura o alla sicurezza di rete, ma specificamente a ci\u00f2 che scriviamo e su cui lavorano gli sviluppatori, cio\u00e8 ai difetti e alle vulnerabilit\u00e0 dell'applicazione stessa.<\/p>\n

Direzione SDL o SDLC<\/a><\/noindex>\u00a0\u2014 Ciclo di vita dello sviluppo della sicurezza<\/b>\u00a0\u00e8 stato sviluppato da Microsoft. Nello schema si vede il modello canonico del SDLC, il cui obiettivo principale \u00e8 garantire che la sicurezza sia integrata in ogni fase dello sviluppo, dai requisiti al rilascio e all'entrata in produzione. Microsoft ha riconosciuto che ci sono troppi bug nel mercato, che stanno aumentando e che \u00e8 necessario intervenire, e ha proposto questo approccio che \u00e8 diventato canonico.<\/p>\n

\"Paura
\n
\nLa sicurezza delle applicazioni e SSDL non sono rivolte alla rilevazione delle vulnerabilit\u00e0, come comunemente si pensa, ma alla prevenzione della loro comparsa. Nel tempo, l'approccio canonico di Microsoft \u00e8 stato migliorato e sviluppato, con un'approfondita immersione nei dettagli.<\/p>\n

\"Paura
\n
\nIl SDLC canonico \u00e8 molto dettagliato in varie metodologie \u2014 OpenSAMM, BSIMM, OWASP. Le metodologie differiscono, ma, in generale, sono simili.<\/p>\n

Building Security In Maturity Model<\/h3>\n

\nMi sta pi\u00f9 a cuore BSIMM<\/b>\u00a0\u2014 Building Security In Maturity Model<\/a><\/noindex>. La base della metodologia consiste nella suddivisione del processo di sicurezza delle applicazioni in 4 domini: Governance, Intelligence, SSDL Touchpoints e Deployment. In ogni dominio ci sono 12 pratiche, presentate in 112 attivit\u00e0.<\/p>\n

\"Paura
\n
\nOgni una delle 112 attivit\u00e0 ha 3 livelli di maturit\u00e0<\/b>: iniziale, medio e avanzato. Tutte e 12 le pratiche possono essere studiate per sezioni, selezionando gli aspetti importanti per voi, approfondendo come implementarli e aggiungendo gradualmente elementi come l'analisi statica e dinamica del codice o la code review. Definite un piano e lavorate serenamente con l'implementazione delle attivit\u00e0 selezionate.<\/p>\n

Perch\u00e9 DevSecOps<\/h2>\n

<\/p>\n

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

\nOriginariamente DevOps<\/b><\/a><\/noindex> Si prevedevano controlli di sicurezza. In pratica, il numero dei team di sicurezza era molto inferiore rispetto a oggi, e agivano pi\u00f9 come un ente di controllo e vigilanza, che stabilisce i requisiti e verifica la qualit\u00e0 del prodotto alla fine del rilascio. Questo \u00e8 un approccio classico, in cui i team di sicurezza si trovavano dietro le quinte dello sviluppo e non partecipavano al processo.<\/p>\n

\"Paura
\n
\nIl problema principale risiede nel fatto che la sicurezza informatica \u00e8 separata dallo sviluppo. Di solito esiste un certo contorno di sicurezza informatica con 2-3 grandi e costosi strumenti. Ogni sei mesi si riceve il codice sorgente o l'applicazione da controllare, e una volta all'anno si effettuano penetration test<\/a><\/noindex>. Questo porta al fatto che i tempi di rilascio vengono posticipati, e agli sviluppatori si accumulano un'enorme quantit\u00e0 di vulnerabilit\u00e0 da strumenti automatizzati. \u00c8 tutto impossibile da analizzare e correggere, poich\u00e9 non si sono ancora esaminati i risultati dei sei mesi precedenti, e ora arriva un nuovo carico.<\/p>\n

Nel corso dell'attivit\u00e0 della nostra azienda, osserviamo che la sicurezza in tutti i settori e le industrie riconosce che \u00e8 arrivato il momento di unirsi e lavorare insieme nello sviluppo - nel\u00a0Agile<\/b><\/a><\/noindex>. Il paradigma DevSecOps si integra perfettamente con la metodologia di sviluppo agile, nella sua implementazione, supporto e partecipazione ad ogni rilascio e iterazione.<\/p>\n

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

Transizione a DevSecOps<\/h2>\n

\nLa parola pi\u00f9 importante nel Security Development Lifecycle \u00e8 \u00abprocesso\u00bb<\/b>. Devi capirlo prima di pensare di acquistare strumenti.<\/p>\n

\u00c8 semplicemente insufficiente inserire strumenti nel processo DevOps - \u00e8 fondamentale la collaborazione 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 del processo di sviluppo sicuro inizia con la scelta e l'acquisto di uno strumento, ma termina con tentativi di integrare lo strumento nel processo attuale, che rimangono tentativi. Questo porta a conseguenze negative, 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 costoso e di alta qualit\u00e0 con ampie funzionalit\u00e0 e si rivolge agli sviluppatori per integrarlo nel processo. Ma non funziona: il processo \u00e8 strutturato in modo tale che le restrizioni 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 aiuter\u00e0 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, guarda a ci\u00f2 che hai gi\u00e0. Ogni azienda ha requisiti di sicurezza per lo sviluppo, ci sono controlli, penetration test \u2014 perch\u00e9 non trasformare tutto questo in una forma comprensibile e utile per tutti?<\/p>\n

Di solito, i requisiti sono un documento cartaceo che viene lasciato sullo scaffale. C'\u00e8 stata una volta in cui siamo stati in un'azienda per esaminare i processi e abbiamo chiesto di mostrare i requisiti di sicurezza per il software. Il specialista responsabile ha cercato a lungo:<\/p>\n

\u2014 Adesso, c'era da qualche parte nelle note il percorso per trovare questo documento.<\/i><\/p>\n

Alla fine abbiamo ottenuto 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 semplice riformattare ci\u00f2 che \u00e8 gi\u00e0 disponibile e utilizzarlo come punto di partenza.<\/p><\/blockquote>\n

<\/p>\n

Utilizza i Security Champions <\/h3>\n

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

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

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

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

\u2014 Chi sei? Ti vedo per la prima volta. Per me va tutto bene \u2014 il mio senior mi ha dato un 'apply' durante il code review, andiamo avanti!<\/i><\/p>\n

Questa \u00e8 una situazione tipica, poich\u00e9 c'\u00e8 molta pi\u00f9 fiducia nei confronti dei senior o semplicemente dei colleghi del team con cui il sviluppatore interagisce costantemente nel lavoro e nelle revisioni del codice. Se il Security Champion indica un errore e le conseguenze invece del responsabile della sicurezza, la sua parola avr\u00e0 pi\u00f9 peso.<\/p>\n

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

Quindi riflettete sull'introduzione di Security Champions e sull'ampliamento dell'influenza del team di sicurezza. Per il campione stesso \u00e8 anche vantaggioso: sviluppo professionale in un nuovo campo, ampliamento delle competenze tecniche, potenziamento delle abilit\u00e0 tecniche, gestionali e di leadership, aumento del valore sul mercato. Questo \u00e8 un elemento di ingegneria sociale, i vostri \u00abocchi\u00bb nel team di sviluppo.<\/p>\n

Fasi di test<\/h2>\n

\nParadigma 20 su 80<\/a><\/noindex>\u00a0afferma che il 20% degli sforzi produce l'80% dei risultati. Questo 20% comprende le pratiche di analisi delle applicazioni che possono e devono essere automatizzate. Esempi di tali attivit\u00e0 includono l'analisi statica \u2014 SAST<\/b>, l'analisi dinamica \u2014 DAST,<\/b> e\u00a0il controllo delle risorse Open Source<\/b>. Spiegher\u00f2 pi\u00f9 nel dettaglio le attivit\u00e0, cos\u00ec come gli strumenti e le peculiarit\u00e0 che incontriamo di solito nel loro implemento nel processo, e come farlo correttamente.<\/p>\n

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

Principali problemi degli strumenti<\/h3>\n

\nEvidenzier\u00f2 i problemi attuali comuni a tutti gli strumenti che richiedono attenzione. Analizzer\u00f2 questi problemi pi\u00f9 a fondo per evitare ripetizioni.<\/p>\n

Lunghe tempistiche di analisi. <\/b>Se dal commit al rilascio in produzione passano 30 minuti per tutti i test e la compilazione, i controlli di sicurezza informatica richiederanno giorni. Nessuno vorr\u00e0 rallentare il processo. Tenete presente questa peculiarit\u00e0 e fate le dovute considerazioni.<\/p>\n

Alto livello di False Negative o False Positive. <\/b>Tutti i prodotti sono diversi, utilizzano framework diversi e il proprio stile di scrittura del codice. Su basi di codice e tecnologie diverse, gli strumenti possono mostrare differenti livelli di False Negative e False Positive. Pertanto, osservate ci\u00f2 che \u00e8 specifico nella\u00a0vostra<\/b> azienda e per i vostri<\/b> le applicazioni mostreranno risultati buoni e affidabili.<\/p>\n

Nessuna integrazione con strumenti esistenti.<\/b>. Esamina gli strumenti dal punto di vista delle integrazioni, considerando ci\u00f2 che gi\u00e0 utilizzi. Ad esempio, se hai Jenkins o TeamCity, controlla l'integrazione degli strumenti con questo software specifico, non con GitLab CI, che non stai usando.<\/p>\n

Mancanza o eccessiva complessit\u00e0 nella personalizzazione. <\/b>Se uno strumento non ha API, a cosa serve? Tutto ci\u00f2 che pu\u00f2 essere fatto nell'interfaccia deve essere accessibile tramite API. Idealmente, lo strumento dovrebbe avere la possibilit\u00e0 di personalizzare i controlli.<\/p>\n

Nessun Roadmap per lo sviluppo del prodotto. <\/b>Lo sviluppo non si ferma mai; 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. Pertanto, \u00e8 importante sapere che il prodotto ha un reale e valido Roadmap<\/a><\/noindex> di sviluppo.<\/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 dovremmo considerare e su cosa prestare attenzione per il team di sicurezza.<\/p>\n

Per non compromettere le scadenze di sviluppo e rilascio, crea regole diverse<\/b> e differenti show stoppers\u00a0<\/b>\u2014 criteri di interruzione del processo di build in presenza di vulnerabilit\u00e0 \u2014 per diversi ambienti<\/b>. Ad esempio, comprendiamo che l'attuale ramo \u00e8 destinato a un ambiente di sviluppo o UAT, quindi non ci fermiamo e non diciamo:<\/p>\n

\u2014 Avete qui delle vulnerabilit\u00e0, non andrete oltre!<\/i><\/p>\n

In questa fase, \u00e8 importante segnalare agli sviluppatori che ci sono problematiche di sicurezza a cui 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 trovare un modo per aumentare la sicurezza del prodotto, affinch\u00e9 gli sviluppatori non trascurino ci\u00f2 che rileva la sicurezza. Quindi, a volte procediamo in questo modo: nell'ambiente, quando viene distribuito sull'ambiente di sviluppo, informiamo semplicemente lo sviluppo:<\/p>\n

\u2014 Ragazzi, se avete problemi, vi preghiamo di prestarvi attenzione.<\/i><\/p>\n

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

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

Se parliamo di codice e di dinamica, dobbiamo 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 gli diciamo che ha un'iniezione SQL e quindi deve correggere urgentemente \u2014 non \u00e8 corretto. Guardate solo a ci\u00f2 che \u00e8 stato scritto ora e al cambiamento che arriva nell'applicazione.<\/p>\n

Supponiamo di avere un difetto funzionale \u2014 come non dovrebbe funzionare l'applicazione: i soldi non vengono trasferiti, al clic su un pulsante non si passa alla pagina successiva o il prodotto non viene caricato. Difetti di sicurezza<\/b>\u00a0\u2014 sono difetti uguali, ma non in termini di funzionamento dell'applicazione, bens\u00ec di 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, devono trovarsi nello stesso luogo in cui si trovano tutti i difetti di sviluppo. Quindi dimenticatevi di report e dei terribili PDF che nessuno legge.<\/p>\n

\"Paura
\n
\nQuando lavoravo in una societ\u00e0 di sviluppo, ricevetti un report dagli strumenti di analisi statici. L'ho aperto, mi sono spaventato, ho fatto un caff\u00e8, ho sfogliato 350 pagine, l'ho chiuso e sono tornato a lavorare. I grandi report sono report morti<\/b>. Di solito non vanno da nessuna parte, le e-mail vengono eliminate, dimenticate, perse, o il business dice che si assume i rischi.<\/p>\n

Cosa fare? I difetti confermati che sono stati trovati vengono semplicemente trasformati in un formato utile per lo sviluppo, ad esempio accumulandoli nel backlog in Jira. Prioritizziamo e risolviamo i difetti in base all'ordine di priorit\u00e0, insieme ai difetti funzionali e ai difetti di test.<\/p>\n

Analisi statica - SAST<\/h2>\n

\n\u00c8 un'analisi del codice per la presenza di vulnerabilit\u00e0<\/b>, ma non \u00e8 la stessa cosa di SonarQube. Non controlliamo solo i pattern o lo stile. Durante l'analisi vengono applicati diversi approcci: 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 nelle fasi iniziali dello sviluppo<\/b>, quando non ci sono ancora ambienti e strumenti pronti, e\u00a0possibilit\u00e0 di scansione incrementale<\/b>: scansione della parte di codice che \u00e8 cambiata e solo della funzionalit\u00e0 su cui stiamo lavorando, il che riduce il tempo di scansione.<\/p>\n

Svantaggi<\/b>\u00a0\u2014 \u00e8 la mancanza di supporto per i linguaggi necessari.<\/p>\n

Integrazioni necessarie, <\/b>che dovrebbero esistere negli strumenti, secondo la mia opinione soggettiva:<\/p>\n