Идея этого материала была у меня давно, ещё в 2021 году, когда я впервые попал на Standoff, и тогда я даже записал интервью с представителем Positive Technologies, но в итоге не получилось, потому что звук оказался очень плохим, даже с диктофона. Поэтому по прошествии четырёх лет я решил сделать серию материалов про киберполигоны. Я думал, материал получится в стиле NGFW, где у всех компаний есть типовые решения, отличия только в удобстве собственного ПО на железках, вендорах самого железа и интеграции с собственными разработками (у компании A интеграция в первую очередь с её ПО, у компании B — с её и так далее). Но киберполигоны меня удивили. Возможно, тех, кто прочитает всю серию интервью, и нет, но я тоже не ИБ-специалист с 50-летним стажем, и есть чему удивляться.
Итак, встречайте мой разговор с руководителем киберполигона и центра развития навыков компании Innostage Дмитрием Матвеевым. Мы поговорили о киберполигоне Innostage, его особенностях и том, нужно ли заказчику обосновывать затраты на разворачивание киберполигона внутри инфраструктуры. Приятного чтения!
Сколько полигонов у компании Innostage: один или несколько? Или у вас есть один основной, который вы копируете и разворачиваете под разные задачи?
У нас киберполигон один. Это единая сущность, которую мы дополняем и развиваем. В рамках этого киберполигона мы создаем отдельные сущности: курсы, практические материалы и так далее. Под каждый курс и каждый материал мы дополняем инфраструктуру.
А как вообще выглядит у вас киберполигон? Это программно-аппаратный комплекс или чисто программный? Или это зависит от бюджета заказчика? Лучше расскажи про ваш основной киберполигон — сколько он существует, зачем вы его создали, какие были этапы развития?
Расскажу поэтапно. У нас был определённый бэкграунд — например, у компании Positive Technologies есть Standoff, на базе которого они построили свою историю. Мы пошли другим путем. Мы три года подряд были глобальным SOC-ом на стенд-офе, участвовали в шести мероприятиях, имели опыт и как участники, и как организаторы. У нас есть собственный SOC. И мы решили, что хотим переложить этот опыт в обучение людей. Так появилась идея нашего киберполигона.
Киберполигон появился в 2022 году. Сначала это был внутренний мини-стартап — просто идея, которую развивали энтузиасты. Сейчас это уже полноценный сервис. Мы обросли командой, можем многое делать самостоятельно. Мы, например, полностью пишем свою платформу с нуля, дорабатываем её под себя.
С точки зрения среды — у нас почти всё завёрнуто в виртуальную инфраструктуру. Это не программно-аппаратный комплекс, а полностью виртуализированное решение. Мы делаем всё кастомно. То, с чем мы пришли как новые игроки, — это сильная backend-история: автоматизация, современные технологии вроде Terraform, Ansible. Мы можем выполнять множество атомарных действий так, как это происходит в реальных условиях.
Но есть и физическая часть. Например, если нужно собирать сигналы не только с контроллера, но и с внешних датчиков — это виртуально сделать сложно или невозможно. То же самое касается некоторых сетевых устройств. Поэтому определённые вещи мы делаем в «железе» отдельно.
Ты упомянул автоматизацию. Какие инструменты вы используете, например, для анализа логов и корреляции событий во время учений?
Мы не сильно фокусируемся именно на корреляции, потому что она может упростить задачу. Не у всех заказчиков есть полноценные решения для корреляции, и мы делаем упор на обучение через «сырые» события — чтобы человек сам искал инцидент по логике. Лучше научиться так, чем надеяться на автоматизацию.
У нас автоматизирован сбор логов, добавление новых источников, работаем активно с Ansible. У нас большой контент по настройке источников. Также используем Greylog, Kafka — всё централизованно, смотрим, откуда идут или перестают идти события, и всё это стекается в СЗИ.
Отличие нашего подхода — мультивендорность. У нас на полигоне сейчас 5 SIEM‑систем, как open source, так и коммерческие. И мы сделали так, чтобы логика приходила в нужном формате в каждую из них. Это тоже всё автоматизировано.
То есть и распределённые атаки, условные ботнеты — это тоже вы моделируете? Как, если у заказчика ограниченные ресурсы?
Тут два пути. Можно просто взять заранее сгенерированный трафик и «подсунуть» его — самый простой способ. Но мы пошли дальше. У нас всё в одной инфраструктуре, мы умеем работать с Kubernetes, можем поднимать много легковесных контейнеров с агентами, которые генерируют нужный трафик. Они могут «жить» в рамках конкретной атаки и потом выключаться — это не нагружает систему постоянно.
Мы моделируем как внешний ботнет, так и внутренний. Например, заражённые внутренние устройства, атакующие DNS или домены. Используем сетевые утилиты, Metasploit и прочее, чтобы заражение выглядело реалистично и с него шел нужный трафик.
Всё делаете на одной платформе. А когда приходите к заказчику, вы разворачиваете её у них или как?
Нет, у нас в этом плане подход другой. Мы не разворачиваем киберполигон на стороне заказчика. Мы либо работаем с их цифровым двойником, если он у них есть, либо добавляем необходимые сегменты в наш собственный киберполигон. За счёт этого мы расширяем текущую инфраструктуру, оставаясь в рамках одного полигона.
А как вы моделируете реалистичный трафик? Какие методы используете?
Всё самописное У нас есть отдельная группа в рамках SOC‑а по сетевой аналитике и группа пентестеров. Вместе мы разрабатываем своё ПО для генерации трафика. Это как «обычный» трафик, так и трафик инцидентов, основанный на реальных кейсах.
А были ли у вас какие-то механизмы защиты, условно, что кто-то попадает внутрь, и вы вырубаете всё рубильником?
Пока что нет, но мы над этим работаем. Сейчас основной фокус на реагировании и восстановлении после атаки. Мы хотим внедрить кейсы, где можно будет «выключить» инфраструктуру в рамках сценария — именно как часть защиты. Ну и просто для фана сделать, чтобы пользователям всплывали сообщения вроде «система умирает, всем домой», такие игровые элементы.
Еще одна идея, над которой мы думаем — развитие взаимодействия с внешними комьюнити: пентестерами, коммерческими SOC-ами, с которыми мы дружим. Хотим создавать кейсы на базе реальных систем заказчика и давать их на анализ этим специалистам. Так можно находить не только очевидные уязвимости, но и те, которые спрятаны глубже. Это позволит делать наш полигон максимально насыщенным и полезным.
Заключение
Вот такой получился у нас разговор с Дмитрием Матвеевым. Это первый материал из серии о киберполигонах, будет ещё несколько материалов от различных ИБ-компаний об их киберполигонах. Так что потом можно будет сравнить подходы нескольких компаний к созданию полигонов для испытаний инфраструктуры и ИБ-специалистов.
Это мой не первый шаг в изучении мира киберучений, но он основательный. Кстати, как и в случае с IT-отраслью, в ИБ ландшафт решений стремительно меняется. Да, с одной стороны, всё тягуче и долго, а с другой — в 2021 году был самый распиаренный киберполигон Standoff, а теперь уже у других компаний есть свои площадки для киберучений. Вроде недавно, 2–3 года назад, было 2–3 вендора, создающие NGFW, а теперь у каждой уважающей себя компании свой Next Generation FireWall. Да, понятно, что в эти 2–3 года произошло много глобальных мировых событий, но такого экспоненциального роста я не ожидал.
По итогам моей серии материалов можно будет сравнить, что лучше: моновендорность или мультивендорность, что лучше: программно‑аппаратный комплекс или только программное решение. Хотя, на мой взгляд, в остальных полигонах вряд ли будет моновендорность, но посмотрим. Кстати, существует и другой подход к киберполигону.
Кроме того, будет ответвление в рамках этой серии материалов (как спин‑офф в кино и комиксах), например, интервью, где было начало про площадку для киберучений, но разговор пошёл у нас в другое русло, или рассказ про другой подход к испытаниям в кибербезопасности. Спасибо за прочтение!
