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

Framework № PCI DSS 4.0 от 01.03.2022

Payment Card Industry Data Security Standard

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. Требования к организации и управлению защитой информации":
РЗИ.9
РЗИ.9 Обеспечение доступности технических мер защиты информации: 
  • применение отказоустойчивых технических решений; 
  • резервирование информационной инфраструктуры, необходимой для функционирования технических мер защиты информации; 
  • осуществление контроля безотказного функционирования технических мер защиты информации; 
  • принятие регламентированных мер по восстановлению отказавших технических мер защиты информации информационной инфраструктуры, необходимых для их функционирования
3-Н 2-Н 1-Т
КЗИ.6
КЗИ.6 Контроль безотказного функционирования технических средств, обнаружение и локализация отказов функционирования, принятие мер по восстановлению отказавших средств и их тестирование
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):
RC.RP-1
RC.RP-1: План восстановления выполняется во время или после события 
PR.IP-10
PR.IP-10: Проверены планы реагирования и восстановления
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ОДТ.1 ОДТ.1 Использование отказоустойчивых технических средств
ОДТ.3 ОДТ.3 Контроль безотказного функционирования технических средств, обнаружение и локализация отказов функционирования, принятие мер по восстановлению отказавших средств и их тестирование
Стандарт № GMP Annex 11: Computerised Systems (RU) от 30.11.2011 "Правила надлежащей производственной практики. Приложение 11: Компьютеризированные системы":
Р. 4 п. 13 п.п. 1
Все инциденты (непредвиденные случаи), включая системные сбои и ошибки данных, должны быть записаны и оценены. Следует установить основную причину критических сбоев и использовать эту информацию в качестве основы корректирующих и предупреждающих действий. 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 10.7.3
10.7.3
Определенные Требования к Подходу:
На сбои любых критически важных систем контроля безопасности оперативно реагируют, включая, но не ограничиваясь этим::
  • Восстановление функций безопасности.
  • Определение и документирование продолжительности (даты и времени от начала до конца) сбоя системы безопасности.
  • Выявление и документирование причины (причин) сбоя и документирование необходимых исправлений.
  • Выявление и устранение любых проблем безопасности, возникших во время сбоя.
  • Определение того, требуются ли дальнейшие действия в результате сбоя системы безопасности.
  • Внедрение средств контроля для предотвращения повторного возникновения причины сбоя.
  • Возобновление мониторинга средств контроля безопасности.
Цель Индивидуального подхода:
Сбои в критически важных системах контроля безопасности анализируются, локализуются и устраняются, а средства контроля безопасности восстанавливаются для минимизации последствий. Возникающие в результате проблемы безопасности устраняются, и принимаются меры для предотвращения повторения.

Примечания по применению:
Это требование применяется только в том случае, если оцениваемая организация является поставщиком услуг до 31 марта 2025 года, после чего это требование будет применяться ко всем организациям.
Это действующее требование версии v3.2.1, которое применяется только к поставщикам услуг. Однако это требование является наилучшей практикой для всех других организаций до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:
  • 10.7.3.a Изучите документацию и опросите персонал, чтобы убедиться, что процессы определены и внедрены для реагирования на сбой любой критической системы контроля безопасности и включают, по крайней мере, все элементы, указанные в этом требовании.
  • 10.7.3.b Изучите записи, чтобы убедиться, что сбои критически важных систем контроля безопасности задокументированы, чтобы включить:
    • Определение причины (причин) сбоя.
    • Продолжительность (дата и время начала и окончания) сбоя системы безопасности.
    • Подробная информация о мерах по устранению неполадок, необходимых для устранения основной причины.
Цель:
Если на предупреждения о сбоях критически важных систем контроля безопасности не реагируют быстро и эффективно, злоумышленники могут использовать это время для внедрения вредоносного программного обеспечения, получения контроля над системой или кражи данных из среды организации.

Надлежащая практика:
Документированные доказательства (например, записи в системе управления проблемами) должны подтверждать наличие процессов и процедур для реагирования на сбои в системе безопасности. Кроме того, персонал должен быть осведомлен о своих обязанностях в случае сбоя. Действия и реакции на сбой должны быть отражены в документированных доказательствах.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
ОДТ.1 ОДТ.1 Использование отказоустойчивых технических средств
ОДТ.3 ОДТ.3 Контроль безотказного функционирования технических средств, обнаружение и локализация отказов функционирования, принятие мер по восстановлению отказавших средств и их тестирование
ЗИС.22 ЗИС.22 Защита информационной системы от угроз безопасности информации, направленных на отказ в обслуживании информационной системы
ЗИС.29 ЗИС.29 Перевод информационной системы или ее устройств (компонентов) в заранее определенную конфигурацию, обеспечивающую защиту информации, в случае возникновении отказов (сбоев) в системе защиты информации информационной системы
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ОДТ.1 ОДТ.1 Использование отказоустойчивых технических средств
ОДТ.3 ОДТ.3 Контроль безотказного функционирования средств и систем
ЗИС.37 ЗИС.37 Перевод информационной (автоматизированной) системы в безопасное состояние при возникновении отказов (сбоев)
NIST Cybersecurity Framework (EN):
RC.RP-1 RC.RP-1: Recovery plan is executed during or after a cybersecurity incident
PR.IP-10 PR.IP-10: Response and recovery plans are tested
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ОДТ.1 ОДТ.1 Использование отказоустойчивых технических средств
ОДТ.3
ОДТ.3 Контроль безотказного функционирования средств и систем
ЗИС.37 ЗИС.37 Перевод информационной (автоматизированной) системы в безопасное состояние при возникновении отказов (сбоев)

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

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