Куда я попал?
SECURITM это SGRC система, ? автоматизирующая процессы в службах информационной безопасности. SECURITM помогает построить и управлять ИСПДн, КИИ, ГИС, СМИБ/СУИБ, банковскими системами защиты.
А еще SECURITM это место для обмена опытом и наработками для служб безопасности.

NIST Cybersecurity Framework (EN)

Framework

ID.SC-4

Для проведения оценки соответствия по документу войдите в систему.

Похожие требования

ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 8":
ПОН.8
ПОН.8 Распределение ответственности в рамках реализации процесса обеспечения операционной надежности при привлечении поставщиков услуг (в том числе поставщиков облачных услуг)
ГОСТ Р № 57580.3-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Управление риском реализации информационных угроз и обеспечение операционной надежности. Общие положения.":
ВИО.21
ВИО.21 Оценка риска реализации информационных угроз, которому финансовая организация подвергает или подвергается со стороны причастных сторон (за исключением клиентов финансовой организации), с учетом степени взаимосвязи и взаимозависимости между финансовой организацией и причастными сторонами (за исключением клиентов финансовой организации), в том числе степени взаимосвязи и взаимозависимости между их объектами информатизации.
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 6. п.п. 4
6.4. Кредитные организации должны обеспечивать выполнение следующих требований к взаимодействию с поставщиками услуг в сфере информационных технологий:
  • нейтрализация информационных угроз, связанных с привлечением поставщиков услуг в сфере информационных технологий, в том числе защита объектов информационной инфраструктуры от возможной реализации информационных угроз со стороны поставщиков услуг в сфере информационных технологий;
  • нейтрализация информационных угроз, обусловленных технологической зависимостью функционирования объектов информационной инфраструктуры кредитной организации от поставщиков услуг в сфере информационных технологий.
ГОСТ Р № 22301 от 01.01.2022 "Надежность в технике. Системы менеджмента непрерывности деятельности. Требования":
Р. 6 п. 3
 6.3 Планирование изменений в системе менеджмента непрерывностью деятельности 
Если организация определяет необходимость изменений в СМНД, включая определенные в разделе 10, изменения должны быть выполнены в плановом порядке. 
Организация должна учитывать: 
  • а) цель изменений и их возможные последствия; 
  • b) обеспечение целостности СМНД; 
  • с) наличие ресурсов; 
  • d) распределение или перераспределение обязанностей и полномочий. 
Р. 8 п. 3 пп. 4
 8.3.4 Требования к ресурсам 
Организация должна определить требования к ресурсам для реализации выбранных решений по обеспечению непрерывности деятельности. Рассматриваемые виды ресурсов должны включать (перечень может быть дополнен) следующим: 
  • а) люди; 
  • b) информация и данные; 
  • с) физическая инфраструктура, такая как здания, рабочие места или другие объекты и связанное с ним оборудование; 
  • d) оборудование и расходные материалы; 
  • е) системы информационно-коммуникационных технологий (ИКТ); 
  • f) транспорт и логистика; 
  • g) финансы; 
  • h) партнеры и поставщики. 
Р. 9 п. 2 пп. 2
 9.2.2 Программа(ы) аудита 
Организация должна: 
  • а) планировать, устанавливать, внедрять и поддерживать в рабочем состоянии программу(ы) аудита, включая требования к частоте проведения, методам, распределению обязанностей, планированию и отчетности, при этом необходимо учитывать важность соответствующих процессов и результаты предыдущих аудитов; 
  • b) определять критерии и область применения каждого аудита; 
  • с) выбирать аудиторов и проводить аудиты так. чтобы обеспечить объективность и беспристрастность процесса аудита; 
  • d) обеспечить, чтобы результаты аудита были доведены до сведения соответствующих руководителей; 
  • е) хранить документированную информацию в качестве объективных свидетельств реализации программ(ы) аудита и результатов аудита; 
  • f) обеспечить, чтобы все необходимые корректирующие действия по устранению обнаруженных несоответствий и их причин были выполнены без неоправданной задержки; 
  • g) обеспечить, чтобы последующие аудиторские действия предпринимались с учетом верификации предпринятых действий и отчетности о результатах верификации. 
Р. 6 п. 2 пп. 2
 6.2.2 Определение целей в области обеспечения непрерывности деятельности 
При планировании способов достижения целей в области обеспечения непрерывности деятельности организация должна определить: 
  • а) что необходимо сделать; 
  • b) какие необходимы ресурсы; 
  • с) ответственных; 
  • d) сроки достижения целей; 
  • е) способы оценки результатов. 
Р. 8 п. 1
 8.1 Оперативное планирование и управление 
Организация должна планировать, выполнять и контролировать процессы, необходимые для выполнения требований и осуществления действий, определенных в 6.1: 
  • а) путем установления критериев состояния процессов;
  • b) осуществления контроля и управления процессами в соответствии с критериями; 
  • с) хранения документированной информации в объеме, необходимом для уверенности в том. что процессы выполнены в соответствии с планом. 
Организация должна управлять запланированными изменениями и анализировать последствия непреднамеренных изменений, принимая меры для смягчения всех неблагоприятных последствий, при необходимости. Организация должна обеспечить управление процессами аутсорсинга и цепочкой поставок. 
Р. 9 п. 3 пп. 2
 9.3.2 Входные данные для анализа со стороны руководства 
Анализ со стороны руководства должен включать рассмотрение: 
  • а) статуса действий по результатам предыдущего анализа со стороны руководства; 
  • b) изменения во внешних и внутренних проблемах, которые имеют отношение к СМНД; 
  • с) информации о показателях работы СМНД, включая тенденции: 
  1. 1) несоответствий и корректирующих действий; 
  2. 2) результатов мониторинга и оценки измерений; 
  3. 3) результатов аудита; 
  • d) отзывов заинтересованных сторон; 
  • е) необходимости изменений СМНД. включая политику и цели; 
  • f) процедур и ресурсов, которые можно использовать в организации для улучшения показателей результативности СМНД; 
  • g) информации, полученной на основе воздействий анализа на деятельность и оценки риска; 
  • h) результатов оценки документации и возможностей по обеспечению непрерывности деятельности (см. 8.6); 
  • i) риска или проблем, которые не были адекватно рассмотрены при предыдущей оценке риска; 
  • j) извлеченных уроков и действий, возникших в результате промахов и нарушения деятельности организации; 
  • к) возможностей постоянного улучшения. 
NIST Cybersecurity Framework (RU):
ID.SC-4
ID.SC-4: Производиться контроль поставщиков и партнеров, чтобы подтвердить, что они выполнили свои обязательства в соответствии с требованиями. Проводятся обзоры аудитов, сводки результатов тестов или другие эквивалентные оценки поставщиков 
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
РВН.5
РВН.5 Планирование, реализация, контроль и совершенствование мероприятий, направленных на уменьшение негативного влияния риска внутреннего нарушителя, применяемых в отношении работников поставщика услуг, привлекаемого в рамках выполнения бизнес- и технологических процессов.
ВПУ.3.3
ВПУ.3.3 Оценку квалификации, опыта и репутации поставщиков услуг;
ВПУ.3.5
ВПУ.3.5 Выявление слабостей или недостатков цепи поставок посредством проведения независимой оценки (внешнего аудита)**;
ВПУ.10
ВПУ.10 Принятие решений по объектам информатизации, сопровождение (техническая поддержка и выпуск обновлений) которых поставщиками прекращено, включая:
  • отказ от эксплуатации и замену объектов информатизации, сопровождение (техническая поддержка и выпуск обновлений) которых поставщиками прекращено;
  • обоснование и документирование (фиксация) решения о дальнейшей эксплуатации объектов информатизации (их компонентов), сопровождение (техническая поддержка и выпуск обновлений) которых поставщиками прекращено.
РВН.6.3
РВН.6.3 Осуществление контроля за выполнением поставщиком требований, установленных в рамках договорных отношений.
ВПУ.5
ВПУ.5 Диверсификация риска нарушения поставок и сопровождения объектов информатизации, в том числе по государственной принадлежности*.
ВПУ.3.2
ВПУ.3.2 Анализ деятельности поставщиков услуг (в том числе до заключения соглашений на поставку объектов информатизации и (или) предоставление сторонних информационных сервисов), включая оценку реализуемых поставщиком услуг процедур по обеспечению безопасности на этапах жизненного цикла поставляемых объектов информатизации и минимизации риска их несанкционированной модификации на этапах поставки;
ВПУ.3.4
ВПУ.3.4 Использование всевозможных источников информации для анализа и оценки поставщиков объектов информатизации и (или) сторонних информационных сервисов;
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:
  • 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: 
  • 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:
  • 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. 
Requirement 3.6.1.1
3.6.1.1
Defined Approach Requirements: 
Additional requirement for service providers only: A documented description of the cryptographic architecture is maintained that includes:
  • Details of all algorithms, protocols, and keys used for the protection of stored account data, including key strength and expiry date. 
  • Preventing the use of the same cryptographic keys in production and test environments. This bullet is a best practice until its effective date; refer to Applicability Notes below for details.
  • Description of the key usage for each key.
  • Inventory of any hardware security modules (HSMs), key management systems (KMS), and other secure cryptographic devices (SCDs) used for key management, including type and location of devices, as outlined in Requirement 12.3.4. 
Customized Approach Objective:
Accurate details of the cryptographic architecture are maintained and available. 

Applicability Notes:
This requirement applies only when the entity being assessed is a service provider. 
In cloud HSM implementations, responsibility for the cryptographic architecture according to this Requirement will be shared between the cloud provider and the cloud customer. 
The bullet above (for including, in the cryptographic architecture, that the use of the same cryptographic keys in production and test is prevented) is a best practice until 31 March 2025, after which it will be required as part of Requirement 3.6.1.1 and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:
  •  3.6.1.1 Additional testing procedure for service provider assessments only: Interview responsible personnel and examine documentation to verify that a document exists to describe the cryptographic architecture that includes all elements specified in this requirement. 
Purpose:
Maintaining current documentation of the cryptographic architecture enables an entity to understand the algorithms, protocols, and cryptographic keys used to protect stored account data, as well as the devices that generate, use, and protect the keys. This allows an entity to keep pace with evolving threats to its architecture and plan for updates as the assurance level provided by different algorithms and key strengths changes. Maintaining such documentation also allows an entity to detect lost or missing keys or key-management devices and identify unauthorized additions to its cryptographic architecture. 
 The use of the same cryptographic keys in both production and test environments introduces a risk of exposing the key if the test environment is not at the same security level as the production environment. 

Good Practice:
Having an automated reporting mechanism can assist with maintenance of the cryptographic attributes. 
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:
  • 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:
  • 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. 
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:
  • 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. 
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:
  • 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:
  • 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. 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.15.2.2
A.15.2.2 Управление изменениями услуг поставщика 
Мера обеспечения информационной безопасности: Требуется управлять изменениями в предоставляемых поставщиками услугах, включая поддержку и улучшение существующих политик, процедур, а также мер и средств информационной безопасности, с учетом категории информации бизнеса, задействованных систем и процессов, а также результатов переоценки рисков информационной безопасности 
A.15.2.1
A.15.2.1 Мониторинг и анализ услуг поставщика 
Мера обеспечения информационной безопасности: Организация должна регулярно проводить мониторинг, проверку и аудит деятельности поставщика по предоставлению услу 
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, то эти требования также “не действуют” для организации.

Определенные Процедуры Тестирования Подхода:
  • 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: Использование сторонних поставщиков услуг.
  • Информационное Дополнение: Обеспечение безопасности Третьей Стороной.
Requirement 3.6.1.1
3.6.1.1
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Поддерживается документированное описание криптографической архитектуры, которое включает:
  • Подробная информация обо всех алгоритмах, протоколах и ключах, используемых для защиты сохраненных данных учетной записи, включая надежность ключа и дату истечения срока действия.
  • Предотвращение использования одних и тех же криптографических ключей в рабочей и тестовой средах. Этот бюллетень является наилучшей практикой до даты его вступления в силу; подробности см. в Примечаниях к применению ниже.
  • Описание использования ключа для каждого ключа.
  • Инвентаризация любых аппаратных модулей безопасности (HSM), систем управления ключами (KMS) и других защищенных криптографических устройств (SCDS), используемых для управления ключами, включая тип и местоположение устройств, как указано в требовании 12.3.4.
Цель Индивидуального подхода:
Поддерживаются и доступны точные сведения о криптографической архитектуре.

Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
В облачных реализациях HSM ответственность за криптографическую архитектуру в соответствии с этим требованием будет разделена между поставщиком облачных услуг и облачным заказчиком.
Вышеприведенный пункт (для включения в криптографическую архитектуру, чтобы предотвратить использование одних и тех же криптографических ключей в производстве и тестировании) является наилучшей практикой до 31 марта 2025 года, после чего он потребуется как часть требования 3.6.1.1 и должен быть полностью рассмотрен во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:
  • 3.6.1.1 Дополнительная процедура тестирования только для оценки поставщика услуг: Опросите ответственный персонал и изучите документацию, чтобы убедиться, что существует документ, описывающий криптографическую архитектуру, которая включает все элементы, указанные в этом требовании.
Цель:
Ведение текущей документации по криптографической архитектуре позволяет организации понимать алгоритмы, протоколы и криптографические ключи, используемые для защиты хранимых данных учетной записи, а также устройства, которые генерируют, используют и защищают ключи. Это позволяет организации идти в ногу с развивающимися угрозами для своей архитектуры и планировать обновления по мере изменения уровня надежности, обеспечиваемого различными алгоритмами и ключевыми преимуществами. Ведение такой документации также позволяет организации обнаруживать потерянные или отсутствующие ключи или устройства управления ключами и выявлять несанкционированные дополнения к своей криптографической архитектуре.
Использование одних и тех же криптографических ключей как в рабочей, так и в тестовой средах создает риск раскрытия ключа, если тестовая среда не соответствует тому же уровню безопасности, что и производственная среда.

Надлежащая практика:
Наличие автоматизированного механизма отчетности может помочь в поддержании криптографических атрибутов.
Requirement 12.5.2.1
12.5.2.1
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Область применения стандарта 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, скорее всего, позволит обнаружить такие пропущенные изменения до того, как они смогут быть использованы злоумышленником.
Requirement 12.4.2.1
12.4.2.1
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Проверки, проведенные в соответствии с требованием 12.4.2, документируются, чтобы включать:
  • Результаты обзоров.
  • Документированные действия по исправлению, предпринятые для любых задач, которые, как было установлено, не были выполнены в соответствии с требованием 12.4.2.
  • Проверка и подписание результатов персоналом, ответственным за программу соответствия требованиям PCI DSS.
Цель Индивидуального подхода:
Результаты проверок операционной эффективности оцениваются руководством; осуществляются соответствующие мероприятия по исправлению положения.

Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.

Определенные Процедуры Тестирования Подхода:
  • 12.4.2.1 Дополнительная процедура тестирования только для оценки поставщика услуг: Изучите документацию по результатам проверок, проведенных в соответствии с требованием PCI DSS 
  • 12.4.2, чтобы убедиться, что документация включает все элементы, указанные в этом требовании.
Цель:
Цель этих независимых проверок состоит в том, чтобы подтвердить, выполняются ли действия по обеспечению безопасности на постоянной основе. Эти проверки также могут быть использованы для проверки наличия надлежащих доказательств — например, журналов аудита, отчетов о проверке уязвимостей, обзоров наборов правил контроля сетевой безопасности — чтобы помочь организации подготовиться к следующей оценке PCI DSS.
Requirement 12.8.5
12.8.5
Определенные Требования к Подходу:
Сохраняется информация о том, какие требования 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.

Дополнительная информация:
Образец шаблона матрицы ответственности приведен в Информационном дополнении: Обеспечение безопасности третьей стороной.
Requirement 12.4.2
12.4.2
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Проверки проводятся не реже одного раза в три месяца, чтобы подтвердить, что персонал выполняет свои задачи в соответствии со всеми политиками безопасности и операционными процедурами. Проверки выполняются персоналом, не являющимся ответственным за выполнение данной задачи, и включают, но не ограничиваются следующими задачами:
  • Ежедневные обзоры журналов.
  • Проверка конфигурации для средств управления сетевой безопасностью.
  • Применение стандартов конфигурации к новым системам.
  • Реагирование на предупреждения системы безопасности.
  • Процессы управления изменениями.
Цель Индивидуального подхода:
Оперативная эффективность критических средств контроля PCI DSS периодически проверяется путем ручной проверки записей.

Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.

Определенные Процедуры Тестирования Подхода:
  • 12.4.2.дополнительная процедура тестирования только для оценки поставщика услуг: Изучите политики и процедуры, чтобы убедиться, что определены процессы для проведения проверок, чтобы подтвердить, что персонал выполняет свои задачи в соответствии со всеми политиками безопасности и всеми операционными процедурами, включая, но не ограничиваясь задачами, указанными в этом требовании.
  • 12.4.2.b Дополнительная процедура тестирования только для оценки поставщика услуг: Опросите ответственный персонал и изучите записи проверок, чтобы убедиться, что проверки проводятся:
    • По крайней мере, раз в три месяца.
    • Персоналом, отличным от тех, кто отвечает за выполнение данной задачи.
Цель:
Регулярное подтверждение соблюдения политик и процедур безопасности обеспечивает уверенность в том, что ожидаемые средства контроля активны и работают должным образом. Это требование отличается от других требований, которые определяют задачу, подлежащую выполнению. Целью этих проверок является не повторное выполнение других требований PCI DSS, а подтверждение того, что действия по обеспечению безопасности выполняются на постоянной основе.

Надлежащая практика:
Эти проверки также могут быть использованы для проверки наличия надлежащих доказательств — например, журналов аудита, отчетов о проверке уязвимостей, обзоров наборов правил контроля сетевой безопасности — чтобы помочь организации подготовиться к следующей оценке PCI DSS.

Примеры:
Рассматривая требование 1.2.7 в качестве одного из примеров, Требование 12.4.2 выполняется путем подтверждения, по крайней мере, один раз в три месяца, что проверки конфигураций средств управления сетевой безопасностью проводились с требуемой периодичностью. С другой стороны, требование 1.2.7 выполняется путем проверки этих конфигураций, как указано в требовании.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.22
А.5.22 Мониторинг, проверка и управление изменениями предоставляемых сервисов
Организация должна мониторить, регулярно, анализировать, проверять и управлять изменениями в практиках ИБ в отношении  поставщиков и предоставлении ими сервисов.
SWIFT Customer Security Controls Framework v2022:
2 - 2.8A Critical Activity Outsourcing
2.8A Critical Activity Outsourcing
Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":
п. 1.7.
1.7. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны обеспечивать выполнение следующих требований в отношении взаимодействия с поставщиками услуг:
  • управление риском реализации информационных угроз при привлечении поставщиков услуг, в том числе защиту своих объектов информационной инфраструктуры от возможной реализации информационных угроз со стороны поставщиков услуг;
  • управление риском технологической зависимости функционирования своих объектов информационной инфраструктуры от поставщиков услуг.
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.5.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.

Связанные защитные меры

Ничего не найдено