И если есть где почитать, то желательно в личку, Денис) благодарю ща понимание ))

Я думаю что спрос на мсэ типа Д должен появиться, нам вот 16 штук недавно надо было, но подход типа пару фильтров прикрутим и вуаля настораживает.

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

Вадим, я этот ваш слайд с "фирменными" кругами видел ещё в 2012-м году на конференции S4.

Каждое предприятие определяет этот момент самостоятельно.

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

Как правило изолированный подход ущербен. Любое ОРД должны быть разработаны в рамках общей концепции, с учетом оценки рисков. Как правило риски можно оценить только в разрезе компании. И общие политики должны быть общими, это я про верхний уровень. Все что связано с техпроектом, и ОРД для конкретного АСУ может быть написанно под него, но должны быть отражены следующие вопросы 1) Группа ограниченний и допушений которые накладываются политиками верхнего уровня 2) Транслировать допустимые показатели рисков (т.к. без этого можно написать то что вам кажется допустимом, но насамом деле это будет сверх критично) Пример, вы можете остановить асу на угольном производстве, и собственно тут может быть очень низкий риск, через день запустим и все хорошо, но если в результате этого у вас в группе компний остынут пять пецей , то для вас это сверх критично...

Это если риски общие, а если определены 9 процессов верхнего уровня, на них в таком же порядке наложены риски. Т.е риски разделены по основным процессам и так ит и асутп разные процессы.

Надо ли разделять тогда? Потому что это разные процессы

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

Я бы делал общию политику и отдельно ОРД.

По поводу  МЭ и цифровых подписей очень сложный вопрос, при этим всегда есть опасность что будет фальш позитив, т.е. будет заблочен лигитивный трафик или цифровая подпись допустим не сойдется, а что будет в результате? если это управляющий трафик то команда просто не пройдет, а в результате могут произойти процессы более критические чем скажем сканирование портов. Мое мнение что проверка подписей и не соответствие трафика АСL только повод для оповещения админа ИБ. Иначе безопасность может быть во зло. Или как миниму должно быть два параметра для автоматической блокировки, скажем не соответствие трафика по данным IDS и отсутствие цифровой подписи.  Мне понравилась тема которую представлял @vpp01 на PHD, когда сравнивались параметры ИБ и физические.  Т.е. я к тому что использование ИТ подходов на прямую к АСУ может быть очень опасно.

да пофигу на круги, текст ;)

сейчас скажут, что SPANят трафик и все равно дайте денег

уже установили что ЛК у ПТ 1в1 слайд скопировали =)

Я круги ровно с этим текстом и имел в виду

так цвета можно было поменять, размеры, расположение и шрифт православный

Если Политика то я бы сделал общую для всей организации если policy то раздельные.

У нас промышленные свитчи ряд вендоров и OEMит 🙂

У нас это давно на уровне концепции определено (если не изменяет память года так с 2009)