ЗВС 1-2

Базовый состав мер по защите информации, передаваемой по вычислительным сетям применительно к уровням защиты информации

ЗВС.1 (Т-Т-Т)

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

Уровень защиты информации: 3-Т, 2-Т, 1-Т.

Пояснение

Существует базовый международный стандарт ISO описывающий проблему аутентификации, в том числе применительно к сетевым протоколам:

-ISO/IEC 29115:2013(MAIN) Information technology — Security techniques — Entity authentication assurance framework ;

Обучающие материалы компании Алладин:

1. https://www.aladdin-rd.ru/company/pressroom/articles/obsij_analiz_mezdunarodnyh_standartov_po_identifikacii_i_autentifikacii_subektov_pri_dostupe_k_informacii_cast_1

2. https://www.aladdin-rd.ru/company/pressroom/articles/obsij_analiz_mezdunarodnyh_standartov_po_identifikacii_i_autentifikacii_subektov_pri_dostupe_k_informacii_cast_2

Реализация - Т

Реализация требования подразумевает использование таких протоколов как mTLS, IKE, SSH и т.д., но ключевая идея любой реализации базируется на аутентификации обеих сторон взаимодействия.

Т.е. на примере клиент-серверной архитектуры - сертификат публичного ключа должен быть и у сервера, и у клиента, подробнее можно прочитать в RFC на SSH:

RFC 4252: The Secure Shell (SSH) Authentication Protocol

Дополнительно важно проводить инвентаризацию внешних взаимодействий и поддерживать в актуальном виде схемы сети и схемы потоков данных.

Проверочные процедуры (свидетельства)

1. В ходе интервью с системными администраторами уточнить внешние взаимодействия;

2. Изучить документацию, в том числе схемы потоков данных и схемы сети организации;

3. Посмотреть настройки сетевого оборудования на внешнем периметре, в том числе конкретные сетевые доступы (какие именно используются протоколы);

4. Изучить настройки конкретного оборудования, серверов, узлов сети на предмет наличия сертификатов или иных способов двухсторонней аутентификации.

Типичные недостатки

Не выявлены.

Компенсационные меры

Можно попробовать занять позицию, аналогичную позиции положений Банка России, которая говорит о возможностях не применять средства СКЗИ для обеспечения целостности электронных сообщений, в ситуациях, когда мы ограничиваем сетевые взаимодействия выделенными сегментами сетей, но это спорный момент, т.к. требование ЗВС.1 все же явно апеллирует именно к рискам подлинности сторон при взаимодействии, и то, что у нас в соединении нет аутентификации обеих сторон по сертификатам не позволяет нам обработать риск подмены одной из сторон.

Ниже цитата из 757-П:

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

Тем не менее попробуем описать тезисы компенсационной меры:

1. Наш риск - подмена получателя, в результате которой реализуется угроза утечки информации, либо получение ложной информации;

2. Чтобы нивелировать этот риск возможно использовать следующий комплекс шагов:

   1. По аналогии с цитатой из положений Банка России ограничить сетевые взаимодействия выделенными сегментами (адресами) и протоколами (по принципу минимизации всех внешних сетевых взаимодействий);

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

   3. На нашей стороне дополнительно использовать контроль форматирования сообщений, типов и размеров данных и т.п. - таким образом, чтобы принимающая система в принципе не могла обработать входящее и могла быть устойчивой к риску подмены второй стороны взаимодействия;

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

Выявленные коллизии

Не выявлены.

ЗВС.2 (Т-Т-Т)

Реализация защиты информации от раскрытия и модификации, применение двухсторонней аутентификации при ее передаче с использованием сети Интернет, телекоммуникационных каналов и (или) линий связи, не контролируемых финансовой организацией.

Уровень защиты информации: 3-Т, 2-Т, 1-Т.

Пояснение

Реализация - Т

Для реализации

Проверочные процедуры (свидетельства)

Для процедур

Типичные недостатки

Для недостатков

Компенсационные меры

Для мер

Выявленные коллизии

Для коллизий