Немного упрощу свой ответ - процессы могут существовать без регламентов (утвержденных документов). Регламенты нужны для стандартизации процесса, придания ему официального статуса с указанием зон ответственности и тд, превращая процесс в упорядоченную повторяемую процедуру, зафиксированную "на бумаге" и обязательную к исполнению.
Если приемлемые значения метрик достигаются и без утвержденных регламентов, то скорее всего ведутся работы по большинству направлений из того, что описано в статье. Это значит, что процессы есть в том или ином виде, например не формализованы на бумаге, и выполняются на основании устных договоренностей.
Но персонал, участвующий в процессах, и сами “держатели” этих процессов могут смениться на предприятии(уволился/сменить подразделение/пойти на повышение), попросту не уведомив тех, кто будет их замещать (если такие люди вообще будут) о имеющихся договоренностей, из-за чего они(договоренности) просто могут забыться и перестать выполняться.
Поэтому регламенты и нужны, даже если показатели достигаются здесь и сейчас, чтобы как минимум сохранять их на том же уровне. Опять же повторюсь, при описании имеющихся процессов и “перекладывании” их на бумагу в виде регламентов значительно проще оценивать эффективность, оптимизировать и вносить корректировки (+ преимущества, описанные в ответе выше).
По личному опыту самой частой проблемой как раз является отсутствие каких-либо сформировавшихся процессов, где вся деятельность идёт “стихийно” (по необходимости здесь и сейчас), не системно, не прогнозируемо, и, банально, не регулярно. Отсюда и название статьи, ее основная идея.
Моя позиция такая - вне зависимости от имеющихся показателей следует вводить регламенты - это огромное подспорье во всей деятельности SOC.
Если метрики, например, высокие, то регламенты внесут "правила" для всех участников. Если метрики неудовлетворительны, то при соблюдении регламентов (а иначе зачем они), показатели, по моему опыту, будут улучшаться.
Процессы и регламенты нужны, чтобы внести ясность и прогнозируемость для всех участников процесса за счет понятно описанной последовательности действий, сроков их выполнения и разделения зон ответственности. При таком подходе всегда будет понятно кто, что и почему делает, и какого результата ожидать на каждом этапе.
Также, в частности, регламенты служат способом оптимизации труда: в части улучшения мониторинга, чтобы источники подключались без регулярного напоминания(когда получится подключить?) и уточнений(а не появилось ли что-то новое?) со стороны технических специалистов, отвечающих за SIEM, и при расследованиях, чтобы аналитики в большинстве случаев действовали по понятным плейбукам, которые позволят минимизировать риск человеческого фактора(забыл, пропустил, не обратил внимания, и тд).
Помимо этого, оценивать эффективность работы (в том числе и искать то, что можно оптимизировать) проще в рамках структурированной, отлаженной последовательности действий.
И как косвенное преимущество - новых сотрудников проще вводить в курс дел и то как устроена работа подразделения при наличии готовых инструкций.
Основная задача SIEM - мониторить логи и обнаруживать подозрения на инциденты, поэтому основные метрики эффективности можно выделить следующие. В части “мониторить”:
соотношение количества подключенных и неподключенных источников в инфраструктуре,
соотношение полноты поступающих логов от подключенных источников к целевым показателям(соответствие уровню логирования),
процент нормализации поступающих событий от общего числа - чем выше, тем лучше.
В части “обнаруживать”:
соотношение ложно-положительных алертов/инцидентов к общему числу. Чем меньше - тем лучше ведется работа над исключениями и доработкой правил детектирования,
время взятия инцидента в работу и время его обработки до принятия решения, является ли он ложноположительным или подтвержденным,
время на локализацию и ликвидацию активности в случае подтвержденных инцидентов,
время задержки между поступлением событий и их обработкой правилами нормализации,обогащения,корреляции,
в рамках периодической проверки - фиксация активности “красных” при проведении пентеста.
Если взводятся алерты/инциденты и отслеживается вся цепочка действий - отлично. Если есть события о действиях(не приведших к взведению инцидентов/алертов) но нет алертов - не плохо(тк можно использовать при расследованиях), но есть повод задуматься о доработке правил крреляции. Если нет событий о каких-то действиях - есть над чем работать, - надо разбираться с логированием и покрытием.
Плюс из дополнительных метрик можно обратить так же внимание на:
время подключения источников событий на мониторинг,- время штатной работы(“аптайм”) SIEM в месяц/квартал/год/etc,
время обновления инсталляции и связанного с этим простоя в обработке событий, и есть ли он вообще.
Немного упрощу свой ответ - процессы могут существовать без регламентов (утвержденных документов). Регламенты нужны для стандартизации процесса, придания ему официального статуса с указанием зон ответственности и тд, превращая процесс в упорядоченную повторяемую процедуру, зафиксированную "на бумаге" и обязательную к исполнению.
Если приемлемые значения метрик достигаются и без утвержденных регламентов, то скорее всего ведутся работы по большинству направлений из того, что описано в статье. Это значит, что процессы есть в том или ином виде, например не формализованы на бумаге, и выполняются на основании устных договоренностей.
Но персонал, участвующий в процессах, и сами “держатели” этих процессов могут смениться на предприятии(уволился/сменить подразделение/пойти на повышение), попросту не уведомив тех, кто будет их замещать (если такие люди вообще будут) о имеющихся договоренностей, из-за чего они(договоренности) просто могут забыться и перестать выполняться.
Поэтому регламенты и нужны, даже если показатели достигаются здесь и сейчас, чтобы как минимум сохранять их на том же уровне. Опять же повторюсь, при описании имеющихся процессов и “перекладывании” их на бумагу в виде регламентов значительно проще оценивать эффективность, оптимизировать и вносить корректировки (+ преимущества, описанные в ответе выше).
По личному опыту самой частой проблемой как раз является отсутствие каких-либо сформировавшихся процессов, где вся деятельность идёт “стихийно” (по необходимости здесь и сейчас), не системно, не прогнозируемо, и, банально, не регулярно. Отсюда и название статьи, ее основная идея.
Моя позиция такая - вне зависимости от имеющихся показателей следует вводить регламенты - это огромное подспорье во всей деятельности SOC.
Если метрики, например, высокие, то регламенты внесут "правила" для всех участников. Если метрики неудовлетворительны, то при соблюдении регламентов (а иначе зачем они), показатели, по моему опыту, будут улучшаться.
Процессы и регламенты нужны, чтобы внести ясность и прогнозируемость для всех участников процесса за счет понятно описанной последовательности действий, сроков их выполнения и разделения зон ответственности. При таком подходе всегда будет понятно кто, что и почему делает, и какого результата ожидать на каждом этапе.
Также, в частности, регламенты служат способом оптимизации труда: в части улучшения мониторинга, чтобы источники подключались без регулярного напоминания(когда получится подключить?) и уточнений(а не появилось ли что-то новое?) со стороны технических специалистов, отвечающих за SIEM, и при расследованиях, чтобы аналитики в большинстве случаев действовали по понятным плейбукам, которые позволят минимизировать риск человеческого фактора(забыл, пропустил, не обратил внимания, и тд).
Помимо этого, оценивать эффективность работы (в том числе и искать то, что можно оптимизировать) проще в рамках структурированной, отлаженной последовательности действий.
И как косвенное преимущество - новых сотрудников проще вводить в курс дел и то как устроена работа подразделения при наличии готовых инструкций.
Основная задача SIEM - мониторить логи и обнаруживать подозрения на инциденты, поэтому основные метрики эффективности можно выделить следующие. В части “мониторить”:
соотношение количества подключенных и неподключенных источников в инфраструктуре,
соотношение полноты поступающих логов от подключенных источников к целевым показателям(соответствие уровню логирования),
процент нормализации поступающих событий от общего числа - чем выше, тем лучше.
В части “обнаруживать”:
соотношение ложно-положительных алертов/инцидентов к общему числу. Чем меньше - тем лучше ведется работа над исключениями и доработкой правил детектирования,
время взятия инцидента в работу и время его обработки до принятия решения, является ли он ложноположительным или подтвержденным,
время на локализацию и ликвидацию активности в случае подтвержденных инцидентов,
время задержки между поступлением событий и их обработкой правилами нормализации,обогащения,корреляции,
в рамках периодической проверки - фиксация активности “красных” при проведении пентеста.
Если взводятся алерты/инциденты и отслеживается вся цепочка действий - отлично.
Если есть события о действиях(не приведших к взведению инцидентов/алертов) но нет алертов - не плохо(тк можно использовать при расследованиях), но есть повод задуматься о доработке правил крреляции.
Если нет событий о каких-то действиях - есть над чем работать, - надо разбираться с логированием и покрытием.
Плюс из дополнительных метрик можно обратить так же внимание на:
время подключения источников событий на мониторинг,- время штатной работы(“аптайм”) SIEM в месяц/квартал/год/etc,
время обновления инсталляции и связанного с этим простоя в обработке событий, и есть ли он вообще.