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

ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022

Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А

A.9.2.4

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

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

ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
РД.40
РД.40 Регистрация осуществления субъектами логического доступа идентификации и аутентификации
3-Т 2-Т 1-Т
NIST Cybersecurity Framework (RU):
PR.AC-1
PR.AC-1: Для авторизованных устройств, пользователей и процессов выдаются, управляются, верифицируются, аннулируются и проверяются идентификационные и учетные данные
PR.AC-7
PR.AC-7: Пользователи, устройства и другие активы проходят аутентификацию (например, однофакторную, многофакторную), соизмеримую с риском транзакции (например, рисками безопасности и конфиденциальности отдельных лиц и другими организационными рисками)
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ИАФ.4 ИАФ.4 Управление средствами аутентификации, в том числе хранение, выдача, инициализация, блокирование средств аутентификации и принятие мер в случае утраты и (или) компрометации средств аутентификации
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 8.6.1
8.6.1
Defined Approach Requirements: 
If accounts used by systems or applications can be used for interactive login, they are managed as follows: 
  • Interactive use is prevented unless needed for an exceptional circumstance.
  • Interactive use is limited to the time needed for the exceptional circumstance. 
  • Business justification for interactive use is documented.
  • Interactive use is explicitly approved by management. 
  • Individual user identity is confirmed before access to account is granted.
  • Every action taken is attributable to an individual user. 
Customized Approach Objective:
When used interactively, all actions with accounts designated as system or application accounts are authorized and attributable to an individual person. 

Applicability Notes:
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:
  • 8.6.1 Examine application and system accounts that can be used interactively and interview administrative personnel to verify that application and system accounts are managed in accordance with all elements specified in this requirement. 
Purpose:
Like individual user accounts, system and application accounts require accountability and strict management to ensure they are used only for the intended purpose and are not misused. 
Attackers often compromise system or application accounts to gain access to cardholder data. 

Good Practice:
Where possible, configure system and application accounts to disallow interactive login to prevent unauthorized individuals from logging in and using the account with its associated system privileges, and to limit the machines and devices on which the account can be used. 

Definitions:
System or application accounts are those accounts that execute processes or perform tasks on a computer system or application and are not typically accounts that an individual logs into. These accounts usually have elevated privileges that are required to perform specialized tasks or functions. 
Interactive login is the ability for a person to log into a system or application account in the same manner as a normal user account. Using system and application accounts this way means there is no accountability and traceability of actions taken by the user. 
Requirement 7.2.3
7.2.3
Defined Approach Requirements: 
Required privileges are approved by authorized personnel 

Customized Approach Objective:
Access privileges cannot be granted to users without appropriate, documented authorization. 

Defined Approach Testing Procedures:
  • 7.2.3.a Examine policies and procedures to verify they define processes for approval of all privileges by authorized personnel. 
  • 7.2.3.b Examine user IDs and assigned privileges, and compare with documented approvals to verify that: 
    • Documented approval exists for the assigned privileges. 
    • The approval was by authorized personnel. 
    • Specified privileges match the roles assigned to the individual. 
Purpose:
Documented approval (for example, in writing or electronically) assures that those with access and privileges are known and authorized by management, and that their access is necessary for their job function. 
Requirement 3.5.1.3
3.5.1.3
Defined Approach Requirements: 
If disk-level or partition-level encryption is used (rather than file-, column-, or field--level database encryption) to render PAN unreadable, it is managed as follows:
  • Logical access is managed separately and independently of native operating system authentication and access control mechanisms.
  • Decryption keys are not associated with user accounts.
  • Authentication factors (passwords, passphrases, or cryptographic keys) that allow access to unencrypted data are stored securely 
Customized Approach Objective:
Disk encryption implementations are configured to require independent authentication and logical access controls for decryption. 

Applicability Notes:
Disk or partition encryption implementations must also meet all other PCI DSS encryption and keymanagement requirements. 

Defined Approach Testing Procedures:
  • 3.5.1.3.a If disk-level or partition-level encryption is used to render PAN unreadable, examine the system configuration and observe the authentication process to verify that logical access is implemented in accordance with all elements specified in this requirement. 
  • 3.5.1.3.b Examine files containing authentication factors (passwords, passphrases, or cryptographic keys) and interview personnel to verify that authentication factors that allow access to unencrypted data are stored securely and are independent from the native operating system’s authentication and access control methods. 
Purpose:
Disk-level encryption typically encrypts the entire disk or partition using the same key, with all data automatically decrypted when the system runs or when an authorized user requests it. Many diskencryption solutions intercept operating system read/write operations and perform the appropriate cryptographic transformations without any special action by the user other than supplying a password or passphrase at system start-up or at the beginning of a session. This provides no protection from a malicious individual that has already managed to gain access to a valid user account. 

Good Practice:
Full disk encryption helps to protect data in the event of physical loss of a disk and therefore its use is best limited only to removable electronic media storage devices. 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 8.6.1
8.6.1
Определенные Требования к Подходу:
Если учетные записи, используемые системами или приложениями, могут использоваться для интерактивного входа в систему, управление ими осуществляется следующим образом:
  • Интерактивное использование запрещено, за исключением случаев, когда это необходимо в исключительных обстоятельствах.
  • Интерактивное использование ограничено временем, необходимым для исключительных обстоятельств.
  • Бизнес-обоснование интерактивного использования задокументировано.
  • Интерактивное использование явно одобрено руководством.
  • Индивидуальная идентификация пользователя подтверждается до предоставления доступа к учетной записи.
  • Каждое предпринятое действие относится к отдельному пользователю.
Цель Индивидуального подхода:
При интерактивном использовании все действия с учетными записями, обозначенными как учетные записи системы или приложения, разрешены и относятся к отдельному лицу.

Примечания по применению:
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:
  • 8.6.1 Изучите учетные записи приложений и систем, которые можно использовать в интерактивном режиме, и опросите административный персонал, чтобы убедиться, что управление учетными записями приложений и систем осуществляется в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Как и учетные записи отдельных пользователей, учетные записи системы и приложений требуют подотчетности и строгого управления, чтобы гарантировать, что они используются только по назначению и не используются не по назначению.
Злоумышленники часто компрометируют учетные записи системы или приложений, чтобы получить доступ к данным о держателях карт.

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

Определения:
Системные или прикладные учетные записи - это учетные записи, которые выполняют процессы или задачи в компьютерной системе или приложении и обычно не являются учетными записями, в которые пользователь входит. Эти учетные записи обычно имеют повышенные привилегии, необходимые для выполнения специализированных задач или функций.
Интерактивный вход в систему - это возможность для пользователя войти в учетную запись системы или приложения таким же образом, как и обычная учетная запись пользователя. Использование учетных записей системы и приложений таким образом означает отсутствие подотчетности и отслеживания действий, предпринятых пользователем.
Requirement 3.5.1.3
3.5.1.3
Определенные Требования к Подходу:
Если используется шифрование на уровне диска или раздела (а не шифрование базы данных на уровне файлов, столбцов или полей), чтобы сделать PAN нечитаемым, оно управляется следующим образом:
  • Логический доступ управляется отдельно и независимо от собственных механизмов аутентификации и контроля доступа операционной системы.
  • Ключи дешифрования не связаны с учетными записями пользователей.
  • Факторы аутентификации (пароли, кодовые фразы или криптографические ключи), которые позволяют получить доступ к незашифрованным данным, хранятся надежно
Цель Индивидуального подхода:
Реализации шифрования диска настроены таким образом, чтобы для дешифрования требовалась независимая проверка подлинности и логический контроль доступа.

Примечания по применению:
Реализации шифрования диска или раздела также должны соответствовать всем другим требованиям к шифрованию PCI DSS и управлению ключами.

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

Надлежащая практика:
Полное шифрование диска помогает защитить данные в случае физической потери диска, и поэтому его использование лучше всего ограничить только съемными электронными устройствами хранения данных.
Requirement 7.2.3
7.2.3
Определенные Требования к Подходу:
Необходимые привилегии утверждаются уполномоченным персоналом

Цель Индивидуального подхода:
Права доступа не могут быть предоставлены пользователям без соответствующей документированной авторизации.

Определенные Процедуры Тестирования Подхода:
  • 7.2.3.a Изучите политики и процедуры, чтобы убедиться, что они определяют процессы утверждения всех привилегий уполномоченным персоналом.
  • 7.2.3.b Проверьте идентификаторы пользователей и назначенные привилегии и сравните с документально подтвержденными утверждениями, чтобы убедиться, что:
    • Для присвоенных привилегий существует документально подтвержденное утверждение.
    • Одобрение было получено уполномоченным персоналом.
    • Указанные привилегии соответствуют ролям, назначенным данному лицу.
Цель:
Документально оформленное одобрение (например, в письменной или электронной форме) гарантирует, что лица, обладающие доступом и привилегиями, известны и авторизованы руководством, и что их доступ необходим для выполнения их должностных функций.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
ИАФ.4 ИАФ.4 Управление средствами аутентификации, в том числе хранение, выдача, инициализация, блокирование средств аутентификации и принятие мер в случае утраты и (или) компрометации средств аутентификации
ГОСТ Р № 59547-2021 от 01.04.2022 "Защита информации. Мониторинг информационной безопасности. Общие положения":
Р. 6 п. 6 п.п. 2
6.6.2 Для защиты данных мониторинга в рамках мероприятий по мониторингу информационной безопасности должны быть реализованы следующие функции безопасности: 
- идентификация и аутентификация пользователей при осуществлении доступа к программным и аппаратным компонентам, применяемым для мониторинга информационной безопасности: 
- управление идентификаторами пользователей при осуществлении доступа к программным и аппаратным компонентам, применяемым для мониторинга информационной безопасности; 
- управление аутентификаторами (аутентификационной информацией) пользователей при осуществлении доступа к программным и аппаратным компонентам, применяемым для мониторинга информационной безопасности;
- управление учетными записями пользователей;
- защита аутентификационной информации в процессе ее ввода для аутентификации от возможного использования лицами, не имеющими на это полномочий; 
- управление доступом пользователей к функциям и данным мониторинга информационной безопасности; 
П р и м е ч а н и е – Для управления доступом пользователей мониторинга информационной безопасности к функциям мониторинга должен быть реализован ролевой метод управления доступом, а для управления доступом пользователей мониторинга информационной безопасности к данным мониторинга ролевой и (или) дискреционный метод управления доступом.
- ограничение неуспешных попыток доступа к программным и аппаратным компонентам, применяемым для мониторинга информационной безопасности; - регистрация действий пользователей при осуществлении доступа к программным и аппаратным компонентам, применяемым для мониторинга информационной безопасности; 
П р и м е ч а н и е – В процессе мониторинга информационной безопасности должны, как минимум, регистрироваться следующие типы событий безопасности, установленные в ГОСТ Р «Защита информации. Регистрация событий безопасности. Требования к регистрируемой информации»: попытки идентификации и аутентификации субъекта доступа; 
управление учетными записями пользователей; 
управление средствами аутентификации; 
управление атрибутами доступа; 
попытки доступа к защищаемой информации; 
управление (администрирование) функциями безопасности; 
действия по управлению журналами (записями) регистрации событий безопасности. 
- защита от несанкционированного изменения данных аудита программных и аппаратных компонентов, применяемых для мониторинга информационной безопасности; 
- оповещение администратора мониторинга информационной безопасности о потенциально опасных действиях пользователей, осуществляющих доступ к программным и аппаратным компонентам, применяемым для мониторинга информационной безопасности. 
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.17
А.5.17 Аутентификационная информация
Распределение и управление аутентификационной информацией должно контролироваться процессом управления, включая информирование персонала о надлежащем обращении с аутентификационной информацией.
А.8.5
А.8.5 Безопасная аутентификация
Технологии и процедуры безопасной аутентификации должны быть внедрены на основании ограничений доступа к информации и специфической тематической политики по контролю доступа.
Приказ ФСБ России № 196 от 06.05.2019 "Требования к средствам, предназначенным для обнаружения, предупреждения и ликвидации последствий компьютерных атак и реагирования на компьютерные инциденты":
VIII п.21.1
21.1. При осуществлении идентификации и аутентификации пользователей средства ГосСОПКА должны обеспечивать:
  • аутентификацию пользователей с использованием паролей (в том числе временного действия) и (или) аппаратных средств аутентификации;
  • хранение паролей в зашифрованном виде;
  • автоматическое информирование о необходимости смены паролей.
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ИАФ.4 ИАФ.4 Управление средствами аутентификации
ИАФ.0 ИАФ.0 Разработка политики идентификации и аутентификации
NIST Cybersecurity Framework (EN):
PR.AC-1 PR.AC-1: Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users and processes
PR.AC-7 PR.AC-7: Users, devices, and other assets are authenticated (e.g., single-factor, multi-factor) commensurate with the risk of the transaction (e.g., individuals’ security and privacy risks and other organizational risks)
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ИАФ.4 ИАФ.4 Управление средствами аутентификации
ИАФ.0 ИАФ.0 Регламентация правил и процедур идентификации и аутентификации
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.5.17
А.5.17 Authentication information
Allocation and management of authentication information shall be controlled by a management process, including advising personnel of appropriate handling of authentication information.
А.8.5
А.8.5 Secure authentication
Secure authentication technologies and procedures shall be implemented based on information access restrictions and the topic-specific policy on access control.

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

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

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