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

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

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

РД.1

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

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

Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ИАФ.1 ИАФ.1 Идентификация и аутентификация пользователей, являющихся работниками оператора
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 8.3.1
8.3.1
Defined Approach Requirements: 
All user access to system components for users and administrators is authenticated via at least one of the following authentication factors:
  • Something you know, such as a password or passphrase.
  • Something you have, such as a token device or smart card.
  • Something you are, such as a biometric element. 
Customized Approach Objective:
An account cannot be accessed except with a combination of user identity and an authentication factor. 

Applicability Notes:
This requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction (such as IDs used by cashiers on point-of-sale terminals). 
This requirement does not supersede multi-factor authentication (MFA) requirements but applies to those in-scope systems not otherwise subject to MFA requirements. 
A digital certificate is a valid option for “something you have” if it is unique for a particular user. 

Defined Approach Testing Procedures:
  • 8.3.1.a Examine documentation describing the authentication factor(s) used to verify that user access to system components is authenticated via at least one authentication factor specified in this requirement. 
  • 8.3.1.b For each type of authentication factor used with each type of system component, observe an authentication to verify that authentication is functioning consistently with documented authentication factor(s). 
Purpose:
When used in addition to unique IDs, an authentication factor helps protect user IDs from being compromised, since the attacker needs to have the unique ID and compromise the associated authentication factor(s). 

Good Practice:
A common approach for a malicious individual to compromise a system is to exploit weak or nonexistent authentication factors (for example, passwords/passphrases). Requiring strong authentication factors helps protect against this attack. 

Further Information:
See fidoalliance.org for more information about using tokens, smart cards, or biometrics as authentication factors. 
Requirement 7.3.1
7.3.1
Defined Approach Requirements: 
An access control system(s) is in place that restricts access based on a user’s need to know and covers all system components. 

Customized Approach Objective:
Access rights and privileges are managed via mechanisms intended for that purpose. 

Defined Approach Testing Procedures:
  • 7.3.1 Examine vendor documentation and system settings to verify that access is managed for each system component via an access control system(s) that restricts access based on a user’s need to know and covers all system components. 
Purpose:
Without a mechanism to restrict access based on user’s need to know, a user may unknowingly be granted access to cardholder data. Access control systems automate the process of restricting access and assigning privileges. 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 7.3.1
7.3.1
Определенные Требования к Подходу:
Существует система (системы) контроля доступа, которая ограничивает доступ на основе необходимости пользователя знать и охватывает все компоненты системы.

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

Определенные Процедуры Тестирования Подхода:
  • 7.3.1 Изучите документацию поставщика и системные настройки, чтобы убедиться, что управление доступом для каждого компонента системы осуществляется с помощью системы (систем) контроля доступа, которая ограничивает доступ на основе потребностей пользователя и охватывает все компоненты системы.
Цель:
Без механизма ограничения доступа, основанного на необходимости пользователя знать, пользователь может неосознанно получить доступ к данным о держателях карт. Системы контроля доступа автоматизируют процесс ограничения доступа и назначения привилегий.
Requirement 8.3.1
8.3.1
Определенные Требования к Подходу:
Весь пользовательский доступ к системным компонентам для пользователей и администраторов проверяется с помощью по крайней мере одного из следующих факторов аутентификации:
  • Что-то, что вы знаете, например, пароль или кодовую фразу.
  • Что-то, что у вас есть, например, токен-устройство или смарт-карта.
  • Что-то, чем вы являетесь, например, биометрический элемент.
Цель Индивидуального подхода:
Доступ к учетной записи возможен только с использованием комбинации идентификатора пользователя и фактора аутентификации.

Примечания по применению:
Это требование не предназначено для применения к учетным записям пользователей в торговых терминалах, которые имеют доступ только к одному номеру карты одновременно для облегчения одной транзакции (например, идентификаторы, используемые кассирами в торговых терминалах).
Это требование не заменяет требования к многофакторной аутентификации (MFA), но применяется к тем системам, которые в других случаях не подпадают под требования MFA.
Цифровой сертификат является допустимым вариантом для “того, что у вас есть”, если он уникален для конкретного пользователя.

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

Надлежащая практика:
Распространенный подход злоумышленника к компрометации системы заключается в использовании слабых или несуществующих факторов аутентификации (например, паролей/парольных фраз). Требование надежных факторов аутентификации помогает защититься от этой атаки.

Дополнительная информация:
См. fidoalliance.org дополнительные сведения об использовании токенов, смарт-карт или биометрических данных в качестве факторов аутентификации см.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
ИАФ.1 ИАФ.1 Идентификация и аутентификация пользователей, являющихся работниками оператора
Положение Банка России № 719-П от 04.06.2020 "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств":
Глава 2 п. 9
2.9. Технологические меры, указанные в пункте 2.8 настоящего Положения, должны обеспечивать реализацию:
  • механизмов идентификации и аутентификации клиента оператора по переводу денежных средств при формировании (подготовке) и при подтверждении им электронных сообщений в соответствии с требованиями законодательства Российской Федерации;
  • механизмов двухфакторной аутентификации клиента оператора по переводу денежных средств при совершении им действий в целях осуществления переводов денежных средств;
  • механизмов и (или) протоколов формирования и обмена электронными сообщениями, обеспечивающих защиту электронных сообщений от искажения, фальсификации, переадресации, несанкционированного ознакомления и (или) уничтожения, ложной авторизации, в том числе аутентификацию входных электронных сообщений;
  • взаимной (двухсторонней) аутентификации участников обмена средствами вычислительной техники операторов по переводу денежных средств, банковских платежных агентов (субагентов), операторов услуг информационного обмена, операторов услуг платежной инфраструктуры, клиентов операторов по переводу денежных средств;
  • возможности использования клиентом оператора по переводу денежных средств независимых программных сред для формирования (подготовки) и подтверждения электронных сообщений;
  • возможности контроля клиентом оператора по переводу денежных средств реквизитов распоряжений о переводе денежных средств при формировании (подготовке) электронных сообщений (пакета электронных сообщений) и их подтверждении;
  • возможности установления временных ограничений на выполнение клиентом оператора по переводу денежных средств подтверждения электронных сообщений;
  • функций передаваемого клиенту оператора по переводу денежных средств программного обеспечения, используемого при осуществлении переводов денежных средств и предназначенного для установки на мобильные устройства клиента оператора по переводу денежных средств, связанных с выявлением модификации мобильного устройства клиента оператора по переводу денежных средств с использованием недекларируемых возможностей, в том числе деактивации (отключения) механизма разграничения доступа (далее - недекларируемая модификация мобильного устройства клиента), а также уведомлением клиента оператора по переводу денежных средств о случаях недекларируемой модификации мобильного устройства клиента с указанием рисков использования такого устройства (при наличии технической возможности).
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ИАФ.1 ИАФ.1 Идентификация и аутентификация пользователей и инициируемых ими процессов
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ИАФ.1 ИАФ.1 Идентификация и аутентификация пользователей и инициируемых ими процессов

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

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