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

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

Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах

РСБ.5

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

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

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

ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
МАС.7
МАС.7 Организация мониторинга данных регистрации о событиях защиты информации, формируемых средствами (системами) контроля и управления доступом
3-Н 2-Н 1-Т
МАС.6
МАС.6 Организация мониторинга данных регистрации о событиях защиты информации, формируемых контроллерами доменов
3-Т 2-Т 1-Т
МАС.5
МАС.5 Организация мониторинга данных регистрации о событиях защиты информации, формируемых АС и приложениями
3-Т 2-Т 1-Т
МАС.2
МАС.2 Организация мониторинга данных регистрации о событиях защиты информации, формируемых сетевым оборудованием, в том числе активным сетевым оборудованием, маршрутизаторами, коммутаторами
3-Н 2-Т 1-Т
МАС.3
МАС.3 Организация мониторинга данных регистрации о событиях защиты информации, формируемых сетевыми приложениями и сервисами
3-Н 2-Т 1-Т
МАС.1
МАС.1 Организация мониторинга данных регистрации о событиях защиты информации, формируемых техническими мерами, входящими в состав системы защиты информации
3-Т 2-Т 1-Т
МАС.4
МАС.4 Организация мониторинга данных регистрации о событиях защиты информации, формируемых системным ПО, операционными системами, СУБД
3-Н 2-Т 1-Т
NIST Cybersecurity Framework (RU):
RS.AN-1
RS.AN-1: Исследуются уведомления от систем обнаружения 
PR.PT-1
PR.PT-1: В соответствии с политикой определяются, документируются, внедряются и проверяются записи аудита / журналов событий 
RS.MI-1
RS.MI-1: Инциденты локализируются 
RS.MI-2
RS.MI-2: Смягчаются последствия от инцидента 
RS.RP-1
RS.RP-1: Во время или после события выполняется план реагирования 
DE.AE-4
DE.AE-4: Определяется влияние событий  
DE.AE-2
DE.AE-2: Обнаруженные события анализируются для определения целей и методов атаки 
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
РСБ.5 РСБ.5 Мониторинг (просмотр, анализ) результатов регистрации событий безопасности и реагирование на них
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
ВРВ.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.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:
  • 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. 
Requirement 10.4.1
10.4.1
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:
  • 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. 
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.
CSC 6.7 CSC 6.7 Regularly Review Logs
On a regular basis, review logs to identify anomalies or abnormal events.
Положение Банка России № 802-П от 25.07.2022 "О требованиях к защите информации в платежной системе Банка России":
П. 16.1
16.1. Участник СБП - банк плательщика должен осуществлять:
  • выявление операций, соответствующих признакам осуществления переводов денежных средств без согласия клиента, установленным Банком России в соответствии с частью 5.1 статьи 8 Федерального закона от 27 июня 2011 года N 161-ФЗ (далее - признаки осуществления переводов денежных средств без согласия клиента), в рамках реализуемой им системы управления рисками при осуществлении переводов денежных средств с использованием сервиса быстрых платежей;
  • приостановление в соответствии с частью 5.1 статьи 8 Федерального закона от 27 июня 2011 года N 161-ФЗ исполнения распоряжения в рамках выявленной операции, соответствующей признакам осуществления переводов денежных средств без согласия клиента, с учетом информации об уровне риска операции без согласия клиента (далее - индикатор уровня риска операции), включенной в электронное сообщение, полученной от ОПКЦ СБП в формате и порядке, установленных договором об оказании услуг между участником СБП и ОПКЦ СБП, содержащей в том числе информацию об индикаторе уровня риска операции, сформированном участником СБП - банком получателя;
  • формирование индикатора уровня риска операции на основе оценки рисков операций в рамках реализуемой участником СБП - банком плательщика системы управления рисками и его направление в электронном сообщении в ОПКЦ СБП в формате и порядке, установленных договором об оказании услуг между участником СБП и ОПКЦ СБП, - в случае невыявления признаков осуществления перевода денежных средств без согласия клиента.
П. 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.2.a Изучите политики и процедуры безопасности, чтобы убедиться, что определены процессы для периодического просмотра журналов всех других компонентов системы.
  • 10.4.2.b Изучите документированные результаты проверок журналов и опросите персонал, чтобы убедиться, что проверки журналов выполняются периодически.
Цель:
Периодический просмотр журналов для всех других компонентов системы (не указанных в требовании 10.4.1) помогает выявить признаки потенциальных проблем или попыток доступа к критическим системам через менее критичные системы.
Requirement 10.4.3
10.4.3
Определенные Требования к Подходу:
Исключения и аномалии, выявленные в ходе процесса проверки, устраняются.

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

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

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

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

Надлежащая практика:
Ежедневная проверка журналов (7 дней в неделю, 365 дней в году, включая праздничные дни) сводит к минимуму количество времени и вероятность потенциального нарушения. Средства сбора, анализа и оповещения журналов, централизованные системы управления журналами, анализаторы журналов событий и решения для управления информацией о безопасности и событиями (SIEM) являются примерами автоматизированных инструментов, которые можно использовать для удовлетворения этого требования.
Ежедневный просмотр событий безопасности — например, уведомлений или предупреждений, которые идентифицируют подозрительные или аномальные действия, — а также журналов критически важных системных компонентов и журналов систем, выполняющих функции безопасности, таких как брандмауэры, идентификаторы/IP-адреса, системы мониторинга целостности файлов (FIM) и т.д., необходим для выявления потенциальные проблемы.
Определение “события безопасности” будет отличаться для каждой организации и может включать в себя рассмотрение типа технологии, местоположения и функции устройства. Организации могут также пожелать поддерживать базовый уровень “нормального” трафика, чтобы помочь выявить аномальное поведение.
Объект, который использует сторонних поставщиков услуг для выполнения служб просмотра журналов, отвечает за предоставление поставщикам услуг контекста среды объекта, чтобы он понимал среду объекта, имел базовый уровень “нормального” трафика для объекта и мог обнаруживать потенциальные проблемы безопасности и предоставлять точные исключения и уведомления об аномалиях.
Методика экспресс-оценки уровня кибербезопасности организации РезБез:
3.2.2.
Определена область мониторинга  событий ИБ (перечень источников событий ИБ, перечень собираемых событий и параметров регистрации) с учетом результатов анализа рисков, связанных с КБ
SWIFT Customer Security Controls Framework v2022:
6 - 6.4 Logging and Monitoring
6.4 Logging and Monitoring
6 - 6.5A Intrusion Detection
6.5A Intrusion Detection
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
АУД.7 АУД.7 Мониторинг безопасности
NIST Cybersecurity Framework (EN):
RS.MI-1 RS.MI-1: Incidents are contained
DE.AE-2 DE.AE-2: Detected events are analyzed to understand attack targets and methods
RS.MI-2 RS.MI-2: Incidents are mitigated
RS.RP-1 RS.RP-1: Response plan is executed during or after an incident
DE.AE-4 DE.AE-4: Impact of events is determined
PR.PT-1 PR.PT-1: Audit/log records are determined, documented, implemented, and reviewed in accordance with policy
RS.AN-1 RS.AN-1: Notifications from detection systems are investigated 
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
АУД.7 АУД.7 Мониторинг безопасности

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

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