В рамках профессиональной деятельности разработчикам, пентестерам, безопасникам приходится сталкиваться с такими процессами, как Vulnerability Management (VM), (Secure) SDLC.
Под этими словосочетаниями скрываются различные наборы практик и используемых инструментов, которые переплетены между собой, хотя их потребители различаются.
Технический прогресс пока не дошёл до того, чтобы одним инструментом заменить человека для проведения анализа защищённости инфраструктуры и ПО.
Интересно понять, почему это так, и с какими проблемами приходится сталкиваться.
Процессы
Процесс Vulnerability Management («управление уязвимостями») предназначен для непрерывного мониторинга защищённости инфраструктуры и патч-менеджмента.
Процесс Secure SDLC («цикл безопасной разработки») предназначен для поддержки защищённости приложения в ходе разработки и эксплуатации.
Схожей частью этих процессов является процесс Vulnerability Assessment — оценки на уязвимости, сканирования на уязвимости.
Основное различие в сканировании в рамках VM и SDLC в том, что в первом случае целью является обнаружить известные уязвимости в стороннем ПО или в конфигурации. Например, устаревшую версию Windows или community-строку по умолчанию для SNMP.
Во втором же случае целью является обнаружить уязвимости не только в сторонних компонентах (зависимостях), но в первую очередь в коде нового продукта.
Это порождает различия в инструментах и подходах. На мой взгляд, задача поиска новых уязвимостей в приложении значительно интереснее, поскольку не сводится к фингерпринтингу версий, сбору баннеров, перебору паролей и т.д.
Для качественного автоматизированного сканирования уязвимостей приложений необходимы алгоритмы, учитывающие семантику приложения, его предназначение, специфичные угрозы.
Инфраструктурный же сканер зачастую можно заменить таймером, как выразился avleonov. Смысл в том, что чисто статистически вы можете считать вашу инфраструктуру уязвимой, если вы её не обновляли, скажем, месяц.
Инструменты
Сканирование, как и анализ защищённости, можно выполнять как чёрным ящиком, так и белым ящиком.
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 дадут сканеру недостающую информацию о потоках данных, дадут возможность просканировать приложение в различных состояниях
- Правильное конфигурирование. Под каждое приложение и инфраструктуру нужно создавать подходящий профиль сканирования, учитывающий количество и характер интерфейсов, используемые технологии
- Кастомизация сканеров. Зачастую приложение нельзя просканировать без доработки сканера. Пример — платёжный шлюз, в котором каждый запрос должен быть подписан. Без написания коннектора к протоколу шлюза сканеры будут бездумно долбиться запросами с неправильной подписью. Также необходимо писать специализированные сканеры под конкретный вид недостатков, таких как Insecure Direct Object Reference
- Риск-менеджмент. Использование различных сканеров и интеграция с внешними системами, такими как Asset Management и Threat Management, позволит использовать для оценки уровня риска множество параметров, так что руководство сможет получить адекватную картину о текущем состоянии безопасности разработки или инфраструктуры
Stay tuned and let's disrupt the vulnerability scanning!
