А вы привлекаете силы ФСБ? Ответ на ваш вопрос здесь "Проект Плана, содержащий положения, предусмотренные пунктом 7 настоящего Порядка, разрабатывается субъектом критической информационной инфраструктуры совместно с НКЦКИ и направляется на согласование в ФСБ России." . Вам НКЦКИ расскажет куда его направлять дальше в ФСБ

Спасибо!

Коллеги, добрый день. Кто-то отправлял форму ОКИИ, обрабатывающему ГТ? Как заполнять наименование ПО, средства защиты и т.д.? Как отправлять?..

как секретное делопроизводство.

А это обязательно надо отправлять?

Для ОКИИ с ГТ исключается только выполнение 239 приказа фстэк. Все остальное выполняется на общих основаниях, но с учётом специфики секретности сведений

Как я понимаю системой с ГТ у вас является аттестованный АРМ для подготовки секретных документов. В таком случае ПО не сильно отличается от тысячи типовых и меры везде одинаковые.
А к какой сфере вы отнесли свой ОКИИ с ГТ?

К той самой, в которой ГТ, в нашем случае - транспорт

Здравствуйте! Интересует вопрос по поводу описания уязвимостей на объекте КИИ. Кто встречался с этим? Как это делать или кому можно позвонить из регуляторов, чтобы примерно проконсультироваться?

а вы с какой целью уязвимости описываете? Так есть госты https://bdu.fstec.ru/documents/27

Да для модели угроз вот требуется

Спасибо, читал стандарт

Для модели угроз указывать уязвимости не нужно.

Методика моделирования, которую предлагает ФСТЭК, рекомендует описывать модель угроз в терминах техник - возможных действий нарушителя, направленных на использование уязвимостей или обход средств защиты. Т.е., когда вы пишете, что нарушитель может перехватить трафик в сегменте сети с помощью техник ARP Spoofing и rogue DHCP, само упоминание этих техник говорит о том, что в этом сегменте возможно появление уязвимостей, позволяющих применять эти техники. Выписывать сами уязвимости при этом не нужно

239 приказ
Описание каждой угрозы безопасности информации должно включать:
......
......
уязвимости (ошибки), которые могут быть использованы для
реализации (способствовать возникновению) угрозы безопасности информации.

И все равно не нужно - методика моделирования угроз этого не требует :) А как сказал один заслуживающий доверия человек, "если проект методики противоречит действующим приказам - пишите замечания, внесём изменения в приказы" :)

Когда вы действительно будете писать модель угроз, вы увидите, что для техник ARP spoofing и rogue DHCP ни в БДУ, ни в CVE, ни где бы то ни было подходящих уязвимостей нет (потому что там нет такого класса уязвимостей, как ошибки архитектуры).

Поэтому будет достаточно, если в качестве уязвимости вы укажете "отсутствие аутентификации узла при подключении сети", "возможность неавторизованной установки софта или запуска сетевой службы" и т.п. Если ещё и идентификаторы CWE укажете - вообще будете отличником боевой и политической.

Дмитрий, а причем здесь проект методики?

Дмитрий, спасибо за идею, но методика моделирования пока что не утверждена. Поэтому тоже непонятно как двигаться. Вдруг в скором времени утвердят и придётся все переделывать.

Вы сперва саму модель напишите без указания конкретных уязвимостей. На это по-любому больше месяца уйдет. А там уже решите, нужно ли вам их подробно вписывать или ну его

Набор средств защиты, достаточный по проекту приказа ФСТЭК России для подключения значимого объекта КИИ к сети связи общего пользования: МЭ уровня сети, граничный маршрутизатор, антивирус, СКЗИ, СОВ/СПВ, МЭ уровня веб-сервера (часть - опционально) https://regulation.gov.ru/projects#npa=101634

А  если цитату про антивирус привести полностью, то это окажется ни разу не "антивирус", а средство контентной фильтрации трафика с антивирусным движком :)

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