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

Framework № PCI DSS 4.0 от 01.03.2022

Payment Card Industry Data Security Standard (RU)

Requirement 11.5.2

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

Список требований

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

ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 9. Требования к защите информации на этапах жизненного цикла автоматизированных систем и приложений":
ЖЦ.23
ЖЦ.23 Регистрация операций по изменению параметров настроек технических мер системы защиты информации АС
3-О 2-Т 1-Т
ЖЦ.22
ЖЦ.22 Регистрация внесения изменений в АС, включая обновление прикладного ПО
3-Н 2-О 1-О
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 8. Требования к организации и управлению защитой информации":
КЗИ.11
КЗИ.11 Регистрация операций по изменению параметров настроек технических мер защиты информации и информационной инфраструктуры, предназначенных для размещения технических мер защиты информации
3-Н 2-Т 1-Т
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
ЗСВ.37
ЗСВ.37 Регистрация операций, связанных с изменением прав логического доступа к серверным компонентам виртуализации
3-Т 2-Т 1-Т
УЗП.27
УЗП.27 Регистрация событий защиты информации, связанных с действиями, и контроль действий эксплуатационного персонала, обладающего правами по изменению параметров настроек средств и систем защиты информации, параметров настроек АС, связанных с защитой информации
3-Н 2-Т 1-Т
СМЭ.21
СМЭ.21 Регистрация изменений параметров настроек средств и систем защиты информации, обеспечивающих реализацию сегментации, межсетевого экранирования и защиты вычислительных сетей финансовой организации
3-Т 2-Т 1-Т
ЗСВ.35
ЗСВ.35 Регистрация операций, связанных с созданием, изменением, копированием, удалением базовых образов виртуальных машин
3-Т 2-Т 1-Т
РД.43
РД.43 Регистрация изменений аутентификационных данных, используемых для осуществления логического доступа
3-Н 2-Т 1-Т
ЗСВ.42
ЗСВ.42 Регистрация операций, связанных с изменением параметров настроек технических мер защиты информации, используемых для реализации контроля доступа к серверным компонентам виртуализации
3-Т 2-Т 1-Т
ЗБС.10
ЗБС.10 Регистрация изменений параметров настроек средств и систем защиты информации, обеспечивающих реализацию сегментации, межсетевого экранирования и защиты внутренних вычислительных сетей финансовой организации и сегментов вычисленных сетей, выделенных в соответствии с мерой ЗБС.3 таблицы 20
3-Н 2-Т 1-Т
ЗСВ.38
ЗСВ.38 Регистрация операций, связанных с изменением параметров настроек серверных компонентов виртуализации
3-Т 2-Т 1-Т
ЗСВ.33
ЗСВ.33 Регистрация операций, связанных с изменением параметров настроек виртуальных сетевых сегментов, реализованных средствами гипервизора
3-Н 2-Т 1-Т
ЗСВ.43
ЗСВ.43 Регистрация операций, связанных с изменением настроек технических мер защиты информации, используемых для обеспечения защиты виртуальных машин
3-Т 2-Т 1-Т
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ОЦЛ.1 ОЦЛ.1 Контроль целостности программного обеспечения, включая программное обеспечение средств защиты информации
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. 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.12.4.1
A.12.4.1 Регистрация событий 
Мера обеспечения информационной безопасности: Требуется обеспечивать формирование, ведение и регулярный анализ регистрационных журналов, фиксирующих действия пользователей, нештатные ситуации, ошибки и события информационной безопасности 
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 14.9 CSC 14.9 Enforce Detail Logging for Access or Changes to Sensitive Data
Enforce detailed audit logging for access to sensitive data or changes to sensitive data (utilizing tools such as File Integrity Monitoring or Security Information and Event Monitoring).
CSC 5.3 CSC 5.3 Securely Store Master Images
Store the master images and templates on securely configured servers, validated with integrity monitoring tools, to ensure that only authorized changes to the images are possible.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
ОЦЛ.1 ОЦЛ.1 Контроль целостности программного обеспечения, включая программное обеспечение средств защиты информации
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.15
А.8.15 Логирование
Должны создаваться, храниться, защищаться и анализироваться журналы, в которых фиксируются деятельность, исключения, сбои и другие релевантные события.
SWIFT Customer Security Controls Framework v2022:
6 - 6.3 Database Integrity
6.3 Database Integrity
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
УКФ.4 УКФ.4 Контроль действий по внесению изменений
ОЦЛ.2 ОЦЛ.2 Контроль целостности информации
ОЦЛ.1 ОЦЛ.1 Контроль целостности программного обеспечения
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
УКФ.4 УКФ.4 Контроль действий по внесению изменений
ОЦЛ.2 ОЦЛ.2 Контроль целостности информации
ОЦЛ.0 ОЦЛ.0 Регламентация правил и процедур обеспечения целостности
ОЦЛ.1 ОЦЛ.1 Контроль целостности программного обеспечения
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
12.4.1
12.4.1 Регистрация событий

Мера обеспечения ИБ
Требуется обеспечивать формирование, ведение и регулярный анализ регистрационных журналов, фиксирующих действия пользователей, нештатные ситуации, ошибки и события безопасности.

Руководство по применению
Журналы событий, где это применимо, должны включать в себя:
  • a) пользовательские идентификаторы;
  • b) действия в системе;
  • c) дату, время и детали ключевых событий, например вход и выход из системы;
  • d) идентификатор устройства или местоположения, если возможно, и системный идентификатор;
  • e) записи об успешных и отклоненных попытках доступа к системе;
  • f) записи об успешных или отклоненных попытках доступа к данным и иным ресурсам;
  • g) изменения конфигурации системы;
  • h) использование привилегий;
  • i) использование системных служебных программ и приложений;
  • j) файлы, к которым был запрошен доступ, а также вид доступа;
  • k) сетевые адреса и протоколы;
  • l) сигналы тревоги от системы контроля управления доступом;
  • m) события активации и деактивации систем защиты, таких как антивирусные средства и системы обнаружения вторжений;
  • n) записи транзакций, выполненных пользователями в приложениях.
Ведение журнала событий служит основой для автоматизированных систем мониторинга, которые способны генерировать консолидированные отчеты и оповещения о безопасности системы.

Дополнительная информация
Журналы событий могут содержать информацию ограниченного доступа. Для обеспечения конфиденциальности должны быть приняты соответствующие меры защиты (см. 18.1.4).
Там, где это возможно, системные администраторы не должны иметь прав на удаление или деактивацию журналирования собственных действий (см. 12.4.3).
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.8.15
А.8.15 Logging
Logs that record activities, exceptions, faults and other relevant events shall be produced, stored, protected and analysed.

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

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

Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.