Куда я попал?
NIST Cybersecurity Framework (EN)
Framework
ID.SC-3
Для проведения оценки соответствия по документу войдите в систему.
Похожие требования
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 8":
ПОН.8
ПОН.8 Распределение ответственности в рамках реализации процесса обеспечения операционной надежности при привлечении поставщиков услуг (в том числе поставщиков облачных услуг)
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 6. п.п. 4
6.4. Кредитные организации должны обеспечивать выполнение следующих требований к взаимодействию с поставщиками услуг в сфере информационных технологий:
- нейтрализация информационных угроз, связанных с привлечением поставщиков услуг в сфере информационных технологий, в том числе защита объектов информационной инфраструктуры от возможной реализации информационных угроз со стороны поставщиков услуг в сфере информационных технологий;
- нейтрализация информационных угроз, обусловленных технологической зависимостью функционирования объектов информационной инфраструктуры кредитной организации от поставщиков услуг в сфере информационных технологий.
NIST Cybersecurity Framework (RU):
ID.SC-3
ID.SC-3: Поставщики и партнеры обязаны по контракту принять соответствующие меры, предназначенные для достижения целей программы информационной безопасности или плана управления рисками кибер-цепочки поставок
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
РВН.5
РВН.5 Планирование, реализация, контроль и совершенствование мероприятий, направленных на уменьшение негативного влияния риска внутреннего нарушителя, применяемых в отношении работников поставщика услуг, привлекаемого в рамках выполнения бизнес- и технологических процессов.
РВН.6.1
РВН.6.1 Установление в рамках договорных отношений требований к соблюдению работниками поставщиков услуг установленных финансовой организацией требований к обеспечению операционной надежности и защите информации, а также их обязанностей и ответственности.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 8.3.10
8.3.10
Defined Approach Requirements:
Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data (i.e., in any singlefactor authentication implementation), then guidance is provided to customer users including:
Defined Approach Requirements:
Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data (i.e., in any singlefactor authentication implementation), then guidance is provided to customer users including:
- Guidance for customers to change their user passwords/passphrases periodically.
- Guidance as to when, and under what circumstances, passwords/passphrases are to be changed.
Customized Approach Objective:
Passwords/passphrases for service providers’ customers cannot be used indefinitely.
Applicability Notes:
This requirement applies only when the entity being assessed is a service provider.
This requirement does not apply to accounts of consumer users accessing their own payment card information.
This requirement for service providers will be superseded by Requirement 8.3.10.1 once 8.3.10.1 becomes effective.
Defined Approach Testing Procedures:
Passwords/passphrases for service providers’ customers cannot be used indefinitely.
Applicability Notes:
This requirement applies only when the entity being assessed is a service provider.
This requirement does not apply to accounts of consumer users accessing their own payment card information.
This requirement for service providers will be superseded by Requirement 8.3.10.1 once 8.3.10.1 becomes effective.
Defined Approach Testing Procedures:
- 8.3.10 Additional testing procedure for service provider assessments only: If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data, examine guidance provided to customer users to verify that the guidance includes all elements specified in this requirement.
Purpose:
Using a password/passphrase as the only authentication factor provides a single point of failure if compromised. Therefore, in these implementations, controls are needed to minimize how long malicious activity could occur via a compromised password/passphrase.
Good Practice:
Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to break the password/phrase. Periodically changing passwords offers less time for a malicious individual to crack a password/passphrase and less time to use a compromised password.
Using a password/passphrase as the only authentication factor provides a single point of failure if compromised. Therefore, in these implementations, controls are needed to minimize how long malicious activity could occur via a compromised password/passphrase.
Good Practice:
Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to break the password/phrase. Periodically changing passwords offers less time for a malicious individual to crack a password/passphrase and less time to use a compromised password.
Requirement 10.7.1
10.7.1
Defined Approach Requirements:
Additional requirement for service providers only: Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems:
Defined Approach Requirements:
Additional requirement for service providers only: Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems:
- Network security controls.
- IDS/IPS.
- FIM.
- Anti-malware solutions.
- Physical access controls.
- Logical access controls.
- Audit logging mechanisms.
- Segmentation controls (if used).
Customized Approach Objective:
Failures in critical security control systems are promptly identified and addressed.
Applicability Notes:
This requirement applies only when the entity being assessed is a service provider.
This requirement will be superseded by Requirement 10.7.2 as of 31 March 2025.
Defined Approach Testing Procedures:
Failures in critical security control systems are promptly identified and addressed.
Applicability Notes:
This requirement applies only when the entity being assessed is a service provider.
This requirement will be superseded by Requirement 10.7.2 as of 31 March 2025.
Defined Approach Testing Procedures:
- 10.7.1.a Additional testing procedure for service provider assessments only: Examine documentation to verify that processes are defined for the prompt detection and addressing of failures of critical security control systems, including but not limited to failure of all elements specified in this requirement.
- 10.7.1.b Additional testing procedure for service provider assessments only: Observe detection and alerting processes and interview personnel to verify that failures of critical security control systems are detected and reported, and that failure of a critical security control results in the generation of an alert.
Purpose:
Without formal processes to detect and alert when critical security controls fail, failures may go undetected for extended periods and provide attackers ample time to compromise system components and steal account data from the CDE.
Good Practice:
The specific types of failures may vary, depending on the function of the device system component and technology in use. Typical failures include a system ceasing to perform its security function or not functioning in its intended manner, such as a firewall erasing all its rules or going offline.
Without formal processes to detect and alert when critical security controls fail, failures may go undetected for extended periods and provide attackers ample time to compromise system components and steal account data from the CDE.
Good Practice:
The specific types of failures may vary, depending on the function of the device system component and technology in use. Typical failures include a system ceasing to perform its security function or not functioning in its intended manner, such as a firewall erasing all its rules or going offline.
Requirement 3.3.3
3.3.3
Defined Approach Requirements:
Additional requirement for issuers and companies that support issuing services and store sensitive authentication data: Any storage of sensitive authentication data is: • Limited to that which is needed for a legitimate issuing business need and is secured. • Encrypted using strong cryptography. This bullet is a best practice until its effective date; refer to Applicability Notes below for details.
Customized Approach Objective:
Sensitive authentication data is retained only as required to support issuing functions and is secured from unauthorized access.
Applicability Notes:
This requirement applies only to issuers and companies that support issuing services and store sensitive authentication data.
Entities that issue payment cards or that perform or support issuing services will often create and control sensitive authentication data as part of the issuing function. It is allowable for companies that perform, facilitate, or support issuing services to store sensitive authentication data ONLY IF they have a legitimate business need to store such data.
PCI DSS requirements are intended for all entities that store, process, or transmit account data, including issuers. The only exception for issuers and issuer processors is that sensitive authentication data may be retained if there is a legitimate reason to do so. Any such data must be stored securely and in accordance with all PCI DSS and specific payment brand requirements.
The bullet above (for encrypting stored SAD with strong cryptography) is a best practice until 31 March 2025, after which it will be required as part of Requirement 3.3.3 and must be fully considered during a PCI DSS assessment.
Defined Approach Testing Procedures:
Defined Approach Requirements:
Additional requirement for issuers and companies that support issuing services and store sensitive authentication data: Any storage of sensitive authentication data is: • Limited to that which is needed for a legitimate issuing business need and is secured. • Encrypted using strong cryptography. This bullet is a best practice until its effective date; refer to Applicability Notes below for details.
Customized Approach Objective:
Sensitive authentication data is retained only as required to support issuing functions and is secured from unauthorized access.
Applicability Notes:
This requirement applies only to issuers and companies that support issuing services and store sensitive authentication data.
Entities that issue payment cards or that perform or support issuing services will often create and control sensitive authentication data as part of the issuing function. It is allowable for companies that perform, facilitate, or support issuing services to store sensitive authentication data ONLY IF they have a legitimate business need to store such data.
PCI DSS requirements are intended for all entities that store, process, or transmit account data, including issuers. The only exception for issuers and issuer processors is that sensitive authentication data may be retained if there is a legitimate reason to do so. Any such data must be stored securely and in accordance with all PCI DSS and specific payment brand requirements.
The bullet above (for encrypting stored SAD with strong cryptography) is a best practice until 31 March 2025, after which it will be required as part of Requirement 3.3.3 and must be fully considered during a PCI DSS assessment.
Defined Approach Testing Procedures:
- 3.3.3.a Additional testing procedure for issuers and companies that support issuing services and store sensitive authentication data: Examine documented policies and interview personnel to verify there is a documented business justification for the storage of sensitive authentication data.
- 3.3.3.b Additional testing procedure for issuers and companies that support issuing services and store sensitive authentication data: Examine data stores and system configurations to verify that the sensitive authentication data is stored securely
Purpose:
SAD can be used by malicious individuals to increase the probability of successfully generating counterfeit payment cards and creating fraudulent transactions.
Good Practice:
Entities should consider encrypting SAD with a different cryptographic key than is used to encrypt PAN. Note that this does not mean that PAN present in SAD (as part of track data) would need to be separately encrypted.
Definitions:
Legitimate issuing business need means that the data is needed to facilitate the issuing business process.
Further Information:
Refer to ISO/DIS 9564-5 Financial services — Personal Identification Number (PIN)
SAD can be used by malicious individuals to increase the probability of successfully generating counterfeit payment cards and creating fraudulent transactions.
Good Practice:
Entities should consider encrypting SAD with a different cryptographic key than is used to encrypt PAN. Note that this does not mean that PAN present in SAD (as part of track data) would need to be separately encrypted.
Definitions:
Legitimate issuing business need means that the data is needed to facilitate the issuing business process.
Further Information:
Refer to ISO/DIS 9564-5 Financial services — Personal Identification Number (PIN)
Requirement 12.8.1
12.8.1
Defined Approach Requirements:
A list of all third-party service providers (TPSPs) with which account data is shared or that could affect the security of account data is maintained, including a description for each of the services provided.
Customized Approach Objective:
Records are maintained of TPSPs and the services provided.
Applicability Notes:
The use of a PCI DSS compliant TPSP does not make an entity PCI DSS compliant, nor does it remove the entity’s responsibility for its own PCI DSS compliance.
Defined Approach Testing Procedures:
Defined Approach Requirements:
A list of all third-party service providers (TPSPs) with which account data is shared or that could affect the security of account data is maintained, including a description for each of the services provided.
Customized Approach Objective:
Records are maintained of TPSPs and the services provided.
Applicability Notes:
The use of a PCI DSS compliant TPSP does not make an entity PCI DSS compliant, nor does it remove the entity’s responsibility for its own PCI DSS compliance.
Defined Approach Testing Procedures:
- 12.8.1.a Examine policies and procedures to verify that processes are defined to maintain a list of TPSPs, including a description for each of the services provided, for all TPSPs with whom account data is shared or that could affect the security of account data.
- 12.8.1.b Examine documentation to verify that a list of all TPSPs is maintained that includes a description of the services provided.
Purpose:
Maintaining a list of all TPSPs identifies where potential risk extends outside the organization and defines the organization’s extended attack surface.
Examples:
Different types of TPSPs include those that:
Maintaining a list of all TPSPs identifies where potential risk extends outside the organization and defines the organization’s extended attack surface.
Examples:
Different types of TPSPs include those that:
- Store, process, or transmit account data on the entity’s behalf (such as payment gateways, payment processors, payment service providers (PSPs), and off-site storage providers).
- Manage system components included in the entity’s PCI DSS assessment (such as providers of network security control services, anti-malware services, and security incident and event management (SIEM); contact and call centers; web-hosting companies; and IaaS, PaaS, SaaS, and FaaS cloud providers).
- Could impact the security of the entity’s CDE (such as vendors providing support via remote access, and bespoke software developers).
Requirement 12.8.2
12.8.2
Defined Approach Requirements:
Written agreements with TPSPs are maintained as follows:
Defined Approach Requirements:
Written agreements with TPSPs are maintained as follows:
- Written agreements are maintained with all TPSPs with which account data is shared or that could affect the security of the CDE.
- Written agreements include acknowledgments from TPSPs that they are responsible for the security of account data the TPSPs possess or otherwise store, process, or transmit on behalf of the entity, or to the extent that they could impact the security of the entity’s CDE.
Customized Approach Objective:
Records are maintained of each TPSP’s acknowledgment of its responsibility to protect account data.
Applicability Notes:
The exact wording of an acknowledgment will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgment does not have to include the exact wording provided in this requirement.
Evidence that a TPSP is meeting PCI DSS requirements (for example, a PCI DSS Attestation of Compliance (AOC) or a declaration on a company’s website) is not the same as a written agreement specified in this requirement.
Defined Approach Testing Procedures:
Records are maintained of each TPSP’s acknowledgment of its responsibility to protect account data.
Applicability Notes:
The exact wording of an acknowledgment will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgment does not have to include the exact wording provided in this requirement.
Evidence that a TPSP is meeting PCI DSS requirements (for example, a PCI DSS Attestation of Compliance (AOC) or a declaration on a company’s website) is not the same as a written agreement specified in this requirement.
Defined Approach Testing Procedures:
- 12.8.2.a Examine policies and procedures to verify that processes are defined to maintain written agreements with all TPSPs in accordance with all elements specified in this requirement.
- 12.8.2.b Examine written agreements with TPSPs to verify they are maintained in accordance with all elements as specified in this requirement.
Purpose:
The written acknowledgment from a TPSP demonstrates its commitment to maintaining proper security of account data that it obtains from its customers and that the TPSP is fully aware of the assets that could be affected during the provisioning of the TPSP’s service. The extent to which a specific TPSP is responsible for the security of account data will depend on the service provided and the agreement between the provider and assessed entity (the customer).
In conjunction with Requirement 12.9.1, this requirement is intended to promote a consistent level of understanding between parties about their applicable PCI DSS responsibilities. For example, the agreement may include the applicable PCI DSS requirements to be maintained as part of the provided service.
Good Practice:
The entity may also want to consider including in their written agreement with a TPSP that the TPSP will support the entity’s request for information per Requirement 12.9.2. Entities will also want to understand whether any TPSPs have “nested” relationships with other TPSPs, meaning the primary TPSP contracts with another TPSP(s) for the purposes of providing a service.
It is important to understand whether the primary TPSP is relying on the secondary TPSP(s) to achieve overall compliance of a service, and what types of written agreements the primary TPSP has in place with the secondary TPSPs. Entities can consider including coverage in their written agreement for any “nested” TPSPs a primary TPSP may use.
Further Information:
Refer to the “Information Supplement: Third-Party Security Assurance for further guidance.
The written acknowledgment from a TPSP demonstrates its commitment to maintaining proper security of account data that it obtains from its customers and that the TPSP is fully aware of the assets that could be affected during the provisioning of the TPSP’s service. The extent to which a specific TPSP is responsible for the security of account data will depend on the service provided and the agreement between the provider and assessed entity (the customer).
In conjunction with Requirement 12.9.1, this requirement is intended to promote a consistent level of understanding between parties about their applicable PCI DSS responsibilities. For example, the agreement may include the applicable PCI DSS requirements to be maintained as part of the provided service.
Good Practice:
The entity may also want to consider including in their written agreement with a TPSP that the TPSP will support the entity’s request for information per Requirement 12.9.2. Entities will also want to understand whether any TPSPs have “nested” relationships with other TPSPs, meaning the primary TPSP contracts with another TPSP(s) for the purposes of providing a service.
It is important to understand whether the primary TPSP is relying on the secondary TPSP(s) to achieve overall compliance of a service, and what types of written agreements the primary TPSP has in place with the secondary TPSPs. Entities can consider including coverage in their written agreement for any “nested” TPSPs a primary TPSP may use.
Further Information:
Refer to the “Information Supplement: Third-Party Security Assurance for further guidance.
Requirement 12.4.1
12.4.1
Defined Approach Requirements:
Additional requirement for service providers only: Responsibility is established by executive management for the protection of cardholder data and a PCI DSS compliance program to include:
Defined Approach Requirements:
Additional requirement for service providers only: Responsibility is established by executive management for the protection of cardholder data and a PCI DSS compliance program to include:
- Overall accountability for maintaining PCI DSS compliance.
- Defining a charter for a PCI DSS compliance program and communication to executive management.
Customized Approach Objective:
Executives are responsible and accountable for security of cardholder data.
Applicability Notes:
This requirement applies only when the entity being assessed is a service provider.
Executive management may include C-level positions, board of directors, or equivalent. The specific titles will depend on the particular organizational structure.
Responsibility for the PCI DSS compliance program may be assigned to individual roles and/or to business units within the organization.
Defined Approach Testing Procedures:
Executives are responsible and accountable for security of cardholder data.
Applicability Notes:
This requirement applies only when the entity being assessed is a service provider.
Executive management may include C-level positions, board of directors, or equivalent. The specific titles will depend on the particular organizational structure.
Responsibility for the PCI DSS compliance program may be assigned to individual roles and/or to business units within the organization.
Defined Approach Testing Procedures:
- 12.4.1 Additional testing procedure for service provider assessments only: Examine documentation to verify that executive management has established responsibility for the protection of cardholder data and a PCI DSS compliance program in accordance with all elements specified in this requirement.
Purpose:
Executive management assignment of PCI DSS compliance responsibilities ensures executivelevel visibility into the PCI DSS compliance program and allows for the opportunity to ask appropriate questions to determine the effectiveness of the program and influence strategic priorities.
Executive management assignment of PCI DSS compliance responsibilities ensures executivelevel visibility into the PCI DSS compliance program and allows for the opportunity to ask appropriate questions to determine the effectiveness of the program and influence strategic priorities.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.15.1.1
A.15.1.1 Политика информационной безопасности во взаимоотношениях с поставщиками
Мера обеспечения информационной безопасности: Требования информационной безопасности, направленные на снижение рисков, связанных с доступом поставщиков к активам организации, должны быть согласованы с поставщиком и документированы
Мера обеспечения информационной безопасности: Требования информационной безопасности, направленные на снижение рисков, связанных с доступом поставщиков к активам организации, должны быть согласованы с поставщиком и документированы
A.15.1.3
A.15.1.3 Цепочка поставок информационно-коммуникационной технологии
Мера обеспечения информационной безопасности: Соглашения с поставщиками должны содержать требования по рассмотрению рисков информационной безопасности, связанных с цепочкой поставок продуктов и услуг информационно-коммуникационных технологий
Мера обеспечения информационной безопасности: Соглашения с поставщиками должны содержать требования по рассмотрению рисков информационной безопасности, связанных с цепочкой поставок продуктов и услуг информационно-коммуникационных технологий
A.15.1.2
A.15.1.2 Рассмотрение вопросов безопасности в соглашениях с поставщиками
Мера обеспечения информационной безопасности: Все соответствующие требования информационной безопасности должны быть установлены и согласованы с каждым поставщиком, который может получить доступ к информации организации, обрабатывать, хранить, передавать информацию или предоставлять соответствующие компоненты ИТ-инфраструктуры
Мера обеспечения информационной безопасности: Все соответствующие требования информационной безопасности должны быть установлены и согласованы с каждым поставщиком, который может получить доступ к информации организации, обрабатывать, хранить, передавать информацию или предоставлять соответствующие компоненты ИТ-инфраструктуры
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 12.8.2
12.8.2
Определенные Требования к Подходу:
Письменные соглашения с TPSP поддерживаются следующим образом:
Определенные Требования к Подходу:
Письменные соглашения с TPSP поддерживаются следующим образом:
- Со всеми TPPS, которым передаются данные учетной записи или которые могут повлиять на безопасность CDE, поддерживаются письменные соглашения.
- Письменные соглашения включают подтверждения от TPPS о том, что они несут ответственность за безопасность учетных данных, которыми владеют TPPS или иным образом хранят, обрабатывают или передают от имени организации, или в той степени, в какой они могут повлиять на безопасность CDE организации.
Цель Индивидуального подхода:
Ведутся записи о подтверждении каждым TPSP своей ответственности за защиту данных учетной записи.
Примечания по применению:
Точная формулировка подтверждения будет зависеть от соглашения между двумя сторонами, деталей предоставляемой услуги и обязанностей, возложенных на каждую сторону. Подтверждение не обязательно должно содержать точную формулировку, предусмотренную в этом требовании.
Доказательства того, что TPSP соответствует требованиям PCI DSS (например, сертификат соответствия PCI DSS (AOC) или декларация на веб-сайте компании), не совпадают с письменным соглашением, указанным в этом требовании.
Определенные Процедуры Тестирования Подхода:
Ведутся записи о подтверждении каждым TPSP своей ответственности за защиту данных учетной записи.
Примечания по применению:
Точная формулировка подтверждения будет зависеть от соглашения между двумя сторонами, деталей предоставляемой услуги и обязанностей, возложенных на каждую сторону. Подтверждение не обязательно должно содержать точную формулировку, предусмотренную в этом требовании.
Доказательства того, что TPSP соответствует требованиям PCI DSS (например, сертификат соответствия PCI DSS (AOC) или декларация на веб-сайте компании), не совпадают с письменным соглашением, указанным в этом требовании.
Определенные Процедуры Тестирования Подхода:
- 12.8.2.a Изучить политики и процедуры, чтобы убедиться, что процессы определены для поддержания письменных соглашений со всеми TPSP в соответствии со всеми элементами, указанными в этом требовании.
- 12.8.2.b Изучите письменные соглашения с TPSP, чтобы убедиться, что они поддерживаются в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Письменное подтверждение от TPSP демонстрирует его приверженность поддержанию надлежащей безопасности учетных данных, которые он получает от своих клиентов, и что TPSP полностью осведомлен об активах, которые могут быть затронуты во время предоставления услуг TPSP. Степень, в которой конкретный TPSP несет ответственность за безопасность данных учетной записи, будет зависеть от предоставляемой услуги и соглашения между поставщиком и оцениваемой организацией (клиентом).
В сочетании с требованием 12.9.1 это требование призвано способствовать постоянному уровню понимания между сторонами их применимых обязанностей по PCI DSS. Например, соглашение может включать применимые требования PCI DSS, которые должны поддерживаться в рамках предоставляемой услуги.
Надлежащая практика:
Организация может также захотеть включить в свое письменное соглашение с TPSP, что TPSP будет поддерживать запрос организации о предоставлении информации в соответствии с требованием 12.9.2. Организации также захотят понять, имеют ли какие-либо TPSP “вложенные” отношения с другими TPSP, что означает, что первичный TPSP заключает контракты с другим TPSP (ами) на цели предоставления услуги.
Важно понимать, полагается ли первичный TPSP на вторичный TPSP(ы) для достижения общего соответствия услуги, и какие типы письменных соглашений заключены у первичного TPSP с вторичными TPSP. Организации могут рассмотреть возможность включения покрытия в свое письменное соглашение для любых “вложенных” TPSP, которые может использовать основной TPSP.
Дополнительная информация:
Дополнительные указания см. в разделе “Информационное дополнение: Обеспечение безопасности третьей стороной".
Письменное подтверждение от TPSP демонстрирует его приверженность поддержанию надлежащей безопасности учетных данных, которые он получает от своих клиентов, и что TPSP полностью осведомлен об активах, которые могут быть затронуты во время предоставления услуг TPSP. Степень, в которой конкретный TPSP несет ответственность за безопасность данных учетной записи, будет зависеть от предоставляемой услуги и соглашения между поставщиком и оцениваемой организацией (клиентом).
В сочетании с требованием 12.9.1 это требование призвано способствовать постоянному уровню понимания между сторонами их применимых обязанностей по PCI DSS. Например, соглашение может включать применимые требования PCI DSS, которые должны поддерживаться в рамках предоставляемой услуги.
Надлежащая практика:
Организация может также захотеть включить в свое письменное соглашение с TPSP, что TPSP будет поддерживать запрос организации о предоставлении информации в соответствии с требованием 12.9.2. Организации также захотят понять, имеют ли какие-либо TPSP “вложенные” отношения с другими TPSP, что означает, что первичный TPSP заключает контракты с другим TPSP (ами) на цели предоставления услуги.
Важно понимать, полагается ли первичный TPSP на вторичный TPSP(ы) для достижения общего соответствия услуги, и какие типы письменных соглашений заключены у первичного TPSP с вторичными TPSP. Организации могут рассмотреть возможность включения покрытия в свое письменное соглашение для любых “вложенных” TPSP, которые может использовать основной TPSP.
Дополнительная информация:
Дополнительные указания см. в разделе “Информационное дополнение: Обеспечение безопасности третьей стороной".
Requirement 8.3.10
8.3.10
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Если пароли/парольные фразы используются в качестве единственного фактора аутентификации для доступа пользователя клиента к данным держателя карты (т.е. в любой реализации однофакторной аутентификации), то пользователям клиентов предоставляются рекомендации, в том числе:
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Если пароли/парольные фразы используются в качестве единственного фактора аутентификации для доступа пользователя клиента к данным держателя карты (т.е. в любой реализации однофакторной аутентификации), то пользователям клиентов предоставляются рекомендации, в том числе:
- Рекомендации для клиентов по периодической смене своих пользовательских паролей/парольных фраз.
- Указания относительно того, когда и при каких обстоятельствах следует менять пароли/парольные фразы.
Цель Индивидуального подхода:
Пароли/парольные фразы для клиентов поставщиков услуг не могут использоваться бесконечно.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование не распространяется на учетные записи пользователей-потребителей, получающих доступ к информации о своих собственных платежных картах.
Это требование к поставщикам услуг будет заменено Требованием 8.3.10.1, как только 8.3.10.1 вступит в силу.
Определенные Процедуры Тестирования Подхода:
Пароли/парольные фразы для клиентов поставщиков услуг не могут использоваться бесконечно.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование не распространяется на учетные записи пользователей-потребителей, получающих доступ к информации о своих собственных платежных картах.
Это требование к поставщикам услуг будет заменено Требованием 8.3.10.1, как только 8.3.10.1 вступит в силу.
Определенные Процедуры Тестирования Подхода:
- 8.3.10 Дополнительная процедура тестирования только для оценки поставщика услуг: Если пароли / парольные фразы используются в качестве единственного фактора аутентификации для доступа пользователя клиента к данным о держателях карт, изучите руководство, предоставленное пользователям клиента, чтобы убедиться, что руководство включает все элементы, указанные в этом требовании.
Цель:
Использование пароля/парольной фразы в качестве единственного фактора аутентификации обеспечивает единую точку отказа в случае компрометации. Поэтому в этих реализациях необходимы средства контроля, чтобы свести к минимуму время, в течение которого может происходить вредоносная активность с использованием скомпрометированного пароля/ключевой фразы.
Надлежащая практика:
Пароли/парольные фразы, которые действительны в течение длительного времени без изменений, дают злоумышленникам больше времени для взлома пароля / фразы. Периодическая смена паролей дает злоумышленнику меньше времени для взлома пароля / парольной фразы и меньше времени для использования скомпрометированного пароля.
Использование пароля/парольной фразы в качестве единственного фактора аутентификации обеспечивает единую точку отказа в случае компрометации. Поэтому в этих реализациях необходимы средства контроля, чтобы свести к минимуму время, в течение которого может происходить вредоносная активность с использованием скомпрометированного пароля/ключевой фразы.
Надлежащая практика:
Пароли/парольные фразы, которые действительны в течение длительного времени без изменений, дают злоумышленникам больше времени для взлома пароля / фразы. Периодическая смена паролей дает злоумышленнику меньше времени для взлома пароля / парольной фразы и меньше времени для использования скомпрометированного пароля.
Requirement 12.8.1
12.8.1
Определенные Требования к Подходу:
Ведется список всех сторонних поставщиков услуг (TPSP), с которыми передаются данные учетной записи или которые могут повлиять на безопасность данных учетной записи, включая описание каждой из предоставляемых услуг.
Цель Индивидуального подхода:
Ведется учет TPPS и предоставляемых услуг.
Примечания по применению:
Использование TPSP, совместимого с PCI DSS, не делает организацию совместимой с PCI DSS и не снимает с организации ответственности за ее собственное соответствие требованиям PCI DSS.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Ведется список всех сторонних поставщиков услуг (TPSP), с которыми передаются данные учетной записи или которые могут повлиять на безопасность данных учетной записи, включая описание каждой из предоставляемых услуг.
Цель Индивидуального подхода:
Ведется учет TPPS и предоставляемых услуг.
Примечания по применению:
Использование TPSP, совместимого с PCI DSS, не делает организацию совместимой с PCI DSS и не снимает с организации ответственности за ее собственное соответствие требованиям PCI DSS.
Определенные Процедуры Тестирования Подхода:
- 12.8.1.a Изучить политики и процедуры, чтобы убедиться, что определены процессы для ведения списка TPPS, включая описание для каждой из предоставляемых услуг, для всех TPPS, с которыми передаются данные учетной записи или которые могут повлиять на безопасность данных учетной записи.
- 12.8.1.b Изучите документацию, чтобы убедиться, что ведется список всех TPSP, который включает описание предоставляемых услуг.
Цель:
Ведение списка всех TPSP определяет, где потенциальный риск распространяется за пределы организации, и определяет расширенную зону атаки организации.
Примеры:
Различные типы TPSP включают те, которые:
Ведение списка всех TPSP определяет, где потенциальный риск распространяется за пределы организации, и определяет расширенную зону атаки организации.
Примеры:
Различные типы TPSP включают те, которые:
- Хранить, обрабатывать или передавать данные учетной записи от имени организации (например, платежные шлюзы, платежные процессоры, поставщики платежных услуг (PSP) и сторонние поставщики хранилища).
- Управляйте системными компонентами, включенными в оценку PCI DSS организации (например, поставщиками услуг контроля сетевой безопасности, услуг защиты от вредоносных программ и управления инцидентами и событиями безопасности (SIEM); контактными и колл-центрами; веб-хостинговыми компаниями; и облачными провайдерами IaaS, PaaS, SaaS и FaaS).
- Может повлиять на безопасность CDE организации (например, поставщики, предоставляющие поддержку через удаленный доступ, и разработчики программного обеспечения на заказ).
Requirement 10.7.1
10.7.1
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Сбои в критически важных системах контроля безопасности обнаруживаются, предупреждаются и оперативно устраняются, включая, но не ограничиваясь, сбои в следующих критически важных системах контроля безопасности:
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Сбои в критически важных системах контроля безопасности обнаруживаются, предупреждаются и оперативно устраняются, включая, но не ограничиваясь, сбои в следующих критически важных системах контроля безопасности:
- Средства управления сетевой безопасностью.
- IDS/IPS.
- FIM.
- Решения для защиты от вредоносных программ.
- Контроль физического доступа.
- Логический контроль доступа.
- Механизмы ведения журнала аудита.
- Элементы управления сегментацией (если они используются).
Цель Индивидуального подхода:
Сбои в критически важных системах контроля безопасности оперативно выявляются и устраняются.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование будет заменено Требованием 10.7.2 с 31 марта 2025 года.
Определенные Процедуры Тестирования Подхода:
Сбои в критически важных системах контроля безопасности оперативно выявляются и устраняются.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование будет заменено Требованием 10.7.2 с 31 марта 2025 года.
Определенные Процедуры Тестирования Подхода:
- 10.7.1.дополнительная процедура тестирования только для оценки поставщика услуг: Изучите документацию, чтобы убедиться, что определены процессы для оперативного обнаружения и устранения сбоев критических систем контроля безопасности, включая, но не ограничиваясь отказом всех элементов, указанных в этом требовании.
- 10.7.1.b Дополнительная процедура тестирования только для оценки поставщика услуг: Наблюдайте за процессами обнаружения и оповещения и опрашивайте персонал, чтобы убедиться, что сбои в критически важных системах контроля безопасности обнаружены и сообщены, и что сбой критического контроля безопасности приводит к генерации предупреждения.
Цель:
Без формальных процессов обнаружения и оповещения о сбое критических средств защиты сбои могут оставаться незамеченными в течение длительного времени и предоставлять злоумышленникам достаточно времени для компрометации системных компонентов и кражи данных учетной записи из CDE.
Надлежащая практика:
Конкретные типы отказов могут варьироваться в зависимости от функции системного компонента устройства и используемой технологии. Типичные сбои включают в себя то, что система перестает выполнять свои функции безопасности или не функционирует должным образом, например, брандмауэр стирает все свои правила или переходит в автономный режим.
Без формальных процессов обнаружения и оповещения о сбое критических средств защиты сбои могут оставаться незамеченными в течение длительного времени и предоставлять злоумышленникам достаточно времени для компрометации системных компонентов и кражи данных учетной записи из CDE.
Надлежащая практика:
Конкретные типы отказов могут варьироваться в зависимости от функции системного компонента устройства и используемой технологии. Типичные сбои включают в себя то, что система перестает выполнять свои функции безопасности или не функционирует должным образом, например, брандмауэр стирает все свои правила или переходит в автономный режим.
Requirement 3.3.3
3.3.3
Определенные Требования к Подходу:
Дополнительное требование к эмитентам и компаниям, которые поддерживают услуги выдачи и хранят конфиденциальные аутентификационные данные: Любое хранение конфиденциальных аутентификационных данных:
Определенные Требования к Подходу:
Дополнительное требование к эмитентам и компаниям, которые поддерживают услуги выдачи и хранят конфиденциальные аутентификационные данные: Любое хранение конфиденциальных аутентификационных данных:
- Ограничено тем, что необходимо для законных бизнес-потребностей эмитента и защищено.
- Зашифровано с использованием надежной криптографии. Этот бюллетень является наилучшей практикой до даты его вступления в силу; подробности см. в Примечаниях к применению ниже.
Цель Индивидуального подхода:
Конфиденциальные аутентификационные данные сохраняются только по мере необходимости для поддержки функций выдачи и защищены от несанкционированного доступа.
Примечания по применению:
Это требование распространяется только на эмитентов и компании, которые поддерживают услуги выдачи и хранят конфиденциальные данные аутентификации.
Организации, которые выпускают платежные карты или которые предоставляют или поддерживают услуги по выдаче, часто создают и контролируют конфиденциальные аутентификационные данные в рамках функции выдачи. Компаниям, которые предоставляют, облегчают или поддерживают выдачу услуг, разрешается хранить конфиденциальные данные аутентификации ТОЛЬКО в том случае, ЕСЛИ у них есть законная деловая потребность в хранении таких данных.
Требования PCI DSS предназначены для всех организаций, которые хранят, обрабатывают или передают данные учетной записи, включая эмитентов. Единственным исключением для эмитентов и обработчиков данных эмитентов является то, что конфиденциальные аутентификационные данные могут быть сохранены, если для этого есть законная причина. Любые такие данные должны храниться надежно и в соответствии со всеми стандартами PCI DSS и конкретными требованиями платежного бренда.
Приведенный выше маркер (для шифрования хранимых данных с помощью надежной криптографии) является наилучшей практикой до 31 марта 2025 года, после чего он потребуется как часть требования 3.3.3 и должен быть полностью рассмотрен во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
Конфиденциальные аутентификационные данные сохраняются только по мере необходимости для поддержки функций выдачи и защищены от несанкционированного доступа.
Примечания по применению:
Это требование распространяется только на эмитентов и компании, которые поддерживают услуги выдачи и хранят конфиденциальные данные аутентификации.
Организации, которые выпускают платежные карты или которые предоставляют или поддерживают услуги по выдаче, часто создают и контролируют конфиденциальные аутентификационные данные в рамках функции выдачи. Компаниям, которые предоставляют, облегчают или поддерживают выдачу услуг, разрешается хранить конфиденциальные данные аутентификации ТОЛЬКО в том случае, ЕСЛИ у них есть законная деловая потребность в хранении таких данных.
Требования PCI DSS предназначены для всех организаций, которые хранят, обрабатывают или передают данные учетной записи, включая эмитентов. Единственным исключением для эмитентов и обработчиков данных эмитентов является то, что конфиденциальные аутентификационные данные могут быть сохранены, если для этого есть законная причина. Любые такие данные должны храниться надежно и в соответствии со всеми стандартами PCI DSS и конкретными требованиями платежного бренда.
Приведенный выше маркер (для шифрования хранимых данных с помощью надежной криптографии) является наилучшей практикой до 31 марта 2025 года, после чего он потребуется как часть требования 3.3.3 и должен быть полностью рассмотрен во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
- 3.3.3.дополнительная процедура тестирования для эмитентов и компаний, которые поддерживают услуги по выдаче и хранят конфиденциальные аутентификационные данные: Изучите документированные политики и опросите персонал, чтобы убедиться в наличии документированного бизнес-обоснования для хранения конфиденциальных аутентификационных данных.
- 3.3.3.b Дополнительная процедура тестирования для эмитентов и компаний, которые поддерживают услуги выдачи и хранят конфиденциальные аутентификационные данные: Проверьте хранилища данных и системные конфигурации, чтобы убедиться, что конфиденциальные аутентификационные данные хранятся надежно
Цель:
SAD может быть использован злоумышленниками для повышения вероятности успешного создания поддельных платежных карт и совершения мошеннических транзакций.
Надлежащая практика:
Организациям следует рассмотреть возможность шифрования SAD с помощью криптографического ключа, отличного от того, который используется для шифрования PAN. Обратите внимание, что это не означает, что PAN, присутствующий в SAD (как часть данных трека), должен быть зашифрован отдельно.
Определения:
Законная бизнес-потребность в выдаче означает, что данные необходимы для облегчения бизнес-процесса выдачи.
Дополнительная информация:
Обратитесь к ISO/DIS 9564-5 Финансовые услуги — Личный идентификационный номер (PIN-код)
SAD может быть использован злоумышленниками для повышения вероятности успешного создания поддельных платежных карт и совершения мошеннических транзакций.
Надлежащая практика:
Организациям следует рассмотреть возможность шифрования SAD с помощью криптографического ключа, отличного от того, который используется для шифрования PAN. Обратите внимание, что это не означает, что PAN, присутствующий в SAD (как часть данных трека), должен быть зашифрован отдельно.
Определения:
Законная бизнес-потребность в выдаче означает, что данные необходимы для облегчения бизнес-процесса выдачи.
Дополнительная информация:
Обратитесь к ISO/DIS 9564-5 Финансовые услуги — Личный идентификационный номер (PIN-код)
Requirement 12.4.1
12.4.1
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Ответственность за защиту данных о держателях карт устанавливается исполнительным руководством, а программа соответствия требованиям PCI DSS включает:
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Ответственность за защиту данных о держателях карт устанавливается исполнительным руководством, а программа соответствия требованиям PCI DSS включает:
- Общая ответственность за поддержание соответствия стандарту PCI DSS.
- Определение устава для программы соответствия требованиям PCI DSS и доведение ее до сведения исполнительного руководства.
Цель Индивидуального подхода:
Руководители несут ответственность и подотчетны за безопасность данных о держателях карт.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Исполнительное руководство может включать должности уровня С, совет директоров или аналогичные должности. Конкретные названия будут зависеть от конкретной организационной структуры.
Ответственность за программу соответствия требованиям PCI DSS может быть возложена на отдельные роли и/или на бизнес-подразделения внутри организации.
Определенные Процедуры Тестирования Подхода:
Руководители несут ответственность и подотчетны за безопасность данных о держателях карт.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Исполнительное руководство может включать должности уровня С, совет директоров или аналогичные должности. Конкретные названия будут зависеть от конкретной организационной структуры.
Ответственность за программу соответствия требованиям PCI DSS может быть возложена на отдельные роли и/или на бизнес-подразделения внутри организации.
Определенные Процедуры Тестирования Подхода:
- 12.4.1 Дополнительная процедура тестирования только для оценки поставщика услуг: Изучите документацию, чтобы убедиться, что исполнительное руководство установило ответственность за защиту данных о держателях карт и программу соответствия требованиям PCI DSS в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Распределение обязанностей по соблюдению требований PCI DSS между исполнительным руководством обеспечивает видимость программы соблюдения требований PCI DSS на уровне руководства и дает возможность задавать соответствующие вопросы для определения эффективности программы и влияния на стратегические приоритеты.
Распределение обязанностей по соблюдению требований PCI DSS между исполнительным руководством обеспечивает видимость программы соблюдения требований PCI DSS на уровне руководства и дает возможность задавать соответствующие вопросы для определения эффективности программы и влияния на стратегические приоритеты.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.20
А.5.20 Учет ИБ в соглашениях с поставщиками
С каждым поставщиком, в зависимости от типа отношений с ним, должны быть установлены и согласованы соответствующие требования ИБ
С каждым поставщиком, в зависимости от типа отношений с ним, должны быть установлены и согласованы соответствующие требования ИБ
А.5.21
А.5.21 Управление ИБ в цепочке поставок информационно-коммуникационных технологий (ИКТ)
В целях управления рисками ИБ, связанными с цепочкой поставок продуктов и услуг ИКТ, должны быть определены и внедрены соответствующие процессы и процедуры.
В целях управления рисками ИБ, связанными с цепочкой поставок продуктов и услуг ИКТ, должны быть определены и внедрены соответствующие процессы и процедуры.
А.5.19
А.5.19 Информационная безопасность в отношениях с поставщиками
В целях управления рисками ИБ, связанными с использованием поставляемыми продуктами или услугами, должны быть определены и внедрены соответствующие процессы и процедуры.
В целях управления рисками ИБ, связанными с использованием поставляемыми продуктами или услугами, должны быть определены и внедрены соответствующие процессы и процедуры.
SWIFT Customer Security Controls Framework v2022:
2 - 2.8A Critical Activity Outsourcing
2.8A Critical Activity Outsourcing
Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":
п. 1.7.
1.7. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны обеспечивать выполнение следующих требований в отношении взаимодействия с поставщиками услуг:
- управление риском реализации информационных угроз при привлечении поставщиков услуг, в том числе защиту своих объектов информационной инфраструктуры от возможной реализации информационных угроз со стороны поставщиков услуг;
- управление риском технологической зависимости функционирования своих объектов информационной инфраструктуры от поставщиков услуг.
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.5.21
А.5.21 Managing information security in the information and communication technology (ICT) supply chain
Processes and procedures shall be defined and implemented to manage information security risks associated with the ICT products and services supply chain.
Processes and procedures shall be defined and implemented to manage information security risks associated with the ICT products and services supply chain.
А.5.20
А.5.20 Addressing information security within supplier agreements
Relevant information security requirements shall be established and agreed with each supplier based on the type of supplier relationship.
Relevant information security requirements shall be established and agreed with each supplier based on the type of supplier relationship.
А.5.19
А.5.19 Information security in supplier relationships
Processes and procedures shall be defined and implemented to manage the information security risks associated with the use of supplier’s products or services.
Processes and procedures shall be defined and implemented to manage the information security risks associated with the use of supplier’s products or services.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.