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

ГОСТ Р № 57580.1-2017 от 01.01.2018

Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации

ЗСВ.33

Для проведения оценки соответствия по документу войдите в систему.

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

Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ЗСВ.3 ЗСВ.3 Регистрация событий безопасности в виртуальной инфраструктуре
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 11.5.2
11.5.2
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:
  • 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:
  • 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. 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 11.5.2
11.5.2
Определенные Требования к Подходу:
Механизм обнаружения изменений (например, средства мониторинга целостности файлов) развертывается следующим образом:
  • Для предупреждения персонала о несанкционированном изменении (включая изменения, добавления и удаления) важных файлов.
  • Для выполнения критических сравнений файлов не реже одного раза в неделю
Цель Индивидуального подхода:
Критически важные файлы не могут быть изменены неавторизованным персоналом без создания предупреждения.

Примечания по применению:
Для целей обнаружения изменений критическими файлами обычно являются те, которые регулярно не изменяются, но изменение которых может указывать на компрометацию системы или риск компрометации. Механизмы обнаружения изменений, такие как продукты мониторинга целостности файлов, обычно поставляются с предварительно настроенными критически важными файлами для соответствующей операционной системы. Другие важные файлы, например файлы для пользовательских приложений, должны быть оценены и определены организацией (то есть продавцом или поставщиком услуг).

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

Надлежащая практика:
Примеры типов файлов, которые следует отслеживать, включают, но не ограничиваются ими:
  • Системные исполняемые файлы.
  • Исполняемые файлы приложений.
  • Файлы конфигурации и параметров.
  • Централизованно хранимые, исторические или архивированные журналы аудита.
  • Дополнительные критические файлы, определенные организацией (например, с помощью оценки рисков или другими способами).
Примеры:
Решения для обнаружения изменений, такие как средства мониторинга целостности файлов (FIM), проверяют наличие изменений, дополнений и удалений в критически важных файлах и уведомляют об обнаружении таких изменений.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
ЗСВ.3 ЗСВ.3 Регистрация событий безопасности в виртуальной инфраструктуре
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
АУД.4 АУД.4 Регистрация событий безопасности
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
АУД.4 АУД.4 Регистрация событий безопасности

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

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