Сегодня расскажу, как мы полтора года строили систему мониторинга информационной безопасности для одного из крупнейших медиахолдингов России. Это будет история о долгом и масштабном проекте, по итогам которого наша команда прокачала навыки инжиниринга и кардинально пересмотрела подход по внедрению SIEM и развертыванию SOC.
Представьте себе организацию с десятками разнородных цифровых активов, где каждое подразделение автономно управляет своей IT-инфраструктурой, что осложняет контроль безопасности.
Мы взялись за сложнейшую задачу — создать систему мониторинга, которая сможет объединить разрозненные инфраструктуры в единую управляемую экосистему. И как вы уже понимаете, решениями со Stack Overflow в данном случае не обойтись.
К нам обратился Холдинг «Газпром-Медиа» с просьбой построить единую точку контроля и централизованного отслеживания событий информационной безопасности. Внедрение комплексного решения позволило бы повысить скорость реагирования на инциденты и эффективность работы ИБ-службы.
Нам поручили разработать механизм сбора и корреляции событий безопасности для всего холдинга, развернуть комплексную систему мониторинга информационной безопасности и создать SOC-центр для Холдинга «Газпром-Медиа».
Подготовка к проекту: команда и ресурсы
Итак, у нас было 5 архитекторов, несколько десятков человек из команды SOC, 5 инженеров и три спеца из команды оперативного реагирования на инциденты и целое множество инфраструктур всех сортов и расцветок, а также серьезная поддержка со стороны Холдинга «Газпром-Медиа». К проекту подключились специалисты ключевых ИБ-подразделений заказчика: архитекторы, инженеры эксплуатации, команда реагирования на инциденты и эксперты по оценке защищенности. Но, несмотря на внушительный список компетенций, фактически над проектом работала совсем небольшая команда — по крайней мере, для такой сложной инфраструктуры.
Особенности инфраструктуры Холдинга «Газпром-Медиа»
Выбор системы мониторинга напрямую зависит от особенностей инфраструктуры заказчика, поэтому обследование и подбор решений обычно идут параллельно и как бы рутинно. В общем, у нас был план, и мы его придерживались, но реальность внесла свои коррективы.
Мы ожидали, что это будет стандартное внедрение SIEM-системы, просто для большой инфраструктуры. В таких случаях мы тщательно собираем базовую информацию об IT-активах компании: анализируем устройство сетей, изучаем специфику центров обработки данных, разбираемся в особенностях функционирования систем и сервисов. Это позволяет сформировать полное представление об IT-ландшафте, подобрать оптимальное решение и приступить к внедрению.
Мы начали с нескольких крупных активов, которые были наиболее подвержены угрозам информационной безопасности. Детально обследовав их, мы предположили, что остальные активы будут примерно такими же. Когда мы добрались до следующего актива холдинга, оказалось, что его IT-ландшафт отличается так же сильно, как Python от Assembler. Казалось бы, настроить две конфигурации SIEM-системы — задача решаемая. Но мы посмотрели на третий актив, и перед нами снова предстала совершенно уникальная инфраструктура. Стало очевидно: IT-ландшафт заказчика не просто разнороден, а напоминает набор параллельных вселенных.
Нам предстояло объединить множество разнородных инфраструктур под единым решением. Это означало внедрение общих политик, правил корреляции и универсального подхода к мониторингу. Решение должно было адаптироваться к любой площадке, независимо от способа подачи логов, особенностей конфигурации или специфики каналов связи. И все это — при сохранении централизованного управления с нашей стороны.
Мультитенантность — наше все
Как сделать так, чтобы SIEM и все данные были на стороне заказчика, а сервис SOC — на стороне исполнителя? Нужно решение, которое позволит реализовать полноценный гибридный SOC с зонтичным мониторингом нескольких обособленных инфраструктур. Для проекта требовалась надежная и отказоустойчивая SIEM-система, способная работать в территориально-распределенном режиме с четким разграничением доступа к данным между активами холдинга.
Раньше рынок SIEM-систем напоминал супермаркет перед праздниками: здесь и open-source решения, и коммерческие продукты вроде ArcSight и Qradar. Однако импортозамещение и риски прекращения вендорской поддержки сузили круг поисков до размеров игольного ушка. Разработка собственной SIEM-системы на базе open source выглядела заманчиво, но не вписывалась ни в бюджет, ни в сроки проекта. Пришлось сфокусироваться на российских коробочных решениях
Оказалось, что большинство отечественных вендоров пока не готовы к работе в настолько разнородной инфраструктуре. Анализ рынка привел нас к фактически единственному подходящему решению — SIEM Kaspersky KUMA.
Основным преимуществом платформы для нас стала мультитенантность — технология, позволяющая разделять инсталляции на независимые среды и объединять их в общую экосистему мониторинга.
С точки зрения архитектуры классическая SIEM-система состоит из четырех ключевых компонентов:
Ядро, обеспечивающее управление и координацию всех процессов SIEM.
Коллектор, который принимает события безопасности из разных источников и приводит к единому формату.
Коррелятор — сервер, который обрабатывает события. Устанавливает взаимосвязи между событиями и выявляет инциденты или подозрения на них.
Хранилище для событий безопасности и результатов работы коррелятора. Сохраняет инциденты в нормализованном виде.
Мультитенантность позволяет создавать из этих компонентов сложные иерархические структуры и тонко настроить взаимодействие между инсталляциями на разных площадках.
В итоге каждый актив Холдинга получил собственный полнофункциональный форк SIEM-системы, интегрированный в общую инфраструктуру. Каждый конкретный оператор видит только события своего форка, а централизованный SOC получает доступ к событиям со всех площадок.
Если канал связи с центральным SOC вдруг решит уйти на внеплановый перерыв, мониторинг продолжит работать, а данные никуда не денутся — они накапливаются и обрабатываются в локальном тенанте. Настройки SIEM при этом можно варьировать для каждой площадки индивидуально: хранить разные типы событий, с разной глубиной и в разных местах.
Теоретически подобную схему можно реализовать и на других российских продуктах, но мы не стали изобретать велосипед. В KUMA эта функция работает сразу из коробки, вот только мы, похоже, стали первыми, кто решился использовать ее на полную мощность. Как говорится, кто-то должен был это сделать.
Архитектура решения: трехуровневая структура мониторинга
В итоге мы разработали трехуровневую структуру, где центральный сегмент обеспечивает прием и хранение событий в том активе, на инфраструктуре которого он расположен, а также отвечает за управление всей системой и целой плеядой подчиненных сегментов двух типов.
К первому типу относятся крупные активы холдинга с развитой ИТ-инфраструктурой, генерирующей от 10 тысяч событий в секунду (EPS). Ко второму типу относятся активы поменьше.
Такой подход обеспечивает несколько серьезных преимуществ:
При подключении крупных активов Холдинга «Газпром-Медиа» и развертывании новых сегментов не нужно пересылать исходные ненормализованные события в центральный сегмент. Мы распределяем нагрузку, децентрализуем накопление и корреляцию событий и благодаря этому увеличиваем производительность поиска и обработки событий в целом по холдингу.
Подключение сегментов второго типа обходится дешевле: можно не разворачивать полную инсталляцию системы, а ограничиться компонентами, которые отвечают за сбор событий. Хотя при этом поток событий в малых сегментах зависит от каналов связи, использование кеша коллекторов позволяет некоторое время накапливать данные для пересылки после восстановления связи.
Особенно приятно, что KUMA лицензируется по объему обрабатываемой информации, а не по количеству инфраструктурных элементов. В системе можно создавать столько коллекторов, корреляторов и хранилищ данных, сколько душе угодно. Единственным реальным ограничением выступает общая нагрузка на компоненты системы. Такой подход обеспечивает исключительную гибкость в проектировании архитектуры, сравнимую разве что с конструктором LEGO.
Тестирование KUMA
Мы начали с создания тестового сегмента — своеобразной песочницы для проверки решения в боевых условиях. В качестве подопытных выбрали заранее определенный набор источников, подключили их к KUMA и приступили к настройке нормализации и корреляции событий. Чтобы оценить гибкость системы, мы намеренно выбрали самые нестандартные источники данных и попытались обработать их стандартными правилами корреляции. Здесь и столкнулись с проблемами.
Нам нужно было настроить систему так, чтобы при отсутствии событий с критически важных источников SIEM поднимала тревогу. В KUMA за это отвечают события типа 5 — они возникают при выходе за установленные границы количества событий в политиках мониторинга.
На версии 2.1.3 мы столкнулись с проблемой — события типа 5 не генерировались вообще. Решение нашлось быстро: достаточно было повторно применить политики мониторинга. Однако после обновления до версии 3.0.2 обнаружилась новая особенность: в распределенной инсталляции события типа 5 отправлялись только на корреляторы тенанта Main. В нашем случае он не использовался, а оставался пустым — вместо этого, мы создавали отдельные тенанты для каждой организации.
Отступать было некуда, и мы обратились в техническую поддержку. Там предложили обновиться до версии 3.0.3.19, содержащей исправления для ClickHouse и событий типа 4, предположив, что это «возможно решит проблему». После обновления ситуация не изменилась — оповещения по-прежнему отсутствовали. Снова обращение в техническую поддержку, очередной сбор логов. Вердикт — да, это все-таки баг. Пришлось дожидаться его исправления в версии 3.2.
Стандартизация процессов и начало внедрения
Следующим этапом стала разработка проектной документации: технического задания и требований к продуктам. Совместно с экспертами вендора мы подготовили спецификацию аппаратного обеспечения и развернули головной сегмент. К нему подключили две ключевые инфраструктуры цифрового блока Холдинга «Газпром-Медиа» — настоящих монстров по сложности и разветвленности.
Чтобы не изобретать велосипед при каждом новом внедрении, мы разработали набор типовых сегментов и решений — шаблоны настроек точек назначения, конфигурации для коллекторов и корреляторов, заготовки конфигов для балансировщиков, которые подходят и для скромного офиса на пять человек, и для промышленного гиганта. Они заметно упрощают и ускоряют подключение новых активов, экономят время на детальный анализ инфраструктуры.
Наконец, мы создали то, что можно назвать главным артефактом проекта — детальный план внедрения SIEM-системы для каждого корпоративного актива из нашего скоупа. В нем мы описали порядок внедрения, функционирования и эксплуатации системы: набор инструкций, технических требований и регламентов развертывания.
Этот процесс включает несколько этапов, где первый шаг — запрос и валидация перечня активов заказчика.
Звучит просто, но на практике напоминает археологические раскопки в древнем городе: каждый найденный артефакт может оказаться ключевым для общей картины. В организационном плане критически важно, чтобы заказчик четко представлял свои активы и их роль в бизнес-процессах. Чем глубже это понимание, тем проще выстроить эффективную систему кибербезопасности.
Рынок демонстрирует парадоксальную картину: большинство компаний не ведет полноценный учет активов. Обычно они выбирают одну из двух крайностей: либо пытаются защитить все подряд, либо игнорируют безопасность вовсе. Первый подход ведет к неоправданным расходам, второй — к неизбежным убыткам от кибератак и затратам на ликвидацию последствий
Параллельно с инвентаризацией активов проходит подготовка к подключению систем. Заказчик получает детальные рекомендации по настройке аудита и требования к доступу для каждого актива. Мы используем стандартизированные форматы журналов и специфические настройки сбора событий безопасности — выстраивается протокол общения между системами. После этого заказчик настраивает источники событий безопасности по нашим инструкциям.
Затем на стороне SIEM проводится настройка сбора событий безопасности. Она включает:
проверку консистентности потока событий и корректности преобразования данных — своеобразный health check для SIEM. Важно проконтролировать полноту поступающих событий и убедиться, что мы не теряем ни одного значимого сигнала в общем потоке данных;
отладку сценариев реагирования — речь идет о настройке правил корреляции, определении логики развития событий и их дальнейшего обогащения.
После прохождения всех этих этапов и всесторонней проверки системы мы перевели активы ГПМХ в режим полноценного мониторинга с соглашением об уровне сервиса (SLA). Причем центры мониторинга заказчика и наш SOC работают совместно, каждый в зоне своей ответственности.
Работа с источниками событий: нестандартные решения
На словах все просто, но проект длился полтора года, и каждый этап интеграции новой инфраструктуры преподносил свои сюрпризы.
Нам предстояло не только организовать мониторинг типовых систем вроде операционок или межсетевых экранов, но и погрузиться в дебри проприетарного корпоративного ПО, которое KUMA видела впервые в жизни. А еще были разнообразные кастомные сборки и самописный софт, документация к которому, кажется, существовала только в голове разрабов. Источники событий безопасности часто оказывались настолько нестандартными, что заставляли вспомнить все известные регулярные выражения.
Отдельной головной болью стал мониторинг на площадках с ограниченным доступом к инфраструктуре — примерно, как попытаться удаленно починить принтер, который вы никогда не видели. Документация не всегда отражала реальную картину, а каждый новый актив требовал решений, достойных отдельной статьи на Хабре. Сказать, что специалисты нашего SOC прокачали свой скилл на этом проекте — ничего не сказать.
Оптимизация производительности: путь к 100 000 EPS
Другим серьезным вызовом стали колоссальные объемы собираемой информации. Некоторые площадки генерировали поток данных, способный впечатлить даже бывалого дата-инженера — около 100 тысяч событий в секунду (EPS) на один коррелятор. А учитывая, что корреляторов были сотни, все это напоминало Ниагару. Фактически у нас получилась одна из самых масштабных инсталляций KUMA в России. Пришлось погрузиться в недра и прицельно оптимизировать ClickHouse — колоночную СУБД на базе SQL, спрятанную под капотом KUMA.
Там много тонкостей, на которые редко обращают внимание. Например, при достижении 95% занятого пространства горячих дисков, ClickHouse автоматически запускает механизм удаления самых тяжелых партиций. Если такая ситуация повторяется регулярно в течение длительного времени, в кластере остаются только небольшие партиции, и это существенно снижает производительность. Поэтому важно контролировать актуальный состав хранимых данных.
Отказоустойчивость: как мы защитили систему от сбоев
На аппаратном уровне мы применили классический подход enterprise-решений: комплексное резервирование всех ключевых компонентов. Ядро, коллектор, коррелятор и хранилища данных получили зеркальные копии. Сетевые интерфейсы и блоки питания были продублированы, а дисковые массивы рассчитаны с большим запасом.
На программном уровне отказоустойчивость KUMA была реализована через многоуровневый подход:
Ядро — работает как кластер высокой доступности на базе Kubernetes с рабочими узлами, контроллерами и внешним балансировщиком, который развернут вне основного кластера.
Коллектор и коррелятор событий — их узлы распределены между основной и резервной площадками, а нагрузка распределяется между ними с помощью отдельного балансировщика.
Хранилище — функционирует как геораспределенный кластер высокой доступности на базе ClickHouse, который также распределен по разным площадкам.
Резервное копирование также работает на двух уровнях: встроенные инструменты KUMA заботятся о копировании конфигураций, баз данных и сертификатов ядра, в то время как архитектура СУБД обеспечивает сохранность событий.
Реализована гибкая балансировка потока событий между компонентами. Коллекторы работают в режиме active/active и могут принимать распределенный поток событий. Корреляторы же на одной площадке работают только в режиме active/passive.
Это техническое ограничение связано с необходимостью анализировать весь поток событий на одном корреляторе: если события распределятся между разными корреляторами, то, например, попытки подбора пароля могут фиксироваться на одном корреляторе, а успешная авторизация — на другом. В результате система либо не создаст инцидент, либо присвоит ему некорректный уровень критичности.
Для стабильной работы между компонентами используются буферы. Они помогают регулировать нагрузку на каналы связи и диски, установленные на компонентах. Буферы накапливают события и сохраняют их даже при временной потере связи между компонентами.
Текущие показатели и перспективы: от SIEM к комплексной защите
Активная фаза проекта продолжается. На данный момент мы интегрировали в систему мониторинга практически все активы двух из трех направлений Холдинга «Газпром-Медиа».
Текущие показатели системы: обработка более 100 тысяч событий в секунду (EPS), более 70 серверов с различными программными компонентами и свыше 150 администрируемых элементов инсталляции (и это не предел). Хранит события и журналы в горячем режиме на протяжении 30 дней, и 180 дней в холодном
Мы подключаем новые активы холдинга к мониторингу, но теперь это происходит гораздо быстрее, без глубокого исследования. А в случае инцидента мы можем подключить актив к мониторингу за сутки и оперативно расследовать происшествие.
Эволюция подхода к управлению ИБ
Для реализации этого проекта пришлось много вкалывать не только нам, но и самому заказчику. Команда Холдинга «Газпром-Медиа» провела огромную работу по модернизации ИБ и IT-инфраструктуры: они сформировали единый центр компетенций ИБ, провели инвентаризацию активов и консолидацию IT-инфраструктуры, а также модернизировали многие процессы управления ИБ.
Отметим, что без содействия команды Холдинга «Газпром-Медиа» и готовности заказчика к серьезным изменениям воплотить проект в жизнь было бы нереально. Всем, кто стоит на пути к подобным решениям, можем пожелать лишь решимости и стойкой веры в успех (и, конечно, не забывать про ISO27000).
Методология быстрого подключения
За полтора года этот проект вышел далеко за рамки разового внедрения. Мы превратили опыт работы с Холдингом «Газпром-Медиа» в универсальную методику подключения и мониторинга активов, которую можно масштабировать на различные инфраструктуры. Уже используем эти наработки и для развития информационной безопасности собственного холдинга, и в работе нашего коммерческого SOC.
Разумеется, каждая компания уникальна: в Холдинге «Газпром-Медиа» мы реализовали зонтичный мониторинг, а в других холдингах архитектура может отличаться. Однако наши стандартизированные конфигурации в любом случае значительно ускоряют процесс внедрения SIEM.
Как правило, самостоятельное создание системы мониторинга и реагирования на инциденты внутри компании растягивается на два-три года, но теперь наша команда SOC подключает новые инфраструктуры почти мгновенно — за одни сутки, а на развертывание полноценного SOC на территории заказчика у нас уходит 6–7 месяцев.