Что касается процесса проверки контента - тут будет несколько итераций Начиная с написания детектирующей логики. Каждое правило корреляции после формирования базовой логики проходит этап "профилирования" - в течение этого этапа алерты по нему не приходят, но корреляционные события создаются. Для вывода правила в "прод" - идем по ранбуку:
Ручной тест работы правила (синтетика) - убедиться, что логика правила корректно работает;
Ретроспективный анализ - прогон детектирующей логики по старым событиям (за последние 30 дней), для формирования базы потенциально нелегитимной активности;
Анализ активности по ретроскану (при необходимости - с привлечением администраторов/пользователей) - для принятия решения о легитимности.
Создание отдельного фильтра для правила корреляции - для включения в него всех исключений;
Настройка сегментации по правилу - определить условия, при которых на основе однотипных корреляционных событий будут создаваться разные алерты;
Заполнение доп.полей - "Описание", "Техники MITRE", "Шаблон карточки для SOAR";
Мы стараемся делать исключения максимально точечными. Полную перепроверку логики исключений при каждом изменения не проводим, т.к. некорректно настроенное точечное исключение просто не отработает и прилетит очередной FP.SOC. Для каждого исключения фиксируем область действия, причину и саму логику исключения в базе знаний. Все исключения подлежат периодической верификации (чтобы не допускать "широких" или уже неактуальных исключений).
А чтобы защитить себя от потенциальных false negative - проводим тестирование правил (в том числе и bas-решениями). Тут рассматриваю, как зону роста, применимость истории с Detection as Code и внедрением автотестов. Если кто-то из читателей проходил этот путь - поделитесь своим опытом и подходами)
И если FP.SOC - это бэклок на доработку, то обычный FP - это организационная сторона вопроса. Снижение FP обычно достигается путем взаимодействия со смежными подразделениями или пользователями. Это либо единичная активность со стороны пользователей и мы ориентируем их на внимательность, проводим инструктажи, формируем иб-дайджесты (либо идем в security awarness). Либо это может быть активностью ит-подразделений, которая не противоречит регламентам, но находится в "серой зоне" - обсуждаем совместно кейс, договариваемся по "правилам игры". А часть FP просто закрываются "на лету", т.к. блок ИТ, например, проинформировал о старте и составе работ, и нам при этом делать какие-либо исключения или мьютить правила - не требуется. Тут мы не стремимся к нулевому FP - уж лучше контролируемый шум, чем широкое исключение.
Справедливое замечание! Bus-фактор, равный одному человеку - это всегда слабое звено.
Абсолютно согласен, по мере повышения уровня зрелости SOC - эту задачу целесообразно планомерно делегировать аналитикам. При этом будет важно зафиксировать в базе знаний единый чек-лист, правила выборки, паттерны для принятия решения, чтобы не превратить делегирование в хаос. Тогда роль руководителя постепенно будет смещаться уже на точечную и периодическую оценку корректности системы контроля качества. В статье я описал текущую практику, где контроль качества пока завязан на руководителя. В периоды отсутствия эта функция передается замещающему сотруднику внутри подразделения.
В будущем планирую рассказать, как мы оцениваем качество работы аналитиков и их готовность к задачам, требующим более высокого уровня самостоятельности и экспертизы, и о том, как мы рассчитываем их трудозатраты, чтобы не перегружать сотрудников дополнительной зоной ответственности. Среди этих задач также будет и контроль качества.
Коллеги, а кто еще применяет практику регулярного кросс-ревью между аналитиками? Поделитесь опытом, подсветите узкие места и подводные камни, с которыми сталкивались на практике.
Что касается процесса проверки контента - тут будет несколько итераций
Начиная с написания детектирующей логики. Каждое правило корреляции после формирования базовой логики проходит этап "профилирования" - в течение этого этапа алерты по нему не приходят, но корреляционные события создаются. Для вывода правила в "прод" - идем по ранбуку:
Ручной тест работы правила (синтетика) - убедиться, что логика правила корректно работает;
Ретроспективный анализ - прогон детектирующей логики по старым событиям (за последние 30 дней), для формирования базы потенциально нелегитимной активности;
Анализ активности по ретроскану (при необходимости - с привлечением администраторов/пользователей) - для принятия решения о легитимности.
Создание отдельного фильтра для правила корреляции - для включения в него всех исключений;
Настройка сегментации по правилу - определить условия, при которых на основе однотипных корреляционных событий будут создаваться разные алерты;
Заполнение доп.полей - "Описание", "Техники MITRE", "Шаблон карточки для SOAR";
Мы стараемся делать исключения максимально точечными. Полную перепроверку логики исключений при каждом изменения не проводим, т.к. некорректно настроенное точечное исключение просто не отработает и прилетит очередной FP.SOC. Для каждого исключения фиксируем область действия, причину и саму логику исключения в базе знаний. Все исключения подлежат периодической верификации (чтобы не допускать "широких" или уже неактуальных исключений).
А чтобы защитить себя от потенциальных false negative - проводим тестирование правил (в том числе и bas-решениями). Тут рассматриваю, как зону роста, применимость истории с Detection as Code и внедрением автотестов. Если кто-то из читателей проходил этот путь - поделитесь своим опытом и подходами)
И если FP.SOC - это бэклок на доработку, то обычный FP - это организационная сторона вопроса. Снижение FP обычно достигается путем взаимодействия со смежными подразделениями или пользователями. Это либо единичная активность со стороны пользователей и мы ориентируем их на внимательность, проводим инструктажи, формируем иб-дайджесты (либо идем в security awarness).
Либо это может быть активностью ит-подразделений, которая не противоречит регламентам, но находится в "серой зоне" - обсуждаем совместно кейс, договариваемся по "правилам игры".
А часть FP просто закрываются "на лету", т.к. блок ИТ, например, проинформировал о старте и составе работ, и нам при этом делать какие-либо исключения или мьютить правила - не требуется. Тут мы не стремимся к нулевому FP - уж лучше контролируемый шум, чем широкое исключение.
Справедливое замечание! Bus-фактор, равный одному человеку - это всегда слабое звено.
Абсолютно согласен, по мере повышения уровня зрелости SOC - эту задачу целесообразно планомерно делегировать аналитикам. При этом будет важно зафиксировать в базе знаний единый чек-лист, правила выборки, паттерны для принятия решения, чтобы не превратить делегирование в хаос. Тогда роль руководителя постепенно будет смещаться уже на точечную и периодическую оценку корректности системы контроля качества.
В статье я описал текущую практику, где контроль качества пока завязан на руководителя. В периоды отсутствия эта функция передается замещающему сотруднику внутри подразделения.
В будущем планирую рассказать, как мы оцениваем качество работы аналитиков и их готовность к задачам, требующим более высокого уровня самостоятельности и экспертизы, и о том, как мы рассчитываем их трудозатраты, чтобы не перегружать сотрудников дополнительной зоной ответственности. Среди этих задач также будет и контроль качества.
Коллеги, а кто еще применяет практику регулярного кросс-ревью между аналитиками? Поделитесь опытом, подсветите узкие места и подводные камни, с которыми сталкивались на практике.