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

to oko
В Вашей логике ТЗ пишет интегратор, а в логике приказа оператор (заказчик).

Отступление от буквы Приказа не всегда радует регулятора: он не любит, когда кто-то умничает ;)

to WORM
Вовсе необязательно. То ли дело, что оператор/владелец в большинстве случаев никакое ТЗ разработать самостоятельно не может - все равно все приходится делать специалистам со стороны...
По моей логике ТЗ не должно быть написано без предварительного анализа Объекта. А раз уж анализ проводился, то имеет смысл и моделирование сделать ДО ТЗ, а не после и тем более не вместо. Тогда в ТЗ можно привести конкретные меры и требования, что, куда и сколько вешать в граммах, а не как обычно, ага...
И потом, никакого противоречия "букве" регулятора - в том же 17 Приказе раздел "Формирование требований" определяет единый этап оформления и ТЗ, и Модели. Мой подход только в том, чтобы моделирование проводить заранее и результаты моделирования включать в ТЗ. А не писать в ТЗ избитое "должно быть проведено моделирование Объекта", потому что результат такого моделирования может очень сильно разойтись с первичным ТЗ. Что потребует его переработки или создания СТЗ, которое по второму кругу придется пускать на согласование с регуляторами. А это, imho, в большинстве случаев лишние бессмысленные действия...

ЗЫ Главное, каждый шаг и тем более отступление от "принятых порядков" ради тех или иных преференций (включая экономию времени и труда специалистов) обосновывать и согласовывать с регуляторами. Чтобы потом не было мучительно больно на этапе аттестации и/или выездных проверок...

to oko
Да это-то понятно, и я с Вами согласен.

Вопрос был в том, на каком этапе определяется (обосновывается) набор мер ЗИ.
По приказу, в ТЗ должны быть отражены "требования к мерам ЗИ" (это что?), а в проектной документации - базовый адаптированный .....бла-бла... набор мер ЗИ. Он выбирается с учетом МУ, особенностей объекта и т .д.

Чтобы угодить Регулятору, мне кажется, в ТЗ можно тупо привести базовый набор (под класс ИС), и задать требование: уточнить его на этапе проектирования с учетом МУ, особенностей объекта и т. п.
Будет логично, а главное, всё по букве приказа (которому, правда, жить осталось меньше года, далее будем разрабатывать систему ЗИ по ППр-676 и по ГОСТам).

to WORM
Формально да, порядок такой. Но тогда ценность такого ТЗ падает, ибо оно перестает быть руководством к действию, а переходит в разряд руководства к размышлению. Что, в случае недобросовестности или отсутствия понимания у исполнителей только усугубляет всю ситуацию в целом...
Вы замену 17 Приказа на новый Проект Приказа для ГИС, гос.органов, ФГУП и т.д. имеете в виду?

\\ Вы замену 17 Приказа на новый Проект Приказа для ГИС, гос.органов, ФГУП и т.д. имеете в виду?

Ну да... Лютиков объявил, что с 01.03.2026 г вступает в силу. Правда, номер не назвал.

to WORM
Muchos gracias!
Впрочем, вне зависимости от перемены приказов и прочей нормативки, пока не придумают радикально новый и удобный метод, все равно буду руководствоваться пошаговкой, приведенной на прошлой странице обсуждения. Ибо логично, непротиворечиво и люфты есть во всех нужных местах, ага...

ЗЫ Жаль, что множество активных товарищей покинуло форум. И периодические интересные обсуждения и баталии уж слишком редки в нашей суетное и неспокойное время...

Добрый день всем.

К рассуждениям выше соглашусь с oko. Сами работаем почти по такому же сценарию.

1. Предварительное обследование обьекта. Утверждение заказчиком каких-то начальных документов (приказ о создании)

2. Модель угроз и следом акт классификации. В МУ не должно быть никаких мер защиты, только про нарушителей, угрозы и тд по методике 21 года.

3) тех задание. Именно тут определяем базовый набор мер, адаптация, уточнение и тд. Все это дружим с угрозами из п.2. Тут чисто требования, все по госту.

Мое личное мнение, что так и должно быть. ТЗ в целом должно выдвигать требования, а след пункт показывать, как их реализовать. Внедрение их реализовывает. Фстэк одобряет такой подход.

4. Техпроект. Тут уже пошло разьяснение этих мер защиты, что должно делаться по данным мерам, какие срзи используются. Что требуется закупить и тд.

5. Разработка ОРД

6. Внедрение СЗИ.

7. Аттестация

8. Ввод в эксплуатацию.


— а теперь логичные ответы на вопросы—

Обследование мб и не нужно, тут как религия подскажет.

Нет документа основания создания - старт работ не обоснован.

Нет МУ - ну и какие требования можно написать в ТЗ?

В ТРП не корректно обьявлять базовый набор мер. ТЗ - говорит как должно быть. ТРП - говорит что для этого нужно. Аттестация - что по итогу вышло. Так, если кратко.

—-к автору—-

Не правы Вы. Живите так, как хочет регулятор. Систему Вы не поломаете.

ПО ПУНКТУ 2 НЕПРАВИЛЬНО
акт классификации
СЛЕДОМ МОДЕЛЬ УГРОЗ
А НЕ НАОБОРОТ

*в сторону*
Безопасники делятся на следующие категории:
- обосновывают угрозы НДВ (1, 2 и 3 типов по ПП РФ 1119) в Модели до момента классификации ИСПДн;
- вначале классифицируют ИСПДн "волевым" решением, а затем стараются обосновать угрозы НДВ в Модели "задним числом";
- в принципе забили на обоснование и принципиально пишут 3 тип угроз НДВ (потому что вменяемых разъяснений и рекомендаций в их отношении ни Правительство, ни регуляторы до сих пор не выдали);
- занимаются безопасностью ГИС/КОНФИ/КИИ/ИСОП/АСУТП, где такой нормативной проблемы попросту не существует;
- не в курсе и/или погружаются в вопросы моделирования и/или классификации ОИ.

Опередил меня oko.

to Аноним. А Вы тип угроз испдн где собрались определять?

МУ делается перед актом!