Приказ ФАПСИ № 152 от 13.06.2001

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). 

3.10 Реализовано шифрование чувствительных данных при передаче
Примеры решений: Transport Layer Security (TLS), Open Secure Shell (OpenSSH).

4.2.1
Defined Approach Requirements: 
Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open, public networks:

Customized Approach Objective:
Cleartext PAN cannot be read or intercepted from any transmissions over open, public networks. 

Defined Approach Testing Procedures:

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: 

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. 

4.2.1
Определенные Требования к Подходу:
Надежная криптография и протоколы безопасности реализованы следующим образом для защиты PAN во время передачи по открытым общедоступным сетям:

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

Определенные Процедуры Тестирования Подхода:

Цель:
Конфиденциальная информация должна быть зашифрована во время передачи по сетям общего пользования, поскольку злоумышленнику легко и часто перехватывать и/или перенаправлять данные во время передачи.

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

Примеры:
Открытые общедоступные сети включают, но не ограничиваются ими:

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