Когда киберинцидент становится существенным: почему SOC не может решить это в одиночку

Компания обнаруживает компрометацию корпоративной системы.

SOC присваивает инциденту высокий уровень критичности. Команда реагирования изолирует узлы, блокирует учётные записи и начинает расследование. Через несколько часов работа системы восстановлена. На первый взгляд, кризис завершён.

Но затем появляются другие вопросы.

Какие данные мог получить злоумышленник? Нужно ли уведомлять клиентов? Может ли событие повлиять на крупный контракт? Возникнут ли расходы, которые изменят финансовый прогноз? Должен ли об инциденте узнать совет директоров? Требуется ли раскрывать информацию инвесторам или регулятору?

На эти вопросы нельзя ответить с помощью CVSS, уровня инцидента в SIEM или количества сработавших правил обнаружения.

Техническая классификация показывает, насколько опасным событие выглядит для инфраструктуры. Существенность показывает, насколько значимыми могут оказаться его последствия для бизнеса и заинтересованных сторон.

И это две разные управленческие задачи.

В большинстве компаний классификация инцидентов строится вокруг технических показателей:

Эти параметры необходимы. Они помогают определить приоритет реагирования, состав команды, глубину расследования и допустимое время восстановления.

Но они не дают полного ответа на вопрос о существенности.

Представим, что критическая уязвимость была использована в изолированном тестовом контуре. Технически инцидент может выглядеть серьёзно: удалённое выполнение кода, административные привилегии, высокая оценка CVSS. Однако бизнес-последствия могут оказаться ограниченными.

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

Количество затронутых записей невелико. Значение этих записей для бизнеса — огромное.

Поэтому формула «высокая техническая критичность означает высокую существенность» не работает. Как не работает и обратная формула: небольшой технический масштаб не гарантирует несущественности.

Одна из распространённых ошибок — добавить в таблицу классификации инцидентов ещё один столбец под названием «materiality».

Например:

Но существенность не является следующим уровнем технической критичности.

Severity отвечает на вопрос:

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

Materiality отвечает на другой вопрос:

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

Именно поэтому оценку существенности нельзя полностью передать SOC, CSIRT или CISO.

Специалисты по информационной безопасности могут установить:

Но ИБ не всегда может самостоятельно определить:

Для этого нужны финансы, legal, compliance, risk, PR, investor relations и владельцы затронутых бизнес-процессов.

Требования разных юрисдикций используют разные понятия, поэтому их нельзя механически объединять в один универсальный порог.

Правила SEC рассматривают materiality с позиции разумного инвестора. Для американских публичных компаний раскрытие по Item 1.05 Form 8-K обычно требуется в течение четырёх рабочих дней после определения существенности, а само решение должно быть принято без необоснованной задержки. При оценке должны учитываться не только количественные, но и качественные обстоятельства. (SEC)

Подход SEC особенно показателен: прекращение атаки, выплата выкупа или страховое возмещение сами по себе не делают инцидент несущественным. Необходимо оценивать долгосрочное влияние на операции, финансы, бренд, отношения с клиентами и доступность страхования. Связанные события, каждое из которых выглядит небольшим, могут оказаться существенными в совокупности. (SEC)

NIS2 использует понятие significant incident. Среди критериев — серьёзное нарушение предоставления услуг, финансовые потери и значительный материальный или нематериальный ущерб другим лицам. Для попадающих под действие директивы организаций предусмотрена многоступенчатая модель уведомления: раннее предупреждение в течение 24 часов, уведомление об инциденте в течение 72 часов и итоговый отчёт, как правило, не позднее месяца после уведомления. (EUR-Lex)

DORA устанавливает для финансовых организаций отдельный процесс классификации ICT-инцидентов. Оцениваются количество и значимость затронутых клиентов и транзакций, продолжительность, географический охват, потери конфиденциальности, целостности, доступности или подлинности данных, критичность услуг, репутационное и экономическое влияние. Повторяющиеся события с одной предполагаемой первопричиной также могут рассматриваться совместно. (EUR-Lex)

Здесь важно не смешивать понятия.

Инцидент может одновременно:

Это разные тесты, разные адресаты и иногда разные сроки.

Зрелая организация не пытается найти один магический показатель. Она создаёт карту применимых обязательств и запускает несколько оценок параллельно.

Ещё одна ошибка — откладывать materiality assessment до завершения расследования.

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

Поэтому процесс должен работать итеративно.

В первые часы организация располагает ограниченными фактами:

Этого недостаточно для окончательного заключения, но достаточно для предварительной оценки.

Правильный вопрос в этот момент звучит не так:

Доказали ли мы, что инцидент существенный?

А так:

Существует ли разумный сценарий, при котором инцидент может оказаться существенным?

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

Отсутствие полной информации не должно превращаться в оправдание бездействия.

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

Я бы разделил оценку на шесть направлений.

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

Два часа недоступности внутреннего портала и два часа невозможности проводить платежи, управлять производством или обслуживать пациентов — совершенно разные события.

Имеют значение:

Количество пострадавших не всегда является главным показателем.

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

Нужно оценивать не только масштаб, но и значимость затронутых сторон.

При утечке важно спрашивать не только «сколько записей похищено», но и «какое решение может принять тот, кто получит эти данные».

Особенно чувствительными могут быть:

Небольшой объём данных может иметь непропорционально высокую ценность.

Прямые расходы — лишь часть картины.

Нужно учитывать:

Материальность часто проявляется не в уже понесённых затратах, а в разумно ожидаемых последствиях.

Один инцидент способен активировать несколько параллельных процедур:

Поэтому legal и compliance должны подключаться не после завершения технического расследования, а сразу после появления потенциально значимых фактов.

Репутационный риск часто оценивают слишком поверхностно: появится ли публикация в СМИ и сколько будет негативных упоминаний.

Гораздо важнее понять:

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

Оценивать каждый инцидент изолированно удобно, но опасно.

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

Это один системный риск, который проявлялся несколько раз.

Поэтому зрелый процесс должен агрегировать события по:

Иногда существенным является не отдельный инцидент, а вывод, который руководство должно сделать из их совокупности.

На мой взгляд, нельзя назначать CISO единственным владельцем решения о существенности.

Это создаёт сразу две проблемы.

Первая — дефицит полномочий и информации. CISO может не владеть финансовыми прогнозами, содержанием договоров, контекстом сделок и ожиданиями инвесторов.

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

Оптимальная модель — заранее определённый materiality committee или аналогичный межфункциональный состав:

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

Если нет — продолжается техническая квалификация.

Если да или достоверно исключить последствия пока нельзя — переход к предварительной оценке.

Если ни одно направление не затронуто и это подтверждено фактами, событие можно оставить в стандартном процессе реагирования.

Если затронуто хотя бы одно — необходимо оценить потенциальную существенность.

Такими триггерами могут быть:

Если да — созывается materiality committee.

Оценка должна учитывать:

Необходимо отдельно проверить:

Если да — принимается и фиксируется решение.

Если нет, но существенный сценарий остаётся реалистичным, событие сохраняет статус potentially material. Назначаются:

В журнале решения должны быть отражены:

Фиксировать нужно не только результат, но и путь к нему.

Практически я бы рекомендовал семь шагов.

Первое. Разделить техническую severity, кризисную значимость и регуляторную существенность. Это разные классификации, хотя они используют общие факты.

Второе. Создать карту применимых требований. Для каждой юрисдикции и договора должны быть известны критерии, сроки, адресаты и владельцы уведомлений.

Третье. Утвердить состав materiality committee и его заместителей. Процесс должен работать ночью, в выходные и при отсутствии ключевого руководителя.

Четвёртое. Определить автоматические триггеры эскалации. Сотрудники не должны во время кризиса спорить, достаточно ли важен инцидент, чтобы позвать legal или CFO.

Пятое. Подготовить единый materiality worksheet. В нём должны оцениваться операции, клиенты, данные, финансы, право, репутация и стратегические последствия.

Шестое. Проводить tabletop exercises не только по реагированию, но и по принятию решений. В сценарии должны участвовать ИБ, бизнес, финансы, legal, PR и руководство.

Седьмое. Проверять связанные события в совокупности. Для этого данные SOC, risk register, аудита, fraud, privacy и обращений клиентов должны сопоставляться, а не существовать в отдельных системах.

Моя позиция проста:

Существенность киберинцидента нельзя вычислить внутри SOC и нельзя делегировать одному CISO. ИБ определяет, что произошло с технологиями. Но только бизнес совместно с ИБ, финансами, legal и risk может определить, что произошедшее означает для компании и её заинтересованных сторон.

Зрелость проявляется не в способности мгновенно дать окончательный ответ.

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

Самая опасная ошибка — считать инцидент несущественным только потому, что системы восстановлены, сумма ущерба пока невелика или техническая команда ещё не завершила расследование.

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

Поэтому главный вопрос руководства должен звучать не так:

Насколько критичным этот инцидент считает SOC?

А так:

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

И какие три фактора в вашей организации должны автоматически выводить киберинцидент на уровень совета директоров?

Понятия material cybersecurity incident, significant incident и major ICT-related incident относятся к разным правовым режимам. Конкретные обязательства необходимо определять с учётом юрисдикции, отрасли, статуса организации и национальной имплементации требований.

Подписывайтесь на мой ТГ канал: @ib_decisions