Куда я попал?
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022
Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А
A.15.2.1
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 8":
ПОН.8
ПОН.8 Распределение ответственности в рамках реализации процесса обеспечения операционной надежности при привлечении поставщиков услуг (в том числе поставщиков облачных услуг)
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 6. п.п. 4
6.4. Кредитные организации должны обеспечивать выполнение следующих требований к взаимодействию с поставщиками услуг в сфере информационных технологий:
- нейтрализация информационных угроз, связанных с привлечением поставщиков услуг в сфере информационных технологий, в том числе защита объектов информационной инфраструктуры от возможной реализации информационных угроз со стороны поставщиков услуг в сфере информационных технологий;
- нейтрализация информационных угроз, обусловленных технологической зависимостью функционирования объектов информационной инфраструктуры кредитной организации от поставщиков услуг в сфере информационных технологий.
NIST Cybersecurity Framework (RU):
DE.CM-7
DE.CM-7: Выполняется мониторинг неавторизованных персонала, подключений, устройств и программного обеспечения
ID.SC-1
ID.SC-1: Идентфицированы, устанавлены, оцениваются, управляются и согласовываются заинтересованными сторонами организации все процессы управления рисками в кибер-цепочке
ID.SC-2
ID.SC-2: С использованием процесса оценки рисков в киберцепочке поставок идентфицированы, расставлены приоритеты и оценены поставщики и партнеры критически важных информационных систем, компонентов и услуг
ID.SC-5
ID.SC-5: С критичными поставщиками проводится планирование, тестирование реагирования и восстановления
ID.BE-1
ID.BE-1: Определена и сообщена роль организации в цепочке поставок
DE.CM-6
DE.CM-6: Контролируется активность внешних поставщиков услуг для обнаружения потенциальных событий кибербезопасности
ID.BE-4
ID.BE-4: Установлены зависимости и критические функции для предоставления критически важных услуг
ID.SC-4
ID.SC-4: Производиться контроль поставщиков и партнеров, чтобы подтвердить, что они выполнили свои обязательства в соответствии с требованиями. Проводятся обзоры аудитов, сводки результатов тестов или другие эквивалентные оценки поставщиков
PR.MA-2
PR.MA-2: Удаленное обслуживание организационных активов одобрено, зарегистрировано и выполняется способом, который предотвращает несанкционированный доступ
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
РВН.5
РВН.5 Планирование, реализация, контроль и совершенствование мероприятий, направленных на уменьшение негативного влияния риска внутреннего нарушителя, применяемых в отношении работников поставщика услуг, привлекаемого в рамках выполнения бизнес- и технологических процессов.
РВН.6.3
РВН.6.3 Осуществление контроля за выполнением поставщиком требований, установленных в рамках договорных отношений.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 12.8.4
12.8.4
Defined Approach Requirements:
A program is implemented to monitor TPSPs’ PCI DSS compliance status at least once every 12 months.
Customized Approach Objective:
The PCI DSS compliance status of TPSPs is verified periodically.
Applicability Notes:
Where an entity has an agreement with a TPSP for meeting PCI DSS requirements on behalf of the entity (for example, via a firewall service), the entity must work with the TPSP to make sure the applicable PCI DSS requirements are met. If the TPSP does not meet those applicable PCI DSS requirements, then those requirements are also “not in place” for the entity.
Defined Approach Testing Procedures:
Defined Approach Requirements:
A program is implemented to monitor TPSPs’ PCI DSS compliance status at least once every 12 months.
Customized Approach Objective:
The PCI DSS compliance status of TPSPs is verified periodically.
Applicability Notes:
Where an entity has an agreement with a TPSP for meeting PCI DSS requirements on behalf of the entity (for example, via a firewall service), the entity must work with the TPSP to make sure the applicable PCI DSS requirements are met. If the TPSP does not meet those applicable PCI DSS requirements, then those requirements are also “not in place” for the entity.
Defined Approach Testing Procedures:
- 12.8.4.a Examine policies and procedures to verify that processes are defined to monitor TPSPs’ PCI DSS compliance status at least once every 12 months.
- 12.8.4.b Examine documentation and interview responsible personnel to verify that the PCI DSS compliance status of each TPSP is monitored at least once every 12 months.
Purpose:
Knowing the PCI DSS compliance status of all engaged TPSPs provides assurance and awareness about whether they comply with the requirements applicable to the services they offer to the organization.
Good Practice:
If the TPSP offers a variety of services, the compliance status the entity monitors should be specific to those services delivered to the entity and those services in scope for the entity’s PCI DSS assessment.
If a TPSP has a PCI DSS Attestation of Compliance (AOC), the expectation is that the TPSP should provide that to customers upon request to demonstrate their PCI DSS compliance status.
If the TPSP did not undergo a PCI DSS assessment, it may be able to provide other sufficient evidence to demonstrate that it has met the applicable requirements without undergoing a formal compliance validation. For example, the TPSP can provide specific evidence to the entity’s assessor so the assessor can confirm applicable requirements are met. Alternatively, the TPSP can elect to undergo multiple on-demand assessments by each of its customers’ assessors, with each assessment targeted to confirm that applicable requirements are met.
Further Information:
For more information about third-party service providers, refer to:
Knowing the PCI DSS compliance status of all engaged TPSPs provides assurance and awareness about whether they comply with the requirements applicable to the services they offer to the organization.
Good Practice:
If the TPSP offers a variety of services, the compliance status the entity monitors should be specific to those services delivered to the entity and those services in scope for the entity’s PCI DSS assessment.
If a TPSP has a PCI DSS Attestation of Compliance (AOC), the expectation is that the TPSP should provide that to customers upon request to demonstrate their PCI DSS compliance status.
If the TPSP did not undergo a PCI DSS assessment, it may be able to provide other sufficient evidence to demonstrate that it has met the applicable requirements without undergoing a formal compliance validation. For example, the TPSP can provide specific evidence to the entity’s assessor so the assessor can confirm applicable requirements are met. Alternatively, the TPSP can elect to undergo multiple on-demand assessments by each of its customers’ assessors, with each assessment targeted to confirm that applicable requirements are met.
Further Information:
For more information about third-party service providers, refer to:
- PCI DSS section: Use of Third-Party Service Providers.
- Information Supplement: Third-Party Security Assurance.
Requirement 12.8.5
12.8.5
Defined Approach Requirements:
Information is maintained about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between the TPSP and the entity.
Customized Approach Objective:
Records detailing the PCI DSS requirements and related system components for which each TPSP is solely or jointly responsible, are maintained and reviewed periodically.
Defined Approach Testing Procedures:
Defined Approach Requirements:
Information is maintained about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between the TPSP and the entity.
Customized Approach Objective:
Records detailing the PCI DSS requirements and related system components for which each TPSP is solely or jointly responsible, are maintained and reviewed periodically.
Defined Approach Testing Procedures:
- 12.8.5.a Examine policies and procedures to verify that processes are defined to maintain information about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between both the TPSP and the entity.
- 12.8.5.b Examine documentation and interview personnel to verify the entity maintains information about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between both entities.
Purpose:
It is important that the entity understands which PCI DSS requirements and sub-requirements its TPSPs have agreed to meet, which requirements are shared between the TPSP and the entity, and for those that are shared, specifics about how the requirements are shared and which entity is responsible for meeting each sub-requirement.
Without this shared understanding, it is inevitable that the entity and the TPSP will assume a given PCI DSS sub-requirement is the responsibility of the other party, and therefore that subrequirement may not be addressed at all.
The specific information an entity maintains will depend on the particular agreement with their providers, the type of service, etc. TPSPs may define their PCI DSS responsibilities to be the same for all their customers; otherwise, this responsibility should be agreed upon by both the entity and TPSP.
Good Practice:
Entities can document these responsibilities via a matrix that identifies all applicable PCI DSS requirements and indicates for each requirement whether the entity or TPSP is responsible for meeting that requirement or whether it is a shared responsibility. This type of document is often referred to as a responsibility matrix.
It is also important for entities 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 how the primary TPSP is monitoring performance of the service and the PCI DSS compliance status of the secondary TPSP(s). Note that it is the responsibility of the primary TPSP to manage and monitor any secondary TPSPs.
Further Information:
Refer to Information Supplement: Third-Party Security Assurance for a sample responsibility matrix template.
It is important that the entity understands which PCI DSS requirements and sub-requirements its TPSPs have agreed to meet, which requirements are shared between the TPSP and the entity, and for those that are shared, specifics about how the requirements are shared and which entity is responsible for meeting each sub-requirement.
Without this shared understanding, it is inevitable that the entity and the TPSP will assume a given PCI DSS sub-requirement is the responsibility of the other party, and therefore that subrequirement may not be addressed at all.
The specific information an entity maintains will depend on the particular agreement with their providers, the type of service, etc. TPSPs may define their PCI DSS responsibilities to be the same for all their customers; otherwise, this responsibility should be agreed upon by both the entity and TPSP.
Good Practice:
Entities can document these responsibilities via a matrix that identifies all applicable PCI DSS requirements and indicates for each requirement whether the entity or TPSP is responsible for meeting that requirement or whether it is a shared responsibility. This type of document is often referred to as a responsibility matrix.
It is also important for entities 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 how the primary TPSP is monitoring performance of the service and the PCI DSS compliance status of the secondary TPSP(s). Note that it is the responsibility of the primary TPSP to manage and monitor any secondary TPSPs.
Further Information:
Refer to Information Supplement: Third-Party Security Assurance for a sample responsibility matrix template.
Requirement 12.4.2
12.4.2
Defined Approach Requirements:
Additional requirement for service providers only: Reviews are performed at least once every three months to confirm that personnel are performing their tasks in accordance with all security policies and operational procedures. Reviews are performed by personnel other than those responsible for performing the given task and include, but are not limited to, the following tasks:
Defined Approach Requirements:
Additional requirement for service providers only: Reviews are performed at least once every three months to confirm that personnel are performing their tasks in accordance with all security policies and operational procedures. Reviews are performed by personnel other than those responsible for performing the given task and include, but are not limited to, the following tasks:
- Daily log reviews.
- Configuration reviews for network security controls.
- Applying configuration standards to new systems.
- Responding to security alerts.
- Change-management processes.
Customized Approach Objective:
The operational effectiveness of critical PCI DSS controls is verified periodically by manual inspection of records.
Applicability Notes:
This requirement applies only when the entity being assessed is a service provider.
Defined Approach Testing Procedures:
The operational effectiveness of critical PCI DSS controls is verified periodically by manual inspection of records.
Applicability Notes:
This requirement applies only when the entity being assessed is a service provider.
Defined Approach Testing Procedures:
- 12.4.2.a Additional testing procedure for service provider assessments only: Examine policies and procedures to verify that processes are defined for conducting reviews to confirm that personnel are performing their tasks in accordance with all security policies and all operational procedures, including but not limited to the tasks specified in this requirement.
- 12.4.2.b Additional testing procedure for service provider assessments only: Interview responsible personnel and examine records of reviews to verify that reviews are performed:
- At least once every three months.
- By personnel other than those responsible for performing the given task.
Purpose:
Regularly confirming that security policies and procedures are being followed provides assurance that the expected controls are active and working as intended. This requirement is distinct from other requirements that specify a task to be performed. The objective of these reviews is not to reperform other PCI DSS requirements, but to confirm that security activities are being performed on an ongoing basis.
Good Practice:
These reviews can also be used to verify that appropriate evidence is being maintained—for example, audit logs, vulnerability scan reports, reviews of network security control rulesets—to assist in the entity’s preparation for its next PCI DSS assessment.
Examples:
Looking at Requirement 1.2.7 as one example, Requirement 12.4.2 is met by confirming, at least once every three months, that reviews of configurations of network security controls have occurred at the required frequency. On the other hand, Requirement 1.2.7 is met by reviewing those configurations as specified in the requirement.
Regularly confirming that security policies and procedures are being followed provides assurance that the expected controls are active and working as intended. This requirement is distinct from other requirements that specify a task to be performed. The objective of these reviews is not to reperform other PCI DSS requirements, but to confirm that security activities are being performed on an ongoing basis.
Good Practice:
These reviews can also be used to verify that appropriate evidence is being maintained—for example, audit logs, vulnerability scan reports, reviews of network security control rulesets—to assist in the entity’s preparation for its next PCI DSS assessment.
Examples:
Looking at Requirement 1.2.7 as one example, Requirement 12.4.2 is met by confirming, at least once every three months, that reviews of configurations of network security controls have occurred at the required frequency. On the other hand, Requirement 1.2.7 is met by reviewing those configurations as specified in the requirement.
Requirement 12.4.2.1
12.4.2.1
Defined Approach Requirements:
Additional requirement for service providers only: Reviews conducted in accordance with Requirement 12.4.2 are documented to include:
Defined Approach Requirements:
Additional requirement for service providers only: Reviews conducted in accordance with Requirement 12.4.2 are documented to include:
- Results of the reviews.
- Documented remediation actions taken for any tasks that were found to not be performed at Requirement 12.4.2.
- Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program.
Customized Approach Objective:
Findings from operational effectiveness reviews are evaluated by management; appropriate remediation activities are implemented.
Applicability Notes:
This requirement applies only when the entity being assessed is a service provider.
Defined Approach Testing Procedures:
Findings from operational effectiveness reviews are evaluated by management; appropriate remediation activities are implemented.
Applicability Notes:
This requirement applies only when the entity being assessed is a service provider.
Defined Approach Testing Procedures:
- 12.4.2.1 Additional testing procedure for service provider assessments only: Examine documentation from the reviews conducted in accordance with PCI DSS Requirement
- 12.4.2 to verify the documentation includes all elements specified in this requirement.
Purpose:
The intent of these independent checks is to confirm whether security activities are being performed on an ongoing basis. These reviews can also be used to verify that appropriate evidence is being maintained—for example, audit logs, vulnerability scan reports, reviews of network security control rulesets—to assist in the entity’s preparation for its next PCI DSS assessment.
The intent of these independent checks is to confirm whether security activities are being performed on an ongoing basis. These reviews can also be used to verify that appropriate evidence is being maintained—for example, audit logs, vulnerability scan reports, reviews of network security control rulesets—to assist in the entity’s preparation for its next PCI DSS assessment.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 12.8.4
12.8.4
Определенные Требования к Подходу:
Внедрена программа для мониторинга статуса соответствия TPSP PCI DSS не реже одного раза в 12 месяцев.
Цель Индивидуального подхода:
Статус соответствия TPSP стандарту PCI DSS периодически проверяется.
Примечания по применению:
Если у организации есть соглашение с TPSP о выполнении требований PCI DSS от имени организации (например, через службу брандмауэра), организация должна работать с TPSP, чтобы убедиться, что применимые требования PCI DSS соблюдены. Если TPSP не соответствует этим применимым требованиям PCI DSS, то эти требования также “не действуют” для организации.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Внедрена программа для мониторинга статуса соответствия TPSP PCI DSS не реже одного раза в 12 месяцев.
Цель Индивидуального подхода:
Статус соответствия TPSP стандарту PCI DSS периодически проверяется.
Примечания по применению:
Если у организации есть соглашение с TPSP о выполнении требований PCI DSS от имени организации (например, через службу брандмауэра), организация должна работать с TPSP, чтобы убедиться, что применимые требования PCI DSS соблюдены. Если TPSP не соответствует этим применимым требованиям PCI DSS, то эти требования также “не действуют” для организации.
Определенные Процедуры Тестирования Подхода:
- 12.8.4.a Изучайте политики и процедуры, чтобы убедиться, что определены процессы для мониторинга статуса соответствия TPSP PCI DSS не реже одного раза в 12 месяцев.
- 12.8.4.b Изучите документацию и опросите ответственный персонал, чтобы убедиться, что статус соответствия PCI DSS каждого TPSP контролируется не реже одного раза в 12 месяцев.
Цель:
Знание статуса соответствия PCI DSS всех задействованных TPPS обеспечивает уверенность и осведомленность о том, соответствуют ли они требованиям, применимым к услугам, которые они предлагают организации.
Надлежащая практика:
Если TPSP предлагает различные услуги, статус соответствия, который отслеживает организация, должен быть специфичным для тех услуг, которые предоставляются организации, и тех услуг, которые подпадают под оценку PCI DSS организации.
Если у TPSP есть сертификат соответствия PCI DSS (AOC), ожидается, что TPSP должен предоставить его клиентам по запросу, чтобы продемонстрировать их статус соответствия PCI DSS.
Если TPSP не проходил оценку PCI DSS, он может быть в состоянии предоставить другие достаточные доказательства, чтобы продемонстрировать, что он соответствует применимым требованиям, не проходя формальную проверку соответствия. Например, TPSP может предоставить конкретные доказательства эксперту по оценке организации, чтобы эксперт мог подтвердить выполнение применимых требований. В качестве альтернативы, TPSP может выбрать проведение нескольких оценок по требованию каждым из оценщиков своих клиентов, причем каждая оценка направлена на подтверждение соответствия применимым требованиям.
Дополнительная информация:
Для получения дополнительной информации о сторонних поставщиках услуг обратитесь к:
Знание статуса соответствия PCI DSS всех задействованных TPPS обеспечивает уверенность и осведомленность о том, соответствуют ли они требованиям, применимым к услугам, которые они предлагают организации.
Надлежащая практика:
Если TPSP предлагает различные услуги, статус соответствия, который отслеживает организация, должен быть специфичным для тех услуг, которые предоставляются организации, и тех услуг, которые подпадают под оценку PCI DSS организации.
Если у TPSP есть сертификат соответствия PCI DSS (AOC), ожидается, что TPSP должен предоставить его клиентам по запросу, чтобы продемонстрировать их статус соответствия PCI DSS.
Если TPSP не проходил оценку PCI DSS, он может быть в состоянии предоставить другие достаточные доказательства, чтобы продемонстрировать, что он соответствует применимым требованиям, не проходя формальную проверку соответствия. Например, TPSP может предоставить конкретные доказательства эксперту по оценке организации, чтобы эксперт мог подтвердить выполнение применимых требований. В качестве альтернативы, TPSP может выбрать проведение нескольких оценок по требованию каждым из оценщиков своих клиентов, причем каждая оценка направлена на подтверждение соответствия применимым требованиям.
Дополнительная информация:
Для получения дополнительной информации о сторонних поставщиках услуг обратитесь к:
- Раздел PCI DSS: Использование сторонних поставщиков услуг.
- Информационное Дополнение: Обеспечение безопасности Третьей Стороной.
Requirement 12.4.2.1
12.4.2.1
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Проверки, проведенные в соответствии с требованием 12.4.2, документируются, чтобы включать:
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Проверки, проведенные в соответствии с требованием 12.4.2, документируются, чтобы включать:
- Результаты обзоров.
- Документированные действия по исправлению, предпринятые для любых задач, которые, как было установлено, не были выполнены в соответствии с требованием 12.4.2.
- Проверка и подписание результатов персоналом, ответственным за программу соответствия требованиям PCI DSS.
Цель Индивидуального подхода:
Результаты проверок операционной эффективности оцениваются руководством; осуществляются соответствующие мероприятия по исправлению положения.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Определенные Процедуры Тестирования Подхода:
Результаты проверок операционной эффективности оцениваются руководством; осуществляются соответствующие мероприятия по исправлению положения.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Определенные Процедуры Тестирования Подхода:
- 12.4.2.1 Дополнительная процедура тестирования только для оценки поставщика услуг: Изучите документацию по результатам проверок, проведенных в соответствии с требованием PCI DSS
- 12.4.2, чтобы убедиться, что документация включает все элементы, указанные в этом требовании.
Цель:
Цель этих независимых проверок состоит в том, чтобы подтвердить, выполняются ли действия по обеспечению безопасности на постоянной основе. Эти проверки также могут быть использованы для проверки наличия надлежащих доказательств — например, журналов аудита, отчетов о проверке уязвимостей, обзоров наборов правил контроля сетевой безопасности — чтобы помочь организации подготовиться к следующей оценке PCI DSS.
Цель этих независимых проверок состоит в том, чтобы подтвердить, выполняются ли действия по обеспечению безопасности на постоянной основе. Эти проверки также могут быть использованы для проверки наличия надлежащих доказательств — например, журналов аудита, отчетов о проверке уязвимостей, обзоров наборов правил контроля сетевой безопасности — чтобы помочь организации подготовиться к следующей оценке PCI DSS.
Requirement 12.8.5
12.8.5
Определенные Требования к Подходу:
Сохраняется информация о том, какие требования PCI DSS выполняются каждым TPSP, которые управляются организацией, и о любых требованиях, которые совместно используются между TPSP и организацией.
Цель Индивидуального подхода:
Записи с подробным описанием требований PCI DSS и связанных с ними системных компонентов, за которые каждый TPSP несет единоличную или совместную ответственность, ведутся и периодически пересматриваются.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Сохраняется информация о том, какие требования PCI DSS выполняются каждым TPSP, которые управляются организацией, и о любых требованиях, которые совместно используются между TPSP и организацией.
Цель Индивидуального подхода:
Записи с подробным описанием требований PCI DSS и связанных с ними системных компонентов, за которые каждый TPSP несет единоличную или совместную ответственность, ведутся и периодически пересматриваются.
Определенные Процедуры Тестирования Подхода:
- 12.8.5.a Изучите политики и процедуры, чтобы убедиться, что процессы определены для поддержания информации о том, какие требования PCI DSS управляются каждым TPSP, которые управляются организацией, и любые, которые являются общими как для TPSP, так и для организации.
- 12.8.5.b Изучите документацию и опросите персонал, чтобы убедиться, что организация хранит информацию о том, какие требования PCI DSS выполняются каждым TPSP, которые управляются организацией, и любые, которые являются общими для обеих организаций.
Цель:
Важно, чтобы организация понимала, какие требования и подзаконные требования PCI DSS согласились выполнять ее TPSP, какие требования являются общими для TPSP и организации, а для тех, которые являются общими, конкретные сведения о том, как распределяются требования и какая организация отвечает за выполнение каждого подзаконного требования.
Без этого общего понимания неизбежно, что организация и TPSP будут считать, что данное дополнительное требование PCI DSS является обязанностью другой стороны, и, следовательно, это дополнительное требование может вообще не выполняться.
Конкретная информация, которую хранит организация, будет зависеть от конкретного соглашения с ее поставщиками, типа услуги и т.д. TPSP могут определять свои обязанности по PCI DSS как одинаковые для всех своих клиентов; в противном случае эта ответственность должна быть согласована как организацией, так и TPSP.
Надлежащая практика:
Организации могут документировать эти обязанности с помощью матрицы, которая идентифицирует все применимые требования PCI DSS и указывает для каждого требования, несет ли организация или TPSP ответственность за выполнение этого требования или это общая ответственность. Этот тип документа часто называют матрицей ответственности.
Для организаций также важно понимать, имеют ли какие-либо TPSP “вложенные” отношения с другими TPSP, что означает, что первичный TPSP заключает контракты с другим TPSP(ами) в целях предоставления услуги. Важно понимать, полагается ли первичный TPSP на вторичный TPSP(ы) для достижения общего соответствия сервиса, и как первичный TPSP отслеживает производительность сервиса и статус соответствия PCI DSS вторичного TPSP(ов). Обратите внимание, что ответственность за управление и мониторинг любых вторичных TPSP лежит на первичном TPSP.
Дополнительная информация:
Образец шаблона матрицы ответственности приведен в Информационном дополнении: Обеспечение безопасности третьей стороной.
Важно, чтобы организация понимала, какие требования и подзаконные требования PCI DSS согласились выполнять ее TPSP, какие требования являются общими для TPSP и организации, а для тех, которые являются общими, конкретные сведения о том, как распределяются требования и какая организация отвечает за выполнение каждого подзаконного требования.
Без этого общего понимания неизбежно, что организация и TPSP будут считать, что данное дополнительное требование PCI DSS является обязанностью другой стороны, и, следовательно, это дополнительное требование может вообще не выполняться.
Конкретная информация, которую хранит организация, будет зависеть от конкретного соглашения с ее поставщиками, типа услуги и т.д. TPSP могут определять свои обязанности по PCI DSS как одинаковые для всех своих клиентов; в противном случае эта ответственность должна быть согласована как организацией, так и TPSP.
Надлежащая практика:
Организации могут документировать эти обязанности с помощью матрицы, которая идентифицирует все применимые требования PCI DSS и указывает для каждого требования, несет ли организация или TPSP ответственность за выполнение этого требования или это общая ответственность. Этот тип документа часто называют матрицей ответственности.
Для организаций также важно понимать, имеют ли какие-либо TPSP “вложенные” отношения с другими TPSP, что означает, что первичный TPSP заключает контракты с другим TPSP(ами) в целях предоставления услуги. Важно понимать, полагается ли первичный TPSP на вторичный TPSP(ы) для достижения общего соответствия сервиса, и как первичный TPSP отслеживает производительность сервиса и статус соответствия PCI DSS вторичного TPSP(ов). Обратите внимание, что ответственность за управление и мониторинг любых вторичных TPSP лежит на первичном TPSP.
Дополнительная информация:
Образец шаблона матрицы ответственности приведен в Информационном дополнении: Обеспечение безопасности третьей стороной.
Requirement 12.4.2
12.4.2
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Проверки проводятся не реже одного раза в три месяца, чтобы подтвердить, что персонал выполняет свои задачи в соответствии со всеми политиками безопасности и операционными процедурами. Проверки выполняются персоналом, не являющимся ответственным за выполнение данной задачи, и включают, но не ограничиваются следующими задачами:
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Проверки проводятся не реже одного раза в три месяца, чтобы подтвердить, что персонал выполняет свои задачи в соответствии со всеми политиками безопасности и операционными процедурами. Проверки выполняются персоналом, не являющимся ответственным за выполнение данной задачи, и включают, но не ограничиваются следующими задачами:
- Ежедневные обзоры журналов.
- Проверка конфигурации для средств управления сетевой безопасностью.
- Применение стандартов конфигурации к новым системам.
- Реагирование на предупреждения системы безопасности.
- Процессы управления изменениями.
Цель Индивидуального подхода:
Оперативная эффективность критических средств контроля PCI DSS периодически проверяется путем ручной проверки записей.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Определенные Процедуры Тестирования Подхода:
Оперативная эффективность критических средств контроля PCI DSS периодически проверяется путем ручной проверки записей.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Определенные Процедуры Тестирования Подхода:
- 12.4.2.дополнительная процедура тестирования только для оценки поставщика услуг: Изучите политики и процедуры, чтобы убедиться, что определены процессы для проведения проверок, чтобы подтвердить, что персонал выполняет свои задачи в соответствии со всеми политиками безопасности и всеми операционными процедурами, включая, но не ограничиваясь задачами, указанными в этом требовании.
- 12.4.2.b Дополнительная процедура тестирования только для оценки поставщика услуг: Опросите ответственный персонал и изучите записи проверок, чтобы убедиться, что проверки проводятся:
- По крайней мере, раз в три месяца.
- Персоналом, отличным от тех, кто отвечает за выполнение данной задачи.
Цель:
Регулярное подтверждение соблюдения политик и процедур безопасности обеспечивает уверенность в том, что ожидаемые средства контроля активны и работают должным образом. Это требование отличается от других требований, которые определяют задачу, подлежащую выполнению. Целью этих проверок является не повторное выполнение других требований PCI DSS, а подтверждение того, что действия по обеспечению безопасности выполняются на постоянной основе.
Надлежащая практика:
Эти проверки также могут быть использованы для проверки наличия надлежащих доказательств — например, журналов аудита, отчетов о проверке уязвимостей, обзоров наборов правил контроля сетевой безопасности — чтобы помочь организации подготовиться к следующей оценке PCI DSS.
Примеры:
Рассматривая требование 1.2.7 в качестве одного из примеров, Требование 12.4.2 выполняется путем подтверждения, по крайней мере, один раз в три месяца, что проверки конфигураций средств управления сетевой безопасностью проводились с требуемой периодичностью. С другой стороны, требование 1.2.7 выполняется путем проверки этих конфигураций, как указано в требовании.
Регулярное подтверждение соблюдения политик и процедур безопасности обеспечивает уверенность в том, что ожидаемые средства контроля активны и работают должным образом. Это требование отличается от других требований, которые определяют задачу, подлежащую выполнению. Целью этих проверок является не повторное выполнение других требований PCI DSS, а подтверждение того, что действия по обеспечению безопасности выполняются на постоянной основе.
Надлежащая практика:
Эти проверки также могут быть использованы для проверки наличия надлежащих доказательств — например, журналов аудита, отчетов о проверке уязвимостей, обзоров наборов правил контроля сетевой безопасности — чтобы помочь организации подготовиться к следующей оценке PCI DSS.
Примеры:
Рассматривая требование 1.2.7 в качестве одного из примеров, Требование 12.4.2 выполняется путем подтверждения, по крайней мере, один раз в три месяца, что проверки конфигураций средств управления сетевой безопасностью проводились с требуемой периодичностью. С другой стороны, требование 1.2.7 выполняется путем проверки этих конфигураций, как указано в требовании.
Стандарт Банка России № СТО БР ИББС-1.4-2018 от 01.07.2018 "Управление риском нарушения информационной безопасности при аутсорсинге":
Р. 9 п. 7
9.7. Организация БС РФ может выполнить оценку поставщика услуг следующими способами:
- самостоятельно работниками организации БС РФ;
- с привлечением аудиторской или консалтинговой организации (независимой от поставщика услуг), обладающей необходимым опытом и компетенцией для проведения оценки поставщика услуг.
Р. 9 п. 1
9.1. Одним из основных элементов успешной реализации управления риском нарушения ИБ при аутсорсинге существенных функций является всесторонняя оценка потенциала поставщика услуг выполнить свои обязательства в соответствии с требованиями по управлению риском нарушения ИБ, применяемыми организацией БС РФ.
Оценку поставщика услуг рекомендуется проводить перед заключением с ним соглашения об аутсор‑ синге, а также на периодической (регулярной) основе.
Оценку поставщика услуг рекомендуется проводить перед заключением с ним соглашения об аутсор‑ синге, а также на периодической (регулярной) основе.
Р. 9 п. 11
9.11. Оценка поставщика услуг должна носить периодический характер и входить в состав мониторинга и контроля риска нарушения ИБ при аутсорсинге существенных функций, установленный разделом 11 настоящего стандарта. Оценку поставщика услуг рекомендуется проводить не реже одного раза в два года. Конкретные интервалы проведения оценки организация БС РФ определяет самостоятельно.
Р. 11 п. 5
11.5. Важной частью мониторинга и контроля риска нарушения ИБ при аутсорсинге существенных функций является прохождение поставщиком услуг регулярного аудита.
Организация БС РФ должна обеспечить анализ результатов проведения периодического аудита с целью:
Организация БС РФ должна обеспечить анализ результатов проведения периодического аудита с целью:
- обновления (уточнения) перечня существенных функций, связанных с обработкой защищаемой инфор‑ мации или обеспечением ИБ, передаваемых на аутсорсинг поставщику услуг;
- контроля надлежащего и своевременного предоставления поставщиком услуг отчетности в части аутсорсинга существенных функций;
- оценки показателей качества деятельности поставщика услуг, определенных на основе показателей (метрик) управления риском нарушения ИБ;
- соблюдения поставщиком услуг установленных соглашением параметров уровня и качества предоставления услуг в части обеспечения ИБ и создания условий непрерывности предоставления финансовых услуг (требований к SLA).
Поставщик услуг должен проходить периодический аудит с целью подтверждения качества предостав‑ ления услуг в части:
- защиты информации в соответствии с требованием законодательства РФ;
- создания условий непрерывности предоставления финансовых услуг организации БС РФ.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.22
А.5.22 Мониторинг, проверка и управление изменениями предоставляемых сервисов
Организация должна мониторить, регулярно, анализировать, проверять и управлять изменениями в практиках ИБ в отношении поставщиков и предоставлении ими сервисов.
Организация должна мониторить, регулярно, анализировать, проверять и управлять изменениями в практиках ИБ в отношении поставщиков и предоставлении ими сервисов.
Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":
п. 1.7.
1.7. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны обеспечивать выполнение следующих требований в отношении взаимодействия с поставщиками услуг:
- управление риском реализации информационных угроз при привлечении поставщиков услуг, в том числе защиту своих объектов информационной инфраструктуры от возможной реализации информационных угроз со стороны поставщиков услуг;
- управление риском технологической зависимости функционирования своих объектов информационной инфраструктуры от поставщиков услуг.
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
PR.MA-2
PR.MA-2: Remote maintenance of organizational assets is approved, logged, and performed in a manner that prevents unauthorized access
DE.CM-6
DE.CM-6: External service provider activity is monitored to detect potential cybersecurity events
ID.BE-4
ID.BE-4: Dependencies and critical functions for delivery of critical services are established
ID.SC-2
ID.SC-2: Suppliers and third party partners of information systems, components, and services are identified, prioritized, and assessed using a cyber supply chain risk assessment process
ID.SC-5
ID.SC-5: Response and recovery planning and testing are conducted with suppliers and third-party providers
DE.CM-7
DE.CM-7: Monitoring for unauthorized personnel, connections, devices, and software is performed
ID.BE-1
ID.BE-1: The organization’s role in the supply chain is identified and communicated
ID.SC-4
ID.SC-4: Suppliers and third-party partners are routinely assessed using audits, test results, or other forms of evaluations to confirm they are meeting their contractual obligations.
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
15.2.1
15.2.1 Мониторинг и анализ услуг поставщика
Мера обеспечения ИБ
Организации должны регулярно проводить мониторинг, проверку и аудит деятельности поставщика по предоставлению услуг.
Руководство по применению
Мониторинг и анализ услуг, предоставляемых поставщиком, должны обеспечивать уверенность в том, что положения и условия, касающиеся ИБ, отраженные в соглашениях, выполняются и что инциденты и проблемы в области ИБ решаются должным образом.
Это должно реализовываться при управлении услугами через процесс взаимодействия между организацией и поставщиком, чтобы:
- a) осуществлять мониторинг уровней предоставления услуг с целью проверки соблюдения условий соглашений;
- b) анализировать отчеты об услугах, подготовленные поставщиком, и организовывать регулярные рабочие встречи, как это определено соглашениями;
- c) проводить аудиты поставщиков вместе с анализом отчетов независимых аудиторов, если они есть, и осуществлять последующие действия по выявленным проблемам;
- d) предоставлять информацию об инцидентах ИБ и анализировать эту информацию в соответствии с требованиями соглашений и любых вспомогательных методических рекомендаций и процедур;
- e) анализировать контрольные записи поставщиков и записи о событиях безопасности, эксплуатационных проблемах, сбоях, обнаруженных ошибках и нарушениях, связанных с поставляемой услугой;
- f) решать любые выявленные проблемы и управлять ими;
- g) анализировать в разрезе аспектов ИБ отношения поставщика с его подрядчиками;
- h) гарантировать, что поставщик сохраняет достаточную способность обслуживания согласно работоспособным планам, разработанным для обеспечения согласованных уровней непрерывности обслуживания при значительных сбоях и аварийных ситуациях (раздел 17).
Ответственность за управление отношениями с поставщиками следует возлагать на специально назначенное лицо или группу по управлению услугами. Кроме того, организация должна обеспечить, чтобы поставщики установили обязанности по анализу соответствия и обеспечению выполнения требований соглашения. Должны быть выделены достаточные ресурсы с необходимыми техническими навыками для мониторинга того, что требования соглашения, в частности требования ИБ, выполняются. Необходимо предпринимать соответствующие действия при обнаружении недостатков в оказании услуг.
Организация должна поддерживать достаточный общий контроль и прозрачность всех аспектов безопасности в отношении информации ограниченного доступа или устройств обработки информации, к которым поставщик имеет доступ, использует их или управляет ими. Организация должна поддерживать прозрачность действий, связанных с безопасностью, таких как управление изменениями, выявление уязвимостей, а также составление отчетов об инцидентах ИБ и реагирование на них с помощью установленного процесса оповещения.
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.5.22
А.5.22 Monitoring, review and change management of supplier services
The organization shall regularly monitor, review, evaluate and manage change in supplier information security practices and service delivery.
The organization shall regularly monitor, review, evaluate and manage change in supplier information security practices and service delivery.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.