Главная » Блоги Экспертов И ИТ-Компаний » КИИ. Категорирование объектов, часть 4. Высокоуровневая оценка ущерба КИИ

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

В предыдущих статьях я начал подробно разбирать этапы категорирования объектов КИИ, остановившись на формировании перечня объектов КИИ.
%25D0%259A%25D0%2598%25D0%2598.jpg
Многие читатели просили меня продолжить и дать рекомендации по следующим этапам.  Изначально я придерживался позиции, что анализ нарушителей, угроз и последствий инцидентов необходимо осуществлять в рамках моделирования угроз и нарушителя. С одной стороны, с ПДн и ГИС эта тема достаточно хорошо проработана, есть много практики и в общем понятно, как это можно делать. С другой стороны (без использования средств автоматизации) моделирование угроз с учетом БДУ ФСТЭК – достаточно сложная и трудоемкая задача. Также тут много зависит от специфики конкретных систем и трудно дать какие-то общие рекомендации.
После общения с регуляторами, коллегами и анализа объектов КИИ для заказчиков постепенно пришел к выводу, что анализ, требуемый при категорировании КИИ, это не совсем тот анализ, который мы традиционной проводили в рамках моделирования угроз.  Основная цель моделирования угроз, определить наиболее опасные (т.е. актуальные) для системы способы атак/воздействий, для того чтобы далее подобрать для них контрмеры.  Основная же цель анализа угроз в рамках категорирования объектов КИИ – это оценить максимально возможный ущерб.
Требования, как необходимо проводить анализ угроз в рамках категорирования объектов КИИ – отсутствуют. Есть только требования к сведениям, которые необходимо предоставить в результате анализа.  А значит мы можем выбрать свою произвольную методику, которая будет давать нам подходящий результат. Ниже представляю самый простой вариант высокоуровневой оценки ущерба КИИ. Простые методики могут быть грубоваты для крупных и сложны систем, но для типовых систем небольших организаций они отлично заходят – вот пример cENISAдля SMB. При высокоуровневой оценке никакие контрмеры не учитываются (такое указание ФСТЭК).
1)      Рассмотреть возможности нарушителей, определить их категории и краткуюхарактеристику …
Перечень возможных нарушителей, их мотивацию и возможности берем из проекта методического документа “Методика определения угроз безопасности информации в ИС” от 2015 г. Там они отлично описаны.
%25D0%25BD%25D0%25B0%25D1%2580%25D1%2583%25D1%2588%25D0%25B8%25D1%2582%25D0%25B5%25D0%25BB%25D1%258C.png
Если вам лень выписывать самим, то на картинке ниже, я сделал подборку по мотивации и возможностям
%25D0%25B2%25D0%25BE%25D0%25B7%25D0%25BC%25D0%25BE%25D0%25B6%25D0%25BD%25D0%25BE%25D1%2581%25D1%2582%25D0%25B8%2B%25D0%25B8%2B%25D0%25BC%25D0%25BE%25D1%2582%25D0%25B8%25D0%25B2%25D0%25B0%25D1%2586%25D0%25B8%25D1%258F.png
Кстати, по-хорошему, нарушителей стоило бы определять уже после оценки возможного ущерба, но в ПП 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   Если низкая, то ущерб от компьютерного инцидента соответствует негативным последствиям, не попадающим в категорию значимости
%25D1%2581%25D1%2582%25D0%25B5%25D0%25BF%25D0%25B5%25D0%25BD%25D1%258C%2B%25D1%2583%25D1%2589%25D0%25B5%25D1%2580%25D0%25B1%25D0%25B0.jpeg
7)      Определяем категорию объекта КИИ как максимум из категорий по отдельным показателям ущербаСобственно, на этом все – записываем результаты и отправляем уведомление во ФСТЭК.Наверное, статья была бы не полной без примеров. Вот несколько для здравоохранения.
%25D0%25BA%25D0%25B0%25D1%2582%25D0%25B5%25D0%25B3%25D0%25BE%25D1%2580%25D0%25B8%25D1%258F.png
Если у вас ещё остаются вопросы по категорированию, обращайтесь – вместе решим.
PS: Возможность категорирования объектов КИИ мы добавили в последнем обновлении системы DocShell, в месте с другими возможностями автоматизации задач в сфере безопасности КИИ.
PPS: На всякий случай напомню общий порядок категорирования объектов КИИ (он немного менялся по результатам общения с регуляторами):
·         Определяем, что Организация действует в сфере КИИ (187-ФЗ) и хотя бы одна любая система = у нас есть процессы в сферах КИИ + любая система = мы Субъект КИИ
·         Из процессов Организации в сферах КИИ определяем Критические процессы
·         Только для Критических процессов определяем системы, которые их обеспечивают и только они попадают в Перечень объектов КИИ
·         Определяем категории только для объектов КИИ из Перечня  
При этом, пожалуй, самым трудоемким является оценка Критичности процесса – по сути именно там мы определяем, какой возможен максимальный ущерб. А остальной анализ – это сколько из этого максимума оставить.


Источник: http://sborisov.blogspot.com/2018/12/4.html


Данный материал является частной записью члена сообщества Club.CNews.
Редакция CNews не несет ответственности за его содержание.
Комментарии
Другие публикации
RU, Краснодар
https://docshell.ru/, https://docshell.ru/
Информационные технологии



Забыл пароль?
Авторизоваться через
Зарегистрируйся сейчас!
Присоединяйся к нашему обществу для того чтобы познакомиться с новыми людьми, создать собственный блог, публиковать анонсы событий и объявления, а также участвовать в обсуждении публикаций CNews. Мы создали единое пространство для общения специалистов рынка информационных технологий и всех, кто интересуется современными технологиями. Регистрация =>