Имаме 2 анализатора на код, 4 инструмента за динамично тестване, собствени разработки и 250 скрипта. Не че всичко това е необходимо в настоящия процес, но като започнахме внедряването на DevSecOps, трябва да се стигне до край.
. Създатели на персонажите: Джъстин Ройланд и Ден Хармън.
Какво е SecDevOps? А DevSecOps? В какво се различават? Какво е Application Security? Защо класическият подход вече не работи? Отговори на всички тези въпроси познава Юрий Шабалин от Swordfish Security. Юрий ще отговори подробно на всичко и ще разгледа проблемите при преминаването от класическия модел на Application Security към процеса DevSecOps: как правилно да се подходи към интегрирането на процеса на безопасна разработка в процеса DevOps, без да се счупи нещо, как да се преминат основните етапи на тестване за безопасност, какви инструменти могат да се прилагат, с какво се различават и как да бъдат правилно настроени, за да се избегнат подводни камъни.
За лекторa: Юрий Шабалин — Главен архитект по сигурността в компанията Swordfish Security. Отговаря за внедряването на SSDL, за общата интеграция на инструментите за анализ на приложения в единна екосистема за разработка и тестване. 7 години опит в информационната безопасност. Работил е в Альфа-Банк, Сбербанк и в Positive Technologies, която разработва софтуер и предоставя услуги. Лектор на международни конференции ZerONights, PHDays, RISSPA, OWASP.
Application Security: какво е това?
Application Security — това е раздел на сигурността, който отговаря за безопасността на приложенията. Той не се отнася до инфраструктурата или мрежовата сигурност, а именно до това, което пишем и над което работят разработчиците — това са недостатъци и уязвимости на самото приложение.
Направление — Security development lifecycle — разработена от компания Microsoft. На схемата — каноничният модел SDLC, основната задача на който е участие на сигурността на всеки етап от разработката, от изискванията, до релиза и пускането в продукция. В Microsoft осъзнаха, че в производството има твърде много бъгове, които стават все повече, и с това трябва нещо да се направи, и предложиха този подход, който стана каноничен.
Application Security и SSDL не са насочени към откритие на уязвимости, както обикновено се смята, а към предотвратяване на тяхното появяване. С времето каноничният подход на Microsoft бе усъвършенстван, развит и в него се появи по-дълбоко детайлно потапяне.
Каноничният SDLC е силно детайлизиран в различни методологии - OpenSAMM, BSIMM, OWASP. Методологиите се различават, но в общи линии са сходни.
Модел за зрялост на вграждане на сигурността
Най-много ми харесва BSIMM — . Основата на методологията е разделянето на процеса на сигурност на приложения на 4 домена: управление, интелигентност, SSDL точки на докосване и внедряване. Във всеки домен има 12 практики, представени под формата на 112 активности.
Всяка от 112 активността има 3 нива на зрялост: начално, средно и напреднало. Всички 12 практики могат да се изучават по раздели, да се отбират важните за вас неща, да се разучава как да ги внедрявате и постепенно да добавяте елементи, например, статичен и динамичен анализ на кода или преглед на кода. Създавате план и по него спокойно работите в рамките на внедряването на избраните активности.
Защо DevSecOps
DevOps е общ процес, в който е важно да се грижите за сигурността.
Първоначално предполага проверки за сигурност. На практика, броят на екипите по сигурност беше значително по-малък от сега, и те не участваха активно в процеса, а действаха като контролен и надзорен орган, който поставя изисквания и проверява качеството на продукта в края на релиза. Това е класически подход, при който екипите по сигурност са далеч от разработката и не вземат участие в процеса.
Основният проблем е, че ИТ сигурността е отделена от разработката. Обикновено това представлява определен контур на ИТ сигурността с 2-3 големи и скъпи инструмента. На всеки шест месеца пристига код или приложение, което трябва да бъде проверено, а веднъж годишно се изпълняват . Всичко това води до закъснение на графика за излизане на продукцията, а на разработчиците се изсипва огромно количество уязвимости от автоматизирани средства. Всичко това е невъзможно за разбиране и поправяне, защото резултатите от предишните шест месеца не са били разгледани, а ето че идва нова партида.
В процеса на работа на нашата компания виждаме, че сигурността във всички сфери и индустрии осъзнава, че е време да се подобри и да се движи в синхрон с разработката - в . Парадигмата DevSecOps идеално се вписва в методологията на гъвкава разработка, за внедряване, поддръжка и участие във всеки релиз и итерация.
Преминаване към DevSecOps
Най-важната дума в жизнения цикъл на разработка на сигурността е "процес"Трябва да разберете това, преди да помислите за закупуване на инструменти.
Просто включването на инструменти в DevOps процеса не е достатъчно – важно е взаимодействието и разбирането между участниците в процеса.
По-важни са хората, а не инструментите.
Често планирането на процеса на сигурна разработка започва с избора и закупуването на инструмент, а завършва с опити да се интегрира инструментът в текущия процес, които така и остават опити. Това води до тъжни последици, защото всеки инструмент има свои характеристики и ограничения.
Разпространен случай е, когато отделът по сигурността избере добър, скъп инструмент с широки възможности и дойде при разработчиците – да го вградят в процеса. Но не става – процесът е построен така, че ограниченията на вече закупения инструмент не съвпадат с текущата парадигма.
Първо опишете какъв резултат искате и как ще изглежда процесът. Това ще помогне да разберете ролите на инструмента и сигурността в процеса.
Започнете с това, което вече се използва.
Преди да закупите скъпи инструменти, погледнете към това, което вече имате. Във всяка компания има изисквания за сигурност, които се прилагат за разработката, има проверки, пентести – защо да не преобразувате всичко това в разбираем и удобен за всички вид?
Обикновено изискванията са един документ, който лежи на рафта. Имаше случай, когато отидохме в компания, за да видим процесите и помолихме да покажат изискванията за сигурност към софтуера. Специалистът, който се занимае с това, дълго търсеше:
– Сега, някъде в бележките ми беше пътят, където стои този документ.
В крайна сметка получихме документа след седмица.
За изискванията, проверките и другото, създайте страница, например, на Confluence – това е удобно за всички.
По-лесно е да преформатирате това, което вече имате и да го използвате за старт.
Използвайте Security Champions.
Обикновено, в средна компания с 100-200 разработчици, работи един специалист по сигурност, който изпълнява няколко функции и физически не успява да провери всичко. Дори да се старае изключително много – сам не може да провери целия код, генериран от разработката. За такива случаи е разработена концепция – .
Security Champions е човекът в екипа по разработка, който е заинтересован в сигурността на вашия продукт.
Security Champion е входна точка в екипа за разработка и евангелист на сигурността в едно лице.
Обикновено, когато в екипа за разработка дойде специалист по сигурността и посочи грешка в кода, получава учуден отговор:
— А вие кой сте? Виждам ви за първи път. При мен всичко е наред — старши колега в code review ми постави „apply“, продължаваме напред!
Това е типична ситуация, защото на старшите или просто колегите от екипа, с които разработчикът постоянно взаимодейства по работа и в code review, се има много повече доверие. Ако вместо специалист по сигурността, грешката и последствията посочи Security Champion, неговото слово ще има много по-голяма тежест.
Също така разработчиците познават своя код по-добре от всеки специалист по сигурността. За човек, който има минимум 5 проекта в инструмента за статичен анализ, обикновено е трудно да запомни всички нюанси. Security Champions познават продукта си: какво взаимодейства с какво и на какво да се обърне внимание в първия момент — те са по-ефективни.
Така че помислете за внедряване на Security Champions и разширяване на влиянието на екипа за сигурност. За самияChampion това също е полезно: професионално развитие в нова област, разширяване на техническия хоризонт, подобряване на техническите, управленческите и лидерските умения, повишаване на пазарната стойност. Това е известен елемент на социална инженерия, вашите „очи“ в екипа по разработка.
Етапи на тестване
казва, че 20% усилия дават 80% резултат. Тези 20% са практиките за анализ на приложения, които могат и трябва да бъдат автоматизирани. Примери за такива активности са статичният анализ — SAST, динамичният анализ — DAST, и контрол на Open Source. Ще разкажа по-подробно за активността, а също така и за инструментите, с какви особености обикновено се сблъскваме при тяхното внедряване в процеса и как да го направим правилно.
Основни проблеми на инструментите
Ще подчертая актуалните за всички инструменти проблеми, които изискват внимание. Ще ги разгледам по-подробно, за да не се повтарям по-нататък.
Дълго време за анализ. Ако от комит до излизането на продукция минават 30 минути за всички тестове и сборка, проверките за информационна сигурност ще отнемат дни. Никой няма да забавя процеса. Вземете предвид тази особеност и направете изводи.
Висок процент на False Negative или False Positive. Всички продукти са различни, всички използват различни фреймворкове и свой стил на написване на код. На различни кодови бази и технологии инструментите могат да показват различно ниво на False Negative и False Positive. Затова обърнете внимание на това, което е в вашата компания и за вашите приложения, което ще показва добри и достоверни резултати.
Няма интеграции с съществуващите инструменти. Обмислете инструментите от гледна точка на интеграциите, които вече използвате. Например, ако имате Jenkins или TeamCity - проверете интеграцията на инструментите точно с този софтуер, а не с GitLab CI, който не използвате.
Липса или прекомерна сложност на кастомизацията. Ако инструментът няма API, защо е необходим? Всичко, което може да се направи в интерфейса, трябва да бъде достъпно чрез API. В идеалния случай, инструментът трябва да предлага възможности за персонализация на проверките.
Няма Roadmap за развитие на продукта. Развитието не стои на място, винаги използваме нови фреймворкове и функции, пренаписваме стария код на нови езици. Искаме да сме сигурни, че инструментът, който купим, ще поддържа нови фреймворкове и технологии. Затова е важно да знаем, че продуктът има реален и правилен за развитие.
Особености на процеса
Освен особеностите на инструментите, вземете предвид и особеностите на процеса на разработка. Например, преченето на разработката е типична грешка. Нека разгледаме какви други особености трябва да се вземат предвид и на какво да обърне внимание екипът по сигурността.
За да не забавяте сроковете за разработка и излизане, създайте различни правила и различни show stoppers — критерии за спиране на процеса на сборка при наличие на уязвимости — за различни среди. Например, разбираме, че текущата клонка отива на девелоперска платформа или UAT, така че не спираме и не казваме:
— Имате уязвимости, няма да преминете напред!
На този етап е важно да кажем на разработчиците, че има проблеми със сигурността, на които трябва да се обърне внимание.
Наличието на уязвимости не е пречка за по-нататъшно тестване: ръчно, интеграционно или мануално. От друга страна, трябва да повишим сигурността на продукта, и разработчиците не трябва да игнорират това, което открива сигурността. Затова понякога постъпваме така: на стенда, когато се пуска в девелоперската среда, просто уведомяваме разработката:
— Хей, имате проблеми, моля, обърнете внимание на тях.
На етапа UAT отново показваме предупреждения за уязвимости, а на етапа на излизане в промоция казваме:
— Хей, предупреждавахме ви няколко пъти, не направихте нищо — с това няма да ви пуснем.
Ако говорим за кода и динамиката, необходимо е да показваме и предупреждаваме за уязвимости само на тези функции и код, които са написани току-що в тази функция. Ако разработчикът е преместил бутона с 3 пиксела и му казваме, че има SQL инжекция и затова трябва спешно да поправи — това е неправилно. Вижте само това, което е написано сега, и изменението, което влиза в приложението.
Да кажем, че имаме някакъв функционален дефект — това е как приложението не трябва да работи: парите не се прехвърлят, при кликване на бутона няма прехвърляне на следващата страница или не се зарежда продукт. Дефекти в сигурността — това са същите дефекти, но не в контекста на работата на приложението, а на сигурността.
Не всички проблеми с качеството на софтуера са проблеми със сигурността. Но всички проблеми със сигурността са свързани с качеството на софтуера. Sherif Mansour, Expedia.
Тъй като всички уязвимости са такива същите дефекти, те трябва да се намират там, където са и всички дефекти на разработката. Затова забравете за отчетите и страховитите PDF файлове, които никой не чете.
Когато работех в компания, занимаваща се с разработка, получих отчет от инструменти за статичен анализ. Отворих го, ужасих се, приготвих кафе, прегледах 350 страници, затворих и продължих да работя. Големите отчети са мъртви отчети. Обикновено те никъде не отиват, имейлите се изтриват, забравят се, губят се или бизнесът казва, че поема рискове.
Какво да правим? Откритите дефекти, които са потвърдени, просто преобразуваме в удобен за разработка формат, например, съхраняваме в backlog в Jira. Дефектите приоритизираме и отстраняваме в реда на приоритетите наред с функционалните дефекти и дефектите от тестовете.
Статичен анализ - SAST
Това е анализ на кода за наличие на уязвимости., но това не е същото като SonarQube. Ние проверяваме не само по патерни или стил. При анализа се прилага редица подходи: по дърво на уязвимостите, по , по анализ на конфигурационни файлове. Това е всичко, свързано пряко с кода.
Предимства на подхода: откриване на уязвимости в кода на ранен етап от разработката, когато все още няма стендове и готов инструмент, и възможност за инкрементално сканиране: сканиране на участък от кода, който е променен, и само на онези функции, които в момента разработваме, което намалява времето за сканиране.
Недостатъци — това е липсата на поддръжка на необходимите езици.
Необходими интеграции, които трябва да бъдат в инструментите, по мое субективно мнение:
- Инструменти за интеграция: Jenkins, TeamCity и Gitlab CI.
- Среда за разработка: Intellij IDEA, Visual Studio. На разработчика му е по-удобно да не навлиза в неразбираем интерфейс, който трябва да запомня, а направо на работното си място в собствената си среда за разработка да вижда всички необходимите интеграции и уязвимости, които е открил.
- Code review: SonarQube и ръчно ревю.
- Дефект трекери: Jira и Bugzilla.
На картинката са представени някои от най-добрите представители на статичния анализ.
Важни са не инструментите, а процесът, затова съществуват Open Source решения, които също са добри за отработване на процеса.
SAST Open Source не откриват огромно количество уязвимости или сложни DataFlow, но при изграждането на процеса, те могат и трябва да се използват. Те помагат да се разбере как ще бъде изграден процесът, кой ще отговаря за бъговете, кой ще докладва и кой - ще отчита. Ако искате да проведете начален етап на изграждане на сигурността на вашия код - използвайте Open Source решения.
Как може да се интегрира това, ако вие сте в началото на пътя, нямате нищо: нито CI, нито Jenkins, нито TeamCity? Нека разгледаме интеграциите в процеса.
Интеграция на ниво CVS
Ако имате Bitbucket или GitLab, може да направите интеграция на ниво .
При събитие — pull request, commit. Сканировате кода и в статуса на build’а показвате, че проверката за безопасност е преминала или не.
Обратна връзка. Безусловно, обратната връзка е винаги необходима. Ако просто сте извършили проверка на страната на безопасността, сложили сте всичко в кутия и не сте разказали на никого за това, а в края на месеца изведнъж излизат много бъгове — това не е правилно и не е добре.
Интеграция със система за преглед на кода
Веднъж поставихме техническия потребител AppSec за дефолтен прегледчик в редица важни проекти. В зависимост от това, дали са открити грешки в новия код или не, на pull request прегледчикът поставя статус на «accept» или «need work» — или всичко е ОК, или трябва да се доработи и указания за това, което именно трябва да се доработи. За интеграцията с версията, която отива в продукция, имаме включен забранителен merge, ако тестът по ИБ не е преминал. Включвахме това в ръчното преглеждане на кода, и останалите участници в процеса виждаха статусите по безопасността именно за този конкретен процес.
Интеграция с SonarQube
Много хора имат по качеството на кода. Тук е същото — можем да направим същите gates само за инструментите SAST. Ще бъде същият интерфейс, същият quality gate, само ще се нарича security gate. И също така, ако имате наложен процес с използване на SonarQube, можете спокойно всичко да интегрирате там.
Интеграция на ниво CI
Тук също всичко е доста просто:
- На едно ниво с автотестовете, юнит-тестовете.
- Разделение по етапи на разработката: dev, test, prod. Могат да се включват различни набори от правила, или различни условия за провал: спираме сборката, не спираме сборката.
- Синхронен/асинхронен старт. Чакаме ли приключването на проверките за безопасност или не чакаме. Тоест просто ги пускаме и продължаваме напред, а после получаваме статус, че всичко е наред или не.
Всичко това е в идеалния розов свят. В реалния живот такова нещо няма, но ние се стремим. Резултатът от изпълнението на проверките за безопасност трябва да бъде аналогичен на резултатите от юнит-тестовете.
Например, взехме голям проект и решихме, че сега ще го сканираме с SAST – ОК. Поставихме проекта в SAST, той ни извади 20 000 уязвимости и с волево решение решихме, че всичко е наред. 20 000 уязвимости – това е нашият технически дълг. Ще сложим дълга в кутия, ще го разгребваме постепенно и ще запишем бъгове в системата за проследяване на дефекти. Ще наемем компания, ще направим всичко сами или ще получим помощ от Security Champions – и техническият дълг ще намалява.
А всички нововъзникнали уязвимости в новия код трябва да бъдат отстранени по същия начин, както грешките в юнит или в автоматизираните тестове. Условно казано, стартира сборката, пускамe тестовете, провалят се два теста и два теста за сигурност. ОК – отидохме, видяхме какво се е случило, коригирахме едното, коригирахме другото, следващия път пуснахме тестовете – всичко е наред, нови уязвимости не са се появили, тестовете са успешни. Ако задачата е по-дълбока и е необходимо да я разберем добре, или коригирането на уязвимостите засяга големи пластове от системата: записваме бъг в системата за проследяване на дефекти, той се приоритизира и се коригира. За съжаление, светът не е идеален и тестовете понякога падат.
Пример за security gate – аналог на quality gate, що се отнася до наличие и количество уязвимости в кода.
Интегрираме с SonarQube – плъгинът се инсталира, всичко е много удобно и готино.
Интеграция със средата за разработка
Възможности за интеграция:
- Стартиране на сканиране от средата за разработка преди commit.
- Преглед на резултатите.
- Анализ на резултатите.
- Синхронизиране със сървъра.
Приблизително така изглежда получаването на резултатите от сървъра.
В нашата среда за разработка просто се появява допълнителен пункт, който съобщава, че по време на сканирането са открити такива уязвимости. Може веднага да се поправя код, да се разглеждат препоръките и . Всичко това е разположено на работното място на разработчика, което е много удобно – не е необходимо да се разхождаме из други връзки и да търсим нещо допълнително.
Отворен код
Това е моята любима тема. Всички използват Open Source библиотеки – защо да пишем купища заглавия и велосипеди, когато можем да вземем готова библиотека, в която всичко е вече реализирано?
Разбира се, така е, но библиотеките също се пишат от хора, включват определени рискове и също така имат уязвимости, за които периодично или постоянно се съобщава. Затова следващата стъпка в Application Security е анализът на Open Source компонент。
Анализ на Open Source – OSA
Инструментът включва три основни етапа.
Търсене на уязвимости в библиотеките. Например, инструментът знае, че използваме определена библиотека, и че в или в бъг-трекерите има уязвимости, които се отнасят до тази версия на библиотеката. При опит за нейното използване, инструментът ще издаде предупреждение, че библиотеката е уязвима, и ще предложи да се използва друга версия, където уязвимости няма.
Анализ на лицензионната чистота. При нас това все още не е особено популярно, но ако работите в чужбина, понякога можете да получите неприятности за използване на компонент с отворен код, който не може да се използва или модифицира. Според политиката на лицензионната библиотека, ние не можем да го направим. Или, ако сме я модифицирали и използваме, трябва да публикуваме кода си. Разбира се, никой не иска да публикува кода на своите продукти, но има начин да се защити и от това.
Анализ на компонентите, използвани в индустриалната среда. Представете си хипотетична ситуация, в която най-накрая завършваме разработката и пускаме в промишлеността последния релиз на нашия микросервис. Той там живее чудесно – седмица, месец, година. Ние не го поддържаме, проверки по сигурността не провеждаме, изглежда всичко е наред. Но изведнъж две седмици след пускането излиза критична уязвимост в Open Source компонента, който използваме точно в тази сборка, в промишлената среда. Ако не записваме какво и къде използваме, просто няма да видим тази уязвимост. В някои инструменти има възможност за мониторинг на уязвимости в библиотеките, които в момента се използват в прома. Това е много полезно.
Възможности:
- Различни политики за различни етапи на разработката.
- Мониторинг на компонентите в индустриалната среда.
- Контрол на библиотеките в контурите на организацията.
- Поддръжка на различни системи за изграждане и езици.
- Анализ на Docker образи.
Няколко примера на лидери в областта, които се занимават с анализ на Open Source.
Единственият безплатен от тях е от OWASP. Можете включить его на начальных этапах, просмотреть, как он работает и что поддерживает. В основном это все облачные продукты или on-premise, но с базой отправляются в интернет. Они отправляют не ваши библиотеки, а хэши или свои значения, которые рассчитывают, и отпечатки на свой сервер, чтобы получить уведомление о наличии уязвимостей.
Интеграция в процесс
Контроль библиотек в периметре, которые загружаются из внешних источников. У нас есть внешний и внутренний репозитории. Например, внутри Event Central используется Nexus, и мы хотим, чтобы в нашем репозитории не было уязвимостей со статусом «критичный» или «высокий». Можно настроить проксирование с помощью инструмента Nexus Firewall Lifecycle так, чтобы такие уязвимости отсекались и не попадали во внутренний репозиторий.
Интеграция в CI. На одном уровне с автотестами, юнит-тестами и разделением по этапам разработки: dev, test, prod. На каждом этапе можно загружать любые библиотеки, использовать что угодно, но если там есть что-то серьезное со статусом «critical», возможно, стоит привлечь внимание разработчиков на этапе выхода в пром.
Интеграция с артефакториями: Nexus и JFrog.
Интеграция в среду разработки. Инструменты, которые вы выбираете, должны иметь интеграцию со средами разработки. Разработчик должен иметь доступ к результатам сканирования со своего рабочего места, либо возможность самостоятельно просканировать и проверить код на наличие уязвимостей до коммита в CVS.
Интеграция в CD. Это классная функция, которая мне очень нравится и о которой я уже рассказывал — мониторинг появления новых уязвимостей в промышленной среде. Это работает примерно так.
У нас есть Public Component Repositories — някои инструменти отвън и нашето вътрешно хранилище. Искаме в него да има само одобрени компоненти. При проксирането на заявки проверяваме, че изтегляната библиотека няма уязвимости. Ако попада под определени политики, които установяваме и обсъждаме с разработката, то тя не се изтегля и идва отказ за използване на друга версия. Следователно, ако в библиотеката има нещо наистина критично и лошо, разработчикът дори на етапа на инсталиране няма да получи библиотеката — нека използва версия нагоре или надолу.
- При компилацията проверяваме, че никой не е подхвърлил нищо лошо, че всички компоненти са безопасни и никой не е внесъл нищо опасно на флашка.
- В репозитория имаме само одобрени компоненти.
- При деплой проверяваме още веднъж самия пакет: war, jar, DL или Docker-образ, за да се уверим, че съответства на политиката.
- При излизане в промишлено производство следим какво става в промишлената среда: появяват ли се или не се появяват критични уязвимости.
Динамичен анализ — DAST
Инструментите за динамичен анализ коренно се различават от всичко, което беше казано дотук. Това е имитация на работата на потребителя с приложението. Ако това е уеб-приложение, изпращаме заявки, имитирайки работата на клиента, натискаме бутони на интерфейса, изпращаме изкуствени данни от формата: кавички, скоби, символи в различни кодировки, за да видим как приложението работи и обработва външни данни.
Тази система позволява да се проверят шаблонните уязвимости в Open Source. Тъй като DAST не знае какво Open Source използваме, той просто задава „вредни“ патерни и анализира отговорите на сървъра:
— Ага, тук има проблем с десериализацията, а тук няма.
В това има големи рискове, защото ако провеждате този тест за сигурност на същия стенд, с който работят тестерите — могат да се случат неприятни неща.
- Висока натовареност на мрежовия сървър на приложението.
- Няма интеграции.
- Възможност за промяна на настройките на анализа на приложението.
- Няма поддръжка на необходимите технологии.
- Сложност на настройката.
Имахме ситуация, в която най-накрая стартирахме AppScan: дълго време пробивахме достъп до приложението, получихме 3 акаунта и се зарадвахме - най-накрая всичко ще проверим! Стартирахме сканирането и първото, което направи AppScan - влезе в администраторския панел, натискаше всички бутони, смени половината данни, а след това изобщо уби сървъра със своите -запитвания. Разработката с тестването казаха:
— Хора, шегувате ли се?! Дадохме ви акаунти, а вие поставихте стенд!
Вземете предвид възможните рискове. В идеалния случай подгответе отделен стенд за тестване на информационна безопасност, който да бъде изолиран поне малко от останалата среда, и условно проверявайте админката желателно в ръчен режим. Това е пентест - онези останали проценти усилия, които в момента не разглеждаме.
Струва си да се вземе предвид, че може да се използва това като аналог на натоварвано тестване. На първия етап може да включите динамичен скенер в 10-15 потока и да видите какво ще стане, но обикновено, както показва практиката, нещо добро не излиза.
Няколко ресурса, които обикновено използваме.
Струва си да се подчертае — това е „швейцарският нож“ за всеки специалист по безопасността. Използва се от всички и е много удобен. Сега излезе нова демо-версия на enterprise edition. Ако преди това беше просто stand alone утилита с плъгини, сега най-накрая разработчиците правят голям сървър, от който ще можете да управлявате няколко агента. Това е готино, препоръчвам да опитате.
Интеграция в процесс
Интеграцията преминава доста добре и лесно: стартиране на сканирането след успешна инсталация на приложението на стенда и сканиране след успешното провеждане на интеграционни тестове.
Ако интеграциите не работят или там стоят заглушки и mock-функции, това е безсмислено и безполезно - какъвто и да е патерн, който изпращаме, сървърът ще отговаря по един и същи начин.
- Идеално - отделен стенд за тестване.
- Преди започване на тестването запишете последователността на логина.
- Тестването на системата за администриране - само ръчно.
Процес
Няколко обобщено за процеса изобщо и за работата на всеки инструмент в частност. Всички приложения са различни - едно работи по-добре с динамичен анализ, друго - със статичен, трето - с анализ на OpenSource, пентестове или изобщо нещо друго, например, събития с .
Всеки процес се нуждае от контрол.
За да разберем как работи процесът и къде може да се подобри, трябва да събираме метрики от всичко, до което можем да достигнем, включително производствени метрики, метрики от инструменти и от трекери за дефекти.
Всякакви данни са полезни. Трябва да разглеждаме различни аспекти, където инструментът се прилага най-добре, къде процесът конкретно се проваля. Може би, си струва да погледнем времето за реакция на разработката, за да разберем къде да подобрим процеса, базирано на времето. Колкото повече данни, толкова повече аспекти можем да изградим, от висшия обобщен до детайлите на всеки процес.
Тъй като всички статични и динамични анализатори имат свои API, свои начини за стартиране, принципи, при някои има графици, при други няма – ние пишем инструмент AppSec Оркестратор, който позволява да създадем единна точка за вход в целия процес на изделието и да го управляваме от една точка.
За мениджърите, разработчиците и инженерите по сигурност има единна точка за вход, от която може да се види какво е стартирано, да се настрои и да се стартира сканиране, да се получат резултати от сканирането и да се предявят изисквания. Ние се стремим да избягваме документацията, да преведем всичко в разбираем език, който използва разработката – страници на Confluence със статуси и метрики, дефекти в Jira или в различни трекери за дефекти, или интеграция в синхронния/асинхронния процес в CI/CD.
Ключови изводи
Инструментите не са на първо място. Първо проектирайте процеса – след това внедрявайте инструментите. Инструментите са полезни, но скъпи, затова можем да започнем с процеса и да настроим взаимодействието и разбирането между разработката и сигурността. От гледна точка на сигурността – не бива да „покриваме“ всичко, От гледна точка на разработката – ако има нещо много критично, то трябва да бъде отстранявано, а не да се затварят очите за проблема.
Качеството на продукта е обща цел както за сигурността, така и за разработката. Ние работим заедно, стремим се всичко да работи правилно и да няма репутационни рискове и финансови загуби. Именно затова пропагандираме подхода към DevSecOps, SecDevOps, за да установим комуникация и да направим продукта по-качествен.
Започнете с това, което вече имате: изисквания, архитектура, частични проверки, тренировки, указания. Не е нужно веднага да прилагате всички практики на всички проекти - движете се итеративно. Няма единен стандарт - експериментирайте и пробвайте различни подходи и решения.
Между дефектите на ИБ и функционалните дефекти има равенство.
Автоматизирайте всичко, което се движи. Всичко, което не се движи - движете и автоматизирайте. Ако нещо се прави ръчно, това не е добра част от процеса. Може би си струва да го преразгледате и да го автоматизирате.
Ако размерът на екипа по ИБ е малък - използвайте Security Champions.
Може би това, за което говорих, не ви подхожда и ще измислите нещо свое - и това е добре. Но избирайте инструменти, на базата на изискванията именно на вашия процес. Не гледайте на това, което казва общността, че този инструмент е лош, а този е добър. Може би именно на вашия продукт всичко ще се окаже обратно.
Изисквания за инструментите.
- Ниско ниво на False Positive.
- Релевантно време за анализ.
- Удобство на използване.
- Наличие на интеграции.
- Разбиране на Roadmap за развитие на продукта.
- Възможност за кастомизация на инструментите.
Докладът на Юрий беше избран за един от най-добрите на DevOpsConf 2018. За да се запознаете с още повече интересни идеи и практически случаи идвайте на 27 и 28 май в Сколково на в рамките на . А още по-добре, ако сте готови да споделите своя опит, тогава за доклад до 21 април.
Източник: habr.com
