среда, 26 декабря 2018 г.

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


4 комментария:

temasey комментирует...

Добрый день, подскажите пожалуйста что именно требуется отправить в фстэк?

Только форму 236 от 22 декабря 2017 года? для каждого объекта получается отдельно заводится такая форма?

Можете ли привести пример заполненной такой формы по объекту?

В посте про "КИИ. КАТЕГОРИРОВАНИЕ ОБЪЕКТОВ, ЧАСТЬ 3" у вас сначала были выделены одни объекты КИИ, в этом посте уже фигурирет и ЕГИСЗ и система скорой помощи и т.д. Это появилось в процессе категорирования или как?

Работаю в роддоме, могли бы вы скинуть какие-то наработки для примера на почту? tyo2439@yandex.ru

интересны именно форма 236 и акты категорирования

Сергей Борисов комментирует...

С Артемом лично обсудили указанные вопросы.
Про то что лишние объекты, кроме МИС нужно убрать. Как оценить степень автоматизации.
Региональный сегмент ЕГИСЗ категорирует его владелец Минзрав или по его поручению оператор МИАЦ.
С остальными разделами формы 236 надеюсь проблем не возникнет.

Анна комментирует...

Сергей, тоже интересуют вопросы по здраву.
У нас перинатальный центр.

1)Есть сегмент ЕМИАС. И не могу понять это будет нашим объектом КИИ или нам его не учитывать, т.к. оператором определен Минздрав?

2) Есть томографы, маммографы, рентген-аппараты. У них у всех принцип работы такой: есть сам аппарат, есть отдельная консоль для проведения процедуры исследования (выбираем зону исследования, осуществляем запуск исследования и т.д.), и есть АРМ врача-рентгенолога, на который передаются полученные снимки, установлено специальное ПО для просмотра снимков и подготовки описаний результатаов исследования для выдачи пациенту. Все эти устройства связаны линиями связи только между собой. Никакого подключения к ЛВС или Интернет не имеют.
Встал вопрос считать ли это АСУ или ИС и, собственно, объектом КИИ?

Сергей Борисов комментирует...

Анна:
1) По поводу сегмента - надо смотреть, есть ли у вас серверы в этом сегменте. Есть ли у вас задачи, которые вы решаете с использованием данного ПО, которые вас не обязывал делать Минздрав и про которые он может не знать? Если нет, то не учитывайте - я об этом писал в предыдущей статье про КИИ.

2) Да, считайте объектом КИИ типа ИС.