Привет! Снова подготовили для вас материал от Романа Стрельникова, руководителя направления по информационной безопасности 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
Четко обозначьте, какие элементы ИТ-инфраструктуры для вас критичны, какие системы необходимо защитить в первую очередь.
Решите, что именно нужно проверить: веб-приложения, сеть или облачные сервисы.
Выберите проверенного подрядчика — посмотрите его опыт, отзывы и кейсы и используемые методы
Подготовьте инфраструктуру, убедитесь в работе всех ИБ-систем, сделайте бэкапы критически важных систем и данных.
Объясните команде, что вы планируете провести тестирование безопасности
Обсудите с подрядчиком сроки, допустимые методы и элементы, которые не нужно тестировать.
Доверяйте подрядчику, не перегибайте палку с контролем процесса. Если будут найдены уязвимости, требующие немедленного реагирования, подрядчик сообщит об этом еще до конца теста.
Ограничьте доступ к результатам пентестов — это очень чувствительная информация.