КИИ. Категорирование объектов, часть 4. Высокоуровневая оценка ущерба КИИ

В предыдущих статьях я начал подробно разбирать этапы категорирования объектов КИИ, остановившись на формировании перечня объектов КИИ.

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

После общения с регуляторами, коллегами и анализа объектов КИИ для заказчиков постепенно пришел к выводу, что анализ, требуемый при категорировании КИИ, это не совсем тот анализ, который мы традиционной проводили в рамках моделирования угроз.  Основная цель моделирования угроз, определить наиболее опасные (т.е. актуальные) для системы способы атак/воздействий, для того чтобы далее подобрать для них контрмеры.  Основная же цель анализа угроз в рамках категорирования объектов КИИ – это оценить максимально возможный ущерб.

Требования, как необходимо проводить анализ угроз в рамках категорирования объектов КИИ – отсутствуют. Есть только требования к сведениям, которые необходимо предоставить в результате анализа.  А значит мы можем выбрать свою произвольную методику, которая будет давать нам подходящий результат. Ниже представляю самый простой вариант высокоуровневой оценки ущерба КИИ. Простые методики могут быть грубоваты для крупных и сложны систем, но для типовых систем небольших организаций они отлично заходят – вот пример c ENISA для SMB. При высокоуровневой оценке никакие контрмеры не учитываются (такое указание ФСТЭК).

1)      Рассмотреть возможности нарушителей, определить их категории и краткую характеристику …

Перечень возможных нарушителей, их мотивацию и возможности берем из проекта методического документа “Методика определения угроз безопасности информации в ИС” от 2015 г. Там они отлично описаны.

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

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

2)      Определяем Нарушителей путем исключения:

·         Спецслужбы исключаем, если только вы не федеральный орган власти или федеральная компания монополист в своей отрасли

·         Всех внешних нарушителей исключаем, если у объекта нет подключения к сетям связи (пункт 3 уведомления)

·         Также исключаем нарушителей, которые в принципе для вас не применимы. (Например, конкурирующие организации, если вы гос.   или подрядчики, если вы их никогда не используете)

·         Всех остальных оставляем, так как ещё не зная возможного ущерба для ИС (но зная что у нас есть критические процессы), а также не имея права учитывать контрмеры мы не можем исключить каких то ещё нарушителей.

3)      Определяем основные угрозы

·         Берем список (из того же проекта методики):

o   несанкционированного доступа и (или) воздействия на объекты на аппаратном уровне (программы (микропрограммы), «прошитые» в аппаратных компонентах (чипсетах))

o   несанкционированного доступа и (или) воздействия на объекты на общесистемном уровне (базовые системы ввода-вывода, гипервизоры, операционные системы)

o   несанкционированного доступа и (или) воздействия на объекты на прикладном уровне (системы управления базами данных, браузеры, web приложения, иные прикладные программы общего и специального назначения)

o   несанкционированного доступа и (или) воздействия на объекты на сетевом уровне (сетевое оборудование, сетевые приложения, сервисы)

o   несанкционированного физического доступа и (или) воздействия на линии, (каналы) связи, технические средства, машинные носители информации

o   воздействия на пользователей, администраторов безопасности, администраторов информационной системы или обслуживающий персонал (социальная инженерия)

·         Убираем угрозы, связанные с компонентами, которых нет в составе вашего объекта КИИ (разве что, сетевое оборудование, остальное исключить не можем)

4)      Определяем типы инцидентов

·         Берем список (из п. 7.1 приказа ФСТЭК №236)

o   отказ в обслуживании

o   несанкционированный доступ

o   утечка данных (нарушение конфиденциальности)

o   модификация (подмена) данных

o   нарушение функционирования технических средств

o   несанкционированное использование вычислительных ресурсов объекта

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

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

5)      Оцениваем степень ущерба или степень автоматизации процесса (промежуточный коэфициент)

·         Теперь самый ответственный момент категорирования. Все вычисления, проведенные на этапе 1-4 носят исключительно справочный характер (зачем то их прописали в ПП 127)

·         Нам необходимо оценить насколько Критический процесс зависит от объекта КИИ:

o   высокая, если в результате инцидентов, возможно полное нарушение или прекращение процессов, обеспечиваемых данным объектом КИИ

o   средняя, если в результате инцидентов, возможно частичное нарушение или прекращение процессов, обеспечиваемых данным объектом КИИ

o   низкая, если в результате инцидентов, не происходит нарушение или прекращение процессов, обеспечиваемых данным объектом КИИ

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

·         Пример 1: все оказанные мед. услуги, полученные диагнозы, назначенные лечения, фиксируются в электронном виде. При оказании услуг врач в первую очередь смотрит данные в системе, и только если они отсутствуют, тогда только начинают запрашивать бумажные карточки, предыдущие справки и диагнозы на бумажных носителях. В таком случае степень ущерба ставим высокую.   

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

6)      Оцениваем ущерб (возможные последствия)

·         Наконец оцениваем ущерб от компьютерных инцидентов, по показателям значимости из ПП 127.

·         Для этого берем оценку возможного ущерба от нарушения Критического процесса и применяем к нему коэфициент Степень автоматизации  

o   Если степень автоматизации высокая, то ущерб от компьютерного инцидента на объекте КИИ аналогичен ущербу от нарушения Критического процесса, который обеспечивает данный объект КИИ  

o   Если средняя, то ущерб от компьютерного инцидента на одну категорию ниже негативных последствий, которые могут произойти при нарушении и (или) прекращении процессов

o   Если низкая, то ущерб от компьютерного инцидента соответствует негативным последствиям, не попадающим в категорию значимости

7)      Определяем категорию объекта КИИ как максимум из категорий по отдельным показателям ущерба
Собственно, на этом все – записываем результаты и отправляем уведомление во ФСТЭК.

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

Если у вас ещё остаются вопросы по категорированию, обращайтесь – вместе решим.

PS: Возможность категорирования объектов КИИ мы добавили в последнем обновлении системы DocShell, в месте с другими возможностями автоматизации задач в сфере безопасности КИИ.

PPS: На всякий случай напомню общий порядок категорирования объектов КИИ (он немного менялся по результатам общения с регуляторами):

·         Определяем, что Организация действует в сфере КИИ (187-ФЗ) и хотя бы одна любая система = у нас есть процессы в сферах КИИ + любая система = мы Субъект КИИ

·         Из процессов Организации в сферах КИИ определяем Критические процессы

·         Только для Критических процессов определяем системы, которые их обеспечивают и только они попадают в Перечень объектов КИИ

·         Определяем категории только для объектов КИИ из Перечня  

При этом, пожалуй, самым трудоемким является оценка Критичности процесса – по сути именно там мы определяем, какой возможен максимальный ущерб. А остальной анализ – это сколько из этого максимума оставить.