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