Введение
Таккак мы уже начали эту тему и рассказали вам про процесс SCA, настало время поговорить о том, как именно тестируется исходный код приложений и сами приложения с точки зрения безопасности. Как и в прошлый раз, это статья для безопасников, которым по каким‑то причинам нужно поддержать разговор про SSDL — безопасную разработку.
Откуда мы вообще берем знания о том, какое ПО и компоненты в нем уязвимы? Есть несколько способов. Во‑первых, всегда можно привлечь специалистов извне (или есть такие энтузиасты), которые будут искать слабые места в ваших продуктах. Во‑вторых, и это уже идет по умолчанию во многих компаниях, производители ПО сами проверяют его, тестируют и ведут реестр найденных уязвимостей вместе с версиями, где это было найдено. Ну и немаловажно упомянуть о сертификации — это уже отлаженный процесс с подробной методикой того, а какие именно шаги нужно предпринимать для тестирования ПО по параметрам безопасности; даже если вам нужен не сам сертификат, а уверенность в том, что вы досконально проверили ваш продукт на наличие уязвимостей — это также пригодится.
У всех компаний процесс выстроен по‑разному, и не всегда совпадают как шаги, так и терминология. Поэтому так важно привести все это к общему знаменателю.
Нормативная документация
Существуют как открытые, так и закрытые документы, описывающие процесс и порядок проведения тестирований. Конечно же, о закрытых документах мы говорить не будем, только верхнеуровнево пройдемся по шагам того, что уже стандартизировано.
Про процесс
Итак, как же нам проверить наш продукт? Не только поискать в известных базах уязвимостей, что в нем может содержаться, но и определить свои?
Давайте определимся с тем, что мы вообще ищем:
Собственно, уязвимости. Первой ассоциацией у большинства специалистов будут уязвимости исходного кода, но это еще не все: уязвимыми также могут быть и конфигурации, которые поставляются вместе, и архитектура — что, если в целом подход к реализации был уязвим?
Недекларированные возможности. Необязательно бекдоры, но в целом все, что не отражено в документации. Даже если администраторам так проще починить продукт, или если разработчик где‑то срезал пару углов — это угроза безопасности всего ПО.
Виды проверок, которые могут нам помочь, также отличаются в зависимости от цели и способа проверки. Для сертификации необходим комплекс проверок, но в некоторых компаниях иногда проводится и что‑то одно, и это не всегда значит, что тестирование неэффективно.
Рассмотрим проверки.
Исследования
Архитектура
Как уже было затронуто ранее, все начинается с архитектуры продукта; уже она сама может быть уязвима.
Обычно на этом этапе проверяется состав модулей продукта; в зависимости от того, что выбрано — монолит, микросервисы, что‑то еще — определяется дальнейший порядок проверок.
Нужно разобраться с тем, как управлять продуктом, как он запускается, какие доступны интерфейсы и тд. На этом этапе также определяется поверхность атаки — что доступно, например, пользователю, какой он видит интерфейс, что он может делать с вашим ПО.
Ну и конечно на этом этапе уже можно оценить возможные угрозы.
Статика
Если вы интересуетесь тестированием ПО как ИБ‑специалист, то, возможно, в ходе вашей работы вам уже довелось столкнуться с анализаторами кода — ПО, которое проверит синтаксис и укажет на возможные уязвимости.
Для специалиста по безопасной разработке и/или разработчика это выглядит как размеченный примечаниями код — программа говорит, что, например, в этой части кода возможно использование SQL‑инъекции, а вот эта — говорит о переполнении буфера.
В целом, вердикт такого анализатора зачастую оказывается правдивым. Но нельзя до конца доверять оценку вашего кода машине — все равно по такой разметке должен пройтись специалист, чтобы подтвердить или опровергнуть вердикт; анализатору кода, к примеру, может быть неизвестно, что проблема с переменной, на которую он указал, решается дальше по коду, и разработчик учел возможные проблемы.
Если говорить о методическом подходе — не весь код может быть покрыт таким анализатором. Это может быть новый язык программирования, для которого пока не все известно.
Динамика
К динамическому анализу кода можно отнести несколько проверок, но мы поговорим только об одной из них — о фаззинг‑тестировании.
В отличие от статики, которая берет текст исходного кода, фаззинг оперирует приложением так, как если бы с ним работал пользователь. Это намеренное обобщение, но, по сути, если посмотреть на результаты такого исследования, найденные уязвимости и их воспроизведение очень на это похожи.
Для проведения фаззинга в код программы добавляются места для общения с продуктом — возможность что‑то получить или отправить. И дальше фаззер начинает массово отправлять данные в эти врезки. На что похожи эти данные? Чаще всего это полуосмысленный поток того, что теоретически может попадать на вход — это может быть и файл, загружаемый пользователем в веб‑версии приложения; и отправка внутри модулей приложения информации о статусе какого‑либо внутреннего объекта.
Дело в том, что фаззер будет видоизменять этот поток данных с помощью мутаций, увеличивать его или уменьшать — словом, проверять нестандартные варианты отправки.
При динамическом тестировании приложение запускается огромное количество раз в ожидании на один такой поток данных получить наконец зависание или ошибку приложения.
Экспертиза кода
Экспертиза кода проводится после всех этапов тестирования, когда мы уже поняли, какие модули или компоненты не были затронуты на предыдущих этапах.
Грубо говоря, сейчас время закрыть пробелы и оценить, уязвим ли непокрытый код, входит ли он в поверхность атаки.
Необязательно смотреть только тот код, который не был проверен автоматически; как мы уже говорили ранее, целиком полагаться на автоматизацию пока не получится, и специалист может проверить все приложение в целом.
К тому же, если у компании еще не выстроены соответствующие процессы, то все, что остается — вручную проверять продукт на уязвимости.
Сообщество
Помимо того, что в рамках сертификации с тестированием ПО помогает регулятор и лаборатории, существует также SDL‑сообщество: команда инициативных специалистов, которые в том числе исследуют ПО с открытым исходным кодом и делятся результатами этих исследований.
Заключение
Чем бы вы ни пользовались на своем пути к безопасной разработке — неважно, начали вы этот путь для сертификата или для того, чтобы быть уверенным в своем продукте — начать всегда можно с малого. Необязательно пытаться выстроить весь процесс с нуля сразу — это попросту невозможно ввиду того, что в том числе все завязано на команду, на внутренние процессы разработки, которые уже существуют.
