Куда я попал?
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021
Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности
15.2.2
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
ГОСТ Р № 57580.3-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Управление риском реализации информационных угроз и обеспечение операционной надежности. Общие положения.":
ВИО.11.3
ВИО.11.3 Сторонних информационных сервисов поставщиков услуг.
ВИО.11.2
ВИО.11.2 Взаимосвязей и взаимозависимостей между финансовой организацией и причастными сторонами (за исключением клиентов финансовой организации) в рамках выполнения бизнеси технологических процессов, в том числе взаимосвязей и взаимозависимостей объектов информатизации;
NIST Cybersecurity Framework (RU):
ID.SC-4
ID.SC-4: Производиться контроль поставщиков и партнеров, чтобы подтвердить, что они выполнили свои обязательства в соответствии с требованиями. Проводятся обзоры аудитов, сводки результатов тестов или другие эквивалентные оценки поставщиков
ID.BE-1
ID.BE-1: Определена и сообщена роль организации в цепочке поставок
ID.SC-2
ID.SC-2: С использованием процесса оценки рисков в киберцепочке поставок идентфицированы, расставлены приоритеты и оценены поставщики и партнеры критически важных информационных систем, компонентов и услуг
ID.SC-1
ID.SC-1: Идентфицированы, устанавлены, оцениваются, управляются и согласовываются заинтересованными сторонами организации все процессы управления рисками в кибер-цепочке
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
ВПУ.3.2
ВПУ.3.2 Анализ деятельности поставщиков услуг (в том числе до заключения соглашений на поставку объектов информатизации и (или) предоставление сторонних информационных сервисов), включая оценку реализуемых поставщиком услуг процедур по обеспечению безопасности на этапах жизненного цикла поставляемых объектов информатизации и минимизации риска их несанкционированной модификации на этапах поставки;
ВПУ.3.1
ВПУ.3.1 Определение приоритета в отношении поставщиков услуг, реализующих необходимые процедуры по обеспечению безопасности на этапах жизненного цикла поставляемых объектов информатизации, в том числе обеспечивающих «прозрачность» в отношении реализуемых ими процессов производства и сопровождения объектов информатизации, а также имеющих необходимую зрелость собственных процессов обеспечения безопасности цепи поставок, подтвержденную посредством проведения независимой оценки (внешнего аудита)**;
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
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 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.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.
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.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.15.2.2
A.15.2.2 Управление изменениями услуг поставщика
Мера обеспечения информационной безопасности: Требуется управлять изменениями в предоставляемых поставщиками услугах, включая поддержку и улучшение существующих политик, процедур, а также мер и средств информационной безопасности, с учетом категории информации бизнеса, задействованных систем и процессов, а также результатов переоценки рисков информационной безопасности
Мера обеспечения информационной безопасности: Требуется управлять изменениями в предоставляемых поставщиками услугах, включая поддержку и улучшение существующих политик, процедур, а также мер и средств информационной безопасности, с учетом категории информации бизнеса, задействованных систем и процессов, а также результатов переоценки рисков информационной безопасности
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 8.2.3
8.2.3
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Поставщики услуг с удаленным доступом к помещениям клиентов используют уникальные факторы аутентификации для каждого помещения клиента.
Цель Индивидуального подхода:
Учетные данные поставщика услуг, используемые для одного клиента, не могут быть использованы для любого другого клиента.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование не предназначено для применения к поставщикам услуг, получающим доступ к своим собственным средам общих служб, в которых размещены несколько клиентских сред.
Если сотрудники поставщика услуг используют общие факторы аутентификации для удаленного доступа к помещениям клиентов, эти факторы должны быть уникальными для каждого клиента и управляться в соответствии с требованием 8.2.2.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Поставщики услуг с удаленным доступом к помещениям клиентов используют уникальные факторы аутентификации для каждого помещения клиента.
Цель Индивидуального подхода:
Учетные данные поставщика услуг, используемые для одного клиента, не могут быть использованы для любого другого клиента.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование не предназначено для применения к поставщикам услуг, получающим доступ к своим собственным средам общих служб, в которых размещены несколько клиентских сред.
Если сотрудники поставщика услуг используют общие факторы аутентификации для удаленного доступа к помещениям клиентов, эти факторы должны быть уникальными для каждого клиента и управляться в соответствии с требованием 8.2.2.
Определенные Процедуры Тестирования Подхода:
- 8.2.3 Дополнительная процедура тестирования только для оценки поставщиков услуг: Изучите политики и процедуры аутентификации и опросите персонал, чтобы убедиться, что поставщики услуг с удаленным доступом к помещениям клиентов используют уникальные факторы аутентификации для удаленного доступа к помещениям каждого клиента.
Цель:
Поставщики услуг с удаленным доступом к помещениям клиентов обычно используют этот доступ для поддержки систем POS POI или предоставления других удаленных услуг.
Если поставщик услуг использует одни и те же факторы аутентификации для доступа к нескольким клиентам, все клиенты поставщика услуг могут быть легко скомпрометированы, если злоумышленник скомпрометирует этот один фактор.
Преступники знают это и намеренно нацеливаются на поставщиков услуг, ищущих общий фактор аутентификации, который дает им удаленный доступ ко многим продавцам через этот единственный фактор.
Примеры:
Такие технологии, как многофакторные механизмы, которые предоставляют уникальные учетные данные для каждого соединения (например, одноразовый пароль), также могут соответствовать цели этого требования.
Поставщики услуг с удаленным доступом к помещениям клиентов обычно используют этот доступ для поддержки систем POS POI или предоставления других удаленных услуг.
Если поставщик услуг использует одни и те же факторы аутентификации для доступа к нескольким клиентам, все клиенты поставщика услуг могут быть легко скомпрометированы, если злоумышленник скомпрометирует этот один фактор.
Преступники знают это и намеренно нацеливаются на поставщиков услуг, ищущих общий фактор аутентификации, который дает им удаленный доступ ко многим продавцам через этот единственный фактор.
Примеры:
Такие технологии, как многофакторные механизмы, которые предоставляют уникальные учетные данные для каждого соединения (например, одноразовый пароль), также могут соответствовать цели этого требования.
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.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, скорее всего, позволит обнаружить такие пропущенные изменения до того, как они смогут быть использованы злоумышленником.
Стандарт Банка России № СТО БР ИББС-1.4-2018 от 01.07.2018 "Управление риском нарушения информационной безопасности при аутсорсинге":
Р. 11 п. 5
11.5. Важной частью мониторинга и контроля риска нарушения ИБ при аутсорсинге существенных функций является прохождение поставщиком услуг регулярного аудита.
Организация БС РФ должна обеспечить анализ результатов проведения периодического аудита с целью:
Организация БС РФ должна обеспечить анализ результатов проведения периодического аудита с целью:
- обновления (уточнения) перечня существенных функций, связанных с обработкой защищаемой инфор‑ мации или обеспечением ИБ, передаваемых на аутсорсинг поставщику услуг;
- контроля надлежащего и своевременного предоставления поставщиком услуг отчетности в части аутсорсинга существенных функций;
- оценки показателей качества деятельности поставщика услуг, определенных на основе показателей (метрик) управления риском нарушения ИБ;
- соблюдения поставщиком услуг установленных соглашением параметров уровня и качества предоставления услуг в части обеспечения ИБ и создания условий непрерывности предоставления финансовых услуг (требований к SLA).
Поставщик услуг должен проходить периодический аудит с целью подтверждения качества предостав‑ ления услуг в части:
- защиты информации в соответствии с требованием законодательства РФ;
- создания условий непрерывности предоставления финансовых услуг организации БС РФ.
Р. 9 п. 11
9.11. Оценка поставщика услуг должна носить периодический характер и входить в состав мониторинга и контроля риска нарушения ИБ при аутсорсинге существенных функций, установленный разделом 11 настоящего стандарта. Оценку поставщика услуг рекомендуется проводить не реже одного раза в два года. Конкретные интервалы проведения оценки организация БС РФ определяет самостоятельно.
Р. 9 п. 1
9.1. Одним из основных элементов успешной реализации управления риском нарушения ИБ при аутсорсинге существенных функций является всесторонняя оценка потенциала поставщика услуг выполнить свои обязательства в соответствии с требованиями по управлению риском нарушения ИБ, применяемыми организацией БС РФ.
Оценку поставщика услуг рекомендуется проводить перед заключением с ним соглашения об аутсор‑ синге, а также на периодической (регулярной) основе.
Оценку поставщика услуг рекомендуется проводить перед заключением с ним соглашения об аутсор‑ синге, а также на периодической (регулярной) основе.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.22
А.5.22 Мониторинг, проверка и управление изменениями предоставляемых сервисов
Организация должна мониторить, регулярно, анализировать, проверять и управлять изменениями в практиках ИБ в отношении поставщиков и предоставлении ими сервисов.
Организация должна мониторить, регулярно, анализировать, проверять и управлять изменениями в практиках ИБ в отношении поставщиков и предоставлении ими сервисов.
NIST Cybersecurity Framework (EN):
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.
ID.BE-1
ID.BE-1: The organization’s role in the supply chain is identified and communicated
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-1
ID.SC-1: Cyber supply chain risk management processes are identified, established, assessed, managed, and agreed to by organizational stakeholders
Стандарт № 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-файлов и соглашаетесь с Политикой обработки персональных данных.