Куда я попал?
Приказ ФСТЭК России № 239 от 25.12.2017
Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости
АУД.7
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
АУД.7 Мониторинг безопасностиОбязательно для категории значимости К1 К2 К3
Похожие требования
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
МАС.7
МАС.7 Организация мониторинга данных регистрации о событиях защиты информации, формируемых средствами (системами) контроля и управления доступом
3-Н 2-Н 1-Т
3-Н 2-Н 1-Т
МАС.6
МАС.6 Организация мониторинга данных регистрации о событиях защиты информации, формируемых контроллерами доменов
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
МАС.5
МАС.5 Организация мониторинга данных регистрации о событиях защиты информации, формируемых АС и приложениями
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
МАС.2
МАС.2 Организация мониторинга данных регистрации о событиях защиты информации, формируемых сетевым оборудованием, в том числе активным сетевым оборудованием, маршрутизаторами, коммутаторами
3-Н 2-Т 1-Т
3-Н 2-Т 1-Т
МАС.3
МАС.3 Организация мониторинга данных регистрации о событиях защиты информации, формируемых сетевыми приложениями и сервисами
3-Н 2-Т 1-Т
3-Н 2-Т 1-Т
РИ.1
РИ.1 Регистрация информации о событиях защиты информации, потенциально связанных с инцидентами защиты информации, в том числе НСД, выявленными в рамках мониторинга и анализа событий защиты информации
3-О 2-Т 1-Т
3-О 2-Т 1-Т
МАС.1
МАС.1 Организация мониторинга данных регистрации о событиях защиты информации, формируемых техническими мерами, входящими в состав системы защиты информации
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
МАС.4
МАС.4 Организация мониторинга данных регистрации о событиях защиты информации, формируемых системным ПО, операционными системами, СУБД
3-Н 2-Т 1-Т
3-Н 2-Т 1-Т
РИ.2
РИ.2 Регистрация информации, потенциально связанной с инцидентами защиты информации, в том числе НСД, полученной от работников, клиентов и (или) контрагентов финансовой организации
3-О 2-Т 1-Т
3-О 2-Т 1-Т
NIST Cybersecurity Framework (RU):
PR.PT-1
PR.PT-1: В соответствии с политикой определяются, документируются, внедряются и проверяются записи аудита / журналов событий
DE.AE-4
DE.AE-4: Определяется влияние событий
DE.AE-2
DE.AE-2: Обнаруженные события анализируются для определения целей и методов атаки
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
РСБ.5
РСБ.5 Мониторинг (просмотр, анализ) результатов регистрации событий безопасности и реагирование на них
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 10.4.2
10.4.2
Defined Approach Requirements:
Logs of all other system components (those not specified in Requirement 10.4.1) are reviewed periodically.
Customized Approach Objective:
Potentially suspicious or anomalous activities for other system components (not included in 10.4.1) are reviewed in accordance with the entity’s identified risk.
Applicability Notes:
This requirement is applicable to all other in-scope system components not included in Requirement 10.4.1.
Defined Approach Testing Procedures:
Defined Approach Requirements:
Logs of all other system components (those not specified in Requirement 10.4.1) are reviewed periodically.
Customized Approach Objective:
Potentially suspicious or anomalous activities for other system components (not included in 10.4.1) are reviewed in accordance with the entity’s identified risk.
Applicability Notes:
This requirement is applicable to all other in-scope system components not included in Requirement 10.4.1.
Defined Approach Testing Procedures:
- 10.4.2.a Examine security policies and procedures to verify that processes are defined for reviewing logs of all other system components periodically.
- 10.4.2.b Examine documented results of log reviews and interview personnel to verify that log reviews are performed periodically.
Purpose:
Periodic review of logs for all other system components (not specified in Requirement 10.4.1) helps to identify indications of potential issues or attempts to access critical systems via less-critical systems.
Periodic review of logs for all other system components (not specified in Requirement 10.4.1) helps to identify indications of potential issues or attempts to access critical systems via less-critical systems.
Requirement 10.4.1
10.4.1
Defined Approach Requirements:
The following audit logs are reviewed at least once daily:
Defined Approach Requirements:
The following audit logs are reviewed at least once daily:
- All security events.
- Logs of all system components that store, process, or transmit CHD and/or SAD.
- Logs of all critical system components.
- Logs of all servers and system components that perform security functions (for example, network security controls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers).
Customized Approach Objective:
Potentially suspicious or anomalous activities are quickly identified to minimize impact.
Defined Approach Testing Procedures:
Potentially suspicious or anomalous activities are quickly identified to minimize impact.
Defined Approach Testing Procedures:
- 10.4.1.a Examine security policies and procedures to verify that processes are defined for reviewing all elements specified in this requirement at least once daily.
- 10.4.1.b Observe processes and interview personnel to verify that all elements specified in this requirement are reviewed at least once daily
Purpose:
Many breaches occur months before being detected. Regular log reviews mean incidents can be quickly identified and proactively addressed.
Good Practice:
Checking logs daily (7 days a week, 365 days a year, including holidays) minimizes the amount of time and exposure of a potential breach. Log harvesting, parsing, and alerting tools, centralized log management systems, event log analyzers, and security information and event management (SIEM) solutions are examples of automated tools that can be used to meet this requirement.
Daily review of security events—for example, notifications or alerts that identify suspicious or anomalous activities—as well as logs from critical system components, and logs from systems that perform security functions, such as firewalls, IDS/IPS, file integrity monitoring (FIM) systems, etc., is necessary to identify potential issues.
The determination of “security event” will vary for each organization and may include consideration for the type of technology, location, and function of the device. Organizations may also wish to maintain a baseline of “normal” traffic to help identify anomalous behavior.
An entity that uses third-party service providers to perform log review services is responsible to provide context about the entity’s environment to the service providers, so it understands the entity’s environment, has a baseline of “normal” traffic for the entity, and can detect potential security issues and provide accurate exceptions and anomaly notifications.
Many breaches occur months before being detected. Regular log reviews mean incidents can be quickly identified and proactively addressed.
Good Practice:
Checking logs daily (7 days a week, 365 days a year, including holidays) minimizes the amount of time and exposure of a potential breach. Log harvesting, parsing, and alerting tools, centralized log management systems, event log analyzers, and security information and event management (SIEM) solutions are examples of automated tools that can be used to meet this requirement.
Daily review of security events—for example, notifications or alerts that identify suspicious or anomalous activities—as well as logs from critical system components, and logs from systems that perform security functions, such as firewalls, IDS/IPS, file integrity monitoring (FIM) systems, etc., is necessary to identify potential issues.
The determination of “security event” will vary for each organization and may include consideration for the type of technology, location, and function of the device. Organizations may also wish to maintain a baseline of “normal” traffic to help identify anomalous behavior.
An entity that uses third-party service providers to perform log review services is responsible to provide context about the entity’s environment to the service providers, so it understands the entity’s environment, has a baseline of “normal” traffic for the entity, and can detect potential security issues and provide accurate exceptions and anomaly notifications.
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 6.6
CSC 6.6 Deploy SIEM or Log Analytic Tools
Deploy Security Information and Event Management (SIEM) or log analytic tool for log correlation and analysis.
Deploy Security Information and Event Management (SIEM) or log analytic tool for log correlation and analysis.
CSC 6.7
CSC 6.7 Regularly Review Logs
On a regular basis, review logs to identify anomalies or abnormal events.
On a regular basis, review logs to identify anomalies or abnormal events.
Положение Банка России № 802-П от 25.07.2022 "О требованиях к защите информации в платежной системе Банка России":
П. 16.3
16.3. ОПКЦ СБП должен осуществлять:
- выявление операций, соответствующих признакам осуществления переводов денежных средств без согласия клиента, на основании моделей оценки риска операций по переводу денежных средств (далее - модели оценки риска операций Банка России), установленных в соответствии с договором о взаимодействии, заключаемым между Банком России и оператором внешней платежной системы в соответствии с частью 37 статьи 15 Федерального закона от 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 10.4.2
10.4.2
Определенные Требования к Подходу:
Журналы всех других компонентов системы (не указанных в требовании 10.4.1) периодически просматриваются.
Цель Индивидуального подхода:
Потенциально подозрительные или аномальные действия для других компонентов системы (не включенных в 10.4.1) рассматриваются в соответствии с выявленным риском организации.
Примечания по применению:
Это требование применимо ко всем другим компонентам системы, не включенным в Требование 10.4.1.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Журналы всех других компонентов системы (не указанных в требовании 10.4.1) периодически просматриваются.
Цель Индивидуального подхода:
Потенциально подозрительные или аномальные действия для других компонентов системы (не включенных в 10.4.1) рассматриваются в соответствии с выявленным риском организации.
Примечания по применению:
Это требование применимо ко всем другим компонентам системы, не включенным в Требование 10.4.1.
Определенные Процедуры Тестирования Подхода:
- 10.4.2.a Изучите политики и процедуры безопасности, чтобы убедиться, что определены процессы для периодического просмотра журналов всех других компонентов системы.
- 10.4.2.b Изучите документированные результаты проверок журналов и опросите персонал, чтобы убедиться, что проверки журналов выполняются периодически.
Цель:
Периодический просмотр журналов для всех других компонентов системы (не указанных в требовании 10.4.1) помогает выявить признаки потенциальных проблем или попыток доступа к критическим системам через менее критичные системы.
Периодический просмотр журналов для всех других компонентов системы (не указанных в требовании 10.4.1) помогает выявить признаки потенциальных проблем или попыток доступа к критическим системам через менее критичные системы.
Requirement 10.4.1
10.4.1
Определенные Требования к Подходу:
Следующие журналы аудита просматриваются не реже одного раза в день:
Определенные Требования к Подходу:
Следующие журналы аудита просматриваются не реже одного раза в день:
- Все мероприятия по обеспечению безопасности.
- Журналы всех системных компонентов, которые хранят, обрабатывают или передают CHD и/или SAD.
- Журналы всех критически важных компонентов системы.
- Журналы всех серверов и системных компонентов, выполняющих функции безопасности (например, средства управления сетевой безопасностью, системы обнаружения вторжений/системы предотвращения вторжений (IDS/IPS), серверы аутентификации).
Цель Индивидуального подхода:
Потенциально подозрительные или аномальные действия быстро выявляются, чтобы свести к минимуму воздействие.
Определенные Процедуры Тестирования Подхода:
Потенциально подозрительные или аномальные действия быстро выявляются, чтобы свести к минимуму воздействие.
Определенные Процедуры Тестирования Подхода:
- 10.4.1.a Изучайте политики и процедуры безопасности, чтобы убедиться, что определены процессы для проверки всех элементов, указанных в этом требовании, по крайней мере, один раз в день.
- 10.4.1.b Наблюдайте за процессами и проводите собеседования с персоналом, чтобы убедиться, что все элементы, указанные в этом требовании, проверяются не реже одного раза в день
Цель:
Многие нарушения происходят за месяцы до их обнаружения. Регулярные проверки журналов позволяют быстро выявлять инциденты и оперативно устранять их.
Надлежащая практика:
Ежедневная проверка журналов (7 дней в неделю, 365 дней в году, включая праздничные дни) сводит к минимуму количество времени и вероятность потенциального нарушения. Средства сбора, анализа и оповещения журналов, централизованные системы управления журналами, анализаторы журналов событий и решения для управления информацией о безопасности и событиями (SIEM) являются примерами автоматизированных инструментов, которые можно использовать для удовлетворения этого требования.
Ежедневный просмотр событий безопасности — например, уведомлений или предупреждений, которые идентифицируют подозрительные или аномальные действия, — а также журналов критически важных системных компонентов и журналов систем, выполняющих функции безопасности, таких как брандмауэры, идентификаторы/IP-адреса, системы мониторинга целостности файлов (FIM) и т.д., необходим для выявления потенциальные проблемы.
Определение “события безопасности” будет отличаться для каждой организации и может включать в себя рассмотрение типа технологии, местоположения и функции устройства. Организации могут также пожелать поддерживать базовый уровень “нормального” трафика, чтобы помочь выявить аномальное поведение.
Объект, который использует сторонних поставщиков услуг для выполнения служб просмотра журналов, отвечает за предоставление поставщикам услуг контекста среды объекта, чтобы он понимал среду объекта, имел базовый уровень “нормального” трафика для объекта и мог обнаруживать потенциальные проблемы безопасности и предоставлять точные исключения и уведомления об аномалиях.
Многие нарушения происходят за месяцы до их обнаружения. Регулярные проверки журналов позволяют быстро выявлять инциденты и оперативно устранять их.
Надлежащая практика:
Ежедневная проверка журналов (7 дней в неделю, 365 дней в году, включая праздничные дни) сводит к минимуму количество времени и вероятность потенциального нарушения. Средства сбора, анализа и оповещения журналов, централизованные системы управления журналами, анализаторы журналов событий и решения для управления информацией о безопасности и событиями (SIEM) являются примерами автоматизированных инструментов, которые можно использовать для удовлетворения этого требования.
Ежедневный просмотр событий безопасности — например, уведомлений или предупреждений, которые идентифицируют подозрительные или аномальные действия, — а также журналов критически важных системных компонентов и журналов систем, выполняющих функции безопасности, таких как брандмауэры, идентификаторы/IP-адреса, системы мониторинга целостности файлов (FIM) и т.д., необходим для выявления потенциальные проблемы.
Определение “события безопасности” будет отличаться для каждой организации и может включать в себя рассмотрение типа технологии, местоположения и функции устройства. Организации могут также пожелать поддерживать базовый уровень “нормального” трафика, чтобы помочь выявить аномальное поведение.
Объект, который использует сторонних поставщиков услуг для выполнения служб просмотра журналов, отвечает за предоставление поставщикам услуг контекста среды объекта, чтобы он понимал среду объекта, имел базовый уровень “нормального” трафика для объекта и мог обнаруживать потенциальные проблемы безопасности и предоставлять точные исключения и уведомления об аномалиях.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
РСБ.5
РСБ.5 Мониторинг (просмотр, анализ) результатов регистрации событий безопасности и реагирование на них
SWIFT Customer Security Controls Framework v2022:
6 - 6.4 Logging and Monitoring
6.4 Logging and Monitoring
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
АУД.7
АУД.7 Мониторинг безопасности
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.