Hofu na Kuchukia DevSecOps

Tulikuwa na vichanganuzi 2 vya msimbo, zana 4 za majaribio madhubuti, ufundi wetu wenyewe na hati 250. Sio kwamba yote haya yanahitajika katika mchakato wa sasa, lakini mara tu unapoanza kutekeleza DevSecOps, unapaswa kwenda hadi mwisho.

Chanzo. Waundaji wa wahusika: Justin Roiland na Dan Harmon.

SecDevOps ni nini? Vipi kuhusu DevSecOps? Je, ni tofauti gani? Usalama wa Maombi - inahusu nini? Kwa nini mbinu ya kawaida haifanyi kazi tena? Anajua majibu ya maswali haya yote Yuri Shabalin ya Usalama wa Swordfish. Yuriy atajibu kila kitu kwa undani na kuchambua shida za mpito kutoka kwa mfano wa Usalama wa Maombi hadi mchakato wa DevSecOps: jinsi ya kukaribia ujumuishaji wa mchakato salama wa maendeleo katika mchakato wa DevOps na sio kuvunja chochote, jinsi ya kupitia hatua kuu. ya upimaji wa usalama, ni zana gani zinaweza kutumika, zinatofautiana nini na jinsi ya kuzisanidi kwa usahihi ili kuepusha mitego.

Kuhusu mzungumzaji: Yuri Shabalin - Msanifu Mkuu wa Usalama katika kampuni Usalama wa Swordfish. Inawajibika kwa utekelezaji wa SSDL, kwa ujumuishaji wa jumla wa zana za uchanganuzi wa programu katika mfumo ikolojia wa maendeleo na majaribio. Miaka 7 ya uzoefu katika usalama wa habari. Alifanya kazi Alfa-Bank, Sberbank na Positive Technologies, ambayo inakuza programu na kutoa huduma. Spika katika mikutano ya kimataifa ZerONights, PHDays, RISSPA, OWASP.

Usalama wa Maombi: inahusu nini?

Usalama wa Maombi - Hii ndio sehemu ya usalama ambayo inawajibika kwa usalama wa programu. Hii haitumiki kwa miundombinu au usalama wa mtandao, bali kwa kile tunachoandika na kile ambacho wasanidi programu wanafanyia kazi - haya ni mapungufu na udhaifu wa programu yenyewe.

mwelekeo SDL au SDLC - Mzunguko wa maisha ya maendeleo ya usalama - iliyotengenezwa na Microsoft. Mchoro unaonyesha mfano wa kisheria wa SDLC, kazi kuu ambayo ni ushiriki wa usalama katika kila hatua ya maendeleo, kutoka kwa mahitaji hadi kutolewa na uzalishaji. Microsoft iligundua kuwa kulikuwa na mende nyingi katika tasnia, kulikuwa na zaidi yao na kitu kilipaswa kufanywa juu yake, na walipendekeza njia hii, ambayo imekuwa ya kisheria.

Usalama wa Programu na SSDL hazilengi kugundua udhaifu, kama inavyoaminika, lakini kuzuia kutokea kwao. Baada ya muda, mbinu ya kisheria ya Microsoft imeboreshwa, kuendelezwa, na kuletwa katika upigaji mbizi wa kina, wa kina zaidi.

SDLC ya kisheria ina maelezo mengi katika mbinu mbalimbali - OpenSAMM, BSIMM, OWASP. Mbinu ni tofauti, lakini kwa ujumla ni sawa.

Kujenga Usalama Katika Mfano wa Ukomavu

Naipenda zaidi BSIMM - Kujenga Usalama Katika Mfano wa Ukomavu. Msingi wa mbinu ni mgawanyiko wa mchakato wa Usalama wa Maombi katika nyanja 4: Utawala, Upelelezi, Pointi za Kugusa za SSDL na Usambazaji. Kila kikoa kina mazoea 12, ambayo yanawakilishwa kama shughuli 112.

Kila moja ya shughuli 112 ina 3 viwango vya ukomavu: anayeanza, wa kati na wa hali ya juu. Unaweza kusoma mazoea yote 12 sehemu kwa sehemu, chagua mambo ambayo ni muhimu kwako, tambua jinsi ya kuyatekeleza na kuongeza hatua kwa hatua vipengele, kwa mfano, uchanganuzi wa kanuni tuli na thabiti au uhakiki wa msimbo. Unaandika mpango na kufanya kazi kwa utulivu kulingana nayo kama sehemu ya utekelezaji wa shughuli zilizochaguliwa.

Kwa nini DevSecOps

DevOps ni mchakato wa jumla, mkubwa ambao usalama lazima uzingatiwe.

Awali DevOps ilihusisha ukaguzi wa usalama. Kwa mazoezi, idadi ya timu za usalama ilikuwa ndogo zaidi kuliko sasa, na hawakufanya kama washiriki katika mchakato huo, lakini kama chombo cha udhibiti na usimamizi ambacho kinaweka mahitaji juu yake na kuangalia ubora wa bidhaa mwishoni mwa toleo. Hii ni mbinu ya kawaida ambapo timu za usalama zilikuwa nyuma ya ukuta kutoka kwa maendeleo na hazikushiriki katika mchakato huo.

Shida kuu ni kwamba usalama wa habari ni tofauti na maendeleo. Kawaida hii ni aina fulani ya mzunguko wa usalama wa habari na ina zana 2-3 kubwa na za gharama kubwa. Mara moja kila baada ya miezi sita, msimbo wa chanzo au programu ambayo inahitaji kuangaliwa hufika, na mara moja kwa mwaka hutolewa pentest. Haya yote husababisha ukweli kwamba tarehe ya kutolewa kwa tasnia imechelewa, na msanidi programu anakabiliwa na udhaifu mkubwa kutoka kwa zana za kiotomatiki. Haiwezekani kutenganisha na kutengeneza haya yote, kwa sababu matokeo ya miezi sita iliyopita hayakupangwa, lakini hapa kuna kundi jipya.

Wakati wa kazi ya kampuni yetu, tunaona kwamba usalama katika maeneo na viwanda vyote unaelewa kuwa ni wakati wa kupata na kuendeleza maendeleo kwa gurudumu moja - katika Agile. Mtazamo wa DevSecOps unalingana kikamilifu na mbinu ya maendeleo ya haraka, utekelezaji, usaidizi na ushiriki katika kila toleo na marudio.

Mpito kwa DevSecOps

Neno muhimu zaidi katika Mzunguko wa Maisha ya Maendeleo ya Usalama ni "mchakato". Lazima uelewe hili kabla ya kufikiria kuhusu kununua zana.

Kujumuisha zana tu katika mchakato wa DevOps haitoshi—mawasiliano na kuelewana kati ya washiriki wa mchakato ni muhimu.

Watu ni muhimu zaidi, sio zana.

Mara nyingi, kupanga kwa mchakato wa maendeleo salama huanza na kuchagua na kununua chombo, na kuishia na majaribio ya kuunganisha chombo katika mchakato wa sasa, ambao unabaki majaribio. Hii inasababisha matokeo mabaya, kwa sababu zana zote zina sifa zao wenyewe na mapungufu.

Kesi ya kawaida ni wakati idara ya usalama ilichagua zana nzuri, ya gharama kubwa yenye uwezo mpana, na ikaja kwa watengenezaji ili kuiunganisha katika mchakato. Lakini haifanyi kazi - mchakato umeundwa kwa njia ambayo mapungufu ya chombo kilichonunuliwa tayari haifai katika dhana ya sasa.

Kwanza, eleza ni matokeo gani unayotaka na mchakato utaonekanaje. Hii itasaidia kuelewa majukumu ya zana na usalama katika mchakato.

Anza na kile ambacho tayari kinatumika

Kabla ya kununua zana za gharama kubwa, angalia kile ulicho nacho. Kila kampuni ina mahitaji ya usalama kwa maendeleo, kuna hundi, pentes - kwa nini usibadilishe haya yote kuwa fomu inayoeleweka na rahisi kwa kila mtu?

Kawaida mahitaji ni Talmud ya karatasi ambayo iko kwenye rafu. Kulikuwa na kesi tulipokuja kwa kampuni ili kuangalia michakato na tukauliza kuona mahitaji ya usalama ya programu. Mtaalamu ambaye alishughulikia hii alitumia muda mrefu kutafuta:

- Sasa, mahali fulani katika maelezo kulikuwa na njia ambapo hati hii iko.

Kwa hiyo, tulipokea hati hiyo wiki moja baadaye.

Kwa mahitaji, hundi na mambo mengine, tengeneza ukurasa kwa k.m. Ushabiki - ni rahisi kwa kila mtu.

Ni rahisi kurekebisha ulicho nacho na kukitumia ili kuanza.

Tumia Mabingwa wa Usalama

Kwa kawaida, katika kampuni ya wastani yenye watengenezaji 100-200, kuna mtaalamu mmoja wa usalama ambaye hufanya kazi kadhaa na hawana kimwili wakati wa kuangalia kila kitu. Hata akijaribu awezavyo, yeye peke yake hataangalia kanuni zote ambazo maendeleo hutoa. Kwa hali kama hizi, dhana imetengenezwa - Mabingwa wa Usalama.

Mabingwa wa Usalama ni watu ndani ya timu ya uendelezaji ambao wanapenda usalama wa bidhaa yako.

Bingwa wa Usalama ni mahali pa kuingilia katika timu ya maendeleo na mwinjilisti wa usalama aliyejumuishwa katika timu moja.

Kawaida, mtaalamu wa usalama anapokuja kwa timu ya ukuzaji na kuashiria hitilafu katika msimbo, hupokea jibu la kushangaza:

- Na wewe ni nani? nakuona kwa mara ya kwanza. Kila kitu kiko sawa kwangu - rafiki yangu mkuu alinipa "tuma maombi" kwenye ukaguzi wa msimbo, tunaendelea!

Hii ni hali ya kawaida, kwa sababu kuna imani zaidi kwa wazee au wachezaji wenza ambao msanidi programu huingiliana nao kila mara kazini na katika ukaguzi wa kanuni. Ikiwa, badala ya afisa wa usalama, Bingwa wa Usalama anaonyesha kosa na matokeo, basi neno lake litakuwa na uzito zaidi.

Pia, wasanidi programu wanajua nambari zao bora kuliko mtaalamu yeyote wa usalama. Kwa mtu ambaye ana angalau miradi 5 katika chombo cha uchambuzi wa tuli, kwa kawaida ni vigumu kukumbuka nuances yote. Mabingwa wa Usalama wanajua bidhaa zao: ni nini huingiliana na nini na nini cha kuangalia kwanza - zinafaa zaidi.

Kwa hivyo zingatia kutekeleza Mabingwa wa Usalama na kupanua ushawishi wa timu yako ya usalama. Hii pia ni muhimu kwa bingwa mwenyewe: maendeleo ya kitaaluma katika uwanja mpya, kupanua upeo wake wa kiufundi, kuboresha ujuzi wa kiufundi, usimamizi na uongozi, kuongeza thamani ya soko. Hiki ni kipengele fulani cha uhandisi wa kijamii, "macho" yako katika timu ya maendeleo.

Hatua za majaribio

Paradigm 20 hadi 80 anasema kuwa 20% ya juhudi hutoa 80% ya matokeo. Hii 20% ni mazoea ya uchanganuzi wa programu ambayo yanaweza na yanapaswa kuwa otomatiki. Mifano ya shughuli hizo ni uchanganuzi tuli - SAST, uchambuzi wa nguvu - DAST и Udhibiti wa Chanzo huria. Nitakuambia kwa undani zaidi juu ya shughuli, na vile vile kuhusu zana, ni vipengele gani ambavyo kwa kawaida hukutana tunapovianzisha katika mchakato, na jinsi ya kuifanya kwa usahihi.

Shida kuu za zana

Nitaangazia shida ambazo zinafaa kwa vyombo vyote na zinahitaji umakini. Nitazichambua kwa undani zaidi ili nisizirudie tena.

Muda mrefu wa uchambuzi. Ikiwa kutoka kwa ahadi ya kutolewa itachukua dakika 30 kwa majaribio yote na mkusanyiko, basi ukaguzi wa usalama wa habari utachukua siku. Kwa hivyo hakuna mtu atakayepunguza mchakato. Zingatia kipengele hiki na ufikie hitimisho.

Kiwango cha juu Uongo Hasi au Uongo Chanya. Bidhaa zote ni tofauti, zote hutumia mifumo tofauti na mtindo wao wa usimbaji. Kwenye misingi na teknolojia tofauti za msimbo, zana zinaweza kuonyesha viwango tofauti vya Uongo Hasi na Chanya Uongo. Kwa hivyo angalia ni nini hasa ndani yako makampuni na kwa yako maombi yataonyesha matokeo mazuri na ya kuaminika.

Hakuna miunganisho na zana zilizopo. Angalia zana katika suala la miunganisho na kile ambacho tayari unatumia. Kwa mfano, ikiwa una Jenkins au TeamCity, angalia ushirikiano wa zana na programu hii, na si kwa GitLab CI, ambayo hutumii.

Ukosefu au utata mwingi wa ubinafsishaji. Ikiwa chombo hakina API, basi kwa nini inahitajika? Kila kitu kinachoweza kufanywa kwenye kiolesura kinapaswa kupatikana kupitia API. Kwa kweli, chombo kinapaswa kuwa na uwezo wa kubinafsisha hundi.

Hakuna Ramani ya Maendeleo ya Bidhaa. Maendeleo hayasimami tuli, kila mara tunatumia mifumo na vitendaji vipya, kuandika upya msimbo wa zamani katika lugha mpya. Tunataka kuwa na uhakika kwamba zana tunayonunua itasaidia mifumo na teknolojia mpya. Kwa hiyo, ni muhimu kujua kwamba bidhaa ina halisi na sahihi Roadmap maendeleo.

Mchakato wa vipengele

Mbali na vipengele vya zana, kuzingatia vipengele vya mchakato wa maendeleo. Kwa mfano, kuzuia maendeleo ni kosa la kawaida. Hebu tuangalie vipengele vingine vinapaswa kuzingatiwa na ni nini timu ya usalama inapaswa kuzingatia.

Ili usikose maendeleo na tarehe za mwisho za kutolewa, unda sheria tofauti na tofauti onyesha vizuizi - vigezo vya kusimamisha mchakato wa ujenzi mbele ya udhaifu - kwa mazingira tofauti. Kwa mfano, tunaelewa kuwa tawi la sasa huenda kwa stendi ya ukuzaji au UAT, ambayo inamaanisha kuwa hatuachi na kusema:

"Una udhaifu hapa, hautaenda popote zaidi!"

Katika hatua hii, ni muhimu kuwaambia watengenezaji kwamba kuna masuala ya usalama ambayo yanahitaji kuzingatiwa.

Uwepo wa udhaifu sio kikwazo kwa majaribio zaidi: mwongozo, ushirikiano au mwongozo. Kwa upande mwingine, tunahitaji kwa namna fulani kuongeza usalama wa bidhaa, na ili watengenezaji wasipuuze kile wanachokiona salama. Kwa hivyo, wakati mwingine tunafanya hivi: kwenye stendi, inapotolewa kwa mazingira ya maendeleo, tunaarifu tu maendeleo:

- Guys, una matatizo, tafadhali makini nao.

Katika hatua ya UAT tunaonyesha tena maonyo juu ya udhaifu, na katika hatua ya kutolewa tunasema:

- Vijana, tulikuonya mara kadhaa, haukufanya chochote - hatutakuacha na hii.

Ikiwa tunazungumzia kuhusu kanuni na mienendo, basi ni muhimu kuonyesha na kuonya kuhusu udhaifu tu wa vipengele na kanuni ambazo ziliandikwa tu katika kipengele hiki. Ikiwa msanidi atahamisha kitufe kwa pikseli 3 na tukamwambia kwamba ana sindano ya SQL hapo na kwa hivyo inahitaji kurekebishwa haraka, hii si sawa. Angalia tu kile kilichoandikwa sasa na mabadiliko yanayokuja kwenye programu.

Hebu sema tuna kasoro fulani ya kazi - njia ambayo maombi haipaswi kufanya kazi: fedha hazihamishiwi, unapobofya kifungo hakuna mpito kwenye ukurasa unaofuata, au bidhaa haipakia. Kasoro za Usalama - haya ni kasoro sawa, lakini si kwa suala la uendeshaji wa maombi, lakini kwa usalama.

Sio matatizo yote ya ubora wa programu ni matatizo ya usalama. Lakini matatizo yote ya usalama yanahusiana na ubora wa programu. Sherif Mansour, Expedia.

Kwa kuwa udhaifu wote ni kasoro sawa, unapaswa kuwekwa mahali sawa na kasoro zote za maendeleo. Kwa hivyo usahau kuhusu ripoti na PDF za kutisha ambazo hakuna mtu anayesoma.

Nilipokuwa nikifanya kazi katika kampuni ya maendeleo, nilipokea ripoti kutoka kwa zana za uchambuzi tuli. Niliifungua, nikaogopa, nikatengeneza kahawa, nikapitia kurasa 350, nikaifunga na kuendelea kufanya kazi. Ripoti kubwa ni ripoti zilizokufa. Kawaida hawaendi popote, barua hufutwa, kusahaulika, kupotea, au biashara inasema inakubali hatari.

Nini cha kufanya? Tunabadilisha tu kasoro zilizothibitishwa ambazo tumepata kuwa fomu inayofaa kwa usanidi, kwa mfano, tunaziweka kwenye kumbukumbu katika Jira. Tunatanguliza kasoro na kuziondoa kwa mpangilio wa kipaumbele, pamoja na kasoro za utendaji na kasoro za majaribio.

Uchambuzi tuli - SAST

Huu ni uchanganuzi wa msimbo wa udhaifu., lakini si sawa na SonarQube. Hatuangalii tu ruwaza au mtindo. Njia kadhaa hutumiwa katika uchambuzi: kulingana na mti wa mazingira magumu, kulingana na DataFlow, kwa kuchambua faili za usanidi. Haya ndiyo yote yanayohusu kanuni yenyewe.

Faida za mbinu: kutambua udhaifu katika msimbo katika hatua ya awali ya maendeleowakati hakuna anasimama au zana tayari-kufanywa bado, na uwezo wa skanning unaoongezeka: kuchanganua sehemu ya msimbo ambayo imebadilika, na kipengele pekee ambacho tunafanya kwa sasa, ambacho kinapunguza muda wa kuchanganua.

Africa - hii ni ukosefu wa msaada kwa lugha muhimu.

Muunganisho wa lazima, ambayo inapaswa kuwa kwenye zana, kwa maoni yangu ya kibinafsi:

• Chombo cha ujumuishaji: Jenkins, TeamCity na Gitlab CI.
• Mazingira ya maendeleo: Intellij IDEA, Visual Studio. Ni rahisi zaidi kwa msanidi programu kutopitia kiolesura kisichoeleweka ambacho bado kinahitaji kukaririwa, lakini kuona miunganisho yote muhimu na udhaifu ambao amepata mahali pa kazi katika mazingira yake ya maendeleo.
• Mapitio ya msimbo: SonarQube na ukaguzi wa mwongozo.
• Wafuatiliaji wa kasoro: Jira na Bugzilla.

Picha inaonyesha baadhi ya wawakilishi bora wa uchambuzi wa tuli.

Sio zana ambazo ni muhimu, lakini mchakato, kwa hivyo kuna suluhu za Open Source ambazo pia ni nzuri kwa kujaribu mchakato.

SAST Open Source haitapata idadi kubwa ya udhaifu au DataFlows changamano, lakini inaweza na inapaswa kutumika wakati wa kuunda mchakato. Wanasaidia kuelewa jinsi mchakato utajengwa, nani atajibu hitilafu, nani ataripoti, na nani ataripoti. Ikiwa unataka kutekeleza hatua ya awali ya kujenga usalama wa nambari yako, tumia suluhu za Open Source.

Hii inawezaje kuunganishwa ikiwa uko mwanzoni mwa safari yako na huna chochote: hakuna CI, hakuna Jenkins, hakuna TeamCity? Wacha tuzingatie ujumuishaji katika mchakato.

Ujumuishaji wa kiwango cha CVS

Ikiwa unayo Bitbucket au GitLab, unaweza kujumuisha kwa kiwango Mfumo wa Matoleo ya Sanjari.

Kwa tukio - ombi la kuvuta, kujitolea. Unachanganua msimbo na hali ya muundo inaonyesha kama ukaguzi wa usalama umepita au haukufaulu.

Maoni. Bila shaka, maoni yanahitajika kila wakati. Ikiwa ulifanya usalama tu upande, kuiweka kwenye sanduku na haukumwambia mtu yeyote kuhusu hilo, na kisha mwishoni mwa mwezi ukatupa kundi la mende - hii si sahihi na si nzuri.

Kuunganishwa na mfumo wa mapitio ya kanuni

Mara moja, tulifanya kama mkaguzi chaguomsingi wa mtumiaji wa kiufundi wa AppSec katika miradi kadhaa muhimu. Kulingana na kama makosa yametambuliwa katika msimbo mpya au hakuna makosa, mhakiki anaweka hali ya ombi la kuvuta ili "kukubali" au "kuhitaji kazi" - kila kitu kiko sawa, au viungo vya kile kinachohitaji kuboreshwa. inahitaji kuboreshwa. Ili kuunganishwa na toleo litakalotolewa kwa toleo la umma, tumewasha katazo la kuunganisha ikiwa jaribio la usalama wa habari halitapitishwa. Tulijumuisha hili katika ukaguzi wa msimbo wa mwongozo, na washiriki wengine katika mchakato waliona hali za usalama za mchakato huu mahususi.

Kuunganishwa na SonarQube

Wengi wamewahi lango la ubora kwa upande wa ubora wa kanuni. Ni sawa hapa - unaweza kutengeneza milango sawa kwa zana za SAST pekee. Kutakuwa na interface sawa, lango la ubora sawa, tu litaitwa lango la usalama. Na pia, ikiwa una mchakato wa kutumia SonarQube, unaweza kuunganisha kwa urahisi kila kitu hapo.

Ujumuishaji katika kiwango cha CI

Kila kitu hapa pia ni rahisi sana:

• Sambamba na majaribio ya kiotomatiki, vipimo vya kitengo.
• Mgawanyiko kwa hatua za maendeleo: dev, test, prod. Seti tofauti za sheria au hali tofauti za kushindwa zinaweza kuingizwa: kuacha mkusanyiko, usisitishe mkusanyiko.
• Uzinduzi wa kusawazisha/asynchronous. Tunasubiri mwisho wa vipimo vya usalama au la. Hiyo ni, tulizizindua tu na kuendelea, na kisha tunapata hali ya kuwa kila kitu ni nzuri au mbaya.

Yote yako katika ulimwengu mzuri wa waridi. Hakuna kitu kama hicho katika maisha halisi, lakini tunajitahidi. Matokeo ya kufanya ukaguzi wa usalama yanapaswa kuwa sawa na matokeo ya vipimo vya kitengo.

Kwa mfano, tulichukua mradi mkubwa na tukaamua kuwa sasa tutachanganua na SAST - OK. Tulisukuma mradi huu katika SAST, ulitupa udhaifu 20 na kwa uamuzi wa nia thabiti tuliamua kuwa kila kitu kilikuwa sawa. 000 udhaifu ni deni letu la kiufundi. Tutaweka deni kwenye sanduku, tutalifuta polepole na kuongeza hitilafu kwa wafuatiliaji kasoro. Hebu tuajiri kampuni, tufanye kila kitu sisi wenyewe, au tuwaombe Mabingwa wa Usalama watusaidie - na deni la kiufundi litapungua.

Na udhaifu wote mpya unaojitokeza katika msimbo mpya lazima uondolewe kwa njia sawa na makosa katika kitengo au katika majaribio ya kiotomatiki. Kwa kusema, mkutano ulianza, tuliendesha, majaribio mawili na vipimo viwili vya usalama vilishindwa. Sawa - tulikwenda, tukaangalia kilichotokea, tukarekebisha kitu kimoja, tukarekebisha kingine, tukaendesha wakati ujao - kila kitu kilikuwa sawa, hakuna udhaifu mpya ulionekana, hakuna vipimo vilivyoshindwa. Ikiwa kazi hii ni ya kina na unahitaji kuielewa vizuri, au kurekebisha udhaifu huathiri tabaka kubwa za kile kilicho chini ya kofia: hitilafu iliongezwa kwa kifuatiliaji cha kasoro, inapewa kipaumbele na kusahihishwa. Kwa bahati mbaya, ulimwengu sio mkamilifu na majaribio wakati mwingine hushindwa.

Mfano wa lango la usalama ni analog ya lango la ubora, kwa kuzingatia uwepo na idadi ya udhaifu katika msimbo.

Tunaunganisha na SonarQube - Plugin imewekwa, kila kitu ni rahisi sana na baridi.

Ushirikiano na mazingira ya maendeleo

Chaguzi za ujumuishaji:

• Kuendesha skanisho kutoka kwa mazingira ya ukuzaji kabla ya kujitolea.
• Tazama matokeo.
• Uchambuzi wa matokeo.
• Usawazishaji na seva.

Hivi ndivyo inavyoonekana kupokea matokeo kutoka kwa seva.

Katika mazingira yetu ya maendeleo WAZO la akili kipengee cha ziada kinaonekana tu ambacho kinakujulisha kuwa udhaifu kama huo uligunduliwa wakati wa skanning. Unaweza kuhariri msimbo mara moja, angalia mapendekezo na Grafu ya Mtiririko. Hii yote iko kwenye eneo la kazi la msanidi programu, ambayo ni rahisi sana - hakuna haja ya kufuata viungo vingine na kuangalia kitu cha ziada.

Open Source

Hii ndiyo mada ninayoipenda zaidi. Kila mtu hutumia maktaba ya Open Source - kwa nini uandike rundo la mikongojo na baiskeli wakati unaweza kuchukua maktaba iliyotengenezwa tayari ambayo kila kitu tayari kimetekelezwa?

Bila shaka, hii ni kweli, lakini maktaba pia yameandikwa na watu, pia yanajumuisha hatari fulani na pia kuna udhaifu ambao mara kwa mara, au mara kwa mara, huripotiwa. Kwa hiyo, kuna hatua inayofuata katika Usalama wa Maombi - hii ni uchambuzi wa vipengele vya Open Source.

Uchambuzi wa Chanzo Huria - OSA

Chombo kinajumuisha hatua tatu kubwa.

Inatafuta udhaifu katika maktaba. Kwa mfano, chombo kinajua kuwa tunatumia maktaba fulani, na kwamba ndani CVE au kuna baadhi ya udhaifu katika vifuatiliaji hitilafu vinavyohusiana na toleo hili la maktaba. Unapojaribu kuitumia, zana itatoa onyo kwamba maktaba iko hatarini na inakushauri kutumia toleo lingine ambalo halina udhaifu.

Uchambuzi wa usafi wa leseni. Hii si maarufu sana hapa bado, lakini ikiwa unafanya kazi nje ya nchi, basi mara kwa mara unaweza kupata ushuru huko kwa kutumia sehemu ya chanzo wazi ambayo haiwezi kutumika au kurekebishwa. Kulingana na sera ya maktaba yenye leseni, hatuwezi kufanya hivi. Au, ikiwa tuliirekebisha na kuitumia, tunapaswa kuchapisha msimbo wetu. Bila shaka, hakuna mtu anataka kuchapisha msimbo wa bidhaa zao, lakini unaweza pia kujikinga na hili.

Uchambuzi wa vipengele vinavyotumika katika mazingira ya viwanda. Hebu tuwazie hali ya dhahania ambayo hatimaye tumekamilisha utayarishaji na kutoa toleo jipya la huduma yetu ndogo. Anaishi huko kwa kushangaza - wiki, mwezi, mwaka. Hatuikusanyi, hatufanyi ukaguzi wa usalama, kila kitu kinaonekana kuwa sawa. Lakini ghafla, wiki mbili baada ya kutolewa, hatari kubwa inaonekana katika sehemu ya Open Source, ambayo tunatumia katika ujenzi huu, katika mazingira ya viwanda. Ikiwa hatutarekodi kile tunachotumia na wapi, basi hatutaona athari hii. Baadhi ya zana zina uwezo wa kufuatilia udhaifu katika maktaba ambazo zinatumika kwa sasa katika sekta hii. Ni muhimu sana.

Fursa:

• Sera tofauti kwa hatua tofauti za maendeleo.
• Vipengele vya ufuatiliaji katika mazingira ya viwanda.
• Udhibiti wa maktaba ndani ya shirika.
• Msaada kwa mifumo na lugha mbalimbali za ujenzi.
• Uchambuzi wa picha za Docker.

Mifano michache ya viongozi wa sekta ambao wanajishughulisha na uchanganuzi wa Open Source.

Ya bure pekee ni hii Utegemezi-Angalia kutoka OWASP. Unaweza kuiwasha katika hatua za kwanza, angalia jinsi inavyofanya kazi na inasaidia nini. Kimsingi, haya yote ni bidhaa za wingu, au kwenye msingi, lakini nyuma ya msingi wao bado hutumwa kwenye mtandao. Hawatumii maktaba zako, lakini heshi au thamani zao wenyewe, ambazo wanahesabu, na alama za vidole kwa seva zao ili kupokea taarifa kuhusu kuwepo kwa udhaifu.

Ujumuishaji wa mchakato

Udhibiti wa mzunguko wa maktaba, ambazo hupakuliwa kutoka kwa vyanzo vya nje. Tuna hazina za nje na za ndani. Kwa mfano, Event Central huendesha Nexus, na tunataka kuhakikisha kuwa hakuna udhaifu ndani ya hazina yetu yenye hali ya "muhimu" au "juu". Unaweza kusanidi seva mbadala kwa kutumia zana ya Nexus Firewall Lifecycle ili udhaifu kama huo ukatwe na usiishie kwenye hazina ya ndani.

Ujumuishaji katika CI. Katika kiwango sawa na majaribio ya kiotomatiki, majaribio ya vitengo na mgawanyiko katika hatua za ukuzaji: dev, test, prod. Katika kila hatua, unaweza kupakua maktaba yoyote, kutumia chochote, lakini ikiwa kuna kitu kigumu na hali ya "muhimu", labda inafaa kuvutia umakini wa watengenezaji kwa hili katika hatua ya kutolewa katika uzalishaji.

Kuunganishwa na mabaki: Nexus na JFrog.

Ujumuishaji katika mazingira ya maendeleo. Zana unazochagua zinapaswa kuwa na ushirikiano na mazingira ya maendeleo. Msanidi lazima awe na ufikiaji wa matokeo ya kuchanganua kutoka mahali pake pa kazi, au uwezo wa kuchanganua na kuangalia msimbo mwenyewe kwa udhaifu kabla ya kujitolea kwa CVS.

Ujumuishaji wa CD. Hiki ni kipengele kizuri ambacho ninakipenda sana na ambacho tayari nimeshakizungumzia - kufuatilia kuibuka kwa udhaifu mpya katika mazingira ya viwanda. Inafanya kazi kama hii.

Tuna Hazina za Sehemu za Umma - zana zingine nje, na hazina yetu ya ndani. Tunataka iwe na vijenzi vinavyoaminika pekee. Tunapotuma ombi, tunaangalia kuwa maktaba iliyopakuliwa haina udhaifu. Iwapo itakuwa chini ya sera fulani ambazo tunaweka na kuratibu na usanidi, basi hatuipaki na tunaombwa kutumia toleo lingine. Ipasavyo, ikiwa kuna kitu muhimu sana na kibaya kwenye maktaba, basi msanidi programu hatapokea maktaba katika hatua ya usakinishaji - wacha atumie toleo la juu au la chini.

• Wakati wa kujenga, tunaangalia kwamba hakuna mtu aliyepungua chochote kibaya, kwamba vipengele vyote ni salama na hakuna mtu aliyeleta chochote hatari kwenye gari la flash.
• Tuna vipengee vinavyoaminika pekee kwenye hifadhi.
• Wakati wa kupeleka, tunaangalia tena kifurushi chenyewe: war, jar, DL au Docker picha ili kuhakikisha kwamba kinatii sera.
• Tunapoingia kwenye tasnia, tunafuatilia kile kinachotokea katika mazingira ya viwanda: udhaifu mkubwa unaonekana au hauonekani.

Uchambuzi wa Nguvu - DAST

Zana za uchambuzi wa nguvu ni tofauti kimsingi na kila kitu ambacho kimesemwa hapo awali. Hii ni aina ya kuiga kazi ya mtumiaji na programu. Ikiwa hii ni programu ya wavuti, tunatuma maombi, kuiga kazi ya mteja, bonyeza kwenye vifungo mbele, kutuma data ya bandia kutoka kwa fomu: nukuu, mabano, wahusika katika encodings tofauti, kuona jinsi programu inavyofanya kazi na taratibu. data ya nje.

Mfumo huo huo hukuruhusu kuangalia udhaifu wa kiolezo katika Chanzo Huria. Kwa kuwa DAST haijui ni Chanzo Huria gani tunachotumia, inatupa tu ruwaza "hasidi" na kuchanganua majibu ya seva:

- Ndio, kuna shida ya kukata tamaa hapa, lakini sio hapa.

Kuna hatari kubwa katika hili, kwa sababu ikiwa utafanya mtihani huu wa usalama kwenye benchi moja ambayo wajaribu hufanya kazi nao, mambo yasiyopendeza yanaweza kutokea.

• Mzigo wa juu kwenye mtandao wa seva ya programu.
• Hakuna miunganisho.
• Uwezo wa kubadilisha mipangilio ya programu iliyochambuliwa.
• Hakuna msaada kwa teknolojia muhimu.
• Ugumu wa kuweka.

Tulikuwa na hali wakati hatimaye tulizindua AppScan: tulitumia muda mrefu kujaribu kupata programu, tukapata akaunti 3 na tukafurahi - hatimaye tutaangalia kila kitu! Tulizindua skana, na jambo la kwanza AppScan ilifanya ni kwenda kwenye paneli ya msimamizi, kutoboa vifungo vyote, kubadilisha nusu ya data, na kisha kuua kabisa seva na yake. fomu ya barua-maombi. Maendeleo na upimaji alisema:

- Guys, unanitania?! Tulikupa akaunti, na uliweka msimamo!

Fikiria hatari zinazowezekana. Kimsingi, tayarisha kisimamo tofauti cha kupima usalama wa habari, ambacho kitatengwa na mazingira mengine angalau kwa namna fulani, na kwa masharti angalia paneli ya msimamizi, ikiwezekana katika hali ya mwongozo. Hili ni pentest - zile asilimia zilizobaki za juhudi ambazo hatuzingatii sasa.

Inafaa kuzingatia kuwa unaweza kutumia hii kama analog ya upimaji wa mzigo. Katika hatua ya kwanza, unaweza kuwasha skana yenye nguvu na nyuzi 10-15 na uone kinachotokea, lakini kwa kawaida, kama inavyoonyesha mazoezi, hakuna kitu kizuri.

Rasilimali chache ambazo sisi hutumia kwa kawaida.

Inastahili kuangaziwa Suite ya Burp ni "kisu cha Uswizi" kwa mtaalamu yeyote wa usalama. Kila mtu anaitumia na ni rahisi sana. Toleo jipya la onyesho la toleo la biashara sasa limetolewa. Ikiwa mapema ilikuwa shirika la kusimama pekee na programu-jalizi, sasa watengenezaji hatimaye wanatengeneza seva kubwa ambayo itawezekana kusimamia mawakala kadhaa. Hii ni nzuri, napendekeza ujaribu.

Ujumuishaji wa mchakato

Ujumuishaji hufanyika vizuri na kwa urahisi: anza kuchanganua baada ya usakinishaji uliofanikiwa maombi ya stendi na skanning baada ya majaribio ya kuunganishwa kwa mafanikio.

Ikiwa miunganisho haifanyi kazi au kuna vitendaji na vitendaji vya kejeli, haina maana na haina maana - haijalishi ni muundo gani tunatuma, seva bado itajibu vivyo hivyo.

• Kimsingi, kusimama tofauti kupima.
• Kabla ya kupima, andika mlolongo wa kuingia.
• Upimaji wa mfumo wa usimamizi ni mwongozo tu.

mchakato

Ya jumla kidogo juu ya mchakato kwa ujumla na juu ya kazi ya kila zana haswa. Programu zote ni tofauti - moja hufanya kazi vizuri zaidi na uchanganuzi wa nguvu, nyingine na uchanganuzi tuli, ya tatu na uchanganuzi wa OpenSource, pentes, au kitu kingine kabisa, kwa mfano, matukio na Waf.

Kila mchakato unahitaji udhibiti.

Ili kuelewa jinsi mchakato unavyofanya kazi na wapi unaweza kuboreshwa, unahitaji kukusanya vipimo kutoka kwa kila kitu unachoweza kupata, ikiwa ni pamoja na vipimo vya uzalishaji, vipimo vya zana na kutoka kwa vifuatiliaji kasoro.

Taarifa yoyote ni ya manufaa. Inahitajika kuangalia kutoka kwa pembe tofauti ambapo hii au chombo hicho kinatumiwa vizuri, ambapo mchakato huo unapungua. Huenda ikafaa kuangalia nyakati za majibu ya usanidi ili kuona mahali pa kuboresha mchakato kulingana na wakati. Kadiri data inavyozidi, ndivyo sehemu nyingi zaidi zinaweza kujengwa kutoka kiwango cha juu hadi maelezo ya kila mchakato.

Kwa kuwa wachambuzi wote tuli na wenye nguvu wana API zao wenyewe, njia zao za uzinduzi, kanuni, wengine wana ratiba, wengine hawana - tunaandika chombo. AppSec Orchestrator, ambayo inakuwezesha kuunda hatua moja ya kuingia katika mchakato mzima kutoka kwa bidhaa na kuisimamia kutoka kwa hatua moja.

Wasimamizi, wasanidi programu na wahandisi wa usalama wana sehemu moja ya kuingilia ambapo wanaweza kuona kinachoendelea, kusanidi na kuendesha uchunguzi, kupokea matokeo ya kuchanganua, na kuwasilisha mahitaji. Tunajaribu kuachana na makaratasi, kutafsiri kila kitu kuwa cha kibinadamu, ambacho hutumiwa na ukuzaji - kurasa kwenye Mchanganyiko na hali na vipimo, kasoro katika Jira au vifuatiliaji kasoro kadhaa, au kuunganishwa kwa mchakato wa kusawazisha/asynchronous katika CI. /CD.

Kuchukua Muhimu

Zana sio jambo kuu. Kwanza fikiria mchakato - kisha utekeleze zana. Zana ni nzuri lakini ni ghali, hivyo unaweza kuanza na mchakato na kujenga mawasiliano na kuelewana kati ya maendeleo na usalama. Kutoka kwa mtazamo wa usalama, hakuna haja ya "kuacha" kila kitu.Kwa mtazamo wa maendeleo, ikiwa kuna kitu cha juu cha mega super muhimu, basi kinahitaji kuondolewa, na si kugeuka kipofu kwa tatizo.

Ubora wa bidhaa - lengo la kawaida usalama na maendeleo. Tunafanya jambo moja, tunajaribu kuhakikisha kwamba kila kitu kinafanya kazi kwa usahihi na hakuna hatari za sifa au hasara za kifedha. Hii ndiyo sababu tunatangaza mbinu ya DevSecOps, SecDevOps ili kuboresha mawasiliano na kuboresha ubora wa bidhaa.

Anza na ulichonacho tayari: mahitaji, usanifu, ukaguzi wa sehemu, mafunzo, miongozo. Hakuna haja ya kutumia mara moja mazoea yote kwa miradi yote - songa mara kwa mara. Hakuna kiwango kimoja - majaribio na jaribu mbinu na suluhisho tofauti.

Kuna ishara sawa kati ya kasoro za usalama wa habari na kasoro za utendaji.

Otomatiki kila kituhiyo inasonga. Kila kitu ambacho hakisogei, songa na kiotomatiki. Ikiwa kitu kinafanywa kwa mkono, sio sehemu nzuri ya mchakato. Labda inafaa kukagua na kuifanya kiotomatiki pia.

Ikiwa saizi ya timu ya IS ni ndogo - tumia Mabingwa wa Usalama.

Labda nilichozungumza hakitakufaa na utakuja na kitu chako - na hiyo ni nzuri. Lakini chagua zana kulingana na mahitaji ya mchakato wako. Usiangalie jamii inasemaje, kwamba chombo hiki ni kibovu na hiki ni kizuri. Labda kinyume chake kitakuwa kweli kwa bidhaa yako.

Mahitaji ya zana.

• Kiwango cha chini cha Uongo chanya.
• Muda wa kutosha wa uchambuzi.
• Urahisi wa matumizi.
• Upatikanaji wa miunganisho.
• Kuelewa ramani ya maendeleo ya bidhaa.
• Uwezekano wa kubinafsisha zana.

Ripoti ya Yuri ilichaguliwa kuwa mojawapo bora zaidi katika DevOpsConf 2018. Ili kufahamiana na mawazo ya kuvutia zaidi na kesi za vitendo, njoo Skolkovo mnamo Mei 27 na 28. DevOpsConf ndani tamasha RIT++. Afadhali zaidi, ikiwa uko tayari kushiriki uzoefu wako, basi kuomba kwa ripoti hiyo hadi Aprili 21.

Chanzo: mapenzi.com