Всем привет! Меня зовут Геннадий Мухамедзянов, в ИТ я более 20 лет, половину из них ― в кибербезопасности. У меня богатый опыт работы в центрах мониторинга ИБ, где я занимался установкой и настройкой различных СЗИ, в том числе систем класса SIEM.
Импортозамещение в области кибербезопасности у всех на слуху: компании продолжают переходить на отечественные средства защиты. В статье я расскажу о тонкостях внедрения нового SIEM-решения в развернутый SOC и о том, как встроить его в существующие в организации процессы, чтобы замена предшественника прошла безболезненно. Чтобы добавить больше практической составляющей, буду рассматривать задачу на примере миграции на MaxPatrol SIEM ― систему выявления инцидентов ИБ российского вендора Positive Technologies.
Миграция с точки зрения контента
То, что я именую контентом, в Positive Technologies принято называть экспертизой. Это понятие включает в себя правила нормализации и корреляции, механизмы обогащения, табличные списки и макросы. Мигрируя на новое SIEM-решение, команде по миграции в первую очередь необходимо проанализировать контент, собранный предыдущей системой. Руководствуемся следующим алгоритмом действий:
Выявляем устаревшие и тестовые правила.
Они точно накопились за годы работы, но переносить их в новую систему — пустая трата времени и ресурсов.
Определяем типы правил и табличных списков.
Бывают как простые правила, направленные на выявление одного потенциально опасного события ИБ, так и сложные, связывающие события ИБ в цепочки. Аналитик должен самостоятельно задать приоритеты для правил.
Группируем контент по принципу 20/80.
Аналитик выбирает 20% контента замещаемой SIEM-системы, который покрывает 80% потребностей компании или клиентов (если вы предоставляете услуги по модели «безопасность как сервис»).
Работа с персонализированным контентом.
В некоторых случаях есть правила корреляции, которые разрабатывались под определенную задачу или под определенного заказчика. Вполне возможно, что такие правила тоже нужно перенести в новую SIEM-систему. Примером таких правил часто является контент threat hunting по поиску закономерностей или того, что позже может попасть в коробочный пакет экспертизы. Аналитики выделяют его отдельно и также расставляют приоритеты при миграции.
Работа с исключениями и профилированием.
Аналитики, привыкшие работать с одной SIEM-системой, выполняют профилирование в коде самих правил, что не всегда верно и удобно. Имейте в виду, что новое решение может не иметь такой функции, из-за чего часть контента для обнаружения киберугроз будет потеряна. Если в детектах ваших клиентов содержатся уникальные данные, советую закреплять их с помощью табличных списков.
Теперь разберем, как следует работать с методологией разработки контента и пакетов экспертизы. В методологии, как правило, закрепляются:
единый стиль написания контента, чтобы аналитики могли легко понять и обработать правила, составленные другими специалистами;
правила наименования сущностей;
шаблоны правил;
схема работы с исключениями;
кейсы использования макросов ― их, наряду с фильтрами, удобнее применять для запроса данных и формирования выборки. Макросы избавляют аналитиков от необходимости перерабатывать нормализацию.
После того как методология разработки подготовлена, специалисты по ИБ могут сгруппировать контент с соответствующими правилами в пакеты экспертизы, например сформировать пакет экспертизы по сетевой безопасности, пакеты для Windows или Linux. Чтобы эффективно противостоять современным киберугрозам, крайне важно актуализировать собранный контент и обновлять правила нормализации.
Затем необходимо синхронизировать модели данных. Некоторые SOC используют собственную модель данных, поэтому адаптируют к ней весь контент, разрабатываемый как для самого центра, так и для различных инструментов в его составе. При замещении SIEM-системы команде по миграции потребуется изучить маппинг полей для корректного переноса контента и запланировать время на доработку данных под принятую в SOC модель.
Для тестирования выбираются несколько пакетов экспертизы, чтобы специалисты заложили верную логику в новую SIEM-систему, проверили ее работу при эмуляции атаки и определили узкие места. Если в заменяемом решении срабатывание произошло, а в новом ― нет, нужно искать причину. Например, возможно, придется переработать устаревшую логику правил, а также плейбуки, если таковые разработаны для реагирования на инциденты в компании.
Переходим к актуализации контента. Эта задача включает в себя автоматизированное тестирование правил, версионирование контента, перенос обновлений в измененные формулы нормализации и подготовку пакета логов для тестов. Кроме того, очень важно запустить или модифицировать процесс актуализации, если он уже есть в компании. В некоторых случаях вендоры SIEM-решений могут менять структуру полей событий, внедрять более оптимальные модели написания кода. Все это нужно отслеживать и дорабатывать соответствующие регламенты и шаблоны написания контента.
Завершающий этап переноса контента из одной SIEM-системы в другую ― его тестирование. Специалисты по ИБ автоматизировано отправляют одни и те же события в различные SIEM-решения и на выходе должны получить идентичные инциденты в IRP. Этот этап показывает, что мы можем осуществлять полный переезд на новый продукт.
Миграция с точки зрения архитектуры
Если информационная безопасность обеспечивается по модели MSSP, то возможен гибридный вариант архитектуры, когда все данные из инфраструктуры клиента передаются в SIEM-систему. В свою очередь, провайдер подключается к ней с помощью интеграций, которые забирают нужные данные в системы SOC.
Другой вариант архитектуры ― облачный: у клиента установлены только коллекторы, собирающие данные для передачи в облачную SIEM-систему, с которой взаимодействуют специалисты MSSP-компании.
При настройке сетевых доступов потребуется создать матрицу с указанием IP-адресов, которые необходимо оставлять открытыми для работы файрволов и VPN. В SOC сосредоточено многообразие инструментов и решений: системы мониторинга, IRP и TI-платформы, клиентские порталы, службы резервного копирования, системы управления конфигурациями, например Ansible, и прочее. Чтобы «подружить» их с новым SIEM-решением, следует разработать механизмы интеграции.
На старте миграции контент в отечественную SIEM-систему, скорее всего, будет передаваться вручную и частями посредством Dev-сервера. Тем не менее желательно постепенно внедрять подход GitOps, позволяющий упаковывать небольшие блоки контента для каждого клиента, автоматизировано доставлять их ему и тестировать.
SIEM-система ― это живой организм. Чтобы мониторить ее «здоровье», необходимо отслеживать не только физические показатели (использование памяти, дисков, среднюю нагрузку на CPU), но и логические. К ним относится, например, срок действия лицензии, за которым бывает сложно уследить, когда у MSSP-провайдера много клиентов. Если говорить о конкретных случаях, то SIEM-система может уведомить оператора о невозможности записи определенного объема данных в табличный список либо о том, что правила срабатывают аномально часто. Эти и другие метрики, связанные с проблемами в работе решения, необходимо фиксировать, анализировать, и единая модель здоровья и мониторинга значительно упрощает задачу. Так, например, инструмент позволяет контролировать состояние компонентов и сущностей SIEM-решения, операционной системы, оборудования и источников событий.
Специалисты SOC, как правило, готовят отчеты для клиентов на основе данных, собираемых и анализируемых SIEM-системой. К ним могут относиться отчеты об инцидентах, отчеты threat hunting и т. п. Отчетность следует привести к единому формату. Так, клиенты всегда будут получать привычные документы, содержание которых остается неизменным вне зависимости от вендора SIEM-системы. Кроме того, формат отчетов необходимо время от времени актуализировать.
В заключение отвечу на самый популярный вопрос: сколько времени занимает переход с одной SIEM-системы на другую в существующем SOC. Идеальный вариант, когда все инженеры свободны, а аналитики готовы быстро переписать на новый синтаксис контент обнаружения и перестроить плейбуки, мы не рассматриваем, да? ?
Что ж, тогда представим ситуацию: специалисты SOC из общей совокупности в 5 тысяч правил уже выделили 3 тысячи, которые точно нужно перенести в новую SIEM-систему. Если в день аналитики будут «переводить» десять правил, то переход займет полгода. В случае сложных интеграций, а также при отсутствии возможности занять время разработчиков внутренних информационных систем или разработчиков вендоров миграция может завершиться через год или больше.