Куда я попал?
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022
Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А
A.12.4.1
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 9. Требования к защите информации на этапах жизненного цикла автоматизированных систем и приложений":
ЖЦ.23
ЖЦ.23 Регистрация операций по изменению параметров настроек технических мер системы защиты информации АС
3-О 2-Т 1-Т
3-О 2-Т 1-Т
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 8. Требования к организации и управлению защитой информации":
КЗИ.12
КЗИ.12 Регистрация сбоев (отказов) технических мер защиты информации
3-Н 2-Т 1-Т
3-Н 2-Т 1-Т
Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 7 п. 4 п.п. 4
7.4.4. В организации БС РФ должны быть определены, выполняться, регистрироваться и контролироваться правила и процедуры мониторинга ИБ, анализа и хранения данных о действиях и операциях, позволяющие выявлять неправомерные или подозрительные операции и транзакции, для чего, среди прочего, следует:
- определить действия и операции, подлежащие регистрации;
- определить состав и содержание данных о действиях и операциях, подлежащих регистрации, сроки их хранения;
- обеспечить резервирование необходимого объема памяти для записи данных;
- обеспечить реагирование на сбои при регистрации действий и операций, в том числе аппаратные и программные ошибки, сбои в технических средствах сбора данных;
- обеспечить генерацию временных меток для регистрируемых действий и операций и синхронизацию системного времени на технических средствах, используемых для целей мониторинга ИБ, анализа и хранения данных.
В организации БС РФ должно быть реализовано ведение журналов действия и операций автоматизированных рабочих мест, серверного и сетевого оборудования, межсетевых экранов и АБС с целью их использования при реагировании на инциденты ИБ.
Рекомендуется обеспечить хранение данных о действиях и операциях не менее трех лет, а для данных, полученных в результате выполнения банковского платежного технологического процесса, - не менее пяти лет, если иные сроки хранения не установлены законодательством РФ, нормативными актами Банка России.
Для проведения процедур мониторинга ИБ и анализа данных о действиях и операциях следует использовать специализированные программные и (или) технические средства.
Процедуры мониторинга ИБ и анализа данных о действиях и операциях должны использовать зафиксированные критерии выявления неправомерных или подозрительных действий и операций. Указанные процедуры мониторинга ИБ и анализа должны применяться на регулярной основе, например ежедневно, ко всем выполненным действиям и операциям (транзакциям).
Для проведения процедур мониторинга ИБ и анализа данных о действиях и операциях следует использовать специализированные программные и (или) технические средства.
Процедуры мониторинга ИБ и анализа данных о действиях и операциях должны использовать зафиксированные критерии выявления неправомерных или подозрительных действий и операций. Указанные процедуры мониторинга ИБ и анализа должны применяться на регулярной основе, например ежедневно, ко всем выполненным действиям и операциям (транзакциям).
CIS Critical Security Controls v8 (The 18 CIS CSC):
13.3
13.3 Deploy a Network Intrusion Detection Solution
Deploy a network intrusion detection solution on enterprise assets, where appropriate. Example implementations include the use of a Network Intrusion Detection System (NIDS) or equivalent cloud service provider (CSP) service.
Deploy a network intrusion detection solution on enterprise assets, where appropriate. Example implementations include the use of a Network Intrusion Detection System (NIDS) or equivalent cloud service provider (CSP) service.
8.8
8.8 Collect Command-Line Audit Logs
Collect command-line audit logs. Example implementations include collecting audit logs from PowerShell®, BASH™, and remote administrative terminals.
Collect command-line audit logs. Example implementations include collecting audit logs from PowerShell®, BASH™, and remote administrative terminals.
8.6
8.6 Collect DNS Query Audit Logs
Collect DNS query audit logs on enterprise assets, where appropriate and supported.
Collect DNS query audit logs on enterprise assets, where appropriate and supported.
8.11
8.11 Conduct Audit Log Reviews
Conduct reviews of audit logs to detect anomalies or abnormal events that could indicate a potential threat. Conduct reviews on a weekly, or more frequent, basis
Conduct reviews of audit logs to detect anomalies or abnormal events that could indicate a potential threat. Conduct reviews on a weekly, or more frequent, basis
8.5
8.5 Collect Detailed Audit Logs
Configure detailed audit logging for enterprise assets containing sensitive data. Include event source, date, username, timestamp, source addresses, destination addresses, and other useful elements that could assist in a forensic investigation.
Configure detailed audit logging for enterprise assets containing sensitive data. Include event source, date, username, timestamp, source addresses, destination addresses, and other useful elements that could assist in a forensic investigation.
8.3
8.3 Ensure Adequate Audit Log Storage
Ensure that logging destinations maintain adequate storage to comply with the enterprise’s audit log management process.
Ensure that logging destinations maintain adequate storage to comply with the enterprise’s audit log management process.
8.7
8.7 Collect URL Request Audit Logs
Collect URL request audit logs on enterprise assets, where appropriate and supported.
Collect URL request audit logs on enterprise assets, where appropriate and supported.
13.1
13.1 Centralize Security Event Alerting Network
Centralize security event alerting across enterprise assets for log correlation and analysis. Best practice implementation requires the use of a SIEM, which includes vendor-defined event correlation alerts. A log analytics platform configured with security-relevant correlation alerts also satisfies this Safeguard.
Centralize security event alerting across enterprise assets for log correlation and analysis. Best practice implementation requires the use of a SIEM, which includes vendor-defined event correlation alerts. A log analytics platform configured with security-relevant correlation alerts also satisfies this Safeguard.
8.2
8.2 Collect Audit Logs
Collect audit logs. Ensure that logging, per the enterprise’s audit log management process, has been enabled across enterprise assets.
Collect audit logs. Ensure that logging, per the enterprise’s audit log management process, has been enabled across enterprise assets.
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
МАС.21
МАС.21 Регистрация нарушений и сбоев в формировании и сборе данных о событиях защиты информации
3-Н 2-Т 1-Т
3-Н 2-Т 1-Т
ЗВК.26
ЗВК.26 Регистрация сбоев в выполнении контроля (проверок) на отсутствие вредоносного кода
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
РД.40
РД.40 Регистрация осуществления субъектами логического доступа идентификации и аутентификации
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
МАС.6
МАС.6 Организация мониторинга данных регистрации о событиях защиты информации, формируемых контроллерами доменов
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
ЗСВ.34
ЗСВ.34 Регистрация операций, связанных с созданием и удалением виртуальных машин
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
МАС.5
МАС.5 Организация мониторинга данных регистрации о событиях защиты информации, формируемых АС и приложениями
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
ПУИ.29
ПУИ.29 Регистрация операций, связанных с осуществлением доступа работниками финансовой организации к ресурсам сети Интернет
3-Н 2-Т 1-Т
3-Н 2-Т 1-Т
ЗВК.27
ЗВК.27 Регистрация отключения средств защиты от вредоносного кода
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
ЗВК.22
ЗВК.22 Регистрация операций по проведению проверок на отсутствие вредоносного кода
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
ЗСВ.40
ЗСВ.40 Регистрация операций, связанных с аутентификацией и авторизацией пользователей при осуществлении доступа к виртуальным машинам
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
ЗВК.23
ЗВК.23 Регистрация фактов выявления вредоносного кода
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-Т
РИ.2
РИ.2 Регистрация информации, потенциально связанной с инцидентами защиты информации, в том числе НСД, полученной от работников, клиентов и (или) контрагентов финансовой организации
3-О 2-Т 1-Т
3-О 2-Т 1-Т
NIST Cybersecurity Framework (RU):
RS.AN-1
RS.AN-1: Исследуются уведомления от систем обнаружения
PR.PT-1
PR.PT-1: В соответствии с политикой определяются, документируются, внедряются и проверяются записи аудита / журналов событий
DE.CM-3
DE.CM-3: Деятельность персонала отслеживается для выявления потенциальных событий кибербезопасности
DE.CM-7
DE.CM-7: Выполняется мониторинг неавторизованных персонала, подключений, устройств и программного обеспечения
DE.AE-3
DE.AE-3: Данные о событиях агрегируются и коррелируются из нескольких источников и сенсоров
DE.AE-2
DE.AE-2: Обнаруженные события анализируются для определения целей и методов атаки
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
РСБ.4
РСБ.4 Реагирование на сбои при регистрации событий безопасности, в том числе аппаратные и программные ошибки, сбои в механизмах сбора информации и достижение предела или переполнения объема (емкости) памяти
ЗСВ.3
ЗСВ.3 Регистрация событий безопасности в виртуальной инфраструктуре
ИНЦ.2
ИНЦ.2 Обнаружение, идентификация и регистрация инцидентов
РСБ.2
РСБ.2 Определение состава и содержания информации о событиях безопасности, подлежащих регистрации
РСБ.1
РСБ.1 Определение событий безопасности, подлежащих регистрации, и сроков их хранения
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
8.8
8.8 Собираются журналы командной строки
Журналы ведутся для PowerShell, BASH, терминалов доступа и так далее.
Журналы ведутся для PowerShell, BASH, терминалов доступа и так далее.
13.3
13.3 Внедрена сетевая (network) система обнаружения вторжений (IDS, Intrusion Detection System)
Внедрить сетевое IDS-решение.
Внедрить сетевое IDS-решение.
8.11
8.11 Реализован анализ журналов регистрации событий
Проводить проверку и анализ журналов аудита
Проводить проверку и анализ журналов аудита
8.6
8.6 Собираются журналы DNS-запросов
Собирать журналы DNS-запросов
Собирать журналы DNS-запросов
8.7
8.7 Собираются журналы URL-запросов
Собирать журналы URL-запросов
Собирать журналы URL-запросов
13.1
13.1 Реализовано централизованное оповещение о событиях безопасности
Лучшие практики включают использование SIEM-систем и платформ для анализа журналов безопасности.
Лучшие практики включают использование SIEM-систем и платформ для анализа журналов безопасности.
8.3
8.3 Обеспечено надлежащее хранение журналов регистрации событий
Использовать надежное хранилище для журналов аудита.
Использовать надежное хранилище для журналов аудита.
8.2
8.2 Реализован сбор журналов регистрации событий
Логирование включено для всех корпоративных устройств и ПО.
Логирование включено для всех корпоративных устройств и ПО.
8.5
8.5 Собираются детализированные журналы регистрации событий
Подробные журналы ведутся для конфиденциальных данных.
Журналы содержат источник события, дату, имя пользователя, временную метку, исходный и конечный адрес передачи информации.
Подробные журналы ведутся для конфиденциальных данных.
Журналы содержат источник события, дату, имя пользователя, временную метку, исходный и конечный адрес передачи информации.
Стандарт Банка России № СТО БР ИББС-1.3-2016 от 01.01.2017 "Сбор и анализ технических данных при реагировании на инциденты информационной безопасности при осуществлении переводов денежных средств":
Р. 6 п. 3 п.п. 2
6.3.2. Информационная инфраструктура организации БС РФ (в настоящем стандарте предполагается, что сбор технических данных реализуется при наличии технической возможности с использованием функциональных возможностей объектов информационной инфраструктуры, эксплуатация которых осуществляется или организована организацией БС РФ):
- энергонезависимые технические данные, расположенные на запоминающих устройствах СВТ целевых систем:
- серверном оборудовании целевых систем;
- серверном оборудовании, поддерживающем функционирование информационной инфраструктуры целевых систем;
- СВТ, используемых для администрирования целевых систем;
- банкоматах и POS-терминалах;
- энергозависимые технические данные, расположенные в оперативной памяти СВТ целевых систем:
- СВТ, используемых для администрирования информационной инфраструктуры целевых систем;
- серверного оборудования целевых систем;
- серверного оборудования, поддерживающего функционирование информационной инфраструктуры целевых систем;
- энергозависимые технические данные СВТ целевых систем в составе следующих данных:
- данные о сетевых конфигурациях;
- данные о сетевых соединениях;
- данные о запущенных программных процессах;
- данные об открытых файлах;
- список открытых сессий доступа;
- системные дата и время операционной системы;
- протоколы (журналы) регистрации целевых систем;
- протоколы (журналы) регистрации телекоммуникационного оборудования, используемого в информационной инфраструктуре целевых систем:
- маршрутизаторы, коммутаторы, точки и контроллеры беспроводного доступа, модемы;
- средства, используемые для предоставления удаленного доступа (VPN-шлюзы);
- протоколы (журналы) регистрации средств защиты информации, используемых в информационной инфраструктуре целевых систем:
- средства (системы) аутентификации, авторизации и разграничения доступа;
- средства межсетевого экранирования;
- средства обнаружения вторжений и сетевых атак, в том числе DDOS-атак;
- DHCP-сервисы;
- средства защиты от НСД, размещенные на СВТ, используемых для администрирования информационной инфраструктуры целевых систем;
- средства антивирусной защиты информационной инфраструктуры;
- СКЗИ;
- протоколы (журналы) регистрации и данные почтовых серверов и средств контентной фильтрации электронной почты;
- протоколы (журналы) регистрации и данные web-серверов и средств контентной фильтрации web-протоколов;
- протоколы (журналы) регистрации систем управления базами данных (далее – СУБД);
- данные сетевого трафика из (в) сегмента (сегмент) вычислительной сети, в котором расположены СВТ целевых систем;
- протоколы (журналы) регистрации автоматических телефонных станций;
- протоколы (журналы) регистрации и данные систем видеонаблюдения и систем контроля доступа, используемые для контроля доступа в помещения, в которых расположены СВТ целевых систем.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
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 11.5.2
11.5.2
Defined Approach Requirements:
A change-detection mechanism (for example, file integrity monitoring tools) is deployed as follows:
Defined Approach Requirements:
A change-detection mechanism (for example, file integrity monitoring tools) is deployed as follows:
- To alert personnel to unauthorized modification (including changes, additions, and deletions) of critical files.
- To perform critical file comparisons at least once weekly
Customized Approach Objective:
Critical files cannot be modified by unauthorized personnel without an alert being generated.
Applicability Notes:
For change-detection purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. Changedetection mechanisms such as file integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is, the merchant or service provider).
Defined Approach Testing Procedures:
Critical files cannot be modified by unauthorized personnel without an alert being generated.
Applicability Notes:
For change-detection purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. Changedetection mechanisms such as file integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is, the merchant or service provider).
Defined Approach Testing Procedures:
- 11.5.2.a Examine system settings, monitored files, and results from monitoring activities to verify the use of a change-detection mechanism.
- 11.5.2.b Examine settings for the change-detection mechanism to verify it is configured in accordance with all elements specified in this requirement.
Purpose:
Changes to critical system, configuration, or content files can be an indicator an attacker has accessed an organization’s system. Such changes can allow an attacker to take additional malicious actions, access cardholder data, and/or conduct activities without detection or record.
A change detection mechanism will detect and evaluate such changes to critical files and generate alerts that can be responded to following defined processes so that personnel can take appropriate actions.
If not implemented properly and the output of the change-detection solution monitored, a malicious individual could add, remove, or alter configuration file contents, operating system programs, or application executables. Unauthorized changes, if undetected, could render existing security controls ineffective and/or result in cardholder data being stolen with no perceptible impact to normal processing.
Good Practice:
Examples of the types of files that should be monitored include, but are not limited to:
Changes to critical system, configuration, or content files can be an indicator an attacker has accessed an organization’s system. Such changes can allow an attacker to take additional malicious actions, access cardholder data, and/or conduct activities without detection or record.
A change detection mechanism will detect and evaluate such changes to critical files and generate alerts that can be responded to following defined processes so that personnel can take appropriate actions.
If not implemented properly and the output of the change-detection solution monitored, a malicious individual could add, remove, or alter configuration file contents, operating system programs, or application executables. Unauthorized changes, if undetected, could render existing security controls ineffective and/or result in cardholder data being stolen with no perceptible impact to normal processing.
Good Practice:
Examples of the types of files that should be monitored include, but are not limited to:
- System executables.
- Application executables.
- Configuration and parameter files.
- Centrally stored, historical, or archived audit logs.
- Additional critical files determined by entity (for example, through risk assessment or other means).
Examples:
Change-detection solutions such as file integrity monitoring (FIM) tools check for changes, additions, and deletions to critical files, and notify when such changes are detected.
Change-detection solutions such as file integrity monitoring (FIM) tools check for changes, additions, and deletions to critical files, and notify when such changes are detected.
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 12.6
CSC 12.6 Deploy Network-Based IDS Sensors
Deploy network-based Intrusion Detection Systems (IDS) sensors to look for unusual attack mechanisms and detect compromise of these systems at each of the organization's network boundaries.
Deploy network-based Intrusion Detection Systems (IDS) sensors to look for unusual attack mechanisms and detect compromise of these systems at each of the organization's network boundaries.
CSC 4.8
CSC 4.8 Log and Alert on Changes to Administrative Group Membership
Configure systems to issue a log entry and alert when an account is added to or removed from any group assigned administrative privileges.
Configure systems to issue a log entry and alert when an account is added to or removed from any group assigned administrative privileges.
CSC 12.5
CSC 12.5 Configure Monitoring Systems to Record Network Packets
Configure monitoring systems to record network packets passing through the boundary at each of the organization's network boundaries.
Configure monitoring systems to record network packets passing through the boundary at each of the organization's network boundaries.
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.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.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 16.12
CSC 16.12 Monitor Attempts to Access Deactivated Accounts
Monitor attempts to access deactivated accounts through audit logging.
Monitor attempts to access deactivated accounts through audit logging.
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 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.
CSC 4.9
CSC 4.9 Log and Alert on Unsuccessful Administrative Account Login
Configure systems to issue a log entry and alert on unsuccessful logins to an administrative account.
Configure systems to issue a log entry and alert on unsuccessful logins to an administrative account.
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 13.5
CSC 13.5 Monitor and Detect Any Unauthorized Use of Encryption
Monitor all traffic leaving the organization and detect any unauthorized use of encryption.
Monitor all traffic leaving the organization and detect any unauthorized use of encryption.
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.
Приказ Минздрава № 911н от 24.12.2018 "Требования к государственным информационным системам в сфере здравоохранения субъектов Российской Федерации, медицинским информационным системам медицинских организаций и информационным системам":
Раздел II п. 9 п.п. д)
д) обеспечивать протоколирование и сохранение сведений о предоставлении доступа и о других операциях с документами и метаданными в автоматизированном режиме, а также автоматизированное ведение электронных журналов учета точного времени и фактов размещения, изменения и удаления информации, содержания вносимых изменений;
Положение Банка России № 802-П от 25.07.2022 "О требованиях к защите информации в платежной системе Банка России":
П. 16.1
16.1. Участник СБП - банк плательщика должен осуществлять:
- выявление операций, соответствующих признакам осуществления переводов денежных средств без согласия клиента, установленным Банком России в соответствии с частью 5.1 статьи 8 Федерального закона от 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.2.1
10.2.1
Определенные Требования к Подходу:
Журналы аудита включены и активны для всех компонентов системы и данных о держателях карт.
Цель Индивидуального подхода:
Фиксируются записи всех действий, влияющих на компоненты системы, и данные о держателях карт.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Журналы аудита включены и активны для всех компонентов системы и данных о держателях карт.
Цель Индивидуального подхода:
Фиксируются записи всех действий, влияющих на компоненты системы, и данные о держателях карт.
Определенные Процедуры Тестирования Подхода:
- 10.2.1 Опросите системного администратора и изучите системные конфигурации, чтобы убедиться, что журналы аудита включены и активны для всех компонентов системы.
Цель:
Журналы аудита должны существовать для всех компонентов системы. Журналы аудита отправляют предупреждения системному администратору, предоставляют данные другим механизмам мониторинга, таким как системы обнаружения вторжений (IDS) и средства защиты информации и систем мониторинга событий (SIEM), а также обеспечивают отслеживание истории для расследования после инцидента.
Ведение журнала и анализ событий, связанных с безопасностью, позволяют организации выявлять и отслеживать потенциально вредоносные действия.
Надлежащая практика:
Когда организация решает, какую информацию записывать в свои журналы, важно помнить, что информация, хранящаяся в журналах аудита, является конфиденциальной и должна быть защищена в соответствии с требованиями настоящего стандарта. Следует позаботиться о том, чтобы в журналах аудита сохранялась только важная информация, чтобы свести к минимуму риск.
Журналы аудита должны существовать для всех компонентов системы. Журналы аудита отправляют предупреждения системному администратору, предоставляют данные другим механизмам мониторинга, таким как системы обнаружения вторжений (IDS) и средства защиты информации и систем мониторинга событий (SIEM), а также обеспечивают отслеживание истории для расследования после инцидента.
Ведение журнала и анализ событий, связанных с безопасностью, позволяют организации выявлять и отслеживать потенциально вредоносные действия.
Надлежащая практика:
Когда организация решает, какую информацию записывать в свои журналы, важно помнить, что информация, хранящаяся в журналах аудита, является конфиденциальной и должна быть защищена в соответствии с требованиями настоящего стандарта. Следует позаботиться о том, чтобы в журналах аудита сохранялась только важная информация, чтобы свести к минимуму риск.
Requirement 11.5.2
11.5.2
Определенные Требования к Подходу:
Механизм обнаружения изменений (например, средства мониторинга целостности файлов) развертывается следующим образом:
Определенные Требования к Подходу:
Механизм обнаружения изменений (например, средства мониторинга целостности файлов) развертывается следующим образом:
- Для предупреждения персонала о несанкционированном изменении (включая изменения, добавления и удаления) важных файлов.
- Для выполнения критических сравнений файлов не реже одного раза в неделю
Цель Индивидуального подхода:
Критически важные файлы не могут быть изменены неавторизованным персоналом без создания предупреждения.
Примечания по применению:
Для целей обнаружения изменений критическими файлами обычно являются те, которые регулярно не изменяются, но изменение которых может указывать на компрометацию системы или риск компрометации. Механизмы обнаружения изменений, такие как продукты мониторинга целостности файлов, обычно поставляются с предварительно настроенными критически важными файлами для соответствующей операционной системы. Другие важные файлы, например файлы для пользовательских приложений, должны быть оценены и определены организацией (то есть продавцом или поставщиком услуг).
Определенные Процедуры Тестирования Подхода:
Критически важные файлы не могут быть изменены неавторизованным персоналом без создания предупреждения.
Примечания по применению:
Для целей обнаружения изменений критическими файлами обычно являются те, которые регулярно не изменяются, но изменение которых может указывать на компрометацию системы или риск компрометации. Механизмы обнаружения изменений, такие как продукты мониторинга целостности файлов, обычно поставляются с предварительно настроенными критически важными файлами для соответствующей операционной системы. Другие важные файлы, например файлы для пользовательских приложений, должны быть оценены и определены организацией (то есть продавцом или поставщиком услуг).
Определенные Процедуры Тестирования Подхода:
- 11.5.2.a Изучите системные настройки, отслеживаемые файлы и результаты действий по мониторингу, чтобы проверить использование механизма обнаружения изменений.
- 11.5.2.b Проверьте настройки механизма обнаружения изменений, чтобы убедиться, что он настроен в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Изменения в критически важных системных, конфигурационных или содержательных файлах могут указывать на то, что злоумышленник получил доступ к системе организации. Такие изменения могут позволить злоумышленнику совершать дополнительные вредоносные действия, получать доступ к данным о держателях карт и/или осуществлять действия без обнаружения или записи.
Механизм обнаружения изменений будет обнаруживать и оценивать такие изменения в критически важных файлах и генерировать предупреждения, на которые можно реагировать в соответствии с определенными процессами, чтобы персонал мог предпринять соответствующие действия.
При неправильной реализации и отслеживании результатов решения для обнаружения изменений злоумышленник может добавлять, удалять или изменять содержимое файла конфигурации, программы операционной системы или исполняемые файлы приложений. Несанкционированные изменения, если они не будут обнаружены, могут сделать существующие меры безопасности неэффективными и/или привести к краже данных о держателях карт без заметного влияния на нормальную обработку.
Надлежащая практика:
Примеры типов файлов, которые следует отслеживать, включают, но не ограничиваются ими:
Изменения в критически важных системных, конфигурационных или содержательных файлах могут указывать на то, что злоумышленник получил доступ к системе организации. Такие изменения могут позволить злоумышленнику совершать дополнительные вредоносные действия, получать доступ к данным о держателях карт и/или осуществлять действия без обнаружения или записи.
Механизм обнаружения изменений будет обнаруживать и оценивать такие изменения в критически важных файлах и генерировать предупреждения, на которые можно реагировать в соответствии с определенными процессами, чтобы персонал мог предпринять соответствующие действия.
При неправильной реализации и отслеживании результатов решения для обнаружения изменений злоумышленник может добавлять, удалять или изменять содержимое файла конфигурации, программы операционной системы или исполняемые файлы приложений. Несанкционированные изменения, если они не будут обнаружены, могут сделать существующие меры безопасности неэффективными и/или привести к краже данных о держателях карт без заметного влияния на нормальную обработку.
Надлежащая практика:
Примеры типов файлов, которые следует отслеживать, включают, но не ограничиваются ими:
- Системные исполняемые файлы.
- Исполняемые файлы приложений.
- Файлы конфигурации и параметров.
- Централизованно хранимые, исторические или архивированные журналы аудита.
- Дополнительные критические файлы, определенные организацией (например, с помощью оценки рисков или другими способами).
Примеры:
Решения для обнаружения изменений, такие как средства мониторинга целостности файлов (FIM), проверяют наличие изменений, дополнений и удалений в критически важных файлах и уведомляют об обнаружении таких изменений.
Решения для обнаружения изменений, такие как средства мониторинга целостности файлов (FIM), проверяют наличие изменений, дополнений и удалений в критически важных файлах и уведомляют об обнаружении таких изменений.
Requirement 10.2.1.1
10.2.1.1
Определенные Требования к Подходу:
Журналы аудита фиксируют весь индивидуальный доступ пользователей к данным о держателях карт.
Цель Индивидуального подхода:
Фиксируются записи обо всех индивидуальных пользовательских доступах к данным о держателях карт.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Журналы аудита фиксируют весь индивидуальный доступ пользователей к данным о держателях карт.
Цель Индивидуального подхода:
Фиксируются записи обо всех индивидуальных пользовательских доступах к данным о держателях карт.
Определенные Процедуры Тестирования Подхода:
- 10.2.1.1 Проверьте конфигурации журнала аудита и данные журнала, чтобы убедиться, что весь индивидуальный доступ пользователя к данным о держателях карт регистрируется.
Цель:
Крайне важно иметь процесс или систему, которые связывают доступ пользователя с доступом к системным компонентам. Злоумышленники могут получить информацию об учетной записи пользователя, имеющей доступ к системам в CDE, или они могут создать новую несанкционированную учетную запись для доступа к данным о держателях карт.
Надлежащая практика:
Запись всего индивидуального доступа к данным о держателях карт позволяет определить, какие учетные записи могли быть скомпрометированы или использованы не по назначению.
Крайне важно иметь процесс или систему, которые связывают доступ пользователя с доступом к системным компонентам. Злоумышленники могут получить информацию об учетной записи пользователя, имеющей доступ к системам в CDE, или они могут создать новую несанкционированную учетную запись для доступа к данным о держателях карт.
Надлежащая практика:
Запись всего индивидуального доступа к данным о держателях карт позволяет определить, какие учетные записи могли быть скомпрометированы или использованы не по назначению.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
РСБ.1
РСБ.1 Определение событий безопасности, подлежащих регистрации, и сроков их хранения
РСБ.4
РСБ.4 Реагирование на сбои при регистрации событий безопасности, в том числе аппаратные и программные ошибки, сбои в механизмах сбора информации и достижение предела или переполнения объема (емкости) памяти
ЗСВ.3
ЗСВ.3 Регистрация событий безопасности в виртуальной инфраструктуре
РСБ.2
РСБ.2 Определение состава и содержания информации о событиях безопасности, подлежащих регистрации
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
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.15
А.8.15 Логирование
Должны создаваться, храниться, защищаться и анализироваться журналы, в которых фиксируются деятельность, исключения, сбои и другие релевантные события.
Должны создаваться, храниться, защищаться и анализироваться журналы, в которых фиксируются деятельность, исключения, сбои и другие релевантные события.
Приказ ФСБ России № 196 от 06.05.2019 "Требования к средствам, предназначенным для обнаружения, предупреждения и ликвидации последствий компьютерных атак и реагирования на компьютерные инциденты":
VIII п.21.3
21.3. При осуществлении регистрации событий ИБ средства ГосСОПКА должны обеспечивать:
- возможность определения перечня событий ИБ, подлежащих регистрации, и хранения соответствующих записей в электронных журналах с возможностью корректировки сроков;
- возможность регистрации следующих связанных с функционированием средств ГосСОПКА сведений: идентификатора пользователя, времени авторизации, запуска (завершения) программ и процессов, связанных с реализацией функций безопасности средств ГосСОПКА, команды управления, неудачных попыток аутентификации, данных о сбоях и неисправностях в работе средств ГосСОПКА;
- ведение электронных журналов учета технического состояния, содержащих следующие поля: информация о состоянии интерфейсов (портов), информация об ошибках в работе средств ГосСОПКА с их классификацией, информация о загрузке и инициализации средств ГосСОПКА и их остановке (только для средств ППКА);
- защиту электронных журналов от редактирования и удаления содержащейся в них информации (только для средств ППКА);
- автоматическое уведомление о заполнении электронного журнала и возможность его сохранения на внешнем носителе информации (только для средств ППКА).
SWIFT Customer Security Controls Framework v2022:
6 - 6.4 Logging and Monitoring
6.4 Logging and Monitoring
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
АУД.8
АУД.8 Реагирование на сбои при регистрации событий безопасности
АУД.4
АУД.4 Регистрация событий безопасности
FDA 21 CFR part 11 (RU):
Sec. 11.10 p. 1 sp. e
(e) Использование защищенных, созданных компьютером с указанием времени возникновения событий журналов аудита для регистрации даты и времени входов и действий операторов (создание, изменение или удаление электронных записей). Изменения в записях журнала не должны скрывать ранее записанную информацию. Такое логирование должно храниться в течение периода, не меньшего, чем требуется для соответствующих электронных записей, и должна быть доступно для просмотра и копирования агентством.
NIST Cybersecurity Framework (EN):
DE.AE-3
DE.AE-3: Event data are collected and correlated from multiple sources and sensors
DE.AE-2
DE.AE-2: Detected events are analyzed to understand attack targets and methods
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
DE.CM-3
DE.CM-3: Personnel activity is monitored to detect potential cybersecurity events
DE.CM-7
DE.CM-7: Monitoring for unauthorized personnel, connections, devices, and software is performed
Стандарт Банка России № РС БР ИББС-2.5-2014 от 01.06.2014 "Менеджмент инцидентов информационной безопасности":
Р. 6 п. 5 п.п. 8
6.5.8. В организации БС РФ рекомендуется реализовать процедуры обеспечения целостности журналов, содержащих информацию о событиях ИБ и инцидентах ИБ, используемых в соответствии с рекомендациями, установленными пп. 6.4.4 настоящего документа, на случай возможных сбоев в работе и отказов технических и (или) программных средств.
Р. 6 п. 5 п.п. 2
6.5.2. Средства мониторинга ИБ и контроля защитных мер должны выполнять следующие основные функции:
- отслеживание и регистрацию событий ИБ в целях обнаружения инцидентов ИБ;
- агрегирование полученной информации о событиях ИБ, корреляцию информации о событиях ИБ, обнаружение инцидентов ИБ на основе установленных в организации БС РФ критериев и правил;
- текущий контроль функционирования применяемых средств защиты информации и обнаружение отклонений в их работе от штатного режима;
- текущий контроль действий пользователей и эксплуатирующего персонала и обнаружение нарушений в эксплуатации технических средств.
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
АУД.8
АУД.8 Реагирование на сбои при регистрации событий безопасности
АУД.4
АУД.4 Регистрация событий безопасности
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
12.4.1
12.4.1 Регистрация событий
Мера обеспечения ИБ
Требуется обеспечивать формирование, ведение и регулярный анализ регистрационных журналов, фиксирующих действия пользователей, нештатные ситуации, ошибки и события безопасности.
Руководство по применению
Журналы событий, где это применимо, должны включать в себя:
- a) пользовательские идентификаторы;
- b) действия в системе;
- c) дату, время и детали ключевых событий, например вход и выход из системы;
- d) идентификатор устройства или местоположения, если возможно, и системный идентификатор;
- e) записи об успешных и отклоненных попытках доступа к системе;
- f) записи об успешных или отклоненных попытках доступа к данным и иным ресурсам;
- g) изменения конфигурации системы;
- h) использование привилегий;
- i) использование системных служебных программ и приложений;
- j) файлы, к которым был запрошен доступ, а также вид доступа;
- k) сетевые адреса и протоколы;
- l) сигналы тревоги от системы контроля управления доступом;
- m) события активации и деактивации систем защиты, таких как антивирусные средства и системы обнаружения вторжений;
- n) записи транзакций, выполненных пользователями в приложениях.
Ведение журнала событий служит основой для автоматизированных систем мониторинга, которые способны генерировать консолидированные отчеты и оповещения о безопасности системы.
Дополнительная информация
Журналы событий могут содержать информацию ограниченного доступа. Для обеспечения конфиденциальности должны быть приняты соответствующие меры защиты (см. 18.1.4).
Там, где это возможно, системные администраторы не должны иметь прав на удаление или деактивацию журналирования собственных действий (см. 12.4.3).
Стандарт № 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.
Logs that record activities, exceptions, faults and other relevant events shall be produced, stored, protected and analysed.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.