Была тут встреча с заказчиком, которому мы SOC помогаем строить. Ну и зашел разговор о метриках, всяких TTA, TTR, TTC и куче других, о которых мы большую статью выпустили на Хабре. Но… важный вопрос, который часто звучит после того, как компании определились с метриками, — как определить конкретные показатели для этих метрик, в частности для времени реагирования?
Про 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, то эти стимулирует их выкладываться лучше.
