Информационная безопасность сейчас одна из наиболее горячих тем для обсуждения, которая вышла далеко за пределы ИБ-сообщества. Количество инцидентов и утечек возросло многократно, что стало дополнительным стимулом усиливать безопасность инфраструктуры и приложений, а уход иностранных вендоров только усугубил этот процесс. Одним из новых трендов стало проведение Bug Bounty программ. В этой статье я раскрою основные плюсы и минусы таких подходов как Bug Bounty и penetration testing.

Классический пентест

Пентест (penetration test, пенетрейшн тест) – тестирование на проникновение и безопасность, иначе анализ системы на наличие уязвимостей. Это метод оценки безопасности информационной системы путем моделирования атаки злоумышленников. Пентестинг ведется с позиции потенциального атакующего и может включать в себя активное использование уязвимостей системы.

Под "классическим" пентестом я подразумеваю старый добрый подход, который в большинстве своем сводится к понятию "время = деньги". Существует еще несколько разновидностей пентеста - от continuous pentest до red teaming. Обычно пентест включает в себя следующие пункты:

• аудит внешнего периметра;

• анализ безопасности веб-приложений;

• аудит внутреннего периметра;

• анализ безопасности беспроводного эфира;

• анализ мобильных приложений.

Зачастую пентестом считают и социотехнические атаки (фишинг/социалка), но правильнее относить этот подвид к security awareness.

Во время проведения пентестов практикуется отключение средств защиты и добавление IP-адресов пентестеров в белые списки, чтобы они успели идентифицировать как можно больше уязвимостей в заданные сроки, не учитывая обход защитных средств.

Хорошим итогом будет нахождение максимального количества уязвимостей за минимальный (условно) срок работ. Качество таких работ (кол-во найденных уязвимостей) зависит от:

• скиллов команды пентестеров;

• подхода к работам (методологии);

• объекта тестирования;

• количества пентестов "до";

• сроков работ.

В своей практике я сталкивался с отчетами по пентесту, которые представляли из себя откровенный шлак, такие отчеты не нравятся заказчикам (не несут полезной составляющей):

• отчет не содержит каких-либо значимых уязвимостей, при этом не описано какие проверки проводились и как;

• отчет содержит информацию об уязвимостях, но без технических деталей и импакта (применения уязвимости и ее влияние на бизнес-процессы);

• отчет не содержит рекомендаций;

• отчет представляет из себя выгрузку из автоматизированной утилиты/сканера (!!!).

Итого: на выходе заказчик получает n-багов и рекомендаций по исправлению, которые он применимо к задачам применяет в пайплайне информационной безопасности и ИТ-подразделений.

Bug Bounty

Программа Bug Bounty — программа, предлагаемая некоторыми веб-сайтами и разработчиками программного обеспечения, с помощью которой люди могут получить признание и вознаграждение за нахождение ошибок, особенно тех, которые касаются эксплойтов и уязвимостей. Эти программы позволяют разработчикам обнаружить и устранить ошибки, прежде чем широкая общественность узнает о них, предотвращая злоупотребления.

Хотя на российском интернет пространстве это и не новый термин (например self-hosted программе bug bounty от Яндекс уже более 10 лет; первая российская платформа Bug Bounty запущена в феврале 2021 года), тем не менее подход к проведению, политика разглашения уязвимостей и сам факт участия в программе принимался многими российскими компаниями как высокорисковое мероприятие:

• у нас априори не может быть уязвимостей, любой дисклоз (возможное публичное раскрытие информации) об уязвимости принесет нам репутационные риски;

• мы привлечем внимание злых хакеров и они нас поломают;

• а что если багхантеры понесут баги не нам, а на черный рынок? (а без публикации программы bb они этого сделать не могут?);

• мы не сможем оперативно править баги;

• вымогательство вознаграждений (да, такое бывает и без программ bb);

• бизнес не даст денег.

Самым большим драйвером популяризации Bug Bounty, как не странно, стал уход зарубежных площадок (вернее нежелание работать с российскими хантерами и холдерами программ).

Bug Bounty vs Penetration testing: подходы и различия

Ниже представлена табличка основных различий различных подходов обеспечения безопасности.

Выводы

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

Перед публикацией официального веб-сайта или онлайн-сервиса (и всегда после крупного обновления) желательно провести внутреннее тестирование, а затем комплексный тест на проникновение, который выявит наибольшие уязвимости безопасности.

После этих проверок происходит публикация приложения и запуск программы bug bounty. Важно, чтобы тестирование в программе bug bounty проходило в течение длительного времени (минимум от 3 до 6 месяцев, в идеале даже дольше). Это позволит хакерам, которые недавно зарегистрировались, предупредить вас об ошибках безопасности, вызванных, например, незначительными обновлениями в вашей системе.

Самым оптимальным вариантом для компании со зрелым циклом обеспечения информационной безопасности будет как проведение тестов на проникновение, так и организация bug bounty программ.