Классификация инцидентов Информационной безопасности

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

У каждого разные ресурсные возможности и, что более важно, разные зоны ответственности внутренних команд и корпоративные бизнес-процессы (БП), поэтому и классификации одних слабо применимы к другим, т.е. классификация инцидентов – дело сугубо индивидуальное, придумывать которую необходимо с глубоким погружением в особенности конкретного предприятия. Все это, вроде, давно известно, однако, продолжают появляться свежие статьи по теме (ссылка приводится не как пример хорошего подхода к классификации или триажу, а как подтверждение того, что в экспертном сообществе, в 2023, тема по-прежнему обсуждается, т.е. актуальна)*, поэтому, не будет лишним ее прояснить.

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

В последнее время, как будто, приходит понимание неизбежности аутсорсинга, и то, что наиболее эффективная модель операционной безопасности – гибридная, когда, имеющие свои сильные и слабые стороны внутренний и внешний ОЦИБ-ы собирают комбинацию из сильных сторон каждого, и уже в такой модели нам надо иметь рабочую классификацию. “Средний по больнице” ответ что допустимо аутсорсить можно найти здесь*. Сильной стороной внутреннего ОЦИБ является максимальная погруженность в контекст организации. В идеальном случае есть нормально работающий процесс Управления конфигурацией, куда встроена ИБ, поэтому изменения не приводят к снижению уровня безопасности активов, а сами активы учтены и понятна их критичность для бизнеса. На практике немного посложнее, но суть, примерно, следующая. На предприятии обычно есть карта БП с пониманием какими информационными системами (ИС) обеспечивается работа этих БП. Критичность БП проецируется на ИС, получаем критичность ИС. ИС состоит из нескольких активов (в некоторых случаях и вся ИС может считаться активом, но это нехороший вариант, так как большая декомпозиция позволяет реализовать более гибкий подход), и на них проецируется уже критичность ИС. И, наконец, активы и ИС вообще, для своей работы потребляют инфраструктурные сервисы, такие как корпоративная служба каталога, аутентификации и авторизации, системы виртуализации, средства управления конфигурацией, сетевая инфраструктура и телеком, электропитание, климатические системы и т.п. По опыту могу сказать, что инфраструктурные компоненты обычно имеют небольшую критичность для бизнеса, очевидно, если перестанет работать сеть, то никто не доберется до своих финансовых бизнес-приложений, если скомпрометируют централизованную систему аутентификации и авторизации, то возможен НСД в любое бизнес-приложение и т.п.

Перейдем к поставщику услуг. Во-первых, ввиду своей универсальности, поставщик, обычно, занимается именно инфраструктурной безопасностью, поскольку чтобы обнаруживать материальные для бизнеса инциденты в бизнес-системах надо погружаться в специфику работы этих ИС и хорошо разбираться в БП (понимать, как на уровне БП выглядит инцидент), возможность чего неумолимо снижается с увеличением клиентской базы, и никогда даже не приблизится к возможностям внутренней команды, поскольку требует глубокого вовлечения в корпоративные ИТ-процессы, как Управление изменениями, Управление конфигурациями и т.п.. Как я выше отметил, критичность инфраструктурного актива всегда будет высокой, поэтому, как правило, незнание конкретного значения критичности актива поставщику не помешает (скажу более, это и невозможно, поскольку, разные заказчики измеряют свою критичность в разных попугаях и мартышках), но сейчас даже и не об этом, а о том, что, во-вторых, сильная сторона поставщика услуги – лучшее знание угроз. И здесь уже внутренней команде тяжело тягаться с поставщиком, просто потому что внутренняя команда видит только себя, а поставщик видит многих. Исходя из угрозы логично внешнему ОЦИБ и классифицировать свои инциденты.

Теперь самое время собрать все вместе. Упрощенно, процесс таков: внешний ОЦИБ обнаруживает инциденты, классифицирует их по угрозе, передает во внутренний ОЦИБ, который добавляет контекст (исходя из критичности ИС, затронутых БП, текущих работах ИТ и бизнес-подразделений, процессов организации реагирования, вовлеченных команд и т.п.) и организует процесс реагирования, исходя уже из результирующей критичности, учитывающей уровень угрозы и важность конкретного актива в данный момент. Практическим опытом на примере технологической безопасности я делился здесь*.

На мой взгляд, наиболее объективная классификация – на основе потенциального ущерба от инцидента, т.е. классификация по ущербу. В этом случае, внешний ОЦИБ регистрирует инциденты исходя из потенциального ущерба от обнаруженной угрозы, а внутренний – корректирует полученные от внешнего ОЦИБ инциденты исходя из потенциального ущерба для корпоративного БП из-за развития (если инцидент не реагировать, он приведет к развитию атаки) обнаруженной угрозы на данном активе. Вот вариант*, как раз для внутреннего ОЦИБ, зависимости критичности и инцидента от типа атаки и потенциального ущерба от нее.

Примером работы классификации внешним ОЦИБ инцидента по угрозе может быть человекоуправляемая атака – критичность высокая, или работа ВПО без видимых следов человекоуправляемости – критичность средняя. Получив инцидент высокого приоритета о человекоупрвляемой атаке на активе “рабочая рядового хозяйственного отдела”, за счет низкой критичности актива, внутренний ОЦИБ может классифицировать этот инцидент как менее важный, в сравнении с тем же критичным инцидентов ввиду человекоуправляемой атаки, но уже на активе “рабочая станция администратора домена”, тем более, если актив – контроллер домена (замечу, что из телеметрии MDR*, как правило, есть возможность установить стандартную роль сервера, поэтому в случае контроллера домена критичность актива и результирующего инцидента будет понятна еще на стороне поставщика услуги).

Очень надеюсь, что данная статья была полезной.

Источник:
https://dzen.ru/a/ZaDeVgSfpAjfk7Vc

Автор:
Сергей Солдатов