Про требования по обеспечению безопасности КИИ

Про требования по обеспечению безопасности КИИ
В прошлой заметке я разбирал Приказ ФСТЭК России от 21 декабря 2017 года № 235 "Об утверждении Требований к созданию систем безопасности значимых объектов критической информационной инфраструктуры Российской Федерации и обеспечению их функционирования", а сейчас решил посмотреть следующий документ - Приказ ФСТЭК России от 25 декабря 2017 года № 239 "Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации".
Документ, в целом, выдержан в духе других приказов (17,21,31), поэтому стандартные положения комментировать не буду, но в нем есть моменты, на которые стоит обратить внимание.

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

2. Требования предъявляются на всех этапах жизненного цикла в ходе создания (модернизации), эксплуатации и вывода из эксплуатации значимых объектов КИИ. Зачем в такой ситуации нужен еще и Приказ №235 (про создание систем безопасности) мне не понятно...

3. В Приказе очень много положений про документирование результатов мероприятий по ИБ, это и:
  • Разработка ТЗ на создание подсистемы безопасности
  • Анализ угроз и разработка их модели
  • Проектирование подсистемы безопасности
  • Описание архитектуры подсистемы безопасности
  • Документирование порядка и параметров настройки программных и программно-аппаратных средств (втч и СЗИ)
  • Подготовка документов для предварительных, эксплуатационных и приемочных испытаний
  • Составление эксплуатационной документации
  • Разработка организационно-распорядительных документов, регламентирующих правила и процедуры обеспечения безопасности
  • Создание политик (по различным группам мер из приложения)
  • Документирование процедур и результатов контроля за обеспечением безопасности значимого объекта
И с учетом не самой простой процедуры по категорированию объектов КИИ это создает огромный рынок для консультантов и "бумажных" безопасников. 

4. При разработке модели угроз и, в дальнейшем, при проведении анализа уязвимостей необходимо использовать БДУ ФСТЭК России . Именно использовать, а не просто ориентироваться в качестве одного из "источников вдохновения". Обратите внимание, что "по результатам анализа уязвимостей должно быть подтверждено, что в значимом объекте, отсутствуют уязвимости, как минимум содержащиеся в банке данных угроз безопасности информации ФСТЭК России".

5. В документе сказано, что при проектировании подсистемы безопасности необходимо определить субъекты и объекты доступа, а также политики управления доступом (дискреционная, мандатная, ролевая, комбинированная). Если к этому этапу работ отнестись добросовестно, то результаты могут в дальнейшем пригодится для выстраивания и автоматизации (например, с использованием IdM) правильных процессов управления доступом.

6. Обратил внимание, что "в случае если в ходе проектирования подсистемы безопасности значимого объекта предусмотрена разработка ПО, ... то такая разработка проводится в соответствии со стандартами безопасной разработки ПО". Об этом ФСТЭК России говорит уже несколько лет, и эта практика скоро будет всеобщей.

7. Помимо усиления "бумажной" безопасности, в документе есть и про практическую ИБ. Например, при анализе уязвимостей следует применять еще и "д) тестирование на проникновение". Но, что забавно, это не просто "пентест", а "пентест в условиях, соответствующих возможностям нарушителей, определенных в модели угроз безопасности". Так что, если у вас в модели учтены возможности иностранных разведок и крупных криминальных групп, то вам и пентестеров придется нанимать, оснащенных современным кибероружием и обладающими другими, практически безграничными, ресурсами :)))

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

9. В документе часто упоминается необходимость реагирования на компьютерные инциденты, но требования к этому процессы минимальные (п.13.5 и меры ИНЦ). Ну, да, если мы говорим про инциденты ИБ, то стоит читать другие документы (ФСБ России про ГосСОПКА).

10. Обратите внимание, что для безопасности КИИ необходимо внедрить меры и запустить процедуры непрерывности бизнеса. Это и меры из п.13.6 и меры ОДТ и ДНС. По моему опыту, если честно и хорошо строить процессы управления непрерывностью и восстановления, то затраты на это могут даже превысить все совокупные затраты на ИБ... Это дорого.

11. В п.20 в явном виде упоминается, что для обеспечения безопасности "при необходимости" могут привлекаться организации, обладающие необходимыми лицензиями по ТЗКИ (и, если надо, по ГТ).

12. Использование СЗИ, прошедших оценку соответствия в форме обязательной сертификации, применяются в случае принятия решения субъектом КИИ. И что-то мне подсказывает, что многие организации (если это не госы) выберут оценку соответствия в виде испытаний и приемки, такая возможность существует. Сохраню сюда эти положения:

13. Из новых положений стоит отметить требования к гарантийной и технической поддержке:

14. А еще очень много интересных правок внесено в уже "классический" для нас состав мер из Приложения (таблица мер). Я не делал полное сравнение мер, но обратил внимание вот на эти изменения (а всего их больше):
  • Общая нумерация и описание мер изменились, теперь они не соответствуют приказам 17/21/31. Похоже, что эти приказы в скором времени будут править.
  • Появилась новая группа мер - АУД "Аудит безопасности", вобравшая в себя меры из групп РСБ и АНЗ. В ней же появились и новые меры:
    • АУД.5 Контроль и анализ сетевого трафика (для 1 категории значимости)
    • АУД.9 Анализ действия пользователей  (для 1 категории значимости)
    • АУД.10 Проведение внутренних аудитов (для всех)
    • АУД.11 Проведение внешних аудитов  (для 1 категории значимости)
  • В группе "АВЗ. Антивирусная защита" появились новые меры:
    • АВЗ.2 Антивирусная защита электронной почты и иных сервисов (для всех)
    • АВЗ.3 Контроль использования архивных, исполняемых и зашифрованных файлов (для 1 категории значимости)
    • АВЗ.5 Использование средств АВЗ различных производителей  (для 1 категории значимости)
  • Группа СОВ переименована из "обнаружения" в "предотвращение" вторжений.
  • Появилась мера ЗИС.7 "Использование эмулятора среды функционирования ПО ("песочница")" (без требований).
  • Появились меры ЗИС.24 "Контроль передачи речевой информации" и ЗИС.25 "Контроль передачи видеоинформации" (для 1 и 2 категории значимости). Что подразумевается?
  • Новая мера ЗИС.31 "Защита от скрытых каналов передачи информации" (для 1 категории значимости). Что это? 
  • Новая мера ЗИС.34 "Защита от угроз отказа в обслуживании (DOS, DDoS-атаки)" (для всех).
  • Убрали группу ОБР "Обеспечение безопасной разработки ПО". 
  • Любителям DLP стоит обратить внимание:
    • Появилась новая мера ЗИС.17 "Защита информации от утечки" (без требований), ее не стоит путать с мерой ЗТС.1 "Защита информации от утечки по техническим каналам".
    • Классическая DLPшная мера ОЦЛ.5 "Контроль содержания информации, передаваемой из автоматизированной системы управления (контейнерный, основанный на свойствах объекта доступа, и контентный, основанный на поиске запрещенной к передаче информации с использованием сигнатур, масок и иных методов), и исключение неправомерной передачи информации" (без требований) теперь стала конкретнее и звучит ОЦЛ.5 "Контроль ошибочных действий пользователей по вооду и (или) передаче информации и предупреждение пользователей об ошибочных действиях" (для 1 и 2 категории значимости).
    • Еще стоит помнить про меры ЗНИ "Защита машинных носителей информации".
ФСТЭК России уже готовит Методические рекомендации по применению мер, без них сейчас трудно адекватно оценить измененный состав мер. Как будет доступен проект, тогда и можно будет говорить конкретнее про их выбор и внедрение. Опять ждем...


Alt text

Цифровые следы - ваша слабость, и хакеры это знают.

Подпишитесь и узнайте, как их замести!

Andrey Prozorov

Информационная безопасность в России и мире