Куда я попал?
Framework № PCI DSS 4.0 от 01.03.2022
Payment Card Industry Data Security Standard (RU)
Requirement 12.3.1
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 5 п. 5.18
5.18. Идентификация, анализ и оценивание рисков нарушения ИБ должны основываться на идентификации активов организации БС РФ, на их ценности для целей и задач организации БС РФ, на моделях угроз и нарушителей ИБ организации БС РФ.
Р. 8 п. 4 п.п. 4
8.4.4. Оценка рисков нарушения ИБ проводится для свойств ИБ всех информационных активов (типов информационных активов) области действия СОИБ.
Р. 8 п. 4 п.п. 5
8.4.5. Полученные в результате оценивания рисков нарушения ИБ величины рисков должны быть соотнесены с уровнем допустимого риска, принятого в организации БС РФ. Результатом выполнения указанной процедуры является зафиксированный перечень недопустимых рисков нарушения ИБ.
Р. 8 п. 11 п.п. 4
8.11.4. Разработка планов обеспечения непрерывности бизнеса и его восстановления после прерывания должна основываться на результатах оценки рисков нарушения ИБ организации БС РФ применительно к информационным активам, существенным для обеспечения непрерывности бизнеса и его восстановления после прерывания.
Р. 8 п. 4 п.п. 1
8.4.1. В организации БС РФ должна быть принята/корректироваться методика оценки рисков нарушения ИБ/подход к оценке рисков нарушения ИБ.
Р. 8 п. 4 п.п. 2
8.4.2. В организации БС РФ должны быть определены критерии принятия рисков нарушения ИБ и уровень допустимого риска нарушения ИБ.
CIS Critical Security Controls v8 (The 18 CIS CSC):
7.2
7.2 Establish and Maintain a Remediation Process
Establish and maintain a risk-based remediation strategy documented in a remediation process, with monthly, or more frequent, reviews.
Establish and maintain a risk-based remediation strategy documented in a remediation process, with monthly, or more frequent, reviews.
ГОСТ Р № 57580.3-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Управление риском реализации информационных угроз и обеспечение операционной надежности. Общие положения.":
ВИО.21
ВИО.21 Оценка риска реализации информационных угроз, которому финансовая организация подвергает или подвергается со стороны причастных сторон (за исключением клиентов финансовой организации), с учетом степени взаимосвязи и взаимозависимости между финансовой организацией и причастными сторонами (за исключением клиентов финансовой организации), в том числе степени взаимосвязи и взаимозависимости между их объектами информатизации.
ОПР.1.1
ОПР.1.1 Определение и описание состава процессов управления риском реализации информационных угроз, обеспечения операционной надежности и защиты информации;
ОПР.19.3
ОПР.19.3 Утверждение допустимого уровня риска реализации информационных угроз (риск-аппетита финансовой организации), состава КПУР, а также их сигнальных и контрольных значений;
ОПР.19.14
ОПР.19.14 Периодический контроль за фактическими значениями КПУР;
NIST Cybersecurity Framework (RU):
ID.RM-3
ID.RM-3: Определение отношения (степени принятия риска) к риску организации основывается на ее роли в критической инфраструктуре и анализе рисков для конкретных секторов
ID.SC-2
ID.SC-2: С использованием процесса оценки рисков в киберцепочке поставок идентфицированы, расставлены приоритеты и оценены поставщики и партнеры критически важных информационных систем, компонентов и услуг
ID.RM-2
ID.RM-2: Определен и четко выражен критерий принятия риска в организации
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
7.2
7.2 Реализован и поддерживается процесс управления обнаруженными проблемами безопасности
Документ с описанием процесса пересматривается раз в месяц или чаще.
Документ с описанием процесса пересматривается раз в месяц или чаще.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Тело стандарта":
6.1.2 Оценка рисков информационной безопасности
6.1.2 Оценка рисков информационной безопасности
Организация должна определить и применять процесс оценки рисков информационной безопасности, который
Организация должна определить и применять процесс оценки рисков информационной безопасности, который
- а) устанавливает и поддерживает критерии рисков информационной безопасности, которые включают в себя:
- 1) критерии приемлемости рисков; а также
- 2) критерии выполнения оценок рисков информационной безопасности;
- b) обеспечивает выработку повторяющимися оценками рисков информационной безопасности цельных, достоверных и сравнимых результатов;
- c) выявляет риски информационной безопасности:
- 1) применение процесса оценки рисков информационной безопасности с целью выявления рисков, связанных с потерей конфиденциальности, целостности и доступности информации в пределах области действия системы менеджмента информационной безопасности; а также
- 2) выявление владельцев рисков;
- d) анализирует риски информационной безопасности:
- 1) оценка возможных последствий, которые могут произойти в результате реализации рисков, выявленных в п.6.1.2 с)1);
- 2) оценка реалистичной вероятности реализации рисков, выявленных в п.6.1.2 с)1); а также
- 3) определение уровней рисков;
- e) оценивает риски информационной безопасности:
- 1) сравнение результатов анализа рисков с критериями, установленными в п.6.1.2 а); а также
- 2) расставляет приоритеты обработки проанализированных рисков.
Организация должна сохранять документированную информацию о процессе оценки рисков информационной безопасности.
8.2 Оценка рисков информационной безопасности
8.2 Оценка рисков информационной безопасности
Организация должна выполнять оценки рисков информационной безопасности в запланированные интервалы времени или при наступлении или предполагаемом наступлении значительных изменений, при этом учитываются критерии, установленные в п.6.1.2 а).
Организация должна сохранять документированную информацию по результатам оценок рисков информационной безопасности.
Организация должна выполнять оценки рисков информационной безопасности в запланированные интервалы времени или при наступлении или предполагаемом наступлении значительных изменений, при этом учитываются критерии, установленные в п.6.1.2 а).
Организация должна сохранять документированную информацию по результатам оценок рисков информационной безопасности.
8.3 Обработка рисков информационной безопасности
8.3 Обработка рисков информационной безопасности
Организация должна внедрить план обработки рисков информационной безопасности.
Организация должна сохранять документированную информацию по результатам обработки рисков информационной безопасности.
Организация должна внедрить план обработки рисков информационной безопасности.
Организация должна сохранять документированную информацию по результатам обработки рисков информационной безопасности.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования":
8.3
8.3 Обработка рисков информационной безопасности
Организация должна реализовать план обработки рисков информационной безопасности. Организация должна хранить документированную информацию о результатах обработки рисков информационной безопасности.
Организация должна реализовать план обработки рисков информационной безопасности. Организация должна хранить документированную информацию о результатах обработки рисков информационной безопасности.
8.2
8.2 Оценка рисков информационной безопасности
Организация должна проводить оценку рисков информационной безопасности через запланированные интервалы времени или в случае предполагаемых или произошедших существенных изменений, учитывая критерии рисков информационной безопасности, установленные в соответствии с 6.1.2 а).
Организация должна хранить документированную информацию о результатах проведенных оценок рисков информационной безопасности.
Организация должна проводить оценку рисков информационной безопасности через запланированные интервалы времени или в случае предполагаемых или произошедших существенных изменений, учитывая критерии рисков информационной безопасности, установленные в соответствии с 6.1.2 а).
Организация должна хранить документированную информацию о результатах проведенных оценок рисков информационной безопасности.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 12.3.1
12.3.1
Defined Approach Requirements:
Each PCI DSS requirement that provides flexibility for how frequently it is performed (for example, requirements to be performed periodically) is supported by a targeted risk analysis that is documented and includes:
Defined Approach Requirements:
Each PCI DSS requirement that provides flexibility for how frequently it is performed (for example, requirements to be performed periodically) is supported by a targeted risk analysis that is documented and includes:
- Identification of the assets being protected.
- Identification of the threat(s) that the requirement is protecting against.
- Identification of factors that contribute to the likelihood and/or impact of a threat being realized.
- Resulting analysis that determines, and includes justification for, how frequently the requirement must be performed to minimize the likelihood of the threat being realized.
- Review of each targeted risk analysis at least once every 12 months to determine whether the results are still valid or if an updated risk analysis is needed.
- Performance of updated risk analyses when needed, as determined by the annual review.
Customized Approach Objective:
Up to date knowledge and assessment of risks to the CDE are maintained.
Applicability Notes:
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:
Up to date knowledge and assessment of risks to the CDE are maintained.
Applicability Notes:
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.3.1 Examine documented policies and procedures to verify a process is defined for performing targeted risk analyses for each PCI DSS requirement that provides flexibility for how frequently the requirement is performed, and that the process includes all elements specified in this requirement.
Purpose:
Some PCI DSS requirements allow an entity to define how frequently an activity is performed based on the risk to environment. Performing this risk analysis according to a methodology ensures validity and consistency with policies and procedures.
This targeted risk analysis (as opposed to a traditional enterprise-wide risk assessment) focuses on those PCI DSS requirements that allow an entity flexibility about how frequently an entity performs a given control. For this risk analysis, the entity carefully evaluates each PCI DSS requirement that provides this flexibility and determines the frequency that supports adequate security for the entity, and the level of risk the entity is willing to accept.
The risk analysis identifies the specific assets, such as the system components and data—for example, log files, or credentials—that the requirement is intended to protect, as well as the threat(s) or outcomes that the requirement is protecting the assets from—for example, malware, an undetected intruder, or misuse of credentials. Examples of factors that could contribute to likelihood or impact include any that could increase the vulnerability of an asset to a threat—for example, exposure to untrusted networks, complexity of environment, or high staff turnover—as well as the criticality of the system components, or volume and sensitivity of the data, being protected.
Reviewing the results of these targeted risk analyses at least once every 12 months and upon changes that could impact the risk to the environment allows the organization to ensure the risk analysis results remain current with organizational changes and evolving threats, trends, and technologies, and that the selected frequencies still adequately address the entity’s risk.
Good Practice:
An enterprise-wide risk assessment, which is a point-in-time activity that enables entities to identify threats and associated vulnerabilities, is recommended, but is not required, for entities to determine and understand broader and emerging threats with the potential to negatively impact its business. This enterprise-wide risk assessment could be established as part of an overarching risk management program that is used as an input to the annual review of an organization's overall information security policy (see Requirement 12.1.1).
Examples of risk-assessment methodologies for enterprise-wide risk assessments include, but are not limited to, ISO 27005 and NIST SP 800-30.
Some PCI DSS requirements allow an entity to define how frequently an activity is performed based on the risk to environment. Performing this risk analysis according to a methodology ensures validity and consistency with policies and procedures.
This targeted risk analysis (as opposed to a traditional enterprise-wide risk assessment) focuses on those PCI DSS requirements that allow an entity flexibility about how frequently an entity performs a given control. For this risk analysis, the entity carefully evaluates each PCI DSS requirement that provides this flexibility and determines the frequency that supports adequate security for the entity, and the level of risk the entity is willing to accept.
The risk analysis identifies the specific assets, such as the system components and data—for example, log files, or credentials—that the requirement is intended to protect, as well as the threat(s) or outcomes that the requirement is protecting the assets from—for example, malware, an undetected intruder, or misuse of credentials. Examples of factors that could contribute to likelihood or impact include any that could increase the vulnerability of an asset to a threat—for example, exposure to untrusted networks, complexity of environment, or high staff turnover—as well as the criticality of the system components, or volume and sensitivity of the data, being protected.
Reviewing the results of these targeted risk analyses at least once every 12 months and upon changes that could impact the risk to the environment allows the organization to ensure the risk analysis results remain current with organizational changes and evolving threats, trends, and technologies, and that the selected frequencies still adequately address the entity’s risk.
Good Practice:
An enterprise-wide risk assessment, which is a point-in-time activity that enables entities to identify threats and associated vulnerabilities, is recommended, but is not required, for entities to determine and understand broader and emerging threats with the potential to negatively impact its business. This enterprise-wide risk assessment could be established as part of an overarching risk management program that is used as an input to the annual review of an organization's overall information security policy (see Requirement 12.1.1).
Examples of risk-assessment methodologies for enterprise-wide risk assessments include, but are not limited to, ISO 27005 and NIST SP 800-30.
Guideline for a healthy information system v.2.0 (EN):
41 STANDARD
/STANDARD
Each organization develops within a complex computing environment specific to itself. As such, any position taken or action plan involving the information system security must be considered in light of the risks foreseen by the management. Whether it is organisational or technical measures, their implementation represents a cost for the organization, which needs to ensure that they are able to reduce an identified risk to an acceptable level.
In the most sensitive cases, the risk analysis may call into question certain previous choices. This may be the case if the probability of an event appearing and its potential consequences prove critical for the organization and there is no preventive action to control it.
The recommended approach consists, in broad terms, of defining the context, assessing the risks and dealing with them. The risk assessment generally works by considering two areas: the likelihood and the impacts. This is then followed by the creation of a risk treatment plan to be validated by a designated authority at a higher level.
Three kinds of approach can be considered to control the risks associated with the information system:
In the most sensitive cases, the risk analysis may call into question certain previous choices. This may be the case if the probability of an event appearing and its potential consequences prove critical for the organization and there is no preventive action to control it.
The recommended approach consists, in broad terms, of defining the context, assessing the risks and dealing with them. The risk assessment generally works by considering two areas: the likelihood and the impacts. This is then followed by the creation of a risk treatment plan to be validated by a designated authority at a higher level.
Three kinds of approach can be considered to control the risks associated with the information system:
- the recourse to best IT security practices;
- a systematic risk analysis based on feedback from users;
- a structured risk management formalised by a dedicated methodology.
In this last case, the EBIOS method referenced by ANSSI is recommended. It is able to write down security needs, identify the security objectives and determine the security demands
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Body":
8.2 Information security risk assessment
8.2 Information security risk assessment
The organization shall perform information security risk assessments at planned intervals or when significant changes are proposed or occur, taking account of the criteria established in 6.1.2 a).
The organization shall retain documented information of the results of the information security risk assessments.
The organization shall perform information security risk assessments at planned intervals or when significant changes are proposed or occur, taking account of the criteria established in 6.1.2 a).
The organization shall retain documented information of the results of the information security risk assessments.
6.1.2 Information security risk assessment
6.1.2 Information security risk assessment
The organization shall define and apply an information security risk assessment process that:
The organization shall define and apply an information security risk assessment process that:
- a) establishes and maintains information security risk criteria that include:
- 1) the risk acceptance criteria; and
- 2) criteria for performing information security risk assessments;
- b) ensures that repeated information security risk assessments produce consistent, valid and comparable results;
- c) identifies the information security risks:
- 1) apply the information security risk assessment process to identify risks associated with the loss of confidentiality, integrity and availability for information within the scope of the information security management system; and
- 2) identify the risk owners;
- d) analyses the information security risks:
- e) evaluates the information security risks:
- 1) compare the results of risk analysis with the risk criteria established in 6.1.2 a); and
- 2) prioritize the analysed risks for risk treatment.
The organization shall retain documented information about the information security risk assessment process.
8.3 Information security risk treatment
8.3 Information security risk treatment
The organization shall implement the information security risk treatment plan.
The organization shall retain documented information of the results of the information security risk treatment.
The organization shall implement the information security risk treatment plan.
The organization shall retain documented information of the results of the information security risk treatment.
Положение Банка России № 802-П от 25.07.2022 "О требованиях к защите информации в платежной системе Банка России":
П. 16.1
16.1. Участник СБП - банк плательщика должен осуществлять:
- выявление операций, соответствующих признакам осуществления переводов денежных средств без согласия клиента, установленным Банком России в соответствии с частью 5.1 статьи 8 Федерального закона от 27 июня 2011 года N 161-ФЗ (далее - признаки осуществления переводов денежных средств без согласия клиента), в рамках реализуемой им системы управления рисками при осуществлении переводов денежных средств с использованием сервиса быстрых платежей;
- приостановление в соответствии с частью 5.1 статьи 8 Федерального закона от 27 июня 2011 года N 161-ФЗ исполнения распоряжения в рамках выявленной операции, соответствующей признакам осуществления переводов денежных средств без согласия клиента, с учетом информации об уровне риска операции без согласия клиента (далее - индикатор уровня риска операции), включенной в электронное сообщение, полученной от ОПКЦ СБП в формате и порядке, установленных договором об оказании услуг между участником СБП и ОПКЦ СБП, содержащей в том числе информацию об индикаторе уровня риска операции, сформированном участником СБП - банком получателя;
- формирование индикатора уровня риска операции на основе оценки рисков операций в рамках реализуемой участником СБП - банком плательщика системы управления рисками и его направление в электронном сообщении в ОПКЦ СБП в формате и порядке, установленных договором об оказании услуг между участником СБП и ОПКЦ СБП, - в случае невыявления признаков осуществления перевода денежных средств без согласия клиента.
П. 16.2
16.2. Участник СБП - банк получателя должен осуществлять формирование индикатора уровня риска операции в рамках реализуемой им системы управления рисками, применяемой для выявления операций, соответствующих признакам осуществления переводов денежных средств без согласия клиента, и его направление в электронном сообщении в ОПКЦ СБП в формате и порядке, установленных договором об оказании услуг между участником СБП и ОПКЦ СБП.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.7
А.5.7 Понимание угроз
Для достижения понимания угроз должна собираться и анализироваться информация, относящаяся к угрозам ИБ.
Для достижения понимания угроз должна собираться и анализироваться информация, относящаяся к угрозам ИБ.
SWIFT Customer Security Controls Framework v2022:
7 - 7.4A Scenario Risk Assessment
7.4A Scenario Risk Assessment
NIST Cybersecurity Framework (EN):
ID.RM-3
ID.RM-3: The organization’s determination of risk tolerance is informed by its role in critical infrastructure and sector specific risk analysis
ID.SC-2
ID.SC-2: Suppliers and third party partners of information systems, components, and services are identified, prioritized, and assessed using a cyber supply chain risk assessment process
ID.RM-2
ID.RM-2: Organizational risk tolerance is determined and clearly expressed
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.5.7
А.5.7 Threat intelligence
Information relating to information security threats shall be collected and analysed to produce threat intelligence.
Information relating to information security threats shall be collected and analysed to produce threat intelligence.
Положение Банка России № 716-П от 08.04.2022 "О требованиях к системе управления операционным риском в кредитной организации и банковской группе":
Глава 8. Пункт 7.7
8.7.7. Кредитная организация (головная кредитная организация банковской группы) определяет во внутренних документах дополнительные требования к информационным системам и их функционированию с учетом осуществляемых операций и (или) действующих процессов, уровня и сочетания принимаемых рисков, текущих и стратегических планов развития и доступных возможностей.
Глава 7. Пункт 11.
7.11. Уполномоченное подразделение проводит регулярную (не реже одного раза в год) независимую оценку соблюдения требований, установленных настоящей главой, в рамках оценки эффективности системы управления операционным риском.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.