Страх и омраза DevSecOps

Имахме 2 кодови анализатора, 4 инструмента за динамично тестване, наши собствени занаяти и 250 скрипта. Не че всичко това беше необходимо в текущия процес, но след като започнете да прилагате DevSecOps, трябва да стигнете до края.

източник. Герои, създадени от Джъстин Ройланд и Дан Хармън.

Какво е SecDevOps? Какво ще кажете за DevSecOps? Какви са разликите? Сигурност на приложението - за какво става въпрос? Защо класическият подход вече не работи? Всички тези въпроси знаят отговора Юрий Шабалин на Swordfish Security. Юрий ще отговори подробно на всичко и ще анализира проблемите на прехода от класическия модел за сигурност на приложенията към процеса DevSecOps: как правилно да подходим към интегрирането на защитения процес на разработка в процеса DevOps и да не нарушаваме нищо, как да преминем през основните етапи на тестване на сигурността, какви инструменти могат да се използват, как се различават и как правилно да ги конфигурирате, за да избегнете клопки.

Относно говорителя: Юрий Шабалин - Главен архитект по сигурността в компанията Swordfish Security. Отговаря за внедряването на SSDL, за цялостната интеграция на инструментите за анализ на приложения в единна екосистема за разработка и тестване. 7 години опит в информационната сигурност. Работил е в Alfa-Bank, Sberbank и Positive Technologies, които разработват софтуер и предоставят услуги. Лектор на международни конференции ZerONights, PHDays, RISSPA, OWASP.

Сигурност на приложението: за какво става дума?

Защита на приложенията е секцията за сигурност, която отговаря за сигурността на приложението. Тук не става дума за инфраструктура или мрежова сигурност, а за това, което пишем и върху какво работят разработчиците – това са недостатъците и уязвимостите на самото приложение.

Посока SDL или SDLC - Жизнен цикъл на развитие на сигурността - Разработено от Microsoft. Диаграмата показва каноничния SDLC модел, чиято основна задача е участието на сигурността на всеки етап от разработката, от изискванията до пускането и пускането до производството. Microsoft разбраха, че има твърде много грешки в бала, има повече от тях и трябва да се направи нещо по въпроса, и те предложиха този подход, който стана каноничен.

Защитата на приложенията и SSDL не са насочени към откриване на уязвимости, както обикновено се смята, а към предотвратяване на появата им. С течение на времето каноничният подход от Microsoft е подобрен, разработен, има по-дълбоко детайлно потапяне.

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

Изграждане на сигурност в модела на зрялост

Най ми харесва BSIMM - Изграждане на сигурност в модела на зрялост. Основата на методологията е разделянето на процеса на сигурност на приложенията на 4 домейна: управление, разузнаване, SSDL Touchpoints и внедряване. Всеки домейн има 12 практики, които са представени като 112 дейности.

Всяка от 112-те дейности има 3 нива на зрялост: начинаещи, средно напреднали и напреднали. Можете да изучавате всичките 12 практики в секции, да избирате неща, които са важни за вас, да измислите как да ги приложите и постепенно да добавяте елементи, например статичен и динамичен анализ на код или преглед на код. Начертавате план и работите по него спокойно като част от изпълнението на избраните дейности.

Защо DevSecOps

DevOps е цялостен голям процес, в който трябва да се погрижим за сигурността.

Първоначално DevOps включени проверки за сигурност. На практика броят на екипите по сигурността беше много по-малък от сега и те действаха не като участници в процеса, а като контролен и надзорен орган, който предявява изисквания към него и проверява качеството на продукта в края на пускането. Това е класически подход, при който екипите за сигурност са били зад стена от разработката и не са участвали в процеса.

Основният проблем е, че информационната сигурност е отделна от развитието. Обикновено това е някаква IB схема и съдържа 2-3 големи и скъпи инструмента. Веднъж на всеки шест месеца изходният код или приложението пристигат за тестване и веднъж годишно Пентести. Всичко това води до факта, че датите на пускане за индустрията се отлагат и огромен брой уязвимости от автоматизирани инструменти падат върху разработчика. Невъзможно е да се разглоби и ремонтира всичко това, защото дори през предходните шест месеца резултатите не бяха демонтирани, а ето нова партида.

В процеса на работа на нашата компания виждаме, че сигурността във всички области и индустрии разбира, че е време да наваксаме и да се завъртим с развитието в едно колело – в Пъргав. Парадигмата на DevSecOps се вписва перфектно в методологията за гъвкаво развитие, внедряване, поддръжка и участие във всяка версия и итерация.

Преход към DevSecOps

Най-важната дума в жизнения цикъл на развитие на сигурността е "процес". Трябва да разберете това, преди да помислите за закупуване на инструменти.

Просто включването на инструменти в процеса на DevOps не е достатъчно – важна е комуникацията и разбирането между участниците в процеса.

Хората са по-важни от инструментите

Често планирането на защитен процес на разработка започва с избора и закупуването на инструмент и завършва с опити за интегриране на инструмента в текущия процес, които си остават опити. Това води до тъжни последици, тъй като всички инструменти имат свои собствени характеристики и ограничения.

Често срещан случай е, когато отделът за сигурност е избрал добър, скъп инструмент с широк набор от функции и е дошъл при разработчиците, за да го вгради в процеса. Но не се получава - процесът е проектиран по такъв начин, че ограниченията на вече закупен инструмент да не се вписват в текущата парадигма.

Първо опишете какъв резултат искате и как ще изглежда процесът. Това ще помогне да се разберат ролите на инструмента и сигурността в процеса.

Започнете с това, което вече се използва

Преди да купите скъпи инструменти, вижте какво вече имате. Всяка компания има изисквания за сигурност, които важат за разработката, има проверки, пентестове - защо не трансформирате всичко това в разбираема и удобна форма за всички?

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

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

В резултат на това получихме документа седмица по-късно.

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

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

Използвайте Security Champions

Обикновено в средна компания за 100-200 разработчици има един служител по сигурността, който изпълнява няколко функции и физически няма време да провери всичко. Дори и да направи всичко възможно, той сам няма да провери целия код, който генерира разработката. За такива случаи е разработена концепция - Шампиони по сигурността.

Security Champions е човек в екипа за разработка, който се интересува от сигурността на вашия продукт.

Security Champion е входна точка към екипа за разработка и евангелист на сигурността, събрани в едно.

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

- А ти кой си? Виждам те за първи път. Всичко е наред с мен - моят старши приятел постави „приложи“ при прегледа на кода, продължаваме!

Това е типична ситуация, защото има много повече доверие в старшите или просто съотборниците, с които разработчикът постоянно взаимодейства по време на работа и при преглед на код. Ако вместо охранител Шампионът по сигурността посочи грешката и последствията, тогава думата му ще има по-голяма тежест.

Освен това разработчиците познават кода си по-добре от всеки човек по сигурността. За човек, който има поне 5 проекта в инструмент за статичен анализ, обикновено е трудно да запомни всички нюанси. Шампионите по сигурността знаят своя продукт: какво взаимодейства с какво и какво да гледаме на първо място - те са по-ефективни.

Така че помислете за внедряване на Security Champions и разширяване на влиянието на екипа по сигурността. За самия шампион това също е полезно: професионално развитие в нова област, разширяване на техническите хоризонти, изпомпване на технически, управленски и лидерски умения, повишаване на пазарната стойност. Това е някакъв елемент от социалното инженерство, вашите „очи“ в екипа за разработка.

Етапи на тестване

Парадигма 20 на 80 казва, че 20% от усилията дават 80% от резултатите. Тези 20% са практики за анализ на приложения, които могат и трябва да бъдат автоматизирани. Примери за такива дейности са статичен анализ − САСТ, динамичен анализ — DAST и контрол с отворен код. Ще ви разкажа повече за дейностите, както и за инструментите, какви функции обикновено срещаме, когато се въвеждат в процеса, и как да го направите правилно.

Основни проблеми с инструмента

Ще подчертая проблемите, които са от значение за всички инструменти, които изискват внимание. Ще ги анализирам по-подробно, за да не се повтарям повече.

Дълго време за анализ. Ако са необходими 30 минути за всички тестове и асемблиране от ангажимент до пускане за производство, тогава проверките за сигурност на информацията ще отнемат един ден. Така че никой няма да забави процеса. Обмислете тази функция и направете изводи.

Високо фалшиво отрицателно или фалшиво положително. Всички продукти са различни, всички използват различни рамки и собствен стил на кодиране. На различни кодови бази и технологии инструментите могат да показват различни нива на фалшиво отрицателно и фалшиво положително. Така че вижте какво има вашият фирми и за Вашият приложенията ще покажат добър и надежден резултат.

Няма интеграции със съществуващи инструменти. Разгледайте инструментите от гледна точка на интеграции с това, което вече използвате. Например, ако имате Jenkins или TeamCity, проверете интеграцията на инструменти с този софтуер, а не с GitLab CI, който не използвате.

Липса или прекомерна сложност на персонализирането. Ако инструментът няма API, тогава защо е необходим? Всичко, което може да се направи в интерфейса, трябва да бъде достъпно чрез API. В идеалния случай инструментът трябва да има възможност за персонализиране на проверките.

Няма пътна карта за развитие на продукта. Развитието не стои неподвижно, ние винаги използваме нови рамки и функции, пренаписваме стар код на нови езици. Искаме да сме сигурни, че инструментът, който купуваме, ще поддържа нови рамки и технологии. Затова е важно да знаете, че продуктът е истински и коректен Пътна карта развитие.

Характеристики на процеса

В допълнение към характеристиките на инструментите, вземете предвид характеристиките на процеса на разработка. Например, намесата в развитието е типична грешка. Нека да видим какви други характеристики трябва да се имат предвид и на какво трябва да обърне внимание екипът по сигурността.

За да не нарушите сроковете за разработка и пускане, създайте различни правила и различни покажи тапи - критерии за спиране на процеса на изграждане при наличие на уязвимости - за различни среди. Например разбираме, че текущият клон отива към щанд за разработка или UAT, така че не спираме и казваме:

- Имате уязвимости тук, няма да отидете никъде по-нататък!

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

Наличието на уязвимости не е пречка за по-нататъшно тестване: ръчно, интегриране или ръчно. От друга страна, трябва по някакъв начин да подобрим сигурността на продукта и така че разработчиците да не оценяват това, което защитата намира. Затова понякога правим следното: на щанда, когато се появи в средата за разработка, ние просто уведомяваме разработката:

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

На етапа на UAT отново показваме предупреждения за уязвимости, а на етапа на изход в бала казваме:

„Момчета, предупредихме ви няколко пъти, не сте направили нищо – няма да ви пуснем с това.

Ако говорим за код и динамика, тогава е необходимо да се показват и предупреждават за уязвимости само на онези функции и код, които току-що бяха написани в тази функция. Ако разработчикът премести бутона с 3 пиксела и ние му кажем, че има SQL инжекция там и следователно трябва да бъде коригирана спешно, това е грешно. Вижте само това, което е написано сега, и промяната, която идва в приложението.

Да кажем, че имаме някакъв функционален дефект - начина, по който приложението не трябва да работи: парите не се прехвърлят, когато щракнете върху бутона, няма преход към следващата страница или продуктът не се зарежда. Дефекти в сигурността - това са същите дефекти, но не в контекста на приложението, а на сигурността.

Не всички проблеми с качеството на софтуера са проблеми със сигурността. Но всички проблеми със сигурността са свързани с качеството на софтуера. Шериф Мансур, Expedia.

Тъй като всички уязвимости са едни и същи дефекти, те трябва да бъдат разположени на същото място като всички дефекти в разработката. Така че забравете за докладите и страшните PDF файлове, които никой не чете.

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

Какво да правя? Ние просто конвертираме потвърдените дефекти, които открихме, във форма, удобна за разработка, например, добавяме ги към изоставането в Jira. Дефектите се приоритизират и елиминират по ред на приоритет заедно с функционалните дефекти и тестовите дефекти.

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

Това е анализ на кода за уязвимости., но не е същото като SonarQube. Ние проверяваме не само за модели или стил. Анализът използва няколко подхода: по дърво на уязвимостите, по поток от данни, чрез анализиране на конфигурационните файлове. Това е всичко за самия код.

Плюсове на подхода: идентифициране на уязвимости в кода на ранен етап от разработкатакогато няма стойки и готови инструменти, и възможност за постепенно сканиране: сканира част от кода, който е променен, и само функцията, която правим в момента, което намалява времето за сканиране.

Против е липсата на поддръжка за необходимите езици.

Необходими интеграции, което трябва да бъде в инструментите, според моето субективно мнение:

• Инструмент за интегриране: Jenkins, TeamCity и Gitlab CI.
• Среда за разработка: Intellij IDEA, Visual Studio. За разработчика е по-удобно да не се качва в неразбираем интерфейс, който все още трябва да се запомни, а да види всички необходими интеграции и уязвимости, които е намерил точно на работното място в собствената си среда за разработка.
• Преглед на кода: SonarQube и ръчен преглед.
• Проследяващи дефекти: Jira и Bugzilla.

Картината показва някои от най-добрите представители на статичния анализ.

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

SAST Open Source няма да намери огромен брой уязвимости или сложен DataFlow, но те могат и трябва да се използват при изграждането на процес. Те помагат да се разбере как ще бъде изграден процесът, кой ще реагира на грешки, кой ще докладва, кой ще докладва. Ако искате да извършите началния етап от изграждането на сигурността на вашия код, използвайте решения с отворен код.

Как може това да бъде интегрирано, ако сте в началото на пътуването, нямате нищо: нито CI, нито Jenkins, нито TeamCity? Помислете за интегриране на процеса.

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

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

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

Обратна връзка. Разбира се, винаги е необходима обратна връзка. Ако просто сте го направили от страна на сигурността, поставили сте го в кутия и не сте казали на никого нищо за него, а след това сте изхвърлили куп грешки в края на месеца, това не е правилно и не е добре.

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

Веднъж зададохме техническия потребител на AppSec като рецензент по подразбиране в редица важни проекти. В зависимост от това дали са открити грешки в новия код или няма грешки, рецензентът поставя статуса на заявката за изтегляне на „приема“ или „има нужда от работа“ - или всичко е наред, или трябва да финализирате и препраща към какво точно за финализиране. За интеграция с версията, която се пуска, сме деактивирали сливането, ако тестът за IS не е преминат. Включихме това в ръчния преглед на кода и останалите участници в процеса видяха статусите на сигурност за този конкретен процес.

Интеграция със SonarQube

Мнозина имат качествена порта по отношение на качеството на кода. Тук е същото - можете да направите същите гейтове само за SAST инструменти. Ще има същия интерфейс, същата порта за качество, само че ще се нарича охранителна врата. Освен това, ако имате процес, настроен с помощта на SonarQube, можете лесно да интегрирате всичко там.

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

Тук също всичко е съвсем просто:

• Наравно с автотестовете, единични тестове.
• Разделяне по етапи на развитие: dev, test, prod. Могат да бъдат включени различни набори от правила или различни условия за отказ: спираме сглобяването, не спираме сглобяването.
• Синхронно/асинхронно изпълнение. Чакаме края на тестовете за сигурност или не чакаме. Тоест просто ги стартирахме и продължаваме напред, след което получаваме статус, че всичко е добро или лошо.

Всичко е в един перфектен розов свят. В реалния живот това не е така, но ние се стремим. Резултатът от извършването на проверки за сигурност трябва да бъде подобен на резултатите от тестовете на модула.

Например, взехме голям проект и решихме, че сега ще го сканираме със SAST - ОК. Вкарахме този проект в SAST, той ни даде 20 000 уязвимости и решихме, че всичко е наред. 20 000 уязвимости са нашият технически дълг. Ще поставим дълга в кутия, бавно ще го съберем и ще стартираме грешки в инструментите за проследяване на дефекти. Наемете компания, направете всичко сами или накарайте Security Champions да ни помогне и техническият дълг ще намалее.

И всички новопоявили се уязвимости в новия код трябва да бъдат елиминирани по същия начин, както грешките в модула или в автотестовете. Относително казано, монтажът започна, измъкна се, паднаха два теста и два теста за сигурност. Добре - отидохме, погледнахме какво се е случило, коригирахме едното, коригирахме второто, карахме следващия път - всичко е наред, не са се появили нови уязвимости, тестовете не са се провалили. Ако тази задача е по-дълбока и трябва да я разберете добре, или коригирането на уязвимости засяга големи слоеве от това, което се крие под капака: грешка се въвежда в инструмента за проследяване на дефекти, тя се приоритизира и коригира. За съжаление светът не е идеален и тестовете понякога се провалят.

Пример за защитна врата е аналог на качествена врата по отношение на наличието и броя на уязвимостите в кода.

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

Интеграция на среда за разработка

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

• Стартиране на сканиране от средата за разработка дори преди ангажимента.
• Вижте резултатите.
• Анализ на резултатите.
• Синхронизация със сървъра.

Ето как изглежда получаването на резултати от сървъра.

В нашата среда за разработка Интелект ИДЕЯ просто се появява допълнителен елемент, който казва, че такива уязвимости са открити по време на сканирането. Можете веднага да редактирате кода, да видите препоръки и графика на потока. Всичко това се намира на работното място на програмиста, което е много удобно - не е необходимо да следвате останалите връзки и да гледате нещо допълнително.

Open Source

Това е любимата ми тема. Всеки използва библиотеки с отворен код - защо да пишете куп патерици и велосипеди, когато можете да вземете готова библиотека, в която всичко вече е внедрено?

Разбира се, това е вярно, но библиотеките също се пишат от хора, също включват определени рискове и има и уязвимости, които периодично или постоянно се докладват. Следователно има следваща стъпка в сигурността на приложенията – това е анализът на компонентите с отворен код.

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

Инструментът включва три основни стъпки.

Намиране на уязвимости в библиотеките. Например, инструментът знае, че използваме някакъв вид библиотека и това в CVE или в инструментите за проследяване на грешки има някои уязвимости, свързани с тази версия на библиотеката. Ако се опитате да го използвате, инструментът ще ви предупреди, че библиотеката е уязвима, и ще ви посъветва да използвате друга версия, където няма уязвимости.

Анализ на чистотата на лиценза. Това все още не е много популярно при нас, но ако работите с чужда държава, тогава там периодично можете да получите атака за използване на компонент с отворен код, който не може да се използва или модифицира. Според политиката на лицензираната библиотека не можем да направим това. Или, ако сме го модифицирали и го използваме, трябва да публикуваме нашия код. Разбира се, никой не иска да публикува кода на своите продукти, но вие също можете да се предпазите от това.

Анализ на компоненти, които се използват в индустриална среда. Представете си хипотетична ситуация, че най-накрая сме завършили разработката и сме пуснали най-новата версия на нашата микроуслуга за индустрията. Там си живее прекрасно - седмица, месец, година. Ние не го събираме, не извършваме проверки за сигурност, всичко изглежда наред. Но внезапно, две седмици след пускането, се появява критична уязвимост в компонента с отворен код, който използваме в тази конкретна сборка, в индустриалната среда. Ако не записваме какво и къде използваме, тогава тази уязвимост просто няма да бъде видяна. Някои инструменти имат способността да наблюдават уязвимости в библиотеки, които в момента се използват в prom. Много е полезно.

Характеристики:

• Различни политики за различните етапи на развитие.
• Наблюдавайте компоненти в индустриална среда.
• Контрол на библиотеките в контура на организацията.
• Поддръжка за различни системи за изграждане и езици.
• Анализ на Docker изображения.

Няколко примера за лидери в областта, които се занимават с анализ на Open Source.

Единственият безплатен е Проверка на зависимостта от OWASP. Можете да го включите на първите етапи, да видите как работи и какво поддържа. По принцип това са всички облачни продукти или локални, но зад тяхната база те все още отиват в Интернет. Те не изпращат вашите библиотеки, а хешове или техните стойности, които изчисляват, и пръстови отпечатъци на своя сървър, за да получат информация за наличието на уязвимости.

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

Контрол на библиотеката на периметъракоито са изтеглени от външни източници. Имаме външни и вътрешни хранилища. Например, имаме Nexus в Event Central и искаме да сме сигурни, че няма уязвимости с „критично“ или „високо“ състояние в нашето хранилище. Можете да настроите прокси чрез инструмента за жизнения цикъл на защитната стена на Nexus, така че подобни уязвимости да бъдат премахнати и да не бъдат включени във вътрешното хранилище.

CI интеграция. На същото ниво с автотестове, модулни тестове и разделяне на етапи на разработка: dev, test, prod. На всеки етап можете да изтегляте всякакви библиотеки, да използвате всичко, но ако има нещо трудно с „критичния“ статус, вероятно трябва да привлечете вниманието на разработчиците към това на етапа на влизане в бала.

Интеграция на артефакти: Nexus и JFrog.

Интеграция в средата за разработка. Избраните от вас инструменти трябва да имат интеграция със среди за разработка. Разработчикът трябва да има достъп до резултатите от сканирането от работното си място или възможността да сканира и проверява кода за уязвимости, преди да го включи в CVS.

CD интеграция. Това е страхотна функция, която наистина харесвам и за която вече говорих - наблюдение на появата на нови уязвимости в индустриална среда. Работи така.

Ние имаме Публични хранилища на компоненти - някои външни инструменти и нашето вътрешно хранилище. Искаме само надеждни компоненти да бъдат в него. Когато проксираме заявка, ние проверяваме дали изтеглената библиотека няма уязвимости. Ако попада под определени правила, които задаваме и задължително координираме с разработката, тогава не го качваме и получаваме отказ да използваме различна версия. Съответно, ако има нещо наистина критично и лошо в библиотеката, тогава разработчикът няма да получи библиотеката дори на етапа на инсталиране - нека използва версия по-висока или по-ниска.

• При изграждането проверяваме дали някой не е подхлъзнал нещо лошо, дали всички компоненти са безопасни и никой не е донесъл нещо опасно на флашката.
• Имаме само доверени компоненти в хранилището.
• При внедряването отново проверяваме самия пакет: war, jar, DL или Docker изображение за факта, че отговаря на правилата.
• Когато навлизаме в индустриалната среда, ние наблюдаваме какво се случва в индустриалната среда: критични уязвимости се появяват или не се появяват.

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

Инструментите за динамичен анализ са фундаментално различни от всичко, което беше казано преди. Това е един вид имитация на работата на потребителя с приложението. Ако това е уеб приложение, изпращаме заявки, имитиращи работата на клиента, щракаме върху бутоните отпред, изпращаме изкуствени данни от формата: кавички, скоби, знаци в различни кодировки, за да видим как работи приложението и обработва външни данни.

Същата система ви позволява да проверявате за уязвимости на шаблони в Open Source. Тъй като DAST не знае кой отворен код използваме, той просто хвърля „злонамерени“ модели и анализира отговорите на сървъра:

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

В това има големи рискове, защото ако провеждате този тест за сигурност на същия стенд, с който работят тестерите, могат да се случат неприятни неща.

• Голямо натоварване на мрежата на сървъра на приложения.
• Без интеграции.
• Възможност за промяна на настройките на анализираното приложение.
• Няма поддръжка за необходимите технологии.
• Трудност при настройка.

Имахме ситуация, когато най-накрая стартирахме AppScan: избихме достъпа до приложението за дълго време, получихме 3 акаунта и бяхме възхитени - най-накрая ще проверим всичко! Стартирахме сканиране и първото нещо, което AppScan направи, беше да влезе в административния панел, да пробие всички бутони, да промени половината от данните и след това да убие напълно сървъра със собствените си форма за поща- искания. Разработка с тестване каза:

„Момчета, шегувате ли се?! Дадохме ти сметки, а ти сложи щанда!

Обмислете възможните рискове. В идеалния случай подгответе отделен щанд за тестване на информационната сигурност, който поне по някакъв начин ще бъде изолиран от останалата среда и условно проверете администраторския панел, за предпочитане в ръчен режим. Това е пентест - онези оставащи проценти от усилията, които не разглеждаме сега.

Струва си да се има предвид, че можете да използвате това като аналог на тестване на натоварване. На първия етап можете да включите динамичния скенер в 10-15 нишки и да видите какво ще се случи, но обикновено, както показва практиката, нищо добро.

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

Струва си да се подчертае Супер суит е "швейцарското ножче" за всеки професионалист по сигурността. Всички го ползват и е много удобно. Вече е пусната нова демо версия на корпоративното издание. Ако по-рано това беше просто самостоятелна помощна програма с плъгини, сега разработчиците най-накрая правят голям сървър, от който ще е възможно да управлявате няколко агента. Готино е, препоръчвам ви да го опитате.

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

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

Ако интеграциите не работят или има мъничета и фиктивни функции, това е безсмислено и безполезно - без значение какъв модел изпращаме, сървърът пак ще отговори по същия начин.

• В идеалния случай, отделен тестов стенд.
• Преди тестване запишете последователността за влизане.
• Тестването на административната система е само ръчно.

процес

Малко обобщено за процеса като цяло и за работата на всеки инструмент в частност. Всички приложения са различни - едното работи по-добре с динамичен анализ, друго със статичен анализ, третото с OpenSource анализ, пентестове или нещо друго като цяло, например събития с Waf.

Всеки процес трябва да се контролира.

За да разберете как работи процесът и къде може да бъде подобрен, трябва да съберете показатели от всичко, до което можете да се докопате, включително производствени показатели, показатели от инструменти и устройства за проследяване на дефекти.

Всяка информация е полезна. Необходимо е да разгледате в различни раздели къде е по-добре да се използва този или онзи инструмент, къде процесът конкретно пропада. Може да си струва да разгледате времето за реакция на разработката, за да видите къде да подобрите процеса въз основа на времето. Колкото повече данни, толкова повече съкращения могат да бъдат изградени от най-високото ниво до детайлите на всеки процес.

Тъй като всички статични и динамични анализатори имат свои собствени API, собствени методи за стартиране, принципи, някои имат планировчици, други не - ние пишем инструмент Оркестратор на AppSec, което ви позволява да направите единна входна точка към целия процес от продукта и да го управлявате от една точка.

Мениджърите, разработчиците и инженерите по сигурността имат една входна точка, от която могат да видят какво се изпълнява, да конфигурират и изпълняват сканирания, да получават резултати от сканиране и да изпращат изисквания. Опитваме се да се отдалечим от парчета хартия, да преведем всичко в човешко, което разработването използва - страници на Confluence със статус и показатели, дефекти в Jira или в различни тракери на дефекти или вграждане в синхронен / асинхронен процес в CI / CD.

Ключови храни за вкъщи

Инструментите нямат значение. Първо помислете за процеса, а след това внедрете инструментите. Инструментите са добри, но скъпи, така че можете да започнете с процеса и да настроите фино взаимодействието и разбирането между разработката и сигурността. От гледна точка на сигурността няма нужда да „спирате" всичко подред. От гледна точка на развитието, ако има нещо високо мега супер критично, то това трябва да се елиминира, а не да се затвори за проблема .

Качество на продукта - обща цел сигурност и развитие. Ние правим едно нещо, опитваме се да гарантираме, че всичко работи правилно и няма рискове за репутацията и финансови загуби. Ето защо ние насърчаваме подхода към DevSecOps, SecDevOps, за да установим комуникация и да направим продукта по-добър.

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

Знак за равенство между IS дефекти и функционални дефекти.

Автоматизирайте всичкоче се движи. Всичко, което не се движи, преместете и автоматизирайте. Ако нещо се прави на ръка, това не е добра част от процеса. Може би си струва да го преразгледате и автоматизирате.

Ако размерът на IB екипа е малък - използвайте Security Champions.

Може би това, за което говорих, няма да ви подхожда и ще измислите нещо свое - и това е добре. Но изберете инструменти въз основа на изискванията на вашия процес. Не гледайте какво казва общността, че този инструмент е лош, а този е добър. Може би във вашия продукт ще е обратното.

Изисквания към инструмента.

• Нисък фалшив положителен.
• Достатъчно време за анализ.
• Лесна употреба.
• Наличие на интеграции.
• Разбиране на пътната карта за развитие на продукта.
• Възможност за персонализиране на инструменти.

Докладът на Юрий беше избран за един от най-добрите на DevOpsConf 2018. За да се запознаете с още по-интересни идеи и практически казуси, заповядайте в Сколково на 27 и 28 май DevOpsConf в рамките на фестивал RIT++. Още по-добре, ако желаете да споделите опита си Приложи Изпратете отчета си до 21 април.

Източник: www.habr.com