Куда я попал?
SECURITM это SGRC система, ? автоматизирующая процессы в службах информационной безопасности. SECURITM помогает построить и управлять ИСПДн, КИИ, ГИС, СМИБ/СУИБ, банковскими системами защиты.
А еще SECURITM это место для обмена опытом и наработками для служб безопасности.

CIS Critical Security Controls v8 (The 18 CIS CSC)

Framework

7.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. 
Положение Банка России № 802-П от 25.07.2022 "О требованиях к защите информации в платежной системе Банка России":
П. 16.1
16.1. Участник СБП - банк плательщика должен осуществлять:
  • выявление операций, соответствующих признакам осуществления переводов денежных средств без согласия клиента, установленным Банком России в соответствии с частью 5.1 статьи 8 Федерального закона от 27 июня 2011 года N 161-ФЗ (далее - признаки осуществления переводов денежных средств без согласия клиента), в рамках реализуемой им системы управления рисками при осуществлении переводов денежных средств с использованием сервиса быстрых платежей;
  • приостановление в соответствии с частью 5.1 статьи 8 Федерального закона от 27 июня 2011 года N 161-ФЗ исполнения распоряжения в рамках выявленной операции, соответствующей признакам осуществления переводов денежных средств без согласия клиента, с учетом информации об уровне риска операции без согласия клиента (далее - индикатор уровня риска операции), включенной в электронное сообщение, полученной от ОПКЦ СБП в формате и порядке, установленных договором об оказании услуг между участником СБП и ОПКЦ СБП, содержащей в том числе информацию об индикаторе уровня риска операции, сформированном участником СБП - банком получателя;
  • формирование индикатора уровня риска операции на основе оценки рисков операций в рамках реализуемой участником СБП - банком плательщика системы управления рисками и его направление в электронном сообщении в ОПКЦ СБП в формате и порядке, установленных договором об оказании услуг между участником СБП и ОПКЦ СБП, - в случае невыявления признаков осуществления перевода денежных средств без согласия клиента.
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.

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

Ничего не найдено

Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.