писал писали на Хабре.Про Time-to-Attack я уже
Обычно, когда только компании подступаются к этому вопросу, они идут по пути наименьшего сопротивления, выбирая некое усредненное значение, которое берется у ИТ-подразделения, или оно определяется сверху регуляторами.
В качестве примера можно назвать положения Банка России 779-П и 787-П, в которых указаны пороговые уровни допустимого времени простоя и (или) деградации технологических процессов (в часах).
Чем плохо усредненного значение от ИТ? Именно тем, что оно усредненное, не учитывающее множество дополнительных факторов. Нельзя взять некую «универсальную» цифру вроде 1 часа или 10 минут и сказать, что это правильное время реакции на инцидент (response time, не путать с time to response) для всех организаций и любых систем. Подход к определению значения этой метрики зависит от нескольких ключевых факторов: критичности ресурсов, типа инцидентов, внутренних и внешних регуляторных требований, а также от фактических возможностей команды ИБ (штат, инструменты, процессы).
Определение бизнес-критичности и потенциального ущерба
Критичность системы. Сервисы, которые напрямую приносят доход или обеспечивают функционирование ключевых бизнес-процессов (например, платежная система или геолокация), требуют более жестких требований к времени реакции — вплоть до нескольких минут, а для непрерывных технологических процессов и того быстрее.
Тип и уровень конфиденциальности данных. Для систем, обрабатывающих персональные данные спецкатегории, обычно вводят ускоренные сроки реагирования, поскольку инцидент здесь может повлечь большие финансовые и репутационные потери.
здесь и здесь.Чем выше потенциальный ущерб (простой бизнеса, финансовые потери, нарушение комплаенса), тем короче допустимый интервал на реакцию. Про оценку ущерба я писал
Категоризация инцидентов и SLA/OLA
Классифицируйте инциденты по уровню критичности. Например, «Высокая» (Critical), «Средняя» (Major), «Низкая» (Minor). Для каждой категории закрепите разные целевые значения по времени реакции.
Я уже писал про различные варианты классификации инцидентов .
Пропишите SLA/OLA (соглашения об уровне услуг и соглашения между подразделениями). В них должно быть четко указано, что именно понимается под «временем реакции»: момент начала активных действий (Containment) или хотя бы первичного отклика (Acknowledgement) и т.д. Например:
- Высококритические инциденты (утечка значимых данных, DDoS ядра сети или ключевых систем) — первичная реакция в течение 15 минут, развернутые действия по ограничению (containment) в течение часа.
- Среднекритические инциденты (локальные компрометации, вирусные атаки на внутренние узлы) — первичная реакция до 1 часа и т. д.
Но такое делается нечасто!
Баланс между желаемым и реальностью
- Оцените ресурсы. Сколько у вас специалистов по ИБ, есть ли круглосуточный SOC, можете ли вы реально держать дежурство 24/7?
- Инструменты мониторинга. Если у вас есть SIEM/EDR/SOAR с достаточно высоким уровнем автоматизации, то можно ставить более жесткие сроки обнаружения и реагирования. Если все делает вручную один человек, значение метрики в 10 минут будет недостижимо.
- Четкие процессы. Без отлаженного процесса эскалации (когда дежурный смены SOC может быстро привлечь нужных специалистов) любые «агрессивные» цели по времени реакции останутся лишь на бумаге.
Но вообще, описанные и поддерживаемые процессы в SOC, — это редкость. Либо до них просто не доходят руки после закупки всяких инструментов и их внедрения, либо они не поддерживаются должным образом и написанное в них расходится с реальным положением дел.
Учет отраслевых и регуляторных требований
Во многих странах и отраслях (финансы, госучреждения, здравоохранение, транспорт и т.п.) могут быть обязательные требования к срокам уведомления о инцидентах (например, «не позднее 72 часов») или к срокам ликвидации.
Например, такие сроки установления для значимых и незначимых объектов КИИ, для утечек персональных данных, для финансовых организаций и т.п.
Если речь про международные стандарты и требования (GDPR, NIST, ISO/IEC 27035 и др.), нужно сверяться с ними: где-то регламентированы именно сроки уведомления регулятора или клиентов, где-то рекомендованы ориентиры по раннему обнаружению.
Особая сложность для международных компаний — сопоставить все национальные требования и учесть их, подведя некий общий знаменатель.
Регулярный пересмотр и адаптация
Часто компании начинают с реалистичного уровня (например, «реакция на критический инцидент — до 1 часа») и отслеживают фактическую статистику. Если оказывается, что фактическое среднее время превышает плановые значения (например, реально 2 часа вместо заявленного 1 часа), нужно либо усиливать команду, либо инвестировать в инструменты автоматизации, либо менять целевой показатель.
Примерный подход к формированию метрики времени реагирования
- Собрать информацию о системах и бизнес-процессах: важность, финансовая ценность, комплаенс, возможный ущерб.
- Ранжировать системы/процессы по критичности (1–3 уровня, можно больше).
- Определить тип инцидентов: утечка, DDoS, внутренний саботаж, вредоносное ПО, APT и т. д. — для каждой категории может отличаться приоритет.
- Прописать значения «максимального времени первичной реакции» для каждого уровня критичности.
- Закрепить их во внутренних регламентах, SLA/OLA.
- Обеспечить контроль исполнения (учет инцидентов, автоматизация, отчетность).
- Пересматривать не реже раза в год или после значимых изменений в инфраструктуре.
Одно время реагирования или два?
Когда мы говорим о времени реагирования, то обычно подразумевается некая верхняя граница, выше которой заступать нельзя. И с ней есть пара нюансов. Во-первых, она немного расслабляет, так как «набив руку», мы начинаем уже «спустя рукава» реагировать, имея некий запас прочности. Во-вторых, всегда существует нижняя граница, до которой инцидент практически не оказывает никакого негативного (значимого) влияния. Например, допустимое время простоя технологического процесса, обеспечивающего выполнение операций на финансовых рынках по требованиям 787-П Банка России составляет 24 часа. При этом финансовая организация может не замечать влияния этого инцидента до 8 часов (зависит от часового самой организации и биржи, на которой она работает). Простой менее 8 часов может быть совсем незаметен.
В этом случае можно вводить специальный показатель, который оценивается по тому, в какую часть шкалы от минимального до максимального времени реагирования укладывается реальное значение. Если мы уложились быстрее минимального порога, то мы устанавливаем значение показателя в 1. Если вышли за максимальное значение, то получаем 0. Ну а между минимальным и максимальным значениями показатель будет принимать значение от 0 до 1.
В реальности вы иногда будете выходить за максимально отведенное на реагирование время. И это может приводить к тому, что у ИБ-команды может пропасть интерес заниматься просроченными инцидентами. Для учета этого момента есть более сложная формула и про нее как-нибудь в другой раз.
Иными словами, можно попробовать внедрить не один временной показатель response time, а два, — максимальное и минимальное значение времени реагирования. С одной стороны ими сложнее управлять (и понадобится дольше времени на сбор сведений для их расчета), но с другой — мы получаем возможность улучшить процесс отражения атак, особенно если мы поручаем эту задачу внешнему поставщику. В обычной жизни ему выгодно разруливать все инциденты в рамках максимального срока реагирования, но вам-то нужно делать это быстрее; в идеале, как можно ближе к минимальному времени. И если вы введете упомянутый выше специальный показатель и привяжете к нему вознаграждение (или систему «штрафов») для провайдера услуг ИБ или аутсорсингового SOC, то эти стимулирует их выкладываться лучше.
Заметка Как рассчитывать время реагирования на инциденты? была впервые опубликована на Бизнес без опасности .
