Раздел 41 STANDARD Guideline for a healthy information system v.2.0 (EN)

Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":

Р. 8 п. 4 п.п. 4

8.4.4. Оценка рисков нарушения ИБ проводится для свойств ИБ всех информационных активов (типов информационных активов) области действия СОИБ.

Р. 5 п. 5.15

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

Р. 8 п. 4 п.п. 1

8.4.1. В организации БС РФ должна быть принята/корректироваться методика оценки рисков нарушения ИБ/подход к оценке рисков нарушения ИБ.

Р. 8 п. 4 п.п. 2

8.4.2. В организации БС РФ должны быть определены критерии принятия рисков нарушения ИБ и уровень допустимого риска нарушения ИБ.

Р. 5 п. 5.18

5.18. Идентификация, анализ и оценивание рисков нарушения ИБ должны основываться на идентификации активов организации БС РФ, на их ценности для целей и задач организации БС РФ, на моделях угроз и нарушителей ИБ организации БС РФ.

Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":

п. 6

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

требования к порядку определения значений целевых показателей операционной надежности и обеспечению контроля за их соблюдением;
требования к идентификации состава элементов, указанных в подпункте 6.1 настоящего пункта;
требования к управлению изменениями элементов, указанных в подпункте 6.1 настоящего пункта;
требования к выявлению, регистрации инцидентов операционной надежности и реагированию на них, а также восстановлению выполнения технологических процессов и функционирования объектов информационной инфраструктуры после реализации указанных инцидентов с учетом установленных главой 7 Положения Банка России N 716-П требований к выявлению событий риска информационной безопасности, порядку реагирования на выявленные события риска информационной безопасности и восстановлению деятельности кредитной организации в случае реализации таких событий;
требования к взаимодействию с третьими лицами (внешними подрядчиками, контрагентами, участниками банковской группы), оказывающими услуги в сфере информационных технологий, связанные с выполнением технологических процессов (далее - поставщики услуг в сфере информационных технологий), с учетом установленных главами 7 и 8 Положения Банка России N 716-П требований к управлению риском информационной безопасности и риском информационных систем при передаче поставщикам услуг в сфере информационных технологий выполнения отдельных функций кредитной организации и (или) использовании внешних информационных систем, а также требований к аутсорсингу обслуживания и функционирования информационных систем;
требования к тестированию операционной надежности технологических процессов;
требования к нейтрализации информационных угроз со стороны несанкционированного доступа работников кредитной организации или работников поставщиков услуг в сфере информационных технологий, обладающих полномочиями доступа к объектам информационной инфраструктуры (далее - внутренний нарушитель), к объектам информационной инфраструктуры;
требования к обеспечению осведомленности кредитной организации об актуальных информационных угрозах, которые могут привести к инцидентам операционной надежности.

NIST Cybersecurity Framework (RU):

ID.RM-3

ID.RM-3: Определение отношения (степени принятия риска) к риску организации основывается на ее роли в критической инфраструктуре и анализе рисков для конкретных секторов

ID.RM-1

ID.RM-1: Процессы управления рисками установлены, управляются и согласованы заинтересованными сторонами организации

ID.GV-4

ID.GV-4: Процессы руководства и управления рисками направлены на устранение рисков кибербезопасности

ID.RM-2

ID.RM-2: Определен и четко выражен критерий принятия риска в организации

ID.RA-5

ID.RA-5: Угрозы, уязвимости, вероятности и воздействия используются для определения риска

ID.RA-6

ID.RA-6: Для рисков определены и расставлены по приоритетам ответные меры

Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Тело стандарта":

8.2 Оценка рисков информационной безопасности

8.2 Оценка рисков информационной безопасности
Организация должна выполнять оценки рисков информационной безопасности в запланированные интервалы времени или при наступлении или предполагаемом наступлении значительных изменений, при этом учитываются критерии, установленные в п.6.1.2 а).
Организация должна сохранять документированную информацию по результатам оценок рисков информационной безопасности.

6.1.1 Общие положения

6.1.1 Общие положения
При планировании системы менеджмента информационной безопасности организация должна рассмотреть параметры, относящиеся к п. 4.1, требования из п.4.2, а также определить риски и возможности, которые требуются в отношении вопросов:

а) обеспечения достижения системой менеджмента информационной безопасности ее ожидаемых результатов;
b) предотвращения или снижения нежелательных последствий, а также
c) достижения непрерывного улучшения

Организация должна планировать:

d) действия в отношении этих рисков и возможностей; а также
e) каким образом
- 1) интегрировать и внедрить действия в процессы ее системы менеджмента информационной безопасности; а также
- 2) оценивать эффективность этих действий.

6.1.3 Обработка рисков информационной безопасности

6.1.3 Обработка рисков информационной безопасности
Организация должна определить и применять процесс обработки рисков в целях:

a) выбора применимых вариантов обработки рисков информационной безопасности, учитывающих результаты оценки рисков;
b) определения всех средств управления информационной безопасностью, необходимых для внедрения выбранного варианта (-ов) обработки рисков информационной безопасности;

ПРИМЕЧАНИЕ 1 Организация может разработать средства управления информационной безопасностью, по мере необходимости, или определить их из иного источника.

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

ПРИМЕЧЕНИЕ 2 Приложение А содержит перечень средств управления информационной безопасностью. Пользователи настоящего документа отсылаются к Приложению А для обеспечения того, что ни одно необходимое средство управления информационной безопасностью не будет пропущено.
ПРИМЕЧАНИЕ 3 Перечисленные в Приложении А средства управления информационной безопасностью не являются исчерпывающими и, по необходимости, могут быть применены потребоваться дополнительные средства управления информационной безопасностью.

d) выработки Положения о Применимости, которое содержит:
- необходимые средства управления информационной безопасностью (см. п.6.1.3 b) и с));
- обоснование их применения;
- сведения от том, реализованы они или нет, а также
- обоснование исключения из применения приведенных в Приложении А средств управления информационной безопасностью.
e) разработки плана обработки рисков; а также
f) получения одобрения плана обработки рисков информационной безопасности и остаточных рисков информационной безопасности со стороны владельцев рисков.

Организация должна сохранять документированную информацию о процессе обработки рисков информационной безопасности.
ПРИМЕЧАНИЕ 4 Процесс оценки и обработки рисков информационной безопасности в настоящем документе соответствует принципам и общим указаниям, изложенным в ИСО 31000.

ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования":

8.2

8.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:

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:

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.

Стандарт № 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.

6.1.1 General

6.1.1 General
When planning for the information security management system, the organization shall consider the issues referred to in 4.1 and the requirements referred to in 4.2 and determine the risks and opportunities that need to be addressed to:

a) ensure the information security management system can achieve its intended outcome(s);
b) prevent, or reduce, undesired effects; and
c) achieve continual improvement.

The organization shall plan:

d) actions to address these risks and opportunities; and
e) how to
- 1) integrate and implement the actions into its information security management system processes; and
- 2) evaluate the effectiveness of these actions.

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:

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.

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.

Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":

Requirement 12.3.1

12.3.1
Определенные Требования к Подходу:
Каждое требование PCI DSS, обеспечивающее гибкость в отношении частоты его выполнения (например, требования, которые должны выполняться периодически), подкрепляется целевым анализом рисков, который документируется и включает:

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

Цель Индивидуального подхода:
Поддерживаются актуальные знания и оценка рисков для 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.

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.RM-1 ID.RM-1: Risk management processes are established, managed, and agreed to by organizational stakeholders

ID.GV-4 ID.GV-4: Governance and risk management processes address cybersecurity risks

ID.RM-2 ID.RM-2: Organizational risk tolerance is determined and clearly expressed

ID.RA-5 ID.RA-5: Threats, vulnerabilities, likelihoods, and impacts are used to determine risk

ID.RA-6 ID.RA-6: Risk responses are identified and prioritized

Guideline for a healthy information system v.2.0 (EN)

Framework

41 STANDARD

Список требований

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

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