Сканирование на уязвимости и безопасная разработка

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

При выполнении работы безопасники, пентестеры и разработчики неизбежно встречаются с процессами Vulnerability Management (VM) и (Secure) SDLC.


Они представляют собой инструменты и практики по проверке качества защиты инфраструктуры и программного обеспечения. Несмотря на то, что они ориентированы на разных потребителей, эти процессы во многом взаимосвязаны.
Рассмотрим подробнее, какие проблемы здесь могут возникнуть и почему технические инструменты до сих пор не смогли полностью заменить работу человека.
Процессы сканирования уязвимостей
Vulnerability Management — это процесс, суть которого в патч-менджменте и постоянном отслеживании состояния инфраструктуры.
Secure SDLC — процесс, предназначенный поддерживать защищенность приложения во время разработки и использования.
Эти процессы имеют общую функцию: сканирование и оценка состояния ПО (Vulnerability Assessment).
Отличаются они в основном целями сканирования.
При VM-сканировании выявляются уязвимости в конфигурациях или стороннем ПО, такие как устаревшая версия операционной системы и другие подобные проблемы. Такое сканирование, называемое ещё инфраструктурным, не очень интересно с точки зрения выполнения данной работы. По сути, его можно заменить таймером — если ваша инфраструктура длительное время не обновлялась, ее можно считать уязвимой.
В случае SDLC-сканирования первостепенно обнаружение уязвимости в самом коде продукта. Для того, чтобы выявить такие угрозы, необходимы специальные инструменты и алгоритмы, которые учитывают специфику приложения и его предназначение.
Инструменты
Два основных инструмента для сканирования защищенности — это «черный» и «белый» ящик.

  1. Black Box
При таком виде сканирования работа производится с помощью тех интерфейсов, с которыми взаимодействуют пользователи сервера. Эти сканеры относятся к классам DAST и IAST.
Инфраструктурные сканнеры, котором относиться и Tenable Nessus, находят сетевые порты, где они могут собрать «баннеры» и проверить имеющуюся версию ПО. 3атем они в своей базе данных ищут информацию о возможной уязвимости этой версии. Помимо этого сканеры проверяют конфигурацию на наличие слабых шифров SSL, незащищенных данных или паролей.
Сканеры проверяют и веб-приложения, в которых так же определяют версии систем и их уязвимые места. Процесс сканирования состоит из двух основных шагов: краулинга и фаззинга. Первый этап — это сбор информации о приложении, то есть его параметры, существующие интерфейсы. 3атем, на этапе фаззинга, сканер создает измененные данные и подставляет их в найденные параметры, таким образом провоцируя ошибку и обнаруживая уязвимость.

  1. White Box
Такое сканирование дает еще больше отличий в процессах VM и SDLC.
При VM сканер чаще всего получает доступ к самой системе, чтобы провести аутентификацию. Это позволяет сканеру работать с параметрами конфигурации и пакетами систем, выгружая их непосредственно из системы, а не угадывая с «баннеров». Анализ защищенности получается более точным и подробным.
Что касается сканеров приложений, здесь используются инструменты SAST-класса, что подразумевает статический анализ кода приложения.
Проблемы
  • Несмотря на разнообразные инструменты, специалисты сталкиваются с разными проблемами в процессе сканирования систем, анализа защищенности и безопасности разработки. Все эти проблемы можно разделить на две группы:
  • Проблемы сканирования веб-приложений
  • Сложно внедрять. Сканерам нужна конфигурация, их надо адаптировать под каждое конкретное приложение. Необходима тестовая среда и внедрение CI/CD, иначе будет неэффективно, а сканирование станет просто формальным и бесполезным.
  • Долгое сканирование. Сканеры все еще не очень хорошо работают с дедупликацией интерфейсов и могут несколько суток анализировать 1000 страниц, потому что считают, что они разные, хотя за них может отвечать один код.
  • Расплывчатые рекомендации. Очень часто сканеры дают общие выводы, по которым разработчик часто не может сразу понять, что конкретно нужно делать, чтобы обезопасить систему, и насколько срочно надо решить этот вопрос.
  • Деструкция. Сканер может негативно влиять на приложение, устроив атаку или создавая/изменяя сущности (например, написав лишние комментарии)
  • Низкое качество анализа. Сканеры могут пропускать те уязвимости, которые не указаны в «payloads», следовательно, не предусмотрены тем сценарием, который есть у сканера.
  • Непонимание назначения приложения и страниц. Сканеры не могут знать и учитывать специфику каждого приложения, ведь для них есть лишь параметры и ссылки, но нет понятия «платёж», «комментарий». Как следствие, огромное количество потенциальных угроз остаются не учтенными. Не могут сканеры и отличать содержание страниц, механизмов регистраций и логинов, поэтому некоторые части приложений сканеры могут просто проигнорировать.
Проблемы при сканировании исходника:
  1. Не достаточно точно. Из-за сложности процесса статического анализа зачастую страдает точность. Дорогостоящие и мощные сканеры тоже допускают множество ошибок.
  2. Сложно внедрять. Чтобы максимально избежать указанных в первом пункте ошибок, приходится адаптировать правила сканирования для каждого кода. Этот процесс хоть и повышает точность, является трудоемким и сложным. Иногда может быть проще проверить код на баги вручную, чем писать новое правило для сканера.
  3. Не поддерживают зависимости. В основном к зависимостям можно отнести фреймворки, дающие больше возможностей для программирования. Однако в базе знаний сканеров может не быть информации об этих библиотеках и их уязвимостях, поэтому сканер может просто не разобрать код.
  4. Время. Сканировать код на незащищенности — это долгий и сложный процесс даже для лучших сканеров. При этом в течение всего процесса сканер будет тратить большой объем вычислительных ресурсов.
  5. Низкая продуктивность. Разработчики SAST-сканеров вынуждены искать компромисс, потому что проанализировать абсолютно все состояния программы сканер не может, невзирая на затраченные ресурсы и время.
  6. Воспроизводимость находок. Хотя сканер и сообщает об уязвимости в конкретной строке, он все еще дает недостаточно полную информацию об угрозах извне. Например, сканер не работает с мертвым кодом, в котором также могут быть недостатки.
Что можно сделать?
  • Использование разных инструментов. Если грамотно использовать сканеры разного класса, анализ получится более полным и точным, а рекомендации позволят составить более полную картину состояния программы. Этот способ эффективнее, чем в сумме работа каждого сканера отдельно.
  • Интегрировать DAST и SAST. Обмениваясь информацией, сканеры этих двух классов дополняют друг друга. Можно проверить на уязвимости коды как изнутри системы, так и извне, что улучшает точность анализа.
  • Автоматический анализ защищенности может в будущем сильно усовершенствоваться благодаря использованию статистики. Это позволит сканерам "интуитивно" понимать ход мысли взломщиков и увеличить скорость своей работы.
  • Интегрировать IAST, где есть автотесты и OpenAPI. Используя CI/CD-pipeline, можно создать процесс сканирования, в основе которого инструменты HTTP-прокси и тесты функциональности. Они могут дать сканеру как возможность анализировать разные состояния приложения, так и получить дополнительную информацию.
  • Правильная конфигурация. Важно учитывать специфику приложений и инфраструктур и настраивать сканер в соответствии с особенностями интерфейсов и технологий.
  • Кастомизировать сканер. Очень часто приходится дорабатывать сканеры, ведь они не могут просканировать продукт полностью. Это зависит от специфики функций приложения и тех возможных недостатков, которые у него могут быть.
  • Риск-менеджмент. Все вышеперечисленные рекомендации: комбинирование сканеров, включение в процесс внешних систем —позволяют получить максимально полную картину о состоянии вашей инфраструктуры или разработки, так как в процессе анализа используются много разных параметров.

Категория: Статьи

Добавил: ingvarr

Дата публикации: 26.06.2019

Последнее редактирование: 15.06.2020

Просмотров: 269 | Рейтинг: 5.0/2

Всего комментариев: 0
Обсуждение материала:
Комментариев: 0
avatar