Куда я попал?
NIST Cybersecurity Framework (EN)
Framework
PR.PT-1
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
CIS Critical Security Controls v8 (The 18 CIS CSC):
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.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.
8.9
8.9 Centralize Audit Logs
Centralize, to the extent possible, audit log collection and retention across enterprise assets.
Centralize, to the extent possible, audit log collection and retention across enterprise assets.
ГОСТ Р № 22301 от 01.01.2022 "Надежность в технике. Системы менеджмента непрерывности деятельности. Требования":
Р. 9 п. 1
9.1 Мониторинг, измерение, анализ и оценка
Организация должна определить:
Организация должна определить:
- а) объекты мониторинга и измерения;
- b) методы мониторинга, измерения, анализа и оценки (что применимо), обеспечивающие достоверные результаты;
- с) сроки и исполнителей мониторинга и измерений;
- d) сроки и исполнителей выполнения анализа и оценки результатов анализа и измерений.
Организация должна хранить соответствующую документированную информацию в качестве объективных свидетельств полученных результатов. Организация должна оценить показатели и результативность СМНД.
Р. 7 п. 5 пп. 1
7.5.1 Общие положения
СМНД организации должна включать следующее:
СМНД организации должна включать следующее:
- а ) документированную информацию, соответствующую требованиям настоящего стандарта;
- b ) определенную организацией документированную информацию, необходимую для обеспечения результативности СМНД.
Примечание — Объем документированной информации СМНД может отличаться в разных организациях вследствие:
- размера организации и особенностей ее видов деятельности, процессов, продукции, услуг и доступных ресурсов;
- сложности процессов организации, ее СМНД и их взаимодействия;
- компетентности персонала.
Р. 9 п. 2 пп. 2
9.2.2 Программа(ы) аудита
Организация должна:
Организация должна:
- а) планировать, устанавливать, внедрять и поддерживать в рабочем состоянии программу(ы) аудита, включая требования к частоте проведения, методам, распределению обязанностей, планированию и отчетности, при этом необходимо учитывать важность соответствующих процессов и результаты предыдущих аудитов;
- b) определять критерии и область применения каждого аудита;
- с) выбирать аудиторов и проводить аудиты так. чтобы обеспечить объективность и беспристрастность процесса аудита;
- d) обеспечить, чтобы результаты аудита были доведены до сведения соответствующих руководителей;
- е) хранить документированную информацию в качестве объективных свидетельств реализации программ(ы) аудита и результатов аудита;
- f) обеспечить, чтобы все необходимые корректирующие действия по устранению обнаруженных несоответствий и их причин были выполнены без неоправданной задержки;
- g) обеспечить, чтобы последующие аудиторские действия предпринимались с учетом верификации предпринятых действий и отчетности о результатах верификации.
Р. 9 п. 2 пп. 1
9.2.1 Общие положения
Организация должна проводить внутренние аудиторские проверки через запланированные промежутки времени, чтобы получить информацию о том. что СМНД:
Организация должна проводить внутренние аудиторские проверки через запланированные промежутки времени, чтобы получить информацию о том. что СМНД:
- а) соответствует:
- 1) требованиям организации к своей СМНД;
- 2) требованиям настоящего стандарта;
- b) результативно функционирует и поддерживается в рабочем состоянии.
Р. 4 п. 2 пп. 2
4.2.2 Законодательные и обязательные требования
Организация должна:
Организация должна:
- а) разработать и поддерживать процесс идентификации, получения доступа и оценки применимых законодательных и обязательных требований, связанных с непрерывностью производства и поставки продукции и оказания услуг, видов деятельности и ресурсов организации;
- b) обеспечить учет при внедрении и функционировании в организации СМНД применимых законодательных. обязательных и других требований;
- с) документировать данную информацию и поддерживать ее в актуализированном состоянии.
Р. 8 п. 4 пп. 3 ппп. 1
8.4.3.1 Организация должна документировать и поддерживать процедуры:
- а) обмена информацией с внутренними и внешними соответствующими заинтересованными сторонами, в том числе о вопросах, сроках и участниках обмена информацией;
Примечание — Организация может документировать и поддерживать процедуры о способах и условиях обмена информацией с сотрудниками по аварийным контактам.
- b) получения, документирования и ответа при обмене информацией с заинтересованными сторонами. включая все государственные или региональные системы консультирования по риску или аналогичные структуры;
- с) обеспечения доступности средств связи при нарушении деятельности организации;
- d) облегчения структурированного обмена информацией с аварийными службами;
- е) предоставления подробной информации об ответных действиях организации в СМИ после инцидента. включая стратегию обмена информацией;
- f) записи деталей нарушения деятельности организации, предпринятых действий и принятых решений.
Р. 9 п. 3 пп. 3 ппп.2
9.3.3.2 Организация должна хранить документированную информацию в качестве объективных свидетельств результатов анализа со стороны руководства, включая:
- а) обмен информацией о результатах анализа со стороны руководства с заинтересованными сторонами;
- b) выполнение соответствующих действий в отношении полученных результатов.
NIST Cybersecurity Framework (RU):
PR.PT-1
PR.PT-1: В соответствии с политикой определяются, документируются, внедряются и проверяются записи аудита / журналов событий
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
РСБ.5
РСБ.5 Мониторинг (просмотр, анализ) результатов регистрации событий безопасности и реагирование на них
РСБ.2
РСБ.2 Определение состава и содержания информации о событиях безопасности, подлежащих регистрации
РСБ.3
РСБ.3 Сбор, запись и хранение информации о событиях безопасности в течение установленного времени хранения
РСБ.1
РСБ.1 Определение событий безопасности, подлежащих регистрации, и сроков их хранения
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
ВРВ.1
ВРВ.1 Организация мониторинга и выявления событий реализации информационных угроз в рамках процессов, реализуемых в соответствии с требованиями ГОСТ Р 57580.1., в целях своевременного обнаружения:
- компьютерных атак;
- аномальной активности лиц, имеющих легальный доступ к объектам информатизации финансовой организации;
- неправомерного использования доступа поставщиками услуг или другими доверенными организациями;
- фактов утечки защищаемой информации.
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
8.11
8.11 Реализован анализ журналов регистрации событий
Проводить проверку и анализ журналов аудита
Проводить проверку и анализ журналов аудита
8.9
8.9 Реализовано централизованное управление журналами регистрации событий
Централизовать ведение журналов аудита
Централизовать ведение журналов аудита
8.2
8.2 Реализован сбор журналов регистрации событий
Логирование включено для всех корпоративных устройств и ПО.
Логирование включено для всех корпоративных устройств и ПО.
8.5
8.5 Собираются детализированные журналы регистрации событий
Подробные журналы ведутся для конфиденциальных данных.
Журналы содержат источник события, дату, имя пользователя, временную метку, исходный и конечный адрес передачи информации.
Подробные журналы ведутся для конфиденциальных данных.
Журналы содержат источник события, дату, имя пользователя, временную метку, исходный и конечный адрес передачи информации.
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 10.4.2
10.4.2
Defined Approach Requirements:
Logs of all other system components (those not specified in Requirement 10.4.1) are reviewed periodically.
Customized Approach Objective:
Potentially suspicious or anomalous activities for other system components (not included in 10.4.1) are reviewed in accordance with the entity’s identified risk.
Applicability Notes:
This requirement is applicable to all other in-scope system components not included in Requirement 10.4.1.
Defined Approach Testing Procedures:
Defined Approach Requirements:
Logs of all other system components (those not specified in Requirement 10.4.1) are reviewed periodically.
Customized Approach Objective:
Potentially suspicious or anomalous activities for other system components (not included in 10.4.1) are reviewed in accordance with the entity’s identified risk.
Applicability Notes:
This requirement is applicable to all other in-scope system components not included in Requirement 10.4.1.
Defined Approach Testing Procedures:
- 10.4.2.a Examine security policies and procedures to verify that processes are defined for reviewing logs of all other system components periodically.
- 10.4.2.b Examine documented results of log reviews and interview personnel to verify that log reviews are performed periodically.
Purpose:
Periodic review of logs for all other system components (not specified in Requirement 10.4.1) helps to identify indications of potential issues or attempts to access critical systems via less-critical systems.
Periodic review of logs for all other system components (not specified in Requirement 10.4.1) helps to identify indications of potential issues or attempts to access critical systems via less-critical systems.
Requirement 5.3.4
5.3.4
Defined Approach Requirements:
Audit logs for the anti-malware solution(s) are enabled and retained in accordance with Requirement 10.5.1.
Customized Approach Objective:
Historical records of anti-malware actions are immediately available and retained for at least 12 months.
Defined Approach Testing Procedures:
Defined Approach Requirements:
Audit logs for the anti-malware solution(s) are enabled and retained in accordance with Requirement 10.5.1.
Customized Approach Objective:
Historical records of anti-malware actions are immediately available and retained for at least 12 months.
Defined Approach Testing Procedures:
- 5.3.4 Examine anti-malware solution(s) configurations to verify logs are enabled and retained in accordance with Requirement 10.5.1.
Purpose:
It is important to track the effectiveness of the anti-malware mechanisms—for example, by confirming that updates and scans are being performed as expected, and that malware is identified and addressed. Audit logs also allow an entity to determine how malware entered the environment and track its activity when inside the entity’s network.
It is important to track the effectiveness of the anti-malware mechanisms—for example, by confirming that updates and scans are being performed as expected, and that malware is identified and addressed. Audit logs also allow an entity to determine how malware entered the environment and track its activity when inside the entity’s network.
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.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.12.4.1
A.12.4.1 Регистрация событий
Мера обеспечения информационной безопасности: Требуется обеспечивать формирование, ведение и регулярный анализ регистрационных журналов, фиксирующих действия пользователей, нештатные ситуации, ошибки и события информационной безопасности
Мера обеспечения информационной безопасности: Требуется обеспечивать формирование, ведение и регулярный анализ регистрационных журналов, фиксирующих действия пользователей, нештатные ситуации, ошибки и события информационной безопасности
A.12.4.2
A.12.4.2 Защита информации регистрационных журналов
Мера обеспечения информационной безопасности: Средства регистрации и информация регистрационных журналов должны быть защищены от фальсификации и несанкционированного доступа
Мера обеспечения информационной безопасности: Средства регистрации и информация регистрационных журналов должны быть защищены от фальсификации и несанкционированного доступа
A.12.4.4
A.12.4.4 Синхронизация часов
Мера обеспечения информационной безопасности: Часы всех систем обработки информации в рамках организации или домена безопасности должны быть синхронизированы с единым эталонным источником времени
Мера обеспечения информационной безопасности: Часы всех систем обработки информации в рамках организации или домена безопасности должны быть синхронизированы с единым эталонным источником времени
A.12.4.3
A.12.4.3 Регистрационные журналы действий администратора и оператора
Мера обеспечения информационной безопасности: Действия системного администратора и оператора системы следует регистрировать, а регистрационные журналы защищать и регулярно анализировать
Мера обеспечения информационной безопасности: Действия системного администратора и оператора системы следует регистрировать, а регистрационные журналы защищать и регулярно анализировать
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 6.5
CSC 6.5 Central Log Management
Ensure that appropriate logs are being aggregated to a central log management system for analysis and review.
Ensure that appropriate logs are being aggregated to a central log management system for analysis and review.
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 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 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.
Положение Банка России № 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.4.2
10.4.2
Определенные Требования к Подходу:
Журналы всех других компонентов системы (не указанных в требовании 10.4.1) периодически просматриваются.
Цель Индивидуального подхода:
Потенциально подозрительные или аномальные действия для других компонентов системы (не включенных в 10.4.1) рассматриваются в соответствии с выявленным риском организации.
Примечания по применению:
Это требование применимо ко всем другим компонентам системы, не включенным в Требование 10.4.1.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Журналы всех других компонентов системы (не указанных в требовании 10.4.1) периодически просматриваются.
Цель Индивидуального подхода:
Потенциально подозрительные или аномальные действия для других компонентов системы (не включенных в 10.4.1) рассматриваются в соответствии с выявленным риском организации.
Примечания по применению:
Это требование применимо ко всем другим компонентам системы, не включенным в Требование 10.4.1.
Определенные Процедуры Тестирования Подхода:
- 10.4.2.a Изучите политики и процедуры безопасности, чтобы убедиться, что определены процессы для периодического просмотра журналов всех других компонентов системы.
- 10.4.2.b Изучите документированные результаты проверок журналов и опросите персонал, чтобы убедиться, что проверки журналов выполняются периодически.
Цель:
Периодический просмотр журналов для всех других компонентов системы (не указанных в требовании 10.4.1) помогает выявить признаки потенциальных проблем или попыток доступа к критическим системам через менее критичные системы.
Периодический просмотр журналов для всех других компонентов системы (не указанных в требовании 10.4.1) помогает выявить признаки потенциальных проблем или попыток доступа к критическим системам через менее критичные системы.
Requirement 10.2.1
10.2.1
Определенные Требования к Подходу:
Журналы аудита включены и активны для всех компонентов системы и данных о держателях карт.
Цель Индивидуального подхода:
Фиксируются записи всех действий, влияющих на компоненты системы, и данные о держателях карт.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Журналы аудита включены и активны для всех компонентов системы и данных о держателях карт.
Цель Индивидуального подхода:
Фиксируются записи всех действий, влияющих на компоненты системы, и данные о держателях карт.
Определенные Процедуры Тестирования Подхода:
- 10.2.1 Опросите системного администратора и изучите системные конфигурации, чтобы убедиться, что журналы аудита включены и активны для всех компонентов системы.
Цель:
Журналы аудита должны существовать для всех компонентов системы. Журналы аудита отправляют предупреждения системному администратору, предоставляют данные другим механизмам мониторинга, таким как системы обнаружения вторжений (IDS) и средства защиты информации и систем мониторинга событий (SIEM), а также обеспечивают отслеживание истории для расследования после инцидента.
Ведение журнала и анализ событий, связанных с безопасностью, позволяют организации выявлять и отслеживать потенциально вредоносные действия.
Надлежащая практика:
Когда организация решает, какую информацию записывать в свои журналы, важно помнить, что информация, хранящаяся в журналах аудита, является конфиденциальной и должна быть защищена в соответствии с требованиями настоящего стандарта. Следует позаботиться о том, чтобы в журналах аудита сохранялась только важная информация, чтобы свести к минимуму риск.
Журналы аудита должны существовать для всех компонентов системы. Журналы аудита отправляют предупреждения системному администратору, предоставляют данные другим механизмам мониторинга, таким как системы обнаружения вторжений (IDS) и средства защиты информации и систем мониторинга событий (SIEM), а также обеспечивают отслеживание истории для расследования после инцидента.
Ведение журнала и анализ событий, связанных с безопасностью, позволяют организации выявлять и отслеживать потенциально вредоносные действия.
Надлежащая практика:
Когда организация решает, какую информацию записывать в свои журналы, важно помнить, что информация, хранящаяся в журналах аудита, является конфиденциальной и должна быть защищена в соответствии с требованиями настоящего стандарта. Следует позаботиться о том, чтобы в журналах аудита сохранялась только важная информация, чтобы свести к минимуму риск.
Requirement 10.2.1.1
10.2.1.1
Определенные Требования к Подходу:
Журналы аудита фиксируют весь индивидуальный доступ пользователей к данным о держателях карт.
Цель Индивидуального подхода:
Фиксируются записи обо всех индивидуальных пользовательских доступах к данным о держателях карт.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Журналы аудита фиксируют весь индивидуальный доступ пользователей к данным о держателях карт.
Цель Индивидуального подхода:
Фиксируются записи обо всех индивидуальных пользовательских доступах к данным о держателях карт.
Определенные Процедуры Тестирования Подхода:
- 10.2.1.1 Проверьте конфигурации журнала аудита и данные журнала, чтобы убедиться, что весь индивидуальный доступ пользователя к данным о держателях карт регистрируется.
Цель:
Крайне важно иметь процесс или систему, которые связывают доступ пользователя с доступом к системным компонентам. Злоумышленники могут получить информацию об учетной записи пользователя, имеющей доступ к системам в CDE, или они могут создать новую несанкционированную учетную запись для доступа к данным о держателях карт.
Надлежащая практика:
Запись всего индивидуального доступа к данным о держателях карт позволяет определить, какие учетные записи могли быть скомпрометированы или использованы не по назначению.
Крайне важно иметь процесс или систему, которые связывают доступ пользователя с доступом к системным компонентам. Злоумышленники могут получить информацию об учетной записи пользователя, имеющей доступ к системам в CDE, или они могут создать новую несанкционированную учетную запись для доступа к данным о держателях карт.
Надлежащая практика:
Запись всего индивидуального доступа к данным о держателях карт позволяет определить, какие учетные записи могли быть скомпрометированы или использованы не по назначению.
Requirement 5.3.4
5.3.4
Определенные Требования к Подходу:
Журналы аудита для решения (решений) для защиты от вредоносных программ включены и сохраняются в соответствии с требованием 10.5.1.
Цель Индивидуального подхода:
Исторические записи о действиях по защите от вредоносных программ становятся доступными немедленно и сохраняются не менее 12 месяцев.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Журналы аудита для решения (решений) для защиты от вредоносных программ включены и сохраняются в соответствии с требованием 10.5.1.
Цель Индивидуального подхода:
Исторические записи о действиях по защите от вредоносных программ становятся доступными немедленно и сохраняются не менее 12 месяцев.
Определенные Процедуры Тестирования Подхода:
- 5.3.4 Проверьте конфигурации решений для защиты от вредоносных программ, чтобы убедиться, что журналы включены и сохраняются в соответствии с требованием 10.5.1.
Цель:
Важно отслеживать эффективность механизмов защиты от вредоносных программ - например, путем подтверждения того, что обновления и проверки выполняются должным образом, а вредоносное ПО идентифицировано и устранено. Журналы аудита также позволяют организации определять, как вредоносное ПО проникло в среду, и отслеживать его активность внутри сети организации.
Важно отслеживать эффективность механизмов защиты от вредоносных программ - например, путем подтверждения того, что обновления и проверки выполняются должным образом, а вредоносное ПО идентифицировано и устранено. Журналы аудита также позволяют организации определять, как вредоносное ПО проникло в среду, и отслеживать его активность внутри сети организации.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
РСБ.5
РСБ.5 Мониторинг (просмотр, анализ) результатов регистрации событий безопасности и реагирование на них
РСБ.2
РСБ.2 Определение состава и содержания информации о событиях безопасности, подлежащих регистрации
РСБ.3
РСБ.3 Сбор, запись и хранение информации о событиях безопасности в течении установленного времени хранения
РСБ.1
РСБ.1 Определение событий безопасности, подлежащих регистрации, и сроков их хранения
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.17
А.8.17 Синхронизация времени
Системное время используемых организацией систем обработки информации должно быть синхронизировано с утвержденными источниками эталонного времени.
Системное время используемых организацией систем обработки информации должно быть синхронизировано с утвержденными источниками эталонного времени.
А.8.15
А.8.15 Логирование
Должны создаваться, храниться, защищаться и анализироваться журналы, в которых фиксируются деятельность, исключения, сбои и другие релевантные события.
Должны создаваться, храниться, защищаться и анализироваться журналы, в которых фиксируются деятельность, исключения, сбои и другие релевантные события.
SWIFT Customer Security Controls Framework v2022:
6 - 6.4 Logging and Monitoring
6.4 Logging and Monitoring
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
АУД.7
АУД.7 Мониторинг безопасности
АУД.4
АУД.4 Регистрация событий безопасности
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
АУД.7
АУД.7 Мониторинг безопасности
АУД.4
АУД.4 Регистрация событий безопасности
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
12.4.4
12.4.4 Синхронизация часов
Мера обеспечения ИБ
Часы всех систем обработки информации в рамках организации или домена безопасности должны быть синхронизированы с единым эталонным источником времени.
Руководство по применению
Внешние и внутренние требования к представлению времени, синхронизаций и точности должны быть задокументированы. Такие требования могут быть правовыми, нормативными, договорными, являться требованиями стандартов или требованиями, касающимися внутреннего мониторинга. В организации должен быть определен стандартный эталон времени.
Подходы организации к получению эталонного времени из внешних источников и надежной синхронизации внутренних часов должны быть задокументированы и реализованы.
Дополнительная информация
Правильная настройка компьютерных часов важна для обеспечения точности журналов аудита, которые могут потребоваться для проведения расследований или в качестве доказательств в юридических или дисциплинарных спорах. Неточные журналы аудита могут препятствовать проведению таких расследований и подрывать достоверность таких доказательств. В качестве эталонного времени в системах регистрации могут быть использованы сигналы точного времени, передаваемые по радио и синхронизированные с национальными центрами стандартов времени и частоты. Для синхронизации всех серверов с эталоном может использоваться протокол сетевого времени (NTP).
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).
12.4.2
12.4.2 Защита информации регистрационных журналов
Мера обеспечения ИБ
Средства регистрации и информация регистрационных журналов должны быть защищены от фальсификации и несанкционированного доступа.
Руководство по применению
Меры обеспечения ИБ должны быть направлены на защиту от несанкционированных изменений информации журнала и проблем, возникающих при эксплуатации средств регистрации, включая:
- a) изменение типов сообщений, которые были записаны;
- b) удаление или изменение журнала;
- c) превышение емкости хранилища файлов журнала, что приводит к невозможности записи событий или перезаписи информации о прошлых событиях.
Может потребоваться сохранять в архиве некоторые журналы аудита как часть политики хранения записей или вследствие наличия требований по сбору и хранению доказательств (см. 16.1.7).
Дополнительная информация
Системные журналы часто содержат большой объем информации, большая часть которой не имеет отношения к мониторингу событий безопасности. Чтобы помочь идентифицировать важные с точки зрения мониторинга ИБ события, следует рассмотреть возможность автоматического копирования записей соответствующего типа во второй журнал, либо использовать подходящие системные служебные программы или инструменты аудита, которые позволят систематизировать файлы журналов.
Системные журналы должны быть защищены, так как, если данные в них можно изменить или удалить, то существование таких журналов может создать ложное чувство безопасности. Копирование журналов в реальном времени в систему, находящуюся вне контроля системного администратора или оператора, может применяться как мера обеспечения безопасности.
12.4.3
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.
А.8.17
А.8.17 Clock synchronization
The clocks of information processing systems used by the organization shall be synchronized to approved time sources.
The clocks of information processing systems used by the organization shall be synchronized to approved time sources.
Положение Банка России № 716-П от 08.04.2022 "О требованиях к системе управления операционным риском в кредитной организации и банковской группе":
Глава 7. Пункт 7.
7.7. Кредитная организация (головная кредитная организация банковской группы) в целях управления риском информационной безопасности определяет во внутренних документах порядок функционирования системы информационной безопасности и обеспечивает его выполнение, в том числе:
- политику информационной безопасности;
- выявление и идентификацию риска информационной безопасности, а также его оценку;
- участие совета директоров (наблюдательного совета) и коллегиального исполнительного органа кредитной организации (головной кредитной организации банковской группы) в решении вопросов управления риском информационной безопасности;
- распределение функций и ответственности коллегиального исполнительного органа и работников кредитной организации (головной кредитной организации банковской группы), в том числе исключающее конфликт интересов в рамках организационной структуры обеспечения информационной безопасности, а также предполагающее определение должностного лица (лица, его замещающего), ответственного за функционирование системы обеспечения информационной безопасности (с прямым подчинением лицу, осуществляющему функции единоличного исполнительного органа кредитной организации (головной кредитной организации банковской группы) и не участвующего в совершении операций, сделок, организации бухгалтерского и управленческого учета, обеспечении функционирования информационных систем; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
- выявление событий риска информационной безопасности, включая рассмотрение обращений клиентов, контрагентов, работников и третьих лиц, связанных с нарушением информационной безопасности, выявление и регистрацию инцидентов защиты информации, выявление фактов компрометации объектов информационной инфраструктуры; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
- обеспечение осведомленности кредитной организации (головной кредитной организации банковской группы) и участников технологических процессов об актуальных угрозах безопасности информации, обмен информацией о событиях риска информационной безопасности, в том числе об инцидентах защиты информации, и представление данных в Банк России в соответствии с требованиями пункта 8 Положения Банка России N 683-П; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
- организацию ресурсного (кадрового и финансового) обеспечения, включая установление требований к квалификации работников кредитной организации (головной кредитной организации банковской группы), в том числе должностного лица (лица, его замещающего), ответственного за функционирование системы обеспечения информационной безопасности; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
- повышение осведомленности, обучение и развитие навыков работников кредитной организации (головной кредитной организации банковской группы) в области противодействия угрозам безопасности информации; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
- установление и реализацию программ контроля, в том числе программ аудита, включая независимую оценку соответствия уровня защиты информации в отношении объектов информационной инфраструктуры кредитной организации (головной кредитной организации банковской группы) в соответствии с требованиями пункта 9 Положения Банка России N 683-П; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
- проведение мониторинга риска информационной безопасности; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
- соответствие фактических значений контрольных показателей уровня риска информационной безопасности принятым в кредитной организации (головной кредитной организации банковской группы) значениям; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
- планирование, разработку, реализацию, контроль и совершенствование комплекса мероприятий, направленных на повышение эффективности управления риском информационной безопасности и уменьшение негативного влияния риска информационной безопасности, в том числе в соответствии с реализуемыми уровнями защиты информации в отношении объектов информационной инфраструктуры кредитной организации (головной кредитной организации банковской группы) в соответствии с требованиями подпункта 3.1 пункта 3 Положения Банка России N 683-П;(Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
- обеспечение защиты от угроз безопасности информации, включая обеспечение защиты информации, управление риском информационной безопасности при передаче третьим лицам (внешним подрядчикам, контрагентам, участникам банковской группы) выполнения отдельных функций кредитной организации (головной кредитной организации банковской группы) и (или) использовании внешних информационных систем в рамках реализации направлений деятельности, в том числе в разрезе составляющих их процессов, кредитной организации (головной кредитной организации банковской группы), управление риском несанкционированного доступа внутреннего нарушителя, являющегося работником кредитной организации (головной кредитной организации банковской группы) или третьим лицом, обладающими полномочиями по доступу к объектам информационной инфраструктуры кредитной организации (далее - внутренний нарушитель), предотвращение не контролируемого кредитной организацией (головной кредитной организацией банковской группы) распространения сведений, составляющих банковскую тайну, а также обеспечение операционной надежности; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
- порядок реагирования на выявленные события риска информационной безопасности, в том числе инциденты защиты информации, и восстановления деятельности кредитной организации (головной кредитной организации банковской группы) в случае реализации таких событий, включая порядок взаимодействия кредитной организации (головной кредитной организации банковской группы) с клиентами и третьими лицами, в том числе в случае получения уведомлений, связанных с осуществлением перевода денежных средств без согласия клиентов; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
- выполнение требований к обеспечению защиты информации при осуществлении банковской деятельности, связанной с осуществлением перевода денежных средств, в соответствии с пунктом 5 Положения Банка России N 683-П; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
- процессы применения прикладного программного обеспечения автоматизированных систем и приложений, соответствующих требованиям пункта 4 Положения Банка России N 683-П; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
- ежегодное тестирование на проникновение и анализ уязвимостей информационной безопасности объектов информационной инфраструктуры в соответствии с подпунктом 3.2 пункта 3 Положения Банка России N 683-П. (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.