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

Приказ ФСТЭК России № 239 от 25.12.2017

Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости

АУД.8

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

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

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

ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 8. Требования к организации и управлению защитой информации":
КЗИ.12
КЗИ.12 Регистрация сбоев (отказов) технических мер защиты информации
3-Н 2-Т 1-Т
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
МАС.21
МАС.21 Регистрация нарушений и сбоев в формировании и сборе данных о событиях защиты информации
3-Н 2-Т 1-Т
ЗВК.26
ЗВК.26 Регистрация сбоев в выполнении контроля (проверок) на отсутствие вредоносного кода
3-Т 2-Т 1-Т
ЗВК.25
ЗВК.25 Регистрация сбоев в функционировании средств защиты от вредоносного кода
3-Т 2-Т 1-Т
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
РСБ.4 РСБ.4 Реагирование на сбои при регистрации событий безопасности, в том числе аппаратные и программные ошибки, сбои в механизмах сбора информации и достижение предела или переполнения объема (емкости) памяти
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 10.4.3
10.4.3
Defined Approach Requirements: 
Exceptions and anomalies identified during the review process are addressed. 

Customized Approach Objective:
Suspicious or anomalous activities are addressed. 

Defined Approach Testing Procedures:
  • 10.4.3.a Examine security policies and procedures to verify that processes are defined for addressing exceptions and anomalies identified during the review process. 
  • 10.4.3.b Observe processes and interview personnel to verify that, when exceptions and anomalies are identified, they are addressed. 
Purpose:
If exceptions and anomalies identified during the log-review process are not investigated, the entity may be unaware of unauthorized and potentially malicious activities occurring within their network. 

Good Practice:
Entities should consider how to address the following when developing their processes for defining and managing exceptions and anomalies:
  • How log review activities are recorded, • How to rank and prioritize exceptions and anomalies,
  • What procedures should be in place to report and escalate exceptions and anomalies, and 
  • Who is responsible for investigating and for any remediation tasks. 
Requirement 10.7.2
10.7.2
Defined Approach Requirements: 
Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems:
  • Network security controls.
  • IDS/IPS.
  • Change-detection mechanisms.
  • Anti-malware solutions.
  • Physical access controls.
  • Logical access controls.
  • Audit logging mechanisms.
  • Segmentation controls (if used).
  • Audit log review mechanisms.
  • Automated security testing tools (if used). 
Customized Approach Objective:
Failures in critical security control systems are promptly identified and addressed. 

Applicability Notes:
This requirement applies to all entities, including service providers, and will supersede Requirement 10.7.1 as of 31 March 2025. It includes two additional critical security control systems not in Requirement 10.7.1. 
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:
  • 10.7.2.a Examine documentation to verify that processes are defined for the prompt detection and addressing of failures of critical security control systems, including but not limited to failure of all elements specified in this requirement. 
  • 10.7.2.b Observe detection and alerting processes and interview personnel to verify that failures of critical security control systems are detected and reported, and that failure of a critical security control results in the generation of an alert. 
Purpose:
Without formal processes to detect and alert when critical security controls fail, failures may go undetected for extended periods and provide attackers ample time to compromise system components and steal account data from the CDE. 

Good Practice:
The specific types of failures may vary, depending on the function of the device system component and technology in use. However, typical failures include a system no longer performing its security function or not functioning in its intended manner—for example, a firewall erasing its rules or going offline. 
Requirement 10.2.1.6
10.2.1.6
Defined Approach Requirements: 
Audit logs capture the following:
  • All initialization of new audit logs, and 
  • All starting, stopping, or pausing of the existing audit logs. 
Customized Approach Objective:
Records of all changes to audit log activity status are captured. 

Defined Approach Testing Procedures:
  • 10.2.1.6 Examine audit log configurations and log data to verify that all elements specified in this requirement are captured. 
Purpose:
Turning off or pausing audit logs before performing illicit activities is common practice for malicious users who want to avoid detection. Initialization of audit logs could indicate that that a user disabled the log function to hide their actions. 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.12.4.1
A.12.4.1 Регистрация событий 
Мера обеспечения информационной безопасности: Требуется обеспечивать формирование, ведение и регулярный анализ регистрационных журналов, фиксирующих действия пользователей, нештатные ситуации, ошибки и события информационной безопасности 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 10.2.1.6
10.2.1.6
Определенные Требования к Подходу:
Журналы аудита фиксируют следующее:
  • Все инициализации новых журналов аудита и
  • Все запуски, остановки или приостановки существующих журналов аудита.
Цель Индивидуального подхода:
Фиксируются записи всех изменений в статусе активности журнала аудита.

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

Цель Индивидуального подхода:
Рассматриваются подозрительные или аномальные действия.

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

Надлежащая практика:
Организациям следует рассмотреть вопрос о том, как учитывать следующее при разработке своих процессов определения и управления исключениями и аномалиями:
  • Как записываются действия по проверке журнала, • Как ранжировать и расставлять приоритеты исключений и аномалий,
  • Какие процедуры должны быть предусмотрены для сообщения об исключениях и аномалиях и их эскалации, а также
  • Кто отвечает за расследование и за любые задачи по исправлению положения.
Requirement 10.7.2
10.7.2
Определенные Требования к Подходу:
Сбои критических систем контроля безопасности обнаруживаются, предупреждаются и оперативно устраняются, включая, но не ограничиваясь, отказ следующих критических систем контроля безопасности:
  • Средства управления сетевой безопасностью.
  • IDS/IPS.
  • Механизмы обнаружения изменений.
  • Решения для защиты от вредоносных программ.
  • Контроль физического доступа.
  • Логический контроль доступа.
  • Механизмы ведения журнала аудита.
  • Элементы управления сегментацией (если они используются).
  • Механизмы проверки журналов аудита.
  • Автоматизированные средства тестирования безопасности (если они используются).
Цель Индивидуального подхода:
Сбои в критически важных системах контроля безопасности оперативно выявляются и устраняются.

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

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

Надлежащая практика:
Конкретные типы отказов могут варьироваться в зависимости от функции системного компонента устройства и используемой технологии. Однако типичные сбои включают в себя то, что система больше не выполняет свою функцию безопасности или не функционирует должным образом — например, брандмауэр стирает свои правила или переходит в автономный режим.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
РСБ.4 РСБ.4 Реагирование на сбои при регистрации событий безопасности, в том числе аппаратные и программные ошибки, сбои в механизмах сбора информации и достижение предела или переполнения объема (емкости) памяти
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.15
А.8.15 Логирование
Должны создаваться, храниться, защищаться и анализироваться журналы, в которых фиксируются деятельность, исключения, сбои и другие релевантные события.
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
АУД.8 АУД.8 Реагирование на сбои при регистрации событий безопасности
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.8.15
А.8.15 Logging
Logs that record activities, exceptions, faults and other relevant events shall be produced, stored, protected and analysed.

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

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

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