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

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

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


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

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

Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ИАФ.4 ИАФ.4 Управление средствами аутентификации, в том числе хранение, выдача, инициализация, блокирование средств аутентификации и принятие мер в случае утраты и (или) компрометации средств аутентификации
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 8.6.3
Defined Approach Requirements: 
Passwords/passphrases for any application and system accounts are protected against misuse as follows:
  • Passwords/passphrases are changed periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1) and upon suspicion or confirmation of compromise.
  • Passwords/passphrases are constructed with sufficient complexity appropriate for how frequently the entity changes the passwords/passphrases. 
Customized Approach Objective:
Passwords/passphrases used by application and system accounts cannot be used indefinitely and are structured to resist brute-force and guessing attacks. 

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.3.a Examine policies and procedures to verify that procedures are defined to protect passwords/passphrases for application or system accounts against misuse in accordance with all elements specified in this requirement. 
  • 8.6.3.b Examine the entity’s targeted risk analysis for the change frequency and complexity for passwords/passphrases used for interactive login to application and system accounts to verify the risk analysis was performed in accordance with all elements specified in Requirement 12.3.1 and addresses: 
    • The frequency defined for periodic changes to application and system passwords/passphrases. 
    • The complexity defined for passwords/passphrases and appropriateness of the complexity relative to the frequency of changes. Customized Approach Objective 
  • 8.6.3.c Interview responsible personnel and examine system configuration settings to verify that passwords/passphrases for any application and system accounts that can be used for interactive login are protected against misuse in accordance with all elements specified in this requirement. 
Systems and application accounts pose more inherent security risk than user accounts because they often run in an elevated security context, with access to systems that may not be typically granted to user accounts, such as programmatic access to databases, etc. As a result, special consideration must be made to protect passwords/passphrases used for application and system accounts. 

Good Practice:
Entities should consider the following risk factors when determining how to protect application and system passwords/passphrases against misuse:
  • How securely the passwords/passphrases are stored (for example, whether they are stored in a password vault).
  • Staff turnover. 
  • The number of people with access to the authentication factor.
  • Whether the account can be used for interactive login. 
  • Whether the security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly (see Requirement 8.3.9). 
All these elements affect the level of risk for application and system accounts and might impact the security of systems accessed by the system and application accounts. 
Entities should correlate their selected change frequency for application and system passwords/passwords with their selected complexity for those passwords/passphrases – i.e., the complexity should be more rigorous when passwords/passphrases are changed infrequently and can be less rigorous when changed more frequently. For example, a longer change frequency is more justifiable when passwords/passphrases complexity is set to 36 alphanumeric characters with upper- and lowercase letters, numbers, and special characters. 
Best practices are to consider password changes at least once a year, a password/passphrase length of at least 15 characters, and complexity for the passwords/passphrase of alphanumeric characters, with upper- and lower-case letters, and special characters. 

Further Information:
For information about variability and equivalency of password strength for passwords/passphrases of different formats, see the industry standards (for example, the current version of NIST SP 800- 63 Digital Identity Guidelines). 
Requirement 2.3.2
Defined Approach Requirements: 
For wireless environments connected to the CDE or transmitting account data, wireless encryption keys are changed as follows: 
  • Whenever personnel with knowledge of the key leave the company or the role for which the knowledge was necessary.
  • Whenever a key is suspected of or known to be compromised. 
Customized Approach Objective:
Knowledge of wireless encryption keys cannot allow unauthorized access to wireless networks. 

Defined Approach Testing Procedures:
  • 2.3.2 Interview responsible personnel and examine key-management documentation to verify that wireless encryption keys are changed in accordance with all elements specified in this requirement 
Changing wireless encryption keys whenever someone with knowledge of the key leaves the organization or moves to a role that no longer requires knowledge of the key, helps keep knowledge of keys limited to only those with a business need to know. 
Also, changing wireless encryption keys whenever a key is suspected or known to be comprised makes a wireless network more resistant to compromise. 

Good Practice:
This goal can be accomplished in multiple ways, including periodic changes of keys, changing keys via a defined “joiners-movers-leavers” (JML) process, implementing additional technical controls, and not using fixed pre-shared keys. 
In addition, any keys that are known to be, or suspected of being, compromised should be managed in accordance with the entity’s incident response plan at Requirement 12.10.1. 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 2.3.2
Определенные Требования к Подходу:
Для беспроводных сред, подключенных к CDE или передающих данные учетной записи, беспроводные ключи шифрования изменяются:
  • Всякий раз, когда персонал, обладающий знаниями о ключе, покидает компанию или должность, для которой эти знания были необходимы.
  • Всякий раз, когда подозревается или известно, что ключ скомпрометирован.
Цель Индивидуального подхода:
Знание беспроводных ключей шифрования не может обеспечить несанкционированный доступ к беспроводным сетям.

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

Надлежащая практика:
Эта цель может быть достигнута несколькими способами, включая периодическую смену ключей, смену ключей с помощью определенного процесса “joiners-movers-leavers” (JML), внедрение дополнительных технических средств контроля и отказ от использования фиксированных предварительно разделяемых ключей.
Кроме того, управление любыми ключами, которые, как известно, или предположительно скомпрометированы, должно осуществляться в соответствии с планом реагирования организации на инциденты в соответствии с требованием 12.10.1.
Requirement 8.6.3
Определенные Требования к Подходу:
Пароли / парольные фразы для любых приложений и системных учетных записей защищены от неправильного использования следующим образом:
  • Пароли/парольные фразы меняются периодически (с частотой, определенной в целевом анализе рисков организации, который выполняется в соответствии со всеми элементами, указанными в Требовании 12.3.1) и при подозрении или подтверждении компрометации.
  • Пароли/парольные фразы создаются с достаточной сложностью, соответствующей тому, как часто объект меняет пароли/парольные фразы.
Цель Индивидуального подхода:
Пароли/парольные фразы, используемые учетными записями приложений и систем, не могут использоваться бесконечно и структурированы таким образом, чтобы противостоять атакам методом перебора и угадывания.

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

Определенные Процедуры Тестирования Подхода:
  • 8.6.3.a Изучите политики и процедуры, чтобы убедиться, что определены процедуры для защиты паролей/парольных фраз для учетных записей приложений или системы от неправильного использования в соответствии со всеми элементами, указанными в этом требовании.
  • 8.6.3.b Изучите целевой анализ рисков организации на предмет частоты и сложности изменений паролей/парольных фраз, используемых для интерактивного входа в учетные записи приложений и системы, чтобы убедиться, что анализ рисков был выполнен в соответствии со всеми элементами, указанными в Требовании 12.3.1, и адреса:
    • Частота, определенная для периодических изменений паролей/парольных фраз приложений и системы.
    • Сложность, определенная для паролей/парольных фраз, и соответствие сложности по отношению к частоте изменений.
  • 8.6.3.c Опросите ответственный персонал и изучите параметры конфигурации системы, чтобы убедиться, что пароли / парольные фразы для любых приложений и системных учетных записей, которые могут использоваться для интерактивного входа в систему, защищены от неправильного использования в соответствии со всеми элементами, указанными в этом требовании.
Учетные записи систем и приложений представляют больший риск для безопасности, чем учетные записи пользователей, поскольку они часто работают в контексте повышенной безопасности, с доступом к системам, который обычно не может быть предоставлен учетным записям пользователей, таким как программный доступ к базам данных и т.д. В результате необходимо уделять особое внимание защите паролей/парольных фраз, используемых для учетных записей приложений и систем.

Надлежащая практика:
Организации должны учитывать следующие факторы риска при определении того, как защитить пароли/парольные фразы приложений и системы от неправильного использования:
  • Насколько надежно хранятся пароли/парольные фразы (например, хранятся ли они в хранилище паролей).
  • Текучесть кадров.
  • Количество людей, имеющих доступ к фактору аутентификации.
  • Можно ли использовать учетную запись для интерактивного входа в систему.
  • Выполняется ли динамический анализ состояния безопасности учетных записей, и соответственно автоматически определяется доступ к ресурсам в режиме реального времени (см. Требование 8.3.9).
Все эти элементы влияют на уровень риска для учетных записей приложений и систем и могут повлиять на безопасность систем, к которым обращаются учетные записи системы и приложений.
Субъекты должны соотносить выбранную ими частоту изменения паролей/паролей приложений и системы с выбранной ими сложностью для этих паролей /парольных фраз – т.е. сложность должна быть более строгой, когда пароли / парольные фразы меняются нечасто, и может быть менее строгой, когда меняются чаще. Например, более длительная частота смены более оправдана, когда сложность паролей/парольных фраз установлена на 36 буквенно-цифровых символов с прописными и строчными буквами, цифрами и специальными символами.
Рекомендуется учитывать необходимость смены пароля не реже одного раза в год, длину пароля/парольной фразы не менее 15 символов и сложность паролей/парольной фразы, состоящей из буквенно-цифровых символов, прописных и строчных букв и специальных символов.

В дальнейшем:
Информация Для получения информации об изменчивости и эквивалентности надежности паролей для паролей/парольных фраз различных форматов см. отраслевые стандарты (например, текущую версию NIST SP 800- 63 Digital Identity Guidelines).
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
ИАФ.4 ИАФ.4 Управление средствами аутентификации, в том числе хранение, выдача, инициализация, блокирование средств аутентификации и принятие мер в случае утраты и (или) компрометации средств аутентификации

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

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