У нас было 2 аналізатара кода, 4 інструменты для дынамічнага тэсціравання, свае вырабы і 250 скрыптоў. Не тое, каб гэта ўсё было патрэбна ў бягучым працэсе, але калі пачаў укараняць DevSecOps, то трэба ідзі да канца.
. Аўтары персанажаў: Джасцін Ройланд і Дэн Хармон.
Што такое SecDevOps? А DevSecOps? У чым адрозненні? Application Security – пра што гэта? Чаму класічны падыход больш не працуе? На ўсе гэтыя пытанні ведае адказ Юрый Шабалін з Swordfish Security. Юры падрабязна на ўсё адкажа і разбярэ праблемы пераходу ад класічнай мадэлі Application Security да працэсу DevSecOps: як правільна падысці да ўбудавання працэсу бяспечнай распрацоўкі ў працэс DevOps і нічога не зламаць пры гэтым, як мінуць асноўныя этапы тэставання на бяспеку, якія прылады можна ўжываць, чым яны адрозніваюцца і як іх правільна наладзіць, каб пазбегнуць падводных камянёў.
Аб спікеры: Юрый Шабалін Chief Security Architect у кампаніі Swordfish Security. Адказвае за ўкараненне SSDL, за агульную інтэграцыю інструментаў аналізу прыкладанняў у адзіную экасістэму распрацоўкі і тэсціравання. 7 гадоў досведу ў інфармацыйнай бяспецы. Працаваў у Альфа-Банк, Ашчадбанк і ў Positive Technologies, якая распрацоўвае софт і дае сэрвісы. Спікер міжнародных канферэнцый ZerONights, PHDays, RISSPA, OWASP.
Application Security: пра што гэта?
Бяспека прыкладанняў - Гэта раздзел бяспекі, які адказвае за бяспеку прыкладанняў. Гэта не адносіцца да інфраструктуры або да сеткавай бяспекі, а менавіта да таго, што мы пішам і над чым працуюць распрацоўшчыкі - гэта недахопы і ўразлівасці самога прыкладання.
напрамак - Security development lifecycle - распрацавала кампанія Microsoft. На схеме – кананічная мадэль SDLC, асноўная задача якой – удзел бяспекі на кожным этапе распрацоўкі, ад патрабаванняў, да рэлізу і выхаду ў прадакшн. У Microsoft зразумелі, што ў проме занадта шмат багаў, іх становіцца больш і з гэтым трэба нешта рабіць, і прапанавалі гэты падыход, які стаў кананічным.
Application Security і SSDL накіраваны не на выяўленне ўразлівасцяў, як прынята лічыць, а на прадухіленне іх з'яўленні. З часам кананічны падыход ад Microsoft быў палепшаны, развіты, у ім з'явілася глыбейшае дэталёвае апусканне.
Кананічны SDLC моцна дэталізаваны ў розных метадалогіях – OpenSAMM, BSIMM, OWASP. Метадалогіі адрозніваюцца, але, у цэлым, падобныя.
Building Security In Maturity Model
Мне больш за ўсё даспадобы BSIMM - . Аснова метадалогіі – падзел працэсу Application Security на 4 дамена: Governance, Intelligence, SSDL Touchpoints і Deployment. У кожным дамене 12 практык, якія прадстаўлены ў выглядзе 112 актыўнасцяў.
У кожнай са 112 актыўнасцяў ёсць 3 ўзроўню сталасці: пачатковы, сярэдні і прасунуты. Усе 12 практык можна вывучаць па раздзелах, адбіраць важныя для вас рэчы, разбірацца, як іх укараняць і паступова дадаваць элементы, напрыклад, статычны і дынамічны аналіз кода ці code review. Распісваеце план і па ім спакойна працуеце ў рамках укаранення абраных актыўнасцяў.
Чаму DevSecOps
DevOps - гэта агульны вялікі працэс, у якім трэба клапаціцца аб бяспецы.
Першапачаткова меркаваў праверкі на бяспеку. На практыцы колькасць каманд бяспекі была нашмат менш, чым цяпер, і яны выступалі не як удзельнікі працэсу, а як кантрольны і наглядны орган, які прад'яўляе да яго патрабаванні і правярае якасць прадукта ў канцы рэлізу. Гэта класічны падыход, у якім каманды бяспекі знаходзіліся за сцяной ад распрацоўкі і не прымалі ўдзел у працэсе.
Асноўная праблема як раз у тым, што ИБ стаяць асобна ад распрацоўкі. Звычайна гэта нейкі контур ИБ і ў ім 2-3 вялікіх і дарагіх інструмента. Раз у паўгода прылятае зыходны код або дадатак, якое трэба праверыць, а раз у год вырабляюцца . Гэта ўсё прыводзіць да таго, што тэрміны выхаду ў прам адкладаюцца, а на распрацоўніка вывальваецца вялікая колькасць уразлівасцяў з аўтаматызаваных сродкаў. Усё гэта немагчыма разабраць і адрамантаваць, таму што яшчэ за папярэднія паўгода не разабралі вынікі, а тут новая партыя.
У працэсе працы нашай кампаніі мы бачым, што бяспека ва ўсіх сферах і індустрыях разумее, што пара падцягвацца і круціцца з распрацоўкай у адным коле – у . Парадыгма DevSecOps выдатна кладзецца на метадалогію гнуткай распрацоўкі, на ўкараненне, падтрымку і ўдзел у кожным рэлізе і ітэрацыі.
Пераход да DevSecOps
Самае важнае слова ў Security Development Lifecycle – гэта «працэс». Вы павінны зразумець, перш чым думаць аб куплі інструментаў.
Проста ўключыць прылады ў працэс DevOps недастаткова - важна ўзаемадзеянне і разуменне паміж удзельнікамі працэсу.
Важнейшыя людзі, а не інструменты
Часта планаванне працэсу бяспечнай распрацоўкі пачынаецца з выбару і пакупкі інструмента, а заканчваецца — спробамі інтэграваць інструмент у бягучы працэс, якія так і застаюцца спробамі. Гэта прыводзіць да сумных наступстваў, таму што ва ўсіх інструментаў свае асаблівасці і абмежаванні.
Распаўсюджаны выпадак, калі аддзел бяспекі абраў добрую, дарагую прыладу, з шырокімі магчымасцямі, і прыйшоў да распрацоўнікаў — убудоўваць у працэс. Але не выходзіць - працэс пабудаваны так, што абмежаванні ўжо набытай прылады не кладуцца ў бягучую парадыгму.
Спачатку апішыце, які вынік вы хочаце і як будзе выглядаць працэс. Гэта дапаможа зразумець ролі прылады і бяспекі падчас.
Пачніце з таго, што ўжо выкарыстоўваецца
Перад пакупкай дарагіх інструментаў паглядзіце на тое, што ў вас ужо ёсць. У кожнай кампаніі ёсць патрабаванні па бяспецы, якія прад'яўляюцца распрацоўцы, ёсць праверкі, пентэсты - чаму б не змяніць усё гэта ў зразумелы і зручны для ўсіх выгляд?
Звычайна патрабаванні - гэта папяровы талмуд, які ляжыць на палічцы. Быў выпадак, калі мы прыходзім у кампанію, каб паглядзець працэсы і просім паказаць патрабаванні па бяспецы да софту. Спецыяліст, які гэтым займаўся, доўга шукаў:
- Зараз, дзесьці ў нататках быў шлях, дзе ляжыць гэты дакумент.
У выніку мы атрымалі дакумент праз тыдзень.
Для патрабаванняў, праверак і іншага, стварыце старонку, напрыклад, на Зліццё - гэта зручна ўсім.
Прасцей перафарматаваць тое, што ўжо ёсць і выкарыстоўваць для старту.
Выкарыстоўвайце Security Champions
Звычайна, у сярэдняй кампаніі на 100-200 распрацоўшчыкаў працуе адзін бяспечнік, які выконвае некалькі функцый, і фізічна не паспявае ўсё правяраць. Нават калі ён імкнецца з усіх сіл - у адзіночку не праверыць увесь код, які генеруе распрацоўка. Для такіх выпадкаў распрацаваны канцэпт .
Security Champions - гэта чалавек усярэдзіне каманд распрацоўкі, які зацікаўлены ў бяспецы вашага прадукта.
Security Champion - кропка ўваходу ў каманду распрацоўкі і евангеліст бяспекі ў адной асобе.
Звычайна, калі ў каманду распрацоўкі прыходзіць бяспечнік і паказвае на памылку ў кодзе, то атрымлівае здзіўлены адказ:
- А вы хто? Я вас бачу першы раз. У мяне ўсё добра мне старэйшы таварыш на code review паставіў apply, мы ідзем далей!
Гэта тыповая сітуацыя, таму што да старэйшых ці проста калег па камандзе, з якімі распрацоўшчык пастаянна ўзаемадзейнічае па працы і ў code review, даверу нашмат больш. Калі замест бяспечніка на памылку і наступствы пакажа Security Champion, тое яго слова будзе мець больш вагі.
Таксама распрацоўшчыкі лепш ведаюць свой код, чым любы бяспечнік. Для чалавека, у якога мінімум 5 праектаў у інструменце статычнага аналізу, звычайна складана памятаць усе нюансы. Security Champions ведаюць свой прадукт: што з чым узаемадзейнічае і на што глядзець у першую чаргу – яны больш эфектыўна.
Так што задумайцеся над тым, каб укараніць Security Champions і пашырыць уплыў каманды бяспекі. Для самога чэмпіёна гэта таксама карысна: прафесійнае развіццё ў новай вобласці, пашырэнне тэхнічнага кругагляду, прапампоўванне тэхнічных, кіраўніцкіх і лідэрскіх навыкаў, павышэнне рынкавага кошту. Гэта некаторы элемент сацыяльнай інжынерыі, вашыя "вочы" ў камандзе распрацоўкі.
Этапы тэсціравання
кажа, што 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'а паказваеце, што праверка на бяспеку мінула ці не мінула.
Зваротная сувязь. Безумоўна, зваротная сувязь патрэбная заўсёды. Калі вы проста выканалі на баку security, у скрыначку склалі і нікому нічога не распавялі пра гэта, а потым у канцы месяца вывалілі кучу багаў - гэта не правільна і не добра.
Інтэграцыя з сістэмай code review
Аднойчы, мы ставілі ў шэрагу важных праектаў дэфолтным рэўюерам тэхнічнага карыстальніка AppSec. У залежнасці ад таго, ці выяўлены памылкі ў новым кодзе ці памылак няма, на pull request рэўюер прастаўляе статут на "accept" ці "need work" – альбо ўсё ОК, альбо трэба дапрацаваць і спасылкі на тое, што менавіта дапрацаваць. На інтэграцыю з версіяй, якая ідзе ў прод, у нас была ўключана забарона merge, калі тэст па ИБ не пройдзены. Мы гэта ўключалі ў ручное code review, і астатнія ўдзельнікі працэсу бачылі статусы па бяспецы менавіта для гэтага канкрэтнага працэсу.
Інтэграцыя з SonarQube
У многіх ёсць па якасці кода. Тут тое ж самае - можна зрабіць тыя ж самыя gates толькі для інструментаў SAST. Будзе той жа інтэрфейс, той жа quality gate, толькі звацца ён будзе security gate. І гэтак жа, калі ў вас пастаўлены працэс з выкарыстаннем SonarQube, можна спакойна ўсё туды інтэграваць.
Інтэграцыя на ўзроўні CI
Тут таксама ўсё дастаткова проста:
- На адным узроўні з аўтатэстамі, юніт-тэстамі.
- Падзел па этапах распрацоўкі: dev, test, prod. Могуць уключацца розныя наборы правіл, альбо розныя fail conditions: ступаем зборку, не ступаем зборку.
- Сінхронны/асінхронны запуск. Мы чакаем заканчэнне праверкі тэстаў на бяспеку ці не чакаем. Гэта значыць, мы іх проста запусцілі і ідзем далей, а потым нам прыходзіць статус, што ўсё добра ці дрэнна.
Гэта ўсё ў ідэальным ружовым свеце. У рэальным жыцці такога няма, але мы імкнемся. Вынік выканання праверак бяспекі павінен быць аналагічны вынікам юніт-тэстаў.
Напрыклад, мы ўзялі вялікі праект і вырашылі, што зараз будзем сканаваць яго SAST'ам - ОК. Мы запіхнулі гэты праект у SAST, ён нам выдаў 20 уразлівасцяў і валявым рашэннем мы прынялі, што ўсё добра. 000 20 уразлівасцяў - гэта наш тэхнічны абавязак. Доўг змесцім у скрыначку, будзем паволі разграбаць і заводзіць багі ў дэфект-трэкеры. Наймем кампанію, зробім усё самі ці нам будуць дапамагаць Security Champions – і тэхнічны доўг будзе памяншацца.
А ўсё ізноў якія з'яўляюцца ўразлівасці ў новым кодзе павінны быць ухіленыя таксама, як памылкі ў юніт ці ў аўтатэстах. Умоўна кажучы, запусцілася зборка, прагналі, зваліліся два тэсты і два тэсты па бяспецы. Добра - схадзілі, паглядзелі, што здарылася, паправілі адно, паправілі другое, наступны раз прагналі - усё добра, новых уразлівасцяў не з'явілася, тэсты не праваленыя. Калі гэтая задача глыбей і трэба добра ў ёй разабрацца, ці выпраўленне ўразлівасцяў закранае вялікія пласты таго, што ляжыць пад капотам: завялі баг у дэфект-трэкер, ён прыярэтызуецца і выпраўляецца. Нажаль, мір не ідэальны і тэсты часам падаюць.
Прыклад security gate - аналаг quality gate, па наяўнасці і колькасці ўразлівасцяў у кодзе.
Інтэгруемся з SonarQube - убудова ставіцца, усё вельмі зручна і класна.
Інтэграцыя з асяроддзем распрацоўкі
Магчымасці інтэграцыі:
- Запуск сканавання з асяроддзя распрацоўкі яшчэ перад commit.
- Прагляд вынікаў.
- Аналіз вынікаў.
- Сінхранізацыя з серверам.
Прыкладна так выглядае атрыманне вынікаў з сэрвера.
У нашым асяроддзі распрацоўкі проста з'яўляецца дадатковы пункт, які паведамляе, што падчас сканавання выяўлены такія ўразлівасці. Можна адразу кіраваць код, глядзець рэкамендацыі і . Гэта ўсё размешчана на працоўным месцы распрацоўніка, што вельмі зручна - не трэба хадзіць па астатніх спасылках і глядзець нешта дадаткова.
Open Source
Гэта мая любімая тэма. Усё выкарыстоўваюць 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 - нейкія інструменты па-за, і наш унутраны рэпазітар. Мы жадаем, каб у ім былі толькі trusted components. Пры праксіраванні запыту правяраем, што ў запампаванай бібліятэкі няма ўразлівасцяў. Калі яна трапляе пад пэўныя палітыкі, якія мы ўстанаўліваем і абавязкова ўзгадняем з распрацоўкай, то яе не запампоўваем і прыходзіць адбіванне на выкарыстанне іншай версіі. Адпаведна, калі ў бібліятэцы ёсць нешта рэальна крытычнае і дрэннае, то распрацоўшчык яшчэ на этапе ўстаноўкі не атрымае бібліятэку — няхай выкарыстоўвае версію вышэй ці ніжэй.
- Пры build'е мы правяраем, што ніхто не падсунуў нічога дрэннага, што ўсе кампаненты бяспечныя і ніхто не прынёс на флэшцы нічога небяспечнага.
- У рэпазітары ў нас толькі trusted components.
- Пры дэплоі мы яшчэ раз правяраем менавіта сам пакет: war, jar, DL ці Docker-вобраз на тое, што ён адпавядае палітыцы.
- Пры выхадзе ў пром мы маніторым тое, што адбываецца ў прамысловым асяроддзі: з'яўляюцца ці не з'яўляюцца крытычныя ўразлівасці.
Дынамічны аналіз - DAST
Інструменты дынамічнага аналізу кардынальна адрозніваюцца ад усяго, што было сказанае да гэтага. Гэта нейкая імітацыя працы карыстальніка з дадаткам. Калі гэта вэб-дадатак, мы адпраўляем запыты, імітуючы працу кліента, націскаем на кнопкі на фронце, пасылаем штучныя дадзеныя з формы: двукоссі, дужкі, сімвалы ў рознай кадоўцы, каб паглядзець на тое, як прыкладанне працуе і апрацоўвае знешнія дадзеныя.
Гэтая ж сістэма дазваляе правяраць шаблонныя ўразлівасці ў Open Source. Так як DAST не ведае, які Open Source мы выкарыстоўваем, ён проста кідае "шкодныя" патэрны і аналізуе адказы сервера:
- Ага, тут ёсць праблема дэсерыялізацыі, а тут няма.
У гэтым ёсць вялікія рызыкі, таму што калі вы праводзіце гэты тэст бяспекі на тым жа стэндзе, з якім працуюць тэсціроўшчыкі - могуць здарыцца непрыемныя рэчы.
- Высокая нагрузка на сеткусервер прыкладання.
- Няма інтэграцый.
- Магчымасць змены налад аналізуемага прыкладання.
- Няма падтрымкі неабходных тэхналогій.
- Складанасць наладкі.
У нас была сітуацыя, калі мы нарэшце запусцілі AppScan: доўга выбівалі доступ да дадатку, атрымалі 3 улікі і ўзрадаваліся — нарэшце ўсё праверым! Запусцілі сканаванне, і першае, што зрабіў AppScan - залез у адмін-панэль, пратыкаў усе кнопкі, памяняў палову дадзеных, а потым наогул забіў сервер сваімі -запытамі. Распрацоўка з тэсціраваннем сказалі:
- Хлопцы, вы здзекуецеся?! Мы вам далі ўлікі, а вы стэнд паклалі!
Улічвайце магчымыя рызыкі. У ідэале рыхтуйце асобны стэнд для тэставання ИБ, які будзе ізаляваны ад астатняга асяроддзя хоць бы неяк, і ўмоўна правяраць адмінку пажадана ў ручным рэжыме. Гэта пэнтэст – тыя астатнія працэнты намаганняў, якія мы зараз не разглядаем.
Варта ўлічыць, што можна выкарыстоўваць гэта як аналаг нагрузачнага тэсціравання. На першым этапе можна ўключыць дынамічны сканер у 10-15 патокаў і паглядзець, што атрымаецца, але звычайна, як паказвае практыка, нічога добрага.
Некалькі рэсурсаў, якія звычайна выкарыстоўваем.
Варта вылучыць - гэта «швейцарскі нож» для любога спецыяліста па бяспецы. Яго выкарыстоўваюць усе, і ён вельмі зручны. Цяпер выйшла новая дэма-версія enterprise edition. Калі раней гэта была проста stand alone утыліта з убудовамі, то зараз нарэшце-то распрацоўшчыкі робяць вялікі сервер, з якога можна будзе кіраваць некалькімі агентамі. Гэта крута, раю паспрабаваць.
Інтэграцыя ў працэс
Інтэграцыя адбываецца дастаткова добра і проста: запуск сканавання пасля паспяховай усталёўкі прыкладанні на стэнд і сканіраванне пасля паспяховага правядзення інтэграцыйнага тэсціравання.
Калі інтэграцыі не працуюць ці там стаяць заглушкі і mock-функцыі, гэта бессэнсоўна і бескарысна - які б мы патэрн не адпраўлялі, сервер будзе ўсё роўна адказваць аднолькава.
- Ідэальна - асобны стэнд для тэставання.
- Да пачатку тэставання запішыце паслядоўнасць лагіна.
- Тэставанне сістэмы адміністравання - толькі ручное.
працэс
Крыху абагульнена пра працэс наогул і пра працу кожнай прылады, у прыватнасці. Усе прыкладанні розныя - у аднаго лепш працуе дынамічны аналіз, у іншага статычны, у трэцяга аналіз OpenSource, пентэсты ці наогул нешта іншае, напрыклад, падзеі з .
Кожны працэс мае патрэбу ў кантролі.
Каб зразумець як працуе працэс і дзе яго можна палепшыць, трэба збіраць метрыкі са ўсяго, да чаго дацягнуцца рукі, у тым ліку вытворчыя метрыкі, метрыкі з прылад і з дэфект-трэкераў.
Любыя дадзеныя карысныя. Трэба глядзець у розных разрэзах на тое, дзе лепш прымяняецца той ці іншы інструмент, дзе працэс канкрэтна асядае. Можа быць, варта паглядзець на час водгуку распрацоўкі, каб зразумець дзе палепшыць працэс на аснове часу. Чым больш дадзеных, тым больш разрэзаў можна пабудаваць ад верхнеўзроўневых да дэталяў кожнага працэсу.
Бо ва ўсіх статычных і дынамічных аналізатараў свае API, свае спосабы запуску, прынцыпы, у адных ёсць шэдулеры, у іншых няма - мы пішам прыладу AppSec Аркестратар, які дазваляе зрабіць адзіную кропку ўваходу ва ўвесь працэс з выраба і кіраваць ім з адной кропкі.
У менеджэраў, распрацоўшчыкаў і security-інжынераў адна кропка ўваходу, з якой можна паглядзець, што запушчана, наладзіць і запусціць сканаванне, атрымаць вынікі сканавання, прад'явіць патрабаванні. Мы стараемся адыходзіць ад паперак, пераводзіць усё ў чалавечы, які выкарыстоўвае распрацоўка — старонкі на Confluence са статусам і метрыкамі, дэфекты ў Jira ці ў розных дэфект-трэкерах, альбо ўбудаванне ў сінхронны/асінхронны працэс у CI/CD.
Ключавыя вынас
Інструменты не галоўнае. Спачатку прадумаць працэс - затым ўкараняць інструменты. Інструменты добрыя, але дарогі, таму можна пачаць з працэсу і наладзіць узаемадзеянне і разуменне паміж распрацоўкай і бяспекай. З пункту гледжання бяспекі - не трэба "стапіць" усё запар, З пункту гледжання распрацоўкі - калі ёсць нешта high mega super critical, то гэта трэба ўстараняць, а не зачыняць на праблему вочы.
Якасць прадукцыі - агульная мэта як бяспекі, так і распрацоўкі. Мы робім адну справу, стараемся, каб усё правільна працавала і не было рэпутацыйных рызык і фінансавых страт. Менавіта таму мы прапагандуем падыход да DevSecOps, SecDevOps, каб наладзіць зносіны і зрабіць прадукт якасней.
Пачніце з таго, што ўжо ёсць: патрабаванні, архітэктура, частковыя праверкі, трэнінгі, гайдлайны. Не трэба адразу прымяняць усе практыкі на ўсе праекты. рухайцеся ітэрацыйна. Адзінага стандарту няма - эксперыментуйце і спрабуйце розныя падыходы і рашэнні.
Паміж дэфектамі ИБ і функцыянальнымі дэфектамі знак роўнасці.
Аўтаматызуйце ўсё, Што рухаецца. Усё, што не рухаецца - рухайце і аўтаматызуйце. Калі нешта робіцца рукамі, гэта не добры ўчастак працэсу. Магчыма, варта яго перагледзець і таксама аўтаматызаваць.
Калі памер каманды ИБ невялікі - выкарыстоўвайце Security Champions.
Магчыма, тое, пра што я расказваў, вам не падыдзе і вы прыдумаеце нешта сваё — і гэта добра. Але выбірайце прылады, зыходзячы з патрабаванняў менавіта да свайго працэсу. Не глядзіце на тое, што кажа community, што гэтая прылада дрэнная, а гэтая добрая. Магчыма, менавіта на вашым прадукце апынецца ўсё наадварот.
Патрабаванні да інструментаў.
- Нізкі ўзровень False Positive.
- Адэкватны час аналізу.
- Зручнасць выкарыстання.
- Наяўнасць інтэграцый.
- Разуменне Roadmap развіцця прадукта.
- Магчымасць кастамізацыі інструментаў.
Даклад Юрыя выбралі адным з лепшых на DevOpsConf 2018. Каб пазнаёміцца з яшчэ вялікай колькасцю цікавых ідэй і практычных кейсаў прыходзьце 27 і 28 траўня ў Сколкава на у рамках . А яшчэ лепш, калі вы гатовы дзяліцца сваім вопытам, тады на даклад да 21 красавіка.
Крыніца: habr.com