Куда я попал?
Framework № PCI DSS 4.0 от 01.03.2022
Payment Card Industry Data Security Standard (RU)
Requirement 4.2.1
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 8. Требования к организации и управлению защитой информации":
РЗИ.14
РЗИ.14 Применение СКЗИ, имеющих класс не ниже КС2 (в случаях, когда применение таких средств необходимо для нейтрализации угроз безопасности, определенных в модели угроз и нарушителей безопасности информации финансовой организации)
3-Н 2-Н 1-Т
3-Н 2-Н 1-Т
Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 7 п. 6 п.п. 4
7.6.4. В организациях БС РФ в связи с повышенными рисками нарушения ИБ при взаимодействии с сетью Интернет должны применяться защитные меры, в том числе межсетевые экраны, антивирусные средства, средства обнаружения вторжений, средства криптографической защиты информации, обеспечивающие, среди прочего, прием и передачу информации только в установленном формате и только для конкретной технологии.
Должны быть разработаны и введены в действие инструкции и рекомендации по использованию сети Интернет, учитывающие особенности банковских технологических процессов.
Должны быть определены и выполняться процедуры протоколирования посещения ресурсов сети Интернет работниками организации БС РФ. Данные о посещенных работниками организации БС РФ ресурсов сети Интернет должны быть доступны работникам службы ИБ.
Должны быть разработаны и введены в действие инструкции и рекомендации по использованию сети Интернет, учитывающие особенности банковских технологических процессов.
Должны быть определены и выполняться процедуры протоколирования посещения ресурсов сети Интернет работниками организации БС РФ. Данные о посещенных работниками организации БС РФ ресурсов сети Интернет должны быть доступны работникам службы ИБ.
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).
Encrypt sensitive data in transit. Example implementations can include: Transport Layer Security (TLS) and Open Secure Shell (OpenSSH).
NIST Cybersecurity Framework (RU):
PR.DS-2
PR.DS-2: Данные при передаче защищаются
Приказ ФАПСИ № 152 от 13.06.2001 "Инструкция об организации и обеспечении безопасности хранения, обработки и передачи по каналам связи с использованием средств криптографической защиты информации с ограниченным доступом, не содержащей сведений, составляющих государственную тайну":
Глава III п. 25
25. При необходимости передачи по техническим средствам связи служебных сообщений, касающихся организации и обеспечения безопасности хранения, обработки и передачи по каналам связи с использованием СКЗИ конфиденциальной информации, соответствующие указания необходимо передавать, только применяя СКЗИ. Передача по техническим средствам связи криптоключей не допускается, за исключением специально организованных систем с децентрализованным снабжением криптоключами.
Глава III п. 24
24. Для организации и обеспечения безопасности хранения, обработки и передачи по каналам связи конфиденциальной информации следует использовать СКЗИ, позволяющие реализовать принцип абонентского шифрования и предусматривающие запись криптоключей на электронные ключевые носители многократного (долговременного) использования (дискеты, компакт-диски (CD-ROM), Data Key, Smart Card, Touch Memory и т.п.).
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
3.10
3.10 Реализовано шифрование чувствительных данных при передаче
Примеры решений: Transport Layer Security (TLS), Open Secure Shell (OpenSSH).
Примеры решений: 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:
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.
Guideline for a healthy information system v.2.0 (EN):
25 STANDARD
/STANDARD
For operational needs, an organization can be required to establish a dedicated network interconnection with a supplier or customer (e.g.: managed services, electronic data interchange, financial flows, etc.)
This interconnection can be done by a link to a private network of the organization or directly online. In the latter case, it is advisable to establish a site to site tunnel, ideally IPsec, adhering to ANSSI’s recommendations.
The partner is, by default, considered as unsafe, so it is essential to carry out IP filtering with the assistance of a firewall as close as possible to the flows’ entrance into the organization’s network. The flow matrix (incoming and outgoing) must be strictly reduced to the operational need, maintained over time and the devices’ configuration must be in accordance with it.
For operational needs, an organization can be required to establish a dedicated network interconnection with a supplier or customer (e.g.: managed services, electronic data interchange, financial flows, etc.)
This interconnection can be done by a link to a private network of the organization or directly online. In the latter case, it is advisable to establish a site to site tunnel, ideally IPsec, adhering to ANSSI’s recommendations.
The partner is, by default, considered as unsafe, so it is essential to carry out IP filtering with the assistance of a firewall as close as possible to the flows’ entrance into the organization’s network. The flow matrix (incoming and outgoing) must be strictly reduced to the operational need, maintained over time and the devices’ configuration must be in accordance with it.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.13.2.1
A.13.2.1 Политики и процедуры передачи информации
Мера обеспечения информационной безопасности: Должны существовать формализованные политики и процедуры передачи информации, а также соответствующие меры обеспечения информационной безопасности, обеспечивающие защиту информации, передаваемой с использованием всех видов средств связи
Мера обеспечения информационной безопасности: Должны существовать формализованные политики и процедуры передачи информации, а также соответствующие меры обеспечения информационной безопасности, обеспечивающие защиту информации, передаваемой с использованием всех видов средств связи
A.14.1.3
A.14.1.3 Защита транзакций прикладных сервисов
Мера обеспечения информационной безопасности: Информацию, используемую в транзакциях прикладных сервисов, следует защищать для предотвращения неполной передачи, ложной маршрутизации, несанкционированного изменения, раскрытия, дублирования или воспроизведения сообщений
Мера обеспечения информационной безопасности: Информацию, используемую в транзакциях прикладных сервисов, следует защищать для предотвращения неполной передачи, ложной маршрутизации, несанкционированного изменения, раскрытия, дублирования или воспроизведения сообщений
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 14.4
CSC 14.4 Encrypt All Sensitive Information in Transit
Encrypt all sensitive information in transit.
Encrypt all sensitive information in transit.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.14
А.5.14 Передача информации
Для всех видов средств передачи информации внутри организации и между организацией и другими сторонами должны действовать правила, процедуры или соглашения по передаче информации.
Для всех видов средств передачи информации внутри организации и между организацией и другими сторонами должны действовать правила, процедуры или соглашения по передаче информации.
SWIFT Customer Security Controls Framework v2022:
2 - 2.5A External Transmission Data Protection
2.5A External Transmission Data Protection
Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":
п. 1.4.
1.4. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны обеспечивать организацию учета и контроля следующих элементов (при их наличии) (далее при совместном упоминании - критичная архитектура):
- технологических процессов, указанных в приложении к настоящему Положению, реализуемых непосредственно некредитной финансовой организацией;
- подразделений (работников) некредитной финансовой организации, ответственных за разработку технологических процессов, указанных в приложении к настоящему Положению, поддержание их выполнения, их реализацию;
- объектов информационной инфраструктуры некредитной финансовой организации, задействованных при выполнении каждого технологического процесса, указанного в приложении к настоящему Положению, реализуемого непосредственно некредитной финансовой организацией;
- технологических участков предусмотренных приложением к настоящему Положению технологических процессов, указанных в пункте 1.10 Положения Банка России от 20 апреля 2021 года N 757-П (далее - технологические участки технологических процессов), реализуемых непосредственно некредитной финансовой организацией;
- технологических процессов, указанных в приложении к настоящему Положению, технологических участков технологических процессов, реализуемых внешними контрагентами, оказывающими услуги в сфере информационных технологий, связанные с выполнением технологических процессов (далее - поставщики услуг);
- работников некредитной финансовой организации или иных лиц, осуществляющих физический и (или) логический доступ, или программных сервисов, осуществляющих логический доступ к объектам информационной инфраструктуры некредитной финансовой организации (далее - субъекты доступа), задействованных при выполнении каждого технологического процесса, указанного в приложении к настоящему Положению;
- взаимосвязей и взаимозависимостей между некредитной финансовой организацией и иными некредитными финансовыми организациями, кредитными организациями и поставщиками услуг в рамках выполнения технологических процессов, указанных в приложении к настоящему Положению (далее при совместном упоминании - участники технологического процесса);
- каналов передачи защищаемой информации, указанной в пункте 1.1 Положения Банка России от 20 апреля 2021 года N 757-П, обрабатываемой и передаваемой в рамках технологических процессов, указанных в приложении к настоящему Положению, участниками технологического процесса.
Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в отношении своих элементов критичной архитектуры, являющихся значимыми объектами критической информационной инфраструктуры в соответствии с пунктом 3 статьи 2 Федерального закона от 26 июля 2017 года N 187-ФЗ "О безопасности критической информационной инфраструктуры Российской Федерации" (Собрание законодательства Российской Федерации, 2017, N 31, ст. 4736) (далее - Федеральный закон от 26 июля 2017 года N 187-ФЗ), должны выполнять требования по обеспечению безопасности значимых объектов критической информационной инфраструктуры, установленные в соответствии с пунктом 4 части 3 статьи 6 Федерального закона от 26 июля 2017 года N 187-ФЗ (Собрание законодательства Российской Федерации, 2017, N 31, ст. 4736).
В целях организации учета и контроля состава технологических процессов, указанных в приложении к настоящему Положению, технологических участков технологических процессов, реализуемых поставщиками услуг, некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, должны обеспечивать ведение реестра указанных технологических процессов и технологических участков технологических процессов в соответствии со своими внутренними документами.
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
14.1.3
14.1.3 Защита транзакций прикладных сервисов
Мера обеспечения ИБ
Информацию, используемую в транзакциях прикладных сервисов, следует защищать для предотвращения неполной передачи, ложной маршрутизации, несанкционированного изменения, раскрытия, дублирования или воспроизведения сообщений.
Руководство по применению
Вопросы безопасности для транзакций прикладных сервисов должны включать следующее:
- a) использование электронных подписей каждой из сторон, участвующих в транзакции;
- b) все аспекты транзакции, то есть обеспечение того, что:
- секретная аутентификационная информация пользователей с каждой стороны проверена и действительна;
- транзакция остается конфиденциальной;
- сохраняется конфиденциальность всех вовлеченных сторон;
- c) канал связи между всеми вовлеченными сторонами защищен;
- d) протоколы, используемые для связи между всеми вовлеченными сторонами, защищены;
- e) обеспечение того, чтобы хранение деталей транзакции находилось за пределами какой-либо общедоступной среды, например в хранилище интрасети организации, которое не доступно непосредственно из сети Интернет;
- f) если используется доверенный орган (например, для целей выдачи и поддержки электронных подписей или цифровых сертификатов), обеспечение безопасности интегрируется и становится частью процесса управления сертификатами/подписями на протяжении всего жизненного цикла такого процесса.
Дополнительная информация
Объем принятых мер обеспечения ИБ должен соответствовать уровню риска, связанного с каждой формой транзакции прикладных сервисов.
Транзакции должны соответствовать юридическим и нормативным требованиям той юрисдикции, где их формируют, обрабатывают, завершают или хранят.
13.2.1
13.2.1 Политики и процедуры передачи информации
Мера обеспечения ИБ
Должны существовать формализованные политики и процедуры передачи информации, а также соответствующие меры, обеспечивающие безопасность информации, передаваемой с использованием всех видов средств связи.
Руководство по применению
Процедуры и меры обеспечения ИБ, которым необходимо следовать при использовании средств связи для передачи информации, должны учитывать следующее:
- a) процедуры, предназначенные для защиты передаваемой информации от перехвата, копирования, модификации, перенаправления и уничтожения;
- b) процедуры обнаружения и защиты от вредоносных программ, которые могут передаваться с использованием электронных средств связи (см. 12.2.1);
- c) процедуры для защиты информации ограниченного доступа в электронном виде, передаваемой в форме вложения;
- d) политику или руководства, определяющие допустимое использование средств связи (см. 8.1.3);
- e) обязанности персонала, внешних сторон и любых иных пользователей не предпринимать действий, ставящих под угрозу организацию, например посредством клеветы, домогательств, неправомерного представления себя от лица организации, рассылки писем по цепочке, неавторизованных закупок и т.д.;
- f) использование криптографических методов, например для защиты конфиденциальности, целостности и аутентичности информации (раздел 10);
- g) руководства по срокам хранения и утилизации всей деловой переписки, включая сообщения, соответствующие национальному и местному законодательству и нормативным документам;
- h) меры обеспечения ИБ и ограничения, связанные с использованием средств связи, например автоматическая пересылка электронной почты на внешние почтовые адреса;
- i) рекомендации персоналу предпринимать меры предосторожности во избежание раскрытия конфиденциальной информации;
- j) не оставлять сообщения, содержащие конфиденциальную информацию на автоответчиках, так как они могут быть прослушаны неавторизованными лицами, сохранены в системах общего пользования или некорректно записаны в результате ошибочного набора номера;
- k) консультирование персонала о проблемах, связанных с использованием факсов и соответствующих услуг, а именно:
- неавторизованный доступ к встроенным хранилищам сообщений для извлечения сообщений;
- преднамеренное или случайное программирование машин на отправку сообщений на определенные номера;
- отсылка документов и сообщений на неверный номер в результате ошибочного набора либо вызова сохраненного неверного номера.
Кроме того, персоналу следует напоминать, что не следует вести конфиденциальные разговоры в общественных местах или по небезопасным каналам связи, в открытых офисах и переговорных.
Услуги по передаче информации должны соответствовать всем релевантным требованиям законодательства (см. 18.1).
Дополнительная информация
Передача информации может осуществляться с использованием ряда различных типов средств связи, включая электронную почту, голосовую и факсимильную связь, а также видео.
Передача программного обеспечения может осуществляться различными способами, включая загрузку из Интернета и приобретение у поставщиков, продающих готовые продукты.
Следует учитывать юридические последствия, влияние на бизнес и безопасность, связанные с обменом электронными данными, электронной торговлей и электронной связью, а также требования к мерам обеспечения ИБ.
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.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.
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.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.