Практика внедрения и эксплуатации SIEM

SIEM остаётся одним из ключевых инструментов в арсенале информационной безопасности, однако между покупкой лицензии и реальным мониторингом угроз лежит пропасть. Слишком часто компании внедряют систему, а на выходе получают дорогостоящее хранилище логов, которое никто не анализирует. Причины разные: отсутствие квалифицированного персонала, попытки «подключить всё и сразу», полное игнорирование процессов реагирования.

Когда SIEM действительно оправдан, а когда это избыточное решение? Какие ошибки на этапе внедрения гарантированно превращают систему в бесполезную «коробку»? Как выстроить приоритеты подключения источников, чтобы система начала приносить пользу в первые месяцы? Какие метрики убедят не только CISO, но и бизнес? И что на практике стоит за словами «ИИ внутри SIEM»: реальный инструмент или маркетинговый шум?

Редакция CISOCLUB обсудила эти и другие вопросы с экспертами. Специалисты рассказали, как определить, когда SIEM становится необходимостью, какие ошибки совершаются чаще всего, как измерять эффективность и к чему готовиться в ближайшие годы. Своими наблюдениями и рекомендациями поделились:

• Максим Кириенко, руководитель технического пресейла компании VolgaBlob.
• Алексей Федоров, руководитель практики внедрения решений для центров мониторинга и реагирования на инциденты ИБ STEP LOGIC.
• Иван Бурмистров, пресейл-инженер компании UDV Group.
• Юрий Тюрин, технический директор MD Audit (SL Soft FabricaONE.AI, акционер: ГК Softline).
• Илья Куриленко, заместитель генерального директора по развитию компании «Анлим».
• Иван Барановский, руководитель группы поддержки продаж/пресейл компании «АйТи Бастион».
• Михаил Шеховцов, руководитель центра мониторинга ИБ Бастион.
• Елизавета Кузнецова, ведущий системный инженер TS Solution.
• Юлия Сонина, старший аналитик Аналитического центра УЦСБ.
• Андрей Новиков, руководитель отдела систем и сервисов iTPROTECT.
• Виталий Фомин, директор центра управления безопасностью информации, Группа Rubytech.
• Илья Одинцов, менеджер по продукту, компания NGR Softlab.
• Руслан Рахметов, СЕО Security Vision.
• Максим Деев, технический директор ARinteg.
• Павел Першин, руководитель группы систем анализа и контроля безопасности ИТ-компании УЦСБ.
• Анна Трохалева, руководитель направления анализа инцидентов информационной безопасности УЦСБ SOC.

Когда компании реально нужен SIEM, а когда это избыточное решение?

Вопрос кажется простым, но ответы экспертов демонстрируют принципиальное расхождение. Одни считают, что без SIEM сегодня не обойтись практически никому. Другие предупреждают: система без процессов и людей — пустая трата бюджета. Между этими полюсами — набор конкретных критериев, привязанных к масштабу инфраструктуры, зрелости процессов ИБ и требованиям регуляторов.

Самую радикальную позицию занял Максим Кириенко, руководитель технического пресейла компании VolgaBlob:

«Компаний, которые не нуждались бы в SIEM, практически не осталось — если, конечно, не говорить о микропредприятиях, где работает меньше 10 человек и нет взаимодействия с ИТ-инфраструктурой. Да, целенаправленных атак на малый бизнес будет значительно меньше, но риски полностью не исчезают. Сегодня на рынке представлены SIEM-решения, которые позволяют даже небольшим организациям выстроить собственную систему мониторинга событий ИБ либо обратиться к экспертам внешнего SOC для защиты периметра».

Противоположная точка зрения у Павла Першина, руководителя группы систем анализа и контроля безопасности ИТ-компании УЦСБ: внедрение SIEM должно решать чётко поставленные цели. Как правило, SIEM решает проблему консолидации данных из разных источников — это помогает специалистам по ИБ оперативно выявлять угрозы и реагировать на них. Если не внедрены необходимые СЗИ (средства защиты информации) или они не настроены должным образом, если нет квалифицированного персонала для постоянного мониторинга и донастройки, от системы не будет пользы. Перед внедрением SIEM в организации уже должен быть наведён порядок; попытка упорядочить хаос с помощью SIEM не работает. Система выявляет угрозы путём корреляции событий от разных типов источников, но если в компании нет человека, который понимал бы угрозы и мог реагировать, она станет балластом — избыточным ИТ-активом, из которого не извлекают пользу.

Между этими крайностями находится большинство экспертов, которые формулируют конкретные условия.

Пороги и триггеры: когда SIEM становится необходимостью

Несколько экспертов назвали конкретные цифры, привязанные к масштабу инфраструктуры.

Елизавета Кузнецова, ведущий системный инженер TS Solution, определила: SIEM нужен, когда у компании возникает ощущение присутствия угрозы при невозможности её верификации — отдельные системы сигнализируют об аномалиях, но собрать из разрозненных фрагментов цельную картину инцидента не получается. Реально SIEM нужен в двух случаях. Первый — когда количество источников событий (серверы, СЗИ, сетевое оборудование) превышает возможности человека удерживать картину в голове. По её наблюдениям, этот порог наступает в компаниях от 300–500 сотрудников, где ИТ-инфраструктура перестаёт быть линейной. Второй — когда появляется потребность в глубоком расследовании инцидентов.

«Если инцидент требует ответа не только на вопрос «что украли», но и на вопросы «как зашли» и «кто виноват», восстановить хронологию событий без SIEM практически нереально. SIEM становится избыточным, если уровень зрелости компании до него еще не дорос. Бессмысленно внедрять его там, где не настроен элементарный сбор логов с контроллера домена. Это как приобрести профессиональный инструмент, не имея базовых навыков работы — результата не будет. Кроме того, SIEM требует выделенного ресурса: даже обычное «коробочное» решение нуждается в донастройке под конкретную инфраструктуру, и если вы не готовы выделить на это человека хотя бы на полставки, система так и останется дорогой игрушкой».

Юрий Тюрин, технический директор MD Audit, указал: SIEM необходим компаниям со сложной распределённой инфраструктурой, несколькими площадками, удалённым доступом, облачными сервисами и повышенными требованиями регуляторов. Если у организации более 200–300 рабочих станций, есть доменная инфраструктура, VPN, публичные сервисы и критичные данные, без централизованной корреляции событий контролировать безопасность практически невозможно. В таких условиях SIEM становится ядром SOC. При этом он рекомендовал перед покупкой провести аудит логирования, оценить объём событий в сутки, определить 10–15 приоритетных сценариев атак и только после этого принимать решение. SIEM — это не «коробка», а процесс с командой и регламентами. Избыточным SIEM может быть для малого бизнеса с простой сетью и минимальным числом сервисов — там выгоднее использовать MDR (Managed Detection and Response) / MSSP (Managed Security Service Provider) или встроенные инструменты мониторинга.

Иван Бурмистров, пресейл-инженер компании UDV Group, указал: SIEM становится необходимым в «зрелых организациях» — когда специалисты по ИБ осознают, что не способны вручную обрабатывать события и требуется автоматизация. Определяющий фактор — количество источников информации и объём данных, в частности количество событий в секунду (EPS). Он проиллюстрировал разницу на двух примерах:

«Есть организация, в которой работает около 60 человек, у каждого — своя рабочая станция. Используются межсетевой экран, антивирус с централизованной системой управления, контроллер домена, почтовый сервер. Три специалиста ИТ/ИБ способны анализировать происходящее и сопоставлять данные четырёх источников. В данном случае внедрение SIEM будет избыточным. Но когда организация вырастает до 500 человек, открывается второй офис, организуется защищённое подключение с офисом в другом городе, добавляются CRM, DLP, системы анализа уязвимостей и мониторинга сетевого трафика (NTA-решения) — количество источников растёт. Анализ входящего потока требует не только увеличения числа сотрудников, но и постоянного развития их компетенций по каждому источнику. В этой точке ИБ-отдел может прийти к выводу о необходимости автоматизации мониторинга и обработки событий. Ценность и необходимость SIEM прямо пропорциональны количеству подключаемых к ней источников информации».

Юлия Сонина, старший аналитик Аналитического центра УЦСБ, отметила: при масштабировании компании SIEM становится главным помощником специалистов ИБ в области обнаружения, ранжирования и контроля обработки инцидентов. Когда число устройств превосходит сотню, а инфраструктура усложняется за счёт облачных решений и геораспределённых площадок, анализ логов перестаёт быть посильной для человека задачей. SIEM является избыточным для бизнеса с простой, не разнообразной ИТ-инфраструктурой, небольшой командой, взаимодействующей с этой инфраструктурой, не попадающего под обязательства к выполнению регуляторных требований о применении технологии и не обрабатывающего критические данные. В пограничных случаях владельцу бизнеса нужно ответить на вопрос, что будет дороже — последствия и восстановление после инцидента ИБ или внедрение и эксплуатация системы. Для этого необходимо грамотно оценить вероятность возникновения подобного события, провести оценку рисков, включая репутационные, определить, является ли бизнес владельцем критических данных, и если да — оценить, какие данные в компании являются наиболее ценными и к каким последствиям приведёт их потеря. В результате необходимо принять взвешенное решение о внедрении или отказе от SIEM и определить условия, при которых будет принято решение о внедрении SIEM-системы.

Впрочем, не все согласны, что размер компании — определяющий фактор. Максим Деев, технический директор ARinteg, разделил потребность на две категории: регуляторную (выполнение требований по защите ПДн (персональных данных) или объектов КИИ (критической информационной инфраструктуры)) и техническую (когда разнородные системы перестают поддаваться ручному контролю). При этом потребность не всегда коррелирует с размером: небольшая организация с множеством веб-серверов, собственных разработок и удалённых пользователей может испытывать острую необходимость в SIEM; а крупная компания с разрозненными площадками нуждается в нём, чтобы связать инциденты в единую картину. Избыточным решение становится лишь тогда, когда инфраструктура проста, а цели внедрения сводятся исключительно к «моде», а не к реальной потребности в автоматизации анализа угроз.

Требования регуляторов надо выполнять

Помимо Максима Деева из ARinteg, отдельный драйвер, связанный с требованиями регулятора подчеркнул Иван Бурмистров (UDV Group): для организаций, подпадающих под ФЗ-152, ФЗ-187 и приказы ФСТЭК России № 17, 21, 31, SIEM фактически обязателен.

Алексей Федоров, руководитель практики внедрения решений для центров мониторинга и реагирования на инциденты ИБ STEP LOGIC, сформулировал двойной критерий: SIEM нужен, когда в компании есть процессы управления событиями ИБ и сотрудники, участвующие в них. С другой стороны, когда регуляторы обязывают собирать и обрабатывать события ИБ, без решений такого класса закрыть эту потребность будет сложно или практически невозможно.

Андрей Новиков, руководитель отдела систем и сервисов iTPROTECT, подошёл к вопросу с позиции автоматизации: SIEM нужен тогда, когда в компании есть процессы, которые можно и нужно автоматизировать, и когда управлять ими вручную невыгодно. SIEM точно необходим для чёткого выполнения регуляторных требований к объектам КИИ, госорганам, операторам ПДн. Также SIEM необходим компаниям с территориально-распределённой инфраструктурой, десятками филиалов, сотнями серверов и множеством средств защиты — без него невозможно коррелировать события и выявлять комплексные атаки. Кроме того, SIEM позволяет быстро реагировать на инциденты и автоматически выявлять подозрительные паттерны. В однородных инфраструктурах с контроллером домена и несколькими серверами мониторинг проще настроить встроенными средствами ОС или бесплатными утилитами. Помимо этого, в отсутствие зрелых процессов ИБ SIEM превратится в «игрушку», генерирующую тонны бесполезных срабатываний.

Результативность SIEM зависит от состояния СУИБ

Руслан Рахметов, СЕО Security Vision, указал, что целесообразность закупки должна определяться в первую очередь бизнес-потребностями компании, зрелостью процессов ИБ и оценкой киберрисков, показавшей экономическую обоснованность для снижения финансового ущерба путём сокращения времени выявления и реагирования на атаки с помощью SIEM. SIEM нужна, если в компании уже существует процесс управления киберинцидентами и специалистам нужен инструмент автоматизации. Результативность SIEM зависит от состояния СУИБ (системы управления информационной безопасностью) компании, работоспособности имеющихся СЗИ и готовности бизнеса корректировать процессы. При оценке инвестиции нужно учитывать капитальные и операционные расходы, включая затраты на оборудование, лицензии, внедрение, первичную настройку и сопровождение, а также администрирование и эксплуатацию квалифицированными специалистами для оперативного реагирования на выявленные инциденты и непрерывной донастройки (источники событий, правила нормализации и корреляции, исключения, отчёты, дашборды). Если компания планирует собственный SOC, следует заранее оценить его структуру и функционал — они повлияют на архитектуру SIEM, включая обеспечение отказоустойчивости, резервирования и высокой доступности. Без SIEM можно обойтись в случае небольшой гомогенной инфраструктуры с решениями от двух-трёх вендоров, управляемыми через встроенные консоли или XDR; альтернативой может стать система класса NG-SOAR (Next Generation Security Orchestration, Automation and Response), включающая функционал парсинга, нормализации и корреляции событий с автоматизированным реагированием на инциденты.

Что должно быть до SIEM

Несколько экспертов акцентировали внимание на том, что без фундамента SIEM превращается в бесполезное хранилище логов.

Виталий Фомин, директор центра управления безопасностью информации Группы Rubytech, напомнил, что SIEM — это инструмент мониторинга для обеспечения ИБ, однако его внедрение оправдано не всегда. При низком уровне зрелости ИБ, когда отсутствуют базовые процессы защиты и нет инвентаризации активов, SIEM не даст результата. Ещё одна встречающаяся ошибка — отсутствие команды для работы с SIEM: организация приобретает её в надежде, что она всё сделает автоматически. В итоге SIEM генерирует огромное количество шума и тысячи предупреждений, а без их анализа и расследования превращается в дорогостоящего, но бесполезного наблюдателя. В лучшем случае система становится простым сборщиком логов, до которого когда-нибудь дойдёт очередь. Среди объективных триггеров он выделил два: уровень зрелости компании, позволяющий оценивать риски ИБ (недоступность сервисов, утечки данных и т.д.) и использовать инструменты для мониторинга и своевременного выявления инцидентов ИБ, и требования нормативно-правовых актов Российской Федерации, причём последние действуют даже при отсутствии необходимой зрелости и квалифицированного персонала, делая SIEM обязательным элементом, который сложно игнорировать.

Илья Куриленко, заместитель генерального директора по развитию компании «Анлим», напомнил, что SIEM — это система мониторинга, не способная самостоятельно блокировать угрозы. Полезность решения зависит от наличия в компании ИБ- и ИТ-специалистов, а также их навыков: система может «кричать о пожаре», но если персонал не способен интерпретировать полученную информацию, толку не будет. Перед внедрением лучше отстроить процессы межсетевого экранирования, обнаружения и предотвращения вторжений, антивирусной защиты и управления уязвимостями:

«Был случай из практики компании, когда даже при наличии комплекса средств защиты информации — SIEM, AV, NGFW, NTA, WAF, Sandbox — во время тестирования удалось за пару часов взломать ЦОД со всеми критичными системами. Иногда на это уходило и несколько минут. Важна грамотная настройка имеющихся ИБ-решений, а также ИТ-инфраструктуры в целом (харденинг). Тогда у «безопасника» появится время на обнаружение и реагирование на атаку. Иными словами, нужно увеличивать продолжительность хакерской атаки и уменьшать время обнаружения злоумышленника. Последнее достигается за счёт грамотной настройки систем мониторинга и обучения персонала».

Илья Одинцов, менеджер по продукту NGR Softlab, предложил считать ресурсы прагматично: SIEM — сложный продукт, и сколько бы ни было правил из коробки, они бесполезны, если компания не готова адаптировать их под свой бизнес. Любой набор типовых правил становится бесполезным, когда вас атакуют по новой схеме — практика показывает, что очень часто именно так и пропускают атаки. Для работы с SIEM нужны выделенные аналитики, а злоумышленник не будет ждать начала рабочего дня или выхода с праздников, отпуска, больничного. Если инфраструктура генерирует несколько тысяч EPS, в выходные накапливается объём, который в понедельник надо разбирать. Вендоры борются с массовыми ложными срабатываниями на правилах для снижения нагрузки на аналитиков, но при этом необходимо учитывать: 700 включённых правил дают в семь раз больше «мусора», чем 100 хорошо отточенных. Немало примеров, когда заказчику удавалось предотвратить первую атаку, но затем следовали повторные — уже успешные, потому что просто не смогли их детектировать из-за нехватки данных. Не стоит забывать и о хранении: по статистике злоумышленник находится в сети от трёх месяцев до года в зависимости от размеров инфраструктуры, а значит, при подозрениях придётся искать за длительный срок. Также стоит принимать во внимание объём СЗИ: чем их больше, тем прозрачнее картина. Служба каталогов, NGFW и антивирус — это три «окна», и дешевле следить за ними напрямую, чем нанимать аналитика, покупать SIEM и выделять ресурсы. Автоматизированные решения класса EDR/XDR для многих будут неплохим выходом. Если у компании нет людей, идёт ранний этап формирования ИБ-культуры и небольшое количество СЗИ, такие инструменты дадут эффект. При этом работа с персоналом в виде повышения киберкультуры однозначно принесёт больший результат, чем установка SIEM без полноценного внедрения.

SIEM сам по себе безопасность не создаёт

Иван Барановский, руководитель группы поддержки продаж/пресейл компании «АйТи Бастион», подытожил:

«Если совсем просто — SIEM нужен тогда, когда безопасность перестаёт быть «по чуть-чуть» и становится системной. Пока инфраструктура небольшая, всё более-менее прозрачно и событий немного, можно обойтись без него. Но как только появляется много серверов, сервисов, сетевого оборудования, учётных записей пользователей — вручную уже ничего не проконтролируешь. Начинается хаос в логах, нет общей картины. Вот в этот момент SIEM становится не роскошью, а необходимостью. Плюс есть регуляторные требования — в ряде отраслей (КИИ, госсектор) централизованный сбор и хранение логов просто обязателен. А избыточным SIEM может быть в маленькой компании с простой инфраструктурой и невысокими рисками, особенно если нет людей, которые будут этим заниматься. Потому что SIEM сам по себе безопасность не создаёт — он работает только там, где есть процесс и ответственность».

Какие ошибки при внедрении SIEM приводят к тому, что система есть, а мониторинга фактически нет?

Главная ошибка, на которую указали практически все эксперты: восприятие SIEM как «коробки», которую достаточно установить. Следом идут отсутствие квалифицированного персонала, подключение источников без стратегии, игнорирование тюнинга коробочных правил и отсутствие процесса реагирования. Отдельная системная проблема: разрыв между установкой SIEM (занимает дни) и полноценным внедрением (занимает месяцы).

«Поставили и забыли»: ключевое заблуждение

Иван Бурмистров, пресейл-инженер компании UDV Group, обозначил корень проблемы: заказчики не видят разницы между установкой SIEM и полноценным внедрением. Установка может занять один день, тогда как внедрение растягивается на месяцы и включает определение перечня источников информации и их приоритизацию (что и в какой последовательности подключается), настройку оповещений и корреляционных правил с учётом специфики организации. Необходимо сформировать перечень недопустимых событий и корректно задать критерии их выявления. Распространённое заблуждение, что достаточно установить SIEM и мониторинг заработает «из коробки». На практике правила корреляции требуют индивидуальной настройки, так же, как и в любой другой системе мониторинга.

Ту же проблему видит Иван Барановский, руководитель группы поддержки продаж/пресейл компании «АйТи Бастион»: чаще всего SIEM воспринимают как «поставили и забыли» — купили, внедрили, показали аудитору, и на этом всё. Логи собираются, отчёты есть, а реальной аналитики и реакции нет. Иногда не подключают критичные системы; иногда настраивают типовые правила и не адаптируют их под свою инфраструктуру. В итоге система либо заваливает ложными алертами, которые перестают разбирать, либо почти ничего не показывает. Отдельно он выделил проблему привилегированного доступа: без связки SIEM и PAM (Privileged Access Management — управление привилегированным доступом) картина получается неполной. SIEM фиксирует факт использования админской учётной записи, но без PAM непонятно, кто именно стоял за сессией, что конкретно делал администратор, была ли заявка и было ли согласование. Если эти системы не интегрированы, часть контекста теряется. Если нет ответа на вопрос «кто реагирует и в какие сроки», даже хорошая интеграция не спасёт. Технологии работают только там, где вокруг них выстроена ответственность.

Требуется не только полноценный SOC?

Михаил Шеховцов, руководитель центра мониторинга ИБ Бастион, сместил акцент: «Это не ошибка внедрения системы, а результат решения внедрить SIEM без организации службы мониторинга или покупки услуг MSSP SOC. На основе подобной практики образуются системы, к которым подключен самый минимум мониторингового ПО или наоборот, множество второстепенных программ без основных систем. Как правило, подобные системы либо находятся в зоне ответственности службы мониторинга, не обладающей достаточным опытом, формализованным SLA и пониманием ответственности за ложноотрицательные срабатывания, либо фактически остаются без внимания. Причина в том, что вручную обработать столь значительный и «шумный» поток событий объективно невозможно. Для обеспечения хотя бы минимального уровня автоматизации требуется не только полноценный SOC с отделом аналитиков угроз, но и подразделение специализированной автоматизации, которое может переложить расследование в ранбуки системы автоматизации или напрямую в код».

Люди, процессы, технологии — именно в таком порядке

Максим Кириенко, руководитель технического пресейла компании VolgaBlob, описал типичную ситуацию:

«SIEM внедрён, причём профессиональным партнёром, подключены все источники, настроены корреляционные правила, налажена генерация инцидентов. Но вся дальнейшая реакция и активные действия ложатся на плечи заказчика. Если его команда не готова оперативно реагировать на инциденты — система бесполезна. Инцидент может быть обнаружен в течение минуты, но если сотрудник, который должен заблокировать злоумышленника, в отпуске и заменить его некем — быть беде».

Проблема, по его словам, решается автоматизацией или передачей функций внешнего управления инфраструктурой, однако к этому приходят не все.

Илья Одинцов, менеджер по продукту, NGR Softlab, расставил приоритеты жёстко: первая и самая главная ошибка — люди (если некому работать с системой, она становится бесполезна; самые эффективные правила написаны конкретно под вашу компанию), вторая — процессы (если ИТ продолжает жить своей жизнью и новые ИС (информационные системы) не подключаются оперативно на мониторинг, теряется прозрачность сети; реагирование должно быть быстрым — дни на поиск ответственных и часы на согласование недопустимы; для соблюдения SLA не нужна дорогущая IRP-система (Incident Response Platform) — достаточно описанных процессов; даже крупные SOC используют опенсорс-платформы для контроля SLA, но это лишь инструменты — без самих процессов они бесполезны), третья — технологии:

«Следовать технологичным трендам и решать задачи — это не одно и то же. «Модный SIEM от крупного вендора», «может обрезать лишние поля, хранить данные, эффективно их сжимая» — звучит красиво, не так ли? Но что делать, если «отрезанные» поля как раз и содержали необходимую информацию, а поиск доступен только по известным полям в схеме, да и тот ограничен небольшим сроком или объёмом? Тысячи или десятки тысяч событий в секунду объёмом 3–4 Кбайта занимают много места, особенно в RAW, но именно эти данные позволят вам детектировать новые угрозы и эффективно реагировать так, чтобы через пару месяцев атака не повторилась».

Человеческий фактор подчеркнули и другие. Илья Куриленко, заместитель генерального директора по развитию компании «Анлим», Алексей Федоров (STEP LOGIC) и Виталий Фомин (Группа Rubytech) сходятся в одном: без подготовленного персонала внедрение — деньги на ветер. Куриленко отмечает: компании выделяют миллионы на покупку SIEM, но не находят времени и денег на обучение сотрудников на киберполигонах или тренажёрах, где можно выявлять инциденты и подготовиться к работе с продуктом. Федоров назвал самой очевидной ошибкой «внедрение для галочки» и добавил, что полнота журналирования, качество источников событий информационной безопасности, понимание инфраструктуры и релевантность корреляционных правил — составляющие, как успешного внедрения системы класса SIEM, так и впустую потраченных денег. Отдельно он отметил ошибку — внедрение SIEM без обучения персонала. Фомин указывает: при проектировании не учитываются необходимые источники событий ИБ и скорость их поступления, в результате решение оказывается неполноценным и не покрывает критичные для бизнеса сценарии; не все источники настроены на передачу событий, а сотрудники не имеют компетенций для работы с системой — не понимают, как настраивать фильтры и правила корреляции. В результате SIEM есть, а рабочего процесса нет: персонал не умеет сопровождать систему, работать в ней и развивать её.

Павел Першин, руководитель группы систем анализа и контроля безопасности ИТ-компании УЦСБ, резюмировал: главные ошибки — отсутствие квалифицированного персонала и выстроенной политики ИБ, когда нет понимания, что является инцидентом, нет ответственных за системы, нет регламента реагирования. Нельзя допускать и того, чтобы подключение источников осуществлялось для галочки или зафиксированные события никоим образом не использовались при обнаружении угроз. Ошибочно полагаться только на коробочную экспертизу: правил в «коробке» много, но мало какие помогут без дальнейшего тюнинга, настройки исключений и так далее.

Технические ошибки: от «подключить всё» до «подключить не то»

Елизавета Кузнецова, ведущий системный инженер TS Solution, перечислила три ключевые ошибки:

«Главная ошибка — попытка «подключить всё и сразу». На моём опыте были проекты, где в первый месяц начинали собирать логи с принтеров и всего, что попадётся под руку, вместо того чтобы настроить критически важные источники. В результате к третьему месяцу команда тонет в шуме, правила корреляции не работают, а SIEM превращается в дорогую свалку логов. Вторая фатальная ошибка — игнорирование нормализации данных. Многие считают: «Лишь бы лилось, а там разберёмся». Не разберётесь. Когда в одном поле «User» приходит «ivanov.p», «IVANOV_P» и «DOMAIN\ivanov», расследование инцидента превращается в квест. Нужно сразу закладывать время на приведение данных к единому стандарту. Третья ошибка — отсутствие приоритизации алертов. Если у вас 1000 срабатываний в день и все критические — значит, критических нет. Система без приоритезации критичности быстро надоедает аналитикам, и они перестают в неё заходить».

Проблему нормализации подтвердил Андрей Новиков, руководитель отдела систем и сервисов iTPROTECT: по его словам, ключевые ошибки при внедрении SIEM связаны с тем, что получаемые данные невозможно использовать для обнаружения атак. Отдельная проблема — отсутствие нормализации и обогащения: если события приходят в сыром виде, а поля не приведены к единому формату, коррелировать данные между разными источниками невозможно, да и аналитику не под силу разобрать поток сырых событий вручную. Компания подключает все источники подряд без фильтрации и получает белый шум вместо осмысленных результатов: система тонет в тысячах событий, критичные логи теряются, а команда нередко не проверяет, действительно ли система детектирует реальные атаки, в итоге некорректность коробочных правил выясняется уже по факту инцидента. Ещё одна ошибка — попытка с первого дня строить сложные корреляционные сценарии: это приводит к огромному количеству ложноположительных срабатываний, команда быстро выгорает и перестаёт воспринимать SIEM как рабочий инструмент. Отдельная проблема — организационная: если нет владельца процесса, после внедрения может выясниться, что некому отвечать за настройку правил, анализ инцидентов и обновление логики под новые угрозы, и система устаревает морально уже через месяц, теряя данные об активах и источниках событий. В практике iTPROTECT были случаи, когда после такого приходилось перенастраивать дорогостоящее решение буквально с нуля.

Максим Деев, технический директор ARinteg, отметил, что подавляющее большинство проблем, после которых SIEM превращается в бесполезную «коробку», связано не с самой системой или настройкой корреляции, а с некорректным выбором источников событий и глубиной их подключения. Первая крайность — недостаточное количество источников: на рабочих станциях не включён расширенный аудит, либо ведётся сбор логов с контроллеров домена без детализации действий, политики собирают лишь «вершки», по которым невозможно выстроить и раскрутить цепочку инцидента до самого конца. Вторая крайность — избыточный «шум», когда SIEM захламлён миллионами событий и аналитику невозможно выделить критичные сигналы; из-за обилия информационного мусора система перестаёт выполнять свою главную функцию — обнаружение атак. Чтобы мониторинг был реальным, а не фиктивным, необходимо подключить базовый минимум, который часто остаётся без контроля: рабочие станции пользователей, сетевое оборудование (коммутаторы, маршрутизаторы) и межсетевые экраны. Критически важно убедиться, что система позволяет вручную раскручивать любую цепочку событий: если вы можете получить исчерпывающую информацию о любом действии в инфраструктуре за счёт смежных событий, значит, SIEM работает; если нет, значит, вы либо подключили не те источники, либо настроили их поверхностно.

Среди технических ошибок Илья Куриленко (компания «Анлим») также выделил: отсутствие анализа того, что защищаем и какие критичные системы требуют мониторинга в первую очередь с последующим переносом этих знаний на уровень SIEM и проведением управления активами (asset management); непонимание, какие элементы инфраструктуры подключать к SIEM — это межсетевые экраны, домен, сетевое оборудование, операционные системы, средства антивирусной защиты, СУБД, веб-ресурсы, системы виртуализации, системы управления инфраструктурой и оборудованием, а также иные средства защиты информации; необдуманную отправку всех событий с источника — ярким примером служит подключение NGFW, когда никаких технических ресурсов и лицензий не хватает, чтобы прервать поток событий с него; обратную ситуацию — недостаточно полную настройку источника; отсутствие исключений — из-за этого SIEM оказывается завалена тысячами ложноположительных срабатываний; а также слабого вендора или ненастроенные пакеты экспертизы — коробочные правила корреляции должны давать 90% эффективности, а рассчитывать на то, что специалист оперативно настроит всю экспертизу с нуля, крайне опрометчиво.

Системные ошибки: от проекта до поддержки

Руслан Рахметов, СЕО Security Vision, систематизировал ошибки в пять категорий. Первая — отсутствие полноценного проекта внедрения: без аудита процессов ИБ, инфраструктуры и настроек имеющихся СЗИ, оценки достаточности аппаратных ресурсов и лицензий, прогноза суммарного EPS, разработки сценариев использования, методического сопровождения внедрения (разработка ролевой модели, инструкций, политики управления киберинцидентами) и критериев успеха проекта с точки зрения бизнес-заказчиков проект теряет смысл. Вторая — отсутствие конструктивного взаимодействия между заказчиками, исполнителями, подрядчиками, руководителями и ИТ/ИБ-специалистами компании. Третья — экономия на процессах: без планомерного повышения уровня зрелости процесса управления киберинцидентами и смежных процессов (управление активами, уязвимостями, конфигурациями, изменениями) результаты SIEM не будут корректно обработаны, инциденты не будут полностью и в срок устранены, а общий уровень киберзащищённости компании не будет постепенно повышаться. Четвёртая — экономия на кадрах: без должной экспертизы инженеров, администраторов и операторов система не покажет результат, даже если по итогам внедрения была настроена идеально. Настройки нужно непрерывно актуализировать — добавлять источники при появлении новых элементов инфраструктуры, контролировать стабильную передачу событий, актуализировать правила корреляции в зависимости от новых тенденций, техник и инструментария атакующих. Пятая — «захламление» ложноположительными срабатываниями: в первые месяцы это вероятно, и это не должно разочаровывать — внесение исключений и корректировка настроек должны сопровождать весь жизненный цикл SIEM-системы, которая призвана быть не бесполезным архивом разрозненных событий, а системой оперативного реагирования и проактивной защиты.

Юлия Сонина, старший аналитик Аналитического центра УЦСБ, перечислила пять типичных ошибок. Первая — отсутствие у менеджмента понимания практической цели: чаще всего это случается, когда система внедрена для соответствия требованиям регулятора, а целевое применение не учитывается и не прорабатывается. Вторая — нехватка квалифицированных кадров: на задачу ставят сотрудника без опыта работы с системой, обучение не организовано; сюда же относится общий недостаток кадров для этой задачи — роли распределяются хаотично, происходит перегрузка персонала и потеря контроля над процессом мониторинга и реагирования. Третья — отсутствие контрактов на сопровождение: SIEM — довольно сложная в эксплуатации система, и во время работы могут возникать нетривиальные технические проблемы, не описанные в руководстве администратора. Четвёртая — организационно-технические проблемы: не предоставлены необходимые доступы к оборудованию и системам — нередко потому, что руководители направления стараются дистанцироваться от ответственности; не учитываются бизнес-риски организации, а сбор информации настроен некорректно — либо собирают «по кусочкам» только то, что получилось подключить (целевые источники не обозначены), либо хаотично льют всё подряд, и ни система, ни аналитик не справляются с объёмом данных. Пятая — некорректная эксплуатация: неправильно настроенные правила корреляции и обработки событий, устаревшие правила, отсутствие паттернов актуальных атак, некорректно сформированное информирование об инцидентах и некорректно настроенные дашборды. Внедрение SIEM — комплексная задача, требующая как правильной организационной работы (все этапы должны быть чётко сформулированы, иметь конечную цель и исчислимые показатели), так и технической, и ресурсной проработки. Нужно быть готовым вкладывать ресурсы, в том числе кадровые, для достижения результата.

Юрий Тюрин, технический директор MD Audit, назвал три ключевые ошибки. Первая — внедрение без чёткой цели: компания подключает максимум источников, но не формирует приоритетные сценарии выявления атак. Вторая — отсутствие ответственной команды и регламентов реагирования: если некому анализировать алерты 24/7 и нет SLA на расследование, SIEM превращается в архив логов. Третья частая ошибка — отсутствие нормализации событий и тюнинга правил, из-за чего аналитики тонут в ложных срабатываниях. Его практический рецепт: начать с минимального, но качественного набора правил, провести baseline-инвентаризацию инфраструктуры и в первые три месяца активно заниматься тюнингом. Обязательно утвердить процесс реагирования: кто, в какие сроки и какие действия предпринимает при инциденте.

Как выстроить приоритеты подключения источников и разработки правил корреляции, чтобы SIEM начал приносить пользу в первые месяцы, а не через год?

Эксперты сходятся в нескольких базовых принципах: идти от рисков, а не от источников; работать итеративно, наращивая покрытие спринтами по 1–2 месяца; фокусироваться на ключевых источниках, дающих максимум детектов. Приоритетный набор источников у большинства экспертов схож: контроллеры домена, межсетевые экраны, VPN-шлюзы, почтовые серверы, EDR/антивирусы и пр. Стартовые правила: брутфорс, аномальные логины, эскалация привилегий, запуск подозрительных процессов и др.

Принцип: от рисков, а не от источников

Елизавета Кузнецова, ведущий системный инженер TS Solution, сформулировала три правила. По её словам, работать с источниками нужно системно — от рисков к «золотому фонду» и итеративному подходу:

«Правило первое: отталкивайтесь не от источников, а от рисков. Прежде чем подключать очередной сетевой элемент, спросите себя: какие три атаки для вас наиболее критичны? Компрометация домена? Утечка из финансовой системы? Шифровальщик на файловых серверах? Именно под эти сценарии мы в первую очередь настраиваем сбор логов и пишем корреляции. Всё остальное — по остаточному принципу. Правило второе: фокус на «золотой фонд» источников. Есть несколько типов данных, которые обеспечивают 80% детектирующей способности при минимальных затратах на интеграцию. Это контроллеры домена (логи аутентификации — базовая телеметрия любого SIEM), межсетевые экраны (видимость периметра) и антивирусы/EDR-решения (готовые алерты, которые не требуют сложной корреляции). Закрыв эти три направления, вы уже получаете работающую систему. Правило третье: итеративный подход вместо каскадного. Не пытайтесь настроить всё сразу. Работайте короткими спринтами. Первый месяц — только Active Directory, NGFW, три правила на брутфорс и аномальные логины. Второй месяц — добавляем EDR и корреляцию процессов. Уже через 60 дней у вас будет не хранилище логов, а инструмент, который реально ловит угрозы. Лучше иметь пять работающих правил, которые ловят реальные угрозы, чем сто правил, которые молчат или создают шум. SIEM — это не про количество подключенных источников, а про качество детекта».

Максим Кириенко, руководитель технического пресейла компании VolgaBlob, подтвердил: риск-ориентированный подход — ключевой. «Создавайте 20% правил, которые дадут 80% эффекта. Не нужно гнаться за количеством: достаточно 40–60 хорошо проработанных корреляционных правил, закрывающих самые критичные зоны — crown jewels организации. В первую очередь это защита критичных активов, доменов, VPN, почты и внешних точек доступа».

Павел Першин, руководитель группы систем анализа и контроля безопасности ИТ-компании УЦСБ, описал образцовый сценарий: определить угрозу → сформировать критерии её выявления (какие события или цепочки событий и с каких источников сигнализируют об угрозе) → получить список источников → определить настройки логирования — достаточные, но не избыточные → подключить и проверить → тюнить правила. Приоритет подключения зависит от критичности угроз, которые команда пытается закрыть. Он отметил: в реальности мало кто следует этому сценарию, так как он требует большого погружения и кропотливой работы.

Практические алгоритмы и порядок подключения

Илья Куриленко, заместитель генерального директора по развитию компании «Анлим», исходя из практики компании, предложил следующий алгоритм работы: 1) определить недопустимые события для бизнеса — важно сделать это без долгих рассуждений; 2) определить целевые системы — то есть те, атаки на которые могут привести к недопустимым событиям; 3) выявить системы, на базе которых функционируют целевые системы; 4) определить векторы атак на целевые системы . В результате при выполнении пунктов 2–4 формируется перечень приоритетных источников.

Иван Бурмистров, пресейл-инженер компании UDV Group, описал последовательность: сначала определить критические активы — например, рабочую станцию бухгалтера или директора, подсеть разработчиков ПО. Их перечень, как правило, формируют владелец бизнеса, совет директоров или топ-менеджмент, поскольку именно они определяют, какие ресурсы являются приоритетными для защиты. Затем определить основные векторы атак — от периметра сети до потенциального доступа к конкретному активу. Для каждой организации набор сценариев индивидуален, однако можно сформировать минимальный перечень источников, из которых поступает информация о подозрительной активности на критических активах: контроллер домена, почтовые серверы, межсетевой экран, центр управления антивирусом, DLP-система. Базовые сценарии: множественные неудачные попытки входа с последующим успешным логином, аномальный объём исходящего трафика, доступ к файлам вне рабочего времени. После этого подключаются прикладные источники информации — корпоративные приложения и системы мониторинга ИТ.

Андрей Новиков, руководитель отдела систем и сервисов iTPROTECT, предложил пошаговую методику. Этап 1: подключение источников с максимумом информации об атаках — контроллеры домена, межсетевые экраны и NGFW, прокси-серверы и шлюзы веб-безопасности, серверы с критичными базами данных и бизнес-системами, антивирусы, EDR, серверы VPN, DNS-серверы. Этап 2: разработка простых, но критичных правил корреляции — обнаружение брутфорса (много неудачных логинов с последующим успешным), создание пользователей в аномальные часы (например, ночью), запуск powershell.exe с пользовательской машины, добавление компьютера в домен неизвестным пользователем, несколько неудачных попыток логинов из разных стран за короткое время. Подключение базовых Threat Intelligence-фидов (для начала достаточно хотя бы базовых фидов с известными вредоносными IP/доменами (C2, майнеры, фишинг)) и назначение ответственного за SIEM в режиме 24/7. Если срабатывания никто не смотрит, система бесполезна. В первые месяцы достаточно, чтобы аналитик ежедневно проверял топ-10 алертов.

Юрий Тюрин, технический директор MD Audit, подчеркнул: начинать нужно с критичных активов: контроллеры домена, системы аутентификации, VPN, почтовые шлюзы, EDR, ключевые серверы приложений. Далее — сетевые устройства и облачные журналы. При разработке правил стоит ориентироваться на реальную модель угроз компании, а не на универсальный список. Практически это означает сначала закрыть сценарии компрометации учётных записей, эскалации привилегий, перемещения внутри сети и запуска вредоносного ПО. Подключение «всего подряд» создаёт шум и затягивает запуск пользы на год. Он рекомендовал внедрять SIEM итерационно, каждые 1–2 месяца добавляя новые источники и сценарии с параллельной оценкой эффективности уже работающих правил.

Стратегический взгляд: mission-critical → business-critical

Илья Одинцов, менеджер по продукту NGR Softlab, подчеркнул: ответ кроется в стратегии компании. Начинать следует с mission-critical систем, сбой которых приведёт к критичным или даже необратимым последствиям для всего бизнеса — мгновенным или долгосрочным. Затем — переходить к business-critical системам, которые также важны для обеспечения непрерывности бизнеса, но их сбой не приведёт к его полной остановке. Например, утечка ПДн из авиакомпании или аэропорта, при всём значении этого инцидента, вряд ли сопоставима по критичности со сбоем в системах связи, навигации или с массовой задержкой рейсов. Параллельно, пока подключаются сегменты и пишутся правила, стоит выяснить у бизнеса, всё ли попало в фокус внимания, возможно, есть важные для них и незаметные для ИБ системы.

Руслан Рахметов, СЕО Security Vision, предложил оценивать приоритеты с двух сторон: по критичности актива и по критичности событий безопасности. Критичную бизнес-систему нужно подключить в первую очередь по причине важности обрабатываемой в ней информации, при этом сам по себе некритичный VPN-шлюз может давать очень ценные сведения о попытках внешних подключений. В первую очередь подключают все СЗИ, контроллеры домена и службы каталогов, некоторые важные сетевые устройства (ядро сети, роутеры, пограничные и VPN-шлюзы), критичные серверы и бизнес-системы; во вторую — конечные точки, некритичные серверы и бизнес-системы, а в конце — оставшиеся устройства. Правила корреляции должны отражать исходные сценарии: включить малошумящие коробочные правила и вносить исключения для снижения False Positive, параллельно разрабатывая правила под конкретные задачи — защита от шифровальщиков или использования скомпрометированных учётных записей, обнаружение внутренних угроз, выявление фрода, детектирование брутфорса. Если компания подходит к настройке SIEM с уже выстроенным процессом управления киберинцидентами, ИБ-специалисты чётко знают, чего именно хотят от SIEM как средства автоматизации рутинных операций, остаётся только перенести порядок выявления инцидентов в формат правил корреляции.

Алексей Федоров, руководитель практики внедрения решений для центров мониторинга и реагирования на инциденты ИБ STEP LOGIC, рекомендовал начинать с небольшого набора правил корреляции, закрывающих наибольшее количество тактик и техник атакующих, и не стремиться на этапе внедрения закрыть всю матрицу MITRE ATT&CK. Если у компании ранее не было SIEM и/или процесса по управлению событиями и инцидентами информационной безопасности, стоит привлечь интегратора для разработки персонифицированных правил корреляции и рекомендаций по настройке источников событий. Однако если у команды ИБ достаточно ресурсов, можно самостоятельно адаптировать коробочные правила корреляции, соблюдая тот же принцип — не стремиться сразу сделать всё.

Нестандартные подходы и роль контекста

Максим Деев, технический директор ARinteg, предложил строить правила от обратного — от ручной аналитики:

«Не имея готовых корреляций, аналитик должен начать вручную разбирать поток событий. Именно в «ручном режиме» он сможет заметить аномалии, ошибки конфигурации или подозрительные цепочки действий, специфичные именно для этой сети. Задача состоит в том, чтобы, увидев проблему вручную, подумать: «Что будет, если эту уязвимость раскрутить и эксплуатировать?» И уже, исходя из этого анализа, формулировать логику правил корреляции, которые будут ловить подобные инциденты в будущем».

Приоритизация, по его мнению, строится на поиске наименее защищённых и неконтролируемых зон — именно здесь возникают основные «слепые зоны». В первую очередь в SIEM должны «полететь» события из сегментов, которые невозможно отслеживать стандартными СЗИ, как правило, это сетевой трафик и активность пользователей на рабочих станциях; закрывать их нужно в первый же месяц, чтобы получить базовую видимость инцидентов. Он предупредил: самая распространённая ошибка — надеяться на коробочные правила или пытаться слепо внедрить правила на основе чужих кейсов и техник; в большинстве случаев это путь в никуда, так как готовая логика с высокой вероятностью не ляжет на специфичную инфраструктуру. Параллельно с написанием правил он рекомендовал устранять первопричины в инфраструктуре, чтобы снижать общий уровень угроз.

Виталий Фомин, директор центра управления безопасностью информации Группы Rubytech, отметил, что ответ на этот вопрос закладывается ещё на этапе проектирования и разработки стратегии развития SIEM или SOC. Многие производители включают в «коробку» необходимые для запуска правила нормализации и корреляции — этого достаточно для быстрого старта, учитывая, что ядро большинства информационных систем типовое, независимо от отрасли: одинаковый набор операционных систем и сервисов. Однако есть отраслевая специфика — на неё необходимо обращать внимание и прорабатывать собственные правила нормализации трафика и корреляционную логику. Главная ошибка на старте — попытка «подключить всё и сразу». Ключевой принцип: 20% источников должны давать 80% детектируемых угроз. В первую очередь подключают критичные активы, которые уже собирают события: контроллеры домена, шлюзы безопасности, системы с чувствительными для бизнеса данными. Также важно подключить источники, помогающие в корреляции событий: почтовые шлюзы, VPN, системы аутентификации. Правила корреляции для SIEM нужно разрабатывать избирательно, исходя из актуальных угроз и выявленных слепых зон. После подключения обязателен аудит коробочных правил: понять, как они работают, отключить лишние, откалибровать для снижения шума, внести исключения. Большинство правил требуют корректировки под задачи и политику безопасности конкретной организации. Практически всегда требуется разработка правил для специфических угроз — под конкретные бизнес-риски.

Михаил Шеховцов, руководитель центра мониторинга ИБ Бастион, рекомендовал начинать с подключения на уровне ОС и сетевых устройств — коммутаторов, маршрутизаторов, файрволов. Этот уровень сбора событий нужен, чтобы получить базовое представление о происходящем в информационных системах. Логи сетевых устройств необходимы для вычисления покрытия мониторингом — именно они отвечают на вопрос «сколько устройств, с которых не поступает аудит уровня ОС». Сюда же можно добавить базовые события САВЗ (средств антивирусной защиты), вычисляющие покрытие ими инфраструктуры и отслеживающие события отключения и заражения ВПО (вредоносного программного обеспечения).

Иван Барановский, руководитель группы поддержки продаж/пресейл компании «АйТи Бастион», предупредил: «Самая распространенная ошибка — пытаться подключить все сразу. В итоге команда тонет в «шуме» и не видит реальных рисков. Лучше начинать с того, что действительно критично: управление доступом, администраторские учетные записи, удаленные подключения, ключевые серверы. Именно там чаще всего начинается атака. И на старте не нужны сотни правил — достаточно набора понятных сценариев: аномальные входы, использование привилегий вне регламента, отключение защит. На практике хороший эффект дает связка SIEM с PAM. Когда SIEM получает данные о привилегированных сессиях из PAM, появляется контекст: кто подключался, по какой заявке, в какое время, какие действия выполнял. Это позволяет не просто видеть событие, а понимать его смысл. И уже в первые месяцы можно отлавливать действительно рискованные сценарии, а не разбирать формальные алерты. Но при этом все равно важно заранее определить процесс реагирования. Если не назначены ответственные и нет понятной процедуры обработки инцидентов, даже самая правильная интеграция не даст результата».

Секторальная приоритизация

Анна Трохалева, руководитель направления анализа инцидентов информационной безопасности УЦСБ SOC, предупредила: даже если бюджет позволяет подключить «всё и сразу», не стоит действовать хаотично — это приведёт к информационному шуму и спаму алертов, которые невозможно будет проанализировать. Чтобы SIEM начинал приносить пользу как можно раньше, источники подключаются поэтапно по приоритетам. В зависимости от рода деятельности организации приоритеты расставляются по-разному.

Для госструктур приоритет — защита данных и целостность. Высокий приоритет: базы данных с ПДн, серверы резервного копирования, сервисы аутентификации (AD, LDAP), внутренние сети (LAN) — трафик между узлами, СЗИ (антивирусы, EDR), СКЗИ (средства криптографической защиты информации), приложения для обработки ПДн, DLP-серверы. Средний: межсетевые экраны (NGFW, FW), системы виртуализации, WAF, файловые серверы, VPN-серверы. Низкий: рабочие станции сотрудников, внутренние системы разработки.

Для финансового сектора — транзакции и контроль доступа. Высокий приоритет: межсетевые экраны, сервисы аутентификации, СЗИ, СКЗИ, VPN-серверы, базы данных с ПДн, DLP. Средний: периметровые сети (DMZ), DNS-серверы, файловые серверы, системы виртуализации, внутренние сети (LAN), серверы резервного копирования, приложения для обработки ПДн, внутренние системы разработки. Низкий: WAF, электронная почта.

Для ИТ-компаний — доступность сервисов. Высокий приоритет: веб-серверы, NGFW, сервисы аутентификации, СЗИ, СКЗИ, WAF, системы разработки (репозитории кода, CI/CD). Средний: DNS-серверы, базы данных с ПДн, файловые серверы, VPN, периметровые сети. Низкий: серверы резервного копирования, DLP-серверы, рабочие станции.

Подход основан на бизнес-рисках и векторах атак, характерных для каждой отрасли. Госсектор не допускает утечек ПДн и нарушения целостности, поэтому базы данных и СКЗИ — в высшем приоритете. Финансовый сектор не допускает компрометации транзакций и несанкционированного доступа к счетам. Поэтому межсетевые экраны и DLP важнее, чем WAF. Для ИТ-компаний критична остановка сервисов и потеря кода. Поэтому веб-серверы, WAF и системы разработки выходят на первый план. Универсального решения нет — приоритизация всегда зависит от того, чем занимается организация и что для неё ценно.

Как измерить, что SIEM работает эффективно, а не просто потребляет бюджет? Какие метрики убедят и CISO, и бизнес?

CISO и бизнес смотрят на SIEM по-разному, и метрики для них нужны разные. Для технических руководителей — MTTD (скорость выявления угроз), MTTR (оперативность реагирования), доля ложных срабатываний, покрытие матрицы MITRE ATT&CK. Для бизнеса — предотвращённый ущерб, сокращение простоев, ROI (возврат инвестиций) / ROSI (возврат инвестиций в безопасность) и результаты аудитов. Отдельно отмечена проактивная ценность: SIEM начинает приносить пользу ещё до первого реального инцидента — через выявление скрытых проблем в инфраструктуре.

Метрики для CISO: техническая эффективность

Елизавета Кузнецова, ведущий системный инженер TS Solution, сразу указала на типичное заблуждение:

«Главная ошибка при оценке эффективности SIEM — мерить его техническими метриками вроде EPS (события в секунду). Бизнесу глубоко безразлично, сколько логов вы получаете. Ему важно, сколько денег вы сохраняете и какие риски закрываете. Эффективность SIEM измеряется тремя показателями. Скорость выявления угроз (MTTD) — автоматизация сокращает время детектирования с часов до минут. Снижение этого показателя (например, с 4 часов до 15 минут) напрямую влияет на финансовые потери, минимизируя простои систем и утечку данных. Глубина покрытия (выявление «слепых зон») — оценка количества подтверждённых инцидентов, которые ранее оставались бы незамеченными; это демонстрация того, как SIEM расширяет периметр видимости ИТ-инфраструктуры. Оперативность реагирования (MTTR) — сокращение времени на расследование инцидента с рабочего дня до одного часа позволяет аналитикам обрабатывать больше угроз, не расширяя штат. Для бизнеса метрика одна: «Мы стали спать спокойнее, потому что вероятность, что нас застанут врасплох, снизилась в N раз». Но чтобы это обосновать, нужен регулярный отчёт для руководства с динамикой ключевых рисков, а не графики загрузки CPU».

Андрей Новиков, руководитель отдела систем и сервисов iTPROTECT, конкретизировал набор для команды ИБ: MTTD, MTTR, процент ложных срабатываний (FP) и пропущенных атак (FN), доля критичных активов, с которых события поступают в SIEM. Бизнесу удобнее оценивать по финансовым показателям и влиянию на репутацию: количество предотвращённых инцидентов и случаев простоя, скорость прохождения комплаенс-проверок и подготовки отчётов, стоимость хранения и обработки 1 ГБ/события, загрузка команды. Главная метрика, понятная всем, — ROI: сумму предотвращённого ущерба и сэкономленного времени сотрудников поделить на совокупные затраты на SIEM.

Иван Бурмистров, пресейл-инженер компании UDV Group, указал: у CISO и бизнеса — принципиально разные показатели эффективности. Для CISO ключевыми метриками являются снижение среднего времени обнаружения и реагирования на инциденты — прямой индикатор корректной настройки правил корреляции и автоматизации расследования. Дополнительно важно определить и отслеживать долю ложных срабатываний на протяжении всего периода внедрения: её снижение свидетельствует о качественной настройке системы. Отдельно можно измерить уровень автоматизации — сколько времени аналитики тратят на рутинный сбор данных и поиск информации, и показать сокращение этих затрат после внедрения SIEM. SIEM не генерирует прямую прибыль, но позволяет её сохранить и минимизировать издержки, возникающие при нарушении бизнес-процессов. Разговор необходимо вести на языке бизнес-рисков и финансов. Для бизнеса — конкретный пример: SIEM даёт возможность выявить атаку на стадии разведки, а не после остановки критического процесса. В денежном выражении это можно оценить так: годовую прибыль разделить на количество рабочих дней и умножить на число дней, необходимых для восстановления данных после их удаления или шифрования, добавив репутационные риски и, в ряде случаев, штрафные санкции.

Юрий Тюрин, технический директор MD Audit, подчеркнул, что эффективность нельзя оценивать объёмом собранных логов. Ключевыми метриками он назвал MTTD (время обнаружения), MTTR (время реагирования), процент инцидентов, выявленных автоматически, и долю ложных срабатываний; для бизнеса значимы показатели снижения простоев и предотвращённого ущерба. Практически полезным он считает раз в квартал проводить «контрольные учения» — моделировать типовые атаки (например, попытку подбора пароля или lateral movement) и проверять, обнаруживает ли их SIEM. Если система не выявляет тестовые сценарии, контент нуждается в пересмотре. Важно отслеживать тренд: сокращается ли время реакции, уменьшается ли количество повторных инцидентов.

Виталий Фомин, директор центра управления безопасностью информации Группы Rubytech, подчеркнул, что для понимания пользы SIEM нужна система метрик, базирующаяся на рисках ИБ и привязанная к целям бизнеса. Метрики необходимо определить заранее, на старте построения мониторинга. Важно понимать, что SIEM — инструмент, а с инструментами работают люди, которые и являются ключевым звеном; при этом эффективность зависит от задач, которые должна решать система, и от настройки инфраструктуры. Среди основных метрик для CISO: время обнаружения инцидента (MTTD), время реагирования (MTTR), доля ложных срабатываний, покрытие тактик и техник MITRE ATT&CK, объём событий в секунду (EPS) и утилизация ресурсов SIEM — не перегружена ли система, достаточно ли мощностей для обработки потока событий.

Метрики для бизнеса: деньги и репутация

Илья Одинцов, менеджер по продукту NGR Softlab, перевёл на язык бизнеса: пока вы не знаете рисков, стоимости простоев или объёмов штрафов, SIEM будет выглядеть иконкой на торпеде автомобиля.

«Бизнесу важны деньги, и если простой вашей производственной линии обходится 10 млн р/час, то своевременное обнаружение атаки на MES или ERP, благодаря которому и удаётся не допустить этого простоя — это и есть метрика. Сколько стоит падение серверов на презентации или на запуске вашего нового продукта? А сколько стоит несколько недель простоя в ретейле или логистике? Если на пилотах SIEM ничего не находит, то это не значит, что в инфраструктуре действительно всё хорошо. Это значит, SIEM просто не видит всей ситуации. Для заказчика это сигнал к тому, что для SIEM недостаточно источников информации, а без них SIEM так и останется модной системой отопления для ЦОД».

Руслан Рахметов, СЕО Security Vision, предложил несколько подходов к обоснованию. Бизнес убедят финансовые показатели, связанные со снижением уровня киберрисков: следует оценить рост скорости обнаружения, анализа, сдерживания, устранения угроз благодаря SIEM-системе, рассчитать ROSI (Return On Security Investment), продемонстрировать список закрытых законодательных требований. Нужный эффект может произвести выявление скрытой киберугрозы, которую ранее нельзя было обнаружить более простыми средствами, обнаружение сложного фрода или незаметной утечки данных, демонстрация позитивных изменений в бизнес-процессах, инициированных по результатам анализа данных из SIEM. Отдельно он обратил внимание на возможность разделения затрат: ИТ-отдел получает данные о производительности устройств, маркетинг — сведения о поведении пользователей на сайте, юридический блок — сводки об инцидентах с ПДн. Для CISO значимы специализированные метрики: охват и полнота событий от источников, актуальность источников и правил корреляции, полнота обогащения событий данными из интегрированных источников, охват правилами корреляции техник матрицы MITRE ATT&CK, тепловые карты, статистика ложноположительных и доброкачественных (подозрительных, но легитимных) инцидентов, число обработанных операторами SIEM инцидентов за определённый период времени и статистика вердиктов закрытия инцидентов. Если SIEM поддерживает построение ресурсно-сервисной модели инфраструктуры и управление активами, построение маршрутов достижимости между активами, выявление наиболее критичных узлов и эффективных точек изоляции атаки, полнота такой накопленной информации также может заинтересовать CISO. Дополнительно он выделил статистику использования SIEM как средства выявления инцидентов по сравнению с другими СЗИ.

Проактивная ценность и практические подходы

Максим Деев, технический директор ARinteg, обратил внимание на проактивную ценность:

«Эффективность SIEM часто ошибочно измеряют количеством пойманных хакеров или предотвращенных вторжений. В реальности же система начинает приносить пользу задолго до реальной атаки. Главный показатель её работы — это способность выявлять «слепые зоны» и ошибки конфигурации уже на этапе внедрения и первичной эксплуатации. Ключевая метрика для технических специалистов и руководителей ИТ — это количество инцидентов, связанных с нарушениями политик безопасности и некорректными настройками, переданные в ИТ-отдел для устранения. Если SIEM регулярно находит рабочие станции без нужного уровня аудита, недокументированные сервисы в сети или подозрительные цепочки в действиях легитимных пользователей — значит, она работает как проактивный инструмент. Она страхует инфраструктуру от неё самой, заставляя закрывать дыры до того, как ими воспользуются злоумышленники».

Рост количества ценных событий при одновременном снижении доли «мусорных» и дублирующихся событий говорит о том, что система учится фильтровать шум. Для бизнеса и CISO убедительной метрикой служит сокращение среднего времени выявления инцидентов (MTTD) и времени реагирования (MTTR), однако на начальных этапах нагляднее динамика критических замечаний по результатам аудитов или пентестов, если после внедрения SIEM внешние аудиторы находят меньше нарушений, это прямой финансовый и репутационный эффект. В конечном счёте, резюмировал Деев, эффективный SIEM — это тот, который регулярно заставляет ИТ-отдел что-то чинить и настраивать, делая компанию устойчивее, а не тот, который просто шлёт сотни бесполезных оповещений.

Михаил Шеховцов, руководитель центра мониторинга ИБ Бастион, напомнил, что SIEM не работает сам по себе, а построение SOC — долгий и дорогой процесс без очевидных выгод для бизнеса. Работа центра мониторинга заключается в том, чтобы не допустить последствий компрометации, а не предотвратить атаку саму по себе — за это обычно отвечает ИБ-служба, внедряющая средства защиты и корпоративные политики безопасности. Задача SOC — предотвратить наступление негативных последствий, когда защита уже нарушена.

Илья Куриленко, заместитель генерального директора по развитию компании «Анлим», предложил комплексный набор: ответить на вопросы «сколько специалистов и для каких задач использует SIEM?», «проходили ли они обучение по работе с системой? Если да, то какое? (установка и настройка или выявление и разбор инцидентов)»; оценить качество настройки с помощью BAS (Breach and Attack Simulation); провести кибериспытания; собрать статистику по инцидентам за период: сколько всего было, сколько обработано, сколько ложных срабатываний; привлечь сервис от вендора (при наличии) для проверки грамотности внедрения; определить степень покрытия SIEM инфраструктуры, выявить осуществляется ли мониторинг ключевых и целевых ресурсов. Отдельно он акцентировал значимость периодической отчётности, содержащей все вышеперечисленные показатели, а также улучшения за отчётный период, исправленные ошибки и описание кейсов ИБ понятным языком, которые были выявлены с использованием SIEM.

Алексей Федоров, руководитель практики внедрения решений для центров мониторинга и реагирования на инциденты ИБ STEP LOGIC, обратил внимание: SIEM — это инструмент, который автоматизирует ряд процессов — управление событиями и инцидентами ИБ, иногда управление активами. Инструменты, как и процессы, не работают без людей. Если в компании уже есть SIEM-система и складывается впечатление, что она работает неэффективно, скорее всего проблема не в продукте, а в совокупности окружающих факторов. В большинстве своём представленные на нашем рынке решения имеют одинаковый набор функций. Конечно, если SIEM-система не устарела морально или технически. Если же компании только предстоит приобрести решение такого класса, стоит подробнее ознакомиться с предложениями вендоров и принять решение на основе релевантных для компании показателей.

Иван Барановский, руководитель группы поддержки продаж/пресейл компании «АйТи Бастион», сфокусировался на практическом эффекте: работающий SIEM — тот, который сокращает время обнаружения и реагирования. Если команда быстрее понимает, что происходит, и перехватывает инциденты на ранней стадии — система приносит пользу. Для службы ИБ это, по сути, про то, как быстро мы обнаруживаем инцидент и как быстро на него реагируем. Но важно не просто получить сигнал, а понимать, насколько он действительно значимый и полезный. Если SIEM интегрирован с PAM, события по привилегированным действиям сразу получают контекст: кто инициировал сессию, была ли она согласована, какие команды выполнялись. Это резко снижает количество спорных ситуаций и упрощает расследование. Мы видим на практике, что такая связка помогает быстрее принимать решения и не тратить время на «ручное выяснение». Для бизнеса всё выглядит ещё проще: меньше простоев, меньше кризисов, спокойнее проходят аудиты. Если тяжёлые инциденты не развиваются в серьёзный ущерб, значит, система действительно работает, а не просто «ест бюджет».

Павел Першин, руководитель группы систем анализа и контроля безопасности ИТ-компании УЦСБ, предложил прагматичный подход: проанализировать отчёт за месяц, отобрав инциденты, реально представлявшие угрозу для компании, если бы на них вовремя не среагировали, оценить возможный ущерб в случае отсутствия реагирования и сравнить стоимость владения SIEM за данный период с возможными потерями.

Как поддерживать правила и контент SIEM актуальными, когда угрозы меняются быстрее, чем команда успевает обновлять корреляции?

Эксперты выделяют несколько подходов: постинцидентный анализ с обязательным обновлением правил, регулярный аудит контента (минимум раз в квартал), использование Threat Intelligence и открытых источников (Sigma HQ, бюллетени регуляторов и др.), назначение владельца контента SIEM, автоматизация развёртывания правил с контролем версий и пр. Ключевая мысль: настройка SIEM — это не разовая история, а непрерывный процесс, требующий выделенной команды.

Постинцидентный анализ и регулярный аудит

Андрей Новиков, руководитель отдела систем и сервисов iTPROTECT, описал основной процесс:

«Актуальность правил держится на правильной организации процессов. После каждого отработанного инцидента аналитик должен ответить на вопрос: «Почему SIEM сработала (или не сработала)?» Если атака была пропущена — нужно создать или доработать правило. Если срабатывание было ложным — уточнить правило. Важно подписаться на фиды Threat Intelligence. Многие вендоры, сообщества и регуляторы предоставляют актуальные списки IoC. Пусть команда раз в неделю загружает свежие индикаторы в систему — это закроет массовые угрозы без сложных корреляций. Также еженедельно следует разбирать статистику. Выгружайте топ-10 самых частых срабатываний и оценивайте их полезность. Правила, которые генерируют шум, но не приводят к реальным инцидентам — отключайте или дорабатывайте. Это снизит нагрузку на команду и освободит время для настройки нового контента. В ежедневном режиме нужно разбирать топ-10 событий: даже без сложной автоматизации аналитик может просмотреть самые подозрительные события и понять, каких правил не хватает».

Юрий Тюрин, технический директор MD Audit, отметил: угрозы меняются быстрее, чем обновляется инфраструктура, поэтому контент SIEM должен регулярно пересматриваться. Он рекомендовал минимум раз в квартал проводить аудит правил: какие срабатывают часто и бесполезно, какие не срабатывали ни разу. Назначить владельца контента SIEM, внедрить change management для правил, использовать тестовую среду для проверки новых правил до вывода в продакшн, чтобы избежать лавины ложных алертов. Полезна интеграция с threat intelligence и обновлениями от вендора, а также обновление правил на базе новых техник атак, отчётов об инцидентах и изменений ИТ-ландшафта.

Иван Барановский, руководитель группы поддержки продаж/пресейл компании «АйТи Бастион», подчеркнул:

«Нужно принять, что настройка SIEM — не разовая история. Инфраструктура меняется, появляются новые сервисы, меняются схемы атак и соответственно правила тоже должны меняться. Здесь хорошая практика — это регулярно пересматривать детекты, разбирать ложные срабатывания, дорабатывать корреляции. Можно использовать внешний threat intelligence и готовый контент от вендора, но полностью полагаться на это нельзя. Лучше меньше правил, но реально рабочих. То есть, по сути, тут всё держится на системной работе команды. Если инциденты разбираются, выводы делаются и правила корректируются — система остаётся живой. Если же нет — она постепенно превращается в склад логов».

Автоматизация: Detection as Code и открытые источники

Илья Одинцов, менеджер по продукту NGR Softlab, выступил за максимальную автоматизацию:

«Detection as Code — такой подход даст больше всего скорости. Уже на следующей стадии, после его внедрения можно подумать о добавлении LLM-помощников — тут я бы доверял самым новым моделям, вне зависимости от страны их происхождения. Если у вас нет процессов контроля версионности, валидации, тестирования и автоматической раскатки правил, вы будете тратить слишком много времени на ручную работу. То, что можно автоматизировать до нескольких часов, в ручном режиме вы будете делать несколько дней. Threat hunting, bug bounty — модные и дорогие тренды. Они, безусловно, полезны и эффективны, но их ручная проработка требует слишком много времени. Представьте, что ваш аналитик описал новое правило, затем пошёл копировать его на тестовый стенд, вручную проверять (а скорее всего, подключил коллег из appsec или pentest через заявку и пару дней ожидания), затем отдал результаты на согласование, а уже потом только правило залили на препрод или прод. Детектирование новой угрозы в этом случае суммарно займёт у вас не менее пяти рабочих дней, при том что с detection as code время измеряется в часах».

Максим Кириенко, руководитель технического пресейла компании VolgaBlob, выделил два пути: дать возможность создавать контент «на местах», чтобы вендор не становился «бутылочным горлышком» в цепочке поставки обновлений, достаточно распространить уведомление о необходимости реализовать правило, приложить примеры и готовые запросы. А уже позже может появиться и полноценное правило, доработанное аналитиками. Второй — обеспечить возможность загрузки правил из открытых источников, например из сообщества Sigma. Это большое международное сообщество, где информация об 0-day угрозах может появиться практически сразу после обнаружения.

Автоматизация: no-code/low-code

Руслан Рахметов, СЕО Security Vision, перечислил инструменты актуализации. Предустановленные («коробочные») правила корреляции — важны их количество и качество; не все будут актуальны для конкретной инфраструктуры, но дадут основу для дальнейшей настройки и создания новых правил. Фирменные маркетплейсы вендоров предоставляют дополнительные готовые интеграции, правила корреляции и свежий контент для обнаружения угроз. Важно, чтобы SIEM предоставляла удобные механизмы тюнинга правил корреляции и нормализации с помощью графических конструкторов и no-code/low-code подхода — это снижает порог входа для новых специалистов. Среди внешних источников он выделил Sigma HQ, Awesome Detection Engineer, MITRE ATT&CK, а из российских — отчёты о расследованиях регуляторов, вендоров и ИБ-исследователей, дайджесты и бюллетени безопасности с описанием способов атак, индикаторов компрометации и способов реагирования. Подобными источниками следует пользоваться для непрерывной актуализации настроек SIEM, понимания тенденций кибератак и современного инструментария злоумышленников.

Альтернативный подход: не гнаться за угрозами

Максим Деев, технический директор ARinteg, предложил сменить парадигму:

«Вечная гонка за актуализацией правил под каждую новую угрозу — тупиковый путь, требующий бесконечных ресурсов. Пытаться писать корреляции под чужие кейсы или под каждую технику бесполезно: к моменту внедрения правила ландшафт угроз снова изменится. Подход, который работает, строится на двух принципах: снижение поверхности атаки и фокус на аномалиях, а не на сложных цепочках. Во-первых, в процессе постоянной эксплуатации SIEM мы должны максимально снижать общую проблемность инфраструктуры. Если злоумышленник не сможет пробить периметр или получить легитимный доступ извне, ему будет крайне сложно эксплуатировать внутренние специфичные уязвимости, устраняя найденные SIEM ошибки конфигурации, мы автоматически обесцениваем огромные пласты потенциальных атак, и гнаться за ними, как правило, уже не нужно. Во-вторых, критически важно сместить фокус с поиска многоходовых комбинаций на выявление именно момента внедрения угрозы. Отлавливать аномалии на ранней стадии — будь то подозрительный сетевой трафик, нехарактерное поведение процесса или запуск редкого исполняемого файла — гораздо эффективнее. Вместо того чтобы пытаться объять необъятное и описать все возможные действия атакующего внутри системы, мы концентрируемся на том, что в принципе не должно происходить в «нормальной» жизни инфраструктуры. Такой подход делает правила корреляции более живучими и не требующими еженедельного переписывания».

Экономика и кадры

Алексей Федоров, руководитель практики внедрения решений для центров мониторинга и реагирования на инциденты ИБ STEP LOGIC, подчеркнул роль threat hunting: в правильном SOC должны быть сотрудники, выполняющие процесс поиска угроз, их задача формировать контент, в том числе правила корреляции, опережая злоумышленника. Если в компании нет такого сотрудника или такого процесса, один из выходов — приобрести эту услугу у того, кто её может предоставить. При этом нужно понимать: всегда есть 0-day уязвимость, которая может быть проэксплуатирована — это может быть как злоумышленник, проникший ранее неизвестным никому способом, так и уборщица в серверной, пролившая ведро воды на оборудование. Вероятность обоих событий одинакова. Важно сконцентрироваться на контенте, который закроёт большинство известных и актуальных для компании правил по выявлению инцидентов ИБ.

Михаил Шеховцов, руководитель центра мониторинга ИБ Бастион, указал на экономическую сторону: использование генераторов контента, например из правил YARA, помогает следить за актуальностью контента. Однако велика вероятность ложных срабатываний, поэтому всё равно понадобится команда, которая будет дорабатывать полученные правила и дополнительные расходы на такой персонал, вероятнее всего, во много раз превысят стоимость самого SIEM-решения. Для построения эффективного SOC на недорогих SIEM-решениях коэффициент превышения будет кратно больше, а общие расходы бюджета выше — экономия на софте переложится в трудозатраты.

Павел Першин, руководитель группы систем анализа и контроля безопасности ИТ-компании УЦСБ, был лаконичен: при наличии квалифицированной команды таких проблем не возникает. Главное — поддерживать не весь контент, а только релевантный для конкретной организации и её угрозам. И это должна быть команда, а не один человек.

Виталий Фомин, директор центра управления безопасностью информации Группы Rubytech, подошёл со стороны бизнес-ценности: бизнес — это про финансовые риски и стратегические показатели, и один из главных вопросов: как SIEM создаёт ценность? Эффективная SIEM даёт бизнесу то, что можно посчитать: предотвращённый ущерб — сколько денег бизнес не потерял благодаря тому, что атаку выявили вовремя (рассчитывается на основе стоимости простоя сервисов, восстановления систем, утечки данных и других факторов), снижение времени простоя — сколько часов работы интернет-сервисов, производства или логистики было сохранено, соответствие требованиям, все обязательные требования регуляторов закрыты, нет штрафов, предписаний и судебных разбирательств, сохранённые деньги, сниженные риски и быстрый возврат инвестиций.

Приоритизация по критичности источников

Анна Трохалева, руководитель направления анализа инцидентов информационной безопасности УЦСБ SOC, подчеркнула, что угрозы и атаки меняются ежедневно, но «старые» атаки (брутфорс, EternalBlue) никуда не исчезают. Принцип актуализации контента строится в первую очередь на ценности защищаемой информации: практически невозможно защититься от всех атак, и задача мониторинга выявить атаку как можно раньше, чтобы минимизировать потенциальный ущерб. Актуальность правил жёстко привязана к приоритету источника: чем важнее система, тем интенсивнее за ней следят. Для высокоприоритетных источников (AD, сервисы аутентификации, критичные межсетевые экраны периметра, репозитории кода, системы резервного копирования, базы данных с ПДн) она выделила три направления: Threat Hunting — когда аналитики не ждут срабатываний, а выявляют всплески трафика, активность администраторов или других пользователей в нетипичное время; реактивная разработка правил под конкретную новую угрозу; TI-фиды с ежесуточным обновлением и обязательным сроком жизни IoC. Для среднеприоритетных источников (сетевая инфраструктура: FW, NGFW, серверы виртуализации, DNS, VPN, прокси-серверы, WAF) угрозы типовые, и часто меняются не методы атак, а конкретные адреса и домены злоумышленников — здесь необходимо автоматическое обновление фидов, сигнатур и динамических списков. Для низкоприоритетных источников (рабочие станции) основная задача не пропустить серьёзную аномалию на фоне «шума»: корректное и своевременное внесение исключений, периодический анализ самых «спамящих» правил и чистка правил залог успеха в выявлении инцидентов. Актуализация правил корреляции и нормализации постоянный процесс в мониторинге, особенно крупных ИТ-инфраструктур, далеко не тривиальный, требующий критического мышления и ответственности от аналитиков.

Что на практике меняет появление ИИ и ML внутри SIEM? Это уже рабочий инструмент или пока только маркетинг?

Эксперты разделяют ML и генеративный ИИ. ML-технологии (UEBA — User and Entity Behavior Analytics, поведенческий анализ, скоринг ложных срабатываний и пр.) признаются рабочими инструментами, которые используются в SIEM не первый год. Генеративный ИИ находится на ранней стадии: помогает аналитикам как «ассистент» при расследовании, но не способен заменить квалифицированных специалистов. Маркетинговые заявления о «полной автономности мониторинга» и «обученной модели из коробки» не соответствуют практике.

ML: уже работает

Елизавета Кузнецова, ведущий системный инженер TS Solution, привела конкретный пример:

«Маркетинга вокруг ИИ действительно много, но за ним уже стоят реальные рабочие кейсы. Важно понять, что искусственный интеллект не замена аналитику, а его «микроскоп», позволяющий разглядеть то, что не видно невооруженным глазом. Яркий пример — детектирование атак типа DLL Hijacking. Сигнатурный анализ здесь бессилен: вредоносная библиотека может называться как угодно, а грузит её легитимный процесс. Человек физически не может пройти по всем сочетаниям «процесс-библиотека». Но ML-модель, обученная на телеметрии, способна сопоставить сотни атрибутов и выдать вердикт: «Этот файл маскируется под системный, но по совокупности признаков — это Cobalt Strike». ML помогал ловить APT-группы именно потому, что находил аномалии там, где злоумышленники пытались идеально замести следы».

Отдельно она подчеркнула: «Поэтому ИИ сегодня — это не про автоматизацию мышления, а про автоматизацию поиска. Он анализирует миллионы событий, чтобы подсветить аналитику те самые 10 инцидентов, на которые действительно нужно обратить внимание».

Андрей Новиков, руководитель отдела систем и сервисов iTPROTECT, оценил ML как уже рабочий инструмент, но отметил, что маркетинга по-прежнему много. Он выделил три области, где ML приносит результат. Первая: UEBA — вместо поиска по спискам ML строит профиль нормального поведения пользователей и устройств, что позволяет выявлять компрометацию учётных записей, когда система замечает, что пользователь Иванов вошёл в систему в 3 часа ночи из необычной локации и начал скачивать несвойственные ему данные. Вторая: снижение шума — традиционные SIEM генерируют тысячи алертов, из которых ложными могут быть до 70%, а ML-модели группируют связанные события, отсеивают повторяющиеся и поднимают аналитику действительно критичные цепочки. Третья: корреляция на новых данных — ML лучше находит связи между событиями из разных источников, по которым не сработали имеющиеся правила корреляции. Однако он предупредил: модели устаревают — без регулярного переобучения качество падает, то, что было нормой полгода назад, сегодня может быть аномалией, и наоборот. Наконец, работа ML по методу «чёрного ящика» приводит к тому, что аналитик не может объяснить, почему сработало то или иное правило — доверие к системе падает, а это особенно критично для расследований и комплаенса. Злоумышленники уже учатся обходить ML: имитируют нормальное поведение, растягивают атаки во времени, пытаются отравить данные для обучения.

Юрий Тюрин, технический директор MD Audit, подтвердил: ML и поведенческая аналитика помогают выявлять аномалии там, где сигнатурные правила бессильны, — например, нетипичную активность учётной записи или необычный объём сетевого трафика. Особенно полезно в больших инфраструктурах с миллионами событий в сутки. Однако без качественных исходных данных и тюнинга ML-модели дают высокий процент ложных срабатываний. Поэтому ИИ — усилитель аналитика, а не его замена. Наибольшая эффективность при связке с SOAR и автоматическими сценариями реагирования. ML-модули следует запускать после периода накопления baseline (1–3 месяца), а результаты проверять вручную до полной автоматизации.

Генеративный ИИ: помощник, не замена

Илья Одинцов, менеджер по продукту NGR Softlab, провёл чёткую границу:

«ИИ снижает порог входа в продукт, но дальше ваши аналитики не продвинутся. ИИ обучены на определённых данных, доступных компании в определённый период времени. Если вы пользуетесь ИИ от компании-мирового лидера, то в лучшем случае это означает, что он обладает информацией, всем известной на момент полугодичной давности. Если же у вас собственный ИИ, то задайте себе вопрос: на каких данных он обучен? Сопоставим ли по эффективности с решением, разработанным на основе гораздо больше ресурсов? ML же — это несколько иное. Это давно обкатанные технологии, работающие с вашими данными. Они не снижают порог входа, не заменяют людей. ML помогает перенаправить ваше внимание туда, куда в обычной ситуации вы бы и не посмотрели. Именно поэтому в большинстве продуктов ИБ используются UEBA, построенные как раз на технологии ML, повышающей их эффективность. Вспомним ситуацию с WannaCry в 2017 году. Любой ИИ пропустил бы атаку или же не знал бы, что с ней делать. А специалисты, столкнувшись с атакой, в режиме реального времени могли оперативно обмениваться информацией и искать пути решения. Спустя какое-то время были подключены ML, которые помогали детектировать атаку в более короткие сроки. Стоит отметить, что и на сегодняшний день ML остаются одним из наиболее эффективных механизмов детекта ransomware. Этот и подобные примеры из прошлого наталкивают на мысль, что ИИ не более чем дорогой маркетинговый пузырь, который приносит какую-то пользу для специалистов уровня Mid/Sen/Lead, но не более. В противовес ему ML уже отработанная технология детекта с гарантированным эффектом».

Иван Бурмистров, пресейл-инженер компании UDV Group, подтвердил: ML решает задачу снижения «информационного шума» и упрощает работу SOC, уменьшая операционную нагрузку. Однако эти технологии не способны заменить профильных специалистов. Реальный прикладной сценарий использования ML — выявление аномального поведения и акцентирование внимания на конкретных событиях или инцидентах в условиях масштабной атаки. Но для этого модель необходимо обучить, чтобы она понимала, что в рамках конкретной организации считается нормой, а что — отклонением. Маркетинговые заявления о «замене специалистов», «полной автономности мониторинга» или «обученной модели из коробки» не соответствуют практике. Принятие решений, особенно в контексте бизнес-рисков и ответственности, остаётся за человеком. Кроме того, обучение модели требует времени и формирования дополнительных компетенций внутри команды.

Максим Кириенко, руководитель технического пресейла компании VolgaBlob, отметил, что ИИ и ML уже становятся рабочими инструментами, как минимум в автоматизации. У его заказчиков уже есть примеры использования LLM для помощи в расследовании инцидентов. ИИ выступает как дополнительный источник «подсказок» для аналитика и помогает автоматизировать рутину. На уровне L1 с менее критичными инцидентами рутины особенно много, и часть таких инцидентов уже сейчас может закрывать ИИ. ML, в свою очередь, помогает адаптировать False Positive и настраивать пороги правил.

Михаил Шеховцов, руководитель центра мониторинга ИБ Бастион, подчеркнул, что нейросети и автоматизированное обучение — это инструменты, для эффективного использования которых необходимы специальные навыки. Он спрогнозировал появление новой роли в SOC — ИИ-инженера-аналитика, человека, который будет уметь правильно формулировать промпты для больших языковых моделей и интерпретировать ответы, отделяя реальность от ошибок нейросетей.

NextGen-SIEM: что уже реализовано

Руслан Рахметов, СЕО Security Vision, отметил, что крупные ИБ-вендоры уже предлагают в своих SIEM-решениях различные инструменты ИИ и ML — именно присутствие подобного функционала и встроенных механизмов реагирования на инциденты позволяет отнести решение к классу NextGen-SIEM. В частности, ML-модели используются для скоринга False Positive с обучением на данных по закрытым инцидентам: при поступлении нового инцидента система оценивает его схожесть с ранее закрытыми ложноположительными и выдаёт процент соответствия. ML применяется для поиска похожих инцидентов с анализом контекста и отображением похожих кейсов, что позволяет аналитику увидеть аналогичные инциденты и посмотреть, как обрабатывались схожие ситуации в прошлом, а также для оценки критичности инцидентов на основе признаков, отражающих массовость и значимость затронутых активов с учётом контекста и связанных с инцидентом алертов. ИИ-помощники в чате по инциденту помогают аналитику сориентироваться, предлагают оптимальные дальнейшие действия и консультируют по обнаруженным угрозам. Встроенные в некоторые SIEM-системы модули UEBA строят типовые модели поведения пользователей, устройств и артефактов, выявляя отклонения и аномальное поведение сущностей в инфраструктуре, а встроенные механизмы управления активами проводят скоринг и оценивают достижимость активов. Уже совсем скоро ИИ позволит выполнять автоматическую нормализацию событий и автоматически выстраивать правила корреляции в SIEM.

Маркетинг или реальность

Максим Деев, технический директор ARinteg, провёл границу: важно разделять уже существующие технологии ML и реальный ИИ, который только начинает появляться. ML в том или ином виде используется в системах достаточно давно. Его классическое применение — поиск отклонений от базовой линии (поведенческий анализ): система изучает типичные паттерны, например связку «пользователь — событие» или «процесс — ресурс», и фиксирует аномалии. Если конкретный сотрудник вдруг начинает вести себя не так, как обычно, это становится маркером для расследования. ML — рабочий инструмент, но ограниченный сравнением двух-трёх параметров. Прорыв обещают генеративные модели, способные анализировать динамические цепочки событий без жёстко прописанных правил, что сейчас является главным камнем преткновения для любой SIEM (ни один вендор не может дать исчерпывающий пакет экспертизы). Кроме того, ИИ способен оценивать правдоподобность срабатываний, отделяя реальные угрозы от «шума». Однако на сегодняшний день — это скорее маркетинг, чем реальность: никто не готов «скармливать» инциденты и сырые события в открытую обучающуюся модель из соображений безопасности и приватности. Причина не в отсутствии технологий, а в неготовности рынка. Пока проблема конфиденциальности данных не будет решена, ИИ в SIEM останется многообещающей, но не до конца раскрытой историей, а реальную работу по-прежнему будут делать поведенческий анализ и ручная экспертиза.

Илья Куриленко, заместитель генерального директора по развитию компании «Анлим», отметил, что внедрение умных технологий при разработке SIEM становится массовым явлением среди вендоров. Машинное обучение помогает с большой точностью выявлять и классифицировать инциденты, а ИИ-ассистенты значительно снижают требования к сотрудникам и ускоряют работу. UEBA помогает выявить аномальное поведение.

Иван Барановский, руководитель группы поддержки продаж/пресейл компании «АйТи Бастион», высказался прагматично:

«Это уже реальность, но без магии. Машинное обучение действительно помогает находить аномалии, которые сложно описать обычными правилами. Оно хорошо работает на больших объёмах данных и помогает уменьшить шум. Но это не замена аналитиков. Модели нужно настраивать под свою инфраструктуру и регулярно проверять. Если просто включить ML и ждать чуда — ничего не произойдёт. Поэтому где-то это действительно маркетинг, а где-то — реальный инструмент, если его правильно встроили в процесс».

Как изменятся требования к SIEM в ближайшие 2–3 года? К чему готовиться тем, кто выбирает решение сейчас?

Большинство экспертов прогнозируют конвергенцию: SIEM превращается в платформу, частично объединяющую функции SOAR, UEBA, IRP и XDR. Ключевые тренды: обязательное присутствие ИИ/ML, интеграция с облачными и контейнерными средами, переход к сервисным моделям (SIEMaaS, MSSP, MDR) на фоне кадрового дефицита. Для российского рынка дополнительным фактором станут требования к аппаратной эффективности в условиях санкционных ограничений.

Конвергенция: от SIEM к платформе

Андрей Новиков, руководитель отдела систем и сервисов iTPROTECT, обозначил выбор SIEM как инвестицию на 3–5 лет. SIEM станет центром управления безопасностью, а не хранилищем логов, вобрав функции SOAR (оркестрация), UEBA (поведенческий анализ) и XDR. ML станет обязательным: уже сейчас он помогает снижать усталость от алертов и повышать точность обнаружения. В ближайшие годы ИИ будет вшит в ядро SIEM или станет дополнительным модулем, обеспечивая автономную приоритизацию инцидентов, подсказки по расследованию и создание правил под новые угрозы. Модель Zero Trust потребует работы с идентификацией в реальном времени: SIEM должна будет оценивать риск каждого действия — логин, запрос к API, доступ к данным и влиять на политики доступа в моменте. Интеграция с IAM, каталогами пользователей и системами управления доступом станет обязательной, а не опциональной. Разрозненные инструменты уходят в прошлое, рынок движется к экосистемности и консолидации. Дополнительным фактором станут регуляторные изменения: поправки в 187-ФЗ и приказ ФСТЭК России №117 усиливают требования к передаче данных в ГосСОПКА и мониторингу событий на объектах КИИ. Рынок смещается в сторону SIEMaaS и MSSP-моделей — малому и среднему бизнесу, который сейчас часто становится жертвой злоумышленников (например, в ходе атак на цепочки поставок), проще покупать защиту как сервис, чем разворачивать собственную инфраструктуру.

Алексей Федоров, руководитель практики внедрения решений для центров мониторинга и реагирования на инциденты ИБ STEP LOGIC, констатировал: решения класса SIEM достигли логического потолка, многие вендоры, присутствующие на нашем рынке, стремятся к платформенному типу решений, где SIEM является лишь одним из модулей. Совокупность разных модулей на одной платформе создаёт экосистему для подразделений ИБ. В таком подходе есть как плюсы — масштабируемость и бесшовная интеграция, так и минусы — зависимость от вендора и возможные ограничения платформы. Но это уже случившийся факт. Выбирать SIEM-систему стоит по оценке стоимости владения в перспективе на предполагаемый срок эксплуатации, а также возможностям интеграции с другими автоматизированными системами подразделения ИБ.

Руслан Рахметов, СЕО Security Vision, спрогнозировал: реагирование на инциденты, которое сейчас осуществляется в XDR и SOAR, будет обеспечивать полный цикл инцидента от обнаружения до постанализа, в концепции NG-SOAR, объединяя в том числе функционал SIEM. Это позволит перейти от мониторинга и пассивного сбора данных к активному реагированию и проактивному предотвращению атак на ранних стадиях. Популярностью будут пользоваться облачные SIEM, которые могут быть нативно интегрированы с решениями класса CSPM, CASB, CNAPP, DSPM. ML и ИИ будут использоваться шире — в том числе для автоматической корреляции незаметных разрозненных событий, которые в совокупности могут указывать на скрытую кибератаку. Новые SIEM должны стать менее ресурсоёмкими, более эффективными и масштабируемыми. Те, кто выбирает решение сейчас, должны ориентироваться на наличие продвинутых функций уже в текущих версиях продуктов — очевидно, что присутствующие на рынке зрелые SIEM будут динамично развиваться и дальше, поскольку спрос на данные продукты только растёт.

Взгляд из России: зрелость, а не революция

Илья Одинцов, менеджер по продукту NGR Softlab, дал прогноз для российского рынка:

«Западный рынок смело смотрит в облака и AI-gen SIEM. Если же говорить о России, то, полагаю, в ближайшие годы серьёзных изменений не произойдёт: вендоры пока учатся более эффективно работать с данными, расширяют экспертизу в рамках детекта. В последнее время появился модный термин NextGen SIEM, но это всего лишь возвращение комплиментарных технологий в продукт. Когда-то IRP и SOAR отделились от SIEM из-за старой монолитной архитектуры, требующей масштабирования нагрузок, но в эпоху облаков и контейнеризации это уже перестало быть проблемой. Полагаю, что в недалёком будущем SIEM разделятся на два лагеря: commodity с поглощением IRP и SOAR, живущий в рамках экосистемы core-вендора и свободные от вендор-лока гибкие системы, ориентированные на экспертизу Detection as Code. Единственное, к чему стоит приготовиться всем — к серьёзному падению экспертизы. Если сегодня мы говорим о кадровом голоде, то через два-три года аналитики 1–2 линии будут либо знать исключительно продукт от конкретного вендора, либо зависеть от нейрослопа. А вот про SIEM они уже знать не будут. Как говорится: если вы знаете Ubuntu, вы знаете Ubuntu; если вы знаете Arch, вы знаете Linux».

Максим Деев, технический директор ARinteg, высказал сдержанную оценку:

«Полагаю, что в ближайшие 2–3 года требования к SIEM вряд ли претерпят революционные изменения. Рынок вошёл в фазу зрелости, и практически все представленные системы имеют сходное наполнение и сопоставимый базовый функционал. Реальные различия сейчас возникают только там, где функционал SIEM расширяют за счёт глубокой интеграции с другими продуктами того же вендора, образуя единую экосистему. Во всём остальном отличия минимальны. Это значит, что в условиях отсутствия жёсткой конкуренции по инновациям борьба идёт преимущественно за технические характеристики (требуемые ресурсы, производительность) и, конечно, за цену. Кто предложит более выгодную стоимость владения, тот и выигрывает. Поэтому тем, кто выбирает решение сегодня, я бы посоветовал не мучиться вопросом «кто круче технически», а смотреть на конкретные «плюшки» от вендора. Сейчас несложно набрать хороший пакет экспертизы, используя чужие наработки и открытые базы знаний, поэтому молодые системы быстро догоняют старых игроков. Чётких объективных показателей больше нет — это во многом вкусовщина и вопрос доверия. Выбирайте исходя из того, какие дополнительные бонусы, сервис и условия поддержки готов предложить производитель, именно уровень сервиса и стоимость, а не мифические новые требования, будут определять успех внедрения в ближайшие пару лет».

Кадровый голод и сервисные модели

Кадровый дефицит стал сквозной темой у нескольких экспертов.

Елизавета Кузнецова, ведущий системный инженер TS Solution, выделила ключевые тренды:

«Конвергенция технологий: грань между SIEM и решениями класса EDR/XDR окончательно исчезнет. Современная платформа обязана «из коробки» одинаково глубоко понимать как сетевой трафик, так и активность на конечных точках, не требуя дополнительных «костылей» для интеграции. Реакция без участия человека: эпоха ручного заведения тикетов завершается, ключевое требование завтрашнего дня — встроенная оркестрация (SOAR), система должна не просто сигнализировать об угрозе, а самостоятельно запускать плейбуки: изолировать заражённый хост, отключить скомпрометированную учётку или закрыть порт на межсетевом экране. Кадровый голод. Дефицит кадров в информационной безопасности меняет критерии выбора. Победят вендоры, предлагающие понятную «коробку» с низким порогом входа. Интерфейсы будут адаптироваться под смежные роли, позволяя решать базовые задачи даже специалистам без хардкорной боевой подготовки».

Илья Куриленко, заместитель генерального директора по развитию компании «Анлим», предсказал: в течение 2–3 лет произойдёт отход от концепции, что SIEM — продукт, созданный специалистами сугубо для специалистов. Квалифицированных кадров мало, поэтому клиенты будут выбирать решения, дающие максимально полную картину об инциденте, то есть объясняющие понятным языком: где, что произошло и пути решения. Использование ИИ в решениях класса SIEM будет применяться с большой вероятностью. Усилятся интеграции с IRP, UEBA, XDR, SOAR или переход их функционала в SIEM.

Михаил Шеховцов, руководитель центра мониторинга ИБ Бастион, отметил тенденцию смещения от SIEM к сервисам MDR или MDR-like, предоставляющим аналитику инцидентов от сторонней команды, контент и доступ к событиям. Вероятно, в условиях кадрового голода рынок будет двигаться в этом направлении.

Максим Кириенко, руководитель технического пресейла компании VolgaBlob, подчеркнул: тем, кто выбирает решение сейчас, стоит ориентироваться на платформы с широкими возможностями интеграций, встроенными модулями реагирования и готовыми инструкциями для аналитиков. Сегодня недостаточно просто зафиксировать инцидент: заказчики ожидают от SIEM-платформы чёткого сценария, что должно быть сделано в первые минуты и часы. Уже сейчас большое внимание уделяется совместимости с российскими ИБ-продуктами, чтобы интеграция с новым оборудованием и ПО не занимала месяцы. В первую очередь речь о платформах, где функции SOAR и IRP встроены и подключаются как модули в едином интерфейсе, такой подход упрощает процессы, исключает разрозненные инструменты и множество окон и заметно экономит время специалистов. Также будут востребованы встроенные инструменты аналитики и визуализации для формирования управленческой отчётности по инцидентам и SLA без привлечения внешних BI-систем. В целом рынок движется к высокопроизводительным и гибким продуктам с возможностями быстрого развёртывания и масштабирования, но на доступных для заказчика условиях. Поэтому бизнес перейдёт к потреблению облачных сервисов — модели SIEMaaS и MSSP обеспечат быстрое развёртывание и масштабирование комплексной защиты без капитальных затрат.

Технологические тренды

Юрий Тюрин, технический директор MD Audit, рекомендовал оценивать не только возможности сбора логов, но и масштабируемость, наличие встроенного SOAR, поддержку API и экосистемы интеграций. SIEM трансформируется в платформу XDR с элементами автоматизации реагирования. Усилится роль автоматизации: ручной анализ миллионов событий становится экономически нецелесообразным. Будут расти требования к интеграции с облачными сервисами, контейнерными средами и DevOps-инфраструктурой. Выбирать платформу с понятной дорожной картой развития и возможностью гибкого расширения, чтобы через два года не пришлось полностью менять архитектуру мониторинга.

Юлия Сонина, старший аналитик Аналитического центра УЦСБ, обратила внимание на несколько направлений. По её оценке, требования и ожидания бизнеса от SIEM-систем будут пропорционально расти относительно новых технологий и актуальных киберугроз. Во-первых, SIEM должны основательно интегрировать ИИ для повышения производительности и качества работы: от него ожидается решение проблем анализа событий в скорости и объёме, поскольку современные атаки становятся всё более обширными и молниеносными. Среди базовых задач модернизации — помощь в создании новых правил корреляции и детектировании атак, приоритизации событий и последовательному устранению последствий атаки, а также расследовании инцидентов, что приведёт к росту затрат на оборудование в связи с новыми требованиями к мощностям для обеспечения высокой производительности. Во-вторых, рост объёмов обрабатываемой информации потребует как увеличения физических объёмов (железа), так и изменения архитектурных подходов, один из вариантов — переход от монолитной структуры хранения к подходу Data Lake, обеспечивающему масштабируемость при хранении данных и гибкость при их анализе и поиске. В-третьих, компаниям необходимо определить, какой процент бизнеса уже находится в облачных ресурсах и насколько он вырастет в ближайшие два-три года, чтобы выбирать SIEM, подходящий конкретной бизнес-модели. Актуальным требованием станет работа с новыми источниками — облачные ресурсы, контейнерная инфраструктура, IoT, поскольку контейнерная инфраструктура и облачные ресурсы являются гибкими источниками, потребуется автоматизация их поиска и подключения для организации процесса безопасности без слепых зон. Отдельно она отметила: бизнесу нужно проанализировать, попадает ли деятельность под предписания регуляторов (например, ФСТЭК России), в таком случае имеет смысл отказаться от open-source в пользу сертифицированных продуктов.

Павел Першин, руководитель группы систем анализа и контроля безопасности ИТ-компании УЦСБ, обратил внимание на несколько трендов. Как и во многих других сферах, всё чаще будет звучать тема UEBA, ML и ИИ. На фоне роста стоимости аппаратных платформ, наличия санкций и так далее немаловажным фактором станут требования к аппаратной платформе. Если раньше проблемы решались наращиванием мощностей (процессоры, память, диски), то сейчас такая экстенсивная модель теряет экономическую целесообразность.

Иван Барановский, руководитель группы поддержки продаж/пресейл компании «АйТи Бастион», заключил:

«SIEM постепенно перестаёт быть просто «сборщиком логов». Это решение становится частью более широкой системы управления безопасностью: с автоматизацией, оркестрацией и элементами ИИ. Инфраструктура становится гибридной: облака, SaaS, контейнеры и всё это нужно видеть в едином контуре. Плюс растёт запрос на автоматическое реагирование, потому что людей не становится больше, а событий становится. Поэтому тем, кто выбирает решение сейчас, важно смотреть не только на текущие функции, но и на то, насколько система гибкая, масштабируемая и готова к автоматизации. Считаю, что будущее за более умными и более автономными системами, которые помогают команде, а не создают дополнительную нагрузку».

Заключение

SIEM остаётся незаменимым инструментом для организаций со сложной инфраструктурой и зрелыми процессами ИБ — но только при условии, что за системой стоят люди, процессы и постоянная работа над контентом. Все опрошенные эксперты сходятся в главном: SIEM — не «коробка», которую достаточно установить, а платформа, требующая непрерывного внимания.

Ключевые выводы, которые прослеживаются через все ответы: начинать нужно не с технологии, а с процессов — определить критичные активы, выстроить приоритеты подключения источников и назначить ответственных за реагирование. Итеративный подход побеждает попытку «подключить всё и сразу»: небольшой набор качественно проработанных правил корреляции ценнее сотни непротестированных. Метрики должны говорить на языке бизнеса: не EPS и объём логов, а предотвращённый ущерб, сокращение MTTD/MTTR и результаты контрольных учений. ML в SIEM уже стал рабочим инструментом; генеративный ИИ находится на ранней стадии, и пока он выполняет роль ассистента аналитика, а не замены квалифицированным специалистам. Автоматизация развёртывания правил, контроль версий и низкий порог входа для новых специалистов становятся важными требованиями к современным SIEM-платформам.

Не менее важной темой стали люди. Эксперты единодушны: без квалифицированной команды SIEM превращается в «балласт» и «дорогую игрушку» — экономия на кадрах названа одной из главных ошибок внедрения. При этом ни ML, ни генеративный ИИ не заменяют аналитика, а лишь усиливают его возможности. Парадокс в том, что кадровый дефицит одновременно повышает ценность каждого специалиста и вынуждает вендоров снижать порог входа в продукт — через автоматизацию, встроенные плейбуки и сервисные модели.

Рынок движется к платформенной модели, где SIEM становится ядром экосистемы с функциями SOAR, UEBA и XDR. Кадровый голод усиливает запрос на снижение порога входа, автоматизацию реагирования и сервисные модели. Для российского рынка дополнительным фактором становятся требования к аппаратной эффективности и совместимости с отечественными продуктами.

Тем, кто выбирает SIEM сейчас, эксперты рекомендуют оценивать не только текущий функционал, но и экосистему, дорожную карту развития, стоимость владения на горизонте 2–3 лет и, возможно, самое важное — готовность собственной команды работать с системой. Инструмент работает ровно настолько, насколько зрелы процессы вокруг него и квалифицированны люди, которые за ним стоят.