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

ГОСТ Р № 57580.1-2017 от 01.01.2018

Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации

МАС.6

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

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

ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
MAC.8
MAC.8 Централизованный сбор данных регистрации о событиях защиты информации, формируемых объектами информатизации, определенных мерами МАС.1-MAC.7
3-Н 2-Т 1-Т
MAC.10
MAC.10 Контроль формирования данных регистрации о событиях защиты информации объектов информатизации, определенных мерами МАС.1- МAC.7
3-О 2-Т 1-Т
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
РСБ.5 РСБ.5 Мониторинг (просмотр, анализ) результатов регистрации событий безопасности и реагирование на них
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
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. 
Requirement 10.2.1
10.2.1
Defined Approach Requirements: 
Audit logs are enabled and active for all system components and cardholder data. 

Customized Approach Objective:
Records of all activities affecting system components and cardholder data are captured. 

Defined Approach Testing Procedures:
  • 10.2.1 Interview the system administrator and examine system configurations to verify that audit logs are enabled and active for all system components. 
Purpose:
Audit logs must exist for all system components. Audit logs send alerts the system administrator, provides data to other monitoring mechanisms, such as intrusion-detection systems (IDS) and security information and event monitoring systems (SIEM) tools, and provide a history trail for post-incident investigation. 
Logging and analyzing security-relevant events enable an organization to identify and trace potentially malicious activities. 

Good Practice:
When an entity considers which information to record in their logs, it is important to remember that information stored in audit logs is sensitive and should be protected per requirements in this standard. Care should be taken to only store essential information in the audit logs to minimize risk.
ГОСТ Р № ИСО/МЭК 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
10.2.1
Определенные Требования к Подходу:
Журналы аудита включены и активны для всех компонентов системы и данных о держателях карт.

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

Определенные Процедуры Тестирования Подхода:
  • 10.2.1 Опросите системного администратора и изучите системные конфигурации, чтобы убедиться, что журналы аудита включены и активны для всех компонентов системы.
Цель:
Журналы аудита должны существовать для всех компонентов системы. Журналы аудита отправляют предупреждения системному администратору, предоставляют данные другим механизмам мониторинга, таким как системы обнаружения вторжений (IDS) и средства защиты информации и систем мониторинга событий (SIEM), а также обеспечивают отслеживание истории для расследования после инцидента.
Ведение журнала и анализ событий, связанных с безопасностью, позволяют организации выявлять и отслеживать потенциально вредоносные действия.

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

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

Надлежащая практика:
Ежедневная проверка журналов (7 дней в неделю, 365 дней в году, включая праздничные дни) сводит к минимуму количество времени и вероятность потенциального нарушения. Средства сбора, анализа и оповещения журналов, централизованные системы управления журналами, анализаторы журналов событий и решения для управления информацией о безопасности и событиями (SIEM) являются примерами автоматизированных инструментов, которые можно использовать для удовлетворения этого требования.
Ежедневный просмотр событий безопасности — например, уведомлений или предупреждений, которые идентифицируют подозрительные или аномальные действия, — а также журналов критически важных системных компонентов и журналов систем, выполняющих функции безопасности, таких как брандмауэры, идентификаторы/IP-адреса, системы мониторинга целостности файлов (FIM) и т.д., необходим для выявления потенциальные проблемы.
Определение “события безопасности” будет отличаться для каждой организации и может включать в себя рассмотрение типа технологии, местоположения и функции устройства. Организации могут также пожелать поддерживать базовый уровень “нормального” трафика, чтобы помочь выявить аномальное поведение.
Объект, который использует сторонних поставщиков услуг для выполнения служб просмотра журналов, отвечает за предоставление поставщикам услуг контекста среды объекта, чтобы он понимал среду объекта, имел базовый уровень “нормального” трафика для объекта и мог обнаруживать потенциальные проблемы безопасности и предоставлять точные исключения и уведомления об аномалиях.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
РСБ.5 РСБ.5 Мониторинг (просмотр, анализ) результатов регистрации событий безопасности и реагирование на них
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.15
А.8.15 Логирование
Должны создаваться, храниться, защищаться и анализироваться журналы, в которых фиксируются деятельность, исключения, сбои и другие релевантные события.
Методика экспресс-оценки уровня кибербезопасности организации РезБез:
3.2.2.
Определена область мониторинга  событий ИБ (перечень источников событий ИБ, перечень собираемых событий и параметров регистрации) с учетом результатов анализа рисков, связанных с КБ
SWIFT Customer Security Controls Framework v2022:
6 - 6.4 Logging and Monitoring
6.4 Logging and Monitoring
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
АУД.7 АУД.7 Мониторинг безопасности
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
АУД.7 АУД.7 Мониторинг безопасности
Стандарт № 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.

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

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