Takot at Poot sa DevSecOps

Nagkaroon kami ng 2 code analyzer, 4 dynamic testing tools, sarili naming crafts at 250 script. Hindi sa lahat ng ito ay kailangan sa kasalukuyang proseso, ngunit sa sandaling simulan mo ang pagpapatupad ng DevSecOps, kailangan mong pumunta sa dulo.

Pinagmulan. Mga tagalikha ng karakter: Justin Roiland at Dan Harmon.

Ano ang SecDevOps? Paano naman ang DevSecOps? Ano ang mga pagkakaiba? Seguridad ng Application - tungkol saan ito? Bakit hindi na gumagana ang klasikong diskarte? Alam ang sagot sa lahat ng mga tanong na ito Yuri Shabalin ng Seguridad ng Swordfish. Sasagutin ni Yuri ang lahat nang detalyado at susuriin ang mga problema ng paglipat mula sa klasikal na modelo ng Application Security sa proseso ng DevSecOps: kung paano maayos na lapitan ang pagsasama ng secure na proseso ng pag-unlad sa proseso ng DevOps at hindi masira ang anuman, kung paano dumaan sa mga pangunahing yugto ng pagsubok sa seguridad, anong mga tool ang maaaring gamitin, at kung ano ang kanilang pagkakaiba at kung paano i-configure ang mga ito nang tama upang maiwasan ang mga pitfalls.

Tungkol sa tagapagsalita: Yuri Shabalin - Chief Security Architect sa kumpanya Seguridad ng Swordfish. Responsable para sa pagpapatupad ng SSDL, para sa pangkalahatang pagsasama ng mga tool sa pagsusuri ng application sa isang pinag-isang development at testing ecosystem. 7 taong karanasan sa seguridad ng impormasyon. Nagtrabaho sa Alfa-Bank, Sberbank at Positive Technologies, na bumubuo ng software at nagbibigay ng mga serbisyo. Tagapagsalita sa mga internasyonal na kumperensya ZerONights, PHDays, RISSPA, OWASP.

Seguridad ng Application: tungkol saan ito?

Security Security - Ito ang seksyon ng seguridad na responsable para sa seguridad ng aplikasyon. Hindi ito nalalapat sa imprastraktura o seguridad ng network, ngunit sa halip sa kung ano ang isinulat namin at kung ano ang pinagtatrabahuhan ng mga developer - ito ang mga pagkukulang at kahinaan ng mismong application.

direksiyon SDL o SDLC - Lifecycle ng pag-unlad ng seguridad - binuo ng Microsoft. Ang diagram ay nagpapakita ng canonical SDLC na modelo, ang pangunahing gawain kung saan ay ang pakikilahok ng seguridad sa bawat yugto ng pag-unlad, mula sa mga kinakailangan hanggang sa paglabas at paggawa. Napagtanto ng Microsoft na napakaraming mga bug sa industriya, marami pa sa kanila at kailangang gawin tungkol dito, at iminungkahi nila ang diskarteng ito, na naging kanonikal.

Ang Application Security at SSDL ay hindi naglalayong tuklasin ang mga kahinaan, gaya ng karaniwang pinaniniwalaan, ngunit sa pagpigil sa kanilang paglitaw. Sa paglipas ng panahon, ang canonical approach ng Microsoft ay napabuti, binuo, at ipinakilala sa isang mas malalim, mas detalyadong pagsisid.

Ang canonical SDLC ay lubos na detalyado sa iba't ibang mga pamamaraan - OpenSAMM, BSIMM, OWASP. Ang mga pamamaraan ay magkakaiba, ngunit sa pangkalahatan ay magkatulad.

Building Security In Maturity Model

pinakagusto ko BSIMM - Building Security In Maturity Model. Ang batayan ng pamamaraan ay ang paghahati ng proseso ng Application Security sa 4 na domain: Governance, Intelligence, SSDL Touchpoints at Deployment. Ang bawat domain ay may 12 kasanayan, na kinakatawan bilang 112 aktibidad.

Ang bawat isa sa 112 aktibidad ay may 3 antas ng kapanahunan: baguhan, intermediate at advanced. Maaari mong pag-aralan ang lahat ng 12 na kasanayan sa bawat seksyon, pumili ng mga bagay na mahalaga sa iyo, alamin kung paano ipatupad ang mga ito at unti-unting magdagdag ng mga elemento, halimbawa, static at dynamic na pagsusuri ng code o pagsusuri ng code. Isulat mo ang isang plano at mahinahon na magtrabaho ayon dito bilang bahagi ng pagpapatupad ng mga napiling aktibidad.

Bakit ang DevSecOps

Ang DevOps ay isang pangkalahatan, malaking proseso kung saan dapat isaalang-alang ang seguridad.

Sa simula pa DevOps kasangkot sa mga pagsusuri sa seguridad. Sa pagsasagawa, ang bilang ng mga pangkat ng seguridad ay mas maliit kaysa ngayon, at hindi sila kumilos bilang mga kalahok sa proseso, ngunit bilang isang control at supervisory body na nagpapataw ng mga kinakailangan dito at sinusuri ang kalidad ng produkto sa pagtatapos ng paglabas. Ito ay isang klasikong diskarte kung saan ang mga security team ay nasa likod ng pader mula sa pag-unlad at hindi lumahok sa proseso.

Ang pangunahing problema ay ang seguridad ng impormasyon ay hiwalay sa pag-unlad. Kadalasan ito ay ilang uri ng information security circuit at naglalaman ito ng 2-3 malalaki at mamahaling kasangkapan. Minsan bawat anim na buwan, darating ang source code o application na kailangang suriin, at isang beses sa isang taon ginagawa ang mga ito mga pentest. Ang lahat ng ito ay humahantong sa katotohanan na ang petsa ng paglabas para sa industriya ay naantala, at ang developer ay nalantad sa isang malaking bilang ng mga kahinaan mula sa mga awtomatikong tool. Imposibleng i-disassemble at ayusin ang lahat ng ito, dahil ang mga resulta para sa nakaraang anim na buwan ay hindi naayos, ngunit narito ang isang bagong batch.

Sa takbo ng trabaho ng aming kumpanya, nakikita namin na ang seguridad sa lahat ng mga lugar at industriya ay nauunawaan na oras na upang mahabol at paikutin ang pag-unlad sa parehong gulong - sa Maliksi. Ang paradigm ng DevSecOps ay ganap na akma sa maliksi na pamamaraan ng pagbuo, pagpapatupad, suporta at pakikilahok sa bawat paglabas at pag-ulit.

Paglipat sa DevSecOps

Ang pinakamahalagang salita sa Security Development Lifecycle ay "proseso". Dapat mong maunawaan ito bago ka mag-isip tungkol sa pagbili ng mga tool.

Ang simpleng pagsasama ng mga tool sa proseso ng DevOps ay hindi sapat—ang komunikasyon at pag-unawa sa pagitan ng mga kalahok sa proseso ay mahalaga.

Ang mga tao ay mas mahalaga, hindi mga kasangkapan.

Kadalasan, ang pagpaplano para sa isang secure na proseso ng pag-unlad ay nagsisimula sa pagpili at pagbili ng isang tool, at nagtatapos sa mga pagtatangka na isama ang tool sa kasalukuyang proseso, na nananatiling mga pagtatangka. Ito ay humahantong sa mga kapus-palad na kahihinatnan, dahil ang lahat ng mga tool ay may sariling mga katangian at limitasyon.

Ang isang karaniwang kaso ay kapag ang departamento ng seguridad ay pumili ng isang mahusay, mamahaling tool na may malawak na kakayahan, at pumunta sa mga developer upang isama ito sa proseso. Ngunit hindi ito gumana - ang proseso ay nakaayos sa paraang ang mga limitasyon ng nabili na tool ay hindi umaangkop sa kasalukuyang paradigm.

Una, ilarawan kung anong resulta ang gusto mo at kung ano ang magiging hitsura ng proseso. Makakatulong ito na maunawaan ang mga tungkulin ng tool at kaligtasan sa proseso.

Magsimula sa kung ano ang ginagamit na

Bago bumili ng mga mamahaling kasangkapan, tingnan kung ano ang mayroon ka na. Ang bawat kumpanya ay may mga kinakailangan sa seguridad para sa pag-unlad, mayroong mga tseke, mga pentest - bakit hindi ibahin ang lahat ng ito sa isang form na naiintindihan at maginhawa para sa lahat?

Kadalasan ang mga kinakailangan ay isang papel na Talmud na nakalagay sa isang istante. May isang kaso nang pumunta kami sa isang kumpanya upang tingnan ang mga proseso at hiniling na makita ang mga kinakailangan sa seguridad para sa software. Ang espesyalista na humarap dito ay gumugol ng mahabang panahon sa paghahanap para sa:

- Ngayon, sa isang lugar sa mga tala ay mayroong isang landas kung saan matatagpuan ang dokumentong ito.

Bilang resulta, natanggap namin ang dokumento makalipas ang isang linggo.

Para sa mga kinakailangan, pagsusuri at iba pang bagay, gumawa ng page sa hal. Confluence - ito ay maginhawa para sa lahat.

Mas madaling i-reformat ang mayroon ka na at gamitin ito para makapagsimula.

Gamitin ang Security Champions

Karaniwan, sa isang karaniwang kumpanya na may 100-200 na mga developer, mayroong isang espesyalista sa seguridad na gumaganap ng ilang mga function at walang pisikal na oras upang suriin ang lahat. Kahit na subukan niya ang kanyang makakaya, siya lamang ang hindi susuriin ang lahat ng code na nabuo ng pag-unlad. Para sa mga ganitong kaso, nabuo ang isang konsepto - Mga Kampeon sa Seguridad.

Ang Security Champions ay mga taong nasa development team na interesado sa seguridad ng iyong produkto.

Ang Security Champion ay isang entry point sa development team at isang security evangelist na pinagsama sa isa.

Karaniwan, kapag ang isang espesyalista sa seguridad ay pumunta sa isang development team at nagturo ng isang error sa code, nakakatanggap siya ng isang nakakagulat na sagot:

- At sino ka? First time kitang makita. Maayos ang lahat sa akin - binigyan ako ng aking senior na kaibigan ng "mag-apply" sa pagsusuri ng code, magpatuloy kami!

Ito ay isang tipikal na sitwasyon, dahil may higit na tiwala sa mga nakatatanda o simpleng mga kasamahan sa koponan kung saan ang developer ay patuloy na nakikipag-ugnayan sa trabaho at sa pagsusuri ng code. Kung, sa halip na ang opisyal ng seguridad, ang Security Champion ay itinuro ang pagkakamali at mga kahihinatnan, kung gayon ang kanyang salita ay magkakaroon ng higit na bigat.

Gayundin, mas alam ng mga developer ang kanilang code kaysa sa anumang espesyalista sa seguridad. Para sa isang tao na may hindi bababa sa 5 mga proyekto sa isang static na tool sa pagsusuri, kadalasan ay mahirap matandaan ang lahat ng mga nuances. Alam ng mga Security Champions ang kanilang produkto: kung ano ang nakikipag-ugnayan sa kung ano at kung ano ang unang tingnan - mas epektibo ang mga ito.

Kaya isaalang-alang ang pagpapatupad ng Security Champions at pagpapalawak ng impluwensya ng iyong security team. Ito ay kapaki-pakinabang din para sa kampeon mismo: propesyonal na pag-unlad sa isang bagong larangan, pagpapalawak ng kanyang mga teknikal na abot-tanaw, pag-upgrade ng teknikal, pangangasiwa at mga kasanayan sa pamumuno, pagtaas ng halaga sa merkado. Ito ay ilang elemento ng social engineering, ang iyong "mga mata" sa development team.

Mga yugto ng pagsubok

Paradigm 20 hanggang 80 sabi na 20% ng pagsisikap ay gumagawa ng 80% ng mga resulta. Ang 20% ​​na ito ay mga kasanayan sa pagsusuri ng aplikasyon na maaari at dapat na awtomatiko. Ang mga halimbawa ng naturang aktibidad ay static analysis - SAST, dinamikong pagsusuri - DAST и Kontrol sa Open Source. Sasabihin ko sa iyo nang mas detalyado ang tungkol sa mga aktibidad, pati na rin ang tungkol sa mga tool, kung anong mga feature ang karaniwan naming nararanasan kapag ipinapasok ang mga ito sa proseso, at kung paano ito gagawin nang tama.

Mga pangunahing problema ng mga tool

Iha-highlight ko ang mga problema na may kaugnayan sa lahat ng instrumento at nangangailangan ng pansin. Susuriin ko ang mga ito nang mas detalyado para hindi na maulit pa.

Mahabang oras ng pagsusuri. Kung mula sa commit to release ay aabutin ng 30 minuto para sa lahat ng pagsubok at pagpupulong, pagkatapos ay aabutin ng isang araw ang mga pagsusuri sa seguridad ng impormasyon. Kaya walang magpapabagal sa proseso. Isaalang-alang ang tampok na ito at gumawa ng mga konklusyon.

Mataas na antas False Negative o False Positive. Ang lahat ng mga produkto ay iba, lahat ay gumagamit ng iba't ibang mga frameworks at kanilang sariling coding style. Sa iba't ibang codebase at teknolohiya, maaaring magpakita ang mga tool ng iba't ibang antas ng False Negative at False Positive. Kaya tingnan kung ano ang eksaktong nasa iyong mga kumpanya at para sa iyong ang mga application ay magpapakita ng mabuti at maaasahang mga resulta.

Walang mga pagsasama sa mga umiiral nang tool. Tumingin sa mga tool sa mga tuntunin ng mga pagsasama sa kung ano ang ginagamit mo na. Halimbawa, kung mayroon kang Jenkins o TeamCity, suriin ang pagsasama ng mga tool sa software na ito, at hindi sa GitLab CI, na hindi mo ginagamit.

Kakulangan o labis na pagiging kumplikado ng pagpapasadya. Kung walang API ang isang tool, bakit ito kailangan? Lahat ng maaaring gawin sa interface ay dapat na available sa pamamagitan ng API. Sa isip, ang tool ay dapat magkaroon ng kakayahang mag-customize ng mga tseke.

Walang Roadmap ng Product Development. Hindi tumitigil ang pag-unlad, palagi kaming gumagamit ng mga bagong framework at function, na muling isinusulat ang lumang code sa mga bagong wika. Gusto naming makatiyak na susuportahan ng tool na binibili namin ang mga bagong framework at teknolohiya. Samakatuwid, mahalagang malaman na ang produkto ay may totoo at tama Roadmap pag-unlad.

Mga tampok ng proseso

Bilang karagdagan sa mga tampok ng mga tool, isaalang-alang ang mga tampok ng proseso ng pag-unlad. Halimbawa, ang paghadlang sa pag-unlad ay isang karaniwang pagkakamali. Tingnan natin kung ano ang iba pang mga tampok na dapat isaalang-alang at kung ano ang dapat bigyang pansin ng pangkat ng seguridad.

Upang hindi makaligtaan ang pagbuo at paglabas ng mga deadline, lumikha iba't ibang mga patakaran at iba show stoppers — pamantayan para sa pagpapahinto sa proseso ng pagbuo sa pagkakaroon ng mga kahinaan — para sa iba't ibang kapaligiran. Halimbawa, naiintindihan namin na ang kasalukuyang sangay ay napupunta sa development stand o UAT, na nangangahulugang hindi kami tumitigil at sasabihing:

"Mayroon kang mga kahinaan dito, hindi ka na magpapatuloy pa!"

Sa puntong ito, mahalagang sabihin sa mga developer na may mga isyu sa seguridad na nangangailangan ng pansin.

Ang pagkakaroon ng mga kahinaan ay hindi isang hadlang sa karagdagang pagsubok: manual, integration o manual. Sa kabilang banda, kailangan nating kahit papaano ay pataasin ang seguridad ng produkto, at upang hindi mapabayaan ng mga developer ang kanilang nakitang ligtas. Samakatuwid, kung minsan ginagawa namin ito: sa stand, kapag inilunsad ito sa kapaligiran ng pag-unlad, ipinapaalam lang namin ang pag-unlad:

- Guys, mayroon kang mga problema, mangyaring bigyang-pansin sila.

Sa yugto ng UAT muli kaming nagpapakita ng mga babala tungkol sa mga kahinaan, at sa yugto ng paglabas ay sinasabi namin:

- Guys, binalaan namin kayo ng ilang beses, wala kayong ginawa - hindi namin kayo papakawalan dito.

Kung pinag-uusapan natin ang tungkol sa code at dynamics, kinakailangan na ipakita at bigyan ng babala ang tungkol sa mga kahinaan lamang ng mga feature at code na iyon na kakasulat lang sa feature na ito. Kung ililipat ng developer ang isang button nang 3 pixels at sasabihin namin sa kanya na mayroon siyang SQL injection doon at samakatuwid ay kailangang ayusin kaagad, mali ito. Tingnan lamang kung ano ang nakasulat ngayon at ang pagbabagong darating sa aplikasyon.

Sabihin nating mayroon kaming isang tiyak na depekto sa pag-andar - ang paraan na hindi dapat gumana ang aplikasyon: hindi inililipat ang pera, kapag nag-click ka sa isang pindutan ay walang paglipat sa susunod na pahina, o hindi naglo-load ang produkto. Mga Depekto sa Seguridad - ito ay ang parehong mga depekto, ngunit hindi sa mga tuntunin ng pagpapatakbo ng aplikasyon, ngunit sa seguridad.

Hindi lahat ng problema sa kalidad ng software ay mga problema sa seguridad. Ngunit ang lahat ng mga problema sa seguridad ay nauugnay sa kalidad ng software. Sherif Mansour, Expedia.

Dahil ang lahat ng mga kahinaan ay magkaparehong mga depekto, dapat silang matatagpuan sa parehong lugar tulad ng lahat ng mga depekto sa pag-unlad. Kaya kalimutan ang tungkol sa mga ulat at nakakatakot na mga PDF na walang nagbabasa.

Noong nagtatrabaho ako sa isang kumpanya ng pagpapaunlad, nakatanggap ako ng ulat mula sa mga static na tool sa pagsusuri. Binuksan ko ito, natakot, nagtimpla ng kape, naglabas ng 350 na pahina, isinara ito at nagpatuloy sa pagtatrabaho. Ang malalaking ulat ay mga patay na ulat. Kadalasan ay wala silang napupuntahan, ang mga liham ay tinatanggal, nakalimutan, nawala, o sinasabi ng negosyo na tinatanggap nito ang mga panganib.

Anong gagawin? I-convert lang namin ang mga nakumpirmang depekto na nakita namin sa isang form na maginhawa para sa pag-unlad, halimbawa, inilagay namin ang mga ito sa isang backlog sa Jira. Inuna namin ang mga depekto at inalis ang mga ito sa pagkakasunud-sunod ng priyoridad, kasama ang mga functional na depekto at mga depekto sa pagsubok.

Static Analysis - SAST

Isa itong pagsusuri ng code para sa mga kahinaan., ngunit hindi ito katulad ng SonarQube. Hindi lang namin tinitingnan ang mga pattern o istilo. Ang isang bilang ng mga diskarte ay ginagamit sa pagsusuri: ayon sa puno ng kahinaan, ayon sa DataFlow, sa pamamagitan ng pagsusuri sa mga configuration file. Ito lang ang may kinalaman sa code mismo.

Mga kalamangan ng diskarte: pagtukoy ng mga kahinaan sa code sa isang maagang yugto ng pag-unladkapag wala pang mga stand o mga nakahandang kasangkapan, at incremental na kakayahan sa pag-scan: pag-scan sa isang seksyon ng code na nagbago, at tanging ang tampok na kasalukuyan naming ginagawa, na nagpapababa sa oras ng pag-scan.

Cons - ito ay ang kakulangan ng suporta para sa mga kinakailangang wika.

Mga kinakailangang pagsasama, na dapat nasa mga tool, sa aking pansariling opinyon:

• Tool sa pagsasama: Jenkins, TeamCity at Gitlab CI.
• Development environment: Intellij IDEA, Visual Studio. Ito ay mas maginhawa para sa isang developer na huwag mag-navigate sa isang hindi maintindihan na interface na kailangan pa ring isaulo, ngunit upang makita ang lahat ng kinakailangang pagsasama at kahinaan na nakita niya mismo sa lugar ng trabaho sa kanyang sariling kapaligiran sa pag-unlad.
• Pagsusuri ng code: SonarQube at manu-manong pagsusuri.
• Defect trackers: Jira at Bugzilla.

Ipinapakita ng larawan ang ilan sa mga pinakamahusay na kinatawan ng static na pagsusuri.

Hindi ang mga tool ang mahalaga, ngunit ang proseso, kaya may mga solusyon sa Open Source na mainam din para sa pagsubok sa proseso.

Ang SAST Open Source ay hindi makakahanap ng malaking bilang ng mga kahinaan o kumplikadong DataFlows, ngunit maaari at dapat gamitin ang mga ito kapag bumubuo ng isang proseso. Tumutulong sila na maunawaan kung paano gagawin ang proseso, sino ang tutugon sa mga bug, sino ang mag-uulat, at kung sino ang mag-uulat. Kung gusto mong isagawa ang unang yugto ng pagbuo ng seguridad ng iyong code, gumamit ng mga solusyon sa Open Source.

Paano ito maisasama kung ikaw ay nasa simula ng iyong paglalakbay at walang anuman: walang CI, walang Jenkins, walang TeamCity? Isaalang-alang natin ang pagsasama sa proseso.

Pagsasama sa antas ng CVS

Kung mayroon kang Bitbucket o GitLab, maaari kang magsama sa antas Sistema ng Kasabay na Mga Bersyon.

Sa pamamagitan ng kaganapan - humiling ng hilahin, mangako. I-scan mo ang code at ipinapakita ng status ng build kung pumasa o nabigo ang pagsusuri sa seguridad.

Feedback. Siyempre, palaging kailangan ang feedback. Kung gumawa ka lang ng seguridad sa gilid, ilagay ito sa isang kahon at hindi sinabi sa sinuman ang anumang bagay tungkol dito, at pagkatapos ay sa katapusan ng buwan ay nag-tapon ng isang grupo ng mga bug - ito ay hindi tama at hindi maganda.

Pagsasama sa sistema ng pagsusuri ng code

Minsan, kumilos kami bilang default na tagasuri para sa isang teknikal na gumagamit ng AppSec sa ilang mahahalagang proyekto. Depende sa kung natukoy ang mga error sa bagong code o walang mga error, itinatakda ng reviewer ang status sa pull request sa "tanggapin" o "kailangan ng trabaho" - alinman sa lahat ay OK, o ang mga link sa kung ano ang eksaktong kailangang pahusayin kailangang pagbutihin. Para sa pagsasama sa bersyon na papasok sa produksyon, pinagana namin ang pagbabawal sa pagsasama kung hindi naipasa ang pagsubok sa seguridad ng impormasyon. Isinama namin ito sa manu-manong pagsusuri ng code, at nakita ng ibang mga kalahok sa proseso ang mga katayuan ng seguridad para sa partikular na prosesong ito.

Pagsasama sa SonarQube

Marami ang mayroon kalidad na gate sa mga tuntunin ng kalidad ng code. Ito ay pareho dito - maaari mong gawin ang parehong mga gate para lamang sa mga tool ng SAST. Magkakaroon ng parehong interface, ang parehong gate ng kalidad, ito lamang ang tatawagin gate ng seguridad. At saka, kung mayroon kang proseso gamit ang SonarQube, madali mong maisasama ang lahat doon.

Pagsasama sa antas ng CI

Ang lahat dito ay medyo simple din:

• Katumbas ng mga autotest, mga pagsubok sa yunit.
• Dibisyon ayon sa mga yugto ng pag-unlad: dev, pagsubok, prod. Maaaring isama ang iba't ibang hanay ng mga panuntunan o iba't ibang kundisyon ng pagkabigo: itigil ang pagpupulong, huwag itigil ang pagpupulong.
• Synchronous/asynchronous na paglulunsad. Naghihintay kami para sa pagtatapos ng mga pagsubok sa seguridad o hindi. Ibig sabihin, inilunsad lang namin ang mga ito at magpatuloy, at pagkatapos ay nakuha namin ang status na lahat ay mabuti o masama.

Ang lahat ay nasa isang perpektong pink na mundo. Walang ganoon sa totoong buhay, ngunit nagsusumikap kami. Ang resulta ng pagpapatakbo ng mga pagsusuri sa seguridad ay dapat na katulad ng mga resulta ng mga pagsubok sa yunit.

Halimbawa, kumuha kami ng isang malaking proyekto at nagpasya na ngayon ay i-scan namin ito gamit ang SAST - OK. Itinulak namin ang proyektong ito sa SAST, nagbigay ito sa amin ng 20 kahinaan at sa pamamagitan ng isang malakas na desisyon ay nagpasya kaming maayos ang lahat. 000 mga kahinaan ang aming teknikal na utang. Ilalagay namin ang utang sa isang kahon, dahan-dahan naming tatanggalin ito at magdagdag ng mga bug sa mga tagasubaybay ng depekto. Mag-hire tayo ng kumpanya, gawin natin ang lahat, o tulungan tayo ng mga Security Champions - at bababa ang teknikal na utang.

At lahat ng bagong umuusbong na mga kahinaan sa bagong code ay dapat na alisin sa parehong paraan tulad ng mga error sa isang unit o sa mga autotest. Sa relatibong pagsasalita, nagsimula ang pagpupulong, pinatakbo namin ito, dalawang pagsubok at dalawang pagsubok sa seguridad ang nabigo. OK - pumunta kami, tiningnan kung ano ang nangyari, inayos ang isang bagay, inayos ang isa pa, pinatakbo ito sa susunod na pagkakataon - maayos ang lahat, walang lumitaw na mga bagong kahinaan, walang mga pagsubok na nabigo. Kung ang gawaing ito ay mas malalim at kailangan mong maunawaan ito ng mabuti, o ang pag-aayos ng mga kahinaan ay nakakaapekto sa malalaking layer ng kung ano ang nasa ilalim ng hood: isang bug ang idinagdag sa defect tracker, ito ay binibigyang-priyoridad at naitama. Sa kasamaang palad, ang mundo ay hindi perpekto at kung minsan ay nabigo ang mga pagsubok.

Ang isang halimbawa ng gate ng seguridad ay isang analogue ng isang de-kalidad na gate, sa mga tuntunin ng presensya at bilang ng mga kahinaan sa code.

Sumasama kami sa SonarQube - ang plugin ay naka-install, lahat ay napaka-maginhawa at cool.

Pagsasama sa kapaligiran ng pag-unlad

Mga opsyon sa pagsasama:

• Pagpapatakbo ng isang pag-scan mula sa kapaligiran ng pag-unlad bago gumawa.
• Tingnan ang Mga Resulta.
• Pagsusuri ng mga resulta.
• Pag-synchronize sa server.

Ito ang hitsura ng pagtanggap ng mga resulta mula sa server.

Sa ating kapaligiran sa pag-unlad Intellect IDEA lalabas lang ang isang karagdagang item na nagpapaalam sa iyo na ang mga naturang kahinaan ay nakita sa panahon ng pag-scan. Maaari mong agad na i-edit ang code, tingnan ang mga rekomendasyon at Graph ng Daloy. Ang lahat ng ito ay matatagpuan sa lugar ng trabaho ng developer, na napaka-maginhawa - hindi na kailangang sundin ang iba pang mga link at tumingin ng karagdagang bagay.

Open Source

Ito ang paborito kong paksa. Gumagamit ang lahat ng mga Open Source na aklatan - bakit magsulat ng isang grupo ng mga saklay at bisikleta kung maaari kang kumuha ng isang handa na library kung saan ang lahat ay naipatupad na?

Siyempre, totoo ito, ngunit ang mga aklatan ay isinulat din ng mga tao, kasama rin nila ang ilang mga panganib at mayroon ding mga kahinaan na pana-panahon, o patuloy, iniuulat. Samakatuwid, mayroong susunod na hakbang sa Application Security - ito ay ang pagsusuri ng mga bahagi ng Open Source.

Open Source Analysis - OSA

Kasama sa tool ang tatlong malalaking yugto.

Paghahanap ng mga kahinaan sa mga aklatan. Halimbawa, alam ng tool na gumagamit kami ng ilang library, at iyon ay CVE o may ilang mga kahinaan sa mga tagasubaybay ng bug na nauugnay sa bersyong ito ng library. Kapag sinubukan mong gamitin ito, maglalabas ang tool ng babala na mahina ang library at pinapayuhan kang gumamit ng ibang bersyon na walang mga kahinaan.

Pagsusuri ng kadalisayan ng lisensya. Hindi pa ito partikular na sikat dito, ngunit kung nagtatrabaho ka sa ibang bansa, pagkatapos ay paminsan-minsan maaari kang makakuha ng buwis doon para sa paggamit ng isang open source na bahagi na hindi magagamit o mabago. Ayon sa patakaran ng lisensyadong library, hindi namin ito magagawa. O, kung binago namin ito at gagamitin, dapat naming i-post ang aming code. Siyempre, walang gustong mag-publish ng code ng kanilang mga produkto, ngunit maaari mo ring protektahan ang iyong sarili mula dito.

Pagsusuri ng mga bahagi na ginagamit sa isang pang-industriyang kapaligiran. Isipin natin ang isang hypothetical na sitwasyon na sa wakas ay natapos na natin ang pag-develop at inilabas ang pinakabagong release ng ating microservice. Siya ay nakatira doon kahanga-hanga - isang linggo, isang buwan, isang taon. Hindi namin kinokolekta ito, hindi kami nagsasagawa ng mga pagsusuri sa kaligtasan, tila maayos ang lahat. Ngunit biglang, dalawang linggo pagkatapos ng paglabas, isang kritikal na kahinaan ang lilitaw sa bahagi ng Open Source, na ginagamit namin sa partikular na build na ito, sa kapaligirang pang-industriya. Kung hindi namin itatala kung ano at saan namin ginagamit, kung gayon hindi namin makikita ang kahinaang ito. May kakayahan ang ilang tool na subaybayan ang mga kahinaan sa mga library na kasalukuyang ginagamit sa industriya. Ito ay lubhang kapaki-pakinabang.

Mga Tampok:

• Iba't ibang mga patakaran para sa iba't ibang yugto ng pag-unlad.
• Pagsubaybay sa mga bahagi sa isang pang-industriyang kapaligiran.
• Kontrol ng mga aklatan sa loob ng organisasyon.
• Suporta para sa iba't ibang mga build system at wika.
• Pagsusuri ng mga larawan ng Docker.

Ilang halimbawa ng mga pinuno ng industriya na nakikibahagi sa pagsusuri sa Open Source.

Ang tanging libre ay ito Dependency-Check mula sa OWASP. Maaari mo itong i-on sa mga unang yugto, tingnan kung paano ito gumagana at kung ano ang sinusuportahan nito. Karaniwan, ang mga ito ay lahat ng mga produkto ng ulap, o nasa lugar, ngunit sa likod ng kanilang base ay ipinapadala pa rin sila sa Internet. Hindi nila ipinapadala ang iyong mga aklatan, ngunit ang mga hash o kanilang sariling mga halaga, na kanilang kinakalkula, at mga fingerprint sa kanilang server upang makatanggap ng impormasyon tungkol sa pagkakaroon ng mga kahinaan.

Pagsasama ng proseso

Kontrol ng perimeter ng mga aklatan, na dina-download mula sa mga panlabas na mapagkukunan. Mayroon kaming panlabas at panloob na mga repositoryo. Halimbawa, ang Event Central ay nagpapatakbo ng Nexus, at gusto naming matiyak na walang mga kahinaan sa loob ng aming repository na may "kritikal" o "mataas" na katayuan. Maaari mong i-configure ang pag-proxy gamit ang Nexus Firewall Lifecycle tool upang ang mga naturang kahinaan ay maputol at hindi mapunta sa panloob na imbakan.

Pagsasama sa CI. Sa parehong antas na may mga autotest, unit test at paghahati sa mga yugto ng pag-unlad: dev, test, prod. Sa bawat yugto, maaari kang mag-download ng anumang mga aklatan, gumamit ng anuman, ngunit kung mayroong isang bagay na mahirap sa "kritikal" na katayuan, marahil ito ay nagkakahalaga ng pagguhit ng pansin ng mga developer dito sa yugto ng paglabas sa produksyon.

Pagsasama sa mga artifact: Nexus at JFrog.

Pagsasama sa kapaligiran ng pag-unlad. Ang mga tool na pipiliin mo ay dapat may integration sa mga development environment. Dapat ay may access ang developer sa mga resulta ng pag-scan mula sa kanyang lugar ng trabaho, o ang kakayahang mag-scan at suriin mismo ang code para sa mga kahinaan bago mag-commit sa CVS.

Pagsasama ng CD. Ito ay isang cool na tampok na talagang gusto ko at napag-usapan ko na - pagsubaybay sa paglitaw ng mga bagong kahinaan sa isang industriyal na kapaligiran. Ito ay gumagana ng isang bagay tulad nito.

Meron kami Mga Public Component Repositories — ilang mga tool sa labas, at ang aming panloob na imbakan. Gusto naming maglaman lamang ito ng mga pinagkakatiwalaang bahagi. Kapag nag-proxy ng isang kahilingan, tinitingnan namin na ang na-download na library ay walang mga kahinaan. Kung napapailalim ito sa ilang partikular na patakaran na itinakda namin at kinakailangang makipag-ugnayan sa development, hindi namin ito ia-upload at ipo-prompt na gumamit ng ibang bersyon. Alinsunod dito, kung mayroong isang bagay na talagang kritikal at masama sa library, hindi matatanggap ng developer ang library sa yugto ng pag-install - hayaan siyang gumamit ng isang bersyon na mas mataas o mas mababa.

• Kapag nagtatayo, sinusuri namin na walang nadulas na anumang masama, na ang lahat ng mga sangkap ay ligtas at walang nagdala ng anumang mapanganib sa flash drive.
• Mayroon lang kaming mga pinagkakatiwalaang bahagi sa repositoryo.
• Kapag nagde-deploy, muli naming tinitingnan ang package mismo: war, jar, DL o Docker image para matiyak na sumusunod ito sa patakaran.
• Kapag pumapasok sa industriya, sinusubaybayan namin kung ano ang nangyayari sa kapaligirang pang-industriya: lumalabas o hindi lumalabas ang mga kritikal na kahinaan.

Dynamic na Pagsusuri - DAST

Ang mga tool sa dynamic na pagsusuri ay sa panimula ay naiiba sa lahat ng nasabi na noon. Ito ay isang uri ng imitasyon ng trabaho ng user sa application. Kung ito ay isang web application, nagpapadala kami ng mga kahilingan, tinutulad ang gawain ng kliyente, mag-click sa mga pindutan sa harap, magpadala ng artipisyal na data mula sa form: mga quote, bracket, mga character sa iba't ibang mga pag-encode, upang makita kung paano gumagana at nagpoproseso ang application panlabas na data.

Binibigyang-daan ka ng parehong system na suriin ang mga kahinaan ng template sa Open Source. Dahil hindi alam ng DAST kung aling Open Source ang ginagamit namin, naghagis lang ito ng mga "malicious" na pattern at sinusuri ang mga tugon ng server:

- Oo, mayroong problema sa deserialization dito, ngunit hindi dito.

May malalaking panganib dito, dahil kung magsasagawa ka ng security test na ito sa parehong bench na pinagtatrabahuhan ng mga tester, maaaring mangyari ang mga hindi kasiya-siyang bagay.

• Mataas na load sa network ng application server.
• Walang mga pagsasama.
• Kakayahang baguhin ang mga setting ng nasuri na application.
• Walang suporta para sa mga kinakailangang teknolohiya.
• Kahirapan sa pag-set up.

Nagkaroon kami ng sitwasyon nang sa wakas ay inilunsad namin ang AppScan: gumugol kami ng mahabang panahon sa pagsubok na makakuha ng access sa application, nakakuha ng 3 account at masaya - sa wakas ay susuriin namin ang lahat! Naglunsad kami ng pag-scan, at ang unang ginawa ng AppScan ay pumunta sa admin panel, tumusok sa lahat ng mga pindutan, palitan ang kalahati ng data, at pagkatapos ay ganap na patayin ang server gamit ang mailform-mga kahilingan. Sinabi ng pag-unlad na may pagsubok:

- Guys, niloloko niyo ba ako?! Binigyan ka namin ng mga account, at nag-set up ka ng stand!

Isaalang-alang ang mga posibleng panganib. Sa isip, maghanda ng isang hiwalay na stand para sa pagsubok ng seguridad ng impormasyon, na kung saan ay ihihiwalay mula sa natitirang bahagi ng kapaligiran kahit papaano, at kondisyon na suriin ang admin panel, mas mabuti sa manual mode. Ito ay isang pentest - ang mga natitirang porsyento ng pagsisikap na hindi natin isinasaalang-alang ngayon.

Ito ay nagkakahalaga ng pagsasaalang-alang na maaari mong gamitin ito bilang isang analogue ng pagsubok sa pag-load. Sa unang yugto, maaari mong i-on ang isang dynamic na scanner na may 10-15 na mga thread at makita kung ano ang mangyayari, ngunit kadalasan, tulad ng mga palabas sa pagsasanay, walang mabuti.

Ilang mapagkukunan na karaniwan naming ginagamit.

Worth highlighting Burp Suite ay isang "Swiss knife" para sa sinumang propesyonal sa seguridad. Ginagamit ito ng lahat at ito ay napaka-maginhawa. Ang isang bagong demo na bersyon ng enterprise edition ay inilabas na ngayon. Kung kanina ito ay isang stand alone na utility na may mga plugin, ngayon ang mga developer ay sa wakas ay gumagawa ng isang malaking server kung saan posible na pamahalaan ang ilang mga ahente. Ito ay cool, inirerekomenda kong subukan mo ito.

Pagsasama ng proseso

Ang pagsasama ay nangyayari nang maayos at simple: simulan ang pag-scan pagkatapos ng matagumpay na pag-install mga aplikasyon para sa stand at pag-scan pagkatapos ng matagumpay na pagsubok sa pagsasama.

Kung hindi gumana ang mga integration o may mga stub at mock function, ito ay walang kabuluhan at walang silbi - kahit anong pattern ang ipadala namin, tutugon pa rin ang server sa parehong paraan.

• Sa isip, isang hiwalay na testing stand.
• Bago ang pagsubok, isulat ang pagkakasunud-sunod ng pag-login.
• Ang pagsubok sa sistema ng pangangasiwa ay manu-mano lamang.

paraan

Medyo pangkalahatan tungkol sa proseso sa pangkalahatan at tungkol sa gawain ng bawat tool sa partikular. Iba-iba ang lahat ng application - ang isa ay gumagana nang mas mahusay sa dynamic na pagsusuri, ang isa ay may static na pagsusuri, ang pangatlo ay may OpenSource analysis, mga pentest, o iba pang bagay, halimbawa, mga kaganapan na may Waf.

Ang bawat proseso ay nangangailangan ng kontrol.

Upang maunawaan kung paano gumagana ang isang proseso at kung saan ito mapapahusay, kailangan mong mangolekta ng mga sukatan mula sa lahat ng maaari mong makuha, kabilang ang mga sukatan ng produksyon, mga sukatan mula sa mga tool, at mula sa mga tagasubaybay ng depekto.

Ang anumang impormasyon ay nakakatulong. Ito ay kinakailangan upang tumingin mula sa iba't ibang mga anggulo kung saan ito o ang tool na iyon ay mas mahusay na ginagamit, kung saan ang proseso ay partikular na lumubog. Maaaring sulit na tingnan ang mga oras ng pagtugon sa pag-unlad upang makita kung saan mapapahusay ang proseso batay sa oras. Kung mas maraming data, mas maraming mga seksyon ang maaaring mabuo mula sa pinakamataas na antas hanggang sa mga detalye ng bawat proseso.

Dahil ang lahat ng mga static at dynamic na analyzer ay may sariling mga API, kanilang sariling mga pamamaraan ng paglulunsad, mga prinsipyo, ang ilan ay may mga scheduler, ang iba ay wala - sumusulat kami ng isang tool AppSec Orchestrator, na nagbibigay-daan sa iyong lumikha ng isang entry point sa buong proseso mula sa produkto at pamahalaan ito mula sa isang punto.

Ang mga manager, developer at security engineer ay may isang entry point kung saan makikita nila kung ano ang tumatakbo, mag-configure at magpatakbo ng scan, makatanggap ng mga resulta ng pag-scan, at magsumite ng mga kinakailangan. Sinusubukan naming lumayo sa mga papeles, upang isalin ang lahat sa isang tao, na ginagamit ng pag-unlad - mga pahina sa Confluence na may katayuan at sukatan, mga depekto sa Jira o sa iba't ibang mga tagasubaybay ng depekto, o pagsasama sa isang kasabay/asynchronous na proseso sa CI /CD.

Key Takeaways

Ang mga tool ay hindi ang pangunahing bagay. Pag-isipan muna ang proseso - pagkatapos ay ipatupad ang mga tool. Ang mga tool ay mahusay ngunit mahal, kaya maaari kang magsimula sa proseso at bumuo ng komunikasyon at pag-unawa sa pagitan ng pag-unlad at seguridad. Mula sa isang punto ng kaligtasan, hindi na kailangang "itigil" ang lahat. Mula sa isang punto ng pag-unlad, kung mayroong isang bagay na mataas na mega na sobrang kritikal, pagkatapos ay kailangan itong alisin, at hindi pumikit sa problema.

Kalidad ng produkto - karaniwang layunin parehong seguridad at pag-unlad. Ginagawa namin ang isang bagay, sinisikap naming tiyakin na gumagana nang tama ang lahat at walang mga panganib sa reputasyon o pagkalugi sa pananalapi. Ito ang dahilan kung bakit nagpo-promote kami ng isang DevSecOps, SecDevOps na diskarte upang mapabuti ang komunikasyon at mapabuti ang kalidad ng produkto.

Magsimula sa kung ano ang mayroon ka na: mga kinakailangan, arkitektura, bahagyang pagsusuri, pagsasanay, mga alituntunin. Hindi na kailangang agad na ilapat ang lahat ng mga kasanayan sa lahat ng mga proyekto - umulit-ulit. Walang iisang pamantayan - eksperimento at subukan ang iba't ibang mga diskarte at solusyon.

Mayroong pantay na tanda sa pagitan ng mga depekto sa seguridad ng impormasyon at mga depekto sa pagganap.

I-automate ang lahatna gumagalaw. Anuman ang hindi gumagalaw, ilipat ito at i-automate ito. Kung ang isang bagay ay ginawa sa pamamagitan ng kamay, ito ay hindi isang magandang bahagi ng proseso. Marahil ay sulit na suriin ito at i-automate din ito.

Kung ang laki ng pangkat ng IS ay maliit - gamitin ang Security Champions.

Marahil ay hindi babagay sa iyo ang napag-usapan ko at makakaisip ka ng sarili mong bagay - at mabuti iyon. Pero pumili ng mga tool batay sa mga kinakailangan para sa iyong proseso. Huwag tingnan kung ano ang sinasabi ng komunidad, na ang tool na ito ay masama at ito ay mabuti. Marahil ang kabaligtaran ay magiging totoo para sa iyong produkto.

Mga kinakailangan para sa mga tool.

• Mababang antas False Positive.
• Sapat na oras ng pagsusuri.
• Dali ng paggamit.
• Availability ng mga pagsasama.
• Pag-unawa sa roadmap ng pagbuo ng produkto.
• Posibilidad ng pagpapasadya ng mga tool.

Ang ulat ni Yuri ay napili bilang isa sa mga pinakamahusay sa DevOpsConf 2018. Upang maging pamilyar sa mas kawili-wiling mga ideya at praktikal na mga kaso, pumunta sa Skolkovo sa Mayo 27 at 28 DevOpsConf sa loob ng pagdiriwang RIT++. Mas mabuti pa, kung handa ka nang ibahagi ang iyong karanasan, kung gayon mag-apply para sa ulat hanggang Abril 21.

Pinagmulan: www.habr.com