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

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

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

ЗСВ.39

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

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

Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ЗСВ.3 ЗСВ.3 Регистрация событий безопасности в виртуальной инфраструктуре
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 10.2.1.4
10.2.1.4
Defined Approach Requirements: 
Audit logs capture all invalid logical access attempts. 

Customized Approach Objective:
Records of all invalid access attempts are captured 

Defined Approach Testing Procedures:
  • 10.2.1.4 Examine audit log configurations and log data to verify that invalid logical access attempts are captured. 
Purpose:
Malicious individuals will often perform multiple access attempts on targeted systems. Multiple invalid login attempts may be an indication of an unauthorized user’s attempts to “brute force” or guess a password. 
Requirement 9.2.4
9.2.4
Defined Approach Requirements: 
Access to consoles in sensitive areas is restricted via locking when not in use. 

Customized Approach Objective:
Physical consoles within sensitive areas cannot be used by unauthorized personnel. 

Defined Approach Testing Procedures:
  • 9.2.4 Observe a system administrator’s attempt to log into consoles in sensitive areas and verify that they are “locked” to prevent unauthorized use. 
Purpose:
Locking console login screens prevents unauthorized persons from gaining access to sensitive information, altering system configurations, introducing vulnerabilities into the network, or destroying records. 
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.3
A.12.4.3 Регистрационные журналы действий администратора и оператора 
Мера обеспечения информационной безопасности: Действия системного администратора и оператора системы следует регистрировать, а регистрационные журналы защищать и регулярно анализировать 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 9.2.4
9.2.4
Определенные Требования к Подходу:
Доступ к консолям в критических зонах ограничен блокировкой, когда они не используются.

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

Определенные Процедуры Тестирования Подхода:
  • 9.2.4 Наблюдайте за попытками системного администратора войти в консоли в конфиденциальных областях и убедитесь, что они “заблокированы” для предотвращения несанкционированного использования.
Цель:
Блокировка экранов входа в консоль предотвращает несанкционированный доступ посторонних лиц к конфиденциальной информации, изменение системных конфигураций, внедрение уязвимостей в сеть или уничтожение записей.
Requirement 10.2.1.4
10.2.1.4
Определенные Требования к Подходу:
Журналы аудита фиксируют все недопустимые попытки логического доступа.

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

Определенные Процедуры Тестирования Подхода:
  • 10.2.1.4 Проверьте конфигурации журнала аудита и данные журнала, чтобы убедиться, что зафиксированы недопустимые попытки логического доступа.
Цель:
Злоумышленники часто совершают многократные попытки доступа к целевым системам. Множественные неудачные попытки входа в систему могут указывать на попытки неавторизованного пользователя “перебрать” или угадать пароль.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
ЗСВ.3 ЗСВ.3 Регистрация событий безопасности в виртуальной инфраструктуре
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
АУД.4 АУД.4 Регистрация событий безопасности
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
АУД.4 АУД.4 Регистрация событий безопасности
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
12.4.3
12.4.3 Регистрационные журналы действий администратора и оператора

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

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

Дополнительная информация
Система обнаружения вторжений, находящаяся вне контроля системных и сетевых администраторов, может быть использована для мониторинга их действий на предмет соответствия.

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

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

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