Согласование МУ и ТЗ - Форум по вопросам информационной безопасности

Коллеги, добрый день! Подскажите по такому вопросу:
Местное Управление ФСТЭК отказывается признавать аттестацию ГИС, так как выявлено нарушение п. 15. б) Порядка аттестации по 77 Приказу - "проверку наличия согласования с ФСТЭК России...модели угроз безопасности информации, технического задания на создание (развитие, модернизацию) объекта информатизации." Основываются что должна быть согласована и МУ и ТЗ.
Данное требование противоречит ПП РФ № 676 п. 3 "Модель угроз безопасности информации и (ИЛИ) техническое задание на создание системы согласуются с федеральным органом исполнительной власти в области обеспечения безопасности."
ТЗ согласовывать Заказчик не собирается, так как требования ПП РФ 676 выполнены - согласована МУ.
Есть у кого-нибудь какая-либо практика по данному вопросу?

to ССП
То ли ситуация мутная, то ли приведенное ее описание...
Стоит для начала выяснить, почему изначально согласовали только Модель. Если отказ отправлять на согласование ТЗ был на стороне отправителя (по принципу "почему бы и нет - должно прокатить") - виноват сам отправитель (по ответному принципу "не прокатило"). Если же согласователь Модели явно ("на бумаге") указал, что ТЗ не требуется, то текущих проверяющих можно ткнуть в такое письмо. Особенно, если согласователь и текущие проверяющие - сотрудники одного и того же УФСТЭК. Если же нет письма - опять-таки виноват сам отправитель...
По опыту, достаточность согласования только Модели (без ТЗ) - крайне маловероятна. Потому что цитировать ПП РФ № 676 нужно полностью - ТЗ всегда первичнее и важнее, ибо "Создание системы осуществляется в соответствии с разрабатываемым согласно концепции техническим заданием на создание системы (очереди системы) с учетом модели угроз безопасности информации". В оную цитату, собственно, настоятельно рекомендуется ткнуть уже Заказчика, ага...

ЗЫ Не знаю, косяк ли это обрезанной цитаты или принципиального подхода, но ТЗ/Модель подлежит согласованию не только с ФСБ России (ФОИВ в области обеспечения безопасности), но и со ФСТЭК России (ФОИВ в области ПДТР и ТЗИ)...

В ПП РФ № 676 п. 3 написано иначе:
>>>Техническое задание на создание системы (очереди системы) и (или) модель угроз безопасности информации согласуются с федеральным органом исполнительной власти в области обеспечения безопасности и федеральным органом исполнительной власти, уполномоченным в области противодействия техническим разведкам и технической защиты информации, в пределах их полномочий в части, касающейся выполнения установленных требований о защите информации.<<<
Разница большая.

to oko
"Если отказ отправлять на согласование ТЗ был на стороне отправителя (по принципу "почему бы и нет - должно прокатить") - виноват сам отправитель (по ответному принципу "не прокатило")".

Прошу указать пункт где написано что должны быть согласованы и "МУ" И "ТЗ", ключевой сочинительный предлог который в п.3 ПП 676 указан в скобках - ИЛИ.
"ТЗ" и "МУ" разработаны и утверждены, "МУ" согласована.
Прямой обязанности что должны быть согласованы И "МУ" И "ТЗ", кроме приказа 77, который к оператору не имеет никакого отношения - нет.

to ССП
Т.е. вас не логика ситуации в целом интересуют, а трактовка букв во фразе, вырезанной из контекста?
Уже все указал и даже процитировал - абзац из ПП РФ 676 выше того, на который ссылаетесь вы. Перечитайте, пожалуйста, внимательно (как указанный абзац, так и весь мой ответ) - и отпадут любые вопросы, откуда такая позиция у регулятора...
Копаться же в предлогах и проч. оборотах языка можно ради интереса либо на форуме филологов, либо сразу в суде. Где доказывать, что регулятор не прав, потому что допускается и "И", и "ИЛИ" (по всей видимости, на усмотрение владельца/оператора ГИС). Но, imho, в причину вышесказанного (и, в особенности, при отсутствии бумаги, в которой конкретный регулятор подтвердил, что для согласования конкретной ГИС достаточно только ее Модели), это не приведет ни к чему полезному...

ЗЫ Модуль экстрасенсорики подсказывает, что все-таки имела место быть ситуация "прокатит - не прокатило"...

to oko
Не убедительно.
Модель угроз безопасности информации написана, утверждена, согласована со ФСТЭК без замечаний.
На основании МУ создано ТЗ на СЗИ. ТЗ утверждено.
На основании какого требования ТЗ должно отправляться в ФСТЭК на согласование?
Что должно было "прокатить" - "не прокатить"?
Требование выполнено.
Касаемо филологов - между кнутом и (или) пряником, я выберу только пряник.

Бесполезная дискуссия. У нас уже сложилась ситуация: "Хотелка регулятора обязательна к исполнению".
Кто не согласен - имеет право обращаться в суд и бодаться с регулятором.

Для суда регулятор - лицо не заинтересованное, его мнение весомее.

Рад вас видеть, тов. WORM, без шуток :)
На мой взгляд по сабжу - тут не хотелки, а чистая логика. Повторюсь в который раз: в означенном ПП РФ явно указано, что создание ГИС осуществляется в соответствии с ТЗ - модель при этом вспомогательна (учитывается, но только в части выводов по актуальным угрозам, потому что Модель не может и не должна содержать конкретных Требований ИБ, предъявляемых к ГИС - это задача ТЗ или отдельного документа). Следовательно, ТЗ всегда первичнее. Следовательно, в указанном И/ИЛИ и при наличии любых сомнений сперва необходимо узнать у регуляторов, нужны ли им на согласование ТЗ+Модель, только ТЗ или (исключения, конечно, возможны) только Модель. И узнать под подпись, официально. Иначе, на последующих этапах работ возможны проблемы как у тов. СПП. Потому что работы по ИБ всегда комплексны: моделирование, проектирование, внедрение, аттестация, периодический контроль. И заранее нужно знать и учитывать особенности каждого этапа. Короче говоря, все закономерно...

И да, 77 Приказ напрямую касается Владельца ГИС. Если же Оператором ГИС является отдельное лицо (не Владелец), то в означенной у тов. СПП ситуации Оператор, желая вывернуть в свою пользу (воспользовался ИЛИ, а про особенности аттестации вообще не в курсе, потому что 77 Приказ его формально не касается), явным образом подставляет Владельца ГИС. Что чревато для Оператора куда большими проблемами, чем частное бодание с предствителями регулятора на почве особенностей русского языка, ага...
Если же Оператор и Владелец - одно лицо, то все вопросы отпадают автоматически. Достаточно лишь уметь читать и думать хотя бы на шаг вперед...

Спасибо, уважаемый oko, взаимно. Да я это так, минутная слабость :)

Логика не всегда помогает в общении с Регулятором. Знаю случаи, когда в ТЗ требовали определить полный набор мер защиты, хотя в их же приказе (17-м) сказано, что набор мер обосновывается на этапе проектирования. Меры выбираются с учетом МУ, которой на этапе ТЗ еще нет.
И как же должны выглядеть "требования к мерам" в ТЗ, не понимает никто.

to WORM
Всегда придерживался следующего подхода (в сущности, полностью соответствует "духу" методологии всех регуляторов):
1. Полноценный предварительный анализ объекта. Выяснение базовых требований, исходя из классификации (категорирования) объекта. Уточнение (дополнение) требований по ведомственной линии и/или "хотелкам" Владельца/Оператора (при наличии таких требований и "хотелок").
2. Анализ уязвимостей объекта (концептуально-логического, функционального, правового, сетевого, технического, программного характера).
3. Моделирование объекта (угрозы, нарушители, ущерб, иные факторы).
4. ТЗ на создание объекта или на КСЗ объекта (особенно, если концепцию и логику объекта менять "нельзя", потому что он "уже есть"). В этом ТЗ совокупные результирующие Требования, полученные из п. 1 - 4. В особо сложных случаях - Требования как отдельный документ с явным обоснованием.
5. Проектирование КСЗ объекта. При необходимости - аналитическое обоснование реализуемых мер безопасности (защиты), если не все Требования удается выполнить "в лоб" (особенно актуально, если Анализ/Моделирование проводили одни, ТЗ писали другие, а Проектированием и Внедрением будут заниматься вообще третьи).
6. Закупка, внедрение, монтаж, настройка, разработка эксплуатационной, технической, организационной документации под это все.
7. Тестовая эксплуатация (если есть возможность и "желание"). При необходимости - возврат вплоть до п. 2, если тестовая эксплуатация подсветила "непокрытые зоны".
8. Контроль эффективности принятых мер безопасности или полноценная аттестация (зависит от Требований). Опять-таки возврат вплоть до п. 2, если результаты испытаний отрицательные.
9. "Боевая" эксплуатация объекта, в ходе которой постоянный мониторинг инцидентов и периодическая переоценка и Модели, и КСЗ. Здесь же и "тестирование защищенности" разного рода и стиля (кого на что хватило, ага). При необходимости - возврат вплоть до п. 2 (с условиями и необходимостью последующего контроля или аттестации при таких изменениях желательно определиться заранее, чтобы потом не было мучительно больно).
10. Вывод из эксплуатации или полноценная модернизация объекта (читай, все заново, начиная с п. 1, потому что объект будет уже совсем не тот, что раньше).
Тогда после п. 4 регуляторам отправляется на согласование ТЗ и, при запросе с их стороны, Модель. Все заранее обговаривается даже если это не требуется законодательно в явном виде. Опять-таки, если Аналит.обоснование/Проект показывают сильные отклонения от ТЗ/Модели - повторное согласование (как минимум, изменений)...
Как показывает практика, такой подход позволяет и принцип комплексности не нарушать, и прозрачность всех действий повышает, и проблемы на этапах аттестации, мониторинга, да даже согласования снижаются до допустимых и ожидаемых отклонений...

ЗЫ Это, конечно, идеал. На деле, разумеется, и этапы местами меняют, и углы "спрямляют, и прочие выверты сознания происходят. Зачастую, по причине банальной неграмотности, жадности или особой упоротости лиц, принимающих решение. Но это уже отдельная песня, ага...