Привет! Снова подготовили для вас материал от Романа Стрельникова, руководителя направления по информационной безопасности 1С‑Битрикс. Сегодня поговорим про offensive security. Вокруг темы много споров — стоит ли контролировать подрядчиков, что выбрать — пентест или баг баунти, как определить квалификацию команды хакеров. В этом материале расскажу про наш подход к «наступательной безопасности» и дам пару советов о том, как получить максимум выгоды из работы с «этичными хакерами».
Прежде чем Роман поделится собственным опытом, давайте пробежимся по ключевым понятиям.
Итак, Offensive Security (наступательная безопасность) — это один из способов проактивной защиты ИТ‑инфраструктуры бизнеса, когда компания платит профессиональным хакерам, чтобы те попытались ее взломать. Так можно найти уязвимости раньше, чем это сделают настоящие злоумышленники, проверить, насколько защита реально работает и соответствует требованиям регуляторов.
Для такой проверки нанимают «этичных хакеров» — специалистов по кибербезу, которые ищут уязвимости в чужих системах легально, с разрешения их владельцев и в рамках договорных отношений. Но есть нюансы — не все виды Offensive Security в полной мере отвечают нормам закона.
Всего их три:
Bug Bounty — компания платит деньги любому, кто найдёт уязвимость в её системе.
Пентест — хакеру дают доступ к сайту и просят найти уязвимости, при этом служба безопасности в курсе проводимой проверки;
Red Team — команда хакеров скрытно атакует компанию, как настоящие киберпреступники.
По российским законам (статья 272 УК РФ) несанкционированное проникновение в ИТ‑системы — это уголовное преступление. Но если доступ согласован с владельцами, то как такового состава преступления нет. При этом в законах нет четкого определения того, как можно, и как нельзя проверять системы на прочность. Например, если Red Team, подписавшая договор с компанией, попробует проникнуть в ее систему с помощью эксплойтов или вредоносных утилит — это создаст проблему со статьей ст. 273 УК РФ, запрещающей подобные методы. Если действия белых хакеров приведут к сбоям или повреждениям систем — это также может быть оценено как преступление.
Так что пока закону соответствуют только пентесты и Bug Bounty, санкционированные владельцами систем.
В данный момент 1С‑Битрикс привлекает для тестирования своих продуктов как пентестеров, так и независимых экспертов на платформе Standoff 365 Bug Bounty от Positive Technologies. Разносторонний подход к Offensive Security позволяет нам поддерживать высокий уровень защищенности решений.
Зачем компаниям проводить пентесты и какие они бывают
Пентестеры используют те же методы и инструменты, что и настоящие хакеры, а результат их работы показывает реальную картину: где можно обойти антивирус; сработает ли защита, если хакер уже закрепился в сети; пройдет ли сотрудник по ссылке из фишинговой рассылки и пр.
Существует несколько видов пентестов:
Black Box Testing. Максимально приближен к реальной жизни, когда хакер ничего не знает о системе и действует практически как злоумышленник, который пытается получить доступ, используя общедоступные данные. Этот вид тестирования полезен для оценки внешней безопасности.
White Box Testing. В этом варианте хакер получает практически всю информацию и по исходному коду, и по архитектуре продукта или внутренних систем — именно в них он выявит недостатки на ранних этапах разработки.
Gray Box Testing. Нечто среднее между двумя предыдущими подходами. Хакеру предоставляют минимальную информацию и ограниченный доступ к системе.
Почему мы выбрали Black Box для проверки облачной инфраструктуры Битрикс24
Для нас проверки на уязвимость — это не формальность, а жизненная необходимость. Мы постоянно играем в «белых хакеров». Не ждем проблем, а сами ищем дыры в безопасности, пока это не сделал кто‑то другой. Это касается всего:
Мы постоянно пробуем взломать наши сайты, API и сервера — именно так, как это делают настоящие злоумышленники.
Тестируем инфраструктуру изнутри. Особенно тщательно проверяем настройки сервисов в инфраструктуре. Часто проблемы возникают не из‑за багов, а потому что что‑то случайно оставили открытым, оставили конфигурацию не крайней версии. Мы смотрим: а туда ли ушли пароли? Тот ли доступ у этого сервиса? Нельзя ли из одного артефакта сделать другой?
Проверяем, что будет, если кто‑то уже внутри? Мы моделируем ситуацию, будто злоумышленник уже проник в систему. Сможет ли он там безнаказанно перемещаться? Это помогает выстроить внутреннюю защиту.
Как уже говорилось выше, black box пентест максимально приближен к реальным атакам — тестирование проводится так же, как действовал бы настоящий злоумышленник. Но для нас было важно оценить еще несколько моментов:
Облака чаще всего атакуют именно извне, а Black Box фокусируется на внешних уязвимостях. Такой подход помогает найти дыры в безопасности, которые могут использовать хакеры, даже если у них нет доступа к внутренним системам.
Этот метод позволяет оценить, насколько легко злоумышленник может добыть конфиденциальные данные, используя только открытые источники.
Тестировщик в black box не знает заранее, как устроена система, поэтому может найти уязвимости, которые могли бы пропустить при других методах проверки.
Как выбрать исполнителя?
Идеальный подрядчик для black box‑тестирования — это команда с опытом в нужной сфере, доказанными навыками взлома, чёткой методологией и хорошей репутацией. Поэтому лучше потратить время на выбор, чем получить формальный отчёт, который не улучшит безопасность. Мы выбирали исполнителя по следующим критериям:
Релевантный опыт. Для нас это доказанный опыт в нужной области: поиск OWASP Top 10 уязвимостей, логических ошибок, проблем авторизации; анализ мобильного приложения (анализ API, защита данных, reverse engineering); тестирование сетевой инфраструктуры (сканирование сетевых сервисов, проверка облачных конфигураций, эмуляция реальных атак).
Методология тестирования: подрядчик должен четко следовать процессу: разведка, моделирование атак, пост‑эксплуатация, анализ логики и документирование.
Сертификация и экспертиза. Наличие сертификатов конечно не гарантирует качество, но отсекает откровенно слабых специалистов. Для нас плюс, если специалисты имеют сертификации OSCP, CEH, PTES.
Репутация и отзывы. Тут помогут непубличные рекомендации от коллег, участие в bug bounty, участие в таких мероприятиях как Киберполигон или конференциях.
Как составить и утвердить ТЗ?
Специалисты по Offensive Security рекомендуют не создавать слишком подробных ТЗ. Белым хакерам достаточно получить от заказчика описание критичных бизнес‑процессов, нарушение которых повлечет серьезные последствия для бизнеса. При этом заказчику не стоит самому предполагать, какие элементы системы могут быть уязвимы. Понять, что может привести к катастрофе — задача хакера.
Опираясь на наш опыт, могу порекомендовать следующее тем, кто впервые обращается к «этичным хакерам»:
Составляя ТЗ для пентеста, учитывайте опыт подрядчика и его мнение.
Определите четкие границы тестирования, отметьте в ТЗ элементы системы, которые, не нужно трогать.
Обозначьте критические важные активы, безопасность и 100% доступность которых важна в первую очередь. Это могут быть базы данных с личными данных клиентов, финансовые системы или внутренние приложения.
Договоритесь о том, какие методы тестирования разрешены, а какие нет. Например, DDoS‑атаки могут привести к недоступности сервисов и серьезным последствиям для бизнеса. Убедитесь, что подрядчик осведомлен о этих ограничениях и готов их соблюдать.
Реализация пентеста
До начала тестирования нужно убедиться, что все системы ИБ работают в штатном режиме, а все компоненты инфраструктуры (серверы, базы данных, сети) доступны для тестирования. Создайте резервные копии всех критически важных данных и систем, чтобы можно было быстро восстановить их в случае непредвиденных проблем. Проверьте еще раз настройки системы мониторинга, чтобы отслеживать любые аномалии или проблемы во время тестирования. Также стоит проверить, что доступ к системам во время тестирования есть только у участников процесса.
Предупреждать ли сотрудников?
В первый раз лучше предупредить, чтобы избежать неконтролируемых последствий — сотрудники могут запаниковать и неверно отреагировать на возможные действия хакеров, что повлечет неконтролируемые последствия. Мы у себя обязательно предупреждаем всех причастных сотрудников.
Что стоит рассказать о предстоящем тестировании, помимо самого факта его проведения:
Если пентест может затронуть рабочие места специалистов или их данные, необходимо заручиться их согласием на проведение тестирования.
Обязательно проинформируйте сотрудников о том, какие проблемы или нештатные ситуации могут возникнуть и объясните, к кому нужно обращаться в этом случае.
Как контролировать качество выполнения работ
Работа хакера не похожа на задачи, которые требуют правок, согласований и регулярных обсуждений с командой. Планируя пентесты, мы задавались вопросом, стоит ли вмешиваться в работу подрядчика и как можно контролировать ее качество? С одной стороны, мы привыкли к прозрачности и хотим оперативно решать возникающие проблемы. С другой — вмешательство в процесс может только замедлить его.
В итоге остановились на компромиссном варианте — минимальное вмешательство в процесс и контроль ключевых этапов. Мы понимаем, насколько комфортно работать в доверии, поэтому договорились, что не будем постоянно дергать коллег, выясняя, насколько они продвинулись вперед. Но если будут найдены критические уязвимости, требующие оперативного вмешательства — нам сразу же сообщат об этом.
Оценивать работу пентестеров мы можем по следующим параметрам:
команда белых хакеров смогла оказаться в одном шаге до реализации недопустимых событий, то есть взлома тех систем, которые обозначил заказчик
результаты работы помогли защитить систему и предотвратить реализацию недопустимых событий реальными злоумышленниками.
Что делать с результатами
Если уязвимостей не обнаружено, то можно просто тщательно изучить отчет и ограничить доступ к нему — опять же из соображений кибербезопасности. Но чаще всего хакеры находят слабые места в защите, а значит, придется их закрывать.
Получая результаты пентестов, мы сразу же проводим встречу с командами разработки и DevSecOps, обсуждаем найденные уязвимости и рекомендации по их устранению. Найденные проблемы ранжируем по степени опасности, учитывая потенциальное воздействие и вероятность эксплуатации. Затем планируем, в какие сроки будем их исправлять. Начинаем, конечно же, с самых критичных.
Наша философия проста:
Мы не проводим разовые «проверки для галочки». Это непрерывный, регулярный процесс. Выкатили новую фичу — протестировали. Изменили конфигурацию — снова проверили.
Мы не полагаемся только на программы‑сканеры. Эксперты вручную ищут уязвимости, думают как преступники и проводят сложные многоходовые атаки.
Главная цель — не написать длинный отчет, а дать команде понятный план: «вот здесь артефакт, вот как от него избавиться».
Рекомендации тем, кто планирует пентест и хочет получить максимум от Offensive Security
Четко обозначьте, какие элементы ИТ‑инфраструктуры для вас критичны, какие системы необходимо защитить в первую очередь.
Решите, что именно нужно проверить: веб‑приложения, сеть или облачные сервисы.
Выберите проверенного подрядчика — посмотрите его опыт, отзывы и кейсы и используемые методы
Подготовьте инфраструктуру, убедитесь в работе всех ИБ‑систем, сделайте бэкапы критически важных систем и данных.
Объясните команде, что вы планируете провести тестирование безопасности
Обсудите с подрядчиком сроки, допустимые методы и элементы, которые не нужно тестировать.
Доверяйте подрядчику, не перегибайте палку с контролем процесса. Если будут найдены уязвимости, требующие немедленного реагирования, подрядчик сообщит об этом еще до конца теста.
Ограничьте доступ к результатам пентестов — это очень чувствительная информация.
