В предыдущих статьях я начал подробно разбирать этапы категорирования объектов КИИ, остановившись на формировании перечня объектов КИИ.
Многие читатели просили меня продолжить и дать рекомендации по следующим этапам. Изначально я придерживался позиции, что анализ нарушителей, угроз и последствий инцидентов необходимо осуществлять в рамках моделирования угроз и нарушителя. С одной стороны, с ПДн и ГИС эта тема достаточно хорошо проработана, есть много практики и в общем понятно, как это можно делать. С другой стороны (без использования средств автоматизации) моделирование угроз с учетом БДУ ФСТЭК – достаточно сложная и трудоемкая задача. Также тут много зависит от специфики конкретных систем и трудно дать какие-то общие рекомендации.
После общения с регуляторами, коллегами и анализа объектов КИИ для заказчиков постепенно пришел к выводу, что анализ, требуемый при категорировании КИИ, это не совсем тот анализ, который мы традиционной проводили в рамках моделирования угроз. Основная цель моделирования угроз, определить наиболее опасные (т.е. актуальные) для системы способы атак/воздействий, для того чтобы далее подобрать для них контрмеры. Основная же цель анализа угроз в рамках категорирования объектов КИИ – это оценить максимально возможный ущерб.
Требования, как необходимо проводить анализ угроз в рамках категорирования объектов КИИ – отсутствуют. Есть только требования к сведениям, которые необходимо предоставить в результате анализа. А значит мы можем выбрать свою произвольную методику, которая будет давать нам подходящий результат. Ниже представляю самый простой вариант высокоуровневой оценки ущерба КИИ. Простые методики могут быть грубоваты для крупных и сложны систем, но для типовых систем небольших организаций они отлично заходят – вот пример 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-ФЗ) и хотя бы одна любая система = у нас есть процессы в сферах КИИ + любая система = мы Субъект КИИ
· Из процессов Организации в сферах КИИ определяем Критические процессы
· Только для Критических процессов определяем системы, которые их обеспечивают и только они попадают в Перечень объектов КИИ
· Определяем категории только для объектов КИИ из Перечня
При этом, пожалуй, самым трудоемким является оценка Критичности процесса – по сути именно там мы определяем, какой возможен максимальный ущерб. А остальной анализ – это сколько из этого максимума оставить.
