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

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 
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. 
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. 
8.9
8.9 Centralize Audit Logs
Centralize, to the extent possible, audit log collection and retention across enterprise assets. 
NIST Cybersecurity Framework (RU):
PR.PT-1
PR.PT-1: В соответствии с политикой определяются, документируются, внедряются и проверяются записи аудита / журналов событий 
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
РСБ.5 РСБ.5 Мониторинг (просмотр, анализ) результатов регистрации событий безопасности и реагирование на них
РСБ.2 РСБ.2 Определение состава и содержания информации о событиях безопасности, подлежащих регистрации
РСБ.3 РСБ.3 Сбор, запись и хранение информации о событиях безопасности в течение установленного времени хранения
РСБ.1 РСБ.1 Определение событий безопасности, подлежащих регистрации, и сроков их хранения
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:
  • 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. 
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:
  • 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. 
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:
  • 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. 
Requirement 10.2.1
10.2.1
Defined Approach Requirements: 
Audit logs are enabled and active for all system components and cardholder data. 

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

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

Good Practice:
When an entity considers which information to record in their logs, it is important to remember that information stored in audit logs is sensitive and should be protected per requirements in this standard. Care should be taken to only store essential information in the audit logs to minimize risk.
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:
  • 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.
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.
CSC 6.7 CSC 6.7 Regularly Review Logs
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.
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.2.a Изучите политики и процедуры безопасности, чтобы убедиться, что определены процессы для периодического просмотра журналов всех других компонентов системы.
  • 10.4.2.b Изучите документированные результаты проверок журналов и опросите персонал, чтобы убедиться, что проверки журналов выполняются периодически.
Цель:
Периодический просмотр журналов для всех других компонентов системы (не указанных в требовании 10.4.1) помогает выявить признаки потенциальных проблем или попыток доступа к критическим системам через менее критичные системы.
Requirement 10.2.1
10.2.1
Определенные Требования к Подходу:
Журналы аудита включены и активны для всех компонентов системы и данных о держателях карт.

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

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

Надлежащая практика:
Когда организация решает, какую информацию записывать в свои журналы, важно помнить, что информация, хранящаяся в журналах аудита, является конфиденциальной и должна быть защищена в соответствии с требованиями настоящего стандарта. Следует позаботиться о том, чтобы в журналах аудита сохранялась только важная информация, чтобы свести к минимуму риск.
Requirement 10.2.1.1
10.2.1.1
Определенные Требования к Подходу:
Журналы аудита фиксируют весь индивидуальный доступ пользователей к данным о держателях карт.

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

Определенные Процедуры Тестирования Подхода:
  • 10.2.1.1 Проверьте конфигурации журнала аудита и данные журнала, чтобы убедиться, что весь индивидуальный доступ пользователя к данным о держателях карт регистрируется.
Цель:
Крайне важно иметь процесс или систему, которые связывают доступ пользователя с доступом к системным компонентам. Злоумышленники могут получить информацию об учетной записи пользователя, имеющей доступ к системам в CDE, или они могут создать новую несанкционированную учетную запись для доступа к данным о держателях карт.

Надлежащая практика:
Запись всего индивидуального доступа к данным о держателях карт позволяет определить, какие учетные записи могли быть скомпрометированы или использованы не по назначению.
Requirement 5.3.4
5.3.4
Определенные Требования к Подходу:
Журналы аудита для решения (решений) для защиты от вредоносных программ включены и сохраняются в соответствии с требованием 10.5.1.

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

Определенные Процедуры Тестирования Подхода:
  • 5.3.4 Проверьте конфигурации решений для защиты от вредоносных программ, чтобы убедиться, что журналы включены и сохраняются в соответствии с требованием 10.5.1.
Цель:
Важно отслеживать эффективность механизмов защиты от вредоносных программ - например, путем подтверждения того, что обновления и проверки выполняются должным образом, а вредоносное ПО идентифицировано и устранено. Журналы аудита также позволяют организации определять, как вредоносное ПО проникло в среду, и отслеживать его активность внутри сети организации.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
РСБ.5 РСБ.5 Мониторинг (просмотр, анализ) результатов регистрации событий безопасности и реагирование на них
РСБ.2 РСБ.2 Определение состава и содержания информации о событиях безопасности, подлежащих регистрации
РСБ.3 РСБ.3 Сбор, запись и хранение информации о событиях безопасности в течении установленного времени хранения
РСБ.1 РСБ.1 Определение событий безопасности, подлежащих регистрации, и сроков их хранения
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 Регистрация событий безопасности

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

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