Никакой личной боли, просто непонятен вопрос и его предпосылки.

Есть функции безопасности, которые заказчик хочет получить 802.1x с интеграцией по RADIUS. Стандартная задача  проектирования - выбрать устройства, которые это умеют. Что должны были моделировать авторы требования? Почему кому-то может понадобиться, куча "разных, но однотипных программ-методик"? Ну и так далее. Такая, проблема и раньше не возникала, и сейчас ее нет.

Личная боль у меня состоит в том, что в текущей модели требований такие распределенные функции безопасности, широко доступные в общесистемном ПО оборудования многих вендоров, применять тяжело. Почти невозможно. Именно как функции безопасности в определениях 239П. Ну или их не считать функциями безопасности, но применять. но в этом случае нужно требования закрывать чем-то иным.

К сожалению, не разбираюсь в 239П, поэтому не могу ответить🤷‍♂

Так как будет выглядеть процедура испытаний для 802.1x+RADIUS когда оборудование - ПК на Win, Linux, IP-Телефоны, МФУ, контроллеры АСУ ТП, коммутаторы и др?

Испытывают конкретные функции, требования к которым заявлены ТЗ, например:
1. В ТЗ прописано требование, что устройства вот таких типов должны аутентифицироваться, через 802.1x + Radius
2. Разработчик системы безопасности должен в рабочей документации описать, что должно быть настроено на сервере авторизации и на каждом типе устройств.
3. В программе тестирования разработчик должен описать, что корректность выполнения этого требования должна быть проверена для каждого типа устройств при корректных и некорректных настройках.
4. Для каждого типа устройств должно быть несколько тест-кейсов (при корректно настроенной аутентификации, при некорректно настроенной, при не настроенной, при некорректных аутентификационных данных и т. п.)

Так оно должно было быть с незапамятных времен.

В 239 приказе добавилось:
5. Пентестеры должны убедится, что такую аутентификацию не получается, обойти.

В новой редакции приказа 239 добавлено:
6. Разработчик системы безопасности должен предоставить техническое описание реализации этой функции в каждом типе устройств.
7. В каждом типе устройств, использующих эту функцию, разработчик должен провести анализ уязвимостей.

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

Ок, возьмем коммутатор или wifi-точку, можно ли их ОС назвать общесистемным ПО, в которое встроены функции 802.1x?

Да, и требования к уровню доверия на них распространяться не будут (п. 29.2, второй абзац).

Дмитрий, спасибо! Трактовка понятна.

Добрый день! Есть ли у кого данный документ в формате ворда?

Добрый день. Подскажите пожалуйста, довелось ли кому-нибудь всё-таки достоверно выяснить, к какой сфере регулирования 187-ФЗ относится система 112?

КАКИЕ ВОПРОСЫ ЕСТЬ К РЕГУЛЯТОРАМ?

Хочу обратиться к вам за помощью 🙏 Мне надо составить обновленный список вопросов для Диалога с регулятором на наших региональных Кодах ИБ к ФСТЭК и ГОССОПКА.

Раньше списки вопросов выглядели так:

ФСТЭК:
1. Какие изменения в законодательстве произошли за последнее время? К чему готовиться субъектам КИИ?
2. Как нужно обосновывать выбранное значение показателей критериев значимости (применимо, не применимо) в актах категорирования?
3. Как проводить контроль выполнения и оценки эффективности выполнения норм защиты информации на объектах КИИ?
4. Как актуализировать Перечень объектов КИИ, подлежащих категорированию, если после его отправки произошли изменения?
5. Если организация отослала акты категорирования ОКИИ в ЦА ФСТЭК и Управление ФСТЭК по ПФО, и прошло больше 30 дней, то можно считать, что объекты уже в реестре ФСТЭК?
6. Нужно ли отправлять перечень объектов КИИ во ФСТЭК России, если он пустой?
7. Как правильно организовать категорирование в случае наличия филиалов — достаточно одной комиссии или же нужно создавать несколько?
8. Когда делать модель угроз безопасности ОКИИ: до или после категорирования?
9. В реестр ФСТЭК попадают только значимые ОКИИ, или незначимые тоже?
10. Какие требования нужно выполнять для незначимых объектов КИИ?
11. Сведения о защите ОКИИ являются гос. тайной?

ГОССОПКА:
1. Какие существуют варианты организации взаимодействия с НКЦКИ? Зависят ли они от размера субъекта КИИ или количества инцидентов?
2. Как получить методические документы ФСБ (помимо шести утвержденных приказов)?
3. Требования 196-го приказа распространяются на любой объект КИИ любого субъекта КИИ или только для центров ГосСОПКИ?
4. Требования 368-го приказа запрещают прямую передачу данных об инцидентах в иностранные организации. Что делать представительству или дочерней организации международной компании, если внутренними правилами установлено передавать данные об инцидентах в штаб-квартиру? Если их передавать в НКЦКИ, как предусмотрено 368-м приказом, то кто их потом и на каком языке передаст в штаб-квартиру?
5. Возможно ли применение SIEM иностранного производства в центрах ГосСОПКИ?
6. Насколько тяжело субъекту самостоятельно аккредитоваться в НКЦКИ, чтобы напрямую сообщать об инцидентах, или же рекомендуется обращаться к услугам специальных центров?

Надо ли что-то добавить/убрать? Буду ОЧЕНЬ благодарна за комментарии 🙏

по ПДн к РКН вопрос нет вообще?

Уважаемые коллеги!
Подскажите пожалуйста в каком документе прописано что подключение к ГосСОПКА необходимо производить через  сеть ViPNet с номером 10976?

«Варианты организации защищённого канала», хоть сам документ и без ограничительных пометок, но распространяется в составе пакета документов, на который в общем наложена пометка.

Вы должны передавать информацию в НКЦКИ. НКЦКИ имеет сеть ViPNet 10976.

Скоро кстати в документе стоит ожидать обновлений :)

КИИ. Подключение к ГосСОПКА
https://club.cnews.ru/blogs/entry/import_kii_podklyuchenie_k_gossopka_0ecb

До начала следующего года получится организовывать взаимодействие с Госсопка по защищённой сети на базе континент? :)