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

Framework № PCI DSS 4.0 от 01.03.2022

Payment Card Industry Data Security Standard (RU)

Requirement 10.7.3

Для проведения оценки соответствия по документу войдите в систему.

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

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

ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 8":
РОН.4
РОН.4  Обеспечение доступности технических мер обеспечения операционной надежности: 
  • применение отказоустойчивых технических решений; 
  • резервирование аппаратных, программных, аппаратно-программных средств и (или) систем, необходимых для функционирования технических мер обеспечения операционной надежности; 
  • осуществление контроля безотказного функционирования аппаратных, программных, аппаратно-программных средств и (или) систем, реализующих технические меры обеспечения операционной надежности; 
  • принятие регламентированных мер по восстановлению отказавших аппаратных, программных, аппаратно-программных средств и (или) систем, реализующих технические меры обеспечения операционной надежности. 
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 9. Требования к защите информации на этапах жизненного цикла автоматизированных систем и приложений":
ЖЦ.19
ЖЦ.19 Обеспечение доступности технических мер системы защиты информации АС: 
  • применение отказоустойчивых технических мер; - резервирование технических средств АС, необходимых для функционирования технических мер; 
  • осуществление контроля безотказного функционирования технических мер; 
  • принятие регламентированных мер по восстановлению отказавших технических мер и технических средств АС, необходимых для их функционирования
3-Н 2-Н 1-Т
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 8. Требования к организации и управлению защитой информации":
КЗИ.6
КЗИ.6 Контроль безотказного функционирования технических средств, обнаружение и локализация отказов функционирования, принятие мер по восстановлению отказавших средств и их тестирование
3-О 2-Т 1-Т
РЗИ.9
РЗИ.9 Обеспечение доступности технических мер защиты информации: 
  • применение отказоустойчивых технических решений; 
  • резервирование информационной инфраструктуры, необходимой для функционирования технических мер защиты информации; 
  • осуществление контроля безотказного функционирования технических мер защиты информации; 
  • принятие регламентированных мер по восстановлению отказавших технических мер защиты информации информационной инфраструктуры, необходимых для их функционирования
3-Н 2-Н 1-Т
Стандарт № GMP Annex 11: Computerised Systems (EN) от 30.11.2011 "Good Manufacturing Practice. Annex 11: Computerised Systems":
Р. 4 п. 13 п.п. 1
All incidents, not only system failures and data errors, should be reported and assessed. The root cause of a critical incident should be identified and should form the basis of corrective and preventive actions. 
NIST Cybersecurity Framework (RU):
PR.IP-10
PR.IP-10: Проверены планы реагирования и восстановления
RC.RP-1
RC.RP-1: План восстановления выполняется во время или после события 
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ОДТ.1 ОДТ.1 Использование отказоустойчивых технических средств
ОДТ.3 ОДТ.3 Контроль безотказного функционирования технических средств, обнаружение и локализация отказов функционирования, принятие мер по восстановлению отказавших средств и их тестирование
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 10.7.3
10.7.3
Defined Approach Requirements: 
Failures of any critical security controls systems are responded to promptly, including but not limited to:
  • Restoring security functions.
  • Identifying and documenting the duration (date and time from start to end) of the security failure.
  • Identifying and documenting the cause(s) of failure and documenting required remediation.
  • Identifying and addressing any security issues that arose during the failure. 
  • Determining whether further actions are required as a result of the security failure.
  • Implementing controls to prevent the cause of failure from reoccurring.
  • Resuming monitoring of security controls. 
Customized Approach Objective:
Failures of critical security control systems are analyzed, contained, and resolved, and security controls restored to minimize impact. Resulting security issues are addressed, and measures taken to prevent reoccurrence. 

Applicability Notes:
This requirement applies only when the entity being assessed is a service provider until 31 March 2025, after which this requirement will apply to all entities. 
This is a current v3.2.1 requirement that applies to service providers only. However, this requirement is a best practice for all other entities until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:
  • 10.7.3.a Examine documentation and interview personnel to verify that processes are defined and implemented to respond to a failure of any critical security control system and include at least all elements specified in this requirement. 
  • 10.7.3.b Examine records to verify that failures of critical security control systems are documented to include:
    • Identification of cause(s) of the failure.
    • Duration (date and time start and end) of the security failure.
    • Details of the remediation required to address the root cause. 
Purpose:
If alerts from failures of critical security control systems are not responded to quickly and effectively, attackers may use this time to insert malicious software, gain control of a system, or steal data from the entity’s environment. 

Good Practice:
Documented evidence (for example, records within a problem management system) should provide support that processes and procedures are in place to respond to security failures. In addition, personnel should be aware of their responsibilities in the event of a failure. Actions and responses to the failure should be captured in the documented evidence. 
Стандарт № GMP Annex 11: Computerised Systems (RU) от 30.11.2011 "Правила надлежащей производственной практики. Приложение 11: Компьютеризированные системы":
Р. 4 п. 13 п.п. 1
Все инциденты (непредвиденные случаи), включая системные сбои и ошибки данных, должны быть записаны и оценены. Следует установить основную причину критических сбоев и использовать эту информацию в качестве основы корректирующих и предупреждающих действий. 
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
ОДТ.1 ОДТ.1 Использование отказоустойчивых технических средств
ОДТ.3 ОДТ.3 Контроль безотказного функционирования технических средств, обнаружение и локализация отказов функционирования, принятие мер по восстановлению отказавших средств и их тестирование
ЗИС.22 ЗИС.22 Защита информационной системы от угроз безопасности информации, направленных на отказ в обслуживании информационной системы
ЗИС.29 ЗИС.29 Перевод информационной системы или ее устройств (компонентов) в заранее определенную конфигурацию, обеспечивающую защиту информации, в случае возникновении отказов (сбоев) в системе защиты информации информационной системы
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ОДТ.3 ОДТ.3 Контроль безотказного функционирования средств и систем
ЗИС.37 ЗИС.37 Перевод информационной (автоматизированной) системы в безопасное состояние при возникновении отказов (сбоев)
ОДТ.1 ОДТ.1 Использование отказоустойчивых технических средств
NIST Cybersecurity Framework (EN):
PR.IP-10 PR.IP-10: Response and recovery plans are tested
RC.RP-1 RC.RP-1: Recovery plan is executed during or after a cybersecurity incident
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ОДТ.3
ОДТ.3 Контроль безотказного функционирования средств и систем
ЗИС.37 ЗИС.37 Перевод информационной (автоматизированной) системы в безопасное состояние при возникновении отказов (сбоев)
ОДТ.1 ОДТ.1 Использование отказоустойчивых технических средств

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

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

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