В ИБ-среде уже, наверное, всем известно, что опубликован проект приказа о внесении изменений в Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах, утвержденные приказом Федеральной службы по техническому и экспортному контролю от 11 февраля 2013 г. № 17. Свои мысли по этому поводу уже высказали Булат Шамсутдинов и Алексей Лукацкий. У меня есть и свои мысли по проекту и я их решил тоже описать здесь и отправить авторам проекта, когда на портале обсуждений починят сертификат…
Об обязательности использования банка данных угроз в моделировании угроз
Это все хорошо, но когда же уже выйдет новая методика определения актуальных угроз безопасности? Проект которой, кстати, появился еще весной 2015-го, а скоро уже весна 2017-го… Дело в том, что БДУ заточена под новую методику, а новая методика заточена под БДУ. Пользоваться мы можем только официально утвержденными документами 2008 года — «Базовая модель…» и «Методика определения актуальных угроз…» и если их применять с угрозами из БДУ, то получается полная ерунда — угрозы, которые интуитивно должны быть актуальными получаются неактуальными, проходили, знаем. Поэтому вся эта суета мне кажется непоследовательной. По-моему сначала надо выпустить методику, потом уже заставлять пользоваться БДУ.
Кстати, я не согласен с мнением о том, что обязательство использовать угрозы из БДУ избавит от копипасты в моделях угроз. Те, кто занимался копипастой будут просто делать это не с «Базовой моделью», а с БДУ, вот и все.
Об отсутствии уязвимостей
В документе есть такие слова:
8) пункт 16.6 дополнить абзацем следующего содержания:
«По результатам анализа уязвимостей должно быть подтверждено, что в информационной системе отсутствуют уязвимости, содержащиеся в банке данных угроз безопасности информации ФСТЭК России, а также в иных источниках»;
По-моему явный намек на запрет использования сканеров уязвимостей, не содержащих данные об уязвимостях из БДУ. Хорошо это или плохо, каждый решает для себя сам. Я не имею отношения к производителям таких сканеров, поэтому лично мне — все равно. Но возможно организациям, у которых на горизонте маячит закупка подобного продукта или обновление существующего, стоит обратить внимание на наличие в базе данных сканера уязвимостей из БДУ ФСТЭК.
О раздельном проектировании и аттестации информационных систем
В проекте дословно написано следующее:
9) пункт 17 дополнить абзацем следующего содержания:
«Проведение аттестационных испытаний информационной системы лицом (подразделением), осуществляющим проектирование и (или) внедрение системы защиты информации информационной системы не допускается»;
Уже идут жаркие споры о том, идет ли речь о различных организациях и о запрете одному лицензиату делать и проектирование системы защиты и аттестацию, либо все же о конкретных сотрудниках. Я считаю, что в данном случае речь идет именно о различных сотрудниках, и о том, что не должны одни и те же люди делать проект и проводить аттестационные испытания и если это будут делать разные подразделения одной организации, то это вроде как допустимо. Вывод сделан чисто интуитивно, исходя из опыта использования других нормативных актов. Обычно связка «лицо (подразделение)» используется в отношении конкретных сотрудников или отделов организации, а для обозначения организаций в целом применяются термины «заказчик», «оператор», «исполнитель», «организация», «лицензиат» и т. д. Но конечно, было бы неплохо сделать уточнение.
Об обязательном тестировании на проникновение ГИС 1 и 2 класса
Я уже писал, о том, что ФСТЭК планомерно движется к реальной защите информации и данный тезис проекта — очередное этому подтверждение. Пентесты разные нужны, пентесты разные важны, но тут тоже требуются уточнения. Очень много уточнений. Возможно, очередная методика или ГОСТ. Потому что нормальный пентест это очень сложный и во многом творческий процесс. С ходу возникают такие вопросы:
- как делать пентест? по методу черного или белого ящика? может серого?
- пентест делать изнутри или снаружи?
- насколько глубоким должен быть пентест? если, например, (утрируя) я запустил nmap и не обнаружил аномалий в части открытых портов и сетевых сервисов, можно сказать, что пентест пройден успешно или нужно копать глубже?
- какими компетенциями должен обладать пентестер? если я пошагово прошел по вот этому гайду и у меня все получилось, я уже могу делать пентесты государственных информационных систем 1 класса? а 2 класса? или все-таки нужны более серьезные курсы, подготовка, опыт?
И это только те вопросы, которые сразу возникают в голове когда слышишь «пентест ГИСа».
Об аттестате на 5 лет
11) в пункте 17.4 слова «в случае окончания срока действия аттестата соответствия» заменить словами «по окончании срока действия аттестата соответствия, который не может превышать 5 лет,»;
Намек на то, что максимальный срок действия аттестата может быть увеличен с 3, до 5 лет. Но чтобы это свершилось, нужно вносить изменения в другие нормативные акты. В принципе, 3 года тоже не превышает 5 лет, поэтому смысла вставлять такую фразу просто так не вижу. Думаю все-таки появилась эта цифра здесь неспроста.
Об упразднении 4 класса ГИС
4-й класс ГИС (а если точнее — 4-й уровень значимости информации) был изначально мертворожденным, непонятным и неприменимым, поэтому здесь все логично. И я даже не вижу тут причину в том, что необходимо сделать 3 класса под новые классы средств защиты. Проблем бы не было, если бы регулятор сказал, что СрЗИ 6 класса используются в ГИС 3 и 4 классов. Проблема была в том, что 4 класс ГИС был практически не применим и лишь вносил лишнюю путаницу. Теперь эта проблема решена.
Далее в проекте приказа идет обновленная таблица с мерами, но отличается она от существующей лишь отсутствием столбца под 4 класс ГИС. При этом ФСТЭК уже давно обещал добавить в список мер как минимум следующие разделы:
- управление потоками информации;
- защита информации при использовании мобильных устройств;
- безопасная разработка ПО;
- управление обновлениями ПО;
- планирование мероприятий по обеспечению защиты информации;
- информирование и обучение персонала;
- анализ угроз безопасности информации и рисков от их реализации;
- выявление инцидентов и реагирование на них;
- управление конфигурацией информационной системы и ее системы защиты информации.
И если многие пункты в том или ином виде уже присутствуют в текущей редакции 17 приказа, то такие разделы как «безопасная разработка ПО» и «информирование и обучение персонала» будут абсолютно новыми. Но так как этих изменений в рассматриваемом проекте приказа нет, значит это лишь начало преобразований главного документа по защите информации в государственных информационных системах.