SIEM перестала быть просто хранилищем логов — теперь это интеллектуальный центр безопасности. На примере KUMA видно, как платформа шаг за шагом отвечает на новые угрозы, ускоряет работу аналитиков и адаптируется к сложной распределённой инфраструктуре.
- 1. Введение
- 2. Почему ИБ-отделам недостаточно простых SIEM
- 3. SIEM с позиции интегратора
- 4. Версия 3.2: Экономия трафика и тонкая настройка
- 5. Версия 3.4: Интеллект и удобство аналитики
- 6. Версия 4.0: Глобальная экспансия и контроль активов
- 7. Версия 4.2: Зрелое администрирование
- 8. Выводы
Введение
Рынок систем управления информацией и событиями безопасности (Security Information and Event Management, SIEM) в России за последние годы прошёл огромный путь. Если ещё недавно перед компаниями стояла базовая задача — просто «собрать логи в одном месте», то сегодня требования к платформам мониторинга изменились кардинально. Им нужно работать в распределённых сетях, обрабатывать терабайты данных, интегрироваться с десятками разнородных источников и делать это быстро.
Пожалуй, самый репрезентативный пример того, как развиваются российские SIEM-системы, — это KUMA (Kaspersky Unified Monitoring and Analysis Platform, платформа для единого мониторинга и анализа событий безопасности) от «Лаборатории Касперского». В её архитектуре и обновлениях видны те же тренды, которые специалисты iTPROTECT наблюдают на рынке в целом: движение в сторону удобства аналитика, поддержки широкого спектра источников и готовности к работе в распределённых средах. Разберём, как от версии к версии она отвечала на вызовы времени.
Почему ИБ-отделам недостаточно простых SIEM
Первые упоминания SIEM в аналитике Gartner относятся к 2005 году. Когда рынок только привыкал к мысли, что управление информацией и событиями безопасности — это базовый элемент защиты, требования к таким системам были довольно просты. Нужно было собирать логи со всех ключевых узлов, хранить их положенный срок по требованиям регуляторов и уметь находить в них простые совпадения. Сегодняшний ландшафт угроз сделал эти представления неактуальными.
SIEM-системы появились как ответ на естественный рост ИТ-инфраструктуры. В какой-то момент количество устройств, сервисов, приложений и прочих ИТ-активов стало таким большим и динамичным, что контролировать всё вручную оказалось физически невозможно. Стало очевидно, что даже небольшой компании не обойтись без централизованного сбора и анализа событий с применением автоматизации.
Изначально это были инструменты скорее реактивные — они помогали разбираться в уже случившихся инцидентах, отвечая на вопрос «что произошло». Но с усложнением угроз роль SIEM фундаментально изменилась. Теперь это не просто архив логов, а аналитический двигатель центров мониторинга и управления безопасностью (Security Operations Center, SOC), который помогает ИБ-командам разобраться, что происходит в инфраструктуре прямо сейчас, спрогнозировать развитие аномалий и их влияние на процессы ИТ и бизнеса.
В последние годы усложнились не только ИТ-инфраструктуры — сами атаки стали комплексными, быстрыми и тихими. Целевые группы (Advanced Persistent Threat, APT) могут годами жить в инфраструктуре, не проявляя себя подозрительной активностью. Шифровальщики превратились в инструменты спланированных операций, где злоумышленник сначала изучает сеть, а уже потом наносит удар. Регуляторы, в свою очередь, требуют не «галочек» о наличии системы, а доказанной эффективности защиты и постоянного мониторинга.
Перед заказчиками встают принципиально новые вопросы. Как выявлять аномалии, а не просто срабатывания по сигнатурам? Как масштабировать сбор событий на тысячи узлов, разбросанных по филиалам, не перегружая каналы связи и не теряя данные? Как ускорить работу аналитиков, чтобы они успевали реагировать на угрозы, а не тонули в море ложных срабатываний? И как интегрировать в единый контур десятки разрозненных систем — от legacy-оборудования до современных решений по защите контейнеров и облаков?
На примере KUMA от «Лаборатории Касперского» можно проследить, как эти вызовы отразились на конкретных технических решениях. Она не пытается быть просто «ещё одной SIEM», которая закрывает базовые потребности по сбору логов. Логика её развития строилась вокруг главного: дать заказчику инструмент, который способен расти вместе с его инфраструктурой и адаптироваться под усложняющийся ландшафт угроз.
SIEM с позиции интегратора
Для вендора его продукт — это результат долгой разработки, логичная и самодостаточная конструкция. Для заказчика — часто «чёрный ящик», от которого ждут чуда: «Поставьте SIEM, и пусть она ловит хакеров». Интегратор смотрит на это иначе.
Мы оцениваем SIEM как будущий центральный элемент сложной экосистемы, который должен не просто работать, а органично вписаться в уже существующий ландшафт. Поэтому, когда мы оцениваем платформу, нас интересуют не только тактико-технические характеристики по паспорту.
Первое — это будущее место в ИБ-экосистеме. SIEM должна получать данные от источников (от «железок» до облачных сервисов), обогащать их информацией от внешних систем (классификаторов активов, межсетевых экранов нового поколения, системы реагирования на киберугрозы на конечных точках), отдавать алерты в оркестратор (Security Orchestration, Automation and Response, SOAR) или тикет-систему и при этом сама оставаться управляемой через единую консоль мониторинга. Поэтому нужно на старте проекта понимать, насколько легко получится встроить SIEM в уже работающий ИБ-ландшафт, не ломая то, что выстроено годами.
Второе — зрелость процессов администрирования. Для нас критически важно, насколько платформа удобна в ежедневной эксплуатации. Подробные отчёты и дашборды нужны живым людям — администраторам и аналитикам SOC, которые должны иметь инструменты для быстрой реакции. Это значит, что в SIEM должна быть возможность временно отключить шумящее правило, не ломая его логику навсегда; понять, на какие смежные компоненты повлияет их настройка; быстро восстановить систему после сбоя, не перечитывая километровые руководства.
Третье — готовность к российским реалиям. Здесь и поддержка специфических источников от российских вендоров, и способность работать в распределённых сетях с «узкими» каналами связи, и, конечно же, наличие необходимых сертификатов. Важно, как именно реализованы эти функции: как они работают «из коробки», не требуют ли многомесячных доработок и консультаций с разработчиками.
В конечном счёте задача интегратора — не просто внедрить продукт, а передать заказчику работающий инструмент, которым его команда сможет пользоваться самостоятельно и эффективно. И каждый крупный релиз KUMA команда iTPROTECT оценивает именно через эту призму: насколько новая версия упрощает интеграцию, облегчает администрирование и расширяет возможности аналитиков без необходимости «костылей» и доработок.
Пройдёмся по этим изменениям, чтобы взглянуть на release notes глазами специалистов, которые приезжают на объекты заказчиков и разворачивают на практике всё то, что разработчики заложили в код.
Версия 3.2: Экономия трафика и тонкая настройка
Команда iTPROTECT начала внедрения KUMA с версии 3.2, где появилось несколько критически важных функций, которые необходимы крупным компаниям. Главные особенности таких заказчиков — это обширная территориальная распределённость, разнородность источников событий, высокая нагрузка на ИТ- и ИБ-службы, которые должны контролировать происходящее в реальном времени.
Так, одна из главных болей — это нагрузка на каналы связи. Когда из каждого удалённого офиса нужно тянуть несколько отдельных потоков событий в головной офис, каналы просто «забиваются». Именно под этот запрос в версии 3.2 появился маршрутизатор событий. Это новый архитектурный компонент, который позволяет собирать данные с нескольких коллекторов в филиале и отправлять их в центральный офис единым оптимизированным потоком. Для компаний с неширокими каналами связи это стало настоящим спасением: снижение утилизации каналов без потери данных.
Тогда же разработчики серьёзно доработали механизмы сбора. Появилась возможность сбора событий с DNS-сервера (Domain Name System, служба доменных имён) через механизм ETW (Event Tracing for Windows, трассировка событий для Windows), что даёт гораздо более детальную картину о работе службы имён, чем стандартные логи. А агент на Windows научился читать не только журналы ОС, но и текстовые файлы — теперь не нужно мучительно настраивать подключение к сетевым папкам, агент сам заберёт нужные логи с хоста.
Важным шагом стало и расширение совместимости. Функция сбора данных из Elasticsearch открыла лёгкий путь миграции для тех, кто хочет уйти с open source-решений на российскую платформу, сохранив исторические данные.
Кроме того, в KUMA значительно улучшили интерфейс аналитика: появилась группировка событий по произвольным полям, что делает расследование инцидентов гораздо более наглядным. А для администраторов добавили встроенный мониторинг состояния сервисов самой KUMA с оповещениями по почте — теперь не нужно гадать, почему платформа тормозит, система сама подскажет, где возникла нагрузка.
Эти возможности KUMA особенно ценны в проектах с географически распределённой инфраструктурой, где нагрузка на каналы связи и сложность сбора данных становятся критическими факторами. В практике iTPROTECT одним из случаев внедрения этого продукта в распределённой инфраструктуре стал проект в крупной нефтяной компании. Защищённая инфраструктура компании распределена географически между головным офисом в Москве и семью филиалами, в том числе в отдалённых регионах — Республике Коми, Пермском крае и Волгоградской области.
Внедрение решения на базе KUMA стало завершающим элементом комплексного проекта, который позволил компании заметно повысить общий уровень защищённости корпоративных информационных систем. В рамках внедрения KUMA мы подключили сбор информации из 12 типов источников, включая операционные системы, сетевые устройства, системы виртуализации и средства защиты информации. Благодаря SIEM-системе команда ИБ-специалистов компании получила возможность отслеживать критические ИБ-события в ИТ-инфраструктуре и быстрее реагировать на потенциально опасную активность.
Версия 3.4: Интеллект и удобство аналитики
Следующий крупный релиз был посвящён качеству анализа и удобству работы команды SOC. Ключевой фишкой, которую оценят все аналитики, стал временный список исключений правил корреляции. Раньше при ложном срабатывании приходилось либо терпеть шум, либо лезть в сложные настройки правил. Теперь аналитик может прямо из интерфейса исключить конкретный параметр, а задача доработки правила ставится администратору планово. Это резко снижает усталость от ложных срабатываний и ускоряет работу.
Для команд, которые любят использовать открытые наработки, в KUMA появился конвертер правил Sigma. Теперь огромная база правил, созданная мировым сообществом, может быть автоматически переведена в формат KUMA и загружена в платформу.
Ещё один шаг к интеллектуализации — категоризация событий. Вместо того чтобы писать отдельные правила для Windows и Linux на один и тот же тип события (например, вход в систему), аналитик теперь может написать одно правило на категорию «логин». Это упрощает администрирование и снижает количество ошибок.
Кроме того, в версии 3.4 появилась трассировка использования ресурсов. Теперь, собираясь изменить правило или справочник, администратор на интерактивном графе сразу видит, на какие связанные элементы это повлияет. А для самых сложных кейсов стал опционально доступен ИИ-рейтинг активов, который помогает выявлять нехарактерные паттерны поведения и ранжировать критичность событий.
Версия 4.0: Глобальная экспансия и контроль активов
Четвёртая версия стала настоящим прорывом в плане количества поддерживаемых источников. В KUMA 4.0 «из коробки» появилась поддержка десятков новых систем: от сетевого оборудования Alcatel и Dell до специализированных решений по защите данных, таких как Dallas Lock, Staffcop и SecurityCode. Интеграция с экосистемой «Лаборатории Касперского» стала ещё глубже — добавились Kaspersky NDR (Network Detection and Response, сетевое обнаружение и реагирование) и KSMG (Kaspersky Secure Mail Gateway, защищённый почтовый шлюз).
Это не просто механическое расширение списка совместимости. За каждым добавленным источником стоит работа по анализу его событий и подготовке правил нормализации, чтобы «сырые» данные сразу превращались в понятные аналитику поля. Фактически с каждым релизом KUMA наращивает свою встроенную базу знаний — ту самую экспертизу вендора, которая позволяет заказчику не начинать настройку с нуля, а опираться на готовые, проверенные паттерны сбора и анализа. Для российского рынка с его обилием специфических систем это критически важно: появляется возможность получить всё «в одном флаконе», не мучаясь с доработкой коннекторов под каждый новый источник.
Но, пожалуй, главным нововведением версии стало обнаружение неизвестных активов. Платформа теперь анализирует логи и выявляет устройства, о которых администратор мог даже не знать. Эти «теневые ИТ-активы» попадают в отдельный список, и аналитик может проверить, не прячутся ли там злоумышленники. Для крупной распределённой сети это незаменимая функция, позволяющая вести превентивную разведку.
Версия 4.2: Зрелое администрирование
Последние обновления показывают, что KUMA достигла уровня зрелости, необходимого для крупных корпоративных SOC. В версии 4.2 появились возможности, которых ждали все администраторы: резервное копирование и восстановление ядра KUMA через веб-интерфейс. Это упрощает работу по восстановлению после сбоев.
Гибкость в управлении доступом вышла на новый уровень эксплуатации, который заметно снижает риски заказчиков. Теперь можно создавать пользовательские роли, кастомизируя права под структуру любой команды. Функция просмотра и управления активными запросами всех пользователей позволяет главному администратору видеть, кто и чем занят в системе, и при необходимости гасить «тяжёлые» запросы, чтобы не ронять производительность.
Для нас как для интегратора эти возможности означают, что мы можем передать заказчику более прозрачную систему, в которой администратор сможет легко разобраться без дополнительных консультаций. А риск ошибок при настройке и, как следствие, будущих проблем с функциональностью — снижается.
Специалисты iTPROTECT познакомились с возможностями свежей версии KUMA в одном из недавних проектов для крупного государственного ведомства. Именно в таких проектах — с распределённой инфраструктурой и высокими требованиями к надёжности — особенно остро чувствуется потребность в инструментах зрелого администрирования. Когда с системой работают десятки специалистов с разным уровнем доступа, возможность гибко настраивать роли и видеть, кто и какие запросы выполняет, перестаёт быть опцией и становится необходимостью.
Без работающей SIEM невозможно гарантировать безопасность государственных информационных систем — это прямая ответственность, и подход «поставили и забыли» здесь не работает.
С технической стороны задачей проекта было создать отказоустойчивый комплекс для мониторинга безопасности из двух ключевых компонентов:
- Основной сервер KUMA — на него установили все необходимые модули для приёма, обработки, анализа и долгосрочного хранения данных.
- Коллектор событий — специализированный сервер для эффективного сбора данных.
Конфигурация оборудования рассчитана на высокую нагрузку — до 750 событий в секунду (Events Per Second, EPS) с учётом требований к длительности хранения информации. Решение интегрировано с Windows Event Collector, который по подпискам собирает события со всех рабочих станций и серверов в домене, обеспечивая их предварительное хранение и пересылку. Вся передача данных происходит с использованием стандартных защищённых протоколов Windows и отвечает требованиям законодательства в части импортозамещения.
В результате ведомство обеспечило возможность отслеживать события безопасности в режиме реального времени. Что особенно важно, в решение заложен запас прочности, который упростит дальнейшее масштабирование — текущая нагрузка в 750 EPS не является пределом, и система сможет расти вместе с потребностями ведомства.
Выводы
За несколько лет KUMA превратилась в зрелую, отказоустойчивую SIEM-платформу, способную закрыть потребности самого требовательного заказчика. Каждая новая версия — это ответ на реальные вызовы, с которыми мы как интеграторы сталкивались в проектах.
Путь от «коробки» до работающего механизма не бывает прямым. Какой бы мощной ни была функциональность, успех проекта определяют компетенции тех, кто эту функциональность настраивает под живую инфраструктуру. Именно в этой точке роль вендора сменяется ролью интегратора, и мы видим, как в каждом проекте с KUMA система включается в сложный пазл из требований регуляторов, бизнес-задач и технических ограничений.
Эволюция KUMA показывает, как продукт прошёл тот же путь, что и сам рынок SIEM — от инструмента «собери и храни» до полноценной платформы мониторинга. И в этом смысле KUMA сегодня — это воплощение всего накопленного в индустрии опыта.
Команда iTPROTECT специализируется на том, чтобы мощная функциональность SIEM-систем была реализована в качестве полноценной платформы мониторинга, вписанной в ландшафт конкретного заказчика, — с учётом всех отраслевых нюансов, требований регуляторов и реальных операционных задач. Если у вас есть вопросы о том, как решение от «Лаборатории Касперского» может работать в вашей инфраструктуре и какие цели бизнеса удастся закрыть с его помощью, напишите нам — мы погрузимся в ваши задачи и проведём консультацию.
Реклама, 18+. АО «Инфозащита». ИНН 7719672244
ERID: 2VfnxxMjUHg
