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

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

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

УЗП.25

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

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

Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
РСБ.3 РСБ.3 Сбор, запись и хранение информации о событиях безопасности в течение установленного времени хранения
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 10.2.1.4
10.2.1.4
Defined Approach Requirements: 
Audit logs capture all invalid logical access attempts. 

Customized Approach Objective:
Records of all invalid access attempts are captured 

Defined Approach Testing Procedures:
  • 10.2.1.4 Examine audit log configurations and log data to verify that invalid logical access attempts are captured. 
Purpose:
Malicious individuals will often perform multiple access attempts on targeted systems. Multiple invalid login attempts may be an indication of an unauthorized user’s attempts to “brute force” or guess a password. 
Requirement 10.2.1.2
10.2.1.2
Defined Approach Requirements: 
Audit logs capture all actions taken by any individual with administrative access, including any interactive use of application or system accounts. 

Customized Approach Objective:
Records of all actions performed by individuals with elevated privileges are captured. 

Defined Approach Testing Procedures:
  • 10.2.1.2 Examine audit log configurations and log data to verify that all actions taken by any individual with administrative access, including any interactive use of application or system accounts, are logged. 
Purpose:
Accounts with increased access privileges, such as the “administrator” or “root” account, have the potential to significantly impact the security or operational functionality of a system. Without a log of the activities performed, an organization is cannot trace any issues resulting from an administrative mistake or misuse of privilege back to the specific action and account. 

Definitions:
Accounts with administrative access are those assigned with specific privileges or abilities for that account to manage systems, networks, and/or applications. The functions or activities considered to be administrative are beyond those performed by regular users as part of routine business functions 
Requirement 10.2.1.5
10.2.1.5
Defined Approach Requirements: 
Audit logs capture all changes to identification and authentication credentials including, but not limited to:
  • Creation of new accounts.
  • Elevation of privileges. 
  • All changes, additions, or deletions to accounts with administrative access. 
Customized Approach Objective:
Records of all changes to identification and authentication credentials are captured. 

Defined Approach Testing Procedures:
  • 10.2.1.5 Examine audit log configurations and log data to verify that changes to identification and authentication credentials are captured in accordance with all elements specified in this requirement. 
Purpose:
Logging changes to authentication credentials (including elevation of privileges, additions, and deletions of accounts with administrative access) provides residual evidence of activities. 
Malicious users may attempt to manipulate authentication credentials to bypass them or impersonate a valid account. 
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.
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.2.1.2
10.2.1.2
Определенные Требования к Подходу:
Журналы аудита фиксируют все действия, предпринятые любым лицом с административным доступом, включая любое интерактивное использование учетных записей приложений или системы.

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

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

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

Определенные Процедуры Тестирования Подхода:
  • 10.2.1.5 Проверьте конфигурации журнала аудита и данные журнала, чтобы убедиться, что изменения в учетных данных идентификации и аутентификации фиксируются в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Регистрация изменений учетных данных для проверки подлинности (включая повышение привилегий, добавления и удаления учетных записей с административным доступом) предоставляет остаточные свидетельства действий.
Злоумышленники могут попытаться манипулировать учетными данными для проверки подлинности, чтобы обойти их или выдать себя за действительную учетную запись.
Requirement 10.2.1.4
10.2.1.4
Определенные Требования к Подходу:
Журналы аудита фиксируют все недопустимые попытки логического доступа.

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

Определенные Процедуры Тестирования Подхода:
  • 10.2.1.4 Проверьте конфигурации журнала аудита и данные журнала, чтобы убедиться, что зафиксированы недопустимые попытки логического доступа.
Цель:
Злоумышленники часто совершают многократные попытки доступа к целевым системам. Множественные неудачные попытки входа в систему могут указывать на попытки неавторизованного пользователя “перебрать” или угадать пароль.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
РСБ.3 РСБ.3 Сбор, запись и хранение информации о событиях безопасности в течении установленного времени хранения
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
АУД.4 АУД.4 Регистрация событий безопасности
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
АУД.4 АУД.4 Регистрация событий безопасности

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

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