Качество данных в SIEM все чаще рассматривают не отдельно от детектирования, а как условие доверия к его результатам. Мы попросили экспертов оценить, насколько такая постановка задачи актуальна для российского рынка и какую роль сама SIEM должна играть в контроле полноты и надежности входных данных.
Эксперты:
- Максим Анненков, менеджер по продуктам Security Vision SIEM, SOAR, NG SOAR
- Даниил Вылегжанин, руководитель отдела предпродажной подготовки компании РуСИЕМ
- Афанасий Клюнков, менеджер продукта Alertix, NGR Softlab
- Татьяна Колесникова, системный аналитик продукта KOMRAD Enterprise SIEM ГК "Эшелон"
- Денис Лобанов, руководитель продукта MaxPatrol SIEM в Positive Technologies
- Николай Лишке, директор центра кибербезопасности ГК “Эшелон”
- Борис Осепов, руководитель направления предпродажной поддержки решений для бизнеса, “Лаборатория Касперского”
- Алексей Павлов, директор по развитию продуктов в Positive Technologies
- Павел Пугач, системный аналитик “СерчИнформ”
- Андрей Шабалин, руководитель группы анализа данных NGR Softlab
Готовы ли российские вендоры и заказчики SIEM измерять качество поступающих событий и предъявлять к нему формальные требования?
Татьяна Колесникова, ГК "Эшелон"
Да, рынок движется в этом направлении. Это уже требование крупных заказчиков. Основная проблема – отсутствие единого ГОСТа или отраслевого стандарта на качество логов. Пока каждый интегратор составляет собственные матрицы требований под проекты. Финальные критерии заказчик определяет сам, исходя из бизнес-процессов и модели угроз.
Да, рынок движется в этом направлении. Это уже требование крупных заказчиков. Основная проблема – отсутствие единого ГОСТа или отраслевого стандарта на качество логов. Пока каждый интегратор составляет собственные матрицы требований под проекты. Финальные критерии заказчик определяет сам, исходя из бизнес-процессов и модели угроз.
Павел Пугач, "СерчИнформ"
Вопрос полноты и качества передачи событий, а также контроля за этим процессом не может решаться на стороне вендоров SIEM, поскольку всегда зависит от источника. Сегодня на рынке нет обязательной стандартизации форматов передачи таких данных, даже соответствие универсальным форматам вроде syslog часто оказывается условным. Однако попытки вендоров SIEM, составляющих меньшинство среди всех игроков ИТ-рынка, диктовать стандарт – малоперспективная затея. С другой стороны, заказчики этой движущей силой выступить могут, но при таком раскладе унификации точно не будет.
Денис Лобанов, Positive Technologies
Важны не формальные требования к качеству событий, а то, чтобы эти события вносили максимальный вклад в общий уровень выявления злоумышленников. Измерять степень покрытия источников и проверять, что с источников собираются правильные типы данных – это разумные задачи для вендоров, так как они напрямую влияют на эффективность работы SIEM. Поставщики программных продуктов, которые в том числе являются источником данных, также заинтересованы в росте их качества. В целом рост популярности ИИ и агентских систем создал запрос на актуальные, достоверные и корректно размеченные данные.
Максим Анненков, Security Vision
Да. Но формализовать стоит не качество вообще, а параметры, от которых зависит конкретный детект: наличие нужного источника, стабильность потока, допустимое время отсутствия событий, полноту журналирования и корректность ключевых полей. Иначе SOC не понимает, действительно ли правило молчит или у него просто исчезли данные. В Security Vision такие отклонения выводятся в отдельный контур контроля сбора.
Андрей Шабалин, NGR Softlab
Технически готовы, но сама методология только начинает складываться. Рынку необходимо время, чтобы импульс MITRE и такого мастодонта, как Elastic, получил свое отражение в российских продуктах. Стоит также понимать, что потенциально может тормозить эту активность: довольно долгое время на рынке наблюдалась борьба цифр и игра метриками, когда исчисляемое количество единиц контента у вендоров стремительно увеличивается, процент покрытия матрицы растет, но на чистоту детекта это не влияет.
Даниил Вылегжанин, РуСИЕМ
Если раньше многие заказчики старались собирать в SIEM как можно больше данных, чтобы отслеживать все и вся, то сейчас они все более осознанно подходят к вопросу о необходимом и достаточном уровне логирования источников. В эпоху дорогого серверного оборудования хранение информационных или мусорных событий становится просто нецелесообразным. Однако не у всех компаний есть четкие критерии оценки хорошего лога, поэтому вендоры выдают свои рекомендации на этапах тестирования и внедрения SIEM, а также стараются предоставить наиболее удобные и понятные инструменты для оценки полноты и качества поступающих событий.
Борис Осепов, "Лаборатория Касперского"
Готовность уже есть: заказчики все чаще связывают качество данных с измеримой эффективностью SOC, а не только с количеством подключенных источников. Следующий шаг – закрепить SLA на полноту, задержку, корректность и полезность полей для приоритетных сценариев. Kaspersky SIEM помогает перевести этот разговор в операционные метрики: контролировать поток событий, нормализацию и контекст, на котором строится детектирование.
Вопрос полноты и качества передачи событий, а также контроля за этим процессом не может решаться на стороне вендоров SIEM, поскольку всегда зависит от источника. Сегодня на рынке нет обязательной стандартизации форматов передачи таких данных, даже соответствие универсальным форматам вроде syslog часто оказывается условным. Однако попытки вендоров SIEM, составляющих меньшинство среди всех игроков ИТ-рынка, диктовать стандарт – малоперспективная затея. С другой стороны, заказчики этой движущей силой выступить могут, но при таком раскладе унификации точно не будет.
Денис Лобанов, Positive Technologies
Важны не формальные требования к качеству событий, а то, чтобы эти события вносили максимальный вклад в общий уровень выявления злоумышленников. Измерять степень покрытия источников и проверять, что с источников собираются правильные типы данных – это разумные задачи для вендоров, так как они напрямую влияют на эффективность работы SIEM. Поставщики программных продуктов, которые в том числе являются источником данных, также заинтересованы в росте их качества. В целом рост популярности ИИ и агентских систем создал запрос на актуальные, достоверные и корректно размеченные данные.
Максим Анненков, Security Vision
Да. Но формализовать стоит не качество вообще, а параметры, от которых зависит конкретный детект: наличие нужного источника, стабильность потока, допустимое время отсутствия событий, полноту журналирования и корректность ключевых полей. Иначе SOC не понимает, действительно ли правило молчит или у него просто исчезли данные. В Security Vision такие отклонения выводятся в отдельный контур контроля сбора.
Андрей Шабалин, NGR Softlab
Технически готовы, но сама методология только начинает складываться. Рынку необходимо время, чтобы импульс MITRE и такого мастодонта, как Elastic, получил свое отражение в российских продуктах. Стоит также понимать, что потенциально может тормозить эту активность: довольно долгое время на рынке наблюдалась борьба цифр и игра метриками, когда исчисляемое количество единиц контента у вендоров стремительно увеличивается, процент покрытия матрицы растет, но на чистоту детекта это не влияет.
Даниил Вылегжанин, РуСИЕМ
Если раньше многие заказчики старались собирать в SIEM как можно больше данных, чтобы отслеживать все и вся, то сейчас они все более осознанно подходят к вопросу о необходимом и достаточном уровне логирования источников. В эпоху дорогого серверного оборудования хранение информационных или мусорных событий становится просто нецелесообразным. Однако не у всех компаний есть четкие критерии оценки хорошего лога, поэтому вендоры выдают свои рекомендации на этапах тестирования и внедрения SIEM, а также стараются предоставить наиболее удобные и понятные инструменты для оценки полноты и качества поступающих событий.
Борис Осепов, "Лаборатория Касперского"
Готовность уже есть: заказчики все чаще связывают качество данных с измеримой эффективностью SOC, а не только с количеством подключенных источников. Следующий шаг – закрепить SLA на полноту, задержку, корректность и полезность полей для приоритетных сценариев. Kaspersky SIEM помогает перевести этот разговор в операционные метрики: контролировать поток событий, нормализацию и контекст, на котором строится детектирование.
Как контролировать полноту поступления событий в SIEM и какую часть этой задачи должна решать сама SIEM?
Павел Пугач, "СерчИнформ"
На стороне систем управления событиями ИБ можно проконтролировать полноту поступления данных от источника: по ID событий, по меткам или другими способами. Но узнать, все ли зафиксировал источник и насколько правильно это сделал, из SIEM невозможно: за это ответственен производитель источника.
Алексей Павлов, Positive Technologies
Полнота событий определяется двумя параметрами – покрытием ИТ-инфраструктуры и правильностью настройки аудита. Обе задачи решаются SIEM – через карту активов и встроенные приоритеты типов источников в зависимости от сегмента и роли, а также через проверку поступающих типов событий через мониторинг источников.
Николай Лишке, ГК "Эшелон"
Оценивать полноту по объему и EPS нельзя: источник может присылать только часть нужных событий. Нужны контрольные события, мониторинг очередей и коллекторов, выявление разрывов и отклонений от профиля сбора. Для выявления таких отклонений мы применяем машинное обучение. Система должна показывать не только недоступность источника, но и какие правила и сценарии остались без данных. За формирование событий отвечает источник, за контроль поступления и формирование инцидентов – SIEM.
Максим Анненков, Security Vision
Базовую техническую часть должна брать на себя SIEM: видеть не только агрегатор, но и конечные источники, факт и объем поступления, нулевые значения и резкие отклонения как в большую, так и меньшую сторону, допустимое время тишины. За SOC остается определение, какие события обязательны для конкретных use case. В Security Vision контроль сохраняется до хостов за WEC/Syslog, поэтому выпавший источник не остается скрытым.
Борис Осепов, "Лаборатория Касперского"
Полноту нельзя проверять только на стороне источника: SIEM должна видеть всю цепочку – генерацию, доставку, прием, разбор и использование события в корреляции. Практический минимум – контроль потока от источника, динамика EPS, наличие очередей на обработку событий и ошибок. В Kaspersky SIEM отслеживаются параметры обработки данных на всех этапах: контролируются изменения потоков событий от источников (мониторинг источников), наличие очередей и ошибок нормализации. Если событие не может быть нормализовано, оно сохраняется в сыром виде и по-прежнему доступно для Threat Hunting.
Даниил Вылегжанин, РуСИЕМ
Для начала нам нужно правильно настроить параметры сбора событий – определить список журналов для сбора и настроить фильтрацию, чтобы в систему изначально приходили только нужные нам события. Далее уже сама SIEM должна непрерывно отслеживать доступность источников и состояние своих агентов, оповещая администраторов о любых сбоях или недоступности источников. С помощью технологий машинного обучения можно также отслеживать изменения в поведении источника: падение потока, отсутствие типичных для источника событий или очистку журнала аудита.
Афанасий Клюнков, NGR Softlab
Современные SIEM позволяют отслеживать стабильность сбора: администратор настраивает пороги для каждого источника и получает уведомление при резком падении или пропаже потока событий, что позволяет оперативно выявлять слепые зоны. Система может также контролировать качество данных, проверяя наличие обязательных полей и точность парсинга, без которых правила корреляции не сработают.
На стороне систем управления событиями ИБ можно проконтролировать полноту поступления данных от источника: по ID событий, по меткам или другими способами. Но узнать, все ли зафиксировал источник и насколько правильно это сделал, из SIEM невозможно: за это ответственен производитель источника.
Алексей Павлов, Positive Technologies
Полнота событий определяется двумя параметрами – покрытием ИТ-инфраструктуры и правильностью настройки аудита. Обе задачи решаются SIEM – через карту активов и встроенные приоритеты типов источников в зависимости от сегмента и роли, а также через проверку поступающих типов событий через мониторинг источников.
Николай Лишке, ГК "Эшелон"
Оценивать полноту по объему и EPS нельзя: источник может присылать только часть нужных событий. Нужны контрольные события, мониторинг очередей и коллекторов, выявление разрывов и отклонений от профиля сбора. Для выявления таких отклонений мы применяем машинное обучение. Система должна показывать не только недоступность источника, но и какие правила и сценарии остались без данных. За формирование событий отвечает источник, за контроль поступления и формирование инцидентов – SIEM.
Максим Анненков, Security Vision
Базовую техническую часть должна брать на себя SIEM: видеть не только агрегатор, но и конечные источники, факт и объем поступления, нулевые значения и резкие отклонения как в большую, так и меньшую сторону, допустимое время тишины. За SOC остается определение, какие события обязательны для конкретных use case. В Security Vision контроль сохраняется до хостов за WEC/Syslog, поэтому выпавший источник не остается скрытым.
Борис Осепов, "Лаборатория Касперского"
Полноту нельзя проверять только на стороне источника: SIEM должна видеть всю цепочку – генерацию, доставку, прием, разбор и использование события в корреляции. Практический минимум – контроль потока от источника, динамика EPS, наличие очередей на обработку событий и ошибок. В Kaspersky SIEM отслеживаются параметры обработки данных на всех этапах: контролируются изменения потоков событий от источников (мониторинг источников), наличие очередей и ошибок нормализации. Если событие не может быть нормализовано, оно сохраняется в сыром виде и по-прежнему доступно для Threat Hunting.
Даниил Вылегжанин, РуСИЕМ
Для начала нам нужно правильно настроить параметры сбора событий – определить список журналов для сбора и настроить фильтрацию, чтобы в систему изначально приходили только нужные нам события. Далее уже сама SIEM должна непрерывно отслеживать доступность источников и состояние своих агентов, оповещая администраторов о любых сбоях или недоступности источников. С помощью технологий машинного обучения можно также отслеживать изменения в поведении источника: падение потока, отсутствие типичных для источника событий или очистку журнала аудита.
Афанасий Клюнков, NGR Softlab
Современные SIEM позволяют отслеживать стабильность сбора: администратор настраивает пороги для каждого источника и получает уведомление при резком падении или пропаже потока событий, что позволяет оперативно выявлять слепые зоны. Система может также контролировать качество данных, проверяя наличие обязательных полей и точность парсинга, без которых правила корреляции не сработают.
Какие требования к входным данным должна уметь автоматически проверять SIEM?
Павел Пугач, "СерчИнформ"
В первую очередь – наличие событий в пакете данных от источника и их соответствие заявленному формату. Если заявлено, что источник передает данные в формате syslog по такому-то каналу, SIEM должна на входе определять, так это или нет.
Николай Лишке, ГК "Эшелон"
Валидный JSON еще не означает, что событие пригодно для детектирования. SIEM должна проверять схему и корректность парсинга, наличие и заполненность обязательных полей, типы и допустимые значения, временную метку и часовой пояс, идентификатор источника, дубликаты, задержки и аномалии потока. Набор проверок должен задаваться профилем источника и требованиями использующих его правил детектирования с учетом инфраструктуры заказчика.
Максим Анненков, Security Vision
Минимум – доступность источника, ожидаемые типы событий, корректность временных меток и обязательные поля, от которых зависит детект. Важно отделять транспортную проблему от смысловой: событие может прийти, но после изменения схемы перестать быть пригодным для правила. В Security Vision требования к источникам, типам событий и обязательным полям можно формализовать для правила, а его проверка позволяет подать сырой лог и увидеть парсинг и срабатывание.
Алексей Павлов, Positive Technologies
SIEM-система должна, исходя из активов ИТ-инфраструктуры и разметки подсетей, давать рекомендации по подключению источников и скрипты по их правильной настройке. Такая помощь должна быть доступна посредством ИИ-ассистентов и интерактивных подсказок в интерфейсе системы. В перспективе SIEM, помимо рекомендаций, должна обеспечивать комплексную валидацию входных данных.
Даниил Вылегжанин, РуСИЕМ
В первую очередь должна быть возможность выбора режима работы с источниками событий: слушать всё или только определенные источники. Это позволит избежать поступления лишних событий в систему от нерелевантных источников. Следующими этапами должны идти проверка качества парсинга, временных метрик и отслеживание аномалий потока событий от источника.
Афанасий Клюнков, NGR Softlab
Современная SIEM должна автоматически проверять входные данные по следующим ключевым параметрам:
Борис Осепов, "Лаборатория Касперского"
SIEM должна автоматически проверять доступность источника, непрерывность и задержку потока, дублирование, соответствие формату, качество временных меток и заполненность полей, критичных для конкретного правила. Kaspersky SIEM нормализует и обогащает данные, делая такие проверки практическими. Обогащение позволяет повышать качество данных – геообогащение IP, прямой и обратный резолв DNS, корректирование таймзон и многое другое.
В первую очередь – наличие событий в пакете данных от источника и их соответствие заявленному формату. Если заявлено, что источник передает данные в формате syslog по такому-то каналу, SIEM должна на входе определять, так это или нет.
Николай Лишке, ГК "Эшелон"
Валидный JSON еще не означает, что событие пригодно для детектирования. SIEM должна проверять схему и корректность парсинга, наличие и заполненность обязательных полей, типы и допустимые значения, временную метку и часовой пояс, идентификатор источника, дубликаты, задержки и аномалии потока. Набор проверок должен задаваться профилем источника и требованиями использующих его правил детектирования с учетом инфраструктуры заказчика.
Максим Анненков, Security Vision
Минимум – доступность источника, ожидаемые типы событий, корректность временных меток и обязательные поля, от которых зависит детект. Важно отделять транспортную проблему от смысловой: событие может прийти, но после изменения схемы перестать быть пригодным для правила. В Security Vision требования к источникам, типам событий и обязательным полям можно формализовать для правила, а его проверка позволяет подать сырой лог и увидеть парсинг и срабатывание.
Алексей Павлов, Positive Technologies
SIEM-система должна, исходя из активов ИТ-инфраструктуры и разметки подсетей, давать рекомендации по подключению источников и скрипты по их правильной настройке. Такая помощь должна быть доступна посредством ИИ-ассистентов и интерактивных подсказок в интерфейсе системы. В перспективе SIEM, помимо рекомендаций, должна обеспечивать комплексную валидацию входных данных.
Даниил Вылегжанин, РуСИЕМ
В первую очередь должна быть возможность выбора режима работы с источниками событий: слушать всё или только определенные источники. Это позволит избежать поступления лишних событий в систему от нерелевантных источников. Следующими этапами должны идти проверка качества парсинга, временных метрик и отслеживание аномалий потока событий от источника.
Афанасий Клюнков, NGR Softlab
Современная SIEM должна автоматически проверять входные данные по следующим ключевым параметрам:
- Стабильность и полнота сбора: отслеживание каждого источника событий с контролем порогов отклонения потока и уведомлением о пропадании данных, превращая слепые зоны в наблюдаемые инциденты.
- Качество парсинга и нормализации: проверка успешности обработки событий, выявление высокого процента ошибок парсинга, контроль наличия обязательных полей (например, source.ip, user.name), необходимых для работы правил корреляции.
- Корректность временных меток: сравнение времени возникновения события с временем поступления в SIEM для выявления критических задержек, делающих невозможным обнаружение угроз в реальном времени.
- Качество правил детектирования: мониторинг частоты срабатываний правил, позволяющий выявлять аномальные изменения (резкий спад или всплеск) и системно снижать уровень шума.
Борис Осепов, "Лаборатория Касперского"
SIEM должна автоматически проверять доступность источника, непрерывность и задержку потока, дублирование, соответствие формату, качество временных меток и заполненность полей, критичных для конкретного правила. Kaspersky SIEM нормализует и обогащает данные, делая такие проверки практическими. Обогащение позволяет повышать качество данных – геообогащение IP, прямой и обратный резолв DNS, корректирование таймзон и многое другое.
Через какие механизмы SIEM должна учитывать деградацию источника при оценке достоверности детекта?
Татьяна Колесникова, ГК "Эшелон"
Для каждого источника нужно вести профиль качества: отслеживать ошибки парсинга, задержки и наличие всех заявленных типов событий. При деградации правильнее снижать не критичность самой угрозы, а степень доверия к конкретному детекту – на нее влияют пропуски данных, нестабильность потока и ошибки нормализации. В перспективе этот индекс стоит обогащать оценкой аномальности от ML-моделей (как в Komrad 4.6), используя ее как дополнительный вес при фильтрации.
Даниил Вылегжанин, РуСИЕМ
Например, здесь можно использовать функции поведенческого анализа, способные подсвечивать потенциальную деградацию источника еще до того, как его событие станет частью инцидента. Если же детект уже произошел, то нам может помочь механизм весов. Событиям будет присваиваться определенный вес, который может снижаться в случае, к примеру, некорректного или неполного парсинга события. В этом случае при детекте уровень критичности инцидента будет автоматически изменен.
Андрей Шабалин, NGR Softlab
Если говорить о деградации источника, в первую очередь напрашивается некоторый совокупный показатель обратной величины – здоровье/качество телеметрии источника, которое и будет влиять на так называемую достоверность детекта. Вероятнее, главным механизмом здесь будет являться статистический анализ метрик, используемых для его расчета, а среди них ничего нового: задержка, Loss-Rate, ошибки, встречающиеся при парсинге, несоответствие формата данных в отдельных полях общепринятой таксономии и т. д.
Павел Пугач, "СерчИнформ"
Деградация обычно сама по себе не происходит – есть целый ряд признаков и/или событий, которые этому предшествуют. Например, увеличение задержки между фиксацией события источником и получением этих данных SIEM. Если же система или ее оператор эти признаки пропустили, то стоит обращать внимание на изменения характеристик потока, таких как снижение количества событий на единицу времени.
Алексей Павлов, Positive Technologies
Современные SIEM-системы способны выявлять деградацию потока, отличать выключение хоста от отключения аудита, контролировать целостность настроек сбора событий. Решается это либо доверенным агентским сбором, где доверенность гарантируется драйвером самозащиты, либо контролем потока событий с хоста, причем по типам собираемых событий.
Борис Осепов, "Лаборатория Касперского"
Понимая важность контроля потока событий от источников, в Kaspersky SIEM реализован специальный функционал мониторинга потока событий. Выполняется автоматическое определение источников событий (на основе пользовательских параметров), для выявленных источников событий отслеживаются параметры потока данных – можно определить нижние и верхние границы потока, учитывать будние дни и выходные. При выходе потока за определенные границы администраторы систем получат уведомление. На нарушение политик мониторинга потока создаются служебные события, которые могут быть учтены в корреляции, что повышает достоверность детектирующей логики.
Максим Анненков, Security Vision
SIEM должна учитывать деградацию источников через механизмы контроля качества сбора: доступность источника, наличие и стабильность потока событий, отклонение его интенсивности от базового уровня. При выявлении деградации достоверность детекта должна оцениваться с учетом возможной неполноты данных. В Security Vision SIEM контролируются доступность источников, текущие отклонения потоков событий, а также их динамика относительно исторических значений.
Для каждого источника нужно вести профиль качества: отслеживать ошибки парсинга, задержки и наличие всех заявленных типов событий. При деградации правильнее снижать не критичность самой угрозы, а степень доверия к конкретному детекту – на нее влияют пропуски данных, нестабильность потока и ошибки нормализации. В перспективе этот индекс стоит обогащать оценкой аномальности от ML-моделей (как в Komrad 4.6), используя ее как дополнительный вес при фильтрации.
Даниил Вылегжанин, РуСИЕМ
Например, здесь можно использовать функции поведенческого анализа, способные подсвечивать потенциальную деградацию источника еще до того, как его событие станет частью инцидента. Если же детект уже произошел, то нам может помочь механизм весов. Событиям будет присваиваться определенный вес, который может снижаться в случае, к примеру, некорректного или неполного парсинга события. В этом случае при детекте уровень критичности инцидента будет автоматически изменен.
Андрей Шабалин, NGR Softlab
Если говорить о деградации источника, в первую очередь напрашивается некоторый совокупный показатель обратной величины – здоровье/качество телеметрии источника, которое и будет влиять на так называемую достоверность детекта. Вероятнее, главным механизмом здесь будет являться статистический анализ метрик, используемых для его расчета, а среди них ничего нового: задержка, Loss-Rate, ошибки, встречающиеся при парсинге, несоответствие формата данных в отдельных полях общепринятой таксономии и т. д.
Павел Пугач, "СерчИнформ"
Деградация обычно сама по себе не происходит – есть целый ряд признаков и/или событий, которые этому предшествуют. Например, увеличение задержки между фиксацией события источником и получением этих данных SIEM. Если же система или ее оператор эти признаки пропустили, то стоит обращать внимание на изменения характеристик потока, таких как снижение количества событий на единицу времени.
Алексей Павлов, Positive Technologies
Современные SIEM-системы способны выявлять деградацию потока, отличать выключение хоста от отключения аудита, контролировать целостность настроек сбора событий. Решается это либо доверенным агентским сбором, где доверенность гарантируется драйвером самозащиты, либо контролем потока событий с хоста, причем по типам собираемых событий.
Борис Осепов, "Лаборатория Касперского"
Понимая важность контроля потока событий от источников, в Kaspersky SIEM реализован специальный функционал мониторинга потока событий. Выполняется автоматическое определение источников событий (на основе пользовательских параметров), для выявленных источников событий отслеживаются параметры потока данных – можно определить нижние и верхние границы потока, учитывать будние дни и выходные. При выходе потока за определенные границы администраторы систем получат уведомление. На нарушение политик мониторинга потока создаются служебные события, которые могут быть учтены в корреляции, что повышает достоверность детектирующей логики.
Максим Анненков, Security Vision
SIEM должна учитывать деградацию источников через механизмы контроля качества сбора: доступность источника, наличие и стабильность потока событий, отклонение его интенсивности от базового уровня. При выявлении деградации достоверность детекта должна оцениваться с учетом возможной неполноты данных. В Security Vision SIEM контролируются доступность источников, текущие отклонения потоков событий, а также их динамика относительно исторических значений.
Должна ли SIEM пересматривать прошлые детекты, если часть событий поступила с задержкой (то есть не участвовала в детекте) или их ненадежность была выявлена позже?
Павел Пугач, "СерчИнформ"
Стоит пересмотреть сработки, если эти события участвуют в сложных детектах, построенных на кросс-корреляции – то есть завязанных на какие-то еще события, кроме запоздавших. Если же никакой связи с другими источниками и правилами нет, то нет и необходимости в перепроверке.
Татьяна Колесникова, ГК "Эшелон"
Да, SIEM обязана поддерживать ретроспективный анализ. Если события поступили с задержкой или после исправления парсера, система должна заново проверить сырые данные за указанный период. Это критически важно для восстановления пропущенных цепочек атак и устранения слепых зон. Такой пересчет не должен нагружать Real-Time-движок, а выполняться как фоновая задача по расписанию или запросу аналитика, гарантируя актуальность инцидентов.
Андрей Шабалин, NGR Softlab
Подобная логика, несомненно, в продуктах необходима, однако регулярный пересмотр всех уже сгенерированных алертов железно станет в копеечку. В настоящий момент, когда все более остро становится вопрос оптимизации используемых ресурсов, наверное, более вероятным на первых этапах выглядит пересмотр только тех детектов, в которых уровень достоверности находится ниже заранее определенного уровня.
Максим Анненков, Security Vision
Да, если поздние данные могли изменить результат корреляции. Система должна уметь восстановить хронологию в допустимом окне и дать возможность перепроверить правило на истории. При этом незаметно "переписывать прошлое" нежелательно: изменение результата должно оставлять аудиторский след. Security Vision восстанавливает последовательность при разрозненном поступлении и поддерживает ретропроверку правил по историческим событиям.
Денис Лобанов, Positive Technologies
SIEM-система должна уметь проводить и потоковую, и ретро/batch-корреляцию. Обе функции неотъемлемы от самого понятия современной SIEM и играют значимую роль в обеспечении киберустойчивости бизнеса.
Стоит пересмотреть сработки, если эти события участвуют в сложных детектах, построенных на кросс-корреляции – то есть завязанных на какие-то еще события, кроме запоздавших. Если же никакой связи с другими источниками и правилами нет, то нет и необходимости в перепроверке.
Татьяна Колесникова, ГК "Эшелон"
Да, SIEM обязана поддерживать ретроспективный анализ. Если события поступили с задержкой или после исправления парсера, система должна заново проверить сырые данные за указанный период. Это критически важно для восстановления пропущенных цепочек атак и устранения слепых зон. Такой пересчет не должен нагружать Real-Time-движок, а выполняться как фоновая задача по расписанию или запросу аналитика, гарантируя актуальность инцидентов.
Андрей Шабалин, NGR Softlab
Подобная логика, несомненно, в продуктах необходима, однако регулярный пересмотр всех уже сгенерированных алертов железно станет в копеечку. В настоящий момент, когда все более остро становится вопрос оптимизации используемых ресурсов, наверное, более вероятным на первых этапах выглядит пересмотр только тех детектов, в которых уровень достоверности находится ниже заранее определенного уровня.
Максим Анненков, Security Vision
Да, если поздние данные могли изменить результат корреляции. Система должна уметь восстановить хронологию в допустимом окне и дать возможность перепроверить правило на истории. При этом незаметно "переписывать прошлое" нежелательно: изменение результата должно оставлять аудиторский след. Security Vision восстанавливает последовательность при разрозненном поступлении и поддерживает ретропроверку правил по историческим событиям.
Денис Лобанов, Positive Technologies
SIEM-система должна уметь проводить и потоковую, и ретро/batch-корреляцию. Обе функции неотъемлемы от самого понятия современной SIEM и играют значимую роль в обеспечении киберустойчивости бизнеса.
Борис Осепов, "Лаборатория Касперского"
Да, причем это делается с разделением режимов. Оперативная корреляция должна быстро предупредить SOC, а ретроспективный анализ – пересчитать картину при поступлении запоздалых данных или изменении оценки их качества. Отдельная функциональность – дата-майнинг, который позволяет выполнять корреляцию с предварительной аналитической обработкой накопленных событий. Это позволяет уточнять связи, приоритет и охват инцидента, не подменяя историю.
Kaspersky SIEM хранит и предоставляет данные для поиска и анализа исторических событий – это важно для Threat Hunting, расследований и проверки гипотез после обнаружения нового контекста.
Даниил Вылегжанин, РуСИЕМ
Однозначно должна. Более того, современная SIEM должна иметь возможности настройки корреляционных движков для работы как по времени создания события, так и по времени его поступления в систему. Если у нас часть событий поступила с задержкой или на разных источниках установлено разное время, то это может привести к тому, что событие не попадет в карточку конкретного инцидента и мы потеряем часть контекста, что недопустимо. Для нас критически важно, чтобы пазл атаки полностью сложился, даже если финальный лог опоздал на часы.
Да, причем это делается с разделением режимов. Оперативная корреляция должна быстро предупредить SOC, а ретроспективный анализ – пересчитать картину при поступлении запоздалых данных или изменении оценки их качества. Отдельная функциональность – дата-майнинг, который позволяет выполнять корреляцию с предварительной аналитической обработкой накопленных событий. Это позволяет уточнять связи, приоритет и охват инцидента, не подменяя историю.
Kaspersky SIEM хранит и предоставляет данные для поиска и анализа исторических событий – это важно для Threat Hunting, расследований и проверки гипотез после обнаружения нового контекста.
Даниил Вылегжанин, РуСИЕМ
Однозначно должна. Более того, современная SIEM должна иметь возможности настройки корреляционных движков для работы как по времени создания события, так и по времени его поступления в систему. Если у нас часть событий поступила с задержкой или на разных источниках установлено разное время, то это может привести к тому, что событие не попадет в карточку конкретного инцидента и мы потеряем часть контекста, что недопустимо. Для нас критически важно, чтобы пазл атаки полностью сложился, даже если финальный лог опоздал на часы.
Ваш прогноз, станет ли оценка качества входных данных такой же обязательной функцией SIEM, как сегодня нормализация и корреляция?
Даниил Вылегжанин, РуСИЕМ
Не думаю, что этот вопрос следует задавать в будущем времени: оценка качества входных данных уже стала одним из обязательных критериев для многих предприятий при выборе SIEM. Сейчас все больше заказчиков интересуются вопросами: есть ли уведомления, если источник перестал присылать события, и как можно оперативно увидеть аномалию в событиях определенного источника. Без этого любая корреляция может стать бесполезной.
Павел Пугач, "СерчИнформ"
Нормализация и корреляция – функции, без которых SIEM объективно не может выполнять задачи. Недаром они стали стандартом для SIEM с 2005 г., когда только появился такой класс. В то же время пять лет назад среди обязательных требований к SIEM называли, например, функционал UBA. Но рыночным стандартом его наличие так и не стало. Реальную пользу от новых технологий в сложившемся классе продуктов можно оценивать, когда хайп утихает и появляются рабочие реализации. Так и с оценкой входных данных: чтобы стать маст-хэвом для рынка, она должна качественно поменять работу SIEM. А это только предстоит увидеть.
Николай Лишке, ГК "Эшелон"
Да, но сначала – именно в рамках SOC. Для зрелых SOC оценка качества уже стала такой же базовой функцией SIEM, как нормализация и корреляция, хотя формально это еще не закреплено стандартами. При этом стандартом является не отдельный функционал, а связка "источник – правила поступления событий – сценарий детектирования" с непрерывным контролем, историей деградаций и оценкой влияния на правила. Для зрелых SOC такой подход уже реализован и используется. Для российских SIEM мой прогноз – ближайшие 2–3 года.
Афанасий Клюнков, NGR Softlab
Да, станет. Это неизбежная эволюция, вызванная тремя факторами:
Максим Анненков, Security Vision
Да. Нормализация сама по себе не гарантирует, что данные полны и пригодны для детекта. Контроль состояния источников, стабильности потока и качества детектов постепенно станет базовой функцией SIEM. Но я бы не сводил ее к одному непрозрачному индексу качества: полезнее набор объяснимых метрик, связанных с конкретными источниками и правилами. По сути, качество данных становится частью Detection Engineering и эксплуатации SOC.
Денис Лобанов, Positive Technologies
Выбирая SIEM-систему сегодня, заказчики ориентируются не на формальную способность обработать как можно больше событий, а на реальную способность обеспечить киберустойчивость при одновременном снижении общих затрат на внедрение, поддержку и эксплуатацию системы (ТСО). Строить качественный мониторинг, собирая все подряд – не оптимальный подход как в плане аппаратных ресурсов, так и в плане ресурсов SOC. В таких условиях вендоры SIEM сами заинтересованы в том, чтобы обеспечивать максимальный уровень обнаружения атак. А именно – в том, чтобы оценивать приоритеты подключения источников, правильность настроек аудита, помогать SOC клиента подключать источники с помощью ИИ-ассистентов и интерактивных подсказок.
Борис Осепов, "Лаборатория Касперского"
Мы уже относимся к оценке качества данных как к обязательному функционалу. В Kaspersky SIEM автоматически отслеживаются изменения потоков событий от источников, настраиваются метрики пайплайна обработки событий (очереди, ошибки нормализации и др.). При этом даже с ошибкой нормализации событию предоставляется второй шанс – оно будет сохранено в сыром виде.
Не думаю, что этот вопрос следует задавать в будущем времени: оценка качества входных данных уже стала одним из обязательных критериев для многих предприятий при выборе SIEM. Сейчас все больше заказчиков интересуются вопросами: есть ли уведомления, если источник перестал присылать события, и как можно оперативно увидеть аномалию в событиях определенного источника. Без этого любая корреляция может стать бесполезной.
Павел Пугач, "СерчИнформ"
Нормализация и корреляция – функции, без которых SIEM объективно не может выполнять задачи. Недаром они стали стандартом для SIEM с 2005 г., когда только появился такой класс. В то же время пять лет назад среди обязательных требований к SIEM называли, например, функционал UBA. Но рыночным стандартом его наличие так и не стало. Реальную пользу от новых технологий в сложившемся классе продуктов можно оценивать, когда хайп утихает и появляются рабочие реализации. Так и с оценкой входных данных: чтобы стать маст-хэвом для рынка, она должна качественно поменять работу SIEM. А это только предстоит увидеть.
Николай Лишке, ГК "Эшелон"
Да, но сначала – именно в рамках SOC. Для зрелых SOC оценка качества уже стала такой же базовой функцией SIEM, как нормализация и корреляция, хотя формально это еще не закреплено стандартами. При этом стандартом является не отдельный функционал, а связка "источник – правила поступления событий – сценарий детектирования" с непрерывным контролем, историей деградаций и оценкой влияния на правила. Для зрелых SOC такой подход уже реализован и используется. Для российских SIEM мой прогноз – ближайшие 2–3 года.
Афанасий Клюнков, NGR Softlab
Да, станет. Это неизбежная эволюция, вызванная тремя факторами:
- ИИ и автоматизация: качество работы ML и генеративного ИИ напрямую зависит от "чистоты" данных. Без валидации входных потоков интеллектуальные функции SIEM будут генерировать шум и ложные срабатывания.
- Рост числа источников: гетерогенные инфраструктуры порождают колоссальный объем неструктурированных данных. Без автоматической проверки полноты и формата SIEM превратится в черную дыру для логов, где ошибки источников маскируются под угрозы.
- Контроль как основа доверия: заказчики все чаще требуют формальных метрик качества (например, дефицит логирования). SIEM будущего будет не просто коррелировать события, но и давать объективную оценку их достоверности, превращая контроль качества данных в ядро платформы.
Максим Анненков, Security Vision
Да. Нормализация сама по себе не гарантирует, что данные полны и пригодны для детекта. Контроль состояния источников, стабильности потока и качества детектов постепенно станет базовой функцией SIEM. Но я бы не сводил ее к одному непрозрачному индексу качества: полезнее набор объяснимых метрик, связанных с конкретными источниками и правилами. По сути, качество данных становится частью Detection Engineering и эксплуатации SOC.
Денис Лобанов, Positive Technologies
Выбирая SIEM-систему сегодня, заказчики ориентируются не на формальную способность обработать как можно больше событий, а на реальную способность обеспечить киберустойчивость при одновременном снижении общих затрат на внедрение, поддержку и эксплуатацию системы (ТСО). Строить качественный мониторинг, собирая все подряд – не оптимальный подход как в плане аппаратных ресурсов, так и в плане ресурсов SOC. В таких условиях вендоры SIEM сами заинтересованы в том, чтобы обеспечивать максимальный уровень обнаружения атак. А именно – в том, чтобы оценивать приоритеты подключения источников, правильность настроек аудита, помогать SOC клиента подключать источники с помощью ИИ-ассистентов и интерактивных подсказок.
Борис Осепов, "Лаборатория Касперского"
Мы уже относимся к оценке качества данных как к обязательному функционалу. В Kaspersky SIEM автоматически отслеживаются изменения потоков событий от источников, настраиваются метрики пайплайна обработки событий (очереди, ошибки нормализации и др.). При этом даже с ошибкой нормализации событию предоставляется второй шанс – оно будет сохранено в сыром виде.
