Уф, конец года, как всегда, очень оживленный, и только нашел время посмотреть проект методического документа ФСТЭК России версии 1.3 “ Меры защиты информации в государственных информационных системах ”. Однако сейчас я изучал только первую часть документа и его общую логику (п.1-2 + Приложение). Ну, а п.3 "Содержание мер защиты информации в информационной системе" мы уже неоднократно обсуждали на совещаниях рабочей группы во ФСТЭК России, которые проходили еженедельно с сентября по ноябрь 2013. Я уже готовил замечания и рекомендации по многим из мер, часть замечаний уже принято, часть отклонено, некоторые еще не рассмотрены.
Итак, на что я обратил внимание:
1.Документ слишком сложный и неудобный для использования целевой аудиторией.
В п.1 "Общие положения" сказано, что:
Методический документ предназначен для обладателей информации, заказчиков, заключивших государственный контракт на создание информационной системы (заказчики), операторов информационных систем (операторы), лиц, обрабатывающих информацию, являющуюся государственным информационным ресурсом, по поручению обладателя информации (заказчика) или оператора и (или) предоставляющее им вычислительные ресурсы (мощности) для обработки информации на основании заключенного договора (уполномоченные лица), а также лиц, привлекаемых в соответствии с законодательством РФ для проведения работ по созданию (проектированию) информационных систем в защищенном исполнении и (или) их систем защиты информации (проектировщики).
По факту, использование документа будет довольно проблематично даже для самого "продвинутого" читателя - проектировщиков (интеграторов). Ведь в документе нет четкой связки между угрозами, элементами ИТ и мерами защиты, нет расставленных приоритетов по внедрению, сложно понять, какие меры можно реализовать используя уже существующие средства защиты и возможности по настройке средств обработки, нет четких рекомендаций по организационным мерам и наличию документов, регламентирующих управление и обеспечение ИБ. Много чего нет, но об чуть ниже...
2.В п.2 "Выбор мер защиты информации для их реализации в информационной системе в рамках системы защиты информации" содержится очень мало новой и полезной информации.В основном, мы видим дословное повторение текста из Приказа 17 про классификацию систем, оценку угроз и выбор мер. Дополнительной, и главное полезной, информации по данным темам, а также рекомендаций практически не дается.
3.В документе представлены рекомендации не по всем мерам защиты информации, которые упомянуты в Приказе 17 (ну, и Приказе 21).
Если мы посмотрим внимательно на Приказ 17, то увидим, что очень много мер защиты информации, упомянуты в тексте Приказа 17, но отсутствуют в перечне "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности ИС" (Приказ 17 Приложение 2). Также Приказ 21 в таблице мер содержит 2 группы. которых нет в таблице Приказа 17, но есть описание по тексту Приказа 17. Вот они:
- XIV. Выявление инцидентов и реагирование на них (ИНЦ)
- XV. Управление конфигурацией ИС и СЗПДн (УКФ)
Кстати, как отличаются таблицы по набору мер в Приказах 17 и 21 можно посмотреть тут .
Ну, а общий набор мер защиты в Приказе 17 надо искать вот здесь:
- п.9 - 1 мера: "назначение ответственного за защиту информации"
- п.16.2 - требования к содержанию ОРД
- п.16.3 - организационные меры защиты
- п.16.6 - анализ уязвимостей
- п.18 - набор требований по защите информации в ходе эксплуатации ИС
- п.19 - набор требований по защите информации при выводе ИС из эксплуатации
- п.20 и Приложение 2
Итого, в текстовой части Приказа 17 мы можем увидеть следующие меры (объединил их для удобства в группы):
- Назначение ответственного за защиту инфомрации- п.9
- Управление (администрирование) системой защиты - п.16.2(1), 18.1(2, 4), 18.1(7)
- Управление документацией - 16.3(2), 18.1(7), 18.4(5)
- Тренинги и повышение осведомленности - п.16.3(3), 18.1(6)
- Аудит ИБ (контроль (мониторинг) за обеспечением уровня защищенности) - п.16.2, 16.3(2), 18.4(3)
- Анализ и совершенствование системы защиты - 18.4(3,4,6)
- Регистрация и анализ событий, управление инцидентами - п.16.2(2), 18.1(5), 18.2, 18.4(1) (+см.меры группы ЗНИ)
- Управление конфигурацией ИС - п.16.2. 16.3(1), 18.3
- Управление уязвимостями (включая обновление ПО) - п.16.6, 18.1(3), 18.4(2), (+см.меры группы АНЗ)
- Управление доступом - п.16.3(1), 18.1(1) (+см.меры группы УПД и ИАФ)
- Архивирование информации при выводе ИС из эксплуатации - п.16.2. п.19.1
- Гарантированное уничтожение информации - п.16.2, п.19.2 (+см.меры группы ЗНИ)
Как мы можем заметить, не все они нашли свое отражение в новом методическом документе...
4.В документе отсутствует описание того, как пользоваться п.3 "Содержание мер защиты информации в ИС". Ну, а конкретно, как используются "Требования к реализации" и "Требования к усилению", как выбираются меры из них, что отражает таблица "Содержание базовой меры" и, самое важное, какие меры являются ОБЯЗАТЕЛЬНЫМИ к исполнению (особенно из требований к усилению)?
Хотя про это немного написано на самой последней странице документа...
Хотя про это немного написано на самой последней странице документа...
5.В документе отсутствуют рекомендации по выбору целей и задач защиты информации, а также связь этих целей с мерами защиты.
Так в новом методическом документе написано:
п.2.3 б) При адаптации базового набора мер защиты информации учитываются цели и задачи защиты информациив информационной системе.
Аналогично про них есть упоминание и в Приказе 17:
п.14.1. При принятии решения о необходимости защиты информации, содержащейся в информационной системе, осуществляется ... определение целей и задач защиты информациив информационной системе...
п.14.4. Требования к системе защиты информации информационной системы ... должны в том числе содержать цель и задачи обеспечения защиты информациив информационной системе...
При этом ни в новом документе, ни в Приказе 17 никакой дополнительной информации по этому нет.
6.В документе отсутствует конкретика по связи угроз и мер защиты. Часть мер защиты прописаны очень детально, но базовая модель угроз не определена. А наличие типовой формулы описания для угроз (УБИ = [возможности нарушителя; уязвимости информационной системы; способ реализации угрозы; последствия от реализации угрозы]) для выбора мер защиты ничего не дает.
А вообще, хотелось бы уже наконец получить рекомендации по составлению модели угроз от регулятора, и все же увидеть связь мер защиты и угроз.
А вообще, хотелось бы уже наконец получить рекомендации по составлению модели угроз от регулятора, и все же увидеть связь мер защиты и угроз.
7.В документе хотелось бы увидеть перечень терминов и определений.
8.В документе хотелось бы увидеть конкретные рекомендации и пояснения по тем мерам, которые могут быть выполнены простой настройкой средств обработки информации и базовых средств защиты информации, организационными мерами.
9.В документе хотелось бы увидеть рекомендуемый перечень организационно-распорядительных документов и записей, которые должны быть в организации для управления и обеспечения ИБ.
10.В документе хотелось бы увидеть приоритеты по реализации мер. С каких начать, какими можно пренебречь при отсутствии необходимого финансирования и наличия специалистов. Понимание того, какие меры должны быть реализованы даже средними и малыми компаниями (да, подключения к ГосИС у них может и не быть, но аналогичные меры по ПДн для них актуальны).
11.Хорошей практикой при составлении такого рода документов является четкое обозначение назначения и целей документа, краткое описание его частей и приложений.
12.Хорошей практикой при составлении такого рода документов является документирование базовых принципов, на которые должны ориентироваться организации при выборе мер и обеспечении ИБ.
13. Хорошей практикой при составлении такого рода документов является указание организаций и экспертов, принявших участие в разработке.
14.Хорошей практикой при составлении такого рода документов является указание дополнительных стандартов и "лучших практик", на которые можно ориентироваться при реализации мер. Я понимаю, что скорее всего не будут ссылаться на международные стандарты (а зря), например на тот же NIST 800-53 . При этом ГОСТ 27001 (аналог ISO 27001-2005) упоминается в Приказе 17. Почему бы не сделать ссылки на его меры?
15.Хорошей практикой при составлении такого рода документов является использование удобных структуры и оформления документа. Хорошо бы в колонтитулах видеть не только номер страницы, а еще наименование документа и соответствующего пункта/приложения.
Ну, это общие мысли по документу. Конкретные предложения я готовлю и отправляю во ФСТЭК России, готов их обсуждать на очередном совещании.
- Алексей Лукацкий: http://lukatsky.blogspot.ru/2013/12/blog-post.html
- Булат Шамсутдинов: http://crypto-anarchist.blogspot.ru/2013/11/blog-post.html
- Сергей Борисов: http://sborisov.blogspot.ru/2013/12/2.html и http://sborisov.blogspot.ru/2013/12/blog-post.html
- Атаманов Геннадий - http://bis-expert.ru/blog/4042/43529
P.S. Еще можно посмотреть:
- Новый подход ФСТЭК vs NIST 800-53
- Приказ 17: На что обратить внимание? ( Часть 1 и Часть 2 )
- Защита ПДн по новому стилю: Минюст утвердил приказ ФСТЭК №21 (SOISO)
- Презентация по SOISO (Приказ ФСТЭК №21) и ПП1119
- SoA и ПДн (требования ФСТЭК)
- 1 шаг вперед, 3 шага назад. Вышло ПП1119 про требования к защите ПДн