Куда я попал?
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022
Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А
A.15.1.3
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 7 п. 3 п.п. 7
7.3.7. В договор (контракт) о разработке АБС или поставке готовых АБС и их компонентов организациям БС РФ должны включаться положения по сопровождению поставляемых изделий на весь срок их службы. В случае невозможности включения в договор (контракт) указанных положений должен быть приобретен полный комплект документации, обеспечивающий возможность сопровождения АБС и их компонентов без участия разработчика. Если оба указанных варианта неприемлемы, например, вследствие высокой стоимости или позиции фирмы-поставщика (разработчика), руководство организации БС РФ должно оценить и зафиксировать допустимость риска нарушения ИБ, возникающего при невозможности сопровождения АБС и их компонентов.
CIS Critical Security Controls v8 (The 18 CIS CSC):
16.11
16.11 Leverage Vetted Modules or Services for Application Security Components
Leverage vetted modules or services for application security components, such as identity management, encryption, and auditing and logging. Using platform features in critical security functions will reduce developers’ workload and minimize the likelihood of design or implementation errors. Modern operating systems provide effective mechanisms for identification, authentication, and authorization and make those mechanisms available to applications. Use only standardized, currently accepted, and extensively reviewed encryption algorithms. Operating systems also provide mechanisms to create and maintain secure audit logs.
Leverage vetted modules or services for application security components, such as identity management, encryption, and auditing and logging. Using platform features in critical security functions will reduce developers’ workload and minimize the likelihood of design or implementation errors. Modern operating systems provide effective mechanisms for identification, authentication, and authorization and make those mechanisms available to applications. Use only standardized, currently accepted, and extensively reviewed encryption algorithms. Operating systems also provide mechanisms to create and maintain secure audit logs.
ГОСТ Р № 57580.3-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Управление риском реализации информационных угроз и обеспечение операционной надежности. Общие положения.":
ВИО.11.2
ВИО.11.2 Взаимосвязей и взаимозависимостей между финансовой организацией и причастными сторонами (за исключением клиентов финансовой организации) в рамках выполнения бизнеси технологических процессов, в том числе взаимосвязей и взаимозависимостей объектов информатизации;
ВИО.11.3
ВИО.11.3 Сторонних информационных сервисов поставщиков услуг.
ВИО.11.1
ВИО.11.1 Бизнес- и технологических процессов, переданных на аутсорсинг и (или) выполняемых с применением сторонних информационных сервисов;
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 6. п.п. 4
6.4. Кредитные организации должны обеспечивать выполнение следующих требований к взаимодействию с поставщиками услуг в сфере информационных технологий:
- нейтрализация информационных угроз, связанных с привлечением поставщиков услуг в сфере информационных технологий, в том числе защита объектов информационной инфраструктуры от возможной реализации информационных угроз со стороны поставщиков услуг в сфере информационных технологий;
- нейтрализация информационных угроз, обусловленных технологической зависимостью функционирования объектов информационной инфраструктуры кредитной организации от поставщиков услуг в сфере информационных технологий.
NIST Cybersecurity Framework (RU):
ID.SC-1
ID.SC-1: Идентфицированы, устанавлены, оцениваются, управляются и согласовываются заинтересованными сторонами организации все процессы управления рисками в кибер-цепочке
ID.SC-3
ID.SC-3: Поставщики и партнеры обязаны по контракту принять соответствующие меры, предназначенные для достижения целей программы информационной безопасности или плана управления рисками кибер-цепочки поставок
ID.BE-1
ID.BE-1: Определена и сообщена роль организации в цепочке поставок
ID.BE-4
ID.BE-4: Установлены зависимости и критические функции для предоставления критически важных услуг
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
16.11
16.11 Используются проверенные модули или службы в приложениях для компонентов обеспечения безопасности
Используются проверенные модули для шифрования, ведения журналов и управления идентификацией пользователей.
Для обеспечения критичных компонентов безопасности используются платформенные функции.
Используются проверенные модули для шифрования, ведения журналов и управления идентификацией пользователей.
Для обеспечения критичных компонентов безопасности используются платформенные функции.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 12.5.2.1
12.5.2.1
Defined Approach Requirements:
Additional requirement for service providers only: PCI DSS scope is documented and confirmed by the entity at least once every six months and upon significant change to the in-scope environment. At a minimum, the scoping validation includes all the elements specified in Requirement 12.5.2.
Customized Approach Objective:
The accuracy of PCI DSS scope is verified to be continuously accurate by comprehensive analysis and appropriate technical measures.
Applicability Notes:
This requirement applies only when the entity being assessed is a service provider.
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
Defined Approach Testing Procedures:
Defined Approach Requirements:
Additional requirement for service providers only: PCI DSS scope is documented and confirmed by the entity at least once every six months and upon significant change to the in-scope environment. At a minimum, the scoping validation includes all the elements specified in Requirement 12.5.2.
Customized Approach Objective:
The accuracy of PCI DSS scope is verified to be continuously accurate by comprehensive analysis and appropriate technical measures.
Applicability Notes:
This requirement applies only when the entity being assessed is a service provider.
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
Defined Approach Testing Procedures:
- 12.5.2.1.a Additional testing procedure for service provider assessments only: Examine documented results of scope reviews and interview personnel to verify that reviews per Requirement
- 12.5.2 are performed:
- At least once every six months, and
- After significant changes
- 12.5.2.1.b Additional testing procedure for service provider assessments only: Examine documented results of scope reviews to verify that scoping validation includes all elements specified in Requirement 12.5.2.
Purpose:
Service providers typically have access to greater volumes of cardholder data than do merchants, or can provide an entry point that can be exploited to then compromise multiple other entities. Service providers also typically have larger and more complex networks that are subject to more frequent change. The probability of overlooked changes to scope in complex and dynamic networks is greater in service providers’ environments.
Validating PCI DSS scope more frequently is likely to discover such overlooked changes before they can be exploited by an attacker.
Service providers typically have access to greater volumes of cardholder data than do merchants, or can provide an entry point that can be exploited to then compromise multiple other entities. Service providers also typically have larger and more complex networks that are subject to more frequent change. The probability of overlooked changes to scope in complex and dynamic networks is greater in service providers’ environments.
Validating PCI DSS scope more frequently is likely to discover such overlooked changes before they can be exploited by an attacker.
Requirement 10.7.1
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:
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:
- Network security controls.
- IDS/IPS.
- FIM.
- Anti-malware solutions.
- Physical access controls.
- Logical access controls.
- Audit logging mechanisms.
- Segmentation controls (if used).
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:
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:
- 10.7.1.a Additional testing procedure for service provider assessments only: Examine documentation to verify that processes are defined for the prompt detection and addressing of failures of critical security control systems, including but not limited to failure of all elements specified in this requirement.
- 10.7.1.b Additional testing procedure for service provider assessments only: Observe detection and alerting processes and interview personnel to verify that failures of critical security control systems are detected and reported, and that failure of a critical security control results in the generation of an alert.
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.
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.
Requirement 12.8.2
12.8.2
Defined Approach Requirements:
Written agreements with TPSPs are maintained as follows:
Defined Approach Requirements:
Written agreements with TPSPs are maintained as follows:
- Written agreements are maintained with all TPSPs with which account data is shared or that could affect the security of the CDE.
- Written agreements include acknowledgments from TPSPs that they are responsible for the security of account data the TPSPs possess or otherwise store, process, or transmit on behalf of the entity, or to the extent that they could impact the security of the entity’s CDE.
Customized Approach Objective:
Records are maintained of each TPSP’s acknowledgment of its responsibility to protect account data.
Applicability Notes:
The exact wording of an acknowledgment will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgment does not have to include the exact wording provided in this requirement.
Evidence that a TPSP is meeting PCI DSS requirements (for example, a PCI DSS Attestation of Compliance (AOC) or a declaration on a company’s website) is not the same as a written agreement specified in this requirement.
Defined Approach Testing Procedures:
Records are maintained of each TPSP’s acknowledgment of its responsibility to protect account data.
Applicability Notes:
The exact wording of an acknowledgment will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgment does not have to include the exact wording provided in this requirement.
Evidence that a TPSP is meeting PCI DSS requirements (for example, a PCI DSS Attestation of Compliance (AOC) or a declaration on a company’s website) is not the same as a written agreement specified in this requirement.
Defined Approach Testing Procedures:
- 12.8.2.a Examine policies and procedures to verify that processes are defined to maintain written agreements with all TPSPs in accordance with all elements specified in this requirement.
- 12.8.2.b Examine written agreements with TPSPs to verify they are maintained in accordance with all elements as specified in this requirement.
Purpose:
The written acknowledgment from a TPSP demonstrates its commitment to maintaining proper security of account data that it obtains from its customers and that the TPSP is fully aware of the assets that could be affected during the provisioning of the TPSP’s service. The extent to which a specific TPSP is responsible for the security of account data will depend on the service provided and the agreement between the provider and assessed entity (the customer).
In conjunction with Requirement 12.9.1, this requirement is intended to promote a consistent level of understanding between parties about their applicable PCI DSS responsibilities. For example, the agreement may include the applicable PCI DSS requirements to be maintained as part of the provided service.
Good Practice:
The entity may also want to consider including in their written agreement with a TPSP that the TPSP will support the entity’s request for information per Requirement 12.9.2. Entities will also want to understand whether any TPSPs have “nested” relationships with other TPSPs, meaning the primary TPSP contracts with another TPSP(s) for the purposes of providing a service.
It is important to understand whether the primary TPSP is relying on the secondary TPSP(s) to achieve overall compliance of a service, and what types of written agreements the primary TPSP has in place with the secondary TPSPs. Entities can consider including coverage in their written agreement for any “nested” TPSPs a primary TPSP may use.
Further Information:
Refer to the “Information Supplement: Third-Party Security Assurance for further guidance.
The written acknowledgment from a TPSP demonstrates its commitment to maintaining proper security of account data that it obtains from its customers and that the TPSP is fully aware of the assets that could be affected during the provisioning of the TPSP’s service. The extent to which a specific TPSP is responsible for the security of account data will depend on the service provided and the agreement between the provider and assessed entity (the customer).
In conjunction with Requirement 12.9.1, this requirement is intended to promote a consistent level of understanding between parties about their applicable PCI DSS responsibilities. For example, the agreement may include the applicable PCI DSS requirements to be maintained as part of the provided service.
Good Practice:
The entity may also want to consider including in their written agreement with a TPSP that the TPSP will support the entity’s request for information per Requirement 12.9.2. Entities will also want to understand whether any TPSPs have “nested” relationships with other TPSPs, meaning the primary TPSP contracts with another TPSP(s) for the purposes of providing a service.
It is important to understand whether the primary TPSP is relying on the secondary TPSP(s) to achieve overall compliance of a service, and what types of written agreements the primary TPSP has in place with the secondary TPSPs. Entities can consider including coverage in their written agreement for any “nested” TPSPs a primary TPSP may use.
Further Information:
Refer to the “Information Supplement: Third-Party Security Assurance for further guidance.
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.
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 18.3
CSC 18.3 Verify That Acquired Software is Still Supported
Verify that the version of all software acquired from outside your organization is still supported by the developer or appropriately hardened based on developer security recommendations.
Verify that the version of all software acquired from outside your organization is still supported by the developer or appropriately hardened based on developer security recommendations.
Стандарт № GMP Annex 11: Computerised Systems (RU) от 30.11.2011 "Правила надлежащей производственной практики. Приложение 11: Компьютеризированные системы":
Р. 2 п. 3 п.п. 2
3.2. Компетентность и надежность поставщиков являются ключевыми условиями выбора провайдеров программного продукта или услуг. Необходимость аудита должна быть основана на оценке рисков.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 12.8.2
12.8.2
Определенные Требования к Подходу:
Письменные соглашения с TPSP поддерживаются следующим образом:
Определенные Требования к Подходу:
Письменные соглашения с TPSP поддерживаются следующим образом:
- Со всеми TPPS, которым передаются данные учетной записи или которые могут повлиять на безопасность CDE, поддерживаются письменные соглашения.
- Письменные соглашения включают подтверждения от TPPS о том, что они несут ответственность за безопасность учетных данных, которыми владеют TPPS или иным образом хранят, обрабатывают или передают от имени организации, или в той степени, в какой они могут повлиять на безопасность CDE организации.
Цель Индивидуального подхода:
Ведутся записи о подтверждении каждым TPSP своей ответственности за защиту данных учетной записи.
Примечания по применению:
Точная формулировка подтверждения будет зависеть от соглашения между двумя сторонами, деталей предоставляемой услуги и обязанностей, возложенных на каждую сторону. Подтверждение не обязательно должно содержать точную формулировку, предусмотренную в этом требовании.
Доказательства того, что TPSP соответствует требованиям PCI DSS (например, сертификат соответствия PCI DSS (AOC) или декларация на веб-сайте компании), не совпадают с письменным соглашением, указанным в этом требовании.
Определенные Процедуры Тестирования Подхода:
Ведутся записи о подтверждении каждым TPSP своей ответственности за защиту данных учетной записи.
Примечания по применению:
Точная формулировка подтверждения будет зависеть от соглашения между двумя сторонами, деталей предоставляемой услуги и обязанностей, возложенных на каждую сторону. Подтверждение не обязательно должно содержать точную формулировку, предусмотренную в этом требовании.
Доказательства того, что TPSP соответствует требованиям PCI DSS (например, сертификат соответствия PCI DSS (AOC) или декларация на веб-сайте компании), не совпадают с письменным соглашением, указанным в этом требовании.
Определенные Процедуры Тестирования Подхода:
- 12.8.2.a Изучить политики и процедуры, чтобы убедиться, что процессы определены для поддержания письменных соглашений со всеми TPSP в соответствии со всеми элементами, указанными в этом требовании.
- 12.8.2.b Изучите письменные соглашения с TPSP, чтобы убедиться, что они поддерживаются в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Письменное подтверждение от TPSP демонстрирует его приверженность поддержанию надлежащей безопасности учетных данных, которые он получает от своих клиентов, и что TPSP полностью осведомлен об активах, которые могут быть затронуты во время предоставления услуг TPSP. Степень, в которой конкретный TPSP несет ответственность за безопасность данных учетной записи, будет зависеть от предоставляемой услуги и соглашения между поставщиком и оцениваемой организацией (клиентом).
В сочетании с требованием 12.9.1 это требование призвано способствовать постоянному уровню понимания между сторонами их применимых обязанностей по PCI DSS. Например, соглашение может включать применимые требования PCI DSS, которые должны поддерживаться в рамках предоставляемой услуги.
Надлежащая практика:
Организация может также захотеть включить в свое письменное соглашение с TPSP, что TPSP будет поддерживать запрос организации о предоставлении информации в соответствии с требованием 12.9.2. Организации также захотят понять, имеют ли какие-либо TPSP “вложенные” отношения с другими TPSP, что означает, что первичный TPSP заключает контракты с другим TPSP (ами) на цели предоставления услуги.
Важно понимать, полагается ли первичный TPSP на вторичный TPSP(ы) для достижения общего соответствия услуги, и какие типы письменных соглашений заключены у первичного TPSP с вторичными TPSP. Организации могут рассмотреть возможность включения покрытия в свое письменное соглашение для любых “вложенных” TPSP, которые может использовать основной TPSP.
Дополнительная информация:
Дополнительные указания см. в разделе “Информационное дополнение: Обеспечение безопасности третьей стороной".
Письменное подтверждение от TPSP демонстрирует его приверженность поддержанию надлежащей безопасности учетных данных, которые он получает от своих клиентов, и что TPSP полностью осведомлен об активах, которые могут быть затронуты во время предоставления услуг TPSP. Степень, в которой конкретный TPSP несет ответственность за безопасность данных учетной записи, будет зависеть от предоставляемой услуги и соглашения между поставщиком и оцениваемой организацией (клиентом).
В сочетании с требованием 12.9.1 это требование призвано способствовать постоянному уровню понимания между сторонами их применимых обязанностей по PCI DSS. Например, соглашение может включать применимые требования PCI DSS, которые должны поддерживаться в рамках предоставляемой услуги.
Надлежащая практика:
Организация может также захотеть включить в свое письменное соглашение с TPSP, что TPSP будет поддерживать запрос организации о предоставлении информации в соответствии с требованием 12.9.2. Организации также захотят понять, имеют ли какие-либо TPSP “вложенные” отношения с другими TPSP, что означает, что первичный TPSP заключает контракты с другим TPSP (ами) на цели предоставления услуги.
Важно понимать, полагается ли первичный TPSP на вторичный TPSP(ы) для достижения общего соответствия услуги, и какие типы письменных соглашений заключены у первичного TPSP с вторичными TPSP. Организации могут рассмотреть возможность включения покрытия в свое письменное соглашение для любых “вложенных” TPSP, которые может использовать основной TPSP.
Дополнительная информация:
Дополнительные указания см. в разделе “Информационное дополнение: Обеспечение безопасности третьей стороной".
Requirement 12.5.2.1
12.5.2.1
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Область применения стандарта PCI DSS документируется и подтверждается организацией не реже одного раза в шесть месяцев и при значительных изменениях в среде, в которой он применяется. Как минимум, проверка области охвата включает в себя все элементы, указанные в требовании 12.5.2.
Цель Индивидуального подхода:
Точность области применения PCI DSS проверяется на постоянную точность с помощью всестороннего анализа и соответствующих технических мер.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Область применения стандарта PCI DSS документируется и подтверждается организацией не реже одного раза в шесть месяцев и при значительных изменениях в среде, в которой он применяется. Как минимум, проверка области охвата включает в себя все элементы, указанные в требовании 12.5.2.
Цель Индивидуального подхода:
Точность области применения PCI DSS проверяется на постоянную точность с помощью всестороннего анализа и соответствующих технических мер.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
- 12.5.2.1.дополнительная процедура тестирования только для оценок поставщиков услуг: Изучите документированные результаты проверок сферы охвата и опросите персонал, чтобы убедиться, что проверки соответствуют требованиям
- 12.5.2 выполняются:
- По крайней мере, раз в шесть месяцев, и
- После значительных изменений
- 12.5.2.1.b Дополнительная процедура тестирования только для оценок поставщиков услуг: Изучите документированные результаты проверок области применения, чтобы убедиться, что проверка области применения включает все элементы, указанные в Требовании 12.5.2.
Цель:
Поставщики услуг обычно имеют доступ к большему объему данных о держателях карт, чем торговцы, или могут предоставить точку входа, которую можно использовать для последующего компрометации множества других организаций. Поставщики услуг также, как правило, имеют более крупные и сложные сети, которые подвержены более частым изменениям. Вероятность незамеченных изменений в области применения в сложных и динамичных сетях выше в среде поставщиков услуг.
Более частая проверка области действия PCI DSS, скорее всего, позволит обнаружить такие пропущенные изменения до того, как они смогут быть использованы злоумышленником.
Поставщики услуг обычно имеют доступ к большему объему данных о держателях карт, чем торговцы, или могут предоставить точку входа, которую можно использовать для последующего компрометации множества других организаций. Поставщики услуг также, как правило, имеют более крупные и сложные сети, которые подвержены более частым изменениям. Вероятность незамеченных изменений в области применения в сложных и динамичных сетях выше в среде поставщиков услуг.
Более частая проверка области действия PCI DSS, скорее всего, позволит обнаружить такие пропущенные изменения до того, как они смогут быть использованы злоумышленником.
Requirement 10.7.1
10.7.1
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Сбои в критически важных системах контроля безопасности обнаруживаются, предупреждаются и оперативно устраняются, включая, но не ограничиваясь, сбои в следующих критически важных системах контроля безопасности:
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Сбои в критически важных системах контроля безопасности обнаруживаются, предупреждаются и оперативно устраняются, включая, но не ограничиваясь, сбои в следующих критически важных системах контроля безопасности:
- Средства управления сетевой безопасностью.
- IDS/IPS.
- FIM.
- Решения для защиты от вредоносных программ.
- Контроль физического доступа.
- Логический контроль доступа.
- Механизмы ведения журнала аудита.
- Элементы управления сегментацией (если они используются).
Цель Индивидуального подхода:
Сбои в критически важных системах контроля безопасности оперативно выявляются и устраняются.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование будет заменено Требованием 10.7.2 с 31 марта 2025 года.
Определенные Процедуры Тестирования Подхода:
Сбои в критически важных системах контроля безопасности оперативно выявляются и устраняются.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование будет заменено Требованием 10.7.2 с 31 марта 2025 года.
Определенные Процедуры Тестирования Подхода:
- 10.7.1.дополнительная процедура тестирования только для оценки поставщика услуг: Изучите документацию, чтобы убедиться, что определены процессы для оперативного обнаружения и устранения сбоев критических систем контроля безопасности, включая, но не ограничиваясь отказом всех элементов, указанных в этом требовании.
- 10.7.1.b Дополнительная процедура тестирования только для оценки поставщика услуг: Наблюдайте за процессами обнаружения и оповещения и опрашивайте персонал, чтобы убедиться, что сбои в критически важных системах контроля безопасности обнаружены и сообщены, и что сбой критического контроля безопасности приводит к генерации предупреждения.
Цель:
Без формальных процессов обнаружения и оповещения о сбое критических средств защиты сбои могут оставаться незамеченными в течение длительного времени и предоставлять злоумышленникам достаточно времени для компрометации системных компонентов и кражи данных учетной записи из CDE.
Надлежащая практика:
Конкретные типы отказов могут варьироваться в зависимости от функции системного компонента устройства и используемой технологии. Типичные сбои включают в себя то, что система перестает выполнять свои функции безопасности или не функционирует должным образом, например, брандмауэр стирает все свои правила или переходит в автономный режим.
Без формальных процессов обнаружения и оповещения о сбое критических средств защиты сбои могут оставаться незамеченными в течение длительного времени и предоставлять злоумышленникам достаточно времени для компрометации системных компонентов и кражи данных учетной записи из CDE.
Надлежащая практика:
Конкретные типы отказов могут варьироваться в зависимости от функции системного компонента устройства и используемой технологии. Типичные сбои включают в себя то, что система перестает выполнять свои функции безопасности или не функционирует должным образом, например, брандмауэр стирает все свои правила или переходит в автономный режим.
Стандарт Банка России № СТО БР ИББС-1.4-2018 от 01.07.2018 "Управление риском нарушения информационной безопасности при аутсорсинге":
Р. 11 п. 4
11.4. В случае возникновения риска нарушения ИБ, связанного с аутсорсингом существенных функций, превышающего принятый приемлемый риск (риск-аппетит), организации БС РФ следует совершить оперативные корректирующие действия, направленные на обработку указанного риска:
- корректировка (пересмотр) соглашения;
- рассмотрение целесообразности расторжения соглашения и последующая реализация стратегии “выхода”.
Организация БС РФ должна предусмотреть механизмы принятия оперативного решения, в случае если уровень риска нарушения ИБ выходит за рамки допустимых значений. В таких случаях должен быть предусмотрен внеплановый аудит поставщика услуг для подтверждения способности выполнять аутсорсинг существенных функций организации БС РФ.
Рассмотрение вопросов о фактах выявления неприемлемых рисков при аутсорсинге существенных функций, а также принятие решения по таким случаям должно входить в компетенцию совета директоров (наблюдательного органа) организации БС РФ.
В случае выявления рисков и принятия решения о корректировке соглашения необходимо проведение надлежащей переоценки риска нарушения ИБ в объеме, определяемом содержанием предполагаемых корректировок.
Рассмотрение вопросов о фактах выявления неприемлемых рисков при аутсорсинге существенных функций, а также принятие решения по таким случаям должно входить в компетенцию совета директоров (наблюдательного органа) организации БС РФ.
В случае выявления рисков и принятия решения о корректировке соглашения необходимо проведение надлежащей переоценки риска нарушения ИБ в объеме, определяемом содержанием предполагаемых корректировок.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.21
А.5.21 Управление ИБ в цепочке поставок информационно-коммуникационных технологий (ИКТ)
В целях управления рисками ИБ, связанными с цепочкой поставок продуктов и услуг ИКТ, должны быть определены и внедрены соответствующие процессы и процедуры.
В целях управления рисками ИБ, связанными с цепочкой поставок продуктов и услуг ИКТ, должны быть определены и внедрены соответствующие процессы и процедуры.
Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":
п. 1.7.
1.7. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны обеспечивать выполнение следующих требований в отношении взаимодействия с поставщиками услуг:
- управление риском реализации информационных угроз при привлечении поставщиков услуг, в том числе защиту своих объектов информационной инфраструктуры от возможной реализации информационных угроз со стороны поставщиков услуг;
- управление риском технологической зависимости функционирования своих объектов информационной инфраструктуры от поставщиков услуг.
NIST Cybersecurity Framework (EN):
ID.SC-1
ID.SC-1: Cyber supply chain risk management processes are identified, established, assessed, managed, and agreed to by organizational stakeholders
ID.BE-4
ID.BE-4: Dependencies and critical functions for delivery of critical services are established
ID.BE-1
ID.BE-1: The organization’s role in the supply chain is identified and communicated
ID.SC-3
ID.SC-3: Contracts with suppliers and third-party partners are used to implement appropriate measures designed to meet the objectives of an organization’s cybersecurity program and Cyber Supply Chain Risk Management Plan.
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
15.1.3
15.1.3 Цепочка поставок информационно-коммуникационных технологий
Мера обеспечения ИБ
Соглашения с поставщиками должны содержать требования по рассмотрению рисков ИБ, связанных с цепочкой поставок продуктов и услуг информационно-коммуникационных технологий.
Руководство по применению
Относительно безопасности цепочек поставок для включения в соглашения с поставщиками должны быть рассмотрены следующие положения:
- a) определение требований ИБ, применимых к закупкам продуктов или услуг в области информационно-коммуникационных технологий, в дополнение к общим требованиям ИБ, относящимся к отношениям с поставщиками;
- b) для услуг в области информационно-коммуникационных технологий требуется, чтобы поставщики распространяли требования безопасности организации на всю цепочку поставки, если поставщик привлекает подрядчиков для выполнения части услуг в области информационно-коммуникационных технологий, оказываемых организации;
- c) для продуктов в области информационно-коммуникационных технологий требуется, чтобы поставщики распространяли соответствующие процедуры, связанные с безопасностью, на всю цепочку поставки, если эти продукты включают в себя компоненты, закупаемые у других поставщиков;
- d) выполнение процесса мониторинга и подходящих методов для подтверждения того, что поставляемые продукты и услуги в области информационно-коммуникационных технологий соответствуют заявленным требованиям безопасности;
- e) выполнение процесса определения компонентов продукта или услуги, которые являются критически важными для поддержания функциональности и следовательно требуют повышенного внимания и изучения, если произведены за пределами организации, особенно если первичный поставщик передает на аутсорсинг производство каких-то элементов продукта или услуги другим поставщикам;
- f) получение уверенности в том, что критически важные компоненты и их происхождение могут быть прослежены по всей цепочке поставки;
- g) получение уверенности в том, что поставляемые продукты в области информационно-коммуникационных технологий функционируют должным образом без каких-либо непредусмотренных или нежелательных функций;
- h) определение правил обмена информацией, касающихся цепочки поставки и любых потенциальных проблем и компромиссов между организацией и поставщиками;
- i) выполнение конкретных процессов управления жизненным циклом и доступностью компонентов информационно-коммуникационных технологий и связанными с ними рисками безопасности. Это включает в себя управление рисками, связанными с тем, что компоненты более не доступны в силу того, что их поставщики прекратили свою деятельность или прекратили поставку этих компонентов по причине развития технологий.
Дополнительная информация
Конкретные методы управления рисками в цепочке поставки информационно-коммуникационных технологий основаны на высокоуровневых процедурах обеспечения общей ИБ, качества, управления проектами и разработки систем, но не заменяют их.
Организациям рекомендуется работать с поставщиками для понимания цепочки поставки информационно-коммуникационных технологий и любых вопросов, оказывающих значительное влияние на поставляемые продукты и услуги. Организации могут влиять на методы обеспечения ИБ в цепочке поставок информационно-коммуникационных технологий, четко определяя в соглашениях со своими поставщиками вопросы, которые должны решаться другими поставщиками в цепочке поставок информационно-коммуникационных технологий.
Цепочка поставок информационно-коммуникационных технологий, как указано здесь, включает в себя услуги облачных вычислений.
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.5.21
А.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.
Processes and procedures shall be defined and implemented to manage information security risks associated with the ICT products and services supply chain.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.