Бортовой лог №1, 23.08.20xx. Говорит Денис Кораблёв, капитан одного из научно-исследовательских кораблей Positive Technologies. Я поручил нашему ай-ай открыть шампанское: сегодня вышел из беты DAST-сканер PT BlackBox.
Что такое DAST-сканер? Какие функции он выполняет? Почему без него в разработку не внедрить качественные практики DevSecOps? И кто такой ай-ай?.. Ответы дадут собранные в этом посте бортовые логи. А если вы уже разбираетесь в DevSecOps, то логи раскроют тонкости нашей работы и расскажут о её результате — PT BlackBox.
Список членов команды с правом записи бортовых логов
Денис Кораблёв
Капитан исследовательского судна PT BlackBox (управляющий директор, директор по продуктам Positive Technologies)
Евгений Рыжов
Коммандер, руководитель научного отдела (руководитель отдела разработки PT BlackBox компании Positive Technologies)
Олег Халаджиев
Главный научный пилот (руководитель группы обеспечения качества PT BlackBox компании Positive Technologies)
Что такое DevSecOps
Бортовой лог №2, 23.08.20xx. Автор лога — Евгений Рыжов. Для начала поговорим про DevSecOps. Что это такое? И почему наша миссия связана с этим понятием?
Наверное, каждый IT-астронавт в наш высокотехнологичный век сталкивался со знаменитой восьмёркой DevOps: бесконечной как просторы Вселенной.
Но в отличие от Вселенной глубоких загадок эта восьмёрка не таит. Цель DevOps — дать компании набор практик и инструментов для быстрого и надёжного выпуска продуктов, обновлений, багфиксов.
DevSecOps — это DevOps + Security. И действительно, цель DevSecOps-практик — на всех этапах следить за безопасностью будущего продукта.
Делают ли это все IT-астронавты? Пока нет, только треть. Есть к чему стремиться. Угрозы тем временем всё ближе: в 2020 и 2021 году уровень защиты половины веб-приложений был низким или даже крайне низким. Есть о чём подумать.
В космосе никто не услышит, как ты кричишь (от злости, что тебя взломали)
Бортовой лог №3, 23.08.20xx. Автор лога — Евгений Рыжов. Наши главные противники — веб-уязвимости. Они разнообразны и многочисленны. Их открывают каждый день — как и новые звёзды. Чем они опасны для разработчиков и пользователей?
Прежде всего это ошибки или недочёты внутри кода приложения. Злоумышленник эксплуатирует их и добивается тем самым своих целей.
Цели эти тоже бывают разными. Цель некоторых киберпреступников — вывести приложение из строя или нарушить его работоспособность. Чтобы весь экипаж в аварийном режиме исправлял последствия взлома. А кого-то из злоумышленников привлекают личные данные астронавтов и космических колонистов. Особенно финансовые. Они их часто шифруют, чтобы потом шантажировать жертву.
Впрочем, есть и злоумышленники, которые работают за идею. Им просто нравится уничтожать данные.
Может показаться, что веб-уязвимости — проблема небольших компаний, которым просто не до безопасности. Но уязвимы все. Если сухие цифры вас не убедили, приведу конкретный пример.
Всего два года назад один из наших специалистов выявил критическую уязвимость в Jira. К тому моменту Jira была проектом с почти 20-летней историей. Программами её производителя Atlassian пользовались 170 тысяч человек по всему миру.
Каждая открытая звезда при занесении в каталог получает собственный номер — и астрономы измеряют её светимость. С недостатками безопасности то же самое: этот получил идентификатор CVE-2020-14181 и оценку угрозы 5,3. Не первой величины звезда — средний уровень опасности — но обратить внимание стоило. С помощью этой уязвимости злоумышленники могли выяснить существующие логины пользователей путём перебора. И если логин в системе существовал, она сама выдавала занесённые в базу личные данные.
Веб-уязвимости многочисленны, они множатся и эволюционируют — ужас технологического мира. Так как им может противостоять DevSecOps?
Space SAST и DAST
Бортовой лог №4, 23.08.20xx. Привет, это Олег Халаджиев. В основе DevSecOps-практик лежат два типа сканеров: SAST и DAST. Изучим, чем они отличаются, на чём специализируются — и к какому типу относится PT BlackBox.
Вроде бы перед нами всё та же DevOps-восьмёрка. Но не совсем. Как видите, по бокам у неё появились слова SAST и DAST — названия двух типов сканеров, которые в открытом космосе защищают корабль от веб-угроз.
SAST-сканер (он же статический сканер) анализирует приложение на уязвимости на ранних этапах разработки. Планирование, кодинг, сборка билдов и тестирование — это его зоны ответственности. Он тестирует продукт по методу белого ящика — все двери для него открыты. При этом тестирование проходит до развёртки. Приложение ещё не находится в среде, в которой позже будет работать.
Это впечатляет, но не даёт исследователям и команде IT-корабля полной картины. Сами понимаете, многие уязвимости появляются, когда продукт уже работает и взаимодействует с другими приложениями.
Здесь на сцену выходит динамический DAST-сканер. Он отслеживает уязвимости, когда приложение появляется на тестовых серверах. Работает такой сканер по методу чёрного ящика. У него нет доступа к внутренностям приложения. Вместо этого он имитирует случайное поведение и действия пользователя. И находит уязвимости, которые ускользают от SAST: недостатки конфигурации защитных механизмов, ошибки идентификации и аутентификации, проблемы, связанные с устаревшими версиями используемого ПО. Все эти типы уязвимостей входят в топ-10 OWASP: то есть называть их несерьёзными язык не поворачивается.
Те же недостатки аутентификации и идентификации несут среднюю или даже высокую степень риска. Воспользовавшись такой уязвимостью, любой космический пират может дорваться до приложений и личных кабинетов обычных пользователей — жителей поселений и исследовательских станций, разбросанных по галактике.
Как же DAST-сканер выявляет эти уязвимости? Да как раз за счёт того, что различными методами внедряется в уже работающее приложение.
Теперь мы разобрались с теорией. Начнём разговор про DAST-сканер PT BlackBox.
Поехали!
Бортовой лог №5, 23.08.20xx. Говорит Денис Кораблёв. Поделюсь воспоминаниями о временах, когда ядро будущего PT BlackBox ещё только зарождалось в других наших продуктах.
Цель нашего корабля — сделать миссии отечественных IT-кораблей безопасными даже на тех рубежах, куда не ступала нога человека. С выходом PT BlackBox мы как никогда близки к этой цели.
Мы создаём экосистему Application Security с DevSecOps полного цикла, способным защитить IT-корабль от любых космических угроз. В этом нам помогают три продукта: PT Application Inspector, PT Application Firewall и PT BlackBox, который стал ещё одним важным шагом для компании на пути к экосистеме AppSec.
На старте наш корабль был поменьше и экипаж насчитывал пять человек. В 2011 у нас уже был свой модуль для DAST-сканирования. Но чего-то в нём не хватало… И мы осознали, что людям нужен полновесный DAST-сканер со всеми фичами: чтобы и сам интегрировался в приложение, и сам проверял. Так родился первый прототип PT BlackBox. Правда, название появилось гораздо позже. Тогда он назывался WebEngine, а между собой мы любовно величали его «веб-движка».
Зачем хитрый, но дружелюбный ай-ай изучает чёрный ящик
Бортовой лог №6, 23.08.20xx. Автор лога — Евгений Рыжов. Что такое тестирование по методу чёрного ящика? Само название PT BlackBox указывает на этот метод проверки. Я опишу, какие задачи он позволяет выполнять.
PT BlackBox — первый полноценный on-premise DAST-сканер на российском рынке. Конкурентные решения — это всегда сочетание SAST и DAST, к которым иногда добавляется ещё и IAST (интерактивное сканирование).
PT BlackBox не имеет ни доступа к исходному коду, ни особых привилегий. На приложения анализатор смотрит снаружи — как сторонний наблюдатель.
Но он любопытен как зверёк ай-ай — маскот созданного нами AppSec-комьюнити. И сканеру, как зверьку, интересно пробраться внутрь чёрного ящика и выведать, что же там прячется.
Ай-ай — зверь дружелюбный и даже разрешённый к содержанию в каюте. PT BlackBox перенял у него эти качества. Если анализатор находит в продукте уязвимости, то, конечно, указывает на них. Чтобы пользователь их исправил до того, как до них доберётся злоумышленник.
В основе PT BlackBox — модульный подход. Ядро сканера взаимодействует с многочисленными модулями, которые проверяют приложения и сайты на разные типы уязвимостей. Добавлять в решение новые модули несложно. Юзер может расширять функционал под свои нужды и решать разные типы задач.
Зачем вообще что-то проверять DAST-анализатором, если существует SAST? До взлёта корабля SAST-сканер вроде бы выявляет все уязвимости. Разве недостаточно просто их устранить?
Нет. DAST и сканирование методом чёрного ящика как раз и нужны потому, что корабль взлетел и бороздит просторы галактики, сталкиваясь с новыми опасностями, которых точно не было на космоверфи во время сборки.
Динамический анализатор может быть контрольной проверкой: уже во время полёта подтверждать те уязвимости, которые SAST нашёл в процессе сборки корабля. Достаточно запустить его в stage-окружении приложения, чтобы понять, какими уязвимостями реально смогут воспользоваться космические пираты — или другие злоумышленники.
Если и SAST-, и DAST-сканеры обнаружили угрозу, она почти наверняка существует и её надо исправлять. Впрочем, если уязвимость не подтвердилась, это не значит, что можно о ней забыть. Возможно, она скрыта другими механизмами. И ещё может о себе неприятно заявить.
Итерации, модули
Бортовой лог №7, 23.08.20xx. Говорит Денис Кораблёв. Во время разработки ядро нашего сканера развивалось и менялось. Сейчас живёт уже четвёртая его итерация. Рассказываю, какие новшества она привнесла в нашу работу.
Вот одно из них: мы реализовали функцию параллельной проверки приложения несколькими модулями. По сравнению с прошлой итерацией данные о различных типах потенциальных уязвимостей собираются куда быстрее. В некоторых случаях четвёртая итерация быстрее третьей на 25%, порой на 50%, а то и на все 150%.
Конкретная скорость сканирования каждой цели зависит, помимо её размеров, ещё и от числа запущенных проверок. Чем больше модулей работают одновременно, чем глубже проверка — тем больше времени она займёт.
Поскольку для нас были важны быстрые и точные параллельные проверки, нужно было подружить между собой модули, которые их проводят. Думаете, один искусственный интеллект на космическом корабле — это проблема? Представьте ситуацию, когда их десять, они все выполняют схожие задачи и время от времени переходят от пассивной киберагрессии к настоящей войне роботов: мешают друг другу найти уязвимость или язвительно подкидывают коллегам ложных позитивов.
К четвёртой итерации ядра мы помогли им этот негатив преодолеть. Теперь модули слаженно работают в команде.
Скорость и бесшумность — самые важные для сканера параметры
Даже когда клиент путешествует в космосе с околосветовой скоростью, время для него остаётся чрезвычайно важным ресурсом. Мы этот ресурс бережём.
Мы провели тест на сканирование множественных целей. Выбрали 60 приложений, целый тестовый полигон. При этом выбранные приложения специально были максимально друг на друга не похожи: разнообразны и сложны, как космические объекты в обозримой вселенной. PT BlackBox просканировал весь полигон за 17,5 дней. Для сравнения: два сканера с открытым исходным кодом анализировали эти же цели 60 и 133 дня соответственно.
Скорость, конечно, важна. Но это не единственный параметр. Даже не основной. Обращать внимание нужно прежде всего на зашумлённость отчёта сканера: она вычисляется через отношение найденных подтверждённых уязвимостей (true positive) к числу ложных срабатываний (false positive), то есть якобы уязвимых мест, в которых на самом деле нет дыр и ошибок. Замеряли мы её по формуле 100% (все уязвимости) - 100% * True Positive / (TP + TP-дубликаты + False Positive + FP-дубликаты).
Шумность — как та же солнечная радиация. Создаёт помехи в общении между сканером и командой корабля. Тратит время всей команды.
Предположим, DAST-сканер найдёт одну и ту же брешь в безопасности 10 раз, все их отметит в отчёте, как уникальные уязвимости. А потом ещё отыщет дюжину False Positive и тоже запишет себе в заслуги. Каково будет специалисту по безопасности, который только что вернулся из недельного отпуска на VR-палубе, разбираться в подобном отчёте? И доверится ли он такому сканеру в будущем?
На нашем тестовом полигоне из 60 приложений мы проверили динамические анализаторы на шумность отчётов. Опенсорсный DAST нашёл 15 238 уязвимостей. Но только 1 972 из них были настоящими True Positive. Остальные 13 266 оказались дубликатами, ложными срабатываниями (их было больше полутора тысяч) и дубликатами ложных срабатываний (их было даже больше, чем просто False Positive).
PT BlackBox в той же ситуации нашёл 2 510 True Positive. Анализатор также обнаружил 80 False Positive и всего 1 False Positive-дубликат. TP-дубликатов он нашёл больше — 6 716. Но итоговый отчёт всё равно вышел почти на 40% короче — 9 307 уязвимостей — с большим количеством реально найденных брешей в безопасности.
Межзвёздные облака
Бортовой лог №8, 23.08.20xx. Автор лога — Евгений Рыжов. Поговорим о том, как наше ядро работает в облачном режиме.
Сейчас ядро лежит в основе бесплатного облачного сервиса PT BlackBox Scanner. С помощью этого сервиса можно проверить сайт. Продукт позволяет запускать несколько ядер сканера в параллель.
Одна из целей PT BlackBox — интегрироваться в процессы разработки. Поэтому, чем сканер доступнее для всех кораблей в IT-космосе — тем лучше.
Разработка этого облачного решения была многокомпонентной. Очевидно, сначала ядро надо было заставить работать в таком режиме. А дальше шла череда нюансов.
Недостаточно, чтобы эти ядра просто работали вместе одновременно на несколько целей. Представим фантастическую ситуацию: одно из ядер сканера почему-то недоступно. Чтобы вы понимали, обычно это форс-мажор и угроза всему сканированию — как если бы у ракеты во время полёта отказал один из двигателей.
Наш сканер в такой ситуации не останавливается. Прежде всего он распределяет задачи между теми компонентами, которые по-прежнему остались в работе. За счёт работающих «двигателей» ракета продолжает намеченный курс на орбиту и не теряет данные.
А когда вышедший из строя «двигатель» сканера возвращается в строй, он тут же снова подхватывает работу.
Искривления в пространстве и точечный анализ космоса
Бортовой лог №9, 23.08.20xx. Привет, это снова Олег Халаджиев. Масштабное и тщательное сканирование на все возможные уязвимости — это круто. Но что, если приложение атакуют прямо сейчас?
Во время атаки полноценное DAST-сканирование, конечно, не успеет защитить приложение. Для этой задачи существуют специальные классы решений: – например, межсетевые экраны уровня веб-приложений. Поэтому мы интегрировали ядро PT BlackBox с другим нашим продуктом — межсетевым экраном уровня приложений PT Application Firewall.
Как действует эта интеграция? Скажем так, она создаёт небольшой разрыв, искривление пространства между приложением и остальным интернетом. И пользователь, начав пользоваться приложением, попадает в это искривление. PT Application Firewall следит за действиями внутри созданного разрыва. Проверяет все запросы с той стороны.
И если замечает подозрительное количество обращений на одну цель, подключает нашу технологию динамического анализа для точечной проверки.
Например, если один за другим приходят запросы с кавычками (это самый простой способ проверить приложение на SQL-инъекцию), PT Application Firewall эти запросы заблокирует. А после попросит сканер проверить, могли ли они нанести системе реальный урон. Если это была настоящая атака, то DAST-анализатор об этом сообщит. А PT Application Firewall повысит приоритет защиты против такого типа уязвимостей.
Рост команды и сумма технологий
Бортовой лог №10, 23.08.20xx. Говорит Денис Кораблёв. Всего несколько логов назад я ностальгировал по временам, когда на корабле нас было пятеро. Ностальгия — это прекрасно. Но ещё важнее рассказать о команде, которую мы собирали для выполнения этой задачи. И о том, какие инструменты она применяет в своей работе.
Давным-давно, в период создания первого прототипа сканера, наша экспертиза лежала в основном в области пентеста. Пентестерские знания пригодились именно на этапе создания прототипа.
Но нам быстро стало не хватать экспертов-разработчиков. Мы набрали в проект команду людей, занятых прежде всего программированием.
Раньше в Positive Technologies были единые команды тестирования для всех проектов компании. Тестеры работали на том или ином корабле смену, а потом улетали на следующее ответственное задание.
Потом за каждым проектом решили закрепить свою команду — и у нас появилась собственная группа тестировщиков. Мы также перешли с ручных тестов на автоматизированные.
Также к нам присоединились свой системный администратор, который совмещает функции разработчика, свой дизайнер и свой специалист по разработке фронтенда.
И специалисты по облакам, конечно. Без них PT BlackBox реализовать в его нынешнем виде было бы невозможно.
Сейчас наша команда пользуется обширным стеком технологий. Перечислю только часть, остальные сведения защищены космическим NDA.
Наш основной язык разработки — Python 3, а начинали мы на Python 2. Для повышения производительности используются компоненты на Go. В качестве корабельной базы данных — кладезя знаний для облачного решения — мы используем PostgreSQL, на который перешли с MariaDB. Работа очередей налажена через RabbitMQ.
Рассказываю я это, чтобы вы поняли, что годы сбора экспертизы и итерационной разработки не прошли даром. Выход PT BlackBox из беты — кульминация 10 лет работы разнопрофильной команды, которая занимается технологиями Application Security.
Решение уже применялось в других продуктах Positive Technologies, чтобы усилить их стек.
Например, межсетевой экран уровня веб-приложений PT Application Firewall использовал данную технологию для сканирования серверной части приложений. В прошлом логе Олег упоминал об этой интеграции.
Сканер использовался в системе анализа защищёенности PT Application Inspector для подтверждения уязвимостей, найденных в исходном коде.
А в системе контроля защищённости и соответствия стандартам MaxPatrol 8 — для поиска веб-уязвимостей внутри периметра.
Включаем варп-двигатель
Бортовой лог №11, 23.08.20xx. Говорит Денис Кораблёв. Перед взлётом важно ответить ещё на один вопрос. Почему мы выходим из беты именно сейчас? Ведь технология уже обкатана.
Причина — состояние информационной безопасности в IT сейчас. Российским компаниям стремительно становятся недоступны коммерческие решения подобного плана. Зарубежные производители похожих продуктов ушли.
Сейчас в стране остались только open-source-решения. Но они далеко не идеальны.
Мы не хотим, чтобы российский интернет стал опасным, поэтому выпускаем сканер именно сейчас.
Важно, что PT BlackBox можно использовать не только как сторонний инструмент, но и встроить его в свои процессы разработки и внедрить в DevSecOps-практики. Это улучшит безопасность многих систем.
Заключение
Бортовой лог №123, 23.08.20xx. Говорит Денис Кораблёв.
PT BlackBox к выходу из беты готов. Я, члены моей и других команд Positive Technologies искренне надеемся, что треть погружённых в практики DevSecOps компаний — не предел для Рунета.
Применение SAST- и DAST-сканеров и другие DevSecOps-практики нужны не только ИБ-компаниям. Настоящий DevSecOps всегда полезен кораблю, путешествующему в цифровом космосе, и зачинается в момент близости ИБ и разработчиков, когда те вместе ищут оптимальное решение в страстном споре «безопасность или функциональность».
Потому в какой бы сфере разработки вы ни были заняты, рекомендую изучить DevSecOps хоть немного. В том числе глубже поинтересоваться тем, как работает PT BlackBox — эта информация есть на нашем сайте. Более того, сканер уже готов к коммерческому использованию — и его можно взять на пилотный проект.
На этом наши логи заканчиваются. А Positive Technologies продолжит выполнять свою главную задачу — обеспечивать безопасность российского IT даже на тех рубежах, куда не ступала нога ай-ай.