measures ssdlc
Сазнајте о разним мерама безбедности које треба применити за безбедан СДЛЦ или ССДЛЦ:
Како технологија брзо расте, прикладне су и безбедносне претње хакирањем и крађом заштићених података. Дакле, нема сумње да технолошки раст ствара изазове произвођачима софтвера како би осигурали да њихов софтвер буде јак и робустан у односу на безбедносне претње и рањивости.
Софтверски производ не може се објавити, чак иако функционише савршено за предвиђену функционалност, осим ако се покаже високо заштићеним и не испуњава специфициране и регулисане стандарде безбедности и приватности, посебно у секторима попут одбране, финансија и здравства који укључују личне и финансијске податке .
Не може се приуштити сигурносна грешка на производу када је постављен, било да је то високе или средње тежине. Стога је веома важно заштитити софтвер и податке од било које врсте напада, злонамерних претњи, рањивости и осигурати поузданост софтвера крајњем кориснику.
За разлику од нашег традиционалног развоја софтвера, тестирање у последњој фази након развоја целог софтвера није ништа ефикасније. Имплементацијом Агиле, ДевОпс и СхифтЛефт концепта, неопходно је извршити тестирање у раној фази, као и у свакој фази животног циклуса апликације.
С обзиром на то, сигурност софтвера не може се изградити, па чак ни тестирати у последњој фази, па је стога потребно градити у свакој фази како би се осигурала укупна сигурност софтвера.
Шта ћете научити:
Мере безбедности за ССДЛЦ
У наставку су наведени различити начини мера повезаних са безбедношћу који се могу применити током животног циклуса развоја софтвера како би се осигурало безбедно СДЛЦ или ССДЛЦ и што је више могуће, недостаци се не могу пренети у следећу фазу.
Различите сигурносне анализе и процене у којима сигурност треба градити у СДЛЦ фазама су.
- Фаза захтева
- Фаза планирања
- Фаза архитектуре и дизајна: Процена безбедносног ризика заснована на дизајну.
- Фаза развоја: Анализа сигурног кода, статичка анализа кода за сигурност.
- Фаза имплементације: Динамичка анализа кода, тестирање сигурности апликација.
- Тестирање - фаза пре примене: Испитивање пенетрације и анализа рањивости.
# 1) Фаза захтева
- Првенствено, како би се осигурало да су неопходне мере безбедности уграђене у софтвер, Специфични захтеви везани за безбедност морају бити јасно обухваћени током фазе захтева са довољно детаља и очекиваних резултата.
- Током идентификовања типичних случајева употребе и пословних сценарија, јасан скуп Случајеви и сценарији коришћења у вези са безбедношћу у сврху верификације треба идентификовати како би се обухватиле сигурносне карактеристике и дизајнирали сценарији сигурносног тестирања.
У наставку је дато неколико примера који илуструју експлицитне захтеве у вези са безбедношћу који се могу обухватити.
Сек-Рек-01: Систем треба да има мере за потврду идентитета на свим улазима и улазним тачкама.
Сек-Рек-02: Систем је потребан за спровођење аутентификације путем сигурног екрана за пријављивање.
Сек-Рек-03: ЛИЧНИ ПОДАЦИ ће бити шифровани у мировању.
# 2) Фаза планирања
На високом нивоу, али не само ограниченом на њих, у фази планирања треба водити рачуна о следећим тачкама.
произвођач бесплатних дијаграма тока за мац
- Јак, Наменски тим за безбедност , који функционишу изван ПМО-а (канцеларије за управљање пројектима) програмског тима, који се састоји од Службеник за безбедност, архитекте за безбедност, испитивачи безбедности да се формира за непристрасно извођење и управљање свим безбедносним активностима програма. За сваку од ових улога дефинисани су јасни РнР (улоге и одговорности) и РАЦИ.
- Било који ескалације, нејасноће у вези са безбедносним питањима треба да се бави ПСО (службеник за безбедност производа), тако да тим за безбедност несметано функционише и помаже у доношењу исправних одлука.
- Робустан Стратегија испитивања безбедности наводећи како треба применити безбедносне захтеве, како, када и шта тестирати, које алате треба користити у свакој фази, треба идентификовати.
- Обавезно је укључити Контакт тачка безбедности за све техничке дискусије / прегледе у вези са програмом, тако да тим за безбедност буде свестан било каквих промена на програму.
# 3) Фаза архитектуре и дизајна
Раније обраћање више пажње на безбедносне аспекте током фазе дизајнирања помоћи ће спречавању безбедносних ризика и умањити значајне напоре у променама дизајна касније у СДЛЦ-у.
Приликом дизајнирања софтвера и инфраструктуре на којој ће софтвер бити домаћин, све је могуће Имплементације дизајна безбедности морају бити добро дизајнирани уз учешће архитеката обезбеђења.
Све двосмислености и сукоби између функционалног и нефункционалног аспекта дизајна и архитектуре морају се решити кроз сесије мозга које укључују праве заинтересоване стране.
Током ове фазе, детаљна процена ризика безбедности производа, која се такође понекад назива „Статичка процена“ треба да изврши тим стручњака за безбедност.
Процена безбедносног ризика укључује преглед програма са становишта безбедности у фази прелиминарног дизајна / архитектуре како би се идентификовале сигурносне мане из перспективе дизајна и сходно томе подигао Производ Ризици безбедности пројектном тиму да им се обрати и избегне улазак у следећу фазу.
Ове процене се врше на основу организационих / индустријских смерница, стандарда и контрола наведених у тим документима. На пример. УКСВ 00320, УКСВ 030017
Током процене ризика безбедности производа:
- Захтеви, карактеристике, корисничке приче и њихови пројектни документи се прегледавају на основу детаља, артефаката које дели пројектни тим, На пример. Пројектни документи (ХЛДД и ЛЛДД). Процене такође укључују разговоре са релевантним члановима пројектног тима у случају одсуства докумената или разјашњавање било каквих сумњи.
- Пропусти се идентификују приликом мапирања безбедносних захтева програма у односу на постављене стандарде и друге најбоље праксе. Понекад се развијају и модели претњи на основу утврђених празнина.
- Ове празнине су идентификоване као потенцијални безбедносни ризици, укључујући и предлагање могућих ублажавања за примену, покретање и управљање њима.
- Једном када пројектни тим примени ова ублажавања, они се верификују за затварање путем одговарајућих тест случајева које је осмислио тим за системски тест.
- Матрица управљања ризиком, која обезбеђује сљедивост, спремна је за праћење ових ризика. Одобрење и одјава са преосталим ризиком преузеће Сецурити Сецурити Арцхитецт и ПСО.
Типични обрасци претњи који се идентификују у фази дизајна повезани су са провером уноса, управљањем ревизијом / евиденцијом, конфигурацијама и шифровањем. Идентификација ризика укључује нападе на рањивости попут слабих лозинки, једноставних напада грубом силом итд.,
Типични прегледи укључују ризике у вези са приступом личним подацима, приступом ревизијским стазама, ентитетима који стављају на црне листе, активностима чишћења података и брисања.
Примери сценарија теста укључују:
- Рањивост преливања бафера: Да би се осигурало да ручним расплињавањем параметара не би требало успорити сервер и присилити сервер да не реагује (одбијање услуге).
- Санитизација података: Да би се осигурало да се за сваки улаз и излаз догоди исправна санитација података, тако да нападач не може убризгати и похранити злонамерни садржај у систем.
# 4) Фаза развоја
Анализа сигурног кода је Процена статичког кода метода која се користи за процену Безбедносни код различитих функција софтвера помоћу аутоматизованог алата за скенирање. Пример: Утврдити.
Ова анализа се врши при свакој пријави / изградњи кода да би се скенирао код генерисан за сигурносне пријетње. Ова процена се углавном врши на нивоу корисничке приче.
- Утврдити скенирања путем додатака треба инсталирати на машине програмера.
- Фортифи треба интегрисати са шаблоном за изградњу.
- Аутоматско скенирање вршиће се свакодневно у свим верзијама.
- Резултат скенирања ће анализирати сигурносни тим на лажне позитивне резултате.
- Кварови идентификовани овом проценом подижу се и управљају до затварања, тако да се процеђивање умањује / ставља на нулу на следећи ниво.
Примери сценарија теста укључују:
број цхар у инт ц ++
- Да бисте осигурали да се осетљиви подаци не шаљу у обичном тексту током преноса података.
- Да би се обезбедио сигуран пренос података, АПИ-ји окренути ка споља морају бити постављени на ХТТПС каналу.
# 5) Фаза имплементације
Динамичка анализа кода није ништа друго до тестирање безбедности апликација, које се такође назива ОВАСП (Опен Веб Апплицатион Сецурити Пројецт) тестирање. Анализа рањивости и испитивање пенетрације (ВАПТ) треба да се изврше у фази примене / тестирања.
Ова анализа процењује бинарне датотеке и неке конфигурације окружења и даље ојачава код за безбедносне захтеве.
Као део ове анализе, Динамичко понашање или се функционалност различитих карактеристика програма анализира на рањивости повезане са безбедношћу. Условљени случајеви употребе и пословни сценарији се такође користе за вршење динамичке анализе кода.
Ова активност се обавља на Тест Буилдс користећи разне сигурносне алате са аутоматизованим и ручним приступом.
- ХП ВебИнспецт, Бурп Суите, ЗАП и СОАП УИ алати се обично користе за проверу рањивости према стандардним базама података о рањивостима ( Пример: ОВАСП Топ 10 )
- Ова активност, иако је углавном аутоматизована, због одређених ограничења алата, можда ће бити потребан ручни рад да би се извршила тријажа лажно позитивних резултата.
- То се идеално ради у одвојеном окружењу (окружење за тестирање система), где се примењује софтвер спреман за тестирање.
- Потребно је подићи рањивости и довести их до затварања предложеним ублажавањем.
Типични обрасци претњи идентификовани током ове анализе повезани су са провером уноса, неисправном аутентификацијом и управљањем сесијама, изложеношћу осетљивих података, КССС и управљањем лозинком.
Примери сценарија теста укључују,
- Управљање лозинком: Да бисте осигурали да се лозинке не чувају у обичном тексту у конфигурационим датотекама или било где у систему.
- Цурење системских информација: Да би се осигурало да системске информације не процуре ни у једном тренутку, информације које открије принтСтацкТраце могу противнику помоћи у плану напада.
# 6) Тестирање - фаза пре примене
Пенетрација тестирање , Тест оловке укратко и Инфра ВАПТ (Анализа рањивости и испитивање пенетрације) , је потпун холистички тест са пуно решење и конфигурације (укључујући мрежу) који се идеално ради у предпроизводном или производном окружењу.
Ово се углавном изводи ради идентификације ДБ рањивости и рањивости сервера, заједно са било којим другим рањивостима. Ово је последња фаза испитивања безбедности која би се спровела. Стога ово такође укључује верификацију раније пријављених недостатака и ризика.
- Алати попут Нессус, Нмап, ХП Веб Инспецт, Бурп Суите, ЗАП који су доступни на тржишту користе се за тестирање оловке.
- Током овог тестирања врши се скенирање веб апликација помоћу аутоматизованих алата и експлоатација ради даље провере. Тестирање се врши како би се симулирало стварно понашање нападача, па стога може садржати и неколико негативних тестова.
- Рањивост инфраструктуре Процена укључује скенирање, анализу и преглед безбедносне конфигурације инфраструктуре (мреже, системи и сервери) ради идентификовања рањивости и провере отпорности на циљане нападе.
- Ово се изводи у предпродукцијском или производном окружењу, где се тестира софтвер који је спреман за примену и тако симулира окружење у реалном времену.
- Рањивости се идентификују помоћу скенера и ручних техника за уклањање лажних резултата. Такође, током ручног тестирања спроводиће се пословни сценарији у реалном времену.
- Израдиће се коначни извештај о целокупној Безбедносној анализи која се спроводи за цео програм истичући статус високо ризичних ставки ако постоје.
Примери сценарија теста укључују,
- Да бисте осигурали да осетљиве ХТТП методе нису омогућене.
- Да би се осигурало да осетљиви подаци осталих корисника нису видљиви у чистом тексту преко мреже.
- Да би се осигурало да се примењује валидација за отпремање датотека како би се избегло отпремање злонамерне датотеке.
Табеларни сажетак за ССДЛЦ
Доња табела сумира различите аспекте сигурносне анализе који су горе објашњени.
СДЛЦ фаза | Кључна анализа готова | Шта се тачно ради у овим проценама | Улазни | Алати који се користе | Оутпут |
---|---|---|---|---|---|
Захтеви | Да би се осигурало да су безбедносни захтеви ефикасно обухваћени. | Захтеви се анализирају. | Захтевани документи / корисничке приче / карактеристике | Приручник | Сигурносни захтеви уграђени су у спецификације захтева. |
Планирање | Оснивање сигурносног тима Припремљена стратегија испитивања безбедности. | Тим је идентификован и постављен. Стратегија припремљена, прегледана и одобрена са заинтересованим странама. | Нула | Приручник | Подешавање сигурносног тима са дефинисаним РнР и РАЦИ. Одјављен документ Стратегије сигурносног тестирања. |
Дизајн | Процена безбедносног ризика | Преглед докумената везаних за програм ради идентификовања сигурносних недостатака. Дискусија са тимом. Идентификују се ризици и предлажу се ублажавања. | Документи у вези са пројектом: ХЛДД, ЛЛДД. | Ручни преглед | Идентификовани дизајнерски ризици. Матрица управљања ризиком са предложеним ублажавањем. |
Развој | Анализа сигурног кода (статичка процена) | Сигурносни скенери су прикључени на машине програмера. Сигурносни алат интегрисан са предлошком градње. | Развијени кодекс | Аутоматизујте скенере (Фортифи). Ручна тријажа лажно позитивних резултата. | Осигурајте кварове кода. Матрица управљања ризиком са ублажавањем. |
Имплементација | Динамичка анализа кода (динамичка процена) | Завршено тестирање сигурности апликација. | Јединица тестирана Наменско испитивање окружења | Алати за испитивање безбедности (ХП ВебИнспецт, Бурп Суите, ЗАП Ручна тријажа лажно позитивних резултата. | Дефекти динамичке анализе кода. Матрица управљања ризиком са ублажавањем. |
Тестирање / пре распоређивања | Тест оловке, Инфра ВАПТ | Тестирање пенетрације и Инфра ВАПТ користећи сценарије у стварном времену. Верификација раније пријављених ризика / недостатака. | Спремни за примену верзије. Претходно произведена или производња попут животне средине. | Алати за испитивање сигурности (Нессус, НМАП, ХП ВебИнспецт) Ручна тријажа лажно позитивних резултата. | Матрица управљања ризиком са ублажавањем. Коначни извештај о безбедносном испитивању са статусом ризика. |
Закључак
Дакле, применом свих ових аспеката везаних за безбедност интегрисаних у различитим фазама СДЛЦ-а помаже организацији да идентификује сигурносне недостатке у раном циклусу и омогућава јој да примени одговарајуће ублажавање, избегавајући тако Високоризични сигурносни недостаци у Ливе систему.
Студија такође показује да се већина сигурносних недостатака уноси у софтвер током фазе развоја, тј. Током Фаза кодирања , при чему кодирање из било којих разлога није довољно водило рачуна о свим безбедносним аспектима.
У идеалном случају, ниједан програмер не би желео да напише лош код који угрожава сигурност. Стога, како би се програмери упутили како да напишу сигуран софтвер, следећи водич покрива Најбоље праксе и смернице за кодирање за програмере, како би се осигурала боља сигурност софтвера.
Надамо се да је ово упутство о сигурном СДЛЦ или ССДЛЦ било корисно !!
Препоручено читање
- СДЛЦ (животни циклус развоја софтвера) фазе, методологије, процеси и модели
- 10 најбољих алата за тестирање безбедности мобилних апликација у 2021. години
- 19 Моћни алати за испитивање пенетрације које су професионалци користили 2021. године
- Смернице за тестирање безбедности мобилне апликације
- Тестирање мрежне сигурности и најбољи алати мрежне сигурности
- Испитивање сигурности (Комплетан водич)
- Врх 4 алата за тестирање безбедности отвореног кода за тестирање веб апликација
- Водич за тестирање безбедности веб апликација