Куда я попал?
NIST Cybersecurity Framework (RU)
Framework
ID.RM-3
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
ГОСТ Р № 57580.3-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Управление риском реализации информационных угроз и обеспечение операционной надежности. Общие положения.":
ВИО.8
ВИО.8 Организация и выполнение на регулярной основе деятельности по определению и анализу возможных информационных угроз: - присущих осуществлению видов деятельности финансовой организации; - присущих взаимодействию финансовой организации с причастными сторонами.
ВИО.1
ВИО.1 Организация* и выполнение деятельности по анализу базы событий риска реализации информационных угроз.
ОПР.1.1
ОПР.1.1 Определение и описание состава процессов управления риском реализации информационных угроз, обеспечения операционной надежности и защиты информации;
ГОСТ Р № 22301 от 01.01.2022 "Надежность в технике. Системы менеджмента непрерывности деятельности. Требования":
Р. 8 п. 2 пп. 1
8.2.1 Общие положения
Организация должна:
Организация должна:
- а) выполнять и поддерживать систематические процессы анализа воздействий на деятельность и оценки риска возникновения нарушения деятельности организации;
- b) проводить анализ воздействий на деятельность и оценку риска через запланированные промежутки времени и при наличии существенных изменений в организации или в области применения.
Примечание — Организация должна определить порядок проведения анализа воздействий на деятельность и оценки риска.
Р. 8 п. 3 пп. 3
8.3.3 Выбор стратегий и решений
Выбор стратегий и решений должен быть основан на уровне их полезности:
Выбор стратегий и решений должен быть основан на уровне их полезности:
- а) при выполнении требований к продолжению и восстановлению приоритетных видов деятельности в установленные сроки и на уровне согласованного объема производства;
- b) проведении анализа величины и вида риска, который организация может или не может принять;
- с) рассмотрении связанных с этим затрат и преимуществ.
Р. 6 п. 1 пп. 1
6.1.1 Определение риска и благоприятных возможностей
При планировании СМНД организация должна учитывать вопросы, указанные в 4.1. требования, указанные в 4.2, и определить риски и возможности:
При планировании СМНД организация должна учитывать вопросы, указанные в 4.1. требования, указанные в 4.2, и определить риски и возможности:
- а) для обеспечения уверенности в достижении СМНД поставленных целей;
- b) предупреждения или снижения нежелательных воздействий;
- с) обеспечения постоянного улучшения.
Р. 4 п. 1
4.1 Понимание особенностей организации и условий ее работы
Организация должна определить внешние и внутренние проблемы, которые могут повлиять на ее возможности достижения поставленных целей и намеченных результатов системы менеджмента непрерывности деятельности (СМНД).
Примечание — Эти проблемы связаны с общими целями организации, ее продукцией и услугами, а также величиной и типом риска, который может или не может быть принят организацией.
Организация должна определить внешние и внутренние проблемы, которые могут повлиять на ее возможности достижения поставленных целей и намеченных результатов системы менеджмента непрерывности деятельности (СМНД).
Примечание — Эти проблемы связаны с общими целями организации, ее продукцией и услугами, а также величиной и типом риска, который может или не может быть принят организацией.
Р. 9 п. 3 пп. 2
9.3.2 Входные данные для анализа со стороны руководства
Анализ со стороны руководства должен включать рассмотрение:
Анализ со стороны руководства должен включать рассмотрение:
- а) статуса действий по результатам предыдущего анализа со стороны руководства;
- b) изменения во внешних и внутренних проблемах, которые имеют отношение к СМНД;
- с) информации о показателях работы СМНД, включая тенденции:
- 1) несоответствий и корректирующих действий;
- 2) результатов мониторинга и оценки измерений;
- 3) результатов аудита;
- d) отзывов заинтересованных сторон;
- е) необходимости изменений СМНД. включая политику и цели;
- f) процедур и ресурсов, которые можно использовать в организации для улучшения показателей результативности СМНД;
- g) информации, полученной на основе воздействий анализа на деятельность и оценки риска;
- h) результатов оценки документации и возможностей по обеспечению непрерывности деятельности (см. 8.6);
- i) риска или проблем, которые не были адекватно рассмотрены при предыдущей оценке риска;
- j) извлеченных уроков и действий, возникших в результате промахов и нарушения деятельности организации;
- к) возможностей постоянного улучшения.
Стандарт № ИСО/МЭК 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.3 Обработка рисков информационной безопасности
8.3 Обработка рисков информационной безопасности
Организация должна внедрить план обработки рисков информационной безопасности.
Организация должна сохранять документированную информацию по результатам обработки рисков информационной безопасности.
Организация должна внедрить план обработки рисков информационной безопасности.
Организация должна сохранять документированную информацию по результатам обработки рисков информационной безопасности.
6.1.3 Обработка рисков информационной безопасности
6.1.3 Обработка рисков информационной безопасности
Организация должна определить и применять процесс обработки рисков в целях:
Организация должна определить и применять процесс обработки рисков в целях:
- a) выбора применимых вариантов обработки рисков информационной безопасности, учитывающих результаты оценки рисков;
- b) определения всех средств управления информационной безопасностью, необходимых для внедрения выбранного варианта (-ов) обработки рисков информационной безопасности;
ПРИМЕЧАНИЕ 1 Организация может разработать средства управления информационной безопасностью, по мере необходимости, или определить их из иного источника.
- c) сравнения средств управления информационной безопасностью, вышеопределенных в п.6.1.3 b) и содержащихся в Приложении А, а также подтверждения того, что ни одно необходимое средство управления информационной безопасностью не пропущено;
ПРИМЕЧЕНИЕ 2 Приложение А содержит перечень средств управления информационной безопасностью. Пользователи настоящего документа отсылаются к Приложению А для обеспечения того, что ни одно необходимое средство управления информационной безопасностью не будет пропущено.
ПРИМЕЧАНИЕ 3 Перечисленные в Приложении А средства управления информационной безопасностью не являются исчерпывающими и, по необходимости, могут быть применены потребоваться дополнительные средства управления информационной безопасностью.
ПРИМЕЧАНИЕ 3 Перечисленные в Приложении А средства управления информационной безопасностью не являются исчерпывающими и, по необходимости, могут быть применены потребоваться дополнительные средства управления информационной безопасностью.
- d) выработки Положения о Применимости, которое содержит:
- необходимые средства управления информационной безопасностью (см. п.6.1.3 b) и с));
- обоснование их применения;
- сведения от том, реализованы они или нет, а также
- обоснование исключения из применения приведенных в Приложении А средств управления информационной безопасностью.
- e) разработки плана обработки рисков; а также
- f) получения одобрения плана обработки рисков информационной безопасности и остаточных рисков информационной безопасности со стороны владельцев рисков.
Организация должна сохранять документированную информацию о процессе обработки рисков информационной безопасности.
ПРИМЕЧАНИЕ 4 Процесс оценки и обработки рисков информационной безопасности в настоящем документе соответствует принципам и общим указаниям, изложенным в ИСО 31000.
ПРИМЕЧАНИЕ 4 Процесс оценки и обработки рисков информационной безопасности в настоящем документе соответствует принципам и общим указаниям, изложенным в ИСО 31000.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования":
8.3
8.3 Обработка рисков информационной безопасности
Организация должна реализовать план обработки рисков информационной безопасности. Организация должна хранить документированную информацию о результатах обработки рисков информационной безопасности.
Организация должна реализовать план обработки рисков информационной безопасности. Организация должна хранить документированную информацию о результатах обработки рисков информационной безопасности.
6.1.3
6.1.3 Обработка рисков информационной безопасности
Организация должна определить и применять процесс обработки рисков информационной безопасности:
а) для выбора подходящих вариантов обработки рисков информационной безопасности, учитывая результаты оценки рисков информационной безопасности;
b) определения всех мер и средств информационной безопасности, необходимых для реализации выбранного(ых) варианта(ов) обработки рисков информационной безопасности.
Примечание — При необходимости организация может разрабатывать меры обеспечения информационной безопасности или взять их из любого источника;
с) сравнения мер и средств информационной безопасности, определенных в соответствии с 6.1.3 Ь), с указанными в приложении А для проверки того, что никакие необходимые меры обеспечения информационной безопасности не были упущены.
Примечание 1 — Приложение А содержит базовый перечень мер и средств информационной безопасности и целей их применения. Пользователям настоящего стандарта следует обращаться к приложению А для обеспечения уверенности в том, что никакие необходимые меры обеспечения информационной безопасности не были упущены.
Примечание 2 — Цели применения мер и средств информационной безопасности неявным образом включены в выбранные меры обеспечения информационной безопасности. Приведенные в приложении А меры обеспечения информационной безопасности и цели их применения не являются исчерпывающими, и организация может рассматривать необходимость дополнительных мер и средств информационной безопасности и целей их применения;
d) подготовки ведомости применимости мер и средств информационной безопасности, которая содержит (Пункт 6.1.3 d) приведен с учетом технической правки к ISO/IEC 27001:2013.)
Организация должна определить и применять процесс обработки рисков информационной безопасности:
а) для выбора подходящих вариантов обработки рисков информационной безопасности, учитывая результаты оценки рисков информационной безопасности;
b) определения всех мер и средств информационной безопасности, необходимых для реализации выбранного(ых) варианта(ов) обработки рисков информационной безопасности.
Примечание — При необходимости организация может разрабатывать меры обеспечения информационной безопасности или взять их из любого источника;
с) сравнения мер и средств информационной безопасности, определенных в соответствии с 6.1.3 Ь), с указанными в приложении А для проверки того, что никакие необходимые меры обеспечения информационной безопасности не были упущены.
Примечание 1 — Приложение А содержит базовый перечень мер и средств информационной безопасности и целей их применения. Пользователям настоящего стандарта следует обращаться к приложению А для обеспечения уверенности в том, что никакие необходимые меры обеспечения информационной безопасности не были упущены.
Примечание 2 — Цели применения мер и средств информационной безопасности неявным образом включены в выбранные меры обеспечения информационной безопасности. Приведенные в приложении А меры обеспечения информационной безопасности и цели их применения не являются исчерпывающими, и организация может рассматривать необходимость дополнительных мер и средств информационной безопасности и целей их применения;
d) подготовки ведомости применимости мер и средств информационной безопасности, которая содержит (Пункт 6.1.3 d) приведен с учетом технической правки к ISO/IEC 27001:2013.)
- необходимые меры обеспечения информационной безопасности [см. 6.1.3 Ь) и с)];
- обоснования их применения;
- информацию о том, реализованы или нет необходимые меры обеспечения информационной безопасности;
- обоснования неприменения мер и средств информационной безопасности, представленных в приложении А;
е) разработки плана обработки рисков информационной безопасности;
f) согласования и (или) утверждения плана обработки рисков информационной безопасности и принятия остаточных рисков информационной безопасности владельцами рисков.
Организация должна хранить документированную информацию о процессе обработки рисков информационной безопасности.
Примечание — Процесс оценки и обработки рисков информационной безопасности в настоящем стандарте согласуется с принципами и общими рекомендациями, представленными в ИСО 31000.
f) согласования и (или) утверждения плана обработки рисков информационной безопасности и принятия остаточных рисков информационной безопасности владельцами рисков.
Организация должна хранить документированную информацию о процессе обработки рисков информационной безопасности.
Примечание — Процесс оценки и обработки рисков информационной безопасности в настоящем стандарте согласуется с принципами и общими рекомендациями, представленными в ИСО 31000.
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":
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.
6.1.3 Information security risk treatment
6.1.3 Information security risk treatment
The organization shall define and apply an information security risk treatment process to:
The organization shall define and apply an information security risk treatment process to:
- a) select appropriate information security risk treatment options, taking account of the risk assessment results;
- b) determine all controls that are necessary to implement the information security risk treatment option(s) chosen;
NOTE 1 Organizations can design controls as required, or identify them from any source.
- c) compare the controls determined in 6.1.3 b) above with those in Annex A and verify that no necessary controls have been omitted;
NOTE 2 Annex A contains a list of possible information security controls. Users of this document are directed to Annex A to ensure that no necessary information security controls are overlooked.
NOTE 3 The information security controls listed in Annex A are not exhaustive and additional information security controls can be included if needed.
NOTE 3 The information security controls listed in Annex A are not exhaustive and additional information security controls can be included if needed.
- d) produce a Statement of Applicability that contains:· the necessary controls (see 6.1.3 b) and c));· justification for their inclusion;· whether the necessary controls are implemented or not; and· the justification for excluding any of the Annex A controls.;
- e) formulate an information security risk treatment plan; and
- f) obtain risk owners’ approval of the information security risk treatment plan and acceptance of the residual information security risks.
The organization shall retain documented information about the information security risk treatment process.
NOTE 4 The information security risk assessment and treatment process in this document aligns with the principles and generic guidelines provided in ISO 31000.
NOTE 4 The information security risk assessment and treatment process in this document aligns with the principles and generic guidelines provided in ISO 31000.
Положение Банка России № 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. Участник СБП - банк получателя должен осуществлять формирование индикатора уровня риска операции в рамках реализуемой им системы управления рисками, применяемой для выявления операций, соответствующих признакам осуществления переводов денежных средств без согласия клиента, и его направление в электронном сообщении в ОПКЦ СБП в формате и порядке, установленных договором об оказании услуг между участником СБП и ОПКЦ СБП.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 12.3.1
12.3.1
Определенные Требования к Подходу:
Каждое требование PCI DSS, обеспечивающее гибкость в отношении частоты его выполнения (например, требования, которые должны выполняться периодически), подкрепляется целевым анализом рисков, который документируется и включает:
Определенные Требования к Подходу:
Каждое требование PCI DSS, обеспечивающее гибкость в отношении частоты его выполнения (например, требования, которые должны выполняться периодически), подкрепляется целевым анализом рисков, который документируется и включает:
- Идентификация защищаемых активов.
- Идентификация угрозы (угроз), от которой защищает требование.
- Выявление факторов, которые способствуют вероятности и/или воздействию реализуемой угрозы.
- Итоговый анализ, который определяет и включает обоснование того, как часто должно выполняться требование, чтобы свести к минимуму вероятность реализации угрозы.
- Просматривайте каждый целевой анализ рисков не реже одного раза в 12 месяцев, чтобы определить, остаются ли результаты в силе или необходим обновленный анализ рисков.
- Проведение обновленного анализа рисков, когда это необходимо, в соответствии с ежегодным обзором.
Цель Индивидуального подхода:
Поддерживаются актуальные знания и оценка рисков для CDE.
Примечания по применению:
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
Поддерживаются актуальные знания и оценка рисков для CDE.
Примечания по применению:
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
- 12.3.1 Изучите документированные политики и процедуры, чтобы убедиться, что определен процесс для выполнения целевого анализа рисков для каждого требования PCI DSS, который обеспечивает гибкость в отношении того, как часто выполняется требование, и что процесс включает все элементы, указанные в этом требовании.
Цель:
Некоторые требования PCI DSS позволяют организации определять, как часто выполняется та или иная деятельность, исходя из риска для окружающей среды. Выполнение этого анализа рисков в соответствии с методологией обеспечивает обоснованность и согласованность с политиками и процедурами.
Этот целевой анализ рисков (в отличие от традиционной общеорганизационной оценки рисков) фокусируется на тех требованиях PCI DSS, которые позволяют организации гибко выбирать, как часто организация выполняет тот или иной контроль. Для этого анализа рисков организация тщательно оценивает каждое требование PCI DSS, обеспечивающее такую гибкость, и определяет частоту, обеспечивающую надлежащую безопасность для организации, а также уровень риска, который организация готова принять.
Анализ рисков определяет конкретные активы, такие как системные компоненты и данные — например, файлы журналов или учетные данные, — для защиты которых предназначено требование, а также угрозы или последствия, от которых требование защищает активы — например, вредоносное ПО, необнаруженный злоумышленник, или неправильное использование учетных данных. Примеры факторов, которые могут способствовать вероятности или воздействию, включают любые, которые могут повысить уязвимость актива к угрозе, например, подверженность ненадежным сетям, сложность среды или высокая текучесть кадров, а также критичность компонентов системы или объем и критичность данных, поскольку защищенный.
Анализ результатов этих целевых анализов рисков не реже одного раза в 12 месяцев и при изменениях, которые могут повлиять на риск для окружающей среды, позволяет организации убедиться, что результаты анализа рисков остаются актуальными с учетом организационных изменений и развивающихся угроз, тенденций и технологий, а также что выбранные частоты по-прежнему адекватно учитывают риск организации..
Надлежащая практика:
Оценка рисков в масштабах всей организации, которая представляет собой оперативную деятельность, позволяющую организациям выявлять угрозы и связанные с ними уязвимости, рекомендуется, но не требуется, для определения и понимания более широких и возникающих угроз, которые могут негативно повлиять на их бизнес. Эта общеорганизационная оценка рисков может быть создана как часть всеобъемлющей программы управления рисками, которая используется в качестве вклада в ежегодный обзор общей политики информационной безопасности организации (см. Требование 12.1.1).
Примеры методологий оценки рисков для оценки рисков в масштабах предприятия включают, но не ограничиваются ими, ISO 27005 и NIST SP 800-30.
Некоторые требования PCI DSS позволяют организации определять, как часто выполняется та или иная деятельность, исходя из риска для окружающей среды. Выполнение этого анализа рисков в соответствии с методологией обеспечивает обоснованность и согласованность с политиками и процедурами.
Этот целевой анализ рисков (в отличие от традиционной общеорганизационной оценки рисков) фокусируется на тех требованиях PCI DSS, которые позволяют организации гибко выбирать, как часто организация выполняет тот или иной контроль. Для этого анализа рисков организация тщательно оценивает каждое требование PCI DSS, обеспечивающее такую гибкость, и определяет частоту, обеспечивающую надлежащую безопасность для организации, а также уровень риска, который организация готова принять.
Анализ рисков определяет конкретные активы, такие как системные компоненты и данные — например, файлы журналов или учетные данные, — для защиты которых предназначено требование, а также угрозы или последствия, от которых требование защищает активы — например, вредоносное ПО, необнаруженный злоумышленник, или неправильное использование учетных данных. Примеры факторов, которые могут способствовать вероятности или воздействию, включают любые, которые могут повысить уязвимость актива к угрозе, например, подверженность ненадежным сетям, сложность среды или высокая текучесть кадров, а также критичность компонентов системы или объем и критичность данных, поскольку защищенный.
Анализ результатов этих целевых анализов рисков не реже одного раза в 12 месяцев и при изменениях, которые могут повлиять на риск для окружающей среды, позволяет организации убедиться, что результаты анализа рисков остаются актуальными с учетом организационных изменений и развивающихся угроз, тенденций и технологий, а также что выбранные частоты по-прежнему адекватно учитывают риск организации..
Надлежащая практика:
Оценка рисков в масштабах всей организации, которая представляет собой оперативную деятельность, позволяющую организациям выявлять угрозы и связанные с ними уязвимости, рекомендуется, но не требуется, для определения и понимания более широких и возникающих угроз, которые могут негативно повлиять на их бизнес. Эта общеорганизационная оценка рисков может быть создана как часть всеобъемлющей программы управления рисками, которая используется в качестве вклада в ежегодный обзор общей политики информационной безопасности организации (см. Требование 12.1.1).
Примеры методологий оценки рисков для оценки рисков в масштабах предприятия включают, но не ограничиваются ими, ISO 27005 и NIST SP 800-30.
Положение Банка России № 719-П от 04.06.2020 "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств":
Глава 5 п. 1
5.1. Оператор платежной системы в целях реализации пункта 11 части 3 статьи 28 Федерального закона № 161-ФЗ (Собрание законодательства Российской Федерации, 2011, № 27, ст. 3872) в рамках системы управления рисками в платежной системе определяет в правилах платежной системы и иных документах порядок обеспечения защиты информации в платежной системе для операторов по переводу денежных средств, являющихся участниками платежной системы, операторов услуг платежной инфраструктуры с учетом требований к обеспечению защиты информации при осуществлении переводов денежных средств (далее - требования к обеспечению защиты информации в платежной системе).
Оператор платежной системы должен определить требования к обеспечению защиты информации в платежной системе в отношении следующих мероприятий:
- управление риском информационной безопасности в платежной системе как одним из видов операционного риска в платежной системе, источниками реализации которого являются: недостатки процессов обеспечения защиты информации, в том числе недостатки применяемых технологических мер защиты информации, недостатки прикладного программного обеспечения автоматизированных систем и приложений, а также несоблюдение требований к указанным процессам деятельности операторами по переводу денежных средств, являющимися участниками платежной системы, операторами услуг платежной инфраструктуры (далее - риск информационной безопасности в платежной системе);
- установление состава показателей уровня риска информационной безопасности в платежной системе;
- реализация операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры механизмов, направленных на соблюдение требований к обеспечению защиты информации при осуществлении переводов денежных средств, и контроль их соблюдения операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры;
- реализация операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры процессов выявления и идентификации риска информационной безопасности в платежной системе в отношении объектов информационной инфраструктуры участников платежной системы, операторов услуг платежной инфраструктуры;
- выявление и анализ операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры риска информационной безопасности в платежной системе;
- реализация операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры процессов реагирования на инциденты защиты информации и восстановления штатного функционирования объектов информационной инфраструктуры в случае реализации инцидентов защиты информации;
- реализация операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры взаимодействия при обмене информацией об инцидентах защиты информации;
- реализация операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры мероприятий по противодействию осуществлению переводов денежных средств без согласия клиента, определенных пунктами 2.2 и 2.4 Указания Банка России от 8 октября 2018 года № 4926-У «О форме и порядке направления операторами по переводу денежных средств, операторами платежных систем, операторами услуг платежной инфраструктуры в Банк России информации обо всех случаях и (или) попытках осуществления переводов денежных средств без согласия клиента и получения ими от Банка России информации, содержащейся в базе данных о случаях и попытках осуществления переводов денежных средств без согласия клиента, а также о порядке реализации операторами по переводу денежных средств, операторами платежных систем, операторами услуг платежной инфраструктуры мероприятий по противодействию осуществлению переводов денежных средств без согласия клиента», зарегистрированного Министерством юстиции Российской Федерации 12 декабря 2018 года № 52988;
- реализация операторами платежных систем процессов применения в отношении операторов по переводу денежных средств, являющихся участниками платежной системы, и операторов услуг платежной инфраструктуры ограничений по параметрам операций по осуществлению переводов денежных средств в случае выявления факта превышения значений показателей уровня риска информационной безопасности в платежной системе, в том числе условий снятия таких ограничений.
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
Положение Банка России № 716-П от 08.04.2022 "О требованиях к системе управления операционным риском в кредитной организации и банковской группе":
Глава 7. Пункт 1.
7.1. Кредитная организация (головная кредитная организация банковской группы) определяет во внутренних документах порядок управления риском информационной безопасности.
Связанные защитные меры
| Название | Дата | Влияние | ||
|---|---|---|---|---|
|
Community
48 / 178
|
Внедрение процесса управления рисками информационной безопасности
Вручную
Организационная
Детективная
08.05.2022
|
08.05.2022 | 48 / 178 |
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.