Представим, что SOC классифицировал инцидент как критический.

Команда отреагировала быстро. Системы восстановлены. Прямые потери пока невелики. Технически ситуация находится под контролем.

Означает ли это, что инцидент несущественный?

Не обязательно.

И обратная ситуация: инцидент получил средний уровень критичности, потому что затронуто небольшое количество данных. Но это может быть информация о стратегической сделке, ключевом клиенте, исходном коде или архитектуре продукта.

Технический масштаб невелик. Бизнес-последствия могут быть огромными.

На мой взгляд, компании часто совершают ошибку, пытаясь встроить materiality в обычную шкалу классификации инцидентов:

Low → Medium → High → Critical → Material.

Но materiality — не уровень severity.

Техническая классификация отвечает на вопрос:

Насколько быстро и интенсивно должна действовать команда реагирования?

Оценка существенности отвечает на другой вопрос:

Может ли событие изменить решения клиентов, инвесторов, партнёров, регуляторов или руководства?

Именно поэтому решение нельзя полностью передать SOC или CISO.

ИБ владеет важной частью фактов:

каким способом произошла атака;

какие системы могли быть затронуты;

сохраняется ли доступ злоумышленника;

могла ли произойти эксфильтрация;

насколько надёжно выполнено сдерживание.

Но для полноценного решения нужны и другие факты: - влияние на выручку и прогнозы; - обязательства по ключевым договорам; - вероятность претензий; - влияние на сделку или стратегический проект; - необходимость уведомления клиентов и регуляторов; - репутационные и долгосрочные последствия.

Поэтому я не считаю правильным назначать CISO единственным владельцем решения о существенности.

Оптимальная модель — межфункциональный materiality committee: ИБ, финансы, legal, risk, бизнес, privacy, PR и, при необходимости, investor relations.

Техническое расследование при этом не должно завершаться до начала оценки существенности. Они должны идти параллельно.

В первые часы полной картины почти никогда нет. Но можно определить, существует ли реалистичный сценарий, при котором событие окажется существенным.

Если существует, инцидент получает предварительный статус potentially material. После этого назначаются владельцы недостающих фактов, сроки повторной оценки и максимальный срок принятия решения.

Особенно важно анализировать связанные события.

Несколько небольших компрометаций учётных записей могут быть следствием одной уязвимости. Несколько утечек у одного поставщика — проявлением общего риска цепочки поставок. Несколько случаев обхода MFA — признаком системной проблемы identity security.

По отдельности каждое событие может выглядеть несущественным. В совокупности — менять оценку риска компании.

Моя позиция:

CISO должен отвечать за качество технических фактов и сценариев киберриска, но не единолично за корпоративное решение о существенности.

ИБ определяет, что произошло с технологиями. Бизнес, финансы, legal и risk совместно определяют, что произошедшее означает для компании.

Как вы считаете, кто должен иметь последнее слово: CISO, CEO, legal, CFO или межфункциональный комитет?