Страв и омраза од DevSecOps

Имавме 2 анализатори на кодови, 4 алатки за динамично тестирање, наши сопствени занаети и 250 скрипти. Не е дека сето ова е потребно во тековниот процес, но штом ќе започнете со имплементирање на DevSecOps, мора да одите до крај.

Извор. Креатори на ликови: Џастин Роиланд и Ден Хармон.

Што е SecDevOps? Што е со DevSecOps? Кои се разликите? Безбедност на апликацијата - за што се работи? Зошто класичниот пристап повеќе не функционира? Го знае одговорот на сите овие прашања Јуриј Шабалин на Безбедност на сабјарка. Јуриј ќе одговори на сè детално и ќе ги анализира проблемите на преминот од класичниот модел за безбедност на апликации во процесот DevSecOps: како правилно да пристапите кон интегрирањето на безбедниот развојен процес во процесот DevOps и да не прекршите ништо, како да поминете низ главните фази за безбедносно тестирање, кои алатки може да се користат и што се разликуваат и како правилно да се конфигурираат за да се избегнат стапици.

За говорникот: Јуриј Шабалин - Главен архитект за безбедност во компанијата Безбедност на сабјарка. Одговорен за имплементација на SSDL, за целокупната интеграција на алатките за анализа на апликации во унифициран екосистем за развој и тестирање. 7 години искуство во безбедноста на информациите. Работел во Alfa-Bank, Sberbank и Positive Technologies, кои развиваат софтвер и обезбедуваат услуги. Говорник на меѓународни конференции ZerONights, PHDays, RISSPA, OWASP.

Безбедност на апликацијата: за што се работи?

Безбедност на апликација - Ова е безбедносен дел кој е одговорен за безбедноста на апликациите. Ова не се однесува на инфраструктурата или безбедноста на мрежата, туку на она што го пишуваме и на што работат програмерите - ова се недостатоците и пропустите на самата апликација.

насока SDL или SDLC - Животен циклус на развој на безбедноста - развиен од Microsoft. Дијаграмот го прикажува канонскиот модел SDLC, чија главна задача е учеството на безбедноста во секоја фаза на развој, од барања до издавање и производство. Мајкрософт сфати дека има премногу грешки во индустријата, ги имаше повеќе и треба да се направи нешто околу тоа, и го предложија овој пристап, кој стана канонски.

Безбедноста на апликациите и SSDL не се насочени кон откривање на пропусти, како што обично се верува, туку кон спречување на нивното појавување. Со текот на времето, канонскиот пристап на Мајкрософт беше подобрен, развиен и воведен во подлабоко, подетално нуркање.

Канонскиот SDLC е многу детален во различни методологии - OpenSAMM, BSIMM, OWASP. Методологиите се различни, но генерално слични.

Модел за градење безбедност во зрелоста

Најмногу ми се допаѓа BSIMM - Модел за градење безбедност во зрелоста. Основата на методологијата е поделбата на процесот за безбедност на апликациите на 4 домени: Управување, разузнавање, SSDL Touchpoints и Deployment. Секој домен има 12 практики, кои се претставени како 112 активности.

Секоја од 112-те активности има 3 нивоа на зрелост: почетник, средно и напреден. Можете да ги проучувате сите 12 практики дел по дел, да изберете работи што ви се важни, да дознаете како да ги имплементирате и постепено да додавате елементи, на пример, статичка и динамичка анализа на код или преглед на код. Запишувате план и смирено работите според него како дел од спроведувањето на избраните активности.

Зошто DevSecOps

DevOps е општ, голем процес во кој мора да се земе предвид безбедноста.

Првично DevOps вклучени безбедносни проверки. Во пракса, бројот на безбедносните тимови беше многу помал од сега, и тие не дејствуваа како учесници во процесот, туку како контролно и надзорно тело кое му наметнува барања и го проверува квалитетот на производот на крајот од пуштањето. Ова е класичен пристап во кој безбедносните тимови беа зад ѕидот од развојот и не учествуваа во процесот.

Главниот проблем е што безбедноста на информациите е одвоена од развојот. Обично ова е некој вид кола за безбедност на информации и содржи 2-3 големи и скапи алатки. Еднаш на секои шест месеци пристигнува изворниот код или апликацијата што треба да се провери и еднаш годишно се произведуваат пентести. Сето ова води до фактот дека датумот на објавување за индустријата е одложен, а инвеститорот е изложен на огромен број пропусти од автоматизирани алатки. Невозможно е сето ова да се расклопи и поправи, бидејќи резултатите за претходните шест месеци не беа средени, но еве нова серија.

Во текот на работата на нашата компанија, гледаме дека безбедноста во сите области и индустрии разбира дека е време да се достигне и да се врти развојот на истото тркало - во Агилниот. Парадигмата DevSecOps совршено се вклопува со агилната развојна методологија, имплементација, поддршка и учество во секое издание и повторување.

Транзиција кон DevSecOps

Најважниот збор во Животниот циклус за развој на безбедноста е "процес". Мора да го разберете ова пред да размислите за купување алатки.

Едноставното вклучување алатки во процесот на DevOps не е доволно - важно е комуникацијата и разбирањето помеѓу учесниците во процесот.

Луѓето се поважни, а не алатките.

Честопати, планирањето за безбеден развојен процес започнува со избирање и купување алатка, а завршува со обиди да се интегрира алатката во тековниот процес, кои остануваат обиди. Ова води до несреќни последици, бидејќи сите алатки имаат свои карактеристики и ограничувања.

Чест случај е кога одделот за безбедност избра добра, скапа алатка со широки можности и дојде кај програмерите да ја интегрираат во процесот. Но, тоа не функционира - процесот е структуриран на таков начин што ограничувањата на веќе купената алатка не се вклопуваат во сегашната парадигма.

Прво, опишете каков исход сакате и како ќе изгледа процесот. Ова ќе помогне да се разберат улогите на алатката и безбедноста во процесот.

Започнете со она што е веќе во употреба

Пред да купите скапи алатки, погледнете што веќе имате. Секоја компанија има безбедносни барања за развој, има проверки, пентести - зошто сето ова да не се трансформира во форма која е разбирлива и погодна за секого?

Обично барањата се хартиен Талмуд што лежи на полица. Имаше случај кога дојдовме во една компанија да ги разгледаме процесите и побаравме да ги видиме безбедносните барања за софтверот. Специјалистот кој се занимаваше со ова помина долго време барајќи:

- Сега, некаде во белешките имаше патека каде што лежи овој документ.

Како резултат на тоа, го добивме документот една недела подоцна.

За барања, проверки и други работи, креирајте страница на пр. сливот - погодно е за секого.

Полесно е да го реформатирате она што веќе го имате и да го искористите за да започнете.

Користете безбедносни шампиони

Вообичаено, во просечна компанија со 100-200 програмери, има еден специјалист за безбедност кој извршува неколку функции и нема физички време да провери сè. Дури и да се потруди, тој сам нема да го провери целиот код што го генерира развојот. За такви случаи, развиен е концепт - Шампиони за безбедност.

Шампионите за безбедност се луѓе во тимот за развој кои се заинтересирани за безбедноста на вашиот производ.

Безбедниот шампион е влезна точка во тимот за развој и безбедносен евангелист вклопен во еден.

Обично, кога специјалист за безбедност доаѓа кај развојниот тим и укажува на грешка во кодот, тој добива изненаден одговор:

- И кој си ти? Се гледам за прв пат. Сè е во ред со мене - мојот постар пријател ми даде „пријавување“ на прегледот на кодот, продолжуваме понатаму!

Ова е типична ситуација, бидејќи има многу поголема доверба во постарите или едноставно соиграчите со кои развивачот постојано комуницира на работа и во прегледот на кодот. Ако наместо безбедносниот, шампионот од обезбедувањето укаже на грешката и последиците, тогаш неговиот збор ќе има поголема тежина.

Исто така, програмерите го знаат нивниот код подобро од кој било специјалист за безбедност. За лице кое има најмалку 5 проекти во алатка за статичка анализа, обично е тешко да се запамети сите нијанси. Шампионите за безбедност го знаат својот производ: што е во интеракција со што и што прво да се погледне - тие се поефикасни.

Затоа, размислете за имплементирање на „Security Champions“ и проширување на влијанието на вашиот безбедносен тим. Ова е корисно и за самиот шампион: професионален развој во ново поле, проширување на неговите технички хоризонти, надградба на технички, менаџерски и лидерски вештини, зголемување на пазарната вредност. Ова е некој елемент на социјалниот инженеринг, вашите „очи“ во тимот за развој.

Фази на тестирање

Парадигма од 20 до 80 вели дека 20% од напорот дава 80% резултати. Овие 20% се практики за анализа на апликации кои можат и треба да се автоматизираат. Примери за такви активности се статичка анализа - САСТ, динамичка анализа - DAST и Контрола со отворен код. Ќе ви кажам подетално за активностите, како и за алатките, со какви карактеристики обично се среќаваме кога ги воведуваме во процесот и како правилно да го направиме тоа.

Главните проблеми на алатките

Ќе ги истакнам проблемите кои се релевантни за сите инструменти и бараат внимание. Ќе ги анализирам подетално за да не ги повторувам понатаму.

Долго време за анализа. Ако од commit до објавување потребни се 30 минути за сите тестови и склопување, тогаш проверките за безбедноста на информациите ќе траат еден ден. Така, никој нема да го забави процесот. Земете ја предвид оваа карактеристика и извлечете заклучоци.

Високо ниво Лажно негативно или лажно позитивно. Сите производи се различни, сите користат различни рамки и свој стил на кодирање. На различни бази на кодови и технологии, алатките може да покажуваат различни нивоа на лажно негативно и лажно позитивно. Па погледнете што точно е во Вашиот компании и за твоето апликациите ќе покажат добри и сигурни резултати.

Нема интеграции со постоечките алатки. Погледнете ги алатките во однос на интеграциите со она што веќе го користите. На пример, ако имате Jenkins или TeamCity, проверете ја интеграцијата на алатките со овој софтвер, а не со GitLab CI, кој не го користите.

Недостаток или прекумерна сложеност на прилагодување. Ако алатката нема API, тогаш зошто е потребна? Сè што може да се направи во интерфејсот треба да биде достапно преку API. Идеално, алатката треба да има способност да ги приспособува проверките.

Нема патоказ за развој на производи. Развојот не мирува, ние секогаш користиме нови рамки и функции, го препишуваме стариот код на нови јазици. Сакаме да бидеме сигурни дека алатката што ја купуваме ќе поддржува нови рамки и технологии. Затоа, важно е да се знае дека производот има вистински и правилен патоказот развој.

Процесни карактеристики

Покрај карактеристиките на алатките, земете ги предвид карактеристиките на процесот на развој. На пример, попречувањето на развојот е честа грешка. Ајде да погледнеме кои други карактеристики треба да се земат предвид и на што треба да обрне внимание безбедносниот тим.

За да не ги пропуштите роковите за развој и ослободување, креирајте различни правила и различни покажуваат стопери — критериуми за запирање на процесот на градење во присуство на пропусти — за различни средини. На пример, разбираме дека тековната гранка оди на штандот за развој или UAT, што значи дека не застануваме и велиме:

„Имате ранливост овде, нема да одите никаде понатаму!

Во овој момент, важно е да им кажете на програмерите дека има безбедносни проблеми на кои им треба внимание.

Присуството на ранливости не е пречка за понатамошно тестирање: прирачник, интеграција или прирачник. Од друга страна, треба некако да ја зголемиме безбедноста на производот, а програмерите да не го занемарат она што го сметаат за безбедно. Затоа, понекогаш го правиме ова: на штандот, кога се пушта во развојната средина, едноставно го известуваме развојот:

- Момци, имате проблеми, ве молам обрнете внимание на нив.

Во фазата UAT повторно покажуваме предупредувања за ранливости, а во фазата на објавување велиме:

- Момци, ве предупредивме неколку пати, не направивте ништо - нема да ве пуштиме со ова.

Ако зборуваме за код и динамика, тогаш потребно е да се прикажат и предупредат за ранливостите само на оние карактеристики и код што штотуку беше напишан во оваа функција. Ако програмерот помести копче за 3 пиксели и му кажеме дека има SQL инјекција таму и затоа треба итно да се поправи, ова не е во ред. Погледнете само што е напишано сега и промената што доаѓа на апликацијата.

Да речеме дека имаме одреден функционален дефект - начинот на кој апликацијата не треба да работи: парите не се префрлаат, кога ќе кликнете на копче нема премин на следната страница или производот не се вчитува. Безбедносни дефекти - ова се истите дефекти, но не во однос на работата на апликацијата, туку во безбедноста.

Не сите проблеми со квалитетот на софтверот се безбедносни проблеми. Но, сите безбедносни проблеми се поврзани со квалитетот на софтверот. Шериф Мансур, Експедија.

Бидејќи сите пропусти се исти дефекти, тие треба да се наоѓаат на истото место како и сите развојни дефекти. Затоа, заборавете на извештаите и страшните PDF-датотеки што никој не ги чита.

Кога работев во развојна компанија, добив извештај од алатките за статичка анализа. Го отворив, се згрозив, направив кафе, прелистав 350 страници, го затворив и продолжив со работа. Големите извештаи се мртви извештаи. Обично тие не одат никаде, буквите се бришат, забораваат, губат или бизнисот вели дека ги прифаќа ризиците.

Што да се прави? Ние едноставно ги претвораме потврдените дефекти што ги најдовме во форма погодна за развој, на пример, ги ставаме во заостанат заостаток во Jira. Ние даваме приоритет на дефектите и ги елиминираме по приоритет, заедно со функционалните дефекти и дефектите на тестот.

Статичка анализа - SAST

Ова е анализа на код за пропусти., но не е исто како SonarQube. Ние не проверуваме само за модели или стил. Во анализата се користат голем број пристапи: според дрвото на ранливост, според Проток на податоци, со анализа на конфигурациските датотеки. Ова е сè што се однесува на самиот код.

Добрите страни на пристапот: идентификување на ранливости во кодот во рана фаза на развојкога сè уште нема држачи или готови алатки и способност за инкрементално скенирање: скенирање на дел од кодот што е променет и само функцијата што ја правиме моментално, што го намалува времето на скенирање.

Конс - ова е недостатокот на поддршка за потребните јазици.

Неопходни интеграции, што треба да биде во алатките, според мое субјективно мислење:

• Алатка за интеграција: Jenkins, TeamCity и Gitlab CI.
• Развојна околина: Intellij IDEA, Visual Studio. За развивачот е попогодно да не се движи по неразбирлив интерфејс што сè уште треба да се запамети, туку да ги види сите потребни интеграции и пропусти што ги нашол токму на работното место во сопствената развојна средина.
• Преглед на код: SonarQube и рачен преглед.
• Тракери за дефекти: Џира и Бугзила.

Сликата покажува некои од најдобрите претставници на статичката анализа.

Не се важни алатките, туку процесот, така што има решенија со отворен код кои исто така се добри за тестирање на процесот.

SAST Open Source нема да најде огромен број на пропусти или сложени DataFlows, но тие можат и треба да се користат при градење на процес. Тие помагаат да се разбере како ќе се гради процесот, кој ќе одговори на грешки, кој ќе пријави и кој ќе пријави. Ако сакате да ја извршите почетната фаза на градење на безбедноста на вашиот код, користете решенија со отворен код.

Како може ова да се интегрира ако сте на почетокот на вашето патување и немате ништо: без CI, без Jenkins, без TeamCity? Да ја разгледаме интеграцијата во процесот.

Интеграција на ниво на CVS

Ако имате Bitbucket или GitLab, можете да се интегрирате на ниво Систем за истовремени верзии.

По настан - повлече барање, обврзете. Го скенирате кодот и статусот на изградба покажува дали безбедносната проверка поминала или не успеала.

Повратни информации Се разбира, повратните информации секогаш се потребни. Ако само направивте безбедност на страна, ставете го во кутија и никому ништо не сте кажале за тоа, а потоа на крајот на месецот исфрливте куп бубачки - ова не е точно и не е добро.

Интеграција со системот за преглед на кодови

Еднаш, ние дејствувавме како стандарден прегледувач за технички корисник на AppSec во голем број важни проекти. Во зависност од тоа дали се идентификувани грешки во новиот код или нема грешки, рецензентот го поставува статусот на барањето за повлекување на „прифати“ или „треба работа“ - или сè е во ред, или врските до она што точно треба да се подобри треба да се подобри. За интеграција со верзијата што влегува во производство, овозможивме забрана за спојување доколку не се помине тестот за безбедност на информациите. Го вклучивме ова во рачниот преглед на кодот, а другите учесници во процесот ги видоа безбедносните статуси за овој конкретен процес.

Интеграција со SonarQube

Многумина имаат квалитетна порта во однос на квалитетот на кодот. Овде е исто - можете да ги направите истите порти само за SAST алатките. Ќе има ист интерфејс, иста квалитетна порта, само што ќе се вика безбедносна порта. И, исто така, ако имате процес со користење на SonarQube, можете лесно да интегрирате сè таму.

Интеграција на ниво на CI

Сè овде е исто така прилично едноставно:

• На исто ниво со автотестовите, единица тестови.
• Поделба по фази на развој: dev, тест, прод. Може да бидат вклучени различни групи правила или различни услови за неуспех: запрете го склопувањето, не запирајте го склопувањето.
• Синхроно/асинхроно лансирање. Го чекаме крајот на безбедносните тестови или не. Односно, ние само ги лансиравме и продолжуваме понатаму, а потоа добиваме статус дека се е добро или лошо.

Сето тоа е во совршен розов свет. Не постои такво нешто во реалниот живот, но ние се стремиме. Резултатот од извршувањето на безбедносните проверки треба да биде сличен на резултатите од тестовите на единицата.

На пример, зедовме голем проект и решивме дека сега ќе го скенираме со SAST - ОК. Го туркавме овој проект во SAST, ни даде 20 пропусти и со силна волја решивме дека се е во ред. 000 пропусти се нашиот технички долг. Ќе го ставиме долгот во кутија, полека ќе го расчистиме и ќе додадеме бубачки во тракерите за дефекти. Ајде да ангажираме компанија, да направиме сè сами или да ни помогнат Шампионите за безбедност - и техничкиот долг ќе се намали.

И сите новопојавени пропусти во новиот код мора да се отстранат на ист начин како и грешките во единицата или во автоматските тестови. Релативно кажано, собранието почна, го истрчавме, два теста и два безбедносни теста не успеаја. ОК - отидовме, погледнавме што се случи, поправивме едно, поправивме друго, го истрчавме следниот пат - сè беше во ред, не се појавија нови пропусти, ниту еден тест не успеа. Ако оваа задача е подлабока и треба добро да ја разберете, или ако поправањето на пропустите влијае на големите слоеви на она што се наоѓа под хаубата: додадена е грешка во тракерот за дефекти, таа е приоритетна и корегирана. За жал, светот не е совршен и тестовите понекогаш не успеваат.

Пример за безбедносна порта е аналог на квалитетна порта, во однос на присуството и бројот на пропусти во кодот.

Ние се интегрираме со SonarQube - приклучокот е инсталиран, сè е многу погодно и кул.

Интеграција со развојната средина

Опции за интеграција:

• Извршување на скенирање од развојната околина пред да се изврши.
• Погледнете ги резултатите.
• Анализа на резултатите.
• Синхронизација со серверот.

Вака изгледа примањето резултати од серверот.

Во нашата развојна средина Интерлиј ИДЕА едноставно се појавува дополнителна ставка која ве информира дека таквите пропусти биле откриени при скенирањето. Можете веднаш да го уредите кодот, да ги погледнете препораките и График на проток. Сето ова се наоѓа на работното место на развивачот, што е многу погодно - нема потреба да следите други врски и да гледате нешто дополнително.

Софтвер со отворен код

Ова е мојата омилена тема. Сите користат библиотеки со отворен код - зошто да напишете куп патерици и велосипеди кога можете да земете готова библиотека во која сè е веќе имплементирано?

Се разбира, тоа е точно, но библиотеките исто така ги пишуваат луѓе, тие исто така вклучуваат одредени ризици, а исто така има и ранливости кои периодично или постојано се пријавуваат. Затоа, тука е следниот чекор во безбедноста на апликациите - ова е анализата на компонентите со отворен код.

Анализа со отворен код - OSA

Алатката вклучува три големи фази.

Пребарување на пропусти во библиотеките. На пример, алатката знае дека користиме некоја библиотека и дека во CVE или има некои пропусти во тракерите за грешки кои се однесуваат на оваа верзија на библиотеката. Кога ќе се обидете да ја користите, алатката ќе издаде предупредување дека библиотеката е ранлива и ве советува да користите друга верзија која нема пропусти.

Анализа на чистотата на лиценцата. Ова сè уште не е особено популарно овде, но ако работите во странство, тогаш од време на време може да добиете данок таму за користење на компонента со отворен код што не може да се користи или менува. Според политиката на лиценцираната библиотека, не можеме да го сториме тоа. Или, ако го изменивме и го користиме, треба да го објавиме нашиот код. Се разбира, никој не сака да го објави кодот на своите производи, но можете да се заштитите и од ова.

Анализа на компоненти кои се користат во индустриска средина. Ајде да замислиме хипотетичка ситуација дека конечно го завршивме развојот и го објавивме најновото издание на нашиот микросервис. Тој живее таму прекрасно - една недела, еден месец, една година. Ние не го собираме, не спроведуваме безбедносни проверки, се чини дека сè е во ред. Но, одеднаш, две недели по објавувањето, се појавува критична ранливост во компонентата со отворен код, која ја користиме во оваа конкретна верзија, во индустриското опкружување. Ако не снимиме што и каде користиме, тогаш едноставно нема да ја видиме оваа ранливост. Некои алатки имаат можност да ги следат пропустите во библиотеките кои моментално се користат во индустријата. Тоа е многу корисно.

Можности:

• Различни политики за различни фази на развој.
• Следење на компоненти во индустриска средина.
• Контрола на библиотеките во рамките на организацијата.
• Поддршка за различни системи за градење и јазици.
• Анализа на сликите на Докер.

Неколку примери на индустриски лидери кои се занимаваат со анализа со отворен код.

Единственото бесплатно е ова Зависност-Проверка од OWASP. Можете да го вклучите во првите фази, да видите како функционира и што поддржува. Во основа, сите овие се облак производи или on-premise, но зад нивната база тие сè уште се испраќаат на Интернет. Тие не ги испраќаат вашите библиотеки, туку хашовите или нивните сопствени вредности, кои тие ги пресметуваат, и отпечатоци од прсти до нивниот сервер за да добиваат информации за присуството на пропусти.

Интеграција на процесот

Периметарска контрола на библиотеки, кои се преземаат од надворешни извори. Имаме надворешни и внатрешни складишта. На пример, Event Central работи Nexus и сакаме да се осигураме дека нема пропусти во нашето складиште со статус „критичен“ или „висок“. Можете да конфигурирате прокси користејќи ја алатката Nexus Firewall Lifecycle така што таквите пропусти се отсечени и не завршуваат во внатрешното складиште.

Интеграција во CI. На исто ниво со автотестови, единечни тестови и поделба на фази на развој: dev, тест, прод. Во секоја фаза, можете да преземете која било библиотека, да користите било што, но ако има нешто тешко со статусот „критичен“, можеби вреди да се привлече вниманието на програмерите на ова во фазата на пуштање во производство.

Интеграција со артефакти: Nexus и JFrog.

Интеграција во развојната средина. Алатките што ќе ги изберете треба да имаат интеграција со развојните средини. Програмерот мора да има пристап до резултатите од скенирањето од неговото работно место или можност самиот да го скенира и проверува кодот за пропусти пред да се посвети на CVS.

ЦД интеграција. Ова е одлична карактеристика што навистина ми се допаѓа и за која веќе зборував - следење на појавата на нови пропусти во индустриско опкружување. Работи вака нешто.

Ние имаме Јавни складишта на компоненти — некои алатки надвор и нашето внатрешно складиште. Сакаме да содржи само доверливи компоненти. Кога проксираме барање, проверуваме дали преземената библиотека нема пропусти. Ако потпаѓа под одредени правила што ги поставуваме и нужно се координираме со развојот, тогаш не го поставуваме и ни е побарано да користиме друга верзија. Според тоа, ако има нешто навистина критично и лошо во библиотеката, тогаш развивачот нема да ја добие библиотеката во фазата на инсталација - нека користи верзија повисока или пониска.

• При изградбата, проверуваме дека никој не лизнал нешто лошо, дали сите компоненти се безбедни и никој не донел нешто опасно на флеш-уредот.
• Имаме само доверливи компоненти во складиштето.
• При распоредувањето, уште еднаш го проверуваме самиот пакет: војна, тегла, DL или слика на Docker за да се осигураме дека е во согласност со политиката.
• Кога влегуваме во индустријата, следиме што се случува во индустриското опкружување: критичните пропусти се појавуваат или не се појавуваат.

Динамичка анализа - DAST

Алатките за динамичка анализа се фундаментално различни од сè што беше кажано претходно. Ова е еден вид имитација на работата на корисникот со апликацијата. Ако ова е веб-апликација, испраќаме барања, симулирајќи ја работата на клиентот, кликнуваме на копчињата од предната страна, испраќаме вештачки податоци од формуларот: цитати, загради, знаци во различни шифри, за да видиме како апликацијата работи и обработува надворешни податоци.

Истиот систем ви овозможува да ги проверите пропустите на шаблоните во отворен код. Бидејќи DAST не знае кој софтвер со отворен код го користиме, едноставно фрла „злонамерни“ обрасци и ги анализира одговорите на серверот:

- Да, тука има проблем со десериализацијата, но не и овде.

Има големи ризици во ова, бидејќи ако го спроведете овој безбедносен тест на истата клупа со која работат тестерите, може да се случат непријатни работи.

• Големо оптоварување на мрежата на серверот за апликации.
• Нема интеграции.
• Можност за промена на поставките на анализираната апликација.
• Нема поддршка за потребните технологии.
• Тешкотии со поставување.

Имавме ситуација кога конечно го лансиравме AppScan: поминавме долго време обидувајќи се да добиеме пристап до апликацијата, добивме 3 сметки и бевме среќни - конечно ќе провериме сè! Започнавме скенирање и првото нешто што AppScan го направи беше да влезе во административниот панел, да ги пробие сите копчиња, да смени половина од податоците и потоа целосно да го убие серверот со неговиот формулар за пошта-барања. Развој со тестирање рече:

- Момци, ме зафркавате?! Ние ви дадовме сметки, а вие поставивте штанд!

Размислете за можните ризици. Идеално, подгответе посебен штанд за тестирање на безбедноста на информациите, кој барем некако ќе биде изолиран од останатата околина и условно проверете го административниот панел, по можност во рачен режим. Ова е пенст - оние преостанати проценти на напор што сега не ги разгледуваме.

Вреди да се земе предвид дека можете да го користите ова како аналог на тестирање на оптоварување. Во првата фаза, можете да вклучите динамичен скенер со 10-15 нишки и да видите што се случува, но обично, како што покажува практиката, ништо добро.

Неколку ресурси кои обично ги користиме.

Вреди да се истакне Бурп апартман е „швајцарски нож“ за секој безбедносен професионалец. Сите го користат и е многу погодно. Сега е објавена нова демо верзија на претпријатието издание. Ако порано тоа беше само самостојна алатка со приклучоци, сега програмерите конечно прават голем сервер од кој ќе може да се управува со неколку агенти. Ова е кул, ви препорачувам да го пробате.

Интеграција на процесот

Интеграцијата се случува доста добро и едноставно: започнете со скенирање по успешна инсталација апликации за штандот и скенирање по успешно тестирање за интеграција.

Ако интеграциите не работат или има никулци и лажни функции, тоа е бесмислено и бескорисно - без разлика каква шема ќе испратиме, серверот сепак ќе реагира на ист начин.

• Идеално, посебен штанд за тестирање.
• Пред тестирање, запишете ја секвенцата за најавување.
• Тестирањето на системот за администрација е само рачно.

процес

Малку генерализирано за процесот воопшто и за работата на секоја алатка посебно. Сите апликации се различни - една работи подобро со динамична анализа, друга со статичка анализа, трета со анализа со отворен извор, пентести или нешто сосема друго, на пример, настани со Waf.

Секој процес бара контрола.

За да разберете како функционира еден процес и каде може да се подобри, треба да соберете метрика од сè што ќе ви дојде при рака, вклучително и метрика на производство, метрика од алатки и од трагачи на дефекти.

Секоја информација е корисна. Неопходно е да се погледне од различни агли каде подобро се користи оваа или онаа алатка, каде што процесот конкретно попушта. Можеби вреди да се погледне времето на одговор на развојот за да се види каде да се подобри процесот врз основа на времето. Колку повеќе податоци, толку повеќе делови може да се изградат од највисоко ниво до детали за секој процес.

Бидејќи сите статични и динамички анализатори имаат свои API-и, свои методи за лансирање, принципи, некои имаат распоредувачи, други немаат - пишуваме алатка Оркестратор на AppSec, што ви овозможува да креирате единствена влезна точка во целиот процес од производот и да управувате со неа од една точка.

Менаџерите, програмерите и безбедносните инженери имаат една влезна точка од која можат да видат што работи, да конфигурираат и да извршат скенирање, да примаат резултати од скенирање и да поднесуваат барања. Се обидуваме да се оддалечиме од документацијата, да преведеме сè во човечко, што го користи развојот - страници на Спојување со статус и метрика, дефекти во Jira или во разни тракери за дефекти, или интеграција во синхрон/асинхрон процес во CI /ЦД.

Клучни Килими

Алатките не се главната работа. Прво размислете низ процесот - потоа имплементирајте ги алатките. Алатките се добри, но скапи, па можете да започнете со процесот и да изградите комуникација и разбирање помеѓу развојот и безбедноста. Од безбедносна гледна точка, нема потреба да се „стопира“ сè. Од развојна гледна точка, ако има нешто високо мега суперкритично, тогаш тоа треба да се елиминира, а не да се замижува пред проблемот.

Квалитет на производот - заедничка цел и безбедноста и развојот. Правиме една работа, се трудиме да се погрижиме се да работи правилно и да нема ризици за репутацијата или финансиски загуби. Ова е причината зошто ние промовираме пристап DevSecOps, SecDevOps за подобрување на комуникацијата и подобрување на квалитетот на производот.

Започнете со она што веќе го имате: барања, архитектура, делумни проверки, обуки, упатства. Нема потреба веднаш да се применуваат сите практики на сите проекти - се движи итеративно. Не постои единствен стандард - експеримент и пробајте различни пристапи и решенија.

Постои еднаков знак помеѓу дефектите на безбедноста на информациите и функционалните дефекти.

Автоматизирајте сèшто се движи. Што и да не се движи, преместете го и автоматизирајте го. Ако нешто се прави рачно, тоа не е добар дел од процесот. Можеби вреди да се прегледа и да се автоматизира.

Ако големината на тимот на ИС е мала - користете безбедносни шампиони.

Можеби она за што зборував нема да ви одговара и ќе смислите нешто свое - и тоа е добро. Но изберете алатки врз основа на барањата за вашиот процес. Не гледајте што вели заедницата, дека оваа алатка е лоша, а оваа е добра. Можеби спротивното ќе биде точно за вашиот производ.

Барања за алатки.

• Ниско ниво Лажно позитивно.
• Соодветно време за анализа.
• Лесно користење.
• Достапност на интеграции.
• Разбирање на патоказот за развој на производи.
• Можност за прилагодување на алатките.

Извештајот на Јури беше избран за еден од најдобрите на DevOpsConf 2018. За да се запознаете со уште поинтересни идеи и практични случаи, дојдете во Сколково на 27 и 28 мај DevOpsConf во рамките фестивал RIT++. Уште подобро, ако сте подготвени да го споделите вашето искуство, тогаш се применуваат за извештајот до 21 април.

Извор: www.habr.com