Исполнение пункта 26.1 приказа ФСТЭК №17. Коммутаторы и маршрутизаторы - Форум по вопросам информационной безопасности

Здравствуйте!
Вопрос по поводу пункта 26.1 приказа ФСТЭК №17.
Собственно, сам пункт: "26.1. При проектировании вновь создаваемых или модернизируемых информационных систем, имеющих доступ к информационно-телекоммуникационной сети "Интернет", должны выбираться маршрутизаторы, сертифицированные на соответствие требованиям по безопасности информации (в части реализованных в них функций безопасности)."
Ситуация:
1. В организации эксплуатируются две подсети: ЛВС и подсеть с доступом к сети "Интернет".
2. В подсети ЛВС функционирует информационная система (1С), для которой планируется построение системы защиты по требованиям 17 приказа.
3. В целях экономии, обе подсети работают на одних "проводах" и "оборудовании": VLAN + управляемые коммутаторы.
Собственно, вопрос: возможно ли остаться "пушистыми" перед ФСТЭК при таком построении сети, если дополнительно на границе подсетей (там, где непосредственно приходит провайдер) использовать сертифицированный маршрутизатор? Сами рабочие станции с 1С планируется оснастить SecretNet Studio (НСД+МЭ+СОВ).
Ведь пункт 26.1 говорит нам непосредственно про маршрутизаторы, а у управляемых коммутаторов несколько иное предназначение

При выполнении любых требований приказа имеет смысл руководствоваться логикой защиты конкретных ресурсов. Сиречь:
- насколько доверяем своим коммутаторам и реализации vlan по части разделения сегментов на "защищаемые" и "общие"?
- возможно, с позиции цена/качество, не имеет смысла думать именно над "маршрутизатором" и стоит влепить полноценный МЭ по профилю "А" с доп.функциями маршрутизации сетевого трафика (и так ли нужна в случае конкретной сети поддержка BGP, IGMP и проч.)?
- возможно, с инфраструктурной точки зрения, имеет смысл одной вменяемой сертифицированной "железкой" с L3-L7-фильтрацией разграничить физически и "защищаемый" от "общего", и их всех от Интернета?
- насколько целесообразно при таком подходе ставить персональные МЭ на каждую тачку внутри "защищаемого" сегмента?
А вообще, модель угроз решает. Если обеспечите логическую изоляцию от Интернета и иных внешних сетей любыми средствами, то можно воздействия из таких сетей не рассматривать. Следовательно, можно не париться над выполнением указанного требования. Но это все остается на совести того, кто подобное утверждение впишет в модель и гарантирует существующие меры защиты без внедрения новых средств, ага...

Спасибо за ответ!
Я правильно понимаю, нецелесообразность использования персональных МЭ вытекает из условия физического разделения сегментов МЭ типа А?
Дело в том, что физически отделить подсеть с ИС у нас не получится, поскольку парк таких машин составляет примерно 50% от всего парка, сами машины задействованы в решении и других задач. Тут ещё есть момент, что в ЛВС мы можем выделить несколько "защищаемых" сегментов, если рассматривать с позиции исполнения 17 либо 21 приказов и различных технологий обработки информации. Также есть своя информация ограниченного доступа (Конф, КТ), которую хотелось бы отделить от всего остального

imho, да, лучше "аппаратного" разделения никто пока не придумал. И перс.МЭ имеет смысл, когда на защищаемой машине есть сервисы, которые должны быть доступны одним, и недоступны другим. Для фильтрации в минималке хотя бы по IP...
Либо вообще для случая блокировки любых подключений к машине, при ее расположении в "опасном" сегменте сети. Но это редко кто-либо декларирует как явное требование, т.е. именно сертиф.перс.МЭ редко имеет смысл - функционал такой блокировки можно реализовать хоть встроенными средствами, хоть доп.средствами АВЗ и т.д. без сертификата. Другой вопрос, если вы рулите всеми компонентами SNS в центр.режиме...
Проблема в том, что перс.МЭ в чистом виде не аутентифицирует другие машины с таким же МЭ и не шифрует трафик между ними. В итоге, перс.МЭ "защищает" машину от "агрессивной среды" вокруг, но исходящий/входящий трафик машины как был подвержен манипуляциям в этой среде, так и остается. И если одна и та же машина должна на сетевом уровне взаимодействовать с сервисами и сегментами разного типа конфиденциальности, то тут уже имеет смысл задуматься либо о маркировке, либо о полноценном шифровании трафика. Иначе само решение в комплексе будет, мягко говоря, однобоким...
А что до требования регулятора - все просто - регулятор пытается хоть как-то заставить народ контролировать точки подключения к публичным сетям. Что бесспорно благая идея, но ее не надо воспринимать исключительно буквально...

Напоследок задам самый "коварный" подвопрос, в развитии моего изначального вопроса: как сегодня ФСТЭК относится к сегментированию сети с разными уровнями конфиденциальности с использованием VLAN? Вопрос заезжен уже лет 10, но я пока не нашёл ответа в стиле "У нас ФСТЭК был - VLAN одобрил". Кто-то в соседних ветках пишет что делает так, кто-то сегментирует самым проверенным способом - кабелями... Соглашусь что VLAN не средство защиты, но может стоит воспринимать VLAN больше как орг.меру по разделению информационных потоков чем техническую?

Для Александра:

> ... но может стоит воспринимать VLAN больше как орг.меру по разделению информационных потоков чем техническую?
Нет, не стОит. VLAN это не субъект, а объект. На неё нельзя ОРД возложить обязанности и наказывать за их неисполнение.

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

Ещё нашёл в методическом документе "Меры защиты информации в ГИС" от 11.02.2014 подробное описание мер ЗИС.17 Разбиение информационной системы на сегменты и ЗИС.23 Защита периметра (физических и (или) логических границ), а также само определение Периметра ИС.
Исходя из описания, есть как физическая, так и логическая граница, и сегментирование (ЗИС.17) может проводится с целью разделения по разным классам защищённости. При этом, по тексту применяются разные понятия: просто сетевой интерфейс и отдельный физический сетевой интерфейс.
Исходя из этого можно сделать вывод, что всё таки логическое разделение не просто допустимо, а именно регламентировано.
Поправьте если я заблуждаюсь

to Александр
Да, и физика, и *вырезано* лирика */вырезано* логика как угодно допустимы. Иначе виртуальные и программно-определяемые сети вообще не получалось бы защищать. Но...
Другое дело, что вы так и не ответили на вопрос, заданный в начале обсуждения: насколько вы доверяете оборудованию, реализующему VLAN на вашем конкретном ОИ? Расширю:
- разделение за счет VLAN у вас единственная "мера защиты" на логическом уровне?
- вы полностью доверяете как самому ТКО (прошивке, компонентам), реализующему VLAN на вашем конкретном ОИ, так и средствам и среде управления им?
- вы хотите прописать это логическое разделение как "исходную меру защиты", неотделимую от объекта информатизации, тем самым по умолчанию устранив любые связанные с ней УБИ? Т.е. по умолчанию после моделирования угроз не выставлять требования реализации иных мер защиты, направленных на обеспечение логического разделения?
- или вы хотите декларировать эту "меру защиты" как требуемую к реализации в рамках выставления требований безопасности к своему конкретному ОИ уже после анализа уязвимостей (недостатков) ОИ и моделирования УБИ? А если так, то нет ли для вашего конкретного ОИ явного требования регулятора использовать для реализации "мер защиты" исключительно сертифицированные средства защиты, к которым тогда следует отнести и логическое разделение VLAN средствами вашего ТКО со всеми вытекающими?
imho, на эти вопросы и следует отвечать каждый раз и применительно к конкретным ОИ при анализе любых спорных моментов, ага...

to СМ
Забавное сравнение...
Орг.меры != исключительно ОРД, а только предусматривает наличие ОРД. Принцип комплексности говорит, что орг.меры и техн.меры всегда взаимосвязанные. В случае с VLAN - техн.реализация такими-то средствами в составе ТКО, а орг.реализация - это правила заведения VLAN (кому access, кому trunk, кому заворот в native и т.д., ага) + правила и порядок контроля выполнения вышесказанного. Собственно, на Политику парольной защиты непосредственно тоже ответственность не возложить, но сама по себе Политика - это именно что часть орг.мер...

Начну с конца:
1. ФСТЭКом в отношении нас выдвинуты требования по аттестации одной из ИС в соответствии с приказом 17. ИС не ГИС. Почему именно по 17 описывать не буду.
2. Требования по использованию сертифицированных СЗИ явно предъявлены в документах ФСТЭК, поэтому не обсуждаются.
3. VLAN планируем как меру по сегментированию. Ограждаемся от других сегментов в ЛВС и ограждаем сегмент Интернет от ЛВС (при этом общение между внутренней и внешней сетью строим через сертифицированные аппаратные МЭ с ДМЗ (экранированной подсетью) ).
5. Задача МИНИМУМ - это "узаконить" сегментацию Интернет от ЛВС (а они сейчас у нас разделены управляемыми коммутаторами с использованием VLAN), т.к. это основная головная боль.
4. Доверять или нет оборудованию - вопрос сложный. Все линии и оборудование находятся в КЗ, администрируется всё это исключительно собственным персоналом. Оборудование (коммутаторы) не сертифицировано, не отечественное. Теоретически можем поставить отечественное и сертифицированное, но VLAN то останется VLANом, даже на нашем железе.
5. Шифрование трафика пока не рассматриваем как меру, уповаем на КЗ.