Положение Банка России № 787-П от 12.01.2022

7.1.7. ИБ АБС должна обеспечиваться на всех стадиях ЖЦ АБС, автоматизирующих банковские технологические процессы, с учетом интересов всех сторон, вовлеченных в процессы ЖЦ (разработчиков, заказчиков, поставщиков продуктов и услуг, эксплуатирующих и надзорных подразделений организации БС РФ).

ВИО.8 Организация и выполнение на регулярной основе деятельности по определению и анализу возможных информационных угроз: - присущих осуществлению видов деятельности финансовой организации; - присущих взаимодействию финансовой организации с причастными сторонами.

ВИО.11.2 Взаимосвязей и взаимозависимостей между финансовой организацией и причастными сторонами (за исключением клиентов финансовой организации) в рамках выполнения бизнеси технологических процессов, в том числе взаимосвязей и взаимозависимостей объектов информатизации;

ВИО.11.3 Сторонних информационных сервисов поставщиков услуг.

ВИО.11.1 Бизнес- и технологических процессов, переданных на аутсорсинг и (или) выполняемых с применением сторонних информационных сервисов;

ID.SC-2: С использованием процесса оценки рисков в киберцепочке поставок идентфицированы, расставлены приоритеты и оценены поставщики и партнеры критически важных информационных систем, компонентов и услуг

ID.AM-6:  Установлены роли и сферы ответственности в области кибербезопасности для всех внутренних и внешних заинтересованных сторон (например, поставщиков, клиентов, партнеров)

ID.SC-5: С критичными поставщиками проводится планирование, тестирование реагирования и восстановления 

ID.SC-3: Поставщики и партнеры обязаны по контракту принять соответствующие меры, предназначенные для достижения целей программы информационной безопасности или плана управления рисками кибер-цепочки поставок 

DE.CM-6: Контролируется активность внешних поставщиков услуг для обнаружения потенциальных событий кибербезопасности 

ID.SC-4: Производиться контроль поставщиков и партнеров, чтобы подтвердить, что они выполнили свои обязательства в соответствии с требованиями. Проводятся обзоры аудитов, сводки результатов тестов или другие эквивалентные оценки поставщиков 

РВН.5 Планирование, реализация, контроль и совершенствование мероприятий, направленных на уменьшение негативного влияния риска внутреннего нарушителя, применяемых в отношении работников поставщика услуг, привлекаемого в рамках выполнения бизнес- и технологических процессов.

ВПУ.3.1 Определение приоритета в отношении поставщиков услуг, реализующих необходимые процедуры по обеспечению безопасности на этапах жизненного цикла поставляемых объектов информатизации, в том числе обеспечивающих «прозрачность» в отношении реализуемых ими процессов производства и сопровождения объектов информатизации, а также имеющих необходимую зрелость собственных процессов обеспечения безопасности цепи поставок, подтвержденную посредством проведения независимой оценки (внешнего аудита)**;

ВПУ.3.2 Анализ деятельности поставщиков услуг (в том числе до заключения соглашений на поставку объектов информатизации и (или) предоставление сторонних информационных сервисов), включая оценку реализуемых поставщиком услуг процедур по обеспечению безопасности на этапах жизненного цикла поставляемых объектов информатизации и минимизации риска их несанкционированной модификации на этапах поставки;

3.6.1.1
Defined Approach Requirements: 
Additional requirement for service providers only: A documented description of the cryptographic architecture is maintained that includes:

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:

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. 

11.4.6
Defined Approach Requirements: 
Additional requirement for service providers only: If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls as follows: 

Customized Approach Objective:
If segmentation is used, it is verified by technical testing to be continually effective, including after any changes, in isolating the CDE from out-of-scope systems. 

Applicability Notes:
This requirement applies only when the entity being assessed is a service provider. 

Defined Approach Testing Procedures:

Purpose:
Service providers typically have access to greater volumes of cardholder data 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 segmentation controls failing in complex and dynamic networks is greater in service provider environments. 
Validating segmentation controls more frequently is likely to discover such failings before they can be exploited by an attacker attempting to pivot laterally from an out-of-scope untrusted network to the CDE. 

Good Practice:
Although the requirement specifies that this scope validation is carried out at least once every six months and after significant change, this exercise should be performed as frequently as possible to ensure it remains effective at isolating the CDE from other networks. 

10.7.1
Defined Approach Requirements: 
Additional requirement for service providers only: Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems:

Customized Approach Objective:
Failures in critical security control systems are promptly identified and addressed. 

Applicability Notes:
This requirement applies only when the entity being assessed is a service provider. 
This requirement will be superseded by Requirement 10.7.2 as of 31 March 2025. 

Defined Approach Testing Procedures:

Purpose:
Without formal processes to detect and alert when critical security controls fail, failures may go undetected for extended periods and provide attackers ample time to compromise system components and steal account data from the CDE. 

Good Practice:
The specific types of failures may vary, depending on the function of the device system component and technology in use. Typical failures include a system ceasing to perform its security function or not functioning in its intended manner, such as a firewall erasing all its rules or going offline. 

A.15.1.1 Политика информационной безопасности во взаимоотношениях с поставщиками 
Мера обеспечения информационной безопасности: Требования информационной безопасности, направленные на снижение рисков, связанных с доступом поставщиков к активам организации, должны быть согласованы с поставщиком и документированы 

A.15.1.3 Цепочка поставок информационно-коммуникационной технологии 
Мера обеспечения информационной безопасности: Соглашения с поставщиками должны содержать требования по рассмотрению рисков информационной безопасности, связанных с цепочкой поставок продуктов и услуг информационно-коммуникационных технологий 

A.15.2.1 Мониторинг и анализ услуг поставщика 
Мера обеспечения информационной безопасности: Организация должна регулярно проводить мониторинг, проверку и аудит деятельности поставщика по предоставлению услу 

4.5. Заказчику следует предпринять все меры, гарантирующие, что компьютеризированная система разработана в соответствии с надлежащей системой управления качеством. Поставщик должен быть оценен соответствующим образом.

3.6.1.1
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Поддерживается документированное описание криптографической архитектуры, которое включает:

Цель Индивидуального подхода:
Поддерживаются и доступны точные сведения о криптографической архитектуре.

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

Определенные Процедуры Тестирования Подхода:

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

Надлежащая практика:
Наличие автоматизированного механизма отчетности может помочь в поддержании криптографических атрибутов.

11.4.6
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Если сегментация используется для изоляции CDE от других сетей, тесты на проникновение выполняются для элементов управления сегментацией следующим образом:

Цель Индивидуального подхода:
Если используется сегментация, она проверяется техническим тестированием на постоянную эффективность, в том числе после любых изменений, в изоляции CDE от систем, выходящих за рамки области применения.

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

Определенные Процедуры Тестирования Подхода:

Цель:
Поставщики услуг обычно имеют доступ к большим объемам данных о держателях карт или могут предоставить точку входа, которую можно использовать для последующего компрометации множества других организаций. Поставщики услуг также, как правило, имеют более крупные и сложные сети, которые подвержены более частым изменениям. Вероятность сбоя элементов управления сегментацией в сложных и динамичных сетях выше в средах поставщиков услуг.
Более частое использование средств контроля сегментации, скорее всего, позволит обнаружить такие сбои до того, как они смогут быть использованы злоумышленником, пытающимся выполнить боковой поворот из недоверенной сети, находящейся вне зоны действия, в CDE.

Надлежащая практика:
Хотя в требовании указано, что проверка этой области проводится по крайней мере раз в шесть месяцев и после внесения существенных изменений, это упражнение следует выполнять как можно чаще, чтобы гарантировать, что оно остается эффективным при изоляции CDE от других сетей.

10.7.1
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Сбои в критически важных системах контроля безопасности обнаруживаются, предупреждаются и оперативно устраняются, включая, но не ограничиваясь, сбои в следующих критически важных системах контроля безопасности:

Цель Индивидуального подхода:
Сбои в критически важных системах контроля безопасности оперативно выявляются и устраняются.

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

Определенные Процедуры Тестирования Подхода:

Цель:
Без формальных процессов обнаружения и оповещения о сбое критических средств защиты сбои могут оставаться незамеченными в течение длительного времени и предоставлять злоумышленникам достаточно времени для компрометации системных компонентов и кражи данных учетной записи из CDE.

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

9.2. Основными целями оценки поставщика услуг являются:

6.2. Основное требование 1. В случае планирования передачи выполнения бизнес-функций поставщикам услуг на аутсорсинг организации БС РФ следует установить политику в отношении аутсорсинга существенных функций (далее - политика аутсорсинга).

Политика аутсорсинга должна среди прочего однозначно определять:

Политика аутсорсинга существенных функций должна быть принята советом директоров (наблюдательным советом) организации БС РФ, а в случае его отсутствия - исполнительным органом организации БС РФ.

В отношении аутсорсинга существенных функций организация БС РФ должна реализовать процедуры внутреннего контроля соответствия принятой политики аутсорсинга, результаты которого должны рассматриваться советом директоров (наблюдательным советом) организации БС РФ.

А.5.21 Управление ИБ в цепочке поставок информационно-коммуникационных технологий (ИКТ)
В целях управления рисками ИБ, связанными с цепочкой поставок продуктов и услуг ИКТ, должны быть определены и внедрены соответствующие процессы и процедуры.

А.5.19 Информационная безопасность в отношениях с поставщиками
В целях управления рисками ИБ, связанными с использованием поставляемыми продуктами или услугами, должны быть определены и внедрены соответствующие процессы и процедуры.

А.5.22 Мониторинг, проверка и управление изменениями предоставляемых сервисов
Организация должна мониторить, регулярно, анализировать, проверять и управлять изменениями в практиках ИБ в отношении  поставщиков и предоставлении ими сервисов.

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

А.5.21 Managing information security in the information and communication technology (ICT) supply chain
Processes and procedures shall be defined and implemented to manage information security risks associated with the ICT products and services supply chain.

А.5.19 Information security in supplier relationships
Processes and procedures shall be defined and implemented to manage the information security risks associated with the use of supplier’s products or services.

А.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.