У рамках прафесійнай дзейнасці распрацоўнікам, пентэстэрам, бяспечнікам даводзіцца сутыкацца з такімі працэсамі, як Vulnerability Management (VM), (Secure) SDLC.
Пад гэтымі словазлучэннямі хаваюцца розныя наборы практык і выкарыстоўваных прылад, якія пераплецены паміж сабой, хоць іх спажыўцы адрозніваюцца.
Тэхнічны прагрэс пакуль не дайшоў да таго, каб адным інструментам замяніць чалавека для правядзення аналізу абароненасці інфраструктуры і ПЗ.
Цікава зразумець, чаму гэта так, і з якімі праблемамі даводзіцца сутыкацца.
працэсы
Працэс Vulnerability Management ("кіраванне ўразлівасцямі") прызначаны для бесперапыннага маніторынгу абароненасці інфраструктуры і патч-мэнэджменту.
Працэс Secure SDLC («цыкл бяспечнай распрацоўкі») прызначаны для падтрымкі абароненасці прыкладання падчас распрацоўкі і эксплуатацыі.
Падобнай часткай гэтых працэсаў з'яўляецца працэс Vulnerability Assessment – адзнакі на ўразлівасці, сканавання на ўразлівасці.
Асноўнае адрозненне ў сканаванні ў рамках VM і SDLC у тым, што ў першым выпадку мэтай з'яўляецца выявіць вядомыя ўразлівасці ў іншым ПЗ ці ў канфігурацыі. Напрыклад, састарэлую версію Windows або community-радок па змаўчанні для SNMP.
У другім жа выпадку мэтай з'яўляецца выявіць уразлівасці не толькі ў іншых кампанентах (залежнасцях), але ў першую чаргу ў кодзе новага прадукта.
Гэта спараджае адрозненні ў інструментах і падыходах. На мой погляд, задача пошуку новых уразлівасцяў у дадатку значна цікавей, паколькі не зводзіцца да фингерпринтингу версій, збору банэраў, перабору пароляў і т.д.
Для якаснага аўтаматызаванага сканавання ўразлівасцяў прыкладанняў неабходныя алгарытмы, якія ўлічваюць семантыку прыкладання, яго прызначэнне, спецыфічныя пагрозы.
Інфраструктурны ж сканер часцяком можна замяніць таймерам, як выказаўся . Сэнс у тым, што чыста статыстычна вы можаце лічыць вашу інфраструктуру ўразлівай, калі вы яе не абнаўлялі, скажам, месяц.
Інструменты
Сканіраванне, як і аналіз абароненасці, можна выконваць як чорнай скрыняй, так і белай скрыняй.
Black Box
Пры blackbox-сканаванні прылада павінна ўмець працаваць з сэрвісам праз тыя ж інтэрфейсы, праз якія з ім працуюць карыстачы.
Сканары інфраструктуры (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose і г.д.) шукаюць адчыненыя сеткавыя порты, збіраюць «банеры», вызначаюць версіі ўсталяванага ПА і шукаюць у сваёй базе ведаў інфармацыю аб уразлівасцях у гэтых версіях. Таксама спрабуюць выявіць памылкі канфігурацыі, такія як паролі па змаўчанні ці адчынены доступ да дадзеных, слабыя шыфры SSL і г.д.
Сканары вэб-прыкладанняў (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, і г.д.) таксама ўмеюць вызначаць вядомыя кампаненты і іх версіі (напрыклад, CMS, фрэймворкі, JS-бібліятэкі). Асноўныя крокі сканара - гэта краўлінг і фазінг.
У ходзе краўлінга сканер збірае інфармацыю аб існуючых інтэрфейсах прыкладання, HTTP-параметрах. Падчас фазінгу ва ўсе выяўленыя параметры падстаўляюцца мутаваныя ці згенераваныя дадзеныя з мэтай справакаваць памылку і выявіць уразлівасць.
Такія сканары прыкладанняў ставяцца да класаў DAST і IAST - адпаведна Dynamic і Interactive Application Security Testing.
White Box
Пры whitebox-сканаванні адрозненняў больш.
У рамках працэсу VM сканарам (Vulners, Incsecurity Couch, Vuls, Tenable Nessus і г.д.) часцяком даюць доступ да сістэм, праводзячы аўтэнтыфікаваны скан. Такім чынам, сканер можа выгрузіць усталяваныя версіі пакетаў і канфігурацыйныя параметры прама з сістэмы, не адгадваючы іх па банэрах сеткавых сэрвісаў.
Скан атрымліваецца дакладней і паўней.
Калі ж казаць аб whitebox-сканаванні (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs і г.д.) прыкладанняў, то гаворка звычайна ідзе аб статычным аналізе кода і выкарыстанні адпаведных інструментаў класа SAST – Static Application Security Testing.
Праблемы
Праблем са сканаваннем узнікае мноства! З большасцю з іх мне даводзіцца сутыкацца асабіста ў рамках падавання сэрвісу па пабудове працэсаў сканавання і бяспечнай распрацоўкі, а таксама пры правядзенні прац па аналізе абароненасці.
Вылучу 3 асноўныя групы праблем, якія пацвярджаюцца і гутаркамі з інжынерамі і кіраўнікамі службаў ИБ у самых розных кампаніях.
Праблемы сканавання вэб-прыкладанняў
- Складанасць укаранення. Сканары трэба разгортваць, канфігураваць, кастамізаваць пад кожнае прыкладанне, вылучаць тэставае асяроддзе пад сканы і ўкараняць у працэс CI/CD, каб гэта было эфектыўна. Інакш гэта будзе бескарысная фармальная працэдура, якая выдае няўжо што ілжывыя спрацоўванні
- Працягласць сканавання. Сканары нават у 2019 дрэнна спраўляюцца з дэдуплікацыяй інтэрфейсаў і могуць суткамі сканаваць тысячу старонак з 10 параметрамі на кожнай, лічачы іх рознымі, хаця адказвае за іх адзін і той жа код. Пры гэтым рашэнне аб дэплоі на прад у рамках цыклу распрацоўкі неабходна прымаць хутка
- Бедныя рэкамендацыі. Сканары выдаюць дастаткова агульныя рэкамендацыі, і не заўсёды распрацоўшчык можа па іх хутка зразумець, як яму знізіць узровень рызыкі, а галоўнае, ці трэба гэта рабіць прама зараз, ці пакуль не страшна
- Дэструктыўнае ўздзеянне на дадатак. Сканары цалкам могуць ажыццявіць DoS-напад на дадатак, а таксама могуць натвараць вялікую колькасць сутнасцяў або змяніць існуючыя (напрыклад, стварыць дзясяткі тысяч каментароў у блогу), так што не варта бяздумна запускаць скан у продзе
- Нізкая якасць выяўлення ўразлівасцяў. Сканары звычайна выкарыстоўваюць фіксаваны масіў карысных нагрузак («payloads») і могуць лёгка прапусціць уразлівасць, якая не ўкладваецца ў вядомы ім сцэнар паводзін прыкладання
- Неразуменне сканарам функцый прыкладання. Сканары самі па сабе не ведаюць, што такое "інтэрнэт-банк", "плацёж", "каментар". Для іх існуюць толькі спасылкі і параметры, так што велізарны пласт магчымых уразлівасцяў бізнэс-логікі застаецца зусім непакрытым, яны не здагадаюцца зрабіць падвойнае спісанне, падглядзець чужыя дадзеныя па ID ці накруціць баланс праз акругленне
- Неразуменне сканарам семантыкі старонак. Сканары не ўмеюць чытаць FAQ, не ўмеюць распазнаваць каптчы, самі па сабе яны не здагадаюцца, як трэба зарэгістравацца, і што затым трэба пералагінвацца, што нельга націскаць "logout", і як трэба падпісваць запыты пры змене значэнняў параметраў. У выніку большая частка прыкладання можа застацца наогул не прасканаваць
Праблемы сканавання зыходнага кода
- Ілжывыя спрацоўванні. Статычны аналіз - складаная задача, пры рашэнні якой даводзіцца звяртацца да мноства кампрамісаў. Часта даводзіцца ахвяраваць дакладнасцю, і нават дарагія enterprise-сканары выдаюць велізарную колькасць ілжывых спрацоўванняў
- Складанасць укаранення. Для павелічэння дакладнасці і паўнаты статычнага аналізу неабходна дапрацоўваць правілы сканавання, і напісанне гэтых правіл можа аказацца занадта працаёмкім. Часам прасцей знайсці ўсе месцы ў кодзе з нейкім багам і выправіць іх, чым пісаць правіла для дэтэкта такіх выпадкаў
- Адсутнасць падтрымкі залежнасцяў. Вялікія праекты залежаць ад вялікай колькасці бібліятэк і фрэймворкаў, якія пашыраюць магчымасці мовы праграмавання. Калі ў базе ведаў сканара няма інфармацыі аб небяспечных месцах («sinks») у гэтых фрэймворках, гэта стане сляпым плямай, і сканер проста нават не зразумее код
- Працягласць сканавання. Пошук уразлівасцяў у кодзе - гэта складаная задача і ў тэрмінах алгарытмаў. Таму працэс цалкам можа зацягнуцца і патрабаваць пры гэтым істотных вылічальных рэсурсаў.
- Нізкае пакрыццё. Нягледзячы на спажыванне рэсурсаў і працягласць сканавання, распрацоўнікам SAST-сродкаў усё роўна даводзіцца звяртацца да кампрамісаў і аналізаваць не ўсе станы, у якіх можа знаходзіцца праграма.
- Прайграванасць знаходак. Указанне на канкрэтны радок і стэк выклікаў, якія прыводзяць да ўразлівасці - гэта выдатна, але на самой справе часта сканер не дае дастаткова інфармацыі, каб праверыць наяўнасць уразлівасці звонку. Бо недахоп можа быць і ў мёртвым кодзе, які недасягальны для атакавалага
Праблемы сканіравання інфраструктуры
- Недастатковая інвентарызацыя. У вялікіх інфраструктурах, асабліва падзеленых геаграфічна, часта цяжэй за ўсё зразумець, якія хасты трэба сканаваць. Іншымі словамі, задача сканавання шчыльна злучана з задачай asset management
- Дрэнная прыярытызацыя. Сеткавыя сканары часта выдаюць шмат вынікаў з недахопамі, якія на практыцы не эксплуатуюцца, але фармальна ўзровень іх рызыкі высокі. Спажывец атрымлівае справаздачу, якую складана інтэрпрэтаваць, і незразумела, што трэба выпраўляць у першую чаргу
- Бедныя рэкамендацыі. У базе ведаў сканара часцяком толькі вельмі агульная інфармацыя аб уразлівасці і спосабах яе выпраўлення, так што адмінам прыйдзецца ўзброіцца гуглам. Сітуацыя крыху лепш з whitebox-сканерамі, якія могуць выдаваць канкрэтную каманду для выпраўлення
- Ручная работа. У інфраструктурах можа быць шмат вузлоў, а значыць, патэнцыйна шмат недахопаў, справаздачы па якіх даводзіцца разбіраць і аналізаваць уручную пры кожнай ітэрацыі.
- Дрэннае пакрыццё. Якасць сканавання інфраструктуры напрамую залежыць ад аб'ёму базы ведаў аб уразлівасцях і версіях ПЗ. Пры гэтым, , нават у лідэраў рынку база ведаў не ўсёабдымная, і ў базах бясплатных рашэнняў ёсць шмат інфармацыі, якой няма ў лідэраў
- Праблемы з патчынгам. Часцей за ўсё патчынг уразлівасцяў у інфраструктуры - гэта абнаўленне пакета ці змена канфігурацыйнага файла. Вялікая праблема тут у тым, што сістэма, асабліва legacy, можа непрадказальна павесці сябе ў выніку абнаўлення. Па сутнасці давядзецца праводзіць інтэграцыйныя тэсты на жывой інфраструктуры ў продзе.
Падыходы
Як жа быць?
Больш падрабязна пра прыклады і пра тое, як змагацца з многімі з пералічаных праблем, я раскажу ў наступных частках, а пакуль укажу асноўныя напрамкі, у якіх можна працаваць:
- Агрэгацыя розных інструментаў сканавання. Пры правільным выкарыстанні некалькіх сканараў можна дамагчыся значнага павелічэння базы ведаў і якасці дэтэкта. Можна знайсці нават больш уразлівасцяў, чым сумарна ўсе сканары, запушчаныя па асобнасці, пры гэтым можна дакладней ацэньваць узровень рызыкі і даваць больш рэкамендацый.
- Інтэграцыя SAST і DAST. Можна павялічыць пакрыццё DAST і дакладнасць SAST за рахунак абмену інфармацыяй паміж імі. З зыходнікаў можна атрымаць інфармацыю аб існых роутах, а пры дапамозе DAST можна праверыць, ці відаць ці слабасць звонку.
- Machine Learning™. У 2015 годзе я (і ) пра прымяненне статыстыкі для таго, каб даць сканарам інтуіцыю хакера, і паскорыць іх. Гэта вызначана з'яўляецца ежай для развіцця аўтаматычнага аналізу абароненасці ў будучыні
- Інтэграцыя IAST з аўтатэстамі і OpenAPI. У рамках CI/CD-pipeline магчыма стварэнне працэсу сканавання на аснове прылад, якія працуюць у якасці HTTP-проксі, і функцыянальных тэстаў, якія працуюць па HTTP. Тэсты і кантракты OpenAPI/Swagger дадуць сканеру неабходную Вам інфармацыю пра струмені дадзеных, дадуць магчымасць прасканаваць прыкладанне ў розных станах
- Правільнае канфігураванне. Пад кожнае прыкладанне і інфраструктуру трэба ствараць прыдатны профіль сканавання, які ўлічвае колькасць і характар інтэрфейсаў, якія выкарыстоўваюцца тэхналогіі
- Кастамізацыя сканараў. Часцяком прыкладанне нельга прасканаваць без дапрацоўкі сканара. Прыклад - плацежны шлюз, у якім кожны запыт павінен быць падпісаны. Без напісання канектара да пратакола шлюза сканары будуць бяздумна дзяўбці запытамі з няправільным подпісам. Таксама неабходна пісаць спецыялізаваныя сканары пад канкрэтны від недахопаў, такіх як
- Рызыка-мэнэджмент. Выкарыстанне розных сканер і інтэграцыя з вонкавымі сістэмамі, такімі як Asset Management і Threat Management, дазволіць выкарыстоўваць для ацэнкі ўзроўню рызыкі мноства параметраў, так што кіраўніцтва зможа атрымаць адэкватную карціну аб бягучым стане бяспекі распрацоўкі або інфраструктуры.
Stay tuned and let's disrupt the vulnerability scanning!
Крыніца: habr.com