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

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

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

РД.28

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

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

Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ИАФ.3
ИАФ.3 Управление идентификаторами, в том числе создание, присвоение, уничтожение идентификаторов
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 8.2.4
8.2.4
Defined Approach Requirements: 
Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are managed as follows:
  • Authorized with the appropriate approval. 
  • Implemented with only the privileges specified on the documented approval. 
Customized Approach Objective:
Lifecycle events for user IDs and authentication factors cannot occur without appropriate authorization. 

Applicability Notes:
This requirement applies to all user accounts, including employees, contractors, consultants, temporary workers, and third-party vendors. 

Defined Approach Testing Procedures:
  • 8.2.4 Examine documented authorizations across various phases of the account lifecycle (additions, modifications, and deletions) and examine system settings to verify the activity has been managed in accordance with all elements specified in this requirement. 
Purpose:
It is imperative that the lifecycle of a user ID (additions, deletions, and modifications) is controlled so that only authorized accounts can perform functions, actions are auditable, and privileges are limited to only what is required. 
Attackers often compromise an existing account and then escalate the privileges of that account to perform unauthorized acts, or they may create new IDs to continue their activity in the background. It is essential to detect and respond when user accounts are created or changed outside the normal change process or without corresponding authorization. 
Requirement 8.3.11
8.3.11
Defined Approach Requirements: 
Where authentication factors such as physical or logical security tokens, smart cards, or certificates are used:
  • Factors are assigned to an individual user and not shared among multiple users. 
  • Physical and/or logical controls ensure only the intended user can use that factor to gain access. 
Customized Approach Objective:
An authentication factor cannot be used by anyone other than the user to which it is assigned. 

Defined Approach Testing Procedures:
  • 8.3.11.a Examine authentication policies and procedures to verify that procedures for using authentication factors such as physical security tokens, smart cards, and certificates are defined and include all elements specified in this requirement. 
  • 8.3.11.b Interview security personnel to verify authentication factors are assigned to an individual user and not shared among multiple users. 
  • 8.3.11.c Examine system configuration settings and/or observe physical controls, as applicable, to verify that controls are implemented to ensure only the intended user can use that factor to gain access. 
Purpose:
If multiple users can use authentication factors such as tokens, smart cards, and certificates, it may be impossible to identify the individual using the authentication mechanism. 

Good Practice:
Having physical and/or logical controls (for example, a PIN, biometric data, or a password) to uniquely authenticate the user of the account will prevent unauthorized users from gaining access to the user account through use of a shared authentication factor. 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 8.3.11
8.3.11
Определенные Требования к Подходу:
Где используются такие факторы аутентификации, как физические или логические маркеры безопасности, смарт-карты или сертификаты:
  • Факторы назначаются отдельному пользователю и не распределяются между несколькими пользователями.
  • Физические и / или логические элементы управления гарантируют, что только предполагаемый пользователь может использовать этот фактор для получения доступа.
Цель Индивидуального подхода:
Фактор аутентификации не может быть использован никем, кроме пользователя, которому он назначен.

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

Надлежащая практика:
Наличие физических и/или логических элементов управления (например, PIN-кода, биометрических данных или пароля) для уникальной аутентификации пользователя учетной записи предотвратит получение несанкционированными пользователями доступа к учетной записи пользователя с помощью общего фактора аутентификации.
Requirement 8.2.4
8.2.4
Определенные Требования к Подходу:
Добавление, удаление и изменение идентификаторов пользователей, факторов аутентификации и других объектов идентификаторов управляются следующим образом:
  • Авторизован с соответствующим утверждением.
  • Реализовано только с привилегиями, указанными в документированном утверждении.
Цель Индивидуального подхода:
События жизненного цикла для идентификаторов пользователей и факторов аутентификации не могут происходить без соответствующей авторизации.

Примечания по применению:
Это требование распространяется на все учетные записи пользователей, включая сотрудников, подрядчиков, консультантов, временных работников и сторонних поставщиков.

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

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

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

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