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


пятница, 7 декабря 2018 г.

(UPDATE) ИБ. Администратор безопасности VS Лицо, ответственное за безопасность


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

Но по моим наблюдениям, организации стараются назвать роль именно так как указано в НПА, например, “приказываю ... Иванова И.И. назначить лицом, ответственным за обеспечение безопасности объектов КИИ” или “… назначить администратором безопасности объектов КИИ” или “… назначить лицом, ответственным за обеспечение безопасности ПДн” или “… назначить администратором ИБ в системе XXX”.

Аргументы за “лицо, ответственное за безопасность”:
·         Постановление правительства РФ №1119 пункт 14
·         Приказ ФСТЭК России № 235, пункт 10, 11, 12, 13, 14
·         Приказ ФСТЭК России № 21, мера УКФ.3
·         Приказ ФСТЭК России № 17, пункт 9
·         Приказ ФСБ России № 378, пункт 17
·         ГОСТР 57580.1—2017, мера ЖЦ.17
·         Положение ЦБ РФ № 382-П, пункт 2.2, 2.3.1, 2.14.4,
Как правило вместе с лицом, ответственным за обеспечение безопасности упоминаются функции:
·         Разрабатывать предложения по совершенствованию
·         Проводить анализ угроз
·         Обеспечивать реализацию мероприятий, эксплуатацию СЗИ
·         Разработка и контроль выполнения планов мероприятий
·         Осуществлять реагирование на инциденты
·         Координацию деятельности других сотрудников по вопросам ИБ

Аргументы за “администратора безопасности”:
·         Приказ ФСТЭК России № 239, пункт 12.3 г), пункт 13.3
·         Приказ ФСТЭК России № 17, пункт 18.1
·         Методический документ ФСТЭК России “меры защиты информации в ГИС”, меры УПД.5, ОПС.1, РСБ.3, АВЗ.1, СОВ.1, АНЗ.1, ЗИС.1
Как правило вместе с администратором (или администрированием) безопасности упоминаются функции:
·         Администрирование подсистемы безопасности
·         Управление учетными записями
·         Управление СЗИ
·         Обновление ПО
·         Мониторинг событий ИБ

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

Понятно, что от смены названия, суть не меняется, но всё-таки интересно, если в вашей организации только один работник занимается ИБ, как называется его роль? Или у вас выделены все эти роли? Или может быть у вас за все ответственность подразделение ИБ? 



(UPDATE) По результатам ваших ответов делаю вывод что все 3 варианта основных ролей ИБ достаточно популярны. Тут вероятно каждый раз стоит спрашивать предпочтение Организации. 
Диаграмма ответов в Формах. Вопрос: Какие основные роли ИБ назначены в вашей Организации? . Количество ответов: 26 ответов.

А вот назначение ответственности, за безопасность конкретной системы, достаточно редко встречается по сравнению с ответственностью за все системы сразу. Наверное в большинстве случаев буду ориентироваться на такую общую ответственность. А персональную закладываем для каких то крупных систем в больших организациях.
Диаграмма ответов в Формах. Вопрос: Применяется ли в Организации определение ответственности за обеспечение безопасности отдельных систем? . Количество ответов: 26 ответов.