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

Приказ ФСТЭК России № 21 от 18.02.2013

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

ИАФ.4

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

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

ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
РД.29
РД.29 Смена аутентификационных данных в случае их компрометации
3-О 2-О 1-О
РД.26
РД.26 Хранение копий аутентификационных данных эксплуатационного персонала на выделенных МНИ или на бумажных носителях
3-О 2-О 1-О
РД.27
РД.27 Реализация защиты копий аутентификационных данных эксплуатационного персонала от НСД при их хранении на МНИ или бумажных носителях
3-О 2-О 1-О
РД.17
РД.17 Запрет на использование технологии аутентификации с сохранением аутентификационных данных в открытом виде в СВТ
3-Т 2-Т 1-Т
NIST Cybersecurity Framework (RU):
PR.AC-1
PR.AC-1: Для авторизованных устройств, пользователей и процессов выдаются, управляются, верифицируются, аннулируются и проверяются идентификационные и учетные данные
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 8.6.2
8.6.2
Defined Approach Requirements: 
Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and custom source code. 

Customized Approach Objective:
Passwords/passphrases used by application and system accounts cannot be used by unauthorized personnel. 

Applicability Notes:
Stored passwords/passphrases are required to be encrypted in accordance with PCI DSS Requirement 8.3.2. 
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.2.a Interview personnel and examine system development procedures to verify that processes are defined for application and system accounts that can be used for interactive login, specifying that passwords/passphrases are not hard coded in scripts, configuration/property files, or bespoke and custom source code. 
  • 8.6.2.b Examine scripts, configuration/property files, and bespoke and custom source code for application and system accounts that can be used for interactive login, to verify passwords/passphrases for those accounts are not present. 
Purpose:
Not properly protecting passwords/passphrases used by application and system accounts, especially if those accounts can be used for interactive login, increases the risk and success of unauthorized use of those privileged accounts. 

Good Practice:
Changing these values due to suspected or confirmed disclosure can be particularly difficult to implement. 
Tools can facilitate both management and security of authentication factors for application and system accounts. For example, consider password vaults or other system-managed controls. 
Requirement 8.6.3
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. 
Purpose:
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
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 
Purpose:
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. 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.9.2.4
A.9.2.4 Процесс управления секретной аутентификационной информацией пользователей 
Мера обеспечения информационной безопасности: Предоставление секретной аутентификационной информации должно контролироваться посредством формального процесса управления. 
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 16.7 CSC 16.7 Establish Process for Revoking Access
Establish and follow an automated process for revoking system access by disabling accounts immediately upon termination or change of responsibilities of an employee or contractor . Disabling these accounts, instead of deleting accounts, allows preservation of audit trails.
CSC 16.6 CSC 16.6 Maintain an Inventory of Accounts
Maintain an inventory of all accounts organized by authentication system.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 2.3.2
2.3.2
Определенные Требования к Подходу:
Для беспроводных сред, подключенных к CDE или передающих данные учетной записи, беспроводные ключи шифрования изменяются:
  • Всякий раз, когда персонал, обладающий знаниями о ключе, покидает компанию или должность, для которой эти знания были необходимы.
  • Всякий раз, когда подозревается или известно, что ключ скомпрометирован.
Цель Индивидуального подхода:
Знание беспроводных ключей шифрования не может обеспечить несанкционированный доступ к беспроводным сетям.

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

Надлежащая практика:
Эта цель может быть достигнута несколькими способами, включая периодическую смену ключей, смену ключей с помощью определенного процесса “joiners-movers-leavers” (JML), внедрение дополнительных технических средств контроля и отказ от использования фиксированных предварительно разделяемых ключей.
Кроме того, управление любыми ключами, которые, как известно, или предположительно скомпрометированы, должно осуществляться в соответствии с планом реагирования организации на инциденты в соответствии с требованием 12.10.1.
Requirement 8.6.3
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).
Requirement 8.6.2
8.6.2
Определенные Требования к Подходу:
Пароли/парольные фразы для любых учетных записей приложений и систем, которые можно использовать для интерактивного входа в систему, не жестко закодированы в скриптах, файлах конфигурации/свойств или в специально разработанном и настраиваемом исходном коде.

Цель Индивидуального подхода:
Пароли/парольные фразы, используемые учетными записями приложений и систем, не могут быть использованы неавторизованным персоналом.

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

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

Надлежащая практика:
Изменение этих значений из-за предполагаемого или подтвержденного раскрытия информации может быть особенно трудным для реализации.
Инструменты могут облегчить как управление, так и безопасность факторов аутентификации для учетных записей приложений и систем. Например, рассмотрите хранилища паролей или другие управляемые системой элементы управления.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
ИАФ.4 ИАФ.4 Управление средствами аутентификации, в том числе хранение, выдача, инициализация, блокирование средств аутентификации и принятие мер в случае утраты и (или) компрометации средств аутентификации
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.17
А.5.17 Аутентификационная информация
Распределение и управление аутентификационной информацией должно контролироваться процессом управления, включая информирование персонала о надлежащем обращении с аутентификационной информацией.
А.8.5
А.8.5 Безопасная аутентификация
Технологии и процедуры безопасной аутентификации должны быть внедрены на основании ограничений доступа к информации и специфической тематической политики по контролю доступа.
SWIFT Customer Security Controls Framework v2022:
4 - 4.2 Multi-Factor Authentication
4.2 Multi-Factor Authentication
5 - 5.2 Token Management
5.2 Token Management
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ИАФ.4 ИАФ.4 Управление средствами аутентификации
Положение Банка России № 757-П от 20.04.2021 "Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций":
1.10.2.
1.10.2. Технология обработки защищаемой информации, применяемая при идентификации, аутентификации и авторизации клиентов некредитных финансовых организаций в целях осуществления финансовых операций, должна обеспечивать выполнение следующих мероприятий:
  • в случае использования единой информационной системы персональных данных, обеспечивающей обработку, включая сбор и хранение, биометрических персональных данных, их проверку и передачу информации о степени их соответствия предоставленным биометрическим персональным данным гражданина Российской Федерации, - реализацию установленных приказом Федеральной службы по техническому и экспортному контролю от 18 февраля 2013 года N 21 "Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных", зарегистрированным Министерством юстиции Российской Федерации 14 мая 2013 года N 28375, 25 апреля 2017 года N 46487, 8 июля 2020 года N 58877, приказом Федеральной службы безопасности Российской Федерации от 10 июля 2014 года N 378 "Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности", зарегистрированным Министерством юстиции Российской Федерации 18 августа 2014 года N 33620, технических и организационных мер в целях нейтрализации угроз безопасности, актуальных при обработке, включая сбор и хранение, биометрических персональных данных, их проверке и передаче информации о степени их соответствия предоставленным биометрическим персональным данным гражданина Российской Федерации;
  • в случае использования единой системы идентификации и аутентификации - соблюдение требований к обеспечению защиты информации в соответствии Техническими требованиями к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия, утвержденными приказом Министерства связи и массовых коммуникаций Российской Федерации от 23 июня 2015 года N 210 "Об утверждении Технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия", зарегистрированным Министерством юстиции Российской Федерации 25 августа 2015 года N 38668, 2 июня 2017 года N 46934.
Положение Банка России № 683-П от 17.04.2019 "Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента":
7.
7. Кредитные организации должны обеспечивать формирование для клиентов рекомендаций по защите информации от воздействия программных кодов, приводящих к нарушению штатного функционирования средства вычислительной техники (далее - вредоносный код) в целях противодействия осуществлению переводов денежных средств без согласия клиента.
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
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ИАФ.4 ИАФ.4 Управление средствами аутентификации
Стандарт № 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-файлов и соглашаетесь с Политикой обработки персональных данных.