Омар Ганиев: По итогам Red Teaming нам всегда удавалось реализовать бизнес-риски

Red Teaming — актуальная и горячая тема, которую продолжают раскрывать российские эксперты по кибербезопасности. В гостях у редакции Anti-Malware.ru побывал «этичный хакер», исследователь и генеральный директор компании DeteAct Омар Ганиев. Представляем вашему вниманию его ответы на многие интересные вопросы.

Совсем недавно прошёл эфир AM Live по теме Red Teaming, но многие вопросы на нём не успели обсудить из-за недостатка времени. Поэтому хотелось бы продолжить и поговорить с вами о российской практике редтиминга. Прочно укрепилось мнение, что Red Teaming — это некий усовершенствованный анализ защищённости. Согласны ли вы с этим? С какими целями заказчики обращаются к вам в DeteAct?

Омар Ганиев: Под анализом защищённости обычно понимают вид оценки, цель которой — выявление максимального количества недостатков в системе.

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

В таком контексте важны не столько количество недостатков и охват всей системы проверками, сколько покрытие различных контролей: видит ли SOC попытки фишинга, факт преодоления сетевого периметра, вредоносное устройство, установленное в офисе? Как быстро реагирует служба ИБ, к каким данным и системам успевают получить доступ атакующие до того, как их нейтрализуют?

Есть более общий термин, который точнее раскрывает суть такого тестирования: Adversary Simulation, то есть симуляция действий противника. Противник может работать как независимо (Red Teaming), так и совместно с командой защитников (тогда это называется Purple Teaming).

Как Red Teaming помогает в настройке инструментов и тренировке специалистов по ИБ, в том числе в корпоративном SOC?

О. Г.: В рамках контролируемых пентестов, в ходе которых команда атакующих не пытается скрыть своё присутствие, а команда защиты проинформирована о совершаемых действиях и не пресекает их, оценка работы систем мониторинга получается менее информативной.

Например, сработало правило SIEM, но на него не отреагировали, потому что это пентест, а не реальный инцидент. Как узнать, смог ли бы SOC быстро расследовать инцидент и нейтрализовать атакующих, если бы это не было тестированием?

Или наоборот: SOC сработал, потому что знал, что идёт пентест, и внимательно отсматривал все срабатывания средств защиты, чтобы не оплошать. При этом они могут знать, с каких адресов и учётных записей работают пентестеры, и целенаправленно исследовать именно их действия.

Для отработки инцидентов в менее синтетической ситуации, для оценки реальной защищённости и киберустойчивости необходима симуляция, которая более приближена к реальным атакам. В этом и помогает Red Teaming.

Если у заказчика SOC на аутсорсинге, то Red Teaming им, наверное, не особо и нужен?

О. Г.: Аутсорсинг функции SOC не означает отсутствия функции по обеспечению ИБ у самого заказчика, поэтому такой формат тестирования всё равно может иметь смысл. Другое дело — как эффективнее его организовать, кого извещать, какие цели ставить перед собственной службой ИБ и перед SOC.

Понятно, что в таком случае у заказчика нет задачи обучать сотрудников SOC, который является сторонней организацией, но есть другие задачи.

Кто на практике в России заказывает Red Teaming? Сколько таких компаний и из каких они областей?

О. Г.: Границы того, что называется Red Teaming, несколько размыты, многие так называют обычный пентест.

В DeteAct мы видим, что заказчики обычно проходят промежуточные стадии: сначала они проводят обычные пентесты, затем переходят к пентестам без информирования SOC, затем ставят конкретные цели по бизнес-рискам (недопустимым событиям).

В конце концов они эволюционно приходят к полноценному редтимингу без жёстких ограничений по методам атак и по срокам. Понятно, что обычно такую услугу заказывают компании, которые уже давно занимаются ИБ, несколько лет проводили пентесты, у них есть SOC и понятный запрос от бизнеса.

При этом различные методы и практики Adversary Simulation и Red Teaming применимы и для менее зрелых организаций: можно, например, проверить работу ИБ в каком-то ограниченном контуре или провести Purple Teaming, при котором синяя и красная команды будут периодически обмениваться информацией, работая «спринтами» и корректируя методику и цели по ходу тестирования.

На эфире мы проводили опрос аудитории, где только 14 % ответили, что у них был опыт Red Teaming. Это много или мало? Как это соотносится с положением дел на зарубежных рынках?

О. Г.: По-моему, 14 % — это довольно много. Скорее всего, респонденты широко трактовали это понятие и причисляли к нему и пентесты в более традиционном понимании.

Сколько времени на вашей практике занимает средний проект Red Teaming? Каков рекорд по продолжительности, минимальный и максимальный?

О. Г.: При отсутствии вводной информации и доступов и при наличии противодействия со стороны ИБ атакующим необходимо гораздо больше времени на подготовку к атакам, приходится быть скрытными, что замедляет работу.

Мы в DeteAct обычно закладываем на подобные работы от трёх до восьми месяцев, но бывали и специфичные запросы: самое короткое тестирование в формате Red Teaming продолжалось две недели.

Сколько занимает подготовка и что в неё входит?

О. Г.: Она похожа на подготовку к любому пентесту: нужно провести разведку ресурсов компании, но в отличие от обычного внешнего пентеста в неё необходимо включать и изучение физических объектов компании, более детальное изучение сотрудников, сбор их контактных данных, а главное — изучение используемых средств защиты, вплоть до поиска информации о подрядчиках компании по ИБ.

Может ли быть непрерывный Red Teaming по аналогии с непрерывными тестированиями на проникновение и есть в этом какой-то смысл?

О. Г.: У любого пентеста есть этапы, у каждого из которых — свои цели. Таким образом, не совсем корректно говорить о непрерывном тестировании, но действительно можно проводить пентесты и учения Red Teaming подряд, ставя новые цели на очередной спринт.

Как исследователи выбирают векторы и инструменты атаки? От этого многое зависит. Можно ли на этом этапе минимизировать человеческий фактор?

О. Г.: В целом такой формат тестирования не подразумевает особых ограничений на векторы и инструменты, но при этом понятно, что у любой команды есть свои предпочтения и компетенции, что их ограничивает.

Имеет смысл в рамках подготовки обсудить с заказчиком, какие векторы для них наиболее интересны. Например, могут быть неинтересны физические векторы атаки.

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

Допустим, Red Teaming проведён. По каким параметрам заказчику оценивать его эффективность?

О. Г.: Можно выделить следующие метрики для оценки. Во-первых, охват различных векторов, тактик и техник: был ли фишинг, пентест веб-приложений, подбор паролей, рассылка вредоносных файлов, физическое проникновение, перехват Wi-Fi и так далее. Во-вторых, реализованные бизнес-риски и недопустимые события: каких из согласованных целей удалось достичь красной команде. В-третьих, эффективность SOC и синей команды: какую часть атаки удалось обнаружить, как быстро это было сделано.

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

Определив для каждого недопустимого события ценность актива и ущерб, сложность и длительность атаки, скорость реагирования SOC, можно получить общую оценку защищённости.

Популярно мнение, что Red Team должна быть внутри организации. Вы же предлагаете внешние услуги. В чём состоят плюсы и минусы этих конфигураций?

О. Г.: Обычно «непрерывный» формат работы присущ как раз внутренним красным командам, поскольку они гораздо глубже интегрированы в процессы компании. Непрерывный аутсорсинг Red Team достаточно дорогостоящ, поэтому немногие компании могут это себе позволить.

При этом по тем же причинам внутренняя команда не всегда может объективно оценить защищённость и беспристрастно симулировать действия атакующих: у них слишком много изначальных знаний об инфраструктуре и при этом ограничены собственные компетенции.

Для расширения подходов и для более объективной оценки как раз и нужны внешние команды — даже в случае, когда у компании есть собственная Red Team.

Как выбирать внешнюю Red Team? Как проверить людей, чтобы не получилось, что они будут работать «без огонька»?

О. Г.: Это — сложный вопрос, на рынке отсутствует объективная экспертиза. Многое будет понятно в рамках обсуждения подхода к проекту, также необходимо, чтобы у подрядчика была достаточно большая и компетентная команда, в которой есть специалисты как по атакам в сетевой инфраструктуре, так и по безопасности приложений.

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

Очень часто обсуждаются правовые риски от Red Teaming. Как «подстелить соломку» и не подпасть под статью УК за незаконное проникновение или использование вредоносных программ?

О. Г.: При описании целей и ограничений работ необходимо учесть: широкое толкование области тестирования может привести к тому, что будут затронуты сторонние организации или физлица, которые не давали согласия на тестирование. Поэтому необходимо заранее провести черту, которую нельзя пересекать без дополнительных согласований.

Например, если компания арендует офис в бизнес-центре, то в таком случае взлом СКУД для проникновения в здание незаконен, поскольку СКУД принадлежит собственнику здания, а не арендатору офиса.

Все особо чувствительные операции, такие как применение социальной инженерии, должны быть явным образом охвачены как договором, так и авторизационным письмом, которое можно предъявить в случае претензий от неинформированных лиц (полиция, охрана, сотрудники СБ).

Авторизационное письмо должно содержать контакты нескольких людей, которые могут подтвердить личность сотрудников подрядчика и законность их действий.

С другой стороны, некоторые заказчики опасаются утечки данных через исследователей. Как здесь минимизировать риски?

О. Г.: Этот страх — довольно суеверный, поскольку если исследователям удалось что-то «нарыть», то с тем же успехом это могло получиться и у реальных злоумышленников. Странно подозревать специалистов, которые официально трудоустроены и работают, не скрывая свою личность, в том, что они потом этим воспользуются. В их интересах скорее не допустить каких-либо утечек, чтобы подозрения не пали на них.

Мы в DeteAct, конечно же, тоже минимизируем риски, регламентируя внутреннюю работу команды: например, без прямой на то необходимости не копируем никакие данные заказчиков на свои устройства. Если необходимость есть (например, нужно скачать документ для дальнейшего анализа), применяем меры по защите этих данных, а после завершения работ всё уничтожаем.

Омар, большое спасибо за беседу! Желаю успехов.