Ni havis 2 kodanalizilojn, 4 dinamikajn testajn ilojn, niajn proprajn metiojn kaj 250 skriptojn. Ne ke ĉio ĉi estis necesa en la nuna procezo, sed post kiam vi komencis efektivigi DevSecOps, vi devas iri ĝis la fino.
. Karakteroj kreitaj fare de Justin Roiland kaj Dan Harmon.
Kio estas SecDevOps? Kio pri DevSecOps? Kio estas la diferencoj? Aplika Sekureco - pri kio temas? Kial la klasika aliro ne plu funkcias? Ĉiuj ĉi tiuj demandoj scias la respondon Jurij Ŝabalin el Sekureco de Spadfiŝo. Yuriy respondos ĉion detale kaj analizos la problemojn de transiro de la klasika Aplika Sekureco-modelo al la procezo DevSecOps: kiel ĝuste alproksimiĝi al la integriĝo de la sekura disvolva procezo en la procezon DevOps kaj ne rompi ion ajn, kiel trairi la ĉefajn stadiojn. de sekureca testado, kiaj iloj povas esti uzataj, kiel ili diferencas kaj kiel ĝuste agordi ilin por eviti malfacilaĵojn.
Pri parolanto: Jurij Ŝabalin - Ĉefa Sekureca Arkitekto en la firmao Sekureco de Spadfiŝo. Respondeca por la efektivigo de SSDL, por la totala integriĝo de aplikaj analiziloj en ununura evoluiga kaj testa ekosistemo. 7 jaroj da sperto en informa sekureco. Laboris ĉe Alfa-Banko, Sberbank kaj Positive Technologies, kiu disvolvas programaron kaj provizas servojn. Parolanto de internaciaj konferencoj ZerONights, PHDays, RISSPA, OWASP.
Aplika Sekureco: pri kio temas?
Aplika Sekureco estas la sekureca sekcio, kiu respondecas pri aplika sekureco. Ĉi tio ne temas pri infrastrukturo aŭ retsekureco, sed pri tio, kion ni skribas kaj pri kio programistoj laboras - ĉi tiuj estas la difektoj kaj vundeblecoj de la aplikaĵo mem.
Destino - Sekureca evolua vivociklo - Disvolvita de Microsoft. La diagramo montras la kanonan SDLC-modelon, kies ĉefa tasko estas la partopreno de sekureco en ĉiu etapo de evoluo, de postuloj, ĝis liberigo kaj liberigo ĝis produktado. Mikrosofto rimarkis, ke estas tro da cimoj en la prom, estas pli da ili kaj io devas esti farita pri ĝi, kaj ili proponis ĉi tiun aliron, kiu iĝis kanona.
Aplika Sekureco kaj SSDL ne celas detekti vundeblecojn, kiel oni kutime kredas, sed malhelpi ilian okazon. Kun la tempo, la kanona aliro de Microsoft estis plibonigita, disvolvita, ĝi havas pli profundan detalan mergon.
La kanona SDLC estas tre detala en diversaj metodaroj - OpenSAMM, BSIMM, OWASP. La metodaroj malsamas, sed ĝenerale similas.
Konstruanta Sekureco En Matureca Modelo
Mi plej ŝatas ĝin BSIMM - . La bazo de la metodaro estas la dividado de la Aplika Sekurecprocezo en 4 domajnojn: Administrado, Inteligenteco, SSDL-Tuŝopunktoj kaj Deplojo. Ĉiu domajno havas 12 praktikojn, kiuj estas reprezentitaj kiel 112 agadoj.
Ĉiu el la 112 agadoj havas 3 maturecniveloj: komencanto, meza kaj progresinta. Vi povas studi ĉiujn 12 praktikojn en sekcioj, elekti aferojn, kiuj estas gravaj por vi, eltrovi kiel efektivigi ilin kaj iom post iom aldoni elementojn, ekzemple, statikan kaj dinamikan kodan analizon aŭ kodan revizion. Vi ellaboras planon kaj laboras laŭ ĝi trankvile kiel parto de la efektivigo de la elektitaj agadoj.
Kial DevSecOps
DevOps estas ĝenerala granda procezo en kiu sekureco devas esti prizorgita.
Komence implikis sekurecajn kontrolojn. Praktike, la nombro da sekurecaj teamoj estis multe pli malgranda ol nun, kaj ili agis ne kiel partoprenantoj en la procezo, sed kiel kontrolo kaj kontrola korpo kiu faras postulojn pri ĝi kaj kontrolas la kvaliton de la produkto ĉe la fino de la eldono. Ĉi tio estas klasika aliro, en kiu sekurecaj teamoj estis malantaŭ muro de evoluo kaj ne partoprenis en la procezo.
La ĉefa problemo estas, ke informa sekureco estas aparta de evoluo. Kutime ĉi tio estas ia IB-cirkvito kaj ĝi enhavas 2-3 grandajn kaj multekostajn ilojn. Unufoje ĉiun ses monatojn, la fontkodo aŭ aplikaĵo alvenas por esti provita, kaj unufoje jare . Ĉio ĉi kondukas al la fakto, ke la eldondatoj por la industrio estas prokrastitaj, kaj grandega nombro da vundeblecoj de aŭtomataj iloj falas sur la programisto. Estas neeble malmunti kaj ripari ĉion ĉi, ĉar eĉ en la antaŭaj ses monatoj la rezultoj ne estis malmuntitaj, kaj jen nova aro.
En la kurso de la laboro de nia kompanio, ni vidas, ke sekureco en ĉiuj areoj kaj industrioj komprenas, ke estas tempo por atingi kaj turniĝi kun la evoluo en unu rado - en . La paradigmo DevSecOps persvadas perfekte en lerta evolumetodaro, efektivigo, subteno kaj partopreno en ĉiu eldono kaj ripeto.
Transiro al DevSecOps
La plej grava vorto en la Sekureca Disvolva Vivciklo estas "procezo". Vi devas kompreni ĉi tion antaŭ ol pensi pri aĉeti ilojn.
Nur inkluzivi ilojn en la procezo DevOps ne sufiĉas - komunikado kaj kompreno inter procezpartoprenantoj gravas.
Homoj estas pli gravaj ol iloj
Ofte planado de sekura evoluprocezo komenciĝas per elekto kaj aĉeto de ilo, kaj finiĝas per provoj integri la ilon en la nunan procezon, kiuj restas provoj. Ĉi tio kondukas al malĝojaj konsekvencoj, ĉar ĉiuj iloj havas siajn proprajn trajtojn kaj limojn.
Ofta kazo estas kiam la sekureca fako elektis bonan, multekostan ilon kun ampleksa gamo de funkcioj kaj venis al la programistoj por konstrui ĝin en la procezon. Sed ĝi ne funkcias - la procezo estas desegnita tiel, ke la limigoj de jam aĉetita instrumento ne konvenas al la nuna paradigmo.
Unue, priskribu kian rezulton vi volas kaj kia aspektos la procezo. Ĉi tio helpos kompreni la rolojn de la ilo kaj sekureco en la procezo.
Komencu per kio jam estas uzata
Antaŭ ol aĉeti multekostajn ilojn, rigardu tion, kion vi jam havas. Ĉiu kompanio havas sekurecajn postulojn, kiuj validas por disvolviĝo, estas kontroloj, enpenetraj testoj - kial ne transformi ĉion ĉi en kompreneblan kaj oportunan formon por ĉiuj?
Kutime la postuloj estas papera Talmudo, kiu kuŝas sur breto. Estis kazo, kiam ni venas al la kompanio por rigardi la procezojn kaj peti ilin montri la sekurecajn postulojn por la programaro. La specialisto, kiu faris tion, serĉis dum longa tempo:
- Nun, ie en la notoj estis vojo, kie kuŝas ĉi tiu dokumento.
Kiel rezulto, ni ricevis la dokumenton semajnon poste.
Por postuloj, ĉekoj kaj pli, kreu paĝon, ekzemple ĉe Kunfluejo - ĝi estas oportuna por ĉiuj.
Estas pli facile reformati kio jam estas tie kaj uzi ĝin por komenci.
Uzu Sekurecajn Ĉampionojn
Kutime, en averaĝa kompanio por 100-200 programistoj, estas unu sekureca oficisto, kiu plenumas plurajn funkciojn kaj fizike ne havas tempon por kontroli ĉion. Eĉ se li provos sian eblon, li sola ne kontrolos la tutan kodon, kiun la evoluo generas. Por tiaj kazoj, koncepto estis evoluigita - .
Sekurecaj Ĉampionoj estas persono en la evolua teamo, kiu interesiĝas pri la sekureco de via produkto.
Sekureca Ĉampiono estas enirejpunkto al la evolua teamo kaj sekureca evangeliisto ĉio envolvita en unu.
Kutime, kiam sekureca oficisto venas al la evolua teamo kaj montras eraron en la kodo, li ricevas surprizitan respondon:
- Kaj kiu vi estas? Mi vidas vin la unuan fojon. Ĉio estas en ordo ĉe mi - mia altranga amiko metis "apliki" sur la koda revizio, ni antaŭeniras!
Ĉi tio estas tipa situacio, ĉar estas multe pli da fido al maljunuloj aŭ nur samteamanoj, kun kiuj la programisto konstante interagas ĉe la laboro kaj en la koda revizio. Se, anstataŭ sekureca gardisto, la Sekureca Ĉampiono montras la eraron kaj la sekvojn, tiam lia vorto havos pli da pezo.
Ankaŭ, programistoj konas sian kodon pli bone ol iu ajn sekureca ulo. Por homo, kiu havas almenaŭ 5-projektojn en statika analiza ilo, kutime estas malfacile memori ĉiujn nuancojn. Sekurecaj Ĉampionoj scias sian produkton: kio interagas kun kio kaj kion rigardi unue - ili estas pli efikaj.
Do konsideru efektivigi Sekurecajn Ĉampionojn kaj vastigi la influon de la sekureca teamo. Por la ĉampiono mem, tio ankaŭ estas utila: profesia evoluo en nova kampo, vastigi la teknikajn horizontojn, pumpi teknikajn, administrajn kaj gvidajn kapablojn, pliigi merkatan valoron. Ĉi tio estas iu elemento de socia inĝenierado, viaj "okuloj" en la evolua teamo.
Testaj etapoj
diras, ke 20% de la klopodoj donas 80% de la rezultoj. Ĉi tiuj 20% estas aplikaj analizaj praktikoj, kiuj povas kaj devas esti aŭtomatigitaj. Ekzemploj de tiaj agadoj estas senmova analizo − SAST, dinamika analizo - DAST и malfermkoda kontrolo. Mi rakontos al vi pli pri agadoj, same kiel pri iloj, kiajn funkciojn ni kutime renkontas kiam ili estas enkondukitaj en la procezon, kaj kiel fari ĝin ĝuste.
Ĉefaj ilaj problemoj
Mi reliefigos la problemojn, kiuj rilatas por ĉiuj instrumentoj, kiuj postulas atenton. Mi analizos ilin pli detale por ne plu ripeti.
Longa analiza tempo. Se necesas 30 minutoj por ĉiuj provoj kaj asembleo de kompromiso ĝis liberigo por produktado, tiam informsekurecaj kontroloj daŭros tagon. Do neniu malrapidigos la procezon. Konsideru ĉi tiun funkcion kaj faru konkludojn.
Alta Falsa Negativo aŭ Falsa Pozitiva. Ĉiuj produktoj estas malsamaj, ĉiuj uzas malsamajn kadrojn kaj sian propran kodigan stilon. Sur malsamaj kodaj bazoj kaj teknologioj, iloj povas montri malsamajn nivelojn de Falsa Negativo kaj Falsa Pozitivo. Do vidu kio estas enen via kompanioj kaj por viaj aplikoj montros bonan kaj fidindan rezulton.
Neniuj integriĝoj kun ekzistantaj iloj. Rigardu la ilojn laŭ integriĝoj kun tio, kion vi jam uzas. Ekzemple, se vi havas Jenkins aŭ TeamCity, kontrolu la integriĝon de iloj kun ĉi tiu programaro, kaj ne kun GitLab CI, kiun vi ne uzas.
Manko aŭ troa komplekseco de personigo. Se la ilo ne havas API, kial ĝi bezonas? Ĉio, kio povas esti farita en la interfaco, estu disponebla per la API. Ideale, la ilo havu la kapablon personecigi ĉekojn.
Neniu produkta disvolva vojmapo. Evoluo ne haltas, ni ĉiam uzas novajn kadrojn kaj funkciojn, reverkas malnovan kodon en novajn lingvojn. Ni volas certigi, ke la ilo, kiun ni aĉetas, subtenos novajn kadrojn kaj teknologiojn. Sekve, estas grave scii, ke la produkto havas realan kaj ĝustan evoluo.
Procesaj ecoj
Krom la trajtoj de la iloj, konsideru la trajtojn de la evoluprocezo. Ekzemple, malhelpi evoluon estas tipa eraro. Ni vidu, kiajn aliajn funkciojn oni devas konsideri kaj kion la sekureca teamo devas atenti.
Por ne interrompi la disvolviĝon kaj liberigi limdatojn, kreu malsamaj reguloj kaj malsamaj montri ŝtopiloj - kriterioj por ĉesigi la konstruprocezon en ĉeesto de vundeblecoj - por malsamaj medioj. Ekzemple, ni komprenas, ke la nuna branĉo iras al evoluiga stando aŭ UAT, do ni ne ĉesas kaj diras:
- Vi havas vundeblecojn ĉi tie, vi ne iros pluen!
Je ĉi tiu punkto, gravas diri al programistoj, ke estas sekurecaj problemoj por atenti.
La ĉeesto de vundeblecoj ne estas baro al plua testado: manlibro, integriĝo aŭ manlibro. Aliflanke, ni devas iel plibonigi la sekurecon de la produkto, kaj por ke la programistoj ne poentu pri tio, kion la sekureco trovas. Tial, foje ni faras ĉi tion: ĉe la stando, kiam ĝi ruliĝas al la evolumedio, ni simple sciigas la evoluon:
- Knaboj, vi havas problemojn, bonvolu atenti ilin.
En la UAT-stadio, ni denove montras avertojn pri vundeblecoj, kaj ĉe la elira etapo en la finbalo ni diras:
“Knaboj, ni avertis vin plurfoje, vi faris nenion – ni ne ellasos vin kun ĉi tio.
Se ni parolas pri kodo kaj dinamiko, tiam necesas montri kaj averti pri vundeblecoj nur de tiuj funkcioj kaj kodo, kiuj ĵus estis skribitaj en ĉi tiu funkcio. Se la programisto movis la butonon je 3 pikseloj kaj ni diras al li, ke li havas SQL-injekton tie kaj tial necesas urĝe ripari, tio estas malĝusta. Rigardu nur tion, kio estas skribita nun, kaj la ŝanĝon, kiu venas al la aplikaĵo.
Ni diru, ke ni havas iun funkcian difekton - kiel la aplikaĵo ne devus funkcii: mono ne estas translokigita, kiam vi alklakas la butonon, ne estas transiro al la sekva paĝo, aŭ la produkto ne ŝarĝas. Sekurecaj Difektoj - ĉi tiuj estas la samaj difektoj, sed ne en la kunteksto de la aplikaĵo, sed sekureco.
Ne ĉiuj problemoj pri kvalito de programaro estas problemoj pri sekureco. Sed ĉiuj sekurecaj problemoj rilatas al la kvalito de la programaro. Ŝerifo Mansour, Expedia.
Ĉar ĉiuj vundeblecoj estas la samaj difektoj, ili devus situi en la sama loko kiel ĉiuj disvolvaj difektoj. Do forgesu pri raportoj kaj timigaj PDF-oj, kiujn neniu legas.
Kiam mi laboris por evoluiga kompanio, mi ricevis raporton de statikaj analiziloj. Mi malfermis ĝin, teruriĝis, faris kafon, foliumis 350 paĝojn, fermis ĝin kaj eklaboris. Grandaj raportoj estas mortintaj raportoj. Kutime ili ne iras ien, retpoŝtoj estas forigitaj, forgesitaj, perditaj, aŭ la komerco diras, ke ĝi riskas.
Kion fari? Ni simple konvertas la konfirmitajn difektojn, kiujn ni trovis, al formo oportuna por disvolviĝo, ekzemple, aldonu ĝin al la restaro en Jira. Difektoj estas prioritatitaj kaj eliminitaj en ordo de prioritato kune kun funkciaj difektoj kaj testdifektoj.
Statika Analizo - SAST
Ĉi tio estas kodanalizo por vundeblecoj., sed ĝi ne estas la sama kiel SonarQube. Ni kontrolas ne nur por ŝablonoj aŭ stilo. La analizo uzas kelkajn alirojn: per vundebla arbo, per , per analizo de agordaj dosieroj. Tio estas ĉio por la kodo mem.
Avantaĝoj de la aliro: identigante vundeblecojn en kodo en frua stadio de evoluokiam mankas standoj kaj pretaj iloj, kaj pliiga skana kapablo: skanas sekcion de kodo kiu ŝanĝiĝis, kaj nur la funkcion kiun ni nuntempe faras, kiu reduktas la skantempon.
Miksoj estas la manko de subteno por la bezonataj lingvoj.
Bezonataj integriĝoj, kiu devus esti en la iloj, laŭ mia subjektiva opinio:
- Integriĝa ilo: Jenkins, TeamCity kaj Gitlab CI.
- Evolumedio: Intellij IDEA, Visual Studio. Estas pli oportune por programisto ne grimpi en nekompreneblan interfacon, kiu ankoraŭ devas esti memorita, sed vidi ĉiujn necesajn integriĝojn kaj vundeblecojn, kiujn li trovis ĝuste ĉe la laborejo en sia propra evolumedio.
- Koda revizio: SonarQube kaj mana revizio.
- Difektspuristoj: Jira kaj Bugzilla.
La bildo montras kelkajn el la plej bonaj reprezentantoj de statika analizo.
Ne la iloj gravas, sed la procezo, do ekzistas Malfermfontaj solvoj, kiuj ankaŭ estas bonaj por funkcii la procezon.
SAST Open Source ne trovos grandegan nombron da vundeblecoj aŭ kompleksa DataFlow, sed ili povas kaj devas esti uzataj dum konstruado de procezo. Ili helpas kompreni kiel la procezo estos konstruita, kiu respondos al cimoj, kiu raportos, kiu raportos. Se vi volas realigi la komencan etapon konstrui la sekurecon de via kodo, uzu Malfermfontajn solvojn.
Kiel ĉi tio povas esti integrita se vi estas ĉe la komenco de la vojaĝo, vi havas nenion: nek CI, nek Jenkins, nek TeamCity? Konsideru procezan integriĝon.
Integriĝo ĉe la CVS-nivelo
Se vi havas Bitbucket aŭ GitLab, vi povas fari integriĝon je la nivelo .
Laŭ evento pull request, kompromiti. Vi skanas la kodon kaj montras en la konstrua stato, ke la sekureca kontrolo pasis aŭ malsukcesis.
Reago. Kompreneble, reagoj ĉiam necesas. Se vi ĵus faris ĝin sur la sekureca flanko, metis ĝin en skatolon kaj nenion diris al iu pri ĝi, kaj poste forĵetis amason da cimoj fine de la monato, ĉi tio ne estas ĝusta kaj ne bona.
Integriĝo kun koda reviziosistemo
Unufoje, ni starigas la teknikan uzanton de AppSec kiel la defaŭltan recenziston en kelkaj gravaj projektoj. Depende de ĉu eraroj estis trovitaj en la nova kodo aŭ ne estas eraroj, la recenzisto metas la statuson sur la tiran peton por "akcepti" aŭ "bezoni laboron" - aŭ ĉio estas en ordo, aŭ vi devas fini kaj ligi al kio ĝuste. fini. Por integriĝo kun la versio kiu estas publikigita, ni malŝaltis kunfandi se la IS-testo ne estas trapasita. Ni inkluzivis ĉi tion en la mana koda revizio, kaj la ceteraj procezpartoprenantoj vidis la sekurecajn statusojn por ĉi tiu aparta procezo.
Integriĝo kun SonarQube
Multaj havas rilate al kodkvalito. Ĉi tie estas same - vi povas fari la samajn pordegojn nur por SAST-instrumentoj. Estos la sama interfaco, la sama kvalita pordego, nur ĝi estos nomita sekureca pordego. Kaj ankaŭ, se vi havas procezon instalitan uzante SonarQube, vi povas facile integri ĉion tie.
Integriĝo ĉe la CI-nivelo
Ĉi tie ankaŭ ĉio estas sufiĉe simpla:
- Same kun aŭtotestoj, unutestoj.
- Divido laŭ evoluaj etapoj: dev, testo, prod. Malsamaj reguloj povas esti inkluzivitaj, aŭ malsamaj malsukcesaj kondiĉoj: ni ĉesigas la asembleon, ni ne ĉesas la asembleon.
- Sinkrona / nesinkrona komenco. Ni atendas la finon de la sekurecaj testoj aŭ ni ne atendas. Tio estas, ni ĵus lanĉis ilin kaj pluiras, kaj tiam ni ricevas statuson, ke ĉio estas bona aŭ malbona.
Ĉio estas en perfekta rozkolora mondo. En la reala vivo, ĉi tio ne estas la kazo, sed ni strebas. La rezulto de farado de sekureckontroloj devus esti simila al la rezultoj de unutestoj.
Ekzemple, ni prenis grandan projekton kaj decidis, ke nun ni skanos ĝin per SAST - OK. Ni ŝovis ĉi tiun projekton en SAST, ĝi donis al ni 20 vundeblecojn, kaj ni faris fortevolan decidon, ke ĉio estas en ordo. 000 vundeblecoj estas nia teknika ŝuldo. Ni metos la ŝuldon en skatolon, ni malrapide rastos ĝin kaj komencos cimojn en difektaj spuriloj. Dungu kompanion, faru ĉion mem aŭ lasu Sekurec-Ĉampionojn helpi nin, kaj teknika ŝuldo malpliiĝos.
Kaj ĉiuj lastatempe aperantaj vundeblecoj en la nova kodo devas esti forigitaj sammaniere kiel eraroj en unuo aŭ en aŭtotestoj. Relative parolante, la asembleo komenciĝis, forveturis, du provoj kaj du sekurecaj provoj falis malsupren. Bone - ni iris, rigardis kio okazis, korektis unu, korektis la duan, veturis la sekvan fojon - ĉio estas en ordo, neniuj novaj vundeblecoj aperis, la testoj ne malsukcesis. Se ĉi tiu tasko estas pli profunda kaj vi devas bone kompreni ĝin, aŭ ripari vundeblecojn influas grandajn tavolojn de tio, kio kuŝas sub la kapuĉo: cimo estas alportita en la difektan spurilon, ĝi estas prioritatita kaj riparita. Bedaŭrinde, la mondo ne estas perfekta kaj provoj foje malsukcesas.
Ekzemplo de sekurecpordego estas analogo de kvalita pordego, laŭ la ĉeesto kaj nombro da vundeblecoj en la kodo.
Ni integras kun SonarQube - la kromaĵo estas instalita, ĉio estas tre oportuna kaj malvarmeta.
Disvolva medio integriĝo
Opcioj de integriĝo:
- Komencante skanadon de la evolumedio eĉ antaŭ la transdono.
- Vidu rezultojn.
- Analizo de rezultoj.
- Sinkronigo kun la servilo.
Jen kiel aspektas ricevi rezultojn de la servilo.
En nia evolua medio ĝi nur aperas plia ero, kiu diras, ke tiaj vundeblecoj estis trovitaj dum la skanado. Vi povas tuj redakti la kodon, vidi rekomendojn kaj . Ĉio ĉi situas ĉe la laborejo de la programisto, kio estas tre oportuna - vi ne bezonas sekvi la ceterajn ligilojn kaj rigardi ion kroman.
Malferma Fonto
Ĉi tiu estas mia plej ŝatata temo. Ĉiuj uzas Malfermkodajn bibliotekojn - kial skribi amason da lambastonoj kaj bicikloj, kiam oni povas preni pretan bibliotekon, en kiu ĉio jam estas efektivigita?
Kompreneble, tio estas vera, sed bibliotekoj ankaŭ estas skribitaj de homoj, ankaŭ inkluzivas certajn riskojn, kaj ankaŭ ekzistas vundeblecoj, kiuj periode aŭ konstante raportas. Tial, estas sekva paŝo en Aplika Sekureco - ĉi tio estas la analizo de Malfermfontaj komponantoj.
Malferma Fonta Analizo - OSA
La ilo inkluzivas tri ĉefajn paŝojn.
Trovi vundeblecojn en bibliotekoj. Ekzemple, la ilo scias, ke ni uzas ian bibliotekon, kaj ke en aŭ en cimspuriloj estas iuj vundeblecoj, kiuj rilatas al ĉi tiu versio de la biblioteko. Se vi provas uzi ĝin, la ilo avertos vin, ke la biblioteko estas vundebla, kaj konsilos vin uzi alian version kie ne estas vundeblecoj.
Analizo de licenca pureco. Ĉi tio ankoraŭ ne estas tre populara ĉe ni, sed se vi laboras kun fremda lando, tiam vi povas periode ricevi atakon por uzi malfermfontan komponanton, kiu ne povas esti uzata aŭ modifita. Laŭ la politiko de la licencita biblioteko, ni ne povas fari tion. Aŭ, se ni modifis ĝin kaj uzis ĝin, ni devas afiŝi nian kodon. Kompreneble, neniu volas afiŝi la kodon de siaj produktoj, sed vi ankaŭ povas protekti vin kontraŭ ĉi tio.
Analizo de komponantoj uzataj en industria medio. Imagu hipotezan situacion, ke ni finfine kompletigis evoluon kaj publikigis la lastan eldonon de nia mikroservo al la industrio. Li loĝas tie mirinde – semajnon, monaton, jaron. Ni ne kolektas ĝin, ni ne faras sekureckontrolojn, ĉio ŝajnas esti bona. Sed subite, du semajnojn post la liberigo, aperas kritika vundebleco en la Malfermfonta komponento, kiun ni uzas en ĉi tiu aparta asembleo, en la industria medio. Se ni ne registras kion kaj kie ni uzas, tiam ĉi tiu vundebleco simple ne estos vidata. Iuj iloj havas la kapablon monitori vundeblecojn en bibliotekoj, kiuj estas nuntempe uzataj en prom. Ĝi estas tre utila.
Karakterizaĵoj:
- Malsamaj politikoj por malsamaj stadioj de evoluo.
- Monitoru komponantojn en industria medio.
- Kontrolo de bibliotekoj en la konturo de la organizo.
- Subteno por diversaj konstrusistemoj kaj lingvoj.
- Analizo de Docker-bildoj.
Kelkaj ekzemploj de gvidantoj en la kampo, kiuj okupiĝas pri la analizo de Malferma Fonto.
La sola senpaga estas de OWASP. Vi povas ŝalti ĝin ĉe la unuaj etapoj, vidi kiel ĝi funkcias kaj kion ĝi subtenas. Esence, ĉi tiuj estas ĉiuj nubaj produktoj, aŭ surlokaj, sed malantaŭ sia bazo ili ankoraŭ iras al Interreto. Ili ne sendas viajn bibliotekojn, sed haŝojn aŭ iliajn valorojn, kiujn ili kalkulas, kaj fingrospurojn al sia servilo por ricevi novaĵojn pri la ĉeesto de vundeblecoj.
Proceza Integriĝo
Kontrolo de la perimetra bibliotekokiuj estas elŝutitaj el eksteraj fontoj. Ni havas eksterajn kaj internajn deponejojn. Ekzemple, ni havas Nexus ene de Event Central, kaj ni volas certigi, ke ne ekzistas vundeblecoj kun la statuso "kritika" aŭ "alta" ene de nia deponejo. Vi povas agordi prokuradon per la Nexus Firewall Lifecycle-ilo por ke tiaj vundeblecoj estu forigitaj kaj ne inkluzivitaj en la interna deponejo.
CI-integriĝo. Sur la sama nivelo kun aŭtotestoj, unutestoj kaj divido en evolustadiojn: dev, testo, prod. En ĉiu etapo, vi povas elŝuti iujn ajn bibliotekojn, uzi ion ajn, sed se estas io malfacila kun la "kritika" statuso, vi verŝajne devus atentigi pri tio la programistojn en la stadio de eniro al la balbalo.
Artefakto integriĝo: Nexus kaj JFrog.
Integriĝo en la evolumedion. La iloj, kiujn vi elektas, devus havi integriĝon kun evoluaj medioj. La programisto devas havi aliron al la skanaj rezultoj de sia laborejo, aŭ la kapablon skani kaj kontroli la kodon por vundeblecoj antaŭ ol fari ĝin en CVS.
KD integriĝo. Ĉi tio estas bonega trajto, kiun mi tre ŝatas kaj pri kiu mi jam parolis - monitori la aperon de novaj vundeblecoj en industria medio. Ĝi funkcias tiel.
Ni havas Publikaj Komponantaj Deponejoj - iuj iloj ekstere, kaj nia interna deponejo. Ni volas, ke nur fidindaj komponantoj estu en ĝi. Dum prokurado de peto, ni kontrolas, ke la elŝutita biblioteko ne havas vundeblecojn. Se ĝi apartenas al certaj politikoj, kiujn ni starigas kaj nepre kunordigas kun la evoluo, tiam ni ne alŝutas ĝin kaj ni ricevas rifuzon uzi alian version. Sekve, se estas io vere kritika kaj malbona en la biblioteko, tiam la programisto ne ricevos la bibliotekon eĉ en la instalaĵo - li uzu version pli altan aŭ pli malaltan.
- Konstruante, ni kontrolas, ke neniu glitis ion malbonan, ke ĉiuj komponantoj estas sekuraj kaj neniu alportis ion danĝeran sur la flash drive.
- Ni nur havas fidindajn komponantojn en la deponejo.
- Dum deplojiĝo, ni denove kontrolas la pakaĵon mem: milito, kruĉo, DL aŭ Docker-bildo por la fakto, ke ĝi konformas al la politiko.
- Enirante la industrian medion, ni kontrolas kio okazas en la industria medio: kritikaj vundeblecoj aperas aŭ ne aperas.
Dinamika Analizo - DAST
Dinamikaj analiziloj estas fundamente malsamaj de ĉio, kio estis dirita antaŭe. Ĉi tio estas speco de imito de la laboro de la uzanto kun la aplikaĵo. Se ĉi tio estas TTT-apliko, ni sendas petojn imitante la laboron de la kliento, alklaku la butonojn ĉe la fronto, sendu artefaritajn datumojn de la formularo: citaĵoj, krampoj, signoj en malsamaj kodigoj por rigardi kiel la aplikaĵo funkcias kaj prilaboras eksteran. datumoj.
La sama sistemo permesas al vi kontroli ŝablonajn vundeblecojn en Malferma Fonto. Ĉar DAST ne scias, kiun Malferma Fonto ni uzas, ĝi simple ĵetas "malicajn" ŝablonojn kaj analizas la respondojn de la servilo:
- Jes, ĉi tie estas deserialigproblemo, sed ne ĉi tie.
Estas grandaj riskoj en ĉi tio, ĉar se vi faras ĉi tiun sekurecan teston sur la sama stando kun kiu laboras la testistoj, malagrablaj aferoj povas okazi.
- Alta ŝarĝo en la aplika servila reto.
- Neniuj integriĝoj.
- La kapablo ŝanĝi la agordojn de la analizita aplikaĵo.
- Ne estas subteno por la postulataj teknologioj.
- Malfacileco de agordo.
Ni havis situacion, kiam ni finfine lanĉis AppScan: ni batis la aliron al la aplikaĵo dum longa tempo, ricevis 3 kontojn kaj ĝojis - finfine ni kontrolos ĉion! Ni lanĉis skanadon, kaj la unua afero, kiun AppScan faris estis eniri la administran panelon, trapiki ĉiujn butonojn, ŝanĝi duonon de la datumoj, kaj poste mortigi la servilon entute per sia propra. -petoj. Evoluo kun Testado diris:
“Knaboj, ĉu vi ŝercas min?! Ni donis al vi kontojn, kaj vi metis la standon!
Konsideru eblajn riskojn. Ideale, preparu apartan standon por testado de informa sekureco, kiu estos izolita de la resto de la medio almenaŭ iel, kaj kondiĉe kontrolu la administran panelon, prefere en mana reĝimo. Ĉi tio estas pentesto - tiuj ceteraj procentoj de klopodoj kiujn ni ne konsideras nun.
Indas konsideri, ke vi povas uzi ĉi tion kiel analogon de ŝarĝtestado. En la unua etapo, vi povas ŝalti la dinamikan skanilon en 10-15 fadenoj kaj vidi kio okazas, sed kutime, kiel praktiko montras, nenio bona.
Kelkaj rimedoj, kiujn ni kutime uzas.
Indas reliefigi estas la "svisa tranĉilo" por iu ajn sekurecprofesiulo. Ĉiuj uzas ĝin kaj ĝi estas tre oportuna. Nova demo-versio de la entreprena eldono nun estis publikigita. Se antaŭe ĝi estis nur memstara utileco kun kromaĵoj, nun programistoj finfine faras grandan servilon, de kiu eblos administri plurajn agentojn. Ĝi estas bonega, mi rekomendas ke vi provu ĝin.
Proceza Integriĝo
La integriĝo estas sufiĉe bona kaj simpla: komenci skanadon post sukcesa instalado aplikoj sur la stando kaj skanado post sukcesa integriga testado.
Se la integriĝoj ne funkcias aŭ ekzistas stumpoj kaj mokfunkcioj, ĝi estas sensignifa kaj senutila - negrave kian ŝablonon ni sendos, la servilo ankoraŭ respondos same.
- Ideale, aparta testbenko.
- Antaŭ testado, skribu la ensalutan sekvencon.
- Testado de la administra sistemo estas nur manlibro.
procezo
Iom ĝeneraligita pri la procezo ĝenerale kaj pri la laboro de ĉiu ilo, aparte. Ĉiuj aplikoj estas malsamaj - unu funkcias pli bone kun dinamika analizo, alia kun statika analizo, la tria kun OpenSource-analizo, pentestoj, aŭ io alia ĝenerale, ekzemple, eventoj kun .
Ĉiu procezo devas esti kontrolita.
Por kompreni kiel la procezo funkcias kaj kie ĝi povas esti plibonigita, vi devas kolekti metrikojn de ĉio, kion vi povas akiri en viaj manoj, inkluzive de produktadaj metrikoj, metrikoj de iloj kaj difektaj spuriloj.
Ajna informo estas helpema. Necesas rigardi en diversaj sekcioj kie tiu aŭ alia ilo estas pli bone uzata, kie la procezo specife malfortiĝas. Eble indas rigardi disvolvan respondtempon por kompreni kie plibonigi la procezon laŭ tempo. Ju pli da datumoj, des pli da tranĉoj povas esti konstruitaj de la plej alta nivelo ĝis la detaloj de ĉiu procezo.
Ĉar ĉiuj statikaj kaj dinamikaj analiziloj havas siajn proprajn APIojn, siajn proprajn lanĉajn metodojn, principojn, iuj havas planilojn, aliaj ne - ni skribas ilon. AppSec Orchestrator, kiu permesas vin fari ununuran enirpunkton al la tuta procezo de la produkto kaj administri ĝin de unu punkto.
Administrantoj, programistoj kaj sekurecaj inĝenieroj havas unu enirpunkton de kiu ili povas vidi kio funkcias, agordi kaj ruli skanaĵojn, ricevi skanajn rezultojn kaj sendi postulojn. Ni provas forigi paperojn, traduki ĉion en homan, kiun la disvolviĝo uzas - paĝoj pri Confluence kun stato kaj metriko, difektoj en Jira aŭ en diversaj difektaj spuriloj, aŭ enkonstrui sin en sinkronan / nesinkronan procezon en CI / KD.
Ŝlosilo Takeaways
La iloj ne gravas. Pripensu la procezon unue, poste efektivigu la ilojn. La iloj estas bonaj, sed multekostaj, do vi povas komenci kun la procezo kaj agordi la interagadon kaj komprenon inter evoluo kaj sekureco. El la vidpunkto de sekureco, ne necesas "halti" ĉion en vico. El la vidpunkto de disvolviĝo, se estas io alta mega super kritika, tiam ĉi tio devas esti forigita, kaj ne fermita al la problemo. .
Produkta kvalito - komuna celo kaj sekureco kaj evoluo. Ni faras unu aferon, ni provas certigi, ke ĉio funkcias ĝuste kaj ne estas reputaciaj riskoj kaj financaj perdoj. Tial ni antaŭenigas la aliron al DevSecOps, SecDevOps por establi komunikadon kaj plibonigi la produkton.
Komencu per kio jam estas tie: postuloj, arkitekturo, partaj kontroloj, trejnadoj, gvidlinioj. Ne necesas tuj apliki ĉiujn praktikojn al ĉiuj projektoj - moviĝi ripete. Ne ekzistas ununura normo eksperimento kaj provu malsamajn alirojn kaj solvojn.
Egala signo inter IS-difektoj kaj funkciaj difektoj.
Aŭtomatigu ĉiontio moviĝas. Ĉio, kio ne moviĝas, moviĝas kaj aŭtomatigas. Se io estas farita mane, ĉi tio ne estas bona parto de la procezo. Eble ankaŭ indas rekonsideri kaj aŭtomatigi ĝin.
Se la grandeco de la IB-teamo estas malgranda - uzu Sekurecajn Ĉampionojn.
Eble tio, pri kio mi parolis, ne konvenos al vi kaj vi elpensos ion propran – kaj tio estas bona. Sed elektu ilojn bazitajn sur la postuloj de via procezo. Ne rigardu, kion diras la komunumo, ke ĉi tiu ilo estas malbona kaj ĉi tiu bona. Eble estos inverse sur via produkto.
Ilaj postuloj.
- Malalta Falsa Pozitivo.
- Adekvata analiza tempo.
- La komforto de uzo.
- Havebleco de integriĝoj.
- Kompreni la vojmapon pri produkta disvolviĝo.
- Kapablo personecigi ilojn.
La raporto de Jurij estis elektita kiel unu el la plej bonaj ĉe DevOpsConf 2018. Por konatiĝi kun eĉ pli interesaj ideoj kaj praktikaj kazoj, venu al Skolkovo la 27-an kaj 28-an de majo ene . Eĉ pli bone, se vi pretas dividi vian sperton, do Sendu vian raporton ĝis la 21-a de aprilo.
fonto: www.habr.com