СОИБ. Анализ. Порядок обеспечения безопасности ИСПДн, ГИС и АСУ
Хочу всех поздравить с тем, что наконец закончилась долгоиграющая разработка методического документа ФСТЭК России по защите ГИС. Он подписан и опубликован. Так-же недавно был выложен на рассмотрение проект требований по
защите АСУ, во многом схожий с по порядку выполнения работ и составу мер защиты
с приказами № 21 и №17.
На недавней конференции "Актуальные
вопросы защиты информации" представители ФСБ России так-же отметили что
существенных изменений в проект приказа по защите ПДн они вносить не будут и
опубликуют его в ближайшее время.
Это дает основания полагать что в
ближайшие год-два ничего существенного в порядках защиты ИСПДн, ГИС не
поменяется. Поэтому хватить совершенствовать законодательство и выжидать – пора
размораживать проекты и реализовывать систему защиты.
Методический документ по защите
ГИС, может так-же использоваться в процессе создания СЗПДн. Я считаю разумным применение
методического документа для большинства
ИСПДн в тех частях, где это не создает дополнительных затрат и не увеличивает
сроков создания СЗПДн.
С учетом методического документа и новых требований по защите АСУ обновил схемы порядков создания систем защиты (не включая эксплуатацию и вывод из действия) и состав основных документов, получаемых в
результате.
Для ГИС
Для АСУ
Для ИСПДн
Для обработки ПДн по поручению
Так-же рекомендую использовать
общий каталог мер защиты, пример которого выложил Андрей Прозоров
В ходе составления схем вылезла
ещё одна ошибка в документах.
Приказ №17
“Требования
к системе защиты информации информационной системы включаются в техническое
задание на создание информационной системы и (или) техническое задание (частное
техническое задание) на создание системы защиты информации информационной
системы, разрабатываемые с учетом ГОСТ 34.602, ГОСТ Р 51583 и ГОСТ Р 51624, и
должны в том числе содержать:
·
…
·
требования
к мерам и средствам защиты информации, применяемым в информационной системе;…”
Исполняя этот пункт мы должны
определить перечень мер и даже СЗИ до разработки ТЗ и включить их в ТЗ.
Но тот же Приказ №17 говорит нам:
“15.1. При
проектировании системы защиты информации информационной системы:
·
…
·
выбираются
меры защиты информации, подлежащие реализации в системе защиты информации
информационной системы;…”
Методический документ по защите:
·
“Выбор мер
защиты информации для их реализации в информационной системе осуществляется в
ходе проектирования системы защиты информации информационной системы в
соответствии с техническим заданием на создание информационной системы и (или)
техническим заданием (частным техническим заданием) на создание системы защиты
информации информационной системы.”
На этапе проектирования опять
выбираются меры? Но разве они не были выбраны на этапе разработки ТЗ?
Тут, я думаю, ФСТЭК Р попал в
ловушку своей терминологии. Скорее всего под “Выбор
мер …для их реализации ” имеется в виду что на этапе проектирования
мы выбираем “конкретные способы реализации мер”.
Комментарии
2. "для обработки по поручению" не совсем понятно, как Оператор сможет разработать модель угроз, не зная ни условий обработки, ни структуры ИС Уполномоченного лица. Исходя из каких данных он должен моделировать угрозы? Или он перед тем, как заключить договор, заявится к Уполномоченному лицу и проведет у него обследование?
3. "требования к мерам и средствам защиты информации, применяемым в информационной системе". Все-таки, требования к СЗИ и выбор конкретных СЗИ - это не одно и то же. Требованиями к СЗИ могут быть, например, требования к применению сертифицированных СЗИ, ограничения по стоимости, назначение и функционал СЗИ. А выбор конкретных версий СЗИ будет сделан с учетом этих требований в ходе проектирования.
1. На схеме у меня показан выбор, а в отчетных документах действительно надо поправить - поправлю.
2. По закону - обязанность оператора моделировать угрозы и устанавливать обработчику требования по защите ПДн. И я считаю, что если речь о типовых обработчиках, то о них оператор имеет достаточно информации для моделирования угроз.
Если какая-то уникальная ситуация и оператор не знает ничего кому и в какие условия он передает ПДн тогда в требованиях может включить и моделирование угроз.
Я рассмотрел минимальный типовой вариант.
3. А вот я считаю что переписывание требований к сертификации нельзя назвать требованиями к СЗИ.
про требования к функционалу - мы не можем их предьявить пока не осуществили выбор мер защиты в соответствии с методикой (дополненный уточненный адаптированный базовый набор)
Этот выбор мы должны делать либо на этапе ТЗ либо на этапе проектирования.
Два раза делать одну работу - бессмысленно.
3. В приказе 17 хватает и юридических, и логических ошибок. Думаю, что практика сложится так, что в ТЗ будут указывать общие требования по защите, а проектной документации - СЗИ, при помощи которых эти меры и будут реализованы.