SIEM-системы: мониторинг, выявление и расследование киберугроз
Задача SIEM — не собирать логи, а превращать события из разных систем в управляемый процесс обнаружения и реагирования. Качество определяется не объёмом телеметрии и не количеством встроенных правил.
Сначала сценарии, потом логи
Проектируем систему от приоритетных угроз к данным, а не наоборот.
Правила, которые проверены
Каждое критичное правило тестируем на воспроизведённом поведении атакующего.
Путь до реагирования
Алерт должен приводить к расследованию и действию, а не к ещё одной строке в журнале.
Решения SIEM
Hafaza Tech проектирует и внедряет SIEM на базе CrowdStrike Falcon Next-Gen SIEM, Elastic Security, Positive Technologies MaxPatrol SIEM, Guardsix и Fortinet FortiSIEM.
Облачная платформа, которая объединяет собственную телеметрию Falcon с данными из сторонних источников: приём и нормализация внешних журналов, обнаружение, поиск, расследование и автоматизация реагирования.
Через Falcon Onum развиваются конвейеры обработки данных и федеративный поиск — это позволяет разделить сбор и анализ. Рассматриваем прежде всего там, где важна тесная связка защиты конечных точек и SIEM.
Для заказчиков с жёсткими требованиями к локальному развёртыванию или к размещению данных архитектуру нужно прорабатывать отдельно.
Объединяет возможности SIEM с поисково-аналитической платформой Elasticsearch. Подходит там, где важны разнородная телеметрия, гибкий поиск, собственная разработка правил обнаружения, масштабирование и контроль над архитектурой развёртывания.
Может работать в облаке, на собственной инфраструктуре и в изолированных сетях. Включает встроенные сценарии для первичного разбора, обогащения событий, работы с инцидентами и реагирования.
Обратная сторона гибкости: качество итоговой системы сильно зависит от архитектуры, конвейеров данных и зрелости процессов.
Промышленный SIEM с готовым экспертным контентом и правилами корреляции. Производитель поставляет правила обнаружения и сопутствующие настройки, которые адаптируются под инфраструктуру заказчика.
Логично рассматривать для локальных и регулируемых сред, где важны собственная инфраструктура и предсказуемая поддержка экспертного контента.
Новое название Logpoint — ребрендинг прошёл в 2026 году, продукты и их назначение сохранились. Платформа SecOps включает SIEM, SOAR, NDR и связанные возможности.
Отдельный акцент — на суверенности данных. Может быть интересна там, где критичен контроль над данными безопасности и над архитектурой развёртывания.
Промышленный SIEM для централизованного сбора, нормализации, корреляции событий, мониторинга инцидентов и реагирования.
Естественно вписывается в инфраструктуру на Fortinet, но поддерживает и разнородные источники. Полноценное локальное развёртывание с рекомендациями по расчёту мощности, отказоустойчивости и аварийному восстановлению, а также по работе без доступа в интернет.
Одной организации нужна максимально гибкая платформа для работы с данными, другой — готовые правила обнаружения, третьей — строго локальная архитектура, четвёртой — единая платформа SOC с XDR и автоматизацией. Поэтому SIEM подбирают под модель работы центра мониторинга и под архитектуру хранения данных безопасности, а не по таблице сравнения функций.
С чего начинается современный SIEM
Начинать нужно со сценариев обнаружения, а не с подключения всех логов
Классический подход — подключить максимум источников, хранить всё, а потом решить, что искать — приводит к дорогой системе, которая собирает много телеметрии и почти ничего не обнаруживает. Мы проектируем SIEM от приоритетных сценариев к данным, а не наоборот.
Что определяет качество системы
Собираются ли данные, которые нужны конкретным правилам обнаружения
Правильно ли они парсятся и нормализуются
Достаточно ли контекста для расследования
Соответствуют ли правила реальной инфраструктуре
Проверялись ли они на практике
Может ли аналитик быстро перейти от алерта к расследованию
Встроено ли реагирование в понятный рабочий процесс SOC
Для приоритетных сценариев формируется цепочка: угроза → необходимые данные → обнаружение → расследование → реагирование.
Телеметрия и качество данных
Наличие источника в списке подключённых ещё не означает, что он действительно работает на обнаружение. Между «событие пришло» и «правило сработало» лежит несколько шагов, и сломаться может любой из них.
Источник
→
События
→
Нужные поля
→
Нормализация
→
Обнаружение
Откуда поступает телеметрия
Системы управления доступом, Windows и Linux, EDR / XDR, межсетевые экраны, VPN, WAF, PAM, DLP, email security, сетевая инфраструктура, облака, SaaS, приложения, базы данных, управление уязвимостями и threat intelligence.
Проблемы возникают незаметно
Источник перестал отправлять события
Изменился формат логов
Парсер больше не извлекает нужное поле
События приходят с задержкой
Часть инфраструктуры больше не покрывается
Неправильно обрабатываются временные метки или часовой пояс
Контроль здоровья источников
Состояние источников нужно отслеживать так же внимательно, как доступность самой SIEM. Иначе система продолжает работать, а часть правил молча перестаёт срабатывать.
Парсинг, нормализация и контекст
Разные продукты описывают одни и те же события по-разному
Поэтому сырую телеметрию приводят к единой модели: сырое событие → разобранные поля → нормализованное событие → событие с контекстом безопасности. Это позволяет правилам обнаружения работать поверх разных источников независимо от формата конкретного производителя.
Чем обогащаются события
Критичность актива и его владелец
Статус привилегированного пользователя
Сетевая зона
Данные CMDB
Информация об уязвимостях
Threat intelligence и данные об учётных записях
Успешный вход становится значительно важнее, если учётная запись привилегированная, цель критична, а источник подключения необычен. Контекст превращает событие в сигнал.
Detection Engineering — основная ценность SIEM
Процесс, который превращает сценарий угрозы в проверяемое правило обнаружения.
Угроза
→
Нужные данные
→
Логика обнаружения
→
Проверка
→
Инструкция по расследованию
→
Донастройка
Что может использовать современная SIEM
Корреляцию, последовательности событий, пороги, сопоставление с индикаторами, поведенческую аналитику, обнаружение аномалий, машинное обучение, готовые правила производителя и собственные правила.
Количество правил — слабая метрика
Для правил отсутствует нужная телеметрия
Правила не адаптированы к инфраструктуре
Правила создают постоянный шум ложных срабатываний
Их никто не тестировал
Алерты не дают аналитику достаточного контекста
Зрелый Detection Engineering делает акцент на точности, регулярной проверке, поддерживаемости и управляемом развитии правил — а не на размере их библиотеки.
Покрытие логами — это ещё не покрытие обнаружением
Сбор журналов безопасности Windows со всех контроллеров домена — это покрытие телеметрией, но ещё не способность обнаруживать атаки. В англоязычной практике это различают как Log Coverage и Detection Coverage.
Проверять нужно всю цепочку, а не наличие источника в списке подключённых. Источник может быть подключён, события — собираться, а нужное поле при этом не извлекаться парсером. Правило не сработает, и об этом никто не узнает, пока не случится инцидент.
Проверка правил обнаружения
Критичные правила обнаружения необходимо тестировать
Проверяется полный путь: действие → событие создано → собрано → разобрано → правило сработало → расследование возможно. Цель — проверить не синтаксис правила, а всю цепочку обнаружения.
Чем проверяют
Контролируемые симуляции
Adversary emulation
Purple-team упражнения
Повтор исторических данных
BAS и тестовые события
Результаты тестирования на проникновение
Действие
→
Событие создано
→
Собрано
→
Разобрано
→
Правило сработало
→
Расследование возможно
Современная архитектура хранения данных безопасности
Не все данные обязаны физически храниться внутри самой SIEM одинаковым способом.
Современные SecOps-платформы всё чаще объединяют SIEM, телеметрию XDR, расследование, SOAR и работу с инцидентами. Поэтому выбор всё меньше сводится к вопросу «SIEM или XDR» и всё больше — к полноте данных, полноте обнаружения, качеству расследования и реагирования.
Расследование и поиск угроз
Хорошее правило должно позволять быстро перейти к расследованию
Кроме автоматических алертов SIEM должна позволять искать угрозы по историческим данным вручную. Поэтому скорость поиска и удобство переходов между сущностями — это часть защищённости, а не просто функция интерфейса.
Куда аналитик должен попасть из алерта
Сырая телеметрия
Учётная запись и конечная точка
Целевой актив
История аутентификаций
Связанные алерты
Сетевая активность и threat intelligence
Кто
→
Что
→
Где
→
Когда
→
Почему подозрительно
→
Связанная активность
От обнаружения к действию: SOAR и автоматизация
SOAR превращает результаты обнаружения и расследования в управляемое реагирование. Рутинные шаги выполняются автоматически, а решения с высоким риском остаются за человеком.
SOAR всё чаще не отдельная система, а встроенная возможность SecOps-платформы. Поэтому при выборе SIEM важно оценивать не только механизм обнаружения, но и то, как платформа переводит алерт в действие.
Искусственный интеллект в центре мониторинга помогает составлять поисковые запросы, кратко описывать инциденты, объяснять сработавшие правила, собирать контекст расследования и ускорять первичный разбор. Некоторые платформы сочетают жёстко заданные сценарии реагирования с ИИ-анализом внутри того же процесса. Но принцип остаётся прежним: ИИ не восполнит отсутствующую телеметрию, не исправит неверный парсер и не заменит слабую логику обнаружения — он усиливает зрелый процесс, но не создаёт его.
Расчёт мощности, экономика и требования к размещению данных
Количество устройств само по себе недостаточно для расчёта. Технически похожие развёртывания могут иметь совершенно разную экономику.
Что учитывается при расчёте
EPS, объём в ГБ или ТБ в сутки, пиковая нагрузка, типы источников, срок хранения, число одновременных поисковых запросов, индексирование, репликация, отказоустойчивость и ожидаемый рост.
Модель лицензирования
Платформы лицензируются по-разному: по объёму принимаемых данных, по объёму хранения, по EPS, по вычислительным ресурсам, по количеству узлов или по другим метрикам нагрузки. Этот пункт стоит оценивать отдельно от технических характеристик.
Перед подключением крупных источников полезно определить: используется ли телеметрия для обнаружения, нужна ли она для расследования, требуется ли для аудита, нужна ли полная детализация и как долго данные должны оставаться доступными для поиска.
On-premise и суверенные среды
Могут ли логи покидать инфраструктуру
Где должны храниться данные
Допустима ли обработка в облаке
Нужен ли self-hosted или air-gapped вариант
Как обновляются парсеры и правила обнаружения
Как подключаются удалённые площадки
Поэтому платформы сравнивают не только по возможностям обнаружения, но и по суверенности данных, модели развёртывания и эксплуатационным требованиям.
Как Hafaza Tech внедряет SIEM
Мы рассматриваем SIEM не как проект «подключить все логи». Девять этапов ниже идут в том порядке, в котором система действительно начинает обнаруживать, а не просто собирать события.
01
Обследование
02
Сценарии
03
Архитектура данных
04
Расчёт мощности
05
Интеграция
06
Detection Engineering
07
Проверка
08
Процессы SOC
09
Донастройка
Определяем критичные активы, сценарии угроз, существующие средства защиты, зрелость SOC, требования соответствия и текущее логирование. Для приоритетных сценариев формируем цепочку «угроза → нужные данные → обнаружение → расследование → реагирование».
Проектируем источники, коллекторы, конвейеры обработки, хранение, сроки хранения, EPS и объём в сутки, модель развёртывания, отказоустойчивость и модель лицензирования. Не вся телеметрия обязана храниться одинаково или непосредственно внутри SIEM.
Источники подключаются поэтапно. Для каждого проверяются полнота, парсинг, нужные поля, нормализация, временные метки, задержка и здоровье источника. Появление событий в SIEM ещё не означает завершённую интеграцию.
Правила производителя адаптируются под инфраструктуру заказчика, для недостающих сценариев создаются собственные. Для каждого важного сценария определяются владелец, нужная телеметрия, инструкция по расследованию, метод проверки и периодичность пересмотра.
Критичные правила проверяются по принципу: можем ли мы воспроизвести поведение → увидеть его → обнаружить → расследовать. Проверяется цепочка целиком, а не синтаксис правила.
Для алертов определяются критичность, владелец, порядок первичного разбора, расследование, эскалация, реагирование и автоматизация. После запуска анализируются ложные срабатывания, пробелы в обнаружении и в данных, шумные источники и обратная связь аналитиков.
CrowdStrike, Elastic, MaxPatrol, Guardsix или FortiSIEM?
Хороший PoC — это не демонстрация дашбордов. Мы выбираем несколько реальных сценариев и проходим полный путь: собрать → распарсить → обнаружить → расследовать → отреагировать. Например: злоупотребление привилегированным доступом, компрометация учётной записи, атака на конечную точку, изменение конфигурации межсетевого экрана.
Размещение данных
Модель развёртывания, ограничения по облаку и локальной инфраструктуре, суверенность данных.
Данные и объём
Экосистема телеметрии, объём данных, срок хранения, требования к поиску.
Обнаружение
Готовые правила производителя и возможность разрабатывать собственные.
Реагирование
SOAR и автоматизация, зрелость SOC, интеграции.
Экономика и эксплуатация
Модель лицензирования и операционная сложность.
Что означает хороший SIEM
Видим ли мы нужную активность, обнаруживаем ли значимые сценарии атак, хватает ли аналитику контекста, можем ли перейти к контролируемому реагированию и доказать, что эта цепочка работает.
Есть еще вопросы? Мы обязательно ответим вам!
Не нашли ответа на свои вопросы? Отправьте свой вопрос ниже, и наша служба поддержки ответит на него в ближайшее время. Мы здесь, чтобы помочь вам с кибербезопасностью!
Задайте вопрос!
Получить консультацию!
Если вы хотите узнать больше о наших услугах в области кибербезопасности или не уверены, какие решения подойдут именно вам, оставьте заявку — и наши специалисты свяжутся с вами для бесплатной консультации.
Смежные решения
Дополняющие решения для комплексной защиты инфраструктуры и повышения общего уровня информационной безопасности.
EDR / XDR
Телеметрия и реагирование на конечных точках — один из ключевых источников данных для обнаружения.
PAM
Контекст привилегированного доступа для корреляции и расследования.
Vulnerability & Patch Management
Информация об уязвимостях для обогащения событий и приоритизации.