Куда я попал?
SECURITM это SGRC система, ? автоматизирующая процессы в службах информационной безопасности. SECURITM помогает построить и управлять ИСПДн, КИИ, ГИС, СМИБ/СУИБ, банковскими системами защиты.
А еще SECURITM это место для обмена опытом и наработками для служб безопасности.

NIST Cybersecurity Framework (RU)

Framework

PR.DS-2

Для проведения оценки соответствия по документу войдите в систему.

Похожие требования

CIS Critical Security Controls v8 (The 18 CIS CSC):
3.10
3.10 Encrypt Sensitive Data in Transit 
Encrypt sensitive data in transit. Example implementations can include: Transport Layer Security (TLS) and Open Secure Shell (OpenSSH). 
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ЗИС.4 ЗИС.4 Обеспечение доверенных канала, маршрута между администратором, пользователем и средствами защиты информации (функциями безопасности средств защиты информации)
ЗИС.3 ЗИС.3 Обеспечение защиты персональных данных от раскрытия, модификации и навязывания (ввода ложной информации) при ее передаче (подготовке к передаче) по каналам связи, имеющим выход за пределы контролируемой зоны, в том числе беспроводным каналам связи
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
3.10
3.10 Реализовано шифрование чувствительных данных при передаче
Примеры решений: Transport Layer Security (TLS), Open Secure Shell (OpenSSH).
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 4.2.1
4.2.1
Defined Approach Requirements: 
Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open, public networks:
  • Only trusted keys and certificates are accepted.
  • Certificates used to safeguard PAN during transmission over open, public networks are confirmed as valid and are not expired or revoked. This bullet is a best practice until its effective date; refer to applicability notes below for details.
  • The protocol in use supports only secure versions or configurations and does not support fallback to, or use of insecure versions, algorithms, key sizes, or implementations.
  • The encryption strength is appropriate for the encryption methodology in use. 
Customized Approach Objective:
Cleartext PAN cannot be read or intercepted from any transmissions over open, public networks. 

Defined Approach Testing Procedures:
  • 4.2.1.a Examine documented policies and procedures and interview personnel to verify processes are defined to include all elements specified in this requirement. 
  • 4.2.1.b Examine system configurations to verify that strong cryptography and security protocols are implemented in accordance with all elements specified in this requirement. 
  • 4.2.1.c Examine cardholder data transmissions to verify that all PAN is encrypted with strong cryptography when it is transmitted over open, public networks. 
  • 4.2.1.d Examine system configurations to verify that keys and/or certificates that cannot be verified as trusted are rejected. 
Purpose:
Sensitive information must be encrypted during transmission over public networks because it is easy and common for a malicious individual to intercept and/or divert data while in transit. 

Good Practice:
The network and data-flow diagrams defined in Requirement 1 are useful resources for identifying all connection points where account data is transmitted or received over open, public networks. 
While not required, it is considered a good practice for entities to also encrypt PAN over their internal networks, and for entities to establish any new network implementations with encrypted communications. 
PAN transmissions can be protected by encrypting the data before it is transmitted, or by encrypting the session over which the data is transmitted, or both. While it is not required that strong cryptography be applied at both the data level and the session level, it is strongly recommended. If encrypted at the data level, the cryptographic keys used for protecting the data can be managed in accordance with Requirements 3.6 and 3.7. If the data is encrypted at the session level, designated key custodians should be assigned responsibility for managing transmission keys and certificates. 
Some protocol implementations (such as SSL, SSH v1.0, and early TLS) have known vulnerabilities that an attacker can use to gain access to the cleartext data. It is critical that entities maintain awareness of industry-defined deprecation dates for the cipher suites they are using and are prepared to migrate to newer versions or protocols when older ones are no longer deemed secure. 
Verifying that certificates are trusted helps ensure the integrity of the secure connection. To be considered trusted, a certificate should be issued from a trusted source, such as a trusted certificate authority (CA), and not be expired. Up-to-date Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) can be used to validate certificates. 
Techniques to validate certificates may include certificate and public key pinning, where the trusted certificate or a public key is pinned either during development or upon its first use. Entities can also confirm with developers or review source code to ensure that clients and servers reject connections if the certificate is bad. 
For browser-based TLS certificates, certificate trust can often be verified by clicking on the lock icon that appears next to the address bar. 

Examples:
 Open, public networks include, but are not limited to: 
  • The Internet and
  • Wireless technologies, including Wi-Fi, Bluetooth, cellular technologies, and satellite communications. 
Further Information:
Vendor recommendations and industry best practices can be consulted for information about the proper encryption strength specific to the encryption methodology in use. 
For more information about strong cryptography and secure protocols, see industry standards and best practices such as NIST SP 800-52 and SP 800-57. 
For more information about trusted keys and certificates, see NIST Cybersecurity Practice Guide Special Publication 1800-16, Securing Web Transactions: Transport Layer Security (TLS) Server Certificate Management. 
Requirement 4.2.2
4.2.2
Defined Approach Requirements: 
PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies. 

Customized Approach Objective:
Cleartext PAN cannot be read or intercepted from transmissions using end-user messaging technologies. 

Applicability Notes:
This requirement also applies if a customer, or other third-party, requests that PAN is sent to them via end-user messaging technologies. 
There could be occurrences where an entity receives unsolicited cardholder data via an insecure communication channel that was not intended for transmissions of sensitive data. In this situation, the entity can choose to either include the channel in the scope of their CDE and secure it according to PCI DSS or delete the cardholder data and implement measures to prevent the channel from being used for cardholder data. 

Defined Approach Testing Procedures:
  • 4.2.2.a Examine documented policies and procedures to verify that processes are defined to secure PAN with strong cryptography whenever sent over end-user messaging technologies. 
  • 4.2.2.b Examine system configurations and vendor documentation to verify that PAN is secured with strong cryptography whenever it is sent via enduser messaging technologies. 
Purpose:
End-user messaging technologies typically can be easily intercepted by packet-sniffing during delivery across internal and public networks. 

Good Practice:
The use of end-user messaging technology to send PAN should only be considered where there is a defined business need. 

Examples:
E-mail, instant messaging, SMS, and chat are examples of the type of end-user messaging technology that this requirement refers to. 
Guideline for a healthy information system v.2.0 (EN):
21 STANDARD
/STANDARD
Although security is no longer optional today, this has not always been the case. This is why numerous network protocols had to evolve to integrate this component and respond to the confidentiality and integrity requirements that exchanging data requires. Secure network protocols must be used as soon as possible, whether on public networks (the Internet for example) or on the organization’s internal network. 

Although it may be difficult to provide an exhaustive list, the most common protocols rely on the use of TLS and are often identifiable by the addition of the letter "s" (for secure) in the protocol acronym. As an example HTTPS for web browsing or IMAPS, SMTPS or POP3S for email. 

Other protocols were designed securely from their creation to replace prior, insecure protocols. As an example SSH (Secure SHell) which came to replace the TELNET and RLOGIN historic communication protocols.. 
18 STANDARD
/STANDARD
The Internet is a network from which it is almost impossible to obtain guarantees as to the way that data will take when you send it through this medium. It is, therefore, entirely possible that a hacker will be on the pathway of data travelling between two correspondents. 

All the data sent by email or uploaded to online hosting tools (Cloud) is therefore vulnerable. Therefore, its systematic encryption must be undertaken before sending it to a correspondent or uploading it. 

Passing on confidential information (password, key, etc.) that is therefore able to decrypt data, if required, must be carried out by a trusted channel or, failing that, a different channel from the data transmission channel. Therefore, although the encrypted data is sent by mail, handing over the password by hand or, failing that, over the phone must be favoured. 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.13.2.3
A.13.2.3 Электронный обмен сообщениями 
Мера обеспечения информационной безопасности: Следует обеспечивать соответствующую защиту информации при электронном обмене сообщениями 
A.13.2.1
A.13.2.1 Политики и процедуры передачи информации 
Мера обеспечения информационной безопасности: Должны существовать формализованные политики и процедуры передачи информации, а также соответствующие меры обеспечения информационной безопасности, обеспечивающие защиту информации, передаваемой с использованием всех видов средств связи 
A.13.1.1
A.13.1.1 Меры обеспечения информационной безопасности для сетей 
Мера обеспечения информационной безопасности: Сети должны управляться и контролироваться для обеспечения защиты информации систем и приложений 
A.14.1.3
A.14.1.3 Защита транзакций прикладных сервисов 
Мера обеспечения информационной безопасности: Информацию, используемую в транзакциях прикладных сервисов, следует защищать для предотвращения неполной передачи, ложной маршрутизации, несанкционированного изменения, раскрытия, дублирования или воспроизведения сообщений 
A.8.2.3
A.8.2.3 Обращение с активами 
Мера обеспечения информационной безопасности: Должны быть разработаны и реализованы процедуры обращения с активами в соответствии с принятой в организации системой категорирования информации.
A.14.1.2
A.14.1.2 Обеспечение безопасности прикладных сервисов, предоставляемых с использованием сетей общего пользования 
Мера обеспечения информационной безопасности: Информация, используемая в прикладных сервисах и передаваемая по сетям общего пользования, должна быть защищена от мошеннической деятельности, оспаривания договоров, а также несанкционированного раскрытия и модификации 
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 15.7 CSC 15.7 Leverage the Advanced Encryption Standard (AES) to Encrypt Wireless Data
Leverage the Advanced Encryption Standard (AES) to encrypt wireless data in transit.
CSC 14.4 CSC 14.4 Encrypt All Sensitive Information in Transit
Encrypt all sensitive information in transit.
Положение Банка России № 802-П от 25.07.2022 "О требованиях к защите информации в платежной системе Банка России":
П. 7 п.п. 3
7.3. Участники СБП, ОПКЦ СБП и ОУИО СБП должны определить во внутренних документах состав и правила применения технологических мер защиты информации, используемых для контроля целостности и подтверждения подлинности электронных сообщений и информационных сообщений (при их наличии), при осуществлении перевода денежных средств с использованием сервиса быстрых платежей на этапах формирования (подготовки), обработки, передачи и хранения электронных сообщений и информационных сообщений (при их наличии).
Участники СБП, ОПКЦ СБП и ОУИО СБП должны применять технологические меры защиты информации, используемые для контроля целостности и подтверждения подлинности электронных сообщений и информационных сообщений на этапах их формирования (подготовки), обработки, передачи и хранения (при их наличии).
П. 14.4
14.4. ОПКЦ СБП должен обеспечивать защиту электронных сообщений при их передаче в Банк России посредством:
  • обработки электронных сообщений и контроля реквизитов электронных сообщений в информационной инфраструктуре ОПКЦ СБП в соответствии с пунктом 2 приложения к настоящему Положению;
  • использования двух усиленных электронных подписей - электронной подписи, применяемой в контуре обработки электронных сообщений, и электронной подписи, применяемой в контуре контроля реквизитов электронных сообщений, - для контроля целостности и подтверждения подлинности электронных сообщений;
  • шифрования электронных сообщений на прикладном уровне в соответствии с эталонной моделью взаимосвязи открытых систем, предусмотренной пунктом 1.7 раздела 1 ГОСТ Р ИСО/МЭК 7498-1-99, с использованием СКЗИ, прошедших процедуру оценки соответствия требованиям, установленным федеральным органом исполнительной власти в области обеспечения безопасности;
  • применения средств защиты информации, реализующих двухстороннюю аутентификацию и шифрование информации на уровне звена данных или сетевом уровне в соответствии с эталонной моделью взаимосвязи открытых систем, предусмотренной пунктом 1.7 раздела 1 ГОСТ Р ИСО/МЭК 7498-1-99, прошедших процедуру оценки соответствия требованиям, установленным федеральным органом исполнительной власти в области обеспечения безопасности.
П. 14.3
14.3. Участники ССНП должны обеспечивать защиту электронных сообщений при их передаче в Банк России посредством:
  • формирования электронных сообщений и контроля реквизитов электронных сообщений с использованием объектов информационной инфраструктуры участника ССНП в соответствии с пунктом 1 приложения к настоящему Положению, в котором установлены Правила материально-технического обеспечения формирования электронных сообщений и контроля реквизитов электронных сообщений в информационной инфраструктуре участника ССНП, а также правила материально-технического обеспечения обработки электронных сообщений и контроля реквизитов электронных сообщений в информационной инфраструктуре ОПКЦ СБП в соответствии с частью пятой статьи 5 Федерального закона от 2 декабря 1990 года N 395-I "О банках и банковской деятельности" (в редакции Федерального закона от 3 февраля 1996 года N 17-ФЗ);
  • использования двух усиленных электронных подписей - электронной подписи, применяемой в контуре формирования электронных сообщений, и электронной подписи, применяемой в контуре контроля реквизитов электронных сообщений, - для контроля целостности и подтверждения подлинности электронных сообщений;
  • применения третьего варианта защиты, указанного в Альбоме электронных сообщений, ведение которого осуществляется Банком России в соответствии с абзацами вторым, третьим и подпунктом 5.2.1 пункта 5.2 Положения Банка России N 732-П;
  • шифрования электронных сообщений на прикладном уровне в соответствии с эталонной моделью взаимосвязи открытых систем, предусмотренной пунктом 1.7 раздела 1 ГОСТ Р ИСО/МЭК 7498-1-99, с использованием СКЗИ, прошедших процедуру оценки соответствия требованиям, установленным федеральным органом исполнительной власти в области обеспечения безопасности;
  • применения средств защиты информации, реализующих двухстороннюю аутентификацию и шифрование информации на уровне звена данных или сетевом уровне в соответствии с эталонной моделью взаимосвязи открытых систем, предусмотренной пунктом 1.7 раздела 1 ГОСТ Р ИСО/МЭК 7498-1-99, прошедших процедуру оценки соответствия требованиям, установленным федеральным органом исполнительной власти в области обеспечения безопасности.
П. 14.2
14.2. Участники СБП и ОПКЦ СБП должны обеспечивать защиту электронных сообщений при передаче между участниками СБП и ОПКЦ СБП посредством:
  • использования усиленной электронной подписи для контроля целостности и подтверждения подлинности электронных сообщений, состав которых определен договором об оказании операционных услуг, услуг платежного клиринга при осуществлении перевода денежных средств с использованием сервиса быстрых платежей, заключенным между участником СБП и ОПКЦ СБП в соответствии с частью 1 статьи 17, частью 1 статьи 18 Федерального закона от 27 июня 2011 года N 161-ФЗ (далее - договор об оказании услуг между участником СБП и ОПКЦ СБП);
  • шифрования электронных сообщений на прикладном уровне в соответствии с эталонной моделью взаимосвязи открытых систем, предусмотренной пунктом 1.7 раздела 1 государственного стандарта Российской Федерации ГОСТ Р ИСО/МЭК 7498-1-99 "Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель", принятого постановлением Государственного комитета Российской Федерации по стандартизации и метрологии от 18 марта 1999 года N 78  и введенного в действие 1 января 2000 года (далее - ГОСТ Р ИСО/МЭК 7498-1-99), с использованием СКЗИ, прошедших процедуру оценки соответствия требованиям, установленным федеральным органом исполнительной власти в области обеспечения безопасности;
  • применения средств защиты информации, посредством использования которых реализуется двухсторонняя аутентификация и шифрование информации на уровне представления или ниже, в соответствии с эталонной моделью взаимосвязи открытых систем, предусмотренной пунктом 1.7 раздела 1 ГОСТ Р ИСО/МЭК 7498-1-99, прошедших процедуру оценки соответствия требованиям, установленным федеральным органом исполнительной власти в области обеспечения безопасности.
Участники СБП, ОПКЦ СБП и ОУИО СБП должны обеспечивать защиту электронных сообщений при их передаче между ОПКЦ СБП, участниками СБП и ОУИО СБП в соответствии с требованиями, установленными абзацами вторым - четвертым настоящего подпункта.
Участники СБП должны реализовать технологии подготовки, обработки и передачи электронных сообщений и защищаемой информации, обеспечивающие проверку соответствия (сверку) реквизитов исходящих в адрес ОПКЦ СБП электронных сообщений с реквизитами соответствующих им входящих электронных сообщений клиентов участников СБП и реквизитами электронных сообщений, на основе которых участником СБП осуществляются операции по списанию денежных средств со счетов клиентов.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 4.2.1
4.2.1
Определенные Требования к Подходу:
Надежная криптография и протоколы безопасности реализованы следующим образом для защиты PAN во время передачи по открытым общедоступным сетям:
  • Принимаются только доверенные ключи и сертификаты.
  • Сертификаты, используемые для защиты PAN во время передачи по открытым сетям общего пользования, подтверждаются как действительные, срок действия которых не истек и не аннулирован. Этот бюллетень является наилучшей практикой до даты его вступления в силу; подробности см. в примечаниях к применению ниже.
  • Используемый протокол поддерживает только безопасные версии или конфигурации и не поддерживает резервное копирование или использование небезопасных версий, алгоритмов, размеров ключей или реализаций.
  • Надежность шифрования соответствует используемой методологии шифрования.
Цель Индивидуального подхода:
Открытый текст PAN не может быть прочитан или перехвачен из любых передач по открытым общедоступным сетям.

Определенные Процедуры Тестирования Подхода:
  • 4.2.1.a Изучите документированные политики и процедуры и опросите персонал, чтобы убедиться, что процессы определены так, чтобы включать все элементы, указанные в этом требовании.
  • 4.2.1.b Изучите системные конфигурации, чтобы убедиться, что надежная криптография и протоколы безопасности реализованы в соответствии со всеми элементами, указанными в этом требовании.
  • 4.2.1.c Проверяйте передачу данных о держателях карт, чтобы убедиться, что все данные зашифрованы с помощью надежной криптографии, когда они передаются по открытым общедоступным сетям.
  • 4.2.1.d Проверьте системные конфигурации, чтобы убедиться, что ключи и/или сертификаты, которые не могут быть проверены как доверенные, отклоняются.
Цель:
Конфиденциальная информация должна быть зашифрована во время передачи по сетям общего пользования, поскольку злоумышленнику легко и часто перехватывать и/или перенаправлять данные во время передачи.

Надлежащая практика:
Схемы сети и потоков данных, определенные в требовании 1, являются полезными ресурсами для определения всех точек подключения, где данные учетной записи передаются или принимаются по открытым общедоступным сетям.
Хотя это и не требуется, считается хорошей практикой для организаций также шифровать PAN по своим внутренним сетям, а для организаций устанавливать любые новые сетевые реализации с зашифрованными сообщениями.
Передача PAN может быть защищена путем шифрования данных перед их передачей или путем шифрования сеанса, по которому передаются данные, или и того, и другого. Хотя не требуется, чтобы надежная криптография применялась как на уровне данных, так и на уровне сеанса, настоятельно рекомендуется. Если данные зашифрованы на уровне данных, криптографическими ключами, используемыми для защиты данных, можно управлять в соответствии с требованиями 3.6 и 3.7. Если данные зашифрованы на уровне сеанса, назначенным хранителям ключей следует назначить ответственность за управление ключами передачи и сертификатами.
Некоторые реализации протоколов (такие как SSL, SSH v1.0 и ранние версии TLS) имеют известные уязвимости, которые злоумышленник может использовать для получения доступа к открытым текстовым данным. Крайне важно, чтобы организации были осведомлены об установленных в отрасли датах устаревания используемых ими наборов шифров и были готовы перейти на более новые версии или протоколы, когда старые больше не считаются безопасными.
Проверка того, что сертификаты являются доверенными, помогает обеспечить целостность защищенного соединения. Чтобы считаться доверенным, сертификат должен быть выдан из надежного источника, такого как доверенный центр сертификации (CA), и срок его действия не истек. Для проверки сертификатов можно использовать обновленные Списки отзыва сертификатов (CRL) или Протокол онлайн-статуса сертификата (OCSP).
Методы проверки сертификатов могут включать закрепление сертификата и открытого ключа, при котором доверенный сертификат или открытый ключ закрепляются либо во время разработки, либо при его первом использовании. Организации также могут подтвердить это у разработчиков или просмотреть исходный код, чтобы убедиться, что клиенты и серверы отклоняют подключения, если сертификат неисправен.
Для сертификатов TLS на основе браузера доверие к сертификату часто можно проверить, нажав на значок блокировки, который появляется рядом с адресной строкой.

Примеры:
Открытые общедоступные сети включают, но не ограничиваются ими:
  • Интернет и
  • Беспроводные технологии, включая Wi-Fi, Bluetooth, сотовые технологии и спутниковую связь.
Дополнительная информация:
С рекомендациями поставщиков и лучшими отраслевыми практиками можно ознакомиться для получения информации о надлежащей надежности шифрования, специфичной для используемой методологии шифрования.
Для получения дополнительной информации о надежной криптографии и безопасных протоколах см. Отраслевые стандарты и рекомендации, такие как NIST SP 800-52 и SP 800-57.
Дополнительные сведения о доверенных ключах и сертификатах см. в Руководстве NIST по практике кибербезопасности Специальная публикация 1800-16 "Защита веб-транзакций: Управление сертификатами сервера безопасности транспортного уровня (TLS)".
Requirement 4.2.2
4.2.2
Определенные Требования к Подходу:
PAN защищен надежной криптографией всякий раз, когда он отправляется с помощью технологий обмена сообщениями конечного пользователя.

Цель Индивидуального подхода:
Открытый текст PAN не может быть прочитан или перехвачен из передач с использованием технологий обмена сообщениями конечных пользователей.

Примечания по применению:
Это требование также применяется, если клиент или другая третья сторона запрашивает, чтобы PAN был отправлен им с помощью технологий обмена сообщениями конечного пользователя.
Могут возникнуть ситуации, когда организация получает незапрашиваемые данные о держателях карт по небезопасному каналу связи, который не предназначен для передачи конфиденциальных данных. В этой ситуации организация может выбрать либо включить канал в область своего CDE и защитить его в соответствии с PCI DSS, либо удалить данные о держателях карт и принять меры для предотвращения использования канала для данных о держателях карт.

Определенные Процедуры Тестирования Подхода:
  • 4.2.2.a Изучите документированные политики и процедуры, чтобы убедиться, что процессы определены для защиты PAN с помощью надежной криптографии при отправке по технологиям обмена сообщениями конечного пользователя.
  • 4.2.2.b Изучите системные конфигурации и документацию поставщика, чтобы убедиться, что PAN защищен надежной криптографией всякий раз, когда он отправляется через технологии обмена сообщениями конечного пользователя.
Цель:
Технологии обмена сообщениями с конечными пользователями обычно могут быть легко перехвачены путем перехвата пакетов во время доставки по внутренним и общедоступным сетям.

Надлежащая практика:
Использование технологии обмена сообщениями с конечным пользователем для отправки PAN следует рассматривать только в тех случаях, когда существует определенная бизнес-потребность.

Примеры:
Электронная почта, мгновенные сообщения, SMS и чат являются примерами типа технологии обмена сообщениями с конечным пользователем, к которой относится это требование.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
ЗИС.4 ЗИС.4 Обеспечение доверенных канала, маршрута между администратором, пользователем и средствами защиты информации (функциями безопасности средств защиты информации)
ЗИС.3 ЗИС.3 Обеспечение защиты информации от раскрытия, модификации и навязывания (ввода ложной информации) при ее передаче (подготовке к передаче) по каналам связи, имеющим выход за пределы контролируемой зоны, в том числе беспроводным каналам связи
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.14
А.5.14 Передача информации
Для всех видов средств передачи информации внутри организации и между организацией и другими сторонами должны действовать правила, процедуры или соглашения по передаче информации.
А.8.20
А.8.20 Сетевая безопасность
В целях защиты информации в системах и приложениях должны быть защищены, управляться и контролироваться сети и сетевые устройства.
Положение Банка России № 719-П от 04.06.2020 "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств":
Глава 4 п.1
4.1. Операторы услуг информационного обмена должны обеспечивать защиту информации при оказании операторам по переводу денежных средств услуг информационного обмена на основании договоров в отношении следующих операций:
  • осуществление переводов денежных средств с использованием электронных средств платежа на основании электронных сообщений клиентов операторов по переводу денежных средств;
  • осуществление переводов денежных средств с использованием электронных средств платежа на основании электронных сообщений иностранных поставщиков платежных услуг.
Глава 6 п. 2
6.2. ПКЦ при предоставлении услуг платежного клиринга должен обеспечивать защиту информации при осуществлении следующих операций:
  • выполнение процедур приема к исполнению электронных сообщений операторов по переводу денежных средств, включая проверку соответствия электронных сообщений операторов по переводу денежных средств установленным требованиям, определение достаточности денежных средств для исполнения электронных сообщений операторов по переводу денежных средств и определение платежных клиринговых позиций;
  • передача РЦ для исполнения электронных сообщений ПКЦ, принятых электронных сообщений операторов по переводу денежных средств;
  • направление операторам по переводу денежных средств извещений (подтверждений), касающихся приема к исполнению электронных сообщений операторов по переводу денежных средств, а также передача извещений (подтверждений), касающихся исполнения электронных сообщений операторов по переводу денежных средств.
Глава 6 п. 1
6.1. Операторы услуг платежной инфраструктуры, осуществляющие деятельность операционных центров (далее - ОЦ), при предоставлении операционных услуг должны обеспечивать защиту информации при осуществлении обмена электронными сообщениями между операторами по переводу денежных средств, между операторами по переводу денежных средств и их клиентами, операторами услуг платежной инфраструктуры, осуществляющими деятельность платежных клиринговых центров (далее - ПКЦ), операторами услуг платежной инфраструктуры, осуществляющими деятельность расчетных центров (далее - РЦ), между ПКЦ и РЦ.
SWIFT Customer Security Controls Framework v2022:
2 - 2.6 Operator Confidentiality and Integrity
2.6 Operator Session Confidentiality and Integrity
2 - 2.5A External Transmission Data Protection
2.5A External Transmission Data Protection
2 - 2.4A Back Office Data Flow Security
2.4A Back Office Data Flow Security
2 - 2.1 Internal Data Flow Security
2.1 Internal Data Flow Security
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ЗИС.19 ЗИС.19 Защита информации при ее передаче по каналам связи
ЗИС.20 ЗИС.20 Обеспечение доверенных канала, маршрута
NIST Cybersecurity Framework (EN):
PR.DS-2 PR.DS-2: Data-in-transit is protected
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ЗИС.19 ЗИС.19 Защита информации при ее передаче по каналам связи
ЗИС.20 ЗИС.20 Обеспечение доверенных канала, маршрута
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.8.20
А.8.20 Networks security
Networks and network devices shall be secured, managed and controlled to protect information in systems and applications.
А.5.14
А.5.14 Information transfer
Information transfer rules, procedures, or agreements shall be in place for all types of transfer facilities within the organization and between the organization and other parties.

Связанные защитные меры

Ничего не найдено