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

SWIFT Customer Security Controls Framework v2022

Framework

6 - 6.4 Logging and Monitoring

Для проведения оценки соответствия по документу войдите в систему.
6.4 Logging and Monitoring
Обязательно для типа архитектуры A1 A2 A3 A4 B
Область требования: Коннектор SWIFT | Уровень обмена данными SWIFT | Универсальный компьютер оператора SWIFT | Графический пользовательский интерфейс SWIFT | Выделенный компьютер оператора SWIFT | Промежуточный сервер SWIFT
Control Definition 

Control Objective: Record security events and detect anomalous actions and operations within the local SWIFT environment. 

In-scope components: 
  • Data exchange layer: network 
  • Operating system of a dedicated and general-purpose operator PC 
  • jump server 
  • SWIFT-related components (including interfaces, GUI, SWIFT and customer connectors) 
  • systems or virtual machines hosting SWIFT-related components 
  • network devices protecting the secure zone and HSM 
  • database linked to a messaging interface or a customer connector 
  • authentication or authorisation servers, or both, controlling accesses to the secure zone 
  • Local or remote (hosted or operated by a third party, or both) Virtualisation platform (also referred to as the hypervisor) hosting SWIFT-related VMs 
  • [Advisory A1/A2/A3: Middleware server (such as IBM® MQ server or similar) used for data exchange between back-office and SWIFT-related components] 
  • [Advisory A4: other Middleware server (such as an IBM® MQ server or similar) than customer connector used for data exchange between back-office and SWIFT-related components] 
Risk Drivers: 
  • lack of traceability 
  • undetected anomalies or suspicious activity 
Implementation Guidance 

Control Statement: 
Capabilities to detect anomalous activity are implemented, and a process or tool is in place to keep and review logs. 

Control Context: 
Developing a logging and monitoring plan is the basis for effectively detecting abnormal behaviour and potential attacks and support further investigations. As the operational environment becomes more complex, so will the logging and monitoring capability needed to perform adequate detection. Simplifying the operational environment will enable simpler logging and monitoring. 

Implementation Guidelines: 
The implementation guidelines are common methods to apply the relevant control. The guidelines are a helpful way to begin an assessment, but should never be considered as an "audit checklist" as each user’s implementation may vary. Therefore, in cases where some implementation guidelines elements are not present or partially covered, mitigations as well as particular environment specificities must be considered to properly assess the overall compliance adherence level (as per the suggested guidelines 
or as per the alternatives). 
  • Overall goals for logging and monitoring: 
    • Implement a plan to log security-relevant activities and configure alarms for suspicious security events (when supported by the application).
    • Implement a plan to monitor security events in logs and to monitor other data (for example, real-time business activities through the GUI), and establish a plan to treat reported alarms. 
    • Support investigations and forensics in case of potential breach through log retention, in line with applicable laws and regulations. 
  • • Logging: 
    • Logging capabilities are implemented to detect and support analysis of abnormal usage within the secure zone and any attempts to undermine the effectiveness of controls within the secure zone.
    • Logs provide traceability of account usage to the appropriate individual. 
    • Minimum logs to be recorded include: 
      • Command-line history for privileged operating system accounts on servers 
      • Messaging and communication interface application and operating system logs which detail abnormal system behaviour (for example, activity outside normal business hours, multiple failed login attempts, authentication errors, changes to user groups) 
      • Firewall logs 
      • Database logs (if available, and as a minimum in the case of hosted database solutions). 
  • Monitoring: 
    • Procedures are in place to identify suspicious login activities into any privileged operating system or application accounts within the secure zone. 
    • Monitoring processes are in place to review server, application, and database monitoring data of the secure zone either daily through human review or through automated monitoring with alerting. 
    • Monitoring processes are in place to review network-monitoring data on a regular basis. 
    • Unusual or suspicious activity is reported for further investigation to the appropriate security team. 
  • Log retention: 
    • All logging and monitoring activities comply with applicable laws, regulations, and employment contracts which supersede other implementation guidance. 
    • Messaging and communication interface application audit logs are retained for no less than 12 months and are sufficiently protected from an enterprise administrator-level compromise (for example, log files are transferred to a separate system with different system administrator credentials). 
    • Operator PC, firewall, and database audit logs are retained for no less than 31 days (it is recommended to extend firewall and database audit logs retention to three months and possibly 12 months to support longer investigations). 
    • Audit logs captured on other identified in-scope components, at application level or system level, are retained for no less than 12 months. 
    • Prevent audit log loss by considering a range of configurable choices when log storage is to be exhausted. As examples, such choices can include log rotation, degraded mode or ignoring some events. 
Optional Enhancements: 
  • A centralised logging capability is implemented, minimising the number of log locations to be inspected. 
  • Session recording is implemented to record all activity conducted by privileged accounts on SWIFT secure zone servers.

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

ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 8. Требования к организации и управлению защитой информации":
КЗИ.12
КЗИ.12 Регистрация сбоев (отказов) технических мер защиты информации
Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 7 п. 4 п.п. 4
7.4.4. В организации БС РФ должны быть определены, выполняться, регистрироваться и контролироваться правила и процедуры мониторинга ИБ, анализа и хранения данных о действиях и операциях, позволяющие выявлять неправомерные или подозрительные операции и транзакции, для чего, среди прочего, следует:
  • определить действия и операции, подлежащие регистрации;
  • определить состав и содержание данных о действиях и операциях, подлежащих регистрации, сроки их хранения;
  • обеспечить резервирование необходимого объема памяти для записи данных;
  • обеспечить реагирование на сбои при регистрации действий и операций, в том числе аппаратные и программные ошибки, сбои в технических средствах сбора данных;
  • обеспечить генерацию временных меток для регистрируемых действий и операций и синхронизацию системного времени на технических средствах, используемых для целей мониторинга ИБ, анализа и хранения данных.
В организации БС РФ должно быть реализовано ведение журналов действия и операций автоматизированных рабочих мест, серверного и сетевого оборудования, межсетевых экранов и АБС с целью их использования при реагировании на инциденты ИБ.
Рекомендуется обеспечить хранение данных о действиях и операциях не менее трех лет, а для данных, полученных в результате выполнения банковского платежного технологического процесса, - не менее пяти лет, если иные сроки хранения не установлены законодательством РФ, нормативными актами Банка России.
Для проведения процедур мониторинга ИБ и анализа данных о действиях и операциях следует использовать специализированные программные и (или) технические средства.
Процедуры мониторинга ИБ и анализа данных о действиях и операциях должны использовать зафиксированные критерии выявления неправомерных или подозрительных действий и операций. Указанные процедуры мониторинга ИБ и анализа должны применяться на регулярной основе, например ежедневно, ко всем выполненным действиям и операциям (транзакциям).
Р. 8 п. 12 п.п. 2
8.12.2. Должны быть определены, выполняться, регистрироваться и контролироваться процедуры сбора и хранения информации о действиях работников организации БС РФ, событиях и параметрах, имеющих отношение к функционированию защитных мер. 
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
МАС.5
МАС.5 Организация мониторинга данных регистрации о событиях защиты информации, формируемых АС и приложениями
РИ.1
РИ.1 Регистрация информации о событиях защиты информации, потенциально связанных с инцидентами защиты информации, в том числе НСД, выявленными в рамках мониторинга и анализа событий защиты информации
МАС.6
МАС.6 Организация мониторинга данных регистрации о событиях защиты информации, формируемых контроллерами доменов
УЗП.28
УЗП.28 Регистрация событий защиты информации, связанных с действиями, и контроль действий эксплуатационного персонала, обладающего правами по управлению криптографическими ключами
МАС.4
МАС.4 Организация мониторинга данных регистрации о событиях защиты информации, формируемых системным ПО, операционными системами, СУБД
NIST Cybersecurity Framework (RU):
PR.PT-1
PR.PT-1: В соответствии с политикой определяются, документируются, внедряются и проверяются записи аудита / журналов событий 
DE.AE-2
DE.AE-2: Обнаруженные события анализируются для определения целей и методов атаки 
RS.AN-1
RS.AN-1: Исследуются уведомления от систем обнаружения 
DE.CM-1
DE.CM-1: Сеть контролируется для обнаружения потенциальных событий кибербезопасности 
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
РСБ.3 РСБ.3 Сбор, запись и хранение информации о событиях безопасности в течение установленного времени хранения
ЗСВ.3 ЗСВ.3 Регистрация событий безопасности в виртуальной инфраструктуре
РСБ.5 РСБ.5 Мониторинг (просмотр, анализ) результатов регистрации событий безопасности и реагирование на них
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 10.4.1
10.4.1
Defined Approach Requirements: 
The following audit logs are reviewed at least once daily:
  • All security events.
  • Logs of all system components that store, process, or transmit CHD and/or SAD.
  • Logs of all critical system components.
  • Logs of all servers and system components that perform security functions (for example, network security controls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers). 
Customized Approach Objective:
Potentially suspicious or anomalous activities are quickly identified to minimize impact. 

Defined Approach Testing Procedures:
  • 10.4.1.a Examine security policies and procedures to verify that processes are defined for reviewing all elements specified in this requirement at least once daily. 
  • 10.4.1.b Observe processes and interview personnel to verify that all elements specified in this requirement are reviewed at least once daily 
Purpose:
Many breaches occur months before being detected. Regular log reviews mean incidents can be quickly identified and proactively addressed. 

Good Practice:
Checking logs daily (7 days a week, 365 days a year, including holidays) minimizes the amount of time and exposure of a potential breach. Log harvesting, parsing, and alerting tools, centralized log management systems, event log analyzers, and security information and event management (SIEM) solutions are examples of automated tools that can be used to meet this requirement. 
Daily review of security events—for example, notifications or alerts that identify suspicious or anomalous activities—as well as logs from critical system components, and logs from systems that perform security functions, such as firewalls, IDS/IPS, file integrity monitoring (FIM) systems, etc., is necessary to identify potential issues. 
The determination of “security event” will vary for each organization and may include consideration for the type of technology, location, and function of the device. Organizations may also wish to maintain a baseline of “normal” traffic to help identify anomalous behavior. 
An entity that uses third-party service providers to perform log review services is responsible to provide context about the entity’s environment to the service providers, so it understands the entity’s environment, has a baseline of “normal” traffic for the entity, and can detect potential security issues and provide accurate exceptions and anomaly notifications. 
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):
8 STRENGTHENED
/STRENGTHENED 
As soon as possible, the logging linked to accounts (e.g.: list of successful/ failed connections) must be activated. 
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 Регистрация событий 
Мера обеспечения информационной безопасности: Требуется обеспечивать формирование, ведение и регулярный анализ регистрационных журналов, фиксирующих действия пользователей, нештатные ситуации, ошибки и события информационной безопасности 
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 6.7 CSC 6.7 Regularly Review Logs
On a regular basis, review logs to identify anomalies or abnormal events.
Положение Банка России № 802-П от 25.07.2022 "О требованиях к защите информации в платежной системе Банка России":
П. 16.1
16.1. Участник СБП - банк плательщика должен осуществлять:
  • выявление операций, соответствующих признакам осуществления переводов денежных средств без согласия клиента, установленным Банком России в соответствии с частью 5.1 статьи 8 Федерального закона от 27 июня 2011 года N 161-ФЗ (далее - признаки осуществления переводов денежных средств без согласия клиента), в рамках реализуемой им системы управления рисками при осуществлении переводов денежных средств с использованием сервиса быстрых платежей;
  • приостановление в соответствии с частью 5.1 статьи 8 Федерального закона от 27 июня 2011 года N 161-ФЗ исполнения распоряжения в рамках выявленной операции, соответствующей признакам осуществления переводов денежных средств без согласия клиента, с учетом информации об уровне риска операции без согласия клиента (далее - индикатор уровня риска операции), включенной в электронное сообщение, полученной от ОПКЦ СБП в формате и порядке, установленных договором об оказании услуг между участником СБП и ОПКЦ СБП, содержащей в том числе информацию об индикаторе уровня риска операции, сформированном участником СБП - банком получателя;
  • формирование индикатора уровня риска операции на основе оценки рисков операций в рамках реализуемой участником СБП - банком плательщика системы управления рисками и его направление в электронном сообщении в ОПКЦ СБП в формате и порядке, установленных договором об оказании услуг между участником СБП и ОПКЦ СБП, - в случае невыявления признаков осуществления перевода денежных средств без согласия клиента.
П. 16.3
16.3. ОПКЦ СБП должен осуществлять:
  • выявление операций, соответствующих признакам осуществления переводов денежных средств без согласия клиента, на основании моделей оценки риска операций по переводу денежных средств (далее - модели оценки риска операций Банка России), установленных в соответствии с договором о взаимодействии, заключаемым между Банком России и оператором внешней платежной системы в соответствии с частью 37 статьи 15 Федерального закона от 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), а также обеспечивают отслеживание истории для расследования после инцидента.
Ведение журнала и анализ событий, связанных с безопасностью, позволяют организации выявлять и отслеживать потенциально вредоносные действия.

Надлежащая практика:
Когда организация решает, какую информацию записывать в свои журналы, важно помнить, что информация, хранящаяся в журналах аудита, является конфиденциальной и должна быть защищена в соответствии с требованиями настоящего стандарта. Следует позаботиться о том, чтобы в журналах аудита сохранялась только важная информация, чтобы свести к минимуму риск.
Requirement 10.4.1
10.4.1
Определенные Требования к Подходу:
Следующие журналы аудита просматриваются не реже одного раза в день:
  • Все мероприятия по обеспечению безопасности.
  • Журналы всех системных компонентов, которые хранят, обрабатывают или передают CHD и/или SAD.
  • Журналы всех критически важных компонентов системы.
  • Журналы всех серверов и системных компонентов, выполняющих функции безопасности (например, средства управления сетевой безопасностью, системы обнаружения вторжений/системы предотвращения вторжений (IDS/IPS), серверы аутентификации).
Цель Индивидуального подхода:
Потенциально подозрительные или аномальные действия быстро выявляются, чтобы свести к минимуму воздействие.

Определенные Процедуры Тестирования Подхода:
  • 10.4.1.a Изучайте политики и процедуры безопасности, чтобы убедиться, что определены процессы для проверки всех элементов, указанных в этом требовании, по крайней мере, один раз в день.
  • 10.4.1.b Наблюдайте за процессами и проводите собеседования с персоналом, чтобы убедиться, что все элементы, указанные в этом требовании, проверяются не реже одного раза в день
Цель:
Многие нарушения происходят за месяцы до их обнаружения. Регулярные проверки журналов позволяют быстро выявлять инциденты и оперативно устранять их.

Надлежащая практика:
Ежедневная проверка журналов (7 дней в неделю, 365 дней в году, включая праздничные дни) сводит к минимуму количество времени и вероятность потенциального нарушения. Средства сбора, анализа и оповещения журналов, централизованные системы управления журналами, анализаторы журналов событий и решения для управления информацией о безопасности и событиями (SIEM) являются примерами автоматизированных инструментов, которые можно использовать для удовлетворения этого требования.
Ежедневный просмотр событий безопасности — например, уведомлений или предупреждений, которые идентифицируют подозрительные или аномальные действия, — а также журналов критически важных системных компонентов и журналов систем, выполняющих функции безопасности, таких как брандмауэры, идентификаторы/IP-адреса, системы мониторинга целостности файлов (FIM) и т.д., необходим для выявления потенциальные проблемы.
Определение “события безопасности” будет отличаться для каждой организации и может включать в себя рассмотрение типа технологии, местоположения и функции устройства. Организации могут также пожелать поддерживать базовый уровень “нормального” трафика, чтобы помочь выявить аномальное поведение.
Объект, который использует сторонних поставщиков услуг для выполнения служб просмотра журналов, отвечает за предоставление поставщикам услуг контекста среды объекта, чтобы он понимал среду объекта, имел базовый уровень “нормального” трафика для объекта и мог обнаруживать потенциальные проблемы безопасности и предоставлять точные исключения и уведомления об аномалиях.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
РСБ.3 РСБ.3 Сбор, запись и хранение информации о событиях безопасности в течении установленного времени хранения
ЗСВ.3 ЗСВ.3 Регистрация событий безопасности в виртуальной инфраструктуре
РСБ.5 РСБ.5 Мониторинг (просмотр, анализ) результатов регистрации событий безопасности и реагирование на них
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
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.15
А.8.15 Логирование
Должны создаваться, храниться, защищаться и анализироваться журналы, в которых фиксируются деятельность, исключения, сбои и другие релевантные события.
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
АУД.4 АУД.4 Регистрация событий безопасности
АУД.7 АУД.7 Мониторинг безопасности
NIST Cybersecurity Framework (EN):
PR.PT-1 PR.PT-1: Audit/log records are determined, documented, implemented, and reviewed in accordance with policy
DE.AE-2 DE.AE-2: Detected events are analyzed to understand attack targets and methods
RS.AN-1 RS.AN-1: Notifications from detection systems are investigated 
Стандарт Банка России № РС БР ИББС-2.5-2014 от 01.06.2014 "Менеджмент инцидентов информационной безопасности":
Р. 6 п. 5 п.п. 2
6.5.2. Средства мониторинга ИБ и контроля защитных мер должны выполнять следующие основные функции: 
  • отслеживание и регистрацию событий ИБ в целях обнаружения инцидентов ИБ;
  • агрегирование полученной информации о событиях ИБ, корреляцию информации о событиях ИБ, обнаружение инцидентов ИБ на основе установленных в организации БС РФ критериев и правил;
  • текущий контроль функционирования применяемых средств защиты информации и обнаружение отклонений в их работе от штатного режима;
  • текущий контроль действий пользователей и эксплуатирующего персонала и обнаружение нарушений в эксплуатации технических средств. 
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
АУД.4 АУД.4 Регистрация событий безопасности
АУД.7 АУД.7 Мониторинг безопасности
Стандарт № 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.

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

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