Куда я попал?
Приказ ФСТЭК России № 21 от 18.02.2013
Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных
РСБ.3
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
РСБ.3 Сбор, запись и хранение информации о событиях безопасности в течение установленного времени храненияОбязательно для уровня защищенности УЗ1 УЗ2 УЗ3 УЗ4
Похожие требования
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 8. Требования к организации и управлению защитой информации":
КЗИ.12
КЗИ.12 Регистрация сбоев (отказов) технических мер защиты информации
3-Н 2-Т 1-Т
3-Н 2-Т 1-Т
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
РД.42
РД.42 Регистрация запуска программных сервисов, осуществляющих логический доступ
3-Н 2-Т 1-Т
3-Н 2-Т 1-Т
РД.40
РД.40 Регистрация осуществления субъектами логического доступа идентификации и аутентификации
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
УЗП.26
УЗП.26 Регистрация событий защиты информации, связанных с действиями, и контроль действий эксплуатационного персонала, обладающего правами по управлению техническими мерами, реализующими многофакторную аутентификацию
3-Н 2-Т 1-Т
3-Н 2-Т 1-Т
УЗП.28
УЗП.28 Регистрация событий защиты информации, связанных с действиями, и контроль действий эксплуатационного персонала, обладающего правами по управлению криптографическими ключами
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
7.2.3.4
Базовый состав мер по регистрации событий, связанных с физическим доступом
УЗП.24
УЗП.24 Регистрация событий защиты информации, связанных с действиями, и контроль действий эксплуатационного персонала, обладающего правами по управлению логическим доступом
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
РИ.14
РИ.14 Установление и применение единых правил закрытия инцидентов защиты информации
3-О 2-О 1-О
3-О 2-О 1-О
ФД.14
ФД.14 Хранение архивов информации средств (систем) контроля и управления доступом не менее трех лет
3-Н 2-Н 1-Т
3-Н 2-Н 1-Т
РД.44
РД.44 Регистрация действий пользователей и эксплуатационного персонала, предусмотренных в случае компрометации их аутентификационных данных
3-Н 2-О 1-О
3-Н 2-О 1-О
УЗП.27
УЗП.27 Регистрация событий защиты информации, связанных с действиями, и контроль действий эксплуатационного персонала, обладающего правами по изменению параметров настроек средств и систем защиты информации, параметров настроек АС, связанных с защитой информации
3-Н 2-Т 1-Т
3-Н 2-Т 1-Т
РИ.1
РИ.1 Регистрация информации о событиях защиты информации, потенциально связанных с инцидентами защиты информации, в том числе НСД, выявленными в рамках мониторинга и анализа событий защиты информации
3-О 2-Т 1-Т
3-О 2-Т 1-Т
РД.43
РД.43 Регистрация изменений аутентификационных данных, используемых для осуществления логического доступа
3-Н 2-Т 1-Т
3-Н 2-Т 1-Т
УЗП.25
УЗП.25 Регистрация событий защиты информации, связанных с действиями по управлению учетными записями и правами субъектов логического доступа
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
РД.39
РД.39 Регистрация выполнения субъектами логического доступа ряда неуспешных последовательных попыток аутентификации
3-Н 2-Т 1-Т
3-Н 2-Т 1-Т
РД.41
РД.41 Регистрация авторизации, завершения и (или) прерывания (приостановки) осуществления эксплуатационным персоналом и пользователями логического доступа, в том числе в АС
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
УЗП.22
УЗП.22 Регистрация событий защиты информации, связанных с действиями, и контроль действий эксплуатационного персонала, обладающего привилегированными правами логического доступа, позволяющими осуществить деструктивное воздействие, приводящие к нарушению выполнения бизнес-процессов или технологических процессов финансовой организации
3-Н 2-Т 1-Т
3-Н 2-Т 1-Т
РИ.2
РИ.2 Регистрация информации, потенциально связанной с инцидентами защиты информации, в том числе НСД, полученной от работников, клиентов и (или) контрагентов финансовой организации
3-О 2-Т 1-Т
3-О 2-Т 1-Т
УЗП.23
УЗП.23 Регистрация событий защиты информации, связанных с действиями, и контроль действий эксплуатационного персонала и пользователей, обладающих правами логического доступа, в том числе в АС, позволяющими осуществить операции (транзакции), приводящие к финансовым последствиям для финансовой организации, клиентов и контрагентов
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
NIST Cybersecurity Framework (RU):
PR.PT-1
PR.PT-1: В соответствии с политикой определяются, документируются, внедряются и проверяются записи аудита / журналов событий
DE.AE-3
DE.AE-3: Данные о событиях агрегируются и коррелируются из нескольких источников и сенсоров
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
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:
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
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.1
10.2.1.1
Defined Approach Requirements:
Audit logs capture all individual user access to cardholder data.
Customized Approach Objective:
Records of all individual user access to cardholder data are captured.
Defined Approach Testing Procedures:
Defined Approach Requirements:
Audit logs capture all individual user access to cardholder data.
Customized Approach Objective:
Records of all individual user access to cardholder data are captured.
Defined Approach Testing Procedures:
- 10.2.1.1 Examine audit log configurations and log data to verify that all individual user access to cardholder data is logged.
Purpose:
It is critical to have a process or system that links user access to system components accessed. Malicious individuals could obtain knowledge of a user account with access to systems in the CDE, or they could create a new, unauthorized account to access cardholder data.
Good Practice:
A record of all individual access to cardholder data can identify which accounts may have been compromised or misused.
It is critical to have a process or system that links user access to system components accessed. Malicious individuals could obtain knowledge of a user account with access to systems in the CDE, or they could create a new, unauthorized account to access cardholder data.
Good Practice:
A record of all individual access to cardholder data can identify which accounts may have been compromised or misused.
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:
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.
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.
Guideline for a healthy information system v.2.0 (EN):
36 STANDARD
/STANDARD
Having relevant logs is required in order to be able to detect possible malfunctions and illegal access attempts to the components of the information system.
The first stage consists of determining what the critical components of the information system are. These may be network and security devices, critical servers, sensitive user workstations, etc.
For each of these, it is advisable to analyse the configuration of logged elements (format, frequency of file rotation, maximum size of log files, event categories recorded, etc.) and to adapt it as a consequence. The critical events for security must be logged and saved for at least one year (or more, depending on the legal requirements of the business area).
A contextual assessment of the information system must be carried out and the following elements must be logged:
Having relevant logs is required in order to be able to detect possible malfunctions and illegal access attempts to the components of the information system.
The first stage consists of determining what the critical components of the information system are. These may be network and security devices, critical servers, sensitive user workstations, etc.
For each of these, it is advisable to analyse the configuration of logged elements (format, frequency of file rotation, maximum size of log files, event categories recorded, etc.) and to adapt it as a consequence. The critical events for security must be logged and saved for at least one year (or more, depending on the legal requirements of the business area).
A contextual assessment of the information system must be carried out and the following elements must be logged:
- firewall: packets blocked;
- systems and applications: authentications and authorisations (failures and successes), unplanned downtime;
- services: protocol errors (for example the errors 403, 404 and 500 for HTTP services), traceability of flows applicable to interconnections (URL on a HTTP relay, headers of messages on a SMTP relay, etc).
In order to be able to correlate the events between the different components, their time synchronisation source (thanks to NTP protocol) must be identical.
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 7.6
CSC 7.6 Log All URL requester
Log all URL requests from each of the organization's systems, whether on-site or a mobile device, in order to identify potentially malicious activity and assist incident handlers with identifying potentially compromised systems.
Log all URL requests from each of the organization's systems, whether on-site or a mobile device, in order to identify potentially malicious activity and assist incident handlers with identifying potentially compromised systems.
CSC 16.13
CSC 16.13 Alert on Account Login Behavior Deviation
Alert when users deviate from normal login behavior, such as time-of-day, workstation location, and duration.
Alert when users deviate from normal login behavior, such as time-of-day, workstation location, and duration.
CSC 8.8
CSC 8.8 Enable Command-Line Audit Logging
Enable command-line audit logging for command shells, such as Microsoft PowerShell and Bash.
Enable command-line audit logging for command shells, such as Microsoft PowerShell and Bash.
CSC 6.3
CSC 6.3 Enable Detailed Logging
Enable system logging to include detailed information such as a event source, date, user, timestamp, source addresses, destination addresses, and other useful elements.
Enable system logging to include detailed information such as a event source, date, user, timestamp, source addresses, destination addresses, and other useful elements.
CSC 8.6
CSC 8.6 Centralize Anti-Malware Logging
Send all malware detection events to enterprise anti-malware administration tools and event log servers for analysis and alerting.
Send all malware detection events to enterprise anti-malware administration tools and event log servers for analysis and alerting.
CSC 8.7
CSC 8.7 Enable DNS Query Logging
Enable Domain Name System (DNS) query logging to detect hostname lookups for known malicious domains.
Enable Domain Name System (DNS) query logging to detect hostname lookups for known malicious domains.
CSC 6.4
CSC 6.4 Ensure Adequate Storage for Logs
Ensure that all systems that store logs have adequate storage space for the logs generated.
Ensure that all systems that store logs have adequate storage space for the logs generated.
CSC 14.9
CSC 14.9 Enforce Detail Logging for Access or Changes to Sensitive Data
Enforce detailed audit logging for access to sensitive data or changes to sensitive data (utilizing tools such as File Integrity Monitoring or Security Information and Event Monitoring).
Enforce detailed audit logging for access to sensitive data or changes to sensitive data (utilizing tools such as File Integrity Monitoring or Security Information and Event Monitoring).
CSC 6.2
CSC 6.2 Activate Audit Logging
Ensure that local logging has been enabled on all systems and networking devices.
Ensure that local logging has been enabled on all systems and networking devices.
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), а также обеспечивают отслеживание истории для расследования после инцидента.
Ведение журнала и анализ событий, связанных с безопасностью, позволяют организации выявлять и отслеживать потенциально вредоносные действия.
Надлежащая практика:
Когда организация решает, какую информацию записывать в свои журналы, важно помнить, что информация, хранящаяся в журналах аудита, является конфиденциальной и должна быть защищена в соответствии с требованиями настоящего стандарта. Следует позаботиться о том, чтобы в журналах аудита сохранялась только важная информация, чтобы свести к минимуму риск.
Журналы аудита должны существовать для всех компонентов системы. Журналы аудита отправляют предупреждения системному администратору, предоставляют данные другим механизмам мониторинга, таким как системы обнаружения вторжений (IDS) и средства защиты информации и систем мониторинга событий (SIEM), а также обеспечивают отслеживание истории для расследования после инцидента.
Ведение журнала и анализ событий, связанных с безопасностью, позволяют организации выявлять и отслеживать потенциально вредоносные действия.
Надлежащая практика:
Когда организация решает, какую информацию записывать в свои журналы, важно помнить, что информация, хранящаяся в журналах аудита, является конфиденциальной и должна быть защищена в соответствии с требованиями настоящего стандарта. Следует позаботиться о том, чтобы в журналах аудита сохранялась только важная информация, чтобы свести к минимуму риск.
Requirement 10.2.1.2
10.2.1.2
Определенные Требования к Подходу:
Журналы аудита фиксируют все действия, предпринятые любым лицом с административным доступом, включая любое интерактивное использование учетных записей приложений или системы.
Цель Индивидуального подхода:
Фиксируются записи всех действий, выполняемых лицами с повышенными привилегиями.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Журналы аудита фиксируют все действия, предпринятые любым лицом с административным доступом, включая любое интерактивное использование учетных записей приложений или системы.
Цель Индивидуального подхода:
Фиксируются записи всех действий, выполняемых лицами с повышенными привилегиями.
Определенные Процедуры Тестирования Подхода:
- 10.2.1.2 Изучите конфигурации журнала аудита и данные журнала, чтобы убедиться, что все действия, предпринятые любым лицом с административным доступом, включая любое интерактивное использование учетных записей приложений или системы, регистрируются.
Цель:
Учетные записи с повышенными правами доступа, такие как учетная запись “администратор” или “суперпользователь”, потенциально могут существенно повлиять на безопасность или функциональность системы. Без журнала выполненных действий организация не может отследить любые проблемы, возникшие в результате административной ошибки или неправильного использования привилегий, вплоть до конкретного действия и учетной записи.
Определения:
Учетные записи с административным доступом - это учетные записи, которым назначены определенные привилегии или возможности для этой учетной записи для управления системами, сетями и/или приложениями. Функции или действия, которые считаются административными, выходят за рамки тех, которые выполняются обычными пользователями в рамках обычных бизнес-функций
Учетные записи с повышенными правами доступа, такие как учетная запись “администратор” или “суперпользователь”, потенциально могут существенно повлиять на безопасность или функциональность системы. Без журнала выполненных действий организация не может отследить любые проблемы, возникшие в результате административной ошибки или неправильного использования привилегий, вплоть до конкретного действия и учетной записи.
Определения:
Учетные записи с административным доступом - это учетные записи, которым назначены определенные привилегии или возможности для этой учетной записи для управления системами, сетями и/или приложениями. Функции или действия, которые считаются административными, выходят за рамки тех, которые выполняются обычными пользователями в рамках обычных бизнес-функций
Requirement 10.2.1.1
10.2.1.1
Определенные Требования к Подходу:
Журналы аудита фиксируют весь индивидуальный доступ пользователей к данным о держателях карт.
Цель Индивидуального подхода:
Фиксируются записи обо всех индивидуальных пользовательских доступах к данным о держателях карт.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Журналы аудита фиксируют весь индивидуальный доступ пользователей к данным о держателях карт.
Цель Индивидуального подхода:
Фиксируются записи обо всех индивидуальных пользовательских доступах к данным о держателях карт.
Определенные Процедуры Тестирования Подхода:
- 10.2.1.1 Проверьте конфигурации журнала аудита и данные журнала, чтобы убедиться, что весь индивидуальный доступ пользователя к данным о держателях карт регистрируется.
Цель:
Крайне важно иметь процесс или систему, которые связывают доступ пользователя с доступом к системным компонентам. Злоумышленники могут получить информацию об учетной записи пользователя, имеющей доступ к системам в CDE, или они могут создать новую несанкционированную учетную запись для доступа к данным о держателях карт.
Надлежащая практика:
Запись всего индивидуального доступа к данным о держателях карт позволяет определить, какие учетные записи могли быть скомпрометированы или использованы не по назначению.
Крайне важно иметь процесс или систему, которые связывают доступ пользователя с доступом к системным компонентам. Злоумышленники могут получить информацию об учетной записи пользователя, имеющей доступ к системам в CDE, или они могут создать новую несанкционированную учетную запись для доступа к данным о держателях карт.
Надлежащая практика:
Запись всего индивидуального доступа к данным о держателях карт позволяет определить, какие учетные записи могли быть скомпрометированы или использованы не по назначению.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
РСБ.3
РСБ.3 Сбор, запись и хранение информации о событиях безопасности в течении установленного времени хранения
Strategies to Mitigate Cyber Security Incidents (EN):
3.3.
Endpoint detection and response software on all computers to centrally log system behaviour and facilitate incident response. Microsoft’s free SysMon tool is an entry level option.
Relative Security Effectiveness: Very Good | Potential User Resistance: Low | Upfront Cost: Medium | Ongoing Maintenance Cost: Medium
Relative Security Effectiveness: Very Good | Potential User Resistance: Low | Upfront Cost: Medium | Ongoing Maintenance Cost: Medium
Методика экспресс-оценки уровня кибербезопасности организации РезБез:
3.2.1.3.
Непрерывность сбора событий контролируется
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
Положение Банка России № 808-П от 17.10.2022 "О требованиях к обеспечению защиты информации при осуществлении деятельности в сфере оказания профессиональных услуг на финансовом рынке в целях противодействия осуществлению незаконных финансовых операций":
Глава 2 Пункт 10
2.10. Бюро кредитных историй должны:
- хранить защищаемую информацию, информацию о регистрации данных, указанных в пункте 2.7 настоящего Положения, и информацию об инцидентах защиты информации;
- обеспечивать целостность и доступность защищаемой информации, информации о регистрации данных, указанных в пункте 2.7 настоящего Положения, и информации об инцидентах защиты информации в течение пяти лет с даты ее формирования бюро кредитных историй (даты поступления в бюро кредитных историй), а в случае если законодательством Российской Федерации, регулирующим деятельность бюро кредитных историй, установлен иной срок - на срок, установленный законодательством Российской Федерации, регулирующим деятельность бюро кредитных историй.
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
АУД.4
АУД.4 Регистрация событий безопасности
NIST Cybersecurity Framework (EN):
DE.AE-3
DE.AE-3: Event data are collected and correlated from multiple sources and sensors
PR.PT-1
PR.PT-1: Audit/log records are determined, documented, implemented, and reviewed in accordance with policy
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
АУД.4
АУД.4 Регистрация событий безопасности
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.