# ЗВС 1-2 ## ЗВС.1 (Т-Т-Т) > *Применение сетевых протоколов, обеспечивающих защиту подлинности сетевого соединения, контроль целостности сетевого взаимодействия и реализацию технологии двухсторонней аутентификации при осуществлении логического доступа с использованием телекоммуникационных каналов и (или) линий связи, не контролируемых финансовой организацией.* > > Уровень защиты информации: 3-Т, 2-Т, 1-Т. #### Пояснение Существует базовый международный стандарт ISO описывающий проблему аутентификации, в том числе применительно к сетевым протоколам: -ISO/IEC 29115:2013(MAIN) Information technology — Security techniques — Entity authentication assurance framework ; Обучающие материалы компании Алладин: 1. 2. #### Реализация - Т Реализация требования подразумевает использование таких протоколов как mTLS, IKE, SSH и т.д., но ключевая идея любой реализации базируется на аутентификации обеих сторон взаимодействия. Т.е. на примере клиент-серверной архитектуры - сертификат публичного ключа должен быть и у сервера, и у клиента, подробнее можно прочитать в RFC на SSH: {% embed url="" %} Дополнительно важно проводить инвентаризацию внешних взаимодействий и поддерживать в актуальном виде схемы сети и схемы потоков данных. #### Проверочные процедуры (свидетельства) 1. В ходе интервью с системными администраторами уточнить внешние взаимодействия; 2. Изучить документацию, в том числе схемы потоков данных и схемы сети организации; 3. Посмотреть настройки сетевого оборудования на внешнем периметре, в том числе конкретные сетевые доступы (какие именно используются протоколы); 4. Изучить настройки конкретного оборудования, серверов, узлов сети на предмет наличия сертификатов или иных способов двухсторонней аутентификации. #### Типичные недостатки Не выявлены. #### Компенсационные меры Можно попробовать занять позицию, аналогичную позиции положений Банка России, которая говорит о возможностях не применять средства СКЗИ для обеспечения целостности электронных сообщений, в ситуациях, когда мы ограничиваем сетевые взаимодействия выделенными сегментами сетей, но это спорный момент, т.к. требование ЗВС.1 все же явно апеллирует именно к рискам подлинности сторон при взаимодействии, и то, что у нас в соединении нет аутентификации обеих сторон по сертификатам не позволяет нам обработать риск подмены одной из сторон. Ниже цитата из 757-П: "*1.9. ..... **Указанные в*** [***абзаце втором***](https://www.garant.ru/products/ipo/prime/doc/400824645/#192) ***настоящего пункта требования по реализации мер** по использованию усиленной квалифицированной электронной подписи, усиленной неквалифицированной электронной подписи или иных СКЗИ, реализующих функцию имитозащиты информации с аутентификацией отправителя сообщения, **не применяются** в случае, **если в целях обеспечения целостности электронных сообщений** и подтверждения их составления уполномоченным на это лицом при передаче электронных сообщений **используются выделенные сегменты вычислительных сетей и указанные меры** определены некредитными финансовыми организациями, реализующими усиленный и стандартный уровни защиты информации, как **неактуальные в модели угроз и нарушителей безопасности информации.***" Тем не менее попробуем описать тезисы компенсационной меры: 1. Наш риск - подмена получателя, в результате которой реализуется угроза утечки информации, либо получение ложной информации; 2. Чтобы нивелировать этот риск возможно использовать следующий комплекс шагов: 1. По аналогии с цитатой из положений Банка России ограничить сетевые взаимодействия выделенными сегментами (адресами) и протоколами (по принципу минимизации всех внешних сетевых взаимодействий); 2. В протоколах взаимодействия вместо аутентификации сторон применить шифрование на уровне сообщений (т.е. даже если мы не уверены в подлинности получателя, то в случае уверенности в надежности криптографии и конфиденциальности секретного ключа, нам в принципе безразлично то, что сообщение попадет не туда); 3. На нашей стороне дополнительно использовать контроль форматирования сообщений, типов и размеров данных и т.п. - таким образом, чтобы принимающая система в принципе не могла обработать входящее и могла быть устойчивой к риску подмены второй стороны взаимодействия; 3. Дополнительный момент над которым стоит поразмышлять - это целесообразность подобной компенсации для конкретного случая, кажется, что в большинстве реальных ситуаций реализовать один из типовых протоколов с двухсторонней аутентификацией не составит труда. При этом, если речь идет о каком-то уникальном проприетарном протоколе взаимодействия, то на основании п. 2 возможно эффективнее будет обосновать неприменимость меры к конкретному взаимодействию или вовсе исключить данную меру из состава мер защиты на этапе адаптации (уточнения). #### Выявленные коллизии Не выявлены. ## ЗВС.2 (Т-Т-Т) > Реализация защиты информации от раскрытия и модификации, применение двухсторонней аутентификации при ее передаче с использованием сети Интернет, телекоммуникационных каналов и (или) линий связи, не контролируемых финансовой организацией. > > Уровень защиты информации: 3-Т, 2-Т, 1-Т.
Пояснение
#### Реализация - Т Для реализации #### Проверочные процедуры (свидетельства) Для процедур #### Типичные недостатки Для недостатков #### Компенсационные меры Для мер #### Выявленные коллизии Для коллизий