Вот прочитали вы мой обзор эфира AM Live по оснащению SOCов после 24-го февраля, посмотрели саму запись, и приняли решение о миграции некоторых (а может и всех) компонентов своего SOC на рельсы из «дружественных материалов», которые не будут подвержены санкционным рискам. Смена даже одного только SIEM — это задача непростая и даже стратегическая, а посему напортачить в ее реализации можно очень легко, что приведет не только к потере денег, но и к снижению уровня защищенности своей компании. Мне довелось участвовать в некоторых проектах, в которых надо было либо спроектировать SOC на чисто российских решениях (та еще задачка, скажу я вам), либо предусмотреть миграцию с решений одной компании на другую. Поэтому я бы хотел вкратце описать ряд моментов, на которые надо обратить свое внимание, если вы все-таки решитесь (или вас заставляют) двинуться в этот непростой путь.
Шаг 0. Нахрена это все?
Если честно, переходить на другой софт только по причине его «некошерности», — не самая лучшая и правильная мотивация. И, как показал эфир AM Live , аутсорсинговые SOC это прекрасно понимают. Патриотизм патриотизмом, но сервис надо оказывать на высоком уровне, а это подразумевает определенные требования к применяемым решениям. Но жизнь есть жизнь и кого-то вынудят сменить SIEM, IRP, SOAR, TIP, коммуникационную платформу, базу знаний, используемые сейчас в SOC, на что-то другое. Логично, предположить, что это будут решения отечественные, тем более, что они вроде как и есть . Однако, помимо импортозамещения вы можете захотеть поменять вендора, который перестал вас устраивать по цене, функциональности, качеству техподдержки, планам развития и т.п. При вынужденной миграции лучше все-таки добавить и еще какую-нибудь, более правильную причину, к которой и стремиться и достижение которой измерять в конце.
Шаг 1. Оценка текущего состояния вашего инструмента
Речь, конечно, не о том инструменте, о котором подумала часть читателей (девушки, простите). Речь идет о SIEM/SOAR/IRP/TIP или что там вы еще мигрируете. Текущие источники телеметрии, покрываемые устройства, сценарии использования (use cases), имеющиеся правила и цепочки правил, текущие варианты визуализации (дашборды и отчеты), сценарии автоматизации реагирования, сценарии тикетинга… Вот тот минимум, который вам нужно будет собрать, например, для вашего «старого» SIEM. На этом же этапе вы можете захотеть пересмотреть свои исходные условия и от чего-то отказаться (например, от устаревших или неактуальных use cases) или, наоборот, установить новые требования (например, новые источники телеметрии или новые сценарии мониторинга).
Помимо ответа на вопрос «Как вы будете использовать новый инструмент?», вам придется ответить также на следующие вопросы:
- Какой масштаб нового внедрения? Будет ли мониториться та же область покрытия, что и раньше, или появятся новые фрагменты (от ответа на этот вопрос будет зависеть в том числе и хранилище для нового решения)?
- Предполагается мониторинг только себя или дочерних предприятий тоже (для холдинговых структур), что потребует от выбираемого решения поддержки multitenant-архитектуры?
- Хотите ли вы автоматически реагировать на инциденты или нет?
Шаг 2. Приоритизация источников телеметрии и TI
Вы не сможете переехать на новый SIEM одномоментно. Поэтому вы будете подключать к новому SIEM свои имеющиеся источники данных для анализа постепенно, а это подразумевает наличие списка таких источников, ранжированных по важности. Этот же список станет для вас точкой отсчета при общении с разработчиком SIEM, если у него сейчас каких-то коннекторов нет или он не поддерживает какие-то имевшиеся ранее источники или используемые им способы форвардинга телеметрии и данных Threat Intelligence.
Кстати, при составлении перечня используемых сейчас источников стоит посмотреть на него критически, — возможно, от каких-то из них пора отказаться ввиду отсутствия в них ценной информации или их несоответствия вашим сценариям. Помочь в этом может такой инструмент как DeTT&CT (Detect Tactics, Techniques & Combat Threats), который позволяет оценить не только покрытие логами TTP из ваших сценариев, но и их качество, а также возможности по использованию их для обнаружения угроз.
Нередко при миграции, когда вы определяете для себя новые сценарии, может оказаться, что нужные для них логи не были подключены к вашему SIEM и это придется учесть — выбрав новые источники, оценив места их расположения, длительность хранения, способы доступа к ним и форвардинга данных из них. А учитывая, что для SIEM один из ключевых вопросов — это размер хранилища, то этот вопрос надо будет проработать серьезно. Если предыдущие этапы занимают от 2-х до 4-х недель, то оценка источников телеметрии и их приоритизация может занять от 4-х недель до 8-ми.
Шаг 3. Маппинг возможностей старого и нового инструмента
Если ваш текущий SIEM — это просто анализ статических логов, а новое решение позволит вам анализировать еще и сетевой трафик, а также поведение пользователей, то это повод задуматься о расширении списка сценариев (может вы фрод захотите ловить, мониторить безопасность облаков или настроить автоматическое блокирование атакующих адрес), а также заложить время и ресурсы на обучение персонала новым фокусам. Кроме того, новое решение может по-другому работать с источниками событий ИБ и, соответственно, более (ну или менее) эффективно реализовывать ваши сценарии, что тоже должно быть учтено при миграции. На этот этап у вас уйдет пару недель для одного-двух продуктов и до четырех-шести для большего числа.
Шаг 4. Подготовка инфраструктуры
Возможно, новый SIEM или новые требования к нему потребуют от вас подготовить/модернизировать инфраструктуру, что будет заключаться как в настройке новых портов на МСЭ и новых ACL на сетевом оборудовании, так и в размещении новых компонентов SIEM (например, брокера для сбора, нормализации и сжатия событий для отправки их с удаленных площадок на головной SIEM или вторичного сервера управления для работы в модели гибридного SOC). Также может понадобиться учесть интеграцию с имеющимися сенсорами (если у SIEM иной способ форвардинга событий) или другими компонентами SOC. Особенно важен этот шаг, если вы уходите с облачного SIEM (например, Azure Sentinel) на решение on-prem или наоборот (в последнем случае вам понадобится Интернет-канал получше). Хорошей практикой будет ориентация на карту информационных потоков, которая была составлена на первом шаге.
Шаг 5. Взаимодействие с другими командами
Чтобы миграция прошло безболезненно, необходимо заручиться поддержкой ИТ, юристов (например, если вы будете мониторить поведение сотрудников), закуперов (будет неприятно узнать, что запланированные вами сервера и СХД нельзя купить или срок закупки выходит за рамки утвержденного вами проекта), а также аутсорсеров, если вы планируете пользоваться их услугами и вам надо будет настраивать передачу данных во внешние SOCи, NFT/EFT/TH-компании, а также подключать SOC к TI-источникам или государственным CERTам.
Шаг 6. Обучение
Ну тут вроде все понятно — те, кто будет мигрировать ваш SOC, и те, кто его будет эксплуатировать, должны быть обучены. Если саму миграцию для вас делает кто-то, то обучение должны пройти только аналитики (правила и запросы-то должен кто-то писать). Если вы уходите в аутсорсинговый SOC, то вам может не понадобиться и оно. Хотя иметь SOC (пусть и внешний) и не иметь обученных людей, понимающих как все устроено и как все контролировать, — это нонсенс.
Шаг 7. Подключение и настройка источников телеметрии
Теперь наступает время для начала миграции, которая начинается с подключения логов к новым инструментам SOC. Может показаться, что задача это несложная, но это не так. Во-первых, новый SIEM/XDR может по-другому работать с источниками событий. Во-вторых, вы можете захотеть подключить новые данные и тогда вам нужно будет распарсить их перед подключением к SIEM. Кто-то из вендоров утверждает, что у них есть универсальный коннектор (это замануха), кто-то готов вам распарсить ваши логи бесплатно, кто-то за деньги и за пару-тройку дней, а кто-то готов это сделать за месяц-другой. Есть и те, кто будет настаивать, что это ваша зона ответственности.
После этого, вы сможете уже начать подключать все источники, предварительно договорившись об этом с соответствующими командами, и имея необходимые вычислительные мощности для индексирования данных, их обработки, а также хранения (холодного, теплого и горячего). Если же вы будете использовать облачные инструменты или аутсорсинговый SOC, то учтите вопрос лицензирования — у ряда вендоров дополнительные объемы хранения лицензируются отдельно и это недешевое удовольствие.
Выполняя этот шаг, не забудьте, что он не только один из самых длительных (от двух до шести месяцев), но и может потребовать от вас передачи логов сразу в два конца — в новый и старый SIEM/XDR, а это надо будет отдельно настраивать.
Шаг 8. Подключение средств защиты, реагирования и обогащения
За источниками телеметрии надо будет подключать новые же (если речь идет об импортозамещении) SOAR, IRP, TIP, систему коммуникаций, базу знаний и другие компоненты. Если вам раньше повезло и у вас все эти компоненты были забугорные (например, Splunk, Phantom, Anomali, Webex, Confluence), то теперь вам придется выбирать все заново и для каждого компонента проверять его взаимодействие друг с другом. Тут, к сожалению, оценить время сложно, но я бы не рассчитывал на срок менее 4 недель в минимально мигрируемом сценарии.
Шаг 9. Перенос правил, кастомных настроек, инцидентов, переписывание контента и т.п.
Этот этап вроде понятен, но он и самый сложный в реализации, так как формат и язык описания правил корреляции и их цепочек, детектов, запросов, фильтров, исключений и т.п. в разных решениях могут быть разными. А это означает, что вам надо их переписать, протестировать, задеплоить, опять протестировать. Знакомая последовательность? Не случайно сейчас в области обнаружения угроз набирает популярность концепция Detection-as-a-Code, когда вы применяете стандартные CI/CD-практики к контенту обнаружения. При наличии сотен и тысяч правил этот этап может занимать достаточно длительное время. Особенно, если новые инструменты используют не просто анализ логов, а могут задействовать различные статистические механизмы для анализа поведения или даже модели машинного обучения. На первом этапе миграции баловаться с такими продвинутыми NG-возможностями не стоит — лучше рассматривать новые решения как MVP и включать новые функции последовательно, а не все разом.
Тоже самое касается переноса карточек инцидентов из старой системы IRP в новую, переписывание скриптов для автоматизации реагирования на инциденты, подключить новые источники Threat Intelligence, разработки шаблонов отчетов и дашбордов и т.п. Вообще, вопрос переноса старых логов SIEM и карточек инцидентов в новое решение не имеет однозначного ответа. Тут вам придется взвесить все за и против и оценить затраты на миграцию старых данных, которые может быть и не так уже важны и нужны (если нет регуляторных ограничений по хранению информации в течение 3-5 лет). Но даже если вам нужны старые события безопасности, то проще использовать старый SIEM как коллектор логов или использовать под это дело отдельное решение класса log management (можно и open source). Это обойдется дешевле, чем пытаться переносить данные из SIEM А в SIEM B, бросив на это силы своих аналитиков/инженеров или заплатив внешним консультантам с почасовой оплатой.
На этом этапе, длящемся от двух недель до 4 месяцев, вы должны ответить себе на следующие вопросы. «Кто будет переносить контент обнаружения и остальные элементы?». Если вы сами, то есть ли у вас такой опыт? Если нет, то готов ли это сделать производитель новых инструментов, которые вы выбрали? Если нет, то есть ли на рынке кто-то, кто это будет делать за вас? Если нет, то не зашли ли вы в тупик?
Вообще, термин «миграция правил» или «миграция контента обнаружения» не очень удачный, так как вы ничего не мигрируете, а переписываете заново, беря прежние правила за основу. Неплохо было бы для отечественных инструментов SOC иметь нечто, похожее на бесплатный сервис uncoder.io, который умеет конвертировать правила между различными решениями SIEM, EDR, NDR.
В идеале хотелось бы иметь инструменты типа SOC Prime или Picus Security, которые имеют либо встроенные базы контента обнаружения, адаптированные под разные платформы, либо транслировать их из Sigma или Yara в форматы популярных SIEM. И хотя это не панацея, но и такого у нас, увы, пока нет, и не факт, что для нашего небольшого рынка такое вообще появится.
Шаг 10. Реинжиниринг процессов, плейбуков и т.п.
Смена инструментария может поставить перед вами и еще один вопрос — о возможном реинжиниринге процессов SOC под новые решения. Например, раньше у вас были отдельные решения для анализа событий, для ведения базы инцидентов и для оркестрации, а новое решение объединяет все в одном. Очевидно, что за этим может последовать и переделка playbook и runbook, что может занять достаточное время. Кроме того, если вы раньше реализовали процесс оценки эффективности и измеряли временные параметры по работе аналитиков с SIEM/IRP/SOAR, то с новыми инструментами длительность операций вероятно поменяется (как в лучшую, так и в худшую сторону) и это надо будет учесть. Этот этап может занять от 2 недель до 4 месяцев в зависимости от глубины реинжиринга.
Шаг 11. Передача знаний
У нас все консалтинговые и внедренческие проекты, включая и проекты по SOC, всегда завершались сессией передачи знаний, в рамках которой эксперты, внедрявшие то или иное решение, делились своим опытом с новой командой. В случае с SOC это особенно важно, чтобы аналитики смогли оперативно включиться в работу с новыми решениями, по которым у них еще нет опыта. В ряде случае можно даже киберучения на 3-5 дней провести, но это уже зависит от наличия бюджета на данную услугу. В идеальном случае вам понадобиться еще и на обучение отправить аналитиков и инженеров, поддерживающих платформу, пишущих контент обнаружения и т.п.
Шаг 12. Распараллеливание работы старых и новых инструментов
Вероятность того, что вы с первого раза запустите без ошибок и проблем новые инструменты невысока. Поэтому ваш старый SIEM должен продолжать работать, резервируя новое решение и подхватывая сложные случаи, которые лучше отрабатывать на проверенной платформе, к которой ваши аналитики привыкли.
Это означает, что лицензии на ваши предыдущие SIEM/IRP/SOAR/TIP и т.п. не должны заканчиваться на моменте начала действия лицензий на новые инструменты. У вас будет перекрытие по срокам и оно может быть достаточно длительным — до полугода, а то и больше. Поэтому готовьтесь платить в определенный интервал времени в 1,5-2 раза больше, чем до и после миграции.
Шаг 13. Оценка миграции
Миграция не завершается, когда новый продукт(ы) внедрен. Вам надо проверить, что вы сделали все правильно. И тут все очевидно — вы запускаете решения класса BAS, собственные скрипты для эмуляции атак, приглашаете пентестеров или Red Team, которые подтверждают (или опровергают) способность вашего нового SOCа обнаруживать то, с чем прекрасно справлялся старый. В план тестирования нового SOCа стоит включить проверку новых сценариев, источников данных, правил, детектов, которые вы добавили в процессе миграции и которых не было ранее.
Помимо тестирования функций обнаружения, вам также может понадобиться оценить и другие параметры нового SOC — скорость обнаружения, скорость реагирования (вплоть до каждого этапа ваших workflow), возможности по реагированию и оркестрации, качество собираемой информации, интеграцию с ГосСОПКОЙ, Тема оценки эффективности SOC вообще непростая и потратить на нее придется от двух до четырех недель.
Шаг 14. Расширение возможностей нового SOC
А вот теперь, когда MVP-стадию вы прошли (не забыв все документировать), вы можете реализовывать новые сценарии, писать новые правила, проектировать новые дашборды, создавать новые скрипты реагирования, моделировать новые workflow в SOAR, подключать новые источники событий и новые объекты для мониторинга (контейнеры, виртуалки, мобильные устройства, удаленные рабочие места, облачные инстансы и тд.), внедрять машинное обучение и т.п. Но это уже не совсем миграция — это новая жизнь с новым SOCом.
Вообще, все описанное выше вам должен предложить сделать вендор нового инструментария SOC, у которого должен быть (должен появиться?) сервис по миграции. У него есть такая услуга?
Итак, подводя итоги, во сколько времени выльется вам процесс миграции? Минимально получается вот такая картина:
То есть для небольшого проекта по миграции только одного из компонентов SOC (например, SIEM) срок составить до 5 месяцев. При увеличении сложности проекта и росте числа мигрируемых компонентов возрастет и срок — обычно до 12-18 месяцев. Так что процедура это совсем небыстрая. Я вообще считаю, что иногда проще построить SOC с нуля, чем провести миграцию старого центра мониторинга на новый. Но в нынешних условиях это роскошь для многих.
Заметка
Как мигрировать с иностранных решений в SOC на отечественные? была впервые опубликована на Бизнес без опасности .
