Оценка эффективности использования SIEM

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

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

Материал основан на оценке эффективности работы Kaspersky Unified Monitoring and Analysis Platform (KUMA), соответственно, все конкретные примеры, команды и названия полей взяты из этого решения. Однако методику проверки, выявленные проблемы и способы повышения эффективности системы несложно экстраполировать на любые другие SIEM.

Методология оценки эффективности SIEM

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

• Состав и полнота подключенных источников
• Полнота покрытия источников
• Потоки данных от имеющихся источников
• Корректность нормализации данных
• Работоспособность детектирующей логики
• Корректность детектирующей логики
• Полнота детектирующей логики
• Использование контекстных данных
• Интеграция SIEM в процессы SOC на техническом уровне
• Работа сотрудников SOC с оповещениями в SIEM
• Передача оповещений, информации о событиях и инцидентах ИБ в другие системы
• Архитектура внедрения и документация

При этом указанные направления рассматриваются не только сами по себе, но и с учетом возможного влияния друг на друга. Вот пара примеров, иллюстрирующих такое влияние.

• Проблемы с детектирующей логикой из-за некорректной нормализации данных. Правило корреляции с условием deviceCustomString1 not contains <string> генерирует множество срабатываний. При этом детектирующая логика корректна: конкретное событие, на которое ориентируется правило, и конкретное поле не должны содержать большого количества информации, подходящей под условие. Как показала проверка, проблема была в данных, поступающих в SIEM, где из-за некорректной кодировки строка, на которую ориентировалось правило, преобразовывалась в другую. Как следствие, все события попадали под условие и генерировали срабатывание.
• При анализе покрытия конкретного типа источников мы выяснили, что SIEM видит лишь 5% от всех источников этого типа, размещенных в инфраструктуре. При этом расширение покрытия вызовет увеличение нагрузки на производительность системы, а также на используемое хранилище. Соответственно, помимо подключения дополнительных источников необходимо расширить ресурсы для отдельных модулей (хранилище, коллекторы или коррелятор).

Оценка эффективности проходит в несколько этапов.

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

В результате такой оценки формируется перечень рекомендаций, часть из которых можно применить практически сразу, а другая часть требует более комплексных изменений, связанных, например, с оптимизацией процессов или переходом на более структурированный подход к использованию системы.

Проблемы, возникающие при эксплуатации SIEM

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

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

Основные наблюдения в рамках оценки

Перечень источников

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

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

Попадались нам и нестандартные случаи неполного перечня источников. Например, в инфраструктуре присутствуют хосты под управлением ОС Windows и Linux, однако к мониторингу подключено только одно семейство операционных систем.

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

В качестве шпаргалки для себя мы составили перечень типов систем, которые встречаются в большинстве организаций. В зависимости от типа организации, ее инфраструктуры и модели угроз мы можем по-разному расставлять приоритеты, однако начать можно со следующего.

• Высокий приоритет — источники, связанные с:
  • предоставлением удаленного доступа;
  • внешними сервисами, доступными из интернета;
  • внешним периметром организации;
  • операционными системами конечных точек;
  • средствами защиты информации.
• Средний приоритет — источники, связанные с:
  • организацией удаленного доступа внутри периметра;
  • сетевым взаимодействием внутри периметра;
  • обеспечением работоспособности инфраструктуры организации;
  • виртуализацией и облачными решениями.
• Низкий приоритет — источники, связанные с:
  • бизнес-приложениями;
  • внутренними IT-сервисами;
  • приложениями различных профильных подразделений (HR, Development, PR, IT и т. д.).

Контроль потока от источников

Независимо от того, насколько хороша логика детектирования, она не будет работать без телеметрии от источников.

Проблема: ядро SIEM не получает события от конкретных источников или коллекторов. Исходя из всех проведенных оценок, средняя доля коллекторов, которые не передают события, хотя имеют настроенные источники, составляет 38%. При этом для источников могут присутствовать правила корреляции, которые, конечно, никогда не сработают. Дополнительно стоит помнить, что за коллектором могут быть сотни источников (например, рабочих станций) и отсутствие потока даже с одного коллектора может означать отключение от мониторинга значительной части инфраструктуры.

Как обнаружить: поиск источников, не передающих данные, можно разбить на две составляющие.

1. Проверка работоспособности коллектора: найдите статус коллекторов (как это сделать в KUMA, можно почитать на сайте поддержки) и определите те из них, чей статус имеет значение Offline, Stopped, Disabled и т. д.
2. Проверка потока событий. Выполнить ее в KUMA можно путем получения статистики с помощью следующего запроса (подсчет количества событий, пришедших с каждого коллектора за определенный промежуток времени):

При этом необходимо указывать оптимальный временной диапазон для сбора статистики. Слишком большой может увеличить нагрузку на SIEM, слишком маленький — дать неточную информацию при однократной проверке (особенно при наличии источников, которые передают телеметрию сравнительно редко, например раз в неделю). Поэтому стоит выбирать небольшой временной диапазон, например 2–4 дня, но выполнять несколько запросов за различные периоды в прошлом.

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

Покрытие источников событий

Проблема: события приходят не со всех источников конкретного типа, присутствующих в инфраструктуре. Например, компания использует рабочие станции и серверы под управлением Windows. В рамках внедрения SIEM рабочие станции сразу подключают к мониторингу, а серверный сегмент по той или иной причине оставляют на потом. Таким образом, SIEM получает события от Windows-систем, поток нормализован, правила корреляции работают, однако инцидент в неподключенном сегменте (на серверах) останется незамеченным.

Как обнаружить: ниже приводятся варианты запроса, который можно использовать для поиска неподключенных источников.

• SELECT count(distinct, DeviceAddress), DeviceVendor, DeviceProduct FROM `events` GROUP BY DeviceVendor, DeviceProduct ORDER BY count(ID)

  1	SELECT count(distinct, DeviceAddress), DeviceVendor, DeviceProduct FROM `events` GROUP BY DeviceVendor, DeviceProduct ORDER BY count(ID)

• SELECT count(distinct, DeviceHostName), DeviceVendor, DeviceProduct FROM `events` GROUP BY DeviceVendor, DeviceProduct ORDER BY count(ID)

  1	SELECT count(distinct, DeviceHostName), DeviceVendor, DeviceProduct FROM `events` GROUP BY DeviceVendor, DeviceProduct ORDER BY count(ID)

Мы разделили запрос на две версии, поскольку в зависимости от источника и настроек интеграции с DNS некоторые события могут содержать лишь одно из полей: DeviceAddress или DeviceHostName.

Запрос позволит определить количество уникальных источников данных с определенным типом логов. Его необходимо сравнить с данными о количестве источников соответствующего типа, полученными от владельцев систем.

Сохранение сырых данных

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

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

Как обнаружить: опция применяется на уровне нормализатора, поэтому необходимо проверить все используемые нормализаторы и определить, нужна ли она для их работы.

Нормализация

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

Проблема: можно выделить несколько связанных с нормализацией проблем.

• Поток событий вообще не нормализуется.
• События нормализуются не полностью (особенно актуально для нормализаторов не «из коробки»).
• Используется нормализатор, который парсит только заголовки, например syslog_headers, а все тело события помещает в одно поле (чаще всего — Message).
• Используется устаревший нормализатор «из коробки».

Как обнаружить: проблемы с нормализацией обнаружить сложнее, чем проблемы с источниками, ввиду большого объема телеметрии и различных парсеров. Здесь приведем несколько вариантов сужения области поиска.

• В первую очередь необходимо проверить, какие нормализаторы, поставляющиеся вместе со SIEM-системой, используются в организации, и является ли их версия актуальной. В рамках проведенных оценок мы нередко сталкиваемся с нормализацией событий auditd с помощью нормализатора Linux audit and iptables syslog v2 для KUMA, который является устаревшим. Новый нормализатор [OOTB] Linux auditd syslog for KUMA 3.2 позволяет полностью изменить и оптимизировать схему нормализации для событий из этого источника.
• Выполнить запрос:

Он позволит собрать статистику по событиям от каждого коллектора, разбитую по полям DeviceVendor и DeviceProduct, которые, в свою очередь, хотя и не являются обязательными, но присутствуют практически в любой схеме нормализации. Соответственно, полное их отсутствие или пустые значения в них могут указывать на проблемы с нормализацией. Если вы разрабатываете собственные нормализаторы, мы также рекомендуем использовать в них эти поля.

Также, чтобы упростить себе выявление проблем с нормализацией, при разработке собственных нормализаторов можно использовать следующий механизм. Для каждого нормализованного события добавлять поле Name с помощью константы или из самого события, а финальным нормализатором, куда будут попадать все ненормализованные события, с помощью константы указывать поле name = unparsed event. В дальнейшем это позволит выявлять ненормализованные события с помощью простого поиска по этому полю.

Покрытие детектирующей логикой

Сами по себе собранные события с точки зрения SIEM в большинстве случаев могут быть использованы только для расследования уже обнаруженного инцидента. Чтобы система работала полноценно, необходимо разрабатывать логику детектирования, которая будет выявлять вероятные инциденты ИБ.

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

Отметим, что мы не рекомендуем решать эту проблему, просто не подключая источники к SIEM. Наоборот, источники подключать нужно, однако стоит делать это одновременно с разработкой соответствующей детектирующей логики, потому что впоследствии про нее можно забыть или отложить ее на неопределенное время, в течение которого источник будет напрасно нагружать систему.

Как обнаружить: здесь мы снова возвращаемся к проведению аудита, в котором может сильно помочь создание и ведение документа «Перечень разработанной детектирующей логики». Ввиду того что не каждая детектирующая логика содержит прямое указание на тип источника, с которого она ожидает телеметрию, добавлять ее описание в документ стоит на стадии разработки этой логики.

Если же описания правил корреляции нет, то при проведении аудита можно ориентироваться на следующее.

• Название логики детектирования — при стандартизированном подходе к наименованию правил корреляции в названии можно указывать связанный источник или как минимум краткое описание того, что именно правило детектирует
• Использование в правилах таких полей, как DeviceVendor, DeviceProduct (еще один аргумент в пользу указания этих полей в нормализаторе), Name, DeviceAction, DeviceEventCategory, DeviceEventClassID и т. д., которые могут помочь идентифицировать сам источник

Спам от детектирующей логики

Один из критериев эффективности правил корреляции — низкий уровень ложноположительных срабатываний.

Проблема: детектирующая логика генерирует аномально большое количество срабатываний, которые физически невозможно обработать, сколько бы ни было сотрудников в SOC.

Как обнаружить: в первую очередь детектирующая логика должна тестироваться в процессе разработки и дорабатываться до приемлемого уровня ложноположительных срабатываний. Однако даже хорошо настроенное правило корреляции может начать выдавать избыточные срабатывания из-за изменений в потоке событий или подключенной инфраструктуре. Для обнаружения таких правил рекомендуется периодически применять запрос:

Значение «3» в поле Type в KUMA означает, что это событие является корреляционным.

Далее для каждого выявленного правила с аномальным количеством срабатываний необходимо проверить корректность используемой логики и корректность потока событий, на котором оно срабатывало.

В зависимости от выявленной проблемы решением может быть изменение логики, добавление исключений (например, часто бывает так, что 99% спама приходится на 1–5 объектов, таких как IP-адрес, параметр в команде, URL-адрес и т. д.) либо корректировка сбора и нормализации событий.

Отсутствие интеграции с индикаторами компрометации

Интеграции SIEM с другими системами в целом являются важной частью как обработки событий, так и обогащения оповещений. При этом как минимум в одном случае ее наличие напрямую влияет на эффективность обнаружения — речь об интеграции с техническими данными Threat Intelligence, или с IoC (индикаторами компрометации).

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

Проблема: отсутствует интеграция с данными TI.

Как обнаружить: в целом интеграция с индикаторами компрометации в SIEM осуществляется на уровне конфигурации системы при внедрении или в ходе дальнейшей оптимизации. Использование TI в SIEM может быть реализовано на различных уровнях.

• На уровне источника данных — некоторые источники, например NGFW, добавляют такую информацию к событиям, в которых фигурируют соответствующие объекты.
• На уровне функциональности SIEM — например, KUMA интегрируется с индикаторами Kaspersky CyberTrace, которые добавляют информацию о репутации объектов в момент обработки события от источника.
• На уровне логики детектирования — информация об индикаторах компрометации сохраняется в различных списках или активных листах, а правила корреляции сопоставляют с ними объекты и обогащают событие.

При этом данные TI не появляются в SIEM из ниоткуда. Они либо предоставляются внешними поставщиками (на коммерческой основе или в открытом формате), либо входят в функциональность используемых средств защиты информации. Например, различные системы класса NGFW могут дополнительно проверять репутацию внешних адресов или доменов, к которым обращаются пользователи. Таким образом, сначала следует определить, получаете ли вы информацию об индикаторах компрометации и в каком виде (выполнялась ли интеграция с внешними поставщиками, есть ли у используемых СЗИ такая функциональность). При этом стоит отметить, что получение данных TI только на уровне СЗИ не всегда позволяет охватить все типы индикаторов компрометации.

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

Если данные TI поступают от внешних поставщиков, то необходимо определить, в каком виде они обрабатываются в организации: есть ли централизованная система накопления данных об угрозах и управления ими (например, Kaspersky CyberTrace), или информация сохраняется, например, в файлах .csv.

В первом случае есть система накопления данных об угрозах и управления ими — необходимо проверить, интегрирована ли она в SIEM. Для KUMA и Kaspersky CyberTrace такая интеграция осуществляется через интерфейс SIEM. После этого потоки событий SIEM направляются в систему накопления данных об угрозах и управления ими, где выявляются совпадения и формируются оповещения, которые передаются обратно в SIEM.

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

Во втором случае (информация об угрозах сохраняется в файлах) необходимо убедиться, что в SIEM существуют коллектор и нормализатор, которые загружают данные в систему в виде событий. Также нужно проверить, настроена ли логика сохранения этих данных в SIEM для использования в корреляции. Обычно это делается при помощи списков, которые содержат полученные индикаторы компрометации. Наконец, стоит проверить, существует ли правило корреляции, которое сопоставляет поток событий со списками IoC.

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

С SIEM ничего не происходит

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

Кроме того, стоит учитывать, что невозможно покрыть 100% всех угроз, поэтому нужно постоянно исследовать атаки, разрабатывать способы детектирования и настраивать соответствующие правила. Развивается и сам SOC, и когда он доходит до определенного уровня зрелости, открываются новые точки роста для команды, которые требуют задействования новых возможностей.

Проблема: SIEM не развивается с момента внедрения.

Как обнаружить: сравнить пояснительную записку (или иную документацию на внедрение) с текущим состоянием. Если изменений нет либо они минимальны, то, скорее всего, для вашего решения SIEM существуют зоны роста и оптимизации: любая инфраструктура живет и требует постоянной адаптации.

Другие проблемы с внедрением и эксплуатацией SIEM-систем

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

• Несоответствие объема лицензии фактической нагрузке на SIEM. При этом практически всегда проблема не в неправильной оценке потребностей организации, а в отсутствии нужных событий от источников.
• Отсутствие управления правами пользователей системы (например, все пользователи имеют роль «администратор»).
• Неудобная организация настраиваемых ресурсов SIEM (правил, нормализаторов, фильтров и т. д.). Например, хаотическое наименование ресурсов, неоптимальная группировка, устаревший и тестовый контент вперемешку с действующим. Так, мы встречали такие противоречивые названия ресурсов, как [dev] test_Добавление пользователя в группу админов_final2.
• Использование коробочных ресурсов без адаптации к инфраструктуре организации. Чтобы SIEM-система приносила максимальную пользу, нужно как минимум заполнять список исключений и указывать параметры инфраструктуры: перечень администраторов, критичных сервисов и хостов.
• Отключение нативных интеграций с такими внешними системами, как LDAP, DNS, GeoIP.

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

Заключение

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

Если SOC перегружен или по иной причине не может самостоятельно выявлять проблемы с эксплуатацией SIEM, пользователям платформы KUMA мы предоставляем услугу по оценке эффективности ее эксплуатации. По итогам оценки мы формируем список рекомендаций по устранению проблем. При этом стоит оговориться, что они не являются строгим руководством к действию, но обозначают моменты, на которые стоит обратить внимание и проанализировать, чтобы улучшить результаты работы продукта, повысить точность детектирования угроз и более эффективно использовать SIEM.