Куда я попал?
ГОСТ Р № 57580.1-2017 от 01.01.2018
Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 8. Требования к организации и управлению защитой информации
РЗИ.14
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
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:
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:
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:
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.
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 12.3.3
12.3.3
Defined Approach Requirements:
Cryptographic cipher suites and protocols in use are documented and reviewed at least once every 12 months, including at least the following:
Defined Approach Requirements:
Cryptographic cipher suites and protocols in use are documented and reviewed at least once every 12 months, including at least the following:
- An up-to-date inventory of all cryptographic cipher suites and protocols in use, including purpose and where used.
- Active monitoring of industry trends regarding continued viability of all cryptographic cipher suites and protocols in use.
- A documented strategy to respond to anticipated changes in cryptographic vulnerabilities.
Customized Approach Objective:
The entity is able to respond quickly to any vulnerabilities in cryptographic protocols or algorithms, where those vulnerabilities affect protection of cardholder data.
Applicability Notes:
The requirement applies to all cryptographic suites and protocols used to meet PCI DSS requirements.
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
Defined Approach Testing Procedures:
The entity is able to respond quickly to any vulnerabilities in cryptographic protocols or algorithms, where those vulnerabilities affect protection of cardholder data.
Applicability Notes:
The requirement applies to all cryptographic suites and protocols used to meet PCI DSS requirements.
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
Defined Approach Testing Procedures:
- 12.3.3 Examine documentation for cryptographic suites and protocols in use and interview personnel to verify the documentation and review is in accordance with all elements specified in this requirement.
Purpose:
Protocols and encryption strengths may quickly change or be deprecated due to identification of vulnerabilities or design flaws. In order to support current and future data security needs, entities need to know where cryptography is used and understand how they would be able to respond rapidly to changes impacting the strength of their cryptographic implementations.
Good Practice:
Cryptographic agility is important to ensure an alternative to the original encryption method or cryptographic primitive is available, with plans to upgrade to the alternative without significant change to system infrastructure. For example, if the entity is aware of when protocols or algorithms will be deprecated by standards bodies, it can make proactive plans to upgrade before the deprecation is impactful to operations.
Definitions:
“Cryptographic agility” refers to the ability to monitor and manage the encryption and related verification technologies deployed across an organization.
Further Information:
Refer to NIST SP 800-131a, Transitioning the Use of Cryptographic Algorithms and Key Lengths.
Protocols and encryption strengths may quickly change or be deprecated due to identification of vulnerabilities or design flaws. In order to support current and future data security needs, entities need to know where cryptography is used and understand how they would be able to respond rapidly to changes impacting the strength of their cryptographic implementations.
Good Practice:
Cryptographic agility is important to ensure an alternative to the original encryption method or cryptographic primitive is available, with plans to upgrade to the alternative without significant change to system infrastructure. For example, if the entity is aware of when protocols or algorithms will be deprecated by standards bodies, it can make proactive plans to upgrade before the deprecation is impactful to operations.
Definitions:
“Cryptographic agility” refers to the ability to monitor and manage the encryption and related verification technologies deployed across an organization.
Further Information:
Refer to NIST SP 800-131a, Transitioning the Use of Cryptographic Algorithms and Key Lengths.
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:
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.
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.
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 во время передачи по открытым сетям общего пользования, подтверждаются как действительные, срок действия которых не истек и не аннулирован. Этот бюллетень является наилучшей практикой до даты его вступления в силу; подробности см. в примечаниях к применению ниже.
- Используемый протокол поддерживает только безопасные версии или конфигурации и не поддерживает резервное копирование или использование небезопасных версий, алгоритмов, размеров ключей или реализаций.
- Надежность шифрования соответствует используемой методологии шифрования.
Цель Индивидуального подхода:
Открытый текст 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 на основе браузера доверие к сертификату часто можно проверить, нажав на значок блокировки, который появляется рядом с адресной строкой.
Примеры:
Открытые общедоступные сети включают, но не ограничиваются ими:
Конфиденциальная информация должна быть зашифрована во время передачи по сетям общего пользования, поскольку злоумышленнику легко и часто перехватывать и/или перенаправлять данные во время передачи.
Надлежащая практика:
Схемы сети и потоков данных, определенные в требовании 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)".
С рекомендациями поставщиков и лучшими отраслевыми практиками можно ознакомиться для получения информации о надлежащей надежности шифрования, специфичной для используемой методологии шифрования.
Для получения дополнительной информации о надежной криптографии и безопасных протоколах см. Отраслевые стандарты и рекомендации, такие как NIST SP 800-52 и SP 800-57.
Дополнительные сведения о доверенных ключах и сертификатах см. в Руководстве NIST по практике кибербезопасности Специальная публикация 1800-16 "Защита веб-транзакций: Управление сертификатами сервера безопасности транспортного уровня (TLS)".
Requirement 12.3.3
12.3.3
Определенные Требования к Подходу:
Используемые наборы криптографических шифров и протоколы документируются и пересматриваются не реже одного раза в 12 месяцев, включая, по крайней мере, следующее:
Определенные Требования к Подходу:
Используемые наборы криптографических шифров и протоколы документируются и пересматриваются не реже одного раза в 12 месяцев, включая, по крайней мере, следующее:
- Актуальный перечень всех используемых наборов криптографических шифров и протоколов, включая назначение и место использования.
- Активный мониторинг отраслевых тенденций в отношении сохранения жизнеспособности всех используемых наборов криптографических шифров и протоколов.
- Документированная стратегия реагирования на ожидаемые изменения в криптографических уязвимостях.
Цель Индивидуального подхода:
Организация способна быстро реагировать на любые уязвимости в криптографических протоколах или алгоритмах, если эти уязвимости влияют на защиту данных о держателях карт.
Примечания по применению:
Это требование распространяется на все криптографические наборы и протоколы, используемые для удовлетворения требований PCI DSS.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
Организация способна быстро реагировать на любые уязвимости в криптографических протоколах или алгоритмах, если эти уязвимости влияют на защиту данных о держателях карт.
Примечания по применению:
Это требование распространяется на все криптографические наборы и протоколы, используемые для удовлетворения требований PCI DSS.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
- 12.3.3 Изучите документацию по используемым криптографическим наборам и протоколам и опросите персонал, чтобы убедиться, что документация и проверка соответствуют всем элементам, указанным в этом требовании.
Цель:
Протоколы и сильные стороны шифрования могут быстро измениться или устареть из-за выявления уязвимостей или недостатков дизайна. Чтобы удовлетворить текущие и будущие потребности в защите данных, организации должны знать, где используется криптография, и понимать, как они смогут быстро реагировать на изменения, влияющие на надежность их криптографических реализаций.
Надлежащая практика:
Криптографическая гибкость важна для обеспечения доступности альтернативы оригинальному методу шифрования или криптографическому примитиву, при этом планируется перейти на альтернативу без существенных изменений в инфраструктуре системы. Например, если организация осведомлена о том, когда протоколы или алгоритмы будут признаны устаревшими органами по стандартизации, она может составить упреждающие планы обновления до того, как устаревание повлияет на операции.
Определения:
“Криптографическая гибкость” относится к способности отслеживать и управлять технологиями шифрования и связанными с ними технологиями проверки, развернутыми в организации.
Дополнительная информация:
Обратитесь к NIST SP 800-131a, Переход к использованию криптографических алгоритмов и длин ключей.
Протоколы и сильные стороны шифрования могут быстро измениться или устареть из-за выявления уязвимостей или недостатков дизайна. Чтобы удовлетворить текущие и будущие потребности в защите данных, организации должны знать, где используется криптография, и понимать, как они смогут быстро реагировать на изменения, влияющие на надежность их криптографических реализаций.
Надлежащая практика:
Криптографическая гибкость важна для обеспечения доступности альтернативы оригинальному методу шифрования или криптографическому примитиву, при этом планируется перейти на альтернативу без существенных изменений в инфраструктуре системы. Например, если организация осведомлена о том, когда протоколы или алгоритмы будут признаны устаревшими органами по стандартизации, она может составить упреждающие планы обновления до того, как устаревание повлияет на операции.
Определения:
“Криптографическая гибкость” относится к способности отслеживать и управлять технологиями шифрования и связанными с ними технологиями проверки, развернутыми в организации.
Дополнительная информация:
Обратитесь к NIST SP 800-131a, Переход к использованию криптографических алгоритмов и длин ключей.
Requirement 4.2.2
4.2.2
Определенные Требования к Подходу:
PAN защищен надежной криптографией всякий раз, когда он отправляется с помощью технологий обмена сообщениями конечного пользователя.
Цель Индивидуального подхода:
Открытый текст PAN не может быть прочитан или перехвачен из передач с использованием технологий обмена сообщениями конечных пользователей.
Примечания по применению:
Это требование также применяется, если клиент или другая третья сторона запрашивает, чтобы PAN был отправлен им с помощью технологий обмена сообщениями конечного пользователя.
Могут возникнуть ситуации, когда организация получает незапрашиваемые данные о держателях карт по небезопасному каналу связи, который не предназначен для передачи конфиденциальных данных. В этой ситуации организация может выбрать либо включить канал в область своего CDE и защитить его в соответствии с PCI DSS, либо удалить данные о держателях карт и принять меры для предотвращения использования канала для данных о держателях карт.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
PAN защищен надежной криптографией всякий раз, когда он отправляется с помощью технологий обмена сообщениями конечного пользователя.
Цель Индивидуального подхода:
Открытый текст PAN не может быть прочитан или перехвачен из передач с использованием технологий обмена сообщениями конечных пользователей.
Примечания по применению:
Это требование также применяется, если клиент или другая третья сторона запрашивает, чтобы PAN был отправлен им с помощью технологий обмена сообщениями конечного пользователя.
Могут возникнуть ситуации, когда организация получает незапрашиваемые данные о держателях карт по небезопасному каналу связи, который не предназначен для передачи конфиденциальных данных. В этой ситуации организация может выбрать либо включить канал в область своего CDE и защитить его в соответствии с PCI DSS, либо удалить данные о держателях карт и принять меры для предотвращения использования канала для данных о держателях карт.
Определенные Процедуры Тестирования Подхода:
- 4.2.2.a Изучите документированные политики и процедуры, чтобы убедиться, что процессы определены для защиты PAN с помощью надежной криптографии при отправке по технологиям обмена сообщениями конечного пользователя.
- 4.2.2.b Изучите системные конфигурации и документацию поставщика, чтобы убедиться, что PAN защищен надежной криптографией всякий раз, когда он отправляется через технологии обмена сообщениями конечного пользователя.
Цель:
Технологии обмена сообщениями с конечными пользователями обычно могут быть легко перехвачены путем перехвата пакетов во время доставки по внутренним и общедоступным сетям.
Надлежащая практика:
Использование технологии обмена сообщениями с конечным пользователем для отправки PAN следует рассматривать только в тех случаях, когда существует определенная бизнес-потребность.
Примеры:
Электронная почта, мгновенные сообщения, SMS и чат являются примерами типа технологии обмена сообщениями с конечным пользователем, к которой относится это требование.
Технологии обмена сообщениями с конечными пользователями обычно могут быть легко перехвачены путем перехвата пакетов во время доставки по внутренним и общедоступным сетям.
Надлежащая практика:
Использование технологии обмена сообщениями с конечным пользователем для отправки PAN следует рассматривать только в тех случаях, когда существует определенная бизнес-потребность.
Примеры:
Электронная почта, мгновенные сообщения, SMS и чат являются примерами типа технологии обмена сообщениями с конечным пользователем, к которой относится это требование.
Положение Банка России № 757-П от 20.04.2021 "Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций":
1.3.
1.3. В случае наличия в технической документации на СКЗИ требований к оценке влияния аппаратных, программно-аппаратных и программных средств сети (системы) конфиденциальной связи, совместно с которыми предполагается штатное функционирование СКЗИ, на выполнение предъявляемых к ним требований некредитные финансовые организации должны проводить указанную оценку в соответствии с Положением ПКЗ-2005 по техническому заданию, согласованному с федеральным органом исполнительной власти в области обеспечения безопасности.
В случае если некредитная финансовая организация применяет СКЗИ российского производства, СКЗИ должны иметь сертификаты соответствия федерального органа исполнительной власти в области обеспечения безопасности.
Безопасность процессов изготовления криптографических ключей СКЗИ должна обеспечиваться комплексом технологических мер защиты информации, организационных мер защиты информации и технических средств защиты информации в соответствии с технической документацией на СКЗИ.
В случае если некредитная финансовая организация применяет СКЗИ российского производства, СКЗИ должны иметь сертификаты соответствия федерального органа исполнительной власти в области обеспечения безопасности.
Безопасность процессов изготовления криптографических ключей СКЗИ должна обеспечиваться комплексом технологических мер защиты информации, организационных мер защиты информации и технических средств защиты информации в соответствии с технической документацией на СКЗИ.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.