В прошлой заметке я разбирал Приказ ФСТЭК России от 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. А еще очень много интересных правок внесено в уже "классический" для нас состав мер из Приложения (таблица мер). Я не делал полное сравнение мер, но обратил внимание вот на эти изменения (а всего их больше):
1. Это требования для значимых объектов КИИ, если ваши объекты КИИ не отнесены к таким, то они могут и не применяться...
2. Требования предъявляются на всех этапах жизненного цикла в ходе создания (модернизации), эксплуатации и вывода из эксплуатации значимых объектов КИИ. Зачем в такой ситуации нужен еще и Приказ №235 (про создание систем безопасности) мне не понятно...
3. В Приказе очень много положений про документирование результатов мероприятий по ИБ, это и:
- Разработка ТЗ на создание подсистемы безопасности
- Анализ угроз и разработка их модели
- Проектирование подсистемы безопасности
- Описание архитектуры подсистемы безопасности
- Документирование порядка и параметров настройки программных и программно-аппаратных средств (втч и СЗИ)
- Подготовка документов для предварительных, эксплуатационных и приемочных испытаний
- Составление эксплуатационной документации
- Разработка организационно-распорядительных документов, регламентирующих правила и процедуры обеспечения безопасности
- Создание политик (по различным группам мер из приложения)
- Документирование процедур и результатов контроля за обеспечением безопасности значимого объекта
И с учетом не самой простой процедуры по категорированию объектов КИИ это создает огромный рынок для консультантов и "бумажных" безопасников.
4. При разработке модели угроз и, в дальнейшем, при проведении анализа уязвимостей необходимо использовать БДУ ФСТЭК России . Именно использовать, а не просто ориентироваться в качестве одного из "источников вдохновения". Обратите внимание, что "по результатам анализа уязвимостей должно быть подтверждено, что в значимом объекте, отсутствуют уязвимости, как минимум содержащиеся в банке данных угроз безопасности информации ФСТЭК России".
5. В документе сказано, что при проектировании подсистемы безопасности необходимо определить субъекты и объекты доступа, а также политики управления доступом (дискреционная, мандатная, ролевая, комбинированная). Если к этому этапу работ отнестись добросовестно, то результаты могут в дальнейшем пригодится для выстраивания и автоматизации (например, с использованием IdM) правильных процессов управления доступом.
6. Обратил внимание, что "в случае если в ходе проектирования подсистемы безопасности значимого объекта предусмотрена разработка ПО, ... то такая разработка проводится в соответствии со стандартами безопасной разработки ПО". Об этом ФСТЭК России говорит уже несколько лет, и эта практика скоро будет всеобщей.
7. Помимо усиления "бумажной" безопасности, в документе есть и про практическую ИБ. Например, при анализе уязвимостей следует применять еще и "д) тестирование на проникновение". Но, что забавно, это не просто "пентест", а "пентест в условиях, соответствующих возможностям нарушителей, определенных в модели угроз безопасности". Так что, если у вас в модели учтены возможности иностранных разведок и крупных криминальных групп, то вам и пентестеров придется нанимать, оснащенных современным кибероружием и обладающими другими, практически безграничными, ресурсами :)))
8. Обязательная аттестация прописана лишь для государственных ИС, являющихся значимыми объектами КИИ.
9. В документе часто упоминается необходимость реагирования на компьютерные инциденты, но требования к этому процессы минимальные (п.13.5 и меры ИНЦ). Ну, да, если мы говорим про инциденты ИБ, то стоит читать другие документы (ФСБ России про ГосСОПКА).
10. Обратите внимание, что для безопасности КИИ необходимо внедрить меры и запустить процедуры непрерывности бизнеса. Это и меры из п.13.6 и меры ОДТ и ДНС. По моему опыту, если честно и хорошо строить процессы управления непрерывностью и восстановления, то затраты на это могут даже превысить все совокупные затраты на ИБ... Это дорого.
11. В п.20 в явном виде упоминается, что для обеспечения безопасности "при необходимости" могут привлекаться организации, обладающие необходимыми лицензиями по ТЗКИ (и, если надо, по ГТ).
12. Использование СЗИ, прошедших оценку соответствия в форме обязательной сертификации, применяются в случае принятия решения субъектом КИИ. И что-то мне подсказывает, что многие организации (если это не госы) выберут оценку соответствия в виде испытаний и приемки, такая возможность существует. Сохраню сюда эти положения:
13. Из новых положений стоит отметить требования к гарантийной и технической поддержке:
- Общая нумерация и описание мер изменились, теперь они не соответствуют приказам 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 категории значимости).
- Еще стоит помнить про меры ЗНИ "Защита машинных носителей информации".
