Применение сетевых протоколов, обеспечивающих защиту подлинности сетевого соединения, контроль целостности сетевого взаимодействия и реализацию технологии двухсторонней аутентификации при осуществлении логического доступа с использованием телекоммуникационных каналов и (или) линий связи, не контролируемых финансовой организацией.
Уровень защиты информации: 3-Т, 2-Т, 1-Т.
Существует базовый международный стандарт ISO описывающий проблему аутентификации, в том числе применительно к сетевым протоколам:
-ISO/IEC 29115:2013(MAIN) Information technology — Security techniques — Entity authentication assurance framework ;
Обучающие материалы компании Алладин:
- https://www.aladdin-rd.ru/company/pressroom/articles/obsij_analiz_mezdunarodnyh_standartov_po_identifikacii_i_autentifikacii_subektov_pri_dostupe_k_informacii_cast_1
- 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:
Дополнительно важно проводить инвентаризацию внешних взаимодействий и поддерживать в актуальном виде схемы сети и схемы потоков данных.
- В ходе интервью с системными администраторами уточнить внешние взаимодействия;
- Изучить документацию, в том числе схемы потоков данных и схемы сети организации;
- Посмотреть настройки сетевого оборудования на внешнем периметре, в том числе конкретные сетевые доступы (какие именно используются протоколы);
- Изучить настройки конкретного оборудования, серверов, узлов сети на предмет наличия сертификатов или иных способов двухсторонней аутентификации.
Не выявлены.
Можно попробовать занять позицию, аналогичную позиции положений Банка России, которая говорит о возможностях не применять средства СКЗИ для обеспечения целостности электронных сообщений, в ситуациях, когда мы ограничиваем сетевые взаимодействия выделенными сегментами сетей, но это спорный момент, т.к. требование ЗВС.1 все же явно апеллирует именно к рискам подлинности сторон при взаимодействии, и то, что у нас в соединении нет аутентификации обеих сторон по сертификатам не позволяет нам обработать риск подмены одной из сторон.
Ниже цитата из 757-П:
"1.9. ..... Указанные в абзаце втором настоящего пункта требования по реализации мер по использованию усиленной квалифицированной электронной подписи, усиленной неквалифицированной электронной подписи или иных СКЗИ, реализующих функцию имитозащиты информации с аутентификацией отправителя сообщения, не применяются в случае, если в целях обеспечения целостности электронных сообщений и подтверждения их составления уполномоченным на это лицом при передаче электронных сообщений используются выделенные сегменты вычислительных сетей и указанные меры определены некредитными финансовыми организациями, реализующими усиленный и стандартный уровни защиты информации, как неактуальные в модели угроз и нарушителей безопасности информации."
Тем не менее попробуем описать тезисы компенсационной меры:
- Наш риск - подмена получателя, в результате которой реализуется угроза утечки информации, либо получение ложной информации;
- Чтобы нивелировать этот риск возможно использовать следующий комплекс шагов:
- По аналогии с цитатой из положений Банка России ограничить сетевые взаимодействия выделенными сегментами (адресами) и протоколами (по принципу минимизации всех внешних сетевых взаимодействий);
- В протоколах взаимодействия вместо аутентификации сторон применить шифрование на уровне сообщений (т.е. даже если мы не уверены в подлинности получателя, то в случае уверенности в надежности криптографии и конфиденциальности секретного ключа, нам в принципе безразлично то, что сообщение попадет не туда);
- На нашей стороне дополнительно использовать контроль форматирования сообщений, типов и размеров данных и т.п. - таким образом, чтобы принимающая система в принципе не могла обработать входящее и могла быть устойчивой к риску подмены второй стороны взаимодействия;
- Дополнительный момент над которым стоит поразмышлять - это целесообразность подобной компенсации для конкретного случая, кажется, что в большинстве реальных ситуаций реализовать один из типовых протоколов с двухсторонней аутентификацией не составит труда. При этом, если речь идет о каком-то уникальном проприетарном протоколе взаимодействия, то на основании п. 2 возможно эффективнее будет обосновать неприменимость меры к конкретному взаимодействию или вовсе исключить данную меру из состава мер защиты на этапе адаптации (уточнения).
Не выявлены.
Реализация защиты информации от раскрытия и модификации, применение двухсторонней аутентификации при ее передаче с использованием сети Интернет, телекоммуникационных каналов и (или) линий связи, не контролируемых финансовой организацией.
Уровень защиты информации 3-Т, 2-Т, 1-Т.
Пояснение
При передаче данных по неконтролируемым каналам (интернет, арендованные линии связи) нужно одновременно шифровать трафик и убеждаться, что оба участника соединения — являются подлинными. Это закрывает перехват и чтение данных на неконтролируемом участке сети (MitM), подмену одной из сторон соединения при отсутствии взаимной проверки подлинности.
Главная цель меры — обеспечить безопасность информационного обмена при удаленном доступе по неконтролируемым каналам связи, гарантируя, что данные не будут перехвачены, изменены, а также что обе стороны обмена являются именно теми, за кого себя выдают.
Реализация требования подразумевает использование криптографических протоколов, обеспечивающих шифрование, контроль целостности и взаимную аутентификацию. Ключевая идея любой реализации базируется на аутентификации обеих сторон взаимодействия.
Основные направления технической реализации:
- Применение протоколов, обеспечивающих шифрование трафика и взаимную аутентификацию, например:
- IPsec с аутентификацией на основе сертификатов;
- TLS/SSL с взаимной аутентификацией (mutual TLS);
- SSH для защищённого удалённого доступа.
- Для использования сертификатной аутентификации можно развернуть и поддерживать собственную PKI или использовать доверенные удостоверяющие центры для выдачи сертификатов как серверам, так и клиентам;
- Организация защищённых каналов связи с использованием VPN-решений, поддерживающих двухстороннюю аутентификацию (например, на базе сертификатов).
Класс используемых средств — средства криптографической защиты каналов связи (VPN-шлюзы), инфраструктура открытых ключей (PKI).
Примеры таких средств:
- Иностранные: Cisco AnyConnect, Palo Alto GlobalProtect и пр.
- Российские сертифицированные (ФСТЭК): ViPNet Coordinator, «Континент 4» (VPN) и др.
- Открытый код: OpenVPN, WireGuard (с внешним PKI) и др.
- Схемы потоков данных и схемы сети организации;
- Конфигурация VPN, PKI: используемые протоколы, параметры шифрования, режим взаимной аутентификации.
- Выгрузка/список сертификатов сторон соединения и срок их действия.
- Итоги интервью с администратором каналов связи.
- Реализована только односторонняя аутентификация (клиент проверяет сервер, обратной проверки нет).
- Не все неконтролируемые каналы (в т. ч. резервные) защищены — часть трафика идёт в открытом виде.
- Используются устаревшие/слабые криптографические протоколы (не соответствующие текущим требованиям).
Не выявлены.
Не выявлены.