Куда я попал?
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022
Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А
A.15.1.2
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
NIST Cybersecurity Framework (RU):
ID.SC-1
ID.SC-1: Идентфицированы, устанавлены, оцениваются, управляются и согласовываются заинтересованными сторонами организации все процессы управления рисками в кибер-цепочке
ID.SC-3
ID.SC-3: Поставщики и партнеры обязаны по контракту принять соответствующие меры, предназначенные для достижения целей программы информационной безопасности или плана управления рисками кибер-цепочки поставок
ID.BE-1
ID.BE-1: Определена и сообщена роль организации в цепочке поставок
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
РВН.6.1
РВН.6.1 Установление в рамках договорных отношений требований к соблюдению работниками поставщиков услуг установленных финансовой организацией требований к обеспечению операционной надежности и защите информации, а также их обязанностей и ответственности.
ВПУ.4.1
ВПУ.4.1 Заключение соглашений об уровне оказания услуг (SLA) и неразглашении информации конфиденциального характера (NDA) в отношении поставщиков услуг***;
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 12.5.3
12.5.3
Defined Approach Requirements:
Additional requirement for service providers only: Significant changes to organizational structure result in a documented (internal) review of the impact to PCI DSS scope and applicability of controls, with results communicated to executive management.
Customized Approach Objective:
PCI DSS scope is confirmed after significant organizational change.
Applicability Notes:
This requirement applies only when the entity being assessed is a service provider.
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:
Defined Approach Requirements:
Additional requirement for service providers only: Significant changes to organizational structure result in a documented (internal) review of the impact to PCI DSS scope and applicability of controls, with results communicated to executive management.
Customized Approach Objective:
PCI DSS scope is confirmed after significant organizational change.
Applicability Notes:
This requirement applies only when the entity being assessed is a service provider.
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.5.3.a Additional testing procedure for service provider assessments only: Examine policies and procedures to verify that processes are defined such that a significant change to organizational structure results in documented review of the impact to PCI DSS scope and applicability of controls.
- 12.5.3.b Additional testing procedure for service provider assessments only: Examine documentation (for example, meeting minutes) and interview responsible personnel to verify that significant changes to organizational structure resulted in documented reviews that included all elements specified in this requirement, with results communicated to executive management.
Purpose:
An organization’s structure and management define the requirements and protocol for effective and secure operations. Changes to this structure could have negative effects to existing controls and frameworks by reallocating or removing resources that once supported PCI DSS controls or inheriting new responsibilities that may not have established controls in place. Therefore, it is important to revisit PCI DSS scope and controls when there are changes to an organization’s structure and management to ensure controls are in place and active.
Examples:
Changes to organizational structure include, but are not limited to, company mergers or acquisitions, and significant changes or reassignments of personnel with responsibility for security controls.
An organization’s structure and management define the requirements and protocol for effective and secure operations. Changes to this structure could have negative effects to existing controls and frameworks by reallocating or removing resources that once supported PCI DSS controls or inheriting new responsibilities that may not have established controls in place. Therefore, it is important to revisit PCI DSS scope and controls when there are changes to an organization’s structure and management to ensure controls are in place and active.
Examples:
Changes to organizational structure include, but are not limited to, company mergers or acquisitions, and significant changes or reassignments of personnel with responsibility for security controls.
Requirement 12.5.2.1
12.5.2.1
Defined Approach Requirements:
Additional requirement for service providers only: PCI DSS scope is documented and confirmed by the entity at least once every six months and upon significant change to the in-scope environment. At a minimum, the scoping validation includes all the elements specified in Requirement 12.5.2.
Customized Approach Objective:
The accuracy of PCI DSS scope is verified to be continuously accurate by comprehensive analysis and appropriate technical measures.
Applicability Notes:
This requirement applies only when the entity being assessed is a service provider.
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:
Defined Approach Requirements:
Additional requirement for service providers only: PCI DSS scope is documented and confirmed by the entity at least once every six months and upon significant change to the in-scope environment. At a minimum, the scoping validation includes all the elements specified in Requirement 12.5.2.
Customized Approach Objective:
The accuracy of PCI DSS scope is verified to be continuously accurate by comprehensive analysis and appropriate technical measures.
Applicability Notes:
This requirement applies only when the entity being assessed is a service provider.
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.5.2.1.a Additional testing procedure for service provider assessments only: Examine documented results of scope reviews and interview personnel to verify that reviews per Requirement
- 12.5.2 are performed:
- At least once every six months, and
- After significant changes
- 12.5.2.1.b Additional testing procedure for service provider assessments only: Examine documented results of scope reviews to verify that scoping validation includes all elements specified in Requirement 12.5.2.
Purpose:
Service providers typically have access to greater volumes of cardholder data than do merchants, or can provide an entry point that can be exploited to then compromise multiple other entities. Service providers also typically have larger and more complex networks that are subject to more frequent change. The probability of overlooked changes to scope in complex and dynamic networks is greater in service providers’ environments.
Validating PCI DSS scope more frequently is likely to discover such overlooked changes before they can be exploited by an attacker.
Service providers typically have access to greater volumes of cardholder data than do merchants, or can provide an entry point that can be exploited to then compromise multiple other entities. Service providers also typically have larger and more complex networks that are subject to more frequent change. The probability of overlooked changes to scope in complex and dynamic networks is greater in service providers’ environments.
Validating PCI DSS scope more frequently is likely to discover such overlooked changes before they can be exploited by an attacker.
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.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.
Requirement 8.2.3
8.2.3
Defined Approach Requirements:
Additional requirement for service providers only: Service providers with remote access to customer premises use unique authentication factors for each customer premises
Customized Approach Objective:
A service provider’s credential used for one customer cannot be used for any other customer.
Applicability Notes:
This requirement applies only when the entity being assessed is a service provider.
This requirement is not intended to apply to service providers accessing their own shared services environments, where multiple customer environments are hosted.
If service provider employees use shared authentication factors to remotely access customer premises, these factors must be unique per customer and managed in accordance with Requirement 8.2.2.
Defined Approach Testing Procedures:
Defined Approach Requirements:
Additional requirement for service providers only: Service providers with remote access to customer premises use unique authentication factors for each customer premises
Customized Approach Objective:
A service provider’s credential used for one customer cannot be used for any other customer.
Applicability Notes:
This requirement applies only when the entity being assessed is a service provider.
This requirement is not intended to apply to service providers accessing their own shared services environments, where multiple customer environments are hosted.
If service provider employees use shared authentication factors to remotely access customer premises, these factors must be unique per customer and managed in accordance with Requirement 8.2.2.
Defined Approach Testing Procedures:
- 8.2.3 Additional testing procedure for service provider assessments only: Examine authentication policies and procedures and interview personnel to verify that service providers with remote access to customer premises use unique authentication factors for remote access to each customer premises.
Purpose:
Service providers with remote access to customer premises typically use this access to support POS POI systems or provide other remote services.
If a service provider uses the same authentication factors to access multiple customers, all the service provider’s customers can easily be compromised if an attacker compromises that one factor.
Criminals know this and deliberately target service providers looking for a shared authentication factor that gives them remote access to many merchants via that single factor.
Examples:
Technologies such as multi-factor mechanisms that provide a unique credential for each connection (such as a single-use password) could also meet the intent of this requirement.
Service providers with remote access to customer premises typically use this access to support POS POI systems or provide other remote services.
If a service provider uses the same authentication factors to access multiple customers, all the service provider’s customers can easily be compromised if an attacker compromises that one factor.
Criminals know this and deliberately target service providers looking for a shared authentication factor that gives them remote access to many merchants via that single factor.
Examples:
Technologies such as multi-factor mechanisms that provide a unique credential for each connection (such as a single-use password) could also meet the intent of this requirement.
Requirement 8.3.10.1
8.3.10.1
Defined Approach Requirements:
Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access (i.e., in any single-factor authentication implementation) then either:
Defined Approach Requirements:
Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access (i.e., in any single-factor authentication implementation) then either:
- Passwords/passphrases are changed at least once every 90 days,
OR
- The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.
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 is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
Until this requirement is effective on 31 March 2025, service providers may meet either Requirement 8.3.10 or 8.3.10.1.
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 is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
Until this requirement is effective on 31 March 2025, service providers may meet either Requirement 8.3.10 or 8.3.10.1.
Defined Approach Testing Procedures:
- 8.3.10.1 Additional testing procedure for service provider assessments only: If passwords/passphrases are used as the only authentication factor for customer user access, inspect system configuration settings to verify that passwords/passphrases are managed in accordance with ONE of the 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.
Dynamically analyzing an account’s security posture is another option that allows for more rapid detection and response to address potentially compromised credentials. Such analysis takes a number of data points which may include device integrity, location, access times, and the resources accessed to determine in real time whether an account can be granted access to a requested resource. In this way, access can be denied and accounts blocked if it is suspected that account credentials have been compromised.
Further Information:
For information about using dynamic analysis to manage user access to resources, refer to NIST SP 800-207 Zero Trust Architecture.
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.
Dynamically analyzing an account’s security posture is another option that allows for more rapid detection and response to address potentially compromised credentials. Such analysis takes a number of data points which may include device integrity, location, access times, and the resources accessed to determine in real time whether an account can be granted access to a requested resource. In this way, access can be denied and accounts blocked if it is suspected that account credentials have been compromised.
Further Information:
For information about using dynamic analysis to manage user access to resources, refer to NIST SP 800-207 Zero Trust Architecture.
Guideline for a healthy information system v.2.0 (EN):
3 STANDARD
/STANDARD
When an organization wants to outsource its information system or data, it must assess, in advance, the risks specific to outsourced services (controlling the information system, remote actions, shared hosting, etc.) in order to take into account the needs ans suitable security measures when creating the requirements applicable to the future service provider. The information security system risks inherent in this type of approach may be linked to the context of the outsourcing operation, but also deficient or incomplete contractual specifications.
Therefore, in order to run smoothly the operations, it is important to:
When an organization wants to outsource its information system or data, it must assess, in advance, the risks specific to outsourced services (controlling the information system, remote actions, shared hosting, etc.) in order to take into account the needs ans suitable security measures when creating the requirements applicable to the future service provider. The information security system risks inherent in this type of approach may be linked to the context of the outsourcing operation, but also deficient or incomplete contractual specifications.
Therefore, in order to run smoothly the operations, it is important to:
- carefully study the offers’ conditions, the option of adapting them to the specific needs and the limits of the service provider’s responsibility;
- impose a list of specific requirements on the service provider: contract reversibility, the carrying out of audits, backup and data recovery in a
- standardised open format, security maintenance over time, etc.
To formalise these commitments, the service provider will provide the customer with a security insurance plan detailed in the bid. This is a contractual document describing all of the specific measures that the applicants commit to implementing in order to guarantee the security requirements specified by the organization are met.
The use of digital solutions or tools (hosted in the Cloud for example) is not considered here as it comes under the area of managed services and, moreover, is not advisable when processing sensitive data.
The use of digital solutions or tools (hosted in the Cloud for example) is not considered here as it comes under the area of managed services and, moreover, is not advisable when processing sensitive data.
Стандарт № GMP Annex 11: Computerised Systems (RU) от 30.11.2011 "Правила надлежащей производственной практики. Приложение 11: Компьютеризированные системы":
Р. 2 п. 3 п.п. 2
3.2. Компетентность и надежность поставщиков являются ключевыми условиями выбора провайдеров программного продукта или услуг. Необходимость аудита должна быть основана на оценке рисков.
Р. 2 п. 3 п.п. 1
3.1. Если задействованы третьи лица (например, поставщики, провайдеры услуг)например, для поставки, установки, настройки, задания конфигурации, интегрирования, валидации, технического обслуживания (например, через удаленный доступ), модификации или поддержания компьютеризированных систем, связанных с ними услуг или обработки данных, то должны иметься надлежаще оформленные договоры между производителем и любыми третьими лицами. В этих договорах должна быть четко установлена ответственность третьих лиц. Аналогичные требования следует предъявлять к подразделениям информационных технологий производителя.
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.2.3
8.2.3
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Поставщики услуг с удаленным доступом к помещениям клиентов используют уникальные факторы аутентификации для каждого помещения клиента.
Цель Индивидуального подхода:
Учетные данные поставщика услуг, используемые для одного клиента, не могут быть использованы для любого другого клиента.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование не предназначено для применения к поставщикам услуг, получающим доступ к своим собственным средам общих служб, в которых размещены несколько клиентских сред.
Если сотрудники поставщика услуг используют общие факторы аутентификации для удаленного доступа к помещениям клиентов, эти факторы должны быть уникальными для каждого клиента и управляться в соответствии с требованием 8.2.2.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Поставщики услуг с удаленным доступом к помещениям клиентов используют уникальные факторы аутентификации для каждого помещения клиента.
Цель Индивидуального подхода:
Учетные данные поставщика услуг, используемые для одного клиента, не могут быть использованы для любого другого клиента.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование не предназначено для применения к поставщикам услуг, получающим доступ к своим собственным средам общих служб, в которых размещены несколько клиентских сред.
Если сотрудники поставщика услуг используют общие факторы аутентификации для удаленного доступа к помещениям клиентов, эти факторы должны быть уникальными для каждого клиента и управляться в соответствии с требованием 8.2.2.
Определенные Процедуры Тестирования Подхода:
- 8.2.3 Дополнительная процедура тестирования только для оценки поставщиков услуг: Изучите политики и процедуры аутентификации и опросите персонал, чтобы убедиться, что поставщики услуг с удаленным доступом к помещениям клиентов используют уникальные факторы аутентификации для удаленного доступа к помещениям каждого клиента.
Цель:
Поставщики услуг с удаленным доступом к помещениям клиентов обычно используют этот доступ для поддержки систем POS POI или предоставления других удаленных услуг.
Если поставщик услуг использует одни и те же факторы аутентификации для доступа к нескольким клиентам, все клиенты поставщика услуг могут быть легко скомпрометированы, если злоумышленник скомпрометирует этот один фактор.
Преступники знают это и намеренно нацеливаются на поставщиков услуг, ищущих общий фактор аутентификации, который дает им удаленный доступ ко многим продавцам через этот единственный фактор.
Примеры:
Такие технологии, как многофакторные механизмы, которые предоставляют уникальные учетные данные для каждого соединения (например, одноразовый пароль), также могут соответствовать цели этого требования.
Поставщики услуг с удаленным доступом к помещениям клиентов обычно используют этот доступ для поддержки систем POS POI или предоставления других удаленных услуг.
Если поставщик услуг использует одни и те же факторы аутентификации для доступа к нескольким клиентам, все клиенты поставщика услуг могут быть легко скомпрометированы, если злоумышленник скомпрометирует этот один фактор.
Преступники знают это и намеренно нацеливаются на поставщиков услуг, ищущих общий фактор аутентификации, который дает им удаленный доступ ко многим продавцам через этот единственный фактор.
Примеры:
Такие технологии, как многофакторные механизмы, которые предоставляют уникальные учетные данные для каждого соединения (например, одноразовый пароль), также могут соответствовать цели этого требования.
Requirement 8.3.10.1
8.3.10.1
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Если пароли / парольные фразы используются в качестве единственного фактора аутентификации для доступа пользователя клиента (т.е. в любой реализации однофакторной аутентификации), то либо:
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Если пароли / парольные фразы используются в качестве единственного фактора аутентификации для доступа пользователя клиента (т.е. в любой реализации однофакторной аутентификации), то либо:
- Пароли/парольные фразы меняются не реже одного раза в 90 дней,
ИЛИ
- Состояние безопасности учетных записей динамически анализируется, и соответственно автоматически определяется доступ к ресурсам в режиме реального времени.
Цель Индивидуального подхода:
Пароли/парольные фразы для клиентов поставщиков услуг не могут использоваться бесконечно.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование не распространяется на учетные записи пользователей-потребителей, получающих доступ к информации о своих собственных платежных картах.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
До тех пор, пока это требование не вступит в силу 31 марта 2025 года, поставщики услуг могут выполнять либо требование 8.3.10, либо 8.3.10.1.
Определенные Процедуры Тестирования Подхода:
Пароли/парольные фразы для клиентов поставщиков услуг не могут использоваться бесконечно.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование не распространяется на учетные записи пользователей-потребителей, получающих доступ к информации о своих собственных платежных картах.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
До тех пор, пока это требование не вступит в силу 31 марта 2025 года, поставщики услуг могут выполнять либо требование 8.3.10, либо 8.3.10.1.
Определенные Процедуры Тестирования Подхода:
- 8.3.10.1 Дополнительная процедура тестирования только для оценки поставщика услуг: Если пароли/парольные фразы используются в качестве единственного фактора аутентификации для доступа пользователя клиента, проверьте параметры конфигурации системы, чтобы убедиться, что управление паролями/парольными фразами осуществляется в соответствии с ОДНИМ из элементов, указанных в этом требовании.
Цель:
Использование пароля/парольной фразы в качестве единственного фактора аутентификации обеспечивает единую точку отказа в случае компрометации. Поэтому в этих реализациях необходимы средства контроля, чтобы свести к минимуму время, в течение которого может происходить вредоносная активность с использованием скомпрометированного пароля/ключевой фразы.
Надлежащая практика:
Пароли/парольные фразы, которые действительны в течение длительного времени без изменений, дают злоумышленникам больше времени для взлома пароля / фразы. Периодическая смена паролей дает злоумышленнику меньше времени для взлома пароля / парольной фразы и меньше времени для использования скомпрометированного пароля.
Динамический анализ состояния безопасности учетной записи - это еще один вариант, который позволяет более быстро обнаруживать и реагировать на потенциально скомпрометированные учетные данные. Для такого анализа требуется ряд точек данных, которые могут включать целостность устройства, местоположение, время доступа и доступные ресурсы, чтобы определить в режиме реального времени, может ли учетная запись получить доступ к запрошенному ресурсу. Таким образом, доступ может быть запрещен, а учетные записи заблокированы, если есть подозрение, что учетные данные учетной записи были скомпрометированы.
Дополнительная информация:
Для получения информации об использовании динамического анализа для управления доступом пользователей к ресурсам обратитесь к NIST SP 800-207 Архитектура нулевого доверия.
Использование пароля/парольной фразы в качестве единственного фактора аутентификации обеспечивает единую точку отказа в случае компрометации. Поэтому в этих реализациях необходимы средства контроля, чтобы свести к минимуму время, в течение которого может происходить вредоносная активность с использованием скомпрометированного пароля/ключевой фразы.
Надлежащая практика:
Пароли/парольные фразы, которые действительны в течение длительного времени без изменений, дают злоумышленникам больше времени для взлома пароля / фразы. Периодическая смена паролей дает злоумышленнику меньше времени для взлома пароля / парольной фразы и меньше времени для использования скомпрометированного пароля.
Динамический анализ состояния безопасности учетной записи - это еще один вариант, который позволяет более быстро обнаруживать и реагировать на потенциально скомпрометированные учетные данные. Для такого анализа требуется ряд точек данных, которые могут включать целостность устройства, местоположение, время доступа и доступные ресурсы, чтобы определить в режиме реального времени, может ли учетная запись получить доступ к запрошенному ресурсу. Таким образом, доступ может быть запрещен, а учетные записи заблокированы, если есть подозрение, что учетные данные учетной записи были скомпрометированы.
Дополнительная информация:
Для получения информации об использовании динамического анализа для управления доступом пользователей к ресурсам обратитесь к NIST SP 800-207 Архитектура нулевого доверия.
Requirement 12.5.2.1
12.5.2.1
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Область применения стандарта PCI DSS документируется и подтверждается организацией не реже одного раза в шесть месяцев и при значительных изменениях в среде, в которой он применяется. Как минимум, проверка области охвата включает в себя все элементы, указанные в требовании 12.5.2.
Цель Индивидуального подхода:
Точность области применения PCI DSS проверяется на постоянную точность с помощью всестороннего анализа и соответствующих технических мер.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Область применения стандарта PCI DSS документируется и подтверждается организацией не реже одного раза в шесть месяцев и при значительных изменениях в среде, в которой он применяется. Как минимум, проверка области охвата включает в себя все элементы, указанные в требовании 12.5.2.
Цель Индивидуального подхода:
Точность области применения PCI DSS проверяется на постоянную точность с помощью всестороннего анализа и соответствующих технических мер.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
- 12.5.2.1.дополнительная процедура тестирования только для оценок поставщиков услуг: Изучите документированные результаты проверок сферы охвата и опросите персонал, чтобы убедиться, что проверки соответствуют требованиям
- 12.5.2 выполняются:
- По крайней мере, раз в шесть месяцев, и
- После значительных изменений
- 12.5.2.1.b Дополнительная процедура тестирования только для оценок поставщиков услуг: Изучите документированные результаты проверок области применения, чтобы убедиться, что проверка области применения включает все элементы, указанные в Требовании 12.5.2.
Цель:
Поставщики услуг обычно имеют доступ к большему объему данных о держателях карт, чем торговцы, или могут предоставить точку входа, которую можно использовать для последующего компрометации множества других организаций. Поставщики услуг также, как правило, имеют более крупные и сложные сети, которые подвержены более частым изменениям. Вероятность незамеченных изменений в области применения в сложных и динамичных сетях выше в среде поставщиков услуг.
Более частая проверка области действия PCI DSS, скорее всего, позволит обнаружить такие пропущенные изменения до того, как они смогут быть использованы злоумышленником.
Поставщики услуг обычно имеют доступ к большему объему данных о держателях карт, чем торговцы, или могут предоставить точку входа, которую можно использовать для последующего компрометации множества других организаций. Поставщики услуг также, как правило, имеют более крупные и сложные сети, которые подвержены более частым изменениям. Вероятность незамеченных изменений в области применения в сложных и динамичных сетях выше в среде поставщиков услуг.
Более частая проверка области действия PCI DSS, скорее всего, позволит обнаружить такие пропущенные изменения до того, как они смогут быть использованы злоумышленником.
Requirement 12.5.3
12.5.3
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Значительные изменения в организационной структуре приводят к документированному (внутреннему) анализу влияния на сферу применения и применимость средств контроля PCI DSS, результаты которого доводятся до сведения исполнительного руководства.
Цель Индивидуального подхода:
Область применения PCI DSS подтверждена после значительных организационных изменений.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Значительные изменения в организационной структуре приводят к документированному (внутреннему) анализу влияния на сферу применения и применимость средств контроля PCI DSS, результаты которого доводятся до сведения исполнительного руководства.
Цель Индивидуального подхода:
Область применения PCI DSS подтверждена после значительных организационных изменений.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
- 12.5.3.дополнительная процедура тестирования только для оценки поставщиков услуг: Изучите политики и процедуры, чтобы убедиться, что процессы определены таким образом, что значительное изменение организационной структуры приводит к документированному анализу влияния на сферу применения и применимость средств контроля PCI DSS.
- 12.5.3.b Дополнительная процедура тестирования только для оценки поставщика услуг: Изучите документацию (например, протоколы собраний) и опросите ответственный персонал, чтобы убедиться, что существенные изменения в организационной структуре привели к документированным проверкам, которые включали все элементы, указанные в этом требовании, с результатами, сообщенными исполнительному руководству.
Цель:
Структура и управление организации определяют требования и протокол для эффективной и безопасной работы. Изменения в этой структуре могут оказать негативное влияние на существующие средства контроля и структуры путем перераспределения или удаления ресурсов, которые когда-то поддерживали средства контроля PCI DSS, или наследования новых обязанностей, которые, возможно, не имели установленных средств контроля. Поэтому важно пересматривать область применения и средства контроля PCI DSS при внесении изменений в структуру и управление организации, чтобы убедиться, что средства контроля установлены и активны.
Примеры:
Изменения в организационной структуре включают, но не ограничиваются ими, слияния или поглощения компаний, а также значительные изменения или переназначения персонала, отвечающего за контроль безопасности.
Структура и управление организации определяют требования и протокол для эффективной и безопасной работы. Изменения в этой структуре могут оказать негативное влияние на существующие средства контроля и структуры путем перераспределения или удаления ресурсов, которые когда-то поддерживали средства контроля PCI DSS, или наследования новых обязанностей, которые, возможно, не имели установленных средств контроля. Поэтому важно пересматривать область применения и средства контроля PCI DSS при внесении изменений в структуру и управление организации, чтобы убедиться, что средства контроля установлены и активны.
Примеры:
Изменения в организационной структуре включают, но не ограничиваются ими, слияния или поглощения компаний, а также значительные изменения или переназначения персонала, отвечающего за контроль безопасности.
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 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 на уровне руководства и дает возможность задавать соответствующие вопросы для определения эффективности программы и влияния на стратегические приоритеты.
Стандарт Банка России № СТО БР ИББС-1.4-2018 от 01.07.2018 "Управление риском нарушения информационной безопасности при аутсорсинге":
Р. 9 п. 6
9.6. При оценке возможности поставщика услуг обеспечить выполнение обязательств организации БС РФ следует рассмотреть следующие показатели:
- соблюдение требований к обеспечению ИБ, установленных для организации БС РФ законодательством РФ по защите информации (в том числе в соответствии с ГОСТ 57580.1-2017);
- возможность получения информации, необходимой для предоставления Банку России и уполномоченным органам исполнительной власти в рамках выполнения надзорных (контрольных) мероприятий в области защиты информации;
- возможность осуществления организацией БС РФ деятельности по мониторингу и контролю риска на‑ рушения ИБ;
- возможность организации БС РФ получать информацию о результатах проведения внешних аудитов обеспечения ИБ и внешних аудитов обеспечения непрерывности деятельности.
Р. 11 п. 6
11.6. Основные требования, предъявляемые к организациям, проводящим аудит информационной безопасности:
- независимость аудиторской организации от выполнения бизнес-функций организации БС РФ и поставщика услуг;
- обладание необходимой компетенцией и навыками выполнения аудиторских проверок, определенных в первую очередь опытом проведения проверок;
- использование передовых отечественных и международных практик аудиторских проверок;
- наличие рекомендаций Банка России о возможности привлечения аудиторской организации.
Р. 6 п. 9
6.9. Основное требование 8. Организации БС РФ при принятии решения об аутсорсинге существенных функций, при котором предполагается трансграничная передача защищаемой информации, следует убедиться в соблюдении требований:
- законодательства РФ, регулирующего вопросы трансграничной передачи персональных данных;
- законодательства РФ, устанавливающего обязанность обработки и хранения персональных данных на территории РФ;
- нормативных актов Банка России, устанавливающих обязанность кредитных организаций создавать и передавать Банку России резервные копии электронных баз данных, а также размещать резервные копии электронных баз данных на территории РФ;
- законодательства РФ, регулирующего вопросы лицензирования отдельных видов деятельности;
- законодательства РФ, регулирующего вопросы обеспечения безопасности критической информационной инфраструктуры.
В случае наличия у поставщика услуг подразделений и (или) дочерних предприятий за пределами РФ, а также при использовании самим поставщиком услуг аутсорсинга поставщик услуг должен предоставить организации БС РФ информацию о таких подразделениях, предприятиях или аутсорсинговых субподрядчиках (если они участвуют в оказании услуг аутсорсинга), выполняемых ими работах, часовых поясах и странах, в которых находятся их штаб-квартиры и из которых они ведут свою деятельность в целях выполнения соглашения об аутсорсинге для организации БС РФ. Необходимо учитывать возможность существования своих законодательных требований и ограничений, а также используемых разговорных языках и возможных культурных и религиозных особенностях в области обеспечения ИБ в юрисдикциях, в которых находятся поставщики услуг, их подразделения, дочерние предприятия и субподрядчики.
Трансграничная передача информации, составляющей банковскую тайну, допускается в обезличенной обобщенной (агрегированной) форме, за исключением случаев, установленных законодательством РФ.
Р. 9 п. 3
9.3. При оценке ресурсов, потенциала и возможностей поставщика услуг организации БС РФ необходимо учитывать следующие показатели:
- финансовое состояние поставщика услуг, наличие финансовых ресурсов, необходимых и достаточных для обеспечения ИБ при предоставлении организации БС РФ услуг аутсорсинга на протяжении всего срока действия соглашения. Для оценки финансового состояния поставщика услуг организацией БС РФ могут использоваться методы, аналогичные применяемым при оценке финансового состояния и потенциала кредиторов и иных контрагентов в организации БС РФ, результаты анализа или аудита финансового состояния (отчетности);
- наличие в штате поставщика услуг персонала в необходимом количестве и с достаточной квалификацией, реализация поставщиком услуг программ повышения квалификации персонала и реализации проведения аттестации персонала в соответствии с применимыми отечественными и международными системами аттестации (см. Приложение 1);
- наличие у поставщика услуг системы обеспечения ИБ;
- реализация политики обеспечения доверия к персоналу, которая должна соответствовать политике обеспечения доверия к персоналу, применяемой в организации БС РФ. В составе реализации такой политики необходимо рассматривать:
- определение, выполнение и регистрацию процедуры контроля деятельности работников, обладающих совокупностью полномочий, определяемых их ролями, позволяющими получить доступ к защищаемой информации организации БС РФ;
- определение, выполнение и регистрацию процедуры приема на работу, реализующие принцип “знать своего работника”, включающие проверку подлинности предоставленных документов, заявляемой квалификации, точности и полноты биографических фактов, а также проверку в части профессиональных навыков и оценку профессиональной пригодности;
- получение письменного обязательства работников поставщика услуг о соблюдении конфиденциальности, приверженности правилам корпоративной этики, включая требования по недопущению конфликта интересов;
- включение обязанности персонала поставщика услуг по выполнению требований к обеспечению ИБ, обработке ПДн, обеспечению сохранности защищаемой информации в трудовые контракты (соглашения, договоры) и (или) должностные инструкции;
- наличие у поставщика услуг необходимых лицензий, предусмотренных законодательством о лицензировании отдельных видов деятельности;
- показатели, характеризующие политику аутсорсинга поставщика услуг в части обеспечения ИБ.
Для оценки политики поставщика услуг может быть рекомендован перечень вопросов, представленный в Приложении 2.
Р. 9 п. 2
9.2. Основными целями оценки поставщика услуг являются:
- оценка ресурсов, потенциала и возможностей поставщика услуг обеспечить необходимый уровень ИБ при выполнении своих обязательств в рамках заключенного соглашения;
- оценка опыта и репутации поставщика услуг;
- оценка показателей деятельности поставщика услуг на основе метрик СВР, принятых организацией БС РФ для контроля и мониторинга риска нарушения ИБ при аутсорсинге существенных функций;
- оценка возможностей поставщика услуг обеспечивать выполнение обязательств организации БС РФ перед клиентами и контрагентами, а также Банком России и уполномоченными органами исполнительной власти в рамках выполнения надзорных (контрольных) мероприятий в области защиты информации, как если бы бизнес-функции, переданные на аутсорсинг, выполнялись самостоятельно организацией БС РФ.
Р. 10 п. 3
10.3. Содержание соглашения об аутсорсинге должно однозначно среди прочего определять:
- перечень существенных функций, связанных с обработкой защищаемой информации или обеспечением ИБ (реализацией процессов обеспечения ИБ), передаваемых на аутсорсинг поставщику услуг;
- обязанности и разделение зоны ответственности поставщика услуг и организации БС РФ в обеспечении ИБ при аутсорсинге существенных функций;
- требования к показателям качества деятельности поставщика услуг, определяемым на основе метрик управления риском нарушения ИБ организацией БС РФ в рамках процедур управления риском;
- требования к уровню и качеству предоставления услуг в части обеспечения ИБ и создания условий непрерывности предоставления финансовых услуг (требования к SLA) и к инструментам по мониторингу этого уровня;
- требования к гарантиям поставщика услуг (в том числе финансовым) в случае наступления риска нарушения ИБ;
- требования к инфраструктуре оказания услуг, включая инфраструктуру обеспечения ИБ и обеспечения непрерывности выполнения бизнес-функций и их восстановления после инцидентов ИБ;
- обязанность поставщика услуг обеспечить возможность проведения организацией БС РФ или привлекаемой организацией БС РФ консалтинговой или аудиторской организацией контрольных мероприятий в рамках мониторинга риска нарушения ИБ;
- обязанность по обеспечению сторонами конфиденциальности информации;
- обязанность поставщика услуг проходить периодический аудит с целью подтверждения качества предоставления услуг в части обеспечения ИБ и создания условий непрерывности предоставления финансовых услуг;
- обязанность поставщика услуг информировать организацию БС РФ об инцидентах ИБ, включая НСД к защищаемой информации, в течение 3‑х часов после выявления инцидента ИБ, а также о мерах, предпринятых для управления наступившими инцидентами;
- порядок разбора конфликтов в случае нарушения поставщиком услуг условий оказания услуг, а также в случае несогласия поставщика услуг признавать факт реализации риска нарушения ИБ или инцидента ИБ;
- обязанность поставщика услуг информировать организацию БС РФ обо всех факторах, связанных с возникновением риска нарушения ИБ при аутсорсинге существенных функций, включая тип событий и обстоятельства их реализации;
- обязанность поставщика услуг передавать всю необходимую информацию организации БС РФ для выполнения своих обязательств перед Банком России и уполномоченными органами исполнительной власти в рамках выполнения надзорных (контрольных) мероприятий в области защиты информации;
- возможность пересмотра и изменения условий соглашения по инициативе организации БС РФ в следующих случаях:
- наличие у организации БС РФ необходимости сохранить надлежащий уровень контроля и управления в отношении риска нарушения ИБ при аутсорсинге существенных функций;
- наличие у организации БС РФ необходимости принять соответствующие меры для выполнения своих обязательств перед клиентами и контрагентами, а также перед Банком России и уполномоченными органами исполнительной власти;
- возможность проведения регулярных (не реже одного раза в квартал) встреч представителей организации БС РФ и поставщика услуг для обсуждения статуса выполнения соглашения об аутсорсинге в части вопросов обеспечения ИБ;
- рекомендуемые основания для отказа организаций БС РФ от исполнения соглашения с поставщиком услуг в одностороннем внесудебном порядке в случае:
- смены владельцев (участников) поставщика услуг;
- изменения финансового состояния поставщика услуг, его потенциала, ресурсов и возможностей в отношении выполнения услуг аутсорсинга существенных функций;
- нарушения поставщиком услуг требований к уровню и качеству предоставления услуг в части обеспечения ИБ и создания условий непрерывности предоставления финансовых услуг (требования к SLA);
- препятствия (отказа) со стороны поставщика услуг реализации мониторинга и контроля риска нарушения ИБ со стороны организации БС РФ или со стороны независимой аудиторской организации;
- возникновения риска нарушения ИБ, превышающего уровень, определенный организацией БС РФ в качестве приемлемого;
- возникновения инцидентов нарушения ИБ;
- минимальный срок выполнения условий расторжения соглашения об аутсорсинге существенных функций, необходимый организации БС РФ для возобновления выполнения бизнес-функций собственными ресурсами или с привлечением иного поставщика услуг в случаях расторжения действующего соглашения;
- условия привлечения поставщиком услуг субподрядчиков, предусматривающие:
- право организации БС РФ сохранить способность мониторинга и контроля риска нарушения ИБ при аутсорсинге существенных функций в случаях привлечения поставщиком услуг субподрядчиков;
- ограничения на передачу субподрядчику обработки защищаемой информации;
- ответственность поставщика услуг за все действия субподрядчика в части вопросов обеспечения ИБ, в том числе ответственность за соблюдение законодательства РФ;
- обязанность поставщика услуг обеспечить уведомление и получать предварительное согласование организации БС РФ при привлечении субподрядчиков для выполнения существенных функций орга‑ низации БС РФ;
- обязанность поставщика услуг предоставить организации БС РФ документы (в том числе политики, стандарты), разработанные поставщиком услуг для обеспечения ИБ
- обязанность поставщика услуг обеспечить соблюдение требований к защите информации, установленных для организации БС РФ, в том числе:
- в рамках законодательства о национальной платежной системе;
- в области защиты информации ограниченного доступа, включая защиту ПДн;
- в области безопасности критической информационной инфраструктуры;
- в области лицензирования отдельных видов деятельности;
- нормативных актов Банка России, устанавливающих обязанность кредитных организаций по созданию и передаче Банку России резервных копий электронных баз данных, а также размещению их на территории РФ;
- политику предоставления поставщику услуг доступа к защищаемой информации и инфраструктуре организации БС РФ;
- описание контактных данных лица, ответственного за реализацию соглашения об аутсорсинге со стороны поставщика услуг, а также процедур эскалации возможных конфликтов при оказании услуг аутсорсинга;
- требования к работникам поставщика услуг, задействованным в обеспечении ИБ.
Р. 6 п. 3
6.3. Основное требование 2. Организация БС РФ должна разработать, применять и обеспечить контроль программы аутсорсинга, предусматривающей вопросы управления риском нарушения ИБ (далее - программа аутсорсинга).
Программа аутсорсинга должна определять:
- состав и содержание мероприятий по управлению риском нарушения ИБ при аутсорсинге существенных функций;
- состав и содержание мероприятий по мониторингу и контролю деятельности поставщика услуг по обеспечению ИБ при аутсорсинге существенных функций;
- возможность привлечения поставщиком услуг субподрядчиков при оказании услуг аутсорсинга, а также требования к таким субподрядчикам.
В части мероприятий по управлению риском нарушения ИБ и контролю над ним программа аутсорсинга должна определять:
- задачи и зоны ответственности исполнительного органа организации БС РФ для цели реализации управления риском нарушения ИБ и контроля над ним при аутсорсинге;
- требования к составу и содержанию мероприятий по оценке организацией БС РФ риска нарушения ИБ при принятии решения о передаче бизнес-функций на аутсорсинг;
- требования к составу и содержанию мероприятий по оценке организацией БС РФ возможности поставщика услуг обеспечить должный уровень ИБ при аутсорсинге существенных функций и по обеспечению наличия внутренней компетенции организации БС РФ для проведения такого рода оценки;
- требования к содержанию соглашений, связанных с передачей выполнения бизнес-функций на аутсорсинг.
В части состава и содержания мероприятий по мониторингу и контролю деятельности поставщика услуг программа аутсорсинга должна определять:
- требования к составу и содержанию мероприятий по контролю обеспечения непрерывности деятельности поставщиков услуг при реализации бизнес-функций организации БС РФ в части обеспечения ИБ;
- требования к составу и содержанию мероприятий по постоянному мониторингу и контролю риска нарушения ИБ при аутсорсинге.
Организация БС РФ должна реализовать контроль выполнения программы аутсорсинга, в том числе со стороны службы ИБ и службы внутреннего контроля, а также контроль со стороны исполнительного органа организации БС РФ.
Р. 8 п. 2
8.2. Основным содержанием задач руководства организации БС РФ при аутсорсинге, определенным в настоящем стандарте, является:
- установление политики и программы аутсорсинга существенных функций в соответствии с требованиями к их содержанию, определенными в настоящем стандарте, и реализация контроля за их выполнением;
- установление механизмов управления и контроля в отношении уровня риска нарушения ИБ в рамках заключения соглашений с поставщиком услуг;
- контроль над реализацией и выполнением деятельности по управлению риском нарушения ИБ;
- принятие решения о возможности аутсорсинга только на основании оценки риска нарушения ИБ;
- обеспечение наличия плана действий организации БС РФ в случае отказа поставщика услуг от выполнения своих обязательств, реализация которого позволит обеспечить необходимый уровень ИБ для продолжения выполнения бизнес-функций в течение периода времени, приемлемого для организации БС РФ (далее - стратегия "выхода").
Р. 6 п. 2
6.2. Основное требование 1. В случае планирования передачи выполнения бизнес-функций поставщикам услуг на аутсорсинг организации БС РФ следует установить политику в отношении аутсорсинга существенных функций (далее - политика аутсорсинга).
Политика аутсорсинга должна среди прочего однозначно определять:
- возможность аутсорсинга бизнес-функций, при выполнении которых осуществляется обработка защищаемой информации;
- возможность аутсорсинга бизнес-функций, невыполнение или ненадлежащее выполнение которых поставщиком услуг создает условия для реализации или реализует инциденты ИБ;
- возможность аутсорсинга только в случае соблюдения требований законодательства РФ в области обработки ПДн и информации, составляющей банковскую тайну, в частности возможность аутсорсинга в случае надлежащего получения соглашения субъектов ПДн;
- возможность аутсорсинга только в случае соблюдения требований законодательства РФ в области защиты информации;
- возможность аутсорсинга только в случае отсутствия прямых или косвенных ограничений на реализацию полномочий Банка России и уполномоченных органов исполнительной власти в рамках выполнения надзорных (контрольных) мероприятий в части вопросов защиты информации;
- возможность аутсорсинга только в случае реализации организацией БС РФ надлежащего управления риском нарушения ИБ и контроля над ним.
Политика аутсорсинга существенных функций должна быть принята советом директоров (наблюдательным советом) организации БС РФ, а в случае его отсутствия - исполнительным органом организации БС РФ.
В отношении аутсорсинга существенных функций организация БС РФ должна реализовать процедуры внутреннего контроля соответствия принятой политики аутсорсинга, результаты которого должны рассматриваться советом директоров (наблюдательным советом) организации БС РФ.
Р. 12 п. 7
12.7. Контрольные ключевые параметры качества сервиса ИБ, вносимые в соглашение, должны быть измеримыми и представляться в виде числовых показателей (метрик). Состав ключевых показателей (ме‑ трик) качества определяется в зависимости от состава предоставляемых сервисов ИБ. Ключевыми пока‑ зателями (метриками) качества сервиса ИБ могут выступать среди прочих:
- временные показатели (метрики):
- время реакции на обращение организации БС РФ
- время, прошедшее с момента поступления и регистрации запроса на обслуживание (сообщение организации БС РФ об инциденте) до фактического начала работ по факту обращения;
- время закрытия инцидента SLA – время, прошедшее с момента фактического начала работ над инцидентом SLA до его фактического закрытия;
- время решения инцидента SLA – суммарное время, прошедшее с момента поступления и регистрации обращения до закрытия заявки на обслуживание;
- максимальное время реакции поставщика услуг – максимальное время, необходимое поставщику услуг при аварийных ситуациях для устранения их последствий;
- время устранения уязвимости – время, прошедшее с момента обнаружения уязвимости до ее устранения;
- качественные характеристики:
- число предотвращенных утечек информации по отношению к общему числу реализованных и предотвращенных утечек информации;
- число предотвращенных фишинговых атак по отношению к общему числу реализованных и предотвращенных фишинговых атак;
- соотношение числа запросов на обслуживание (сообщение организации БС РФ об инциденте) к числу инцидентов SLA;
- число повторных инцидентов SLA определенного типа;
- соотношение найденных и устраненных уязвимостей;
- качественные метрики:
- уровень брака – это количественное или процентное выражение количества инцидентов SLA за определенный (отчетный) период времени;
- техническое качество – уровень технического качества программно-аппаратного комплекса, используемого для предоставления сервисов ИБ и обеспечивающего гарантию непрерывности предоставления финансовых услуг;
- удовлетворенность качеством обслуживания – степень соответствия реализации сервиса ИБ потребности организации БС РФ, определяемой на основании опросов, проводимых самостоятельно организацией БС РФ и (или) с привлечением независимой организации;
- метрики доступности и непрерывности сервисов ИБ:
- доступность сервисов ИБ организации БС РФ – количество времени или временной промежуток, в котором сервисы ИБ, выполняемые поставщиком услуг, остаются доступными;
- время восстановления сервисов ИБ в случае прерывания (RTO, Recovery time objective).
Количество метрик, включаемых в SLA, должно быть достаточным для проведения объективной оценки качества предоставления сервисов ИБ поставщиком услуг.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.20
А.5.20 Учет ИБ в соглашениях с поставщиками
С каждым поставщиком, в зависимости от типа отношений с ним, должны быть установлены и согласованы соответствующие требования ИБ
С каждым поставщиком, в зависимости от типа отношений с ним, должны быть установлены и согласованы соответствующие требования ИБ
NIST Cybersecurity Framework (EN):
ID.SC-1
ID.SC-1: Cyber supply chain risk management processes are identified, established, assessed, managed, and agreed to by organizational stakeholders
ID.BE-1
ID.BE-1: The organization’s role in the supply chain is identified and communicated
ID.SC-3
ID.SC-3: Contracts with suppliers and third-party partners are used to implement appropriate measures designed to meet the objectives of an organization’s cybersecurity program and Cyber Supply Chain Risk Management Plan.
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.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.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.