Привет, спасибо за обратную связь! В среднем от недели до двух, зависит от сложности правила и времени, которое нужно потратить на обработку тестовых сработок и внесени исключений, если это необходимо
Привет, спасибо за обратную связь! Отвечу на вопросы также по пунктам: 1. Для начала аналитик L1 может просто пообщаться с разработчиком правила в корпоративном месенджере и обсудить логику правила. Кроме того, один раз в неделю мы собираемся группами L1 и L2 и разбираем вопросы друг друга. Все вопросы непосредственно про мониторинги безопасности. Во второй части встречи смотрим метрики по алертам, чтобы понять, какое правило создаёт много шума, а также какие аномалии были за прошедшую неделю. Однако и доля автоматизации присутствует: если сотрудник L1 явно видит ошибку в правиле, то может с помощью "волшебной кнопки" создать баг, который аналитик L2 должен будет проанализировать, спланировать и выполнить, если ошибка валидна. 2. Наверное частично ответил в первом пункте. После релиза на уже упомянутом синке мы увидим, если правило создает много ложных и легитимных сработок, из-за чего появится необходимость его исправления, так как L1 заинтересованы в том, чтобы мониторинг был качественный. В основном мы смотрим на кол-во FP/LTP/TP, а также на проценты от общего количества. Человеко-часы явно не измеряем, однако спрашиваем у ребят, много ли уходит времени на разбор конкретного правила относительно другого, при этом было ли это время потрачено на действительно важную сработку. 3. Прям для каждого правила не считаем суммарных изменений, однако на примере своих правил могу сказать, что количество ложных и легитимных сработок в сумме снизилось в 2 раза на этапе тестирования правила и ретроспективного анализа сработок. Ну и из-за того, что мы поддерживаем правила актуальным на всем его жизненном цикле, разницу лучше просматривать для конкретных временных интервалов. В одно время правило могло молчать, а в другое, при изменении инфраструктуры, оно засыпало нас легитимными сработками.
Привет, спасибо за обратную связь! Самая легкая стадия разработки - однозначно анализ необходимости правила. Достаточно проверить, насколько покрыта та или иная угроза, а также применима ли она в целом к нашей инфраструктуре. Тяжелые же части - это как раз разработка и тестирование, однако последняя и самая эффективная!
Привет, спасибо за обратную связь! В среднем от недели до двух, зависит от сложности правила и времени, которое нужно потратить на обработку тестовых сработок и внесени исключений, если это необходимо
Привет, спасибо за обратную связь! Отвечу на вопросы также по пунктам:
1. Для начала аналитик L1 может просто пообщаться с разработчиком правила в корпоративном месенджере и обсудить логику правила. Кроме того, один раз в неделю мы собираемся группами L1 и L2 и разбираем вопросы друг друга. Все вопросы непосредственно про мониторинги безопасности. Во второй части встречи смотрим метрики по алертам, чтобы понять, какое правило создаёт много шума, а также какие аномалии были за прошедшую неделю. Однако и доля автоматизации присутствует: если сотрудник L1 явно видит ошибку в правиле, то может с помощью "волшебной кнопки" создать баг, который аналитик L2 должен будет проанализировать, спланировать и выполнить, если ошибка валидна.
2. Наверное частично ответил в первом пункте. После релиза на уже упомянутом синке мы увидим, если правило создает много ложных и легитимных сработок, из-за чего появится необходимость его исправления, так как L1 заинтересованы в том, чтобы мониторинг был качественный. В основном мы смотрим на кол-во FP/LTP/TP, а также на проценты от общего количества. Человеко-часы явно не измеряем, однако спрашиваем у ребят, много ли уходит времени на разбор конкретного правила относительно другого, при этом было ли это время потрачено на действительно важную сработку.
3. Прям для каждого правила не считаем суммарных изменений, однако на примере своих правил могу сказать, что количество ложных и легитимных сработок в сумме снизилось в 2 раза на этапе тестирования правила и ретроспективного анализа сработок. Ну и из-за того, что мы поддерживаем правила актуальным на всем его жизненном цикле, разницу лучше просматривать для конкретных временных интервалов. В одно время правило могло молчать, а в другое, при изменении инфраструктуры, оно засыпало нас легитимными сработками.
Привет, спасибо за обратную связь! Самая легкая стадия разработки - однозначно анализ необходимости правила. Достаточно проверить, насколько покрыта та или иная угроза, а также применима ли она в целом к нашей инфраструктуре. Тяжелые же части - это как раз разработка и тестирование, однако последняя и самая эффективная!