Avemu avutu 2 analizzatori di codice, 4 strumenti di teste dinamichi, i nostri articuli è 250 scripts. Micca chì tuttu questu era necessariu in u prucessu attuale, ma quandu avete principiatu à implementà DevSecOps, avete bisognu à andà à a fine.
. I caratteri creati da Justin Roiland è Dan Harmon.
Cosa hè SecDevOps? E DevSecOps? Chì sò e diffirenzii ? Sicurezza di l'applicazioni - di cosa si tratta? Perchè l'approcciu classicu ùn funziona più ? Tutte queste dumande cunnoscenu a risposta Yuri Shabalin из Sicurezza di pesciu spada. Yuriy hà da risponde à tuttu in dettagliu è analizà i prublemi di transizione da u mudellu classicu di Sicurezza di l'Applicazione à u prucessu DevSecOps: cumu avvicinà bè l'integrazione di u prucessu di sviluppu sicuru in u prucessu DevOps è ùn rompe nunda, cumu passà per e tappe principali. di teste di sicurezza, quali strumenti ponu esse aduprati, cumu si sò diffirenti è cumu cunfigurà bè per evità insidie.
À propositu di parlante: Yuri Shabalin - Chief Security Architect in a cumpagnia Sicurezza di pesciu spada. Responsabile per l'implementazione di SSDL, per l'integrazione generale di l'arnesi di analisi di l'applicazioni in un unicu ecosistema di sviluppu è teste. 7 anni di sperienza in sicurezza di l'infurmazioni. Hà travagliatu in Alfa-Bank, Sberbank è Tecnologie Positive, chì sviluppa software è furnisce servizii. Relatore di cunferenze internaziunali ZerONights, PHDays, RISSPA, OWASP.
Sicurezza di l'applicazioni: di cosa si tratta?
Sicurità di Applicazioni hè a sezione di sicurità chì hè rispunsevule per a sicurità di l'applicazioni. Ùn si tratta micca di l'infrastruttura o di a sicurità di a rete, ma di ciò chì scrivimu è ciò chì i sviluppatori travaglianu - sò i difetti è i vulnerabili di l'applicazione stessa.
Direzione - Ciclu di vita di sviluppu di sicurità - Sviluppatu da Microsoft. U diagramma mostra u mudellu SDLC canonicu, u compitu principale di quale hè a participazione di a sicurità in ogni stadiu di u sviluppu, da i bisogni, à liberazione è liberazione à a produzzione. Microsoft hà capitu chì ci sò troppu bugs in u prom, ci sò più di elli è qualcosa deve esse fattu per questu, è pruposti stu approcciu, chì hè diventatu canonicu.
A Sicurezza di l'Applicazione è SSDL ùn sò micca destinati à detectà e vulnerabilità, cum'è cumu si crede, ma à prevene a so occurrence. À u tempu, l'approcciu canonicu da Microsoft hè statu migliuratu, sviluppatu, hà una immersione dettagliata più profonda.
U SDLC canonicu hè assai detallatu in diverse metodologie - OpenSAMM, BSIMM, OWASP. I metodulugii sò diffirenti, ma sò generalmente simili.
Building Security In Maturità Modellu
Mi piace u più BSIMM - . A basa di a metodulugia hè a divisione di u prucessu di Sicurezza di l'Applicazione in 4 duminii: Governance, Intelligence, SSDL Touchpoints and Deployment. Ogni duminiu hà 12 pratiche, chì sò rapprisintati cum'è 112 attività.
Ciascuna di e 112 attività hà 3 livelli di maturità: principianti, intermedi è avanzati. Pudete studià tutte e pratiche 12 in sezzioni, selezziunate e cose chì sò impurtanti per voi, scopre cumu implementà è aghjunghje gradualmente elementi, per esempiu, analisi di codice staticu è dinamicu o revisione di codice. Elaborate un pianu è travagliate in cunfurmità cum'è parte di l'implementazione di l'attività selezziunata.
Perchè DevSecOps
DevOps hè un grande prucessu generale in quale a sicurità deve esse cura.
nizziarmenti implicate cuntrolli di sicurità. In pratica, u numeru di squadre di sicurità era assai più chjucu cà avà, è ùn anu micca agitu cum'è participanti in u prucessu, ma cum'è un corpu di cuntrollu è di vigilanza chì face richieste è verifica a qualità di u pruduttu à a fine di a liberazione. Questu hè un accostu classicu in quale e squadre di sicurezza eranu daretu à un muru da u sviluppu è ùn anu micca participatu à u prucessu.
U prublema principali hè chì a sicurità di l'infurmazioni hè separata da u sviluppu. Di solitu questu hè un tipu di circuitu IB è cuntene 2-3 strumenti grande è caru. Una volta ogni sei mesi, u codice fonte o l'appiecazione vene per esse pruvatu, è una volta à l'annu . Tuttu chistu porta à u fattu chì e date di liberazione per l'industria sò postponate, è un gran numaru di vulnerabilità da l'arnesi automatizati cascanu nantu à u sviluppatore. Hè impussibile di disassemble è riparà tuttu questu, perchè ancu in i sei mesi precedenti i risultati ùn sò micca stati dismantellati, è quì hè un novu batch.
In u prucessu di u travagliu di a nostra cumpagnia, vedemu chì a sicurità in tutti i spazii è l'industrii capisce chì hè ora di catturà è spin cù u sviluppu in una rota - in . U paradigma DevSecOps si adatta perfettamente à a metodulugia di sviluppu agile, implementazione, supportu è participazione in ogni versione è iterazione.
Transizione à DevSecOps
A parolla più impurtante in u Ciclu di Vita di u Sviluppu di Sicurezza hè "prucessu". Avete bisognu di capiscenu questu prima di pensà à cumprà strumenti.
L'inclusione di strumenti in u prucessu DevOps ùn hè micca abbastanza - a cumunicazione è a cunniscenza trà i participanti di u prucessu hè impurtante.
A ghjente hè più impurtante chè l'arnesi
Spessu a pianificazione di un prucessu di sviluppu sicuru principia cù a scelta è l'acquistu di un strumentu, è finisce cù i tentativi di integrà l'uttellu in u prucessu attuale, chì fermanu tentativi. Questu porta à cunsiquenzi tristi, perchè tutti l'arnesi anu e so caratteristiche è limitazioni.
Un casu cumuni hè quandu u dipartimentu di sicurità hà sceltu un strumentu bonu è caru cù una larga gamma di funzioni è ghjunse à i sviluppatori per custruisce in u prucessu. Ma ùn funziona micca - u prucessu hè cuncepitu in tale manera chì e limitazioni di un strumentu digià acquistatu ùn si mette micca in u paradigma attuale.
Prima, descrivite u risultatu chì vulete è ciò chì u prucessu serà. Questu hà da aiutà à capisce i roli di l'uttellu è a sicurità in u prucessu.
Cumincià cù ciò chì hè digià in usu
Prima di cumprà arnesi caru, fighjate ciò chì avete digià. Ogni cumpagnia hà esigenze di sicurità chì si applicanu à u sviluppu, ci sò cuntrolli, pentests - perchè micca trasfurmà tuttu questu in una forma comprensibile è còmuda per tutti?
Di solitu i requisiti sò un Talmud di carta chì si trova nantu à un scaffale. Ci hè statu un casu quandu avemu ghjuntu à a cumpagnia per guardà i prucessi è dumandate à mustrà i requisiti di sicurezza per u software. U specialistu chì hà fattu questu cercava assai tempu:
- Avà, in qualchì locu in e note, ci era un percorsu induve si trova stu documentu.
In u risultatu, avemu ricevutu u documentu una settimana dopu.
Per esigenze, cuntrolli è più, crea una pagina, per esempiu à Confluenza - hè cunvene per tutti.
Hè più faciule per riformattà ciò chì ci hè digià è aduprà per inizià.
Utilizà i Campioni di Sicurezza
Di solitu, in una cumpagnia media per i sviluppatori 100-200, ci hè un ufficiale di sicurità chì eseguisce parechje funzioni è ùn hà micca fisicamente tempu per verificà tuttu. Ancu s'ellu prova u so megliu, ellu solu ùn verificarà micca tuttu u codice chì u sviluppu genera. Per tali casi, un cuncettu hè statu sviluppatu - .
Security Champions hè una persona in u squadra di sviluppu chì hè interessata in a sicurità di u vostru pruduttu.
U Campionu di Sicurezza hè un puntu d'entrata à a squadra di sviluppu è un evangelista di sicurezza tutti in una sola.
Di solitu, quandu un ufficiale di sicurità vene à a squadra di sviluppu è indica un errore in u codice, riceve una risposta sorpresa:
- È quale site ? Ti vecu per a prima volta. Tuttu hè bè cun mè - u mo amicu anzianu mette "applicà" nantu à a revisione di u codice, andemu avanti!
Questa hè una situazione tipica, perchè ci hè assai più fiducia in l'anziani o solu i cumpagni di squadra cù quale u sviluppatore interagisce constantemente à u travagliu è in a revisione di codice. Sì, invece di un guardianu di sicurità, u Campione di Sicurezza indica l'errore è e cunsequenze, allora a so parolla averà più pesu.
Inoltre, i sviluppatori cunnoscenu u so codice megliu cà qualsiasi tipu di sicurità. Per una persona chì hà almenu 5 prughjetti in un strumentu di analisi statica, hè di solitu difficiuli di ricurdà tutte e sfumature. I Campioni di Sicurezza cunnoscenu u so pruduttu: ciò chì interagisce cù ciò chì è ciò chì vede in u primu locu - sò più efficaci.
Allora cunsiderà implementà i Campioni di Sicurezza è espansione l'influenza di a squadra di sicurezza. Per u campionu stessu, questu hè ancu utile: sviluppu prufessiunale in un novu campu, espansione l'orizzonti tecnichi, pumping tecnichi, cumpetenze manageriali è dirigenti, aumentendu u valore di u mercatu. Questu hè qualchì elementu di l'ingenieria suciale, i vostri "ochji" in u squadra di sviluppu.
E tappe di prova
dice chì 20% di i sforzi dà 80% di i risultati. Questi 20% sò pratiche di analisi di l'applicazioni chì ponu è deve esse automatizati. Esempii di tali attività sò analisi statica - SAST, analisi dinamica - DAST и cuntrollu open source. Vi dicu più nantu à l'attività, è ancu nantu à l'arnesi, ciò chì e funzioni chì avemu in solitu scontru quandu sò intrudutti in u prucessu, è cumu per fà bè.
Prublemi principali di u strumentu
Puderaghju evidenza i prublemi chì sò pertinenti per tutti i strumenti chì necessitanu attenzione. Li analizzeraghju in più detail per ùn ripetiri più.
Longu tempu di analisi. S'ellu ci vole 30 minuti per tutte e teste è l'assemblea da l'impegnu à a liberazione per a produzzione, i cuntrolli di sicurezza di l'infurmazioni piglianu un ghjornu. Allora nimu hà da rallentà u prucessu. Cunsiderate sta funzione è piglià cunclusioni.
High False Negative o False Positive. Tutti i prudutti sò diffirenti, tutti utilizanu frameworks differenti è u so propiu stile di codificazione. Nantu à e diverse basi di codice è tecnulugii, l'arnesi ponu mostra diversi livelli di Falsi Negativi è Falsi Positivi. Allora vedi ciò chì ci hè di u vostru cumpagnie è per u vostru l'applicazioni mostraranu un risultatu bonu è affidabile.
Nisuna integrazione cù l'arnesi esistenti. Fighjate à l'arnesi in termini di integrazioni cù ciò chì avete digià utilizatu. Per esempiu, sè vo avete Jenkins o TeamCity, verificate l'integrazione di l'arnesi cù stu software, è micca cù GitLab CI, chì ùn avete micca utilizatu.
Mancanza o cumplessità eccessiva di persunalizazione. Se l'uttellu ùn hà micca una API, perchè hè necessariu? Tuttu ciò chì pò esse fattu in l'interfaccia deve esse dispunibule attraversu l'API. Ideale, l'uttellu deve avè a capacità di persunalizà cuntrolli.
Nisuna roadmap di sviluppu di produttu. U sviluppu ùn si ferma, avemu sempre aduprà novi frameworks è funzioni, riscrive u vechju codice in novi lingue. Vulemu assicurà chì l'uttellu chì compremu sustenerà novi frameworks è tecnulugia. Per quessa, hè impurtante sapè chì u pruduttu hà un veru è currettu sviluppu.
Process features
In più di e caratteristiche di l'arnesi, cunsiderà e caratteristiche di u prucessu di sviluppu. Per esempiu, interferiscenu cù u sviluppu hè un sbagliu tipicu. Videmu ciò chì altre caratteristiche deve esse cunsideratu è ciò chì a squadra di sicurezza deve esse attentu.
Per ùn disturbà u sviluppu è i termini di liberazione, crea regule diverse è differente mostra i tappi - criteri per fermà u prucessu di creazione in presenza di vulnerabili - per ambienti diversi. Per esempiu, avemu capitu chì u ramu attuale và à un stand di sviluppu o UAT, perchè ùn ci ferma micca è dicemu:
- Avete vulnerabili quì, ùn anderete più luntanu !
À questu puntu, hè impurtante di dì à i sviluppatori chì ci sò prublemi di sicurezza à circà.
A prisenza di vulnerabili ùn hè micca un ostaculu per più teste: manuale, integrazione o manuale. Per d 'altra banda, avemu bisognu à migliurà a sicurità di u pruduttu, è cusì chì i sviluppatori ùn anu micca puntuatu nantu à ciò chì a sicurità trova. Dunque, qualchì volta facemu questu: à u stand, quandu si stende à l'ambiente di sviluppu, simpricimenti avvisemu u sviluppu:
- Ragazzi, avete prublemi, fate attenzione à elli.
À a tappa UAT, avemu di novu mostra avvirtimenti nantu à e vulnerabilità, è in a tappa di uscita in u prom dicemu:
"Ragazzi, vi avemu avvistatu parechje volte, ùn avete micca fattu nunda - ùn vi lasciaremu micca fora cù questu.
Se parlemu di codice è dinamica, allora hè necessariu di vede è avvistà nantu à e vulnerabilità solu di quelli funziunalità è u codice chì era ghjustu scrittu in questa funzione. Se u sviluppatore hà spustatu u buttone da 3 pixels è li dicemu chì hà una iniezione SQL quì è per quessa deve esse riparatu urgente, questu hè sbagliatu. Fighjate solu à ciò chì hè scrittu avà, è à u cambiamentu chì vene à l'applicazione.
Dicemu chì avemu qualchì difettu funziunale - a manera chì l'applicazione ùn deve micca travaglià: i soldi ùn sò micca trasferiti, quandu cliccate nant'à u buttone, ùn ci hè micca transizione à a pagina dopu, o u pruduttu ùn carica micca. Difetti di sicurezza - Quessi sò i stessi difetti, ma micca in u cuntestu di l'applicazione, ma a sicurità.
Ùn sò micca tutti i prublemi di qualità di u software sò prublemi di sicurezza. Ma tutti i prublemi di sicurità sò ligati à a qualità di u software. Sherif Mansour, Expedia.
Siccomu tutte e vulnerabilità sò i stessi difetti, anu da esse situatu in u stessu locu cum'è tutti i difetti di sviluppu. Allora scurdate di rapporti è PDF spaventosi chì nimu leghje.
Quandu aghju travagliatu per una sucietà di sviluppu, aghju ricevutu un rapportu da strumenti di analisi statica. L'aghju apertu, mi sò spaventatu, aghju fattu u caffè, fogliu 350 pagine, chjusu è andò à travaglià. I grandi rapporti sò rapporti morti. Di solitu ùn vanu in ogni locu, e-mail sò sguassati, scurdati, persi, o l'affari dice chì piglia risichi.
Chì fà ? Simplicemu cunvertisce i difetti cunfirmati chì avemu trovu in una forma cunvene per u sviluppu, per esempiu, mette in u backlog in Jira. I difetti sò priurità è eliminati in ordine di priorità cù i difetti funziunali è i difetti di prova.
Analisi statica - SAST
Questu hè l'analisi di codice per i vulnerabili., ma ùn hè micca listessu chì SonarQube. Avemu verificatu micca solu per mudelli o stile. L'analisi usa una quantità di avvicinamenti: da l'arbre di vulnerabilità, da , analizendu i schedarii di cunfigurazione. Hè tuttu per u codice stessu.
Pros di l'approcciu: identificà e vulnerabilità in u codice in una prima fase di sviluppuquandu ùn ci hè micca stands è arnesi ready-made, è capacità di scansione incrementali: scansà una sezione di codice chì hà cambiatu, è solu a funzione chì facemu attualmente, chì riduce u tempu di scansione.
Минусы hè a mancanza di supportu per e lingue richieste.
integrazioni necessarie, chì deve esse in l'arnesi, in a mo opinione subjectiva:
- Strumenta di integrazione: Jenkins, TeamCity è Gitlab CI.
- Ambiente di sviluppu: Intellij IDEA, Visual Studio. Hè più còmuda per un sviluppatore per ùn cullà in una interfaccia incomprensibile chì deve esse ricurdata, ma per vede tutte l'integrazioni necessarie è e vulnerabilità chì hà trovu ghjustu à u locu di travagliu in u so propiu ambiente di sviluppu.
- Revisione di codice: SonarQube è rivista manuale.
- Trackers di difetti: Jira è Bugzilla.
A stampa mostra alcuni di i migliori rapprisentanti di l'analisi statica.
Ùn sò micca i strumenti chì importanu, ma u prucessu, cusì ci sò suluzioni Open Source chì sò ancu boni per eseguisce u prucessu.
SAST Open Source ùn truverete micca un gran numaru di vulnerabilità o DataFlow cumplessu, ma ponu è deve esse usatu quandu custruisce un prucessu. Aiutanu à capisce cumu u prucessu serà custruitu, quale risponde à i bug, quale hà da rapportu, quale hà da rapportu. Sè vo vulete purtà fora u stadiu iniziale di custruì a sicurità di u vostru codice, aduprà suluzioni Open Source.
Cumu pò esse integratu si site à u principiu di u viaghju, ùn avete nunda: nè CI, nè Jenkins, nè TeamCity? Cunsiderate l'integrazione di u prucessu.
Integrazione à u livellu CVS
Sè avete Bitbucket o GitLab, pudete fà integrazione à u livellu .
Per avvenimentu pull request, commit. Scansate u codice è mostra in u statutu di custruzzione chì u cuntrollu di sicurità hà passatu o fallutu.
Feedback. Di sicuru, u feedback hè sempre necessariu. Sì avete fattu solu in u latu di a sicurità, mette in una scatula è ùn hà micca dettu à nimu, è poi sguassate una mansa di bug à a fine di u mese, questu hè micca ghjustu è micca bè.
Integrazione cù u sistema di rivisione di codice
Una volta, avemu stabilitu l'utilizatore tecnicu AppSec cum'è u revisor predeterminatu in una quantità di prughjetti impurtanti. Sicondu s'ellu si trovanu errori in u novu codice o ùn ci sò micca errori, u rivisore mette u statutu nantu à a dumanda di pull per "accettà" o "bisognu di travagliu" - o tuttu hè OK, o avete bisognu di finalizà è ligami à ciò chì esattamente. per finalizà. Per integrazione cù a versione chì hè stata liberata, avemu disattivatu a fusione se a prova IS ùn hè micca passatu. Avemu inclusu questu in a rivista di codice manuale, è u restu di i participanti di u prucessu anu vistu i stati di sicurità per stu prucessu particulari.
Integrazione cù SonarQube
Parechji anu in termini di qualità di codice. Hè listessa quì - pudete fà e stesse porte solu per i strumenti SAST. Ci sarà a stessa interfaccia, a stessa porta di qualità, solu serà chjamatu porta di sicurità. È ancu, sè vo avete un prucessu stallatu cù SonarQube, pudete facilmente integrà tuttu quì.
Integrazione à u livellu CI
Quì, ancu, tuttu hè abbastanza sèmplice:
- À parità cù l'autotest, test di unità.
- Divisione per fasi di sviluppu: dev, test, prod. Differenti insemi di regule pò esse inclusu, o diverse cundizioni di fiaschi: avemu firmatu l'assemblea, ùn ci ferma micca l'assemblea.
- Partenza sincrona / asincrona. Aspittemu a fine di e teste di sicurezza o ùn aspettemu micca. Vale à dì, avemu appena lanciatu è andemu avanti, è dopu avemu un statutu chì tuttu hè bonu o cattivu.
Hè tuttu in un mondu rosa perfettu. In a vita reale, questu ùn hè micca u casu, ma strivemu. U risultatu di eseguisce cuntrolli di sicurezza deve esse simili à i risultati di e teste di unità.
Per esempiu, avemu pigliatu un grande prughjettu è decisu chì avà l'avemu scansatu cù SAST - OK. Avemu spintu stu prughjettu in SAST, ci hà datu 20 vulnerabilità, è avemu fattu una decisione forte chì tuttu hè bè. 000 20 vulnerabilità hè u nostru debitu tecnicu. Puderemu u debitu in una scatula, l'arracheremu lentamente è cuminciamu bug in trackers di difetti. Ingaghjate una cumpagnia, fate tuttu per noi stessi, o avete i Campioni di Sicurezza chì ci aiutanu, è u debitu tecnicu diminuirà.
È tutte e vulnerabilità di novu apparsu in u novu codice deve esse eliminati in u listessu modu cum'è l'errori in una unità o in autotests. Relativamente parlante, l'assemblea hà cuminciatu, s'hè alluntanatu, duie teste è duie teste di sicurezza sò cascate. OK - andemu, fighjemu ciò chì hè accadutu, currettu unu, currettu u sicondu, guidò a prossima volta - tuttu hè bè, nisuna vulnerabilità nova hè apparsa, i testi ùn anu micca fallutu. Se sta attività hè più profonda è avete bisognu di capiscenu bè, o a correzione di vulnerabilità affetta grandi strati di ciò chì si trova sottu u cappucciu: un bug hè purtatu in u tracker di difetti, hè priurità è riparatu. Sfurtunatamente, u mondu ùn hè micca perfettu è e teste volte fallenu.
Un esempiu di una porta di sicurità hè un analogu di una porta di qualità, in quantu à a presenza è u numeru di vulnerabili in u codice.
Integremu cù SonarQube - u plugin hè stallatu, tuttu hè assai còmode è cool.
Integrazione di l'ambiente di sviluppu
Opzioni di integrazione:
- Cumincià una scansione da l'ambiente di sviluppu ancu prima di l'impegnu.
- Vede i risultati.
- Analisi di i risultati.
- Sincronizazione cù u servitore.
Questu hè cumu ottene risultati da u servitore.
In u nostru ambiente di sviluppu Apparisce solu un articulu supplementu chì dice chì tali vulnerabilità sò state truvate durante a scansione. Pudete immediatamente edità u codice, vede i cunsiglii è . Tuttu chistu si trova in u locu di travagliu di u sviluppatore, chì hè assai còmuda - ùn avete micca bisognu di seguità u restu di i ligami è fighjate qualcosa extra.
Open Source
Questu hè u mo tema preferitu. Tutti usanu biblioteche Open Source - perchè scrive una mansa di crutches è biciclette quandu pudete piglià una biblioteca pronta in quale tuttu hè digià implementatu?
Di sicuru, questu hè veru, ma e biblioteche sò ancu scritte da e persone, includenu ancu certi risichi, è ci sò ancu vulnerabili chì sò periodicamente, o constantemente, rappurtati. Dunque, ci hè un passu prossimu in a Sicurezza di l'Applicazione - questu hè l'analisi di cumpunenti Open Source.
Analisi Open Source - OSA
U strumentu include trè passi maiò.
Truvà vulnerabilità in biblioteche. Per esempiu, l'uttellu sapi chì avemu aduprà qualchì tipu di biblioteca, è chì in o in i bug trackers ci sò qualchi vulnerabilità chì riguardanu sta versione di a biblioteca. Se pruvate d'utilizà, l'uttellu vi avvisarà chì a biblioteca hè vulnerabile, è vi cunsigliu per aduprà una altra versione induve ùn ci hè micca vulnerabilità.
Analisi di a purità di licenza. Questu ùn hè micca assai populari cun noi ancu, ma se travagliate cù un paese straneru, allora pudete ottene un attaccu periodicamente per utilizà un cumpunente open source chì ùn pò micca esse usatu o mudificatu. Sicondu a pulitica di a biblioteca licenziata, ùn pudemu micca fà questu. O, se l'avemu mudificatu è l'utilizate, avemu da postà u nostru codice. Di sicuru, nimu ùn vole pubblicà u codice di i so prudutti, ma pudete ancu prutezzione di questu.
Analisi di cumpunenti chì sò usati in un ambiente industriale. Imagine una situazione ipotetica chì avemu finitu u sviluppu è liberatu l'ultima versione di u nostru microserviziu à l'industria. Vive quì maravigliosamente - una settimana, un mese, un annu. Ùn a cullemu micca, ùn facemu micca cuntrolli di sicurezza, tuttu pare esse bè. Ma di colpu, duie settimane dopu à a liberazione, esce una vulnerabilità critica in u cumpunente Open Source, chì avemu usatu in questu assemblea particulari, in l'ambiente industriale. Se ùn avemu micca registratu ciò chì è induve usemu, allora sta vulnerabilità ùn serà micca vista. Certi arnesi anu a capacità di monitorà e vulnerabilità in biblioteche chì sò attualmente aduprate in prom. Hè assai utile.
Funzioni:
- Diverse pulitiche per diverse tappe di sviluppu.
- Monitorà i cumpunenti in un ambiente industriale.
- Cuntrolla di biblioteche in u contornu di l'urganizazione.
- Supportu per vari sistemi di custruzzione è lingue.
- Analisi di l'imaghjini Docker.
Uni pochi esempi di capi in u campu chì sò impegnati in l'analisi di Open Source.
L'unicu liberu hè da OWASP. Pudete accende in i primi fasi, vede cumu funziona è ciò chì sustene. Fondamentalmente, questi sò tutti i prudutti di nuvola, o in premisa, ma daretu à a so basa anu sempre andà in Internet. Ùn mandanu micca e vostre biblioteche, ma hashes o i so valori chì calculanu, è impronte digitali à u so servitore per riceve nutizie di a presenza di vulnerabili.
Integrazione di prucessu
Cuntrolla di biblioteca perimetruchì sò scaricati da fonti esterni. Avemu repositori esterni è interni. Per esempiu, avemu Nexus in Event Central, è vulemu assicurà chì ùn ci hè micca vulnerabilità cù un statu "criticu" o "altu" in u nostru repository. Pudete cunfigurà u proxy utilizendu l'utillita Nexus Firewall Lifecycle per chì tali vulnerabilità sò tagliate è micca incluse in u repository internu.
Integrazione di CI. À u listessu livellu cù autotests, test unità è divisioni in tappe di sviluppu: dev, test, prod. In ogni tappa, pudete scaricà qualsiasi biblioteche, aduprate qualcosa, ma s'ellu ci hè qualcosa di duru cù u statu "criticu", avete da esse prubabilmente attirà l'attenzione di i sviluppatori à questu in u stadiu di l'ingressu à u prom.
Integrazione di l'artefatti: Nexus è JFrog.
Integrazione in l'ambiente di sviluppu. L'arnesi chì sceglite deve avè integrazione cù l'ambienti di sviluppu. U sviluppatore deve avè accessu à i risultati di scansione da u so postu di travagliu, o l'abilità di scansà è verificate u codice per vulnerabilità prima di cummette in CVS.
Integrazione di CD. Questa hè una funzione fresca chì mi piace assai è di quale aghju digià parlatu - monitorizà l'emergenza di novi vulnerabili in un ambiente industriale. Funziona cusì.
Avemu Repositori di cumpunenti publichi - certi arnesi fora, è u nostru repository internu. Vulemu solu cumpunenti di fiducia per esse in questu. Quandu proxy una dumanda, verificamu chì a biblioteca scaricata ùn hà micca vulnerabilità. S'ellu cade in certi pulitiche chì avemu stabilitu è necessariamente coordinate cù u sviluppu, allora ùn l'avemu micca caricatu è avemu un refuff per aduprà una versione diversa. Dunque, s'ellu ci hè qualcosa veramente criticu è cattivu in a biblioteca, allora u sviluppatore ùn riceve micca a biblioteca ancu in a fase di stallazione - lasciate aduprà una versione più alta o più bassa.
- Quandu custruite, verificamu chì nimu hà sbulicatu qualcosa di male, chì tutti i cumpunenti sò sicuri è nimu hà purtatu qualcosa di periculosu in u flash drive.
- Avemu solu cumpunenti di fiducia in u repository.
- Quandu u dispiegamentu, una volta cuntrollemu u pacchettu stessu: guerra, jar, DL o Docker image per u fattu chì hè cumpletu cù a pulitica.
- Quandu entra in l'ambiente industriale, monitoremu ciò chì succede in l'ambiente industriale: vulnerabilità critiche appariscenu o ùn si prisentanu micca.
Analisi Dinamica - DAST
Strumenti di analisi dinamica sò fundamentalmente sfarente di tuttu ciò chì hè statu dettu prima. Questu hè un tipu d'imitazione di u travagliu di l'utilizatori cù l'applicazione. S'ellu hè una applicazione web, mandemu dumande imitandu u travagliu di u cliente, cliccate nantu à i buttoni in fronte, mandate dati artificiali da a forma: quotes, parentesi, caratteri in diverse codificazioni per vede cumu l'applicazione funziona è processa esterni. dati.
U stessu sistema permette di verificà e vulnerabilità di mudelli in Open Source. Siccomu DAST ùn cunnosci micca quale Open Source usemu, simpricimenti tira mudelli "maliziusi" è analizà e risposte di u servitore:
- Iè, ci hè un prublema di deserializazione quì, ma micca quì.
Ci sò grandi risichi in questu, perchè se fate sta prova di sicurezza nantu à u listessu stand cù i teste chì travaglianu, ponu accade cose sgradevoli.
- Carica alta nantu à a reta di u servitore di l'applicazioni.
- Nisuna integrazioni.
- A capacità di cambià i paràmetri di l'applicazione analizata.
- Ùn ci hè micca supportu per e tecnulugia necessarie.
- Difficultà di mette.
Avemu avutu una situazione quandu avemu finalmente lanciatu AppScan: avemu sguassatu l'accessu à l'applicazione per un bellu pezzu, avemu ricevutu 3 cunti è eramu felici - infine, verificaremu tuttu! Avemu lanciatu una scansione, è a prima cosa chì AppScan hà fattu era entre in u pannellu di amministrazione, pierce tutti i buttoni, cambia a mità di e dati, è poi tumbà u servitore in tuttu cù u so propiu. - dumande. Sviluppu cù Testing hà dettu:
"Ragazzi, mi scherzi ?! Avemu datu i cunti, è avete messu u stand !
Cunsiderate i risichi pussibuli. Ideale, preparanu un stand separatu per a prova di a sicurità di l'infurmazioni, chì serà isolatu da u restu di l'ambiente, almenu in qualchì manera, è cuntrolla in cundizzioni u pannellu admin, preferibile in modu manuale. Questu hè un pentest - quelli percentuali rimanenti di sforzi chì ùn avemu micca cunsideratu avà.
Hè vale a pena cunsiderà chì pudete aduprà questu cum'è un analogu di teste di carica. À u primu stadiu, pudete accende u scanner dinamicu in 10-15 fili è vede ciò chì succede, ma di solitu, cum'è a pratica mostra, nunda di bonu.
Uni pochi di risorse chì usualmente usemu.
Vale a pena mette in risaltu hè u "cutellu svizzero" per ogni prufessiunali di sicurità. Tutti l'utilizanu è hè assai còmuda. Una nova versione demo di l'edizione di l'impresa hè stata liberata. Se prima era solu una utilità autonoma cù plugins, avà i sviluppatori facenu infine un grande servitore da quale serà pussibule di gestisce parechji agenti. Hè bellu, vi cunsigliu di pruvà.
Integrazione di prucessu
L'integrazione hè abbastanza bona è simplice: principià a scansione dopu a stallazione successu applicazioni nantu à u stand è scanning dopu a prova di integrazione successu.
Se l'integrazioni ùn viaghjanu micca o ci sò stubs è funziunamentu di funziunamentu, hè senza significatu è inutile - ùn importa micca u mudellu chì mandemu, u servitore risponderà sempre u listessu modu.
- Ideale, un bancu di prova separatu.
- Prima di pruvà, scrive a sequenza di login.
- A prova di u sistema di amministrazione hè solu manuale.
prucessu
Un pocu generalizatu nantu à u prucessu in generale è nantu à u travagliu di ogni strumentu, in particulare. Tutte l'applicazioni sò diverse - una travaglia megliu cù l'analisi dinamica, l'altra cù l'analisi statica, u terzu cù l'analisi OpenSource, pentests, o qualcosa d'altru in generale, per esempiu, avvenimenti cù .
Ogni prucessu deve esse cuntrullatu.
Per capiscenu cumu funziona u prucessu è induve pò esse migliuratu, avete bisognu di cullà metriche da tuttu ciò chì pudete mette in manu, cumprese metriche di produzzione, metriche di arnesi è trackers di difetti.
Ogni infurmazione hè utile. Hè necessariu di guardà in diverse rùbbriche induve questu o quellu strumentu hè megliu utilizatu, induve u prucessu specificamente sags. Puderia vale a pena guardà u tempu di risposta di sviluppu per vede induve migliurà u prucessu basatu annantu à u tempu. A più dati, i più taglii ponu esse custruitu da u livellu superiore à i dettagli di ogni prucessu.
Siccomu tutti l'analizzatori statichi è dinamichi anu u so propiu API, i so propri metudi di lanciamentu, principii, alcuni anu pianificatori, altri ùn anu micca - scrivemu un strumentu AppSec Orchestrator, chì permette di fà un unicu puntu di ingressu à u prucessu tutale da u pruduttu è gestisce da un puntu.
I gestori, i sviluppatori è l'ingegneri di sicurezza anu un puntu d'entrata da quale ponu vede ciò chì hè in esecuzione, cunfigurà è eseguite scans, uttene risultati di scansione è sottumette esigenze. Pruvemu di alluntanassi da pezzi di carta, traduce tuttu in un umanu chì u sviluppu usa - pagine nantu à Confluence cù statutu è metrica, difetti in Jira o in diversi trackers di difetti, o incrustendu in un prucessu sincronu / asincronu in CI / CD.
Chiave Takeaways
L'arnesi ùn importa micca. Pensate à u prucessu prima, dopu implementà l'arnesi. L'arnesi sò boni, ma caru, cusì pudete principià cù u prucessu è fine-tune l'interazzione è a cunniscenza trà u sviluppu è a sicurità. Da u puntu di vista di a sicurità, ùn ci hè bisognu di "piantà" tuttu in una fila. Da u puntu di vista di u sviluppu, s'ellu ci hè qualcosa d'altu mega super criticu, allora questu deve esse eliminatu, è micca chjusu à u prublema. .
Qualità di u produttu - scopu cumuni sia sicurezza è sviluppu. Facemu una cosa, pruvemu di assicurà chì tuttu funziona bè è ùn ci hè micca risichi di reputazione è perdite finanziarie. Hè per quessa chì prumove l'approcciu di DevSecOps, SecDevOps per stabilisce a cumunicazione è fà u pruduttu megliu.
Cumincià cù ciò chì ci hè digià: esigenze, architettura, cuntrolli parziali, furmazione, linee guida. Ùn hè micca necessariu applicà immediatamente tutte e pratiche à tutti i prughjetti - move in modu iterativu. Ùn ci hè micca un standard unicu esperimentu è pruvà diverse approcci è suluzioni.
Segnu uguale trà difetti IS è difetti funziunali.
Automatizà tuttuchì si move. Tuttu ciò chì ùn si move, si move è automatizà. Se qualcosa hè fattu da a manu, questu ùn hè micca una bona parte di u prucessu. Forse vale a pena ricunsiderà è automatizà ancu.
Se a dimensione di a squadra IB hè chjuca - aduprà Campioni di Sicurezza.
Forsi ciò chì aghju parlatu ùn vi cunvene micca è vi venerà cù qualcosa di u vostru propiu - è hè bonu. Ma sceglie arnesi basatu nantu à i bisogni di u vostru prucessu. Ùn fighjate micca ciò chì a cumunità dice chì questu strumentu hè male è questu hè bonu. Forsi serà l'altru in u vostru pruduttu.
Esigenze di u strumentu.
- Low False Positive.
- Tempu di analisi adattatu.
- Facilità d'usu.
- Disponibilità di integrazioni.
- Capisce a strada di sviluppu di u produttu.
- Capacità di persunalizà l'arnesi.
U rapportu di Yuriy hè statu sceltu cum'è unu di i migliori in DevOpsConf 2018. Per fà cunnosce ancu idee più interessanti è casi pratichi, vene à Skolkovo u 27 è 28 di maghju. dentro . Ancu megliu, sè vo site dispostu à sparte a vostra sperienza, allora Mandate u vostru rapportu da u 21 d'aprile.
Source: www.habr.com
