Куда я попал?
Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014
Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения
Р. 7 п. 6 п.п. 7
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
РД.15
РД.15 Выполнение процедуры повторной аутентификации для продолжения осуществления логического доступа после его принудительного или автоматического прерывания (приостановки осуществления логического доступа), предусмотренного мерами РД.13 и РД.14 настоящей таблицы
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
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:
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.
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.
Requirement 8.2.8
8.2.8
Defined Approach Requirements:
If a user session has been idle for more than 15 minutes, the user is required to re-authenticate to re-activate the terminal or session.
Customized Approach Objective:
A user session cannot be used except by the authorized user.
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 is not meant to prevent legitimate activities from being performed while the console/PC is unattended.
Defined Approach Testing Procedures:
Defined Approach Requirements:
If a user session has been idle for more than 15 minutes, the user is required to re-authenticate to re-activate the terminal or session.
Customized Approach Objective:
A user session cannot be used except by the authorized user.
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 is not meant to prevent legitimate activities from being performed while the console/PC is unattended.
Defined Approach Testing Procedures:
- 8.2.8 Examine system configuration settings to verify that system/session idle timeout features for user sessions have been set to 15 minutes or less.
Purpose:
When users walk away from an open machine with access to system components or cardholder data, there is a risk that the machine may be used by others in the user’s absence, resulting in unauthorized account access and/or misuse.
Good Practice:
The re-authentication can be applied either at the system level to protect all sessions running on that machine or at the application level.
Entities may also want to consider staging controls in succession to further restrict the access of an unattended session as time passes. For example, the screensaver may activate after 15 minutes and log off the user after an hour.
However, timeout controls must balance the risk of access and exposure with the impact to the user and purpose of the access.
If a user needs to run a program from an unattended computer, the user can log in to the computer to initiate the program, and then “lock” the computer so that no one else can use the user’s login while the computer is unattended.
Examples:
One way to meet this requirement is to configure an automated screensaver to launch whenever the console is idle for 15 minutes and requiring the logged-in user to enter their password to unlock the screen.
When users walk away from an open machine with access to system components or cardholder data, there is a risk that the machine may be used by others in the user’s absence, resulting in unauthorized account access and/or misuse.
Good Practice:
The re-authentication can be applied either at the system level to protect all sessions running on that machine or at the application level.
Entities may also want to consider staging controls in succession to further restrict the access of an unattended session as time passes. For example, the screensaver may activate after 15 minutes and log off the user after an hour.
However, timeout controls must balance the risk of access and exposure with the impact to the user and purpose of the access.
If a user needs to run a program from an unattended computer, the user can log in to the computer to initiate the program, and then “lock” the computer so that no one else can use the user’s login while the computer is unattended.
Examples:
One way to meet this requirement is to configure an automated screensaver to launch whenever the console is idle for 15 minutes and requiring the logged-in user to enter their password to unlock the screen.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.9.4.4
A.9.4.4 Использование привилегированных служебных программ
Мера обеспечения информационной безопасности: Использование служебных программ, которые могли бы обойти меры обеспечения информационной безопасности систем и приложений, следует ограничивать и строго контролировать
Мера обеспечения информационной безопасности: Использование служебных программ, которые могли бы обойти меры обеспечения информационной безопасности систем и приложений, следует ограничивать и строго контролировать
A.9.3.1
A.9.3.1 Использование секретной аутентификационной информации
Мера обеспечения информационной безопасности: При использовании секретной аутентификационной информации пользователи должны выполнять установленные в организации правила
Мера обеспечения информационной безопасности: При использовании секретной аутентификационной информации пользователи должны выполнять установленные в организации правила
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.2.8
8.2.8
Определенные Требования к Подходу:
Если сеанс пользователя простаивает более 15 минут, пользователю необходимо повторно пройти аутентификацию, чтобы повторно активировать терминал или сеанс.
Цель Индивидуального подхода:
Сеанс пользователя может быть использован только авторизованным пользователем.
Примечания по применению:
Это требование не предназначено для применения к учетным записям пользователей в торговых терминалах, которые имеют доступ только к одному номеру карты одновременно для облегчения одной транзакции (например, идентификаторы, используемые кассирами в торговых терминалах).
Это требование не предназначено для предотвращения выполнения законных действий, пока консоль / ПК находятся без присмотра.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Если сеанс пользователя простаивает более 15 минут, пользователю необходимо повторно пройти аутентификацию, чтобы повторно активировать терминал или сеанс.
Цель Индивидуального подхода:
Сеанс пользователя может быть использован только авторизованным пользователем.
Примечания по применению:
Это требование не предназначено для применения к учетным записям пользователей в торговых терминалах, которые имеют доступ только к одному номеру карты одновременно для облегчения одной транзакции (например, идентификаторы, используемые кассирами в торговых терминалах).
Это требование не предназначено для предотвращения выполнения законных действий, пока консоль / ПК находятся без присмотра.
Определенные Процедуры Тестирования Подхода:
- 8.2.8 Проверьте параметры конфигурации системы, чтобы убедиться, что функции тайм-аута ожидания системы/сеанса для пользовательских сеансов установлены на 15 минут или меньше.
Цель:
Когда пользователи уходят с открытого компьютера, имеющего доступ к системным компонентам или данным о держателях карт, существует риск того, что компьютер может быть использован другими лицами в отсутствие пользователя, что приведет к несанкционированному доступу к учетной записи и/или неправильному использованию.
Надлежащая практика:
Повторная проверка подлинности может быть применена либо на системном уровне для защиты всех сеансов, запущенных на этом компьютере, либо на уровне приложения.
Организации могут также захотеть рассмотреть возможность последовательного размещения элементов управления, чтобы с течением времени дополнительно ограничить доступ к сеансу без присмотра. Например, заставка может активироваться через 15 минут, а пользователь может выйти из системы через час.
Однако контроль времени ожидания должен сбалансировать риск доступа и воздействия с воздействием на пользователя и целью доступа.
Если пользователю необходимо запустить программу с компьютера, находящегося без присмотра, пользователь может войти в систему, чтобы запустить программу, а затем “заблокировать” компьютер, чтобы никто другой не мог использовать логин пользователя, пока компьютер находится без присмотра.
Примеры:
Один из способов выполнить это требование - настроить автоматическую заставку, которая будет запускаться всякий раз, когда консоль простаивает в течение 15 минут, и требовать от вошедшего в систему пользователя ввода пароля для разблокировки экрана.
Когда пользователи уходят с открытого компьютера, имеющего доступ к системным компонентам или данным о держателях карт, существует риск того, что компьютер может быть использован другими лицами в отсутствие пользователя, что приведет к несанкционированному доступу к учетной записи и/или неправильному использованию.
Надлежащая практика:
Повторная проверка подлинности может быть применена либо на системном уровне для защиты всех сеансов, запущенных на этом компьютере, либо на уровне приложения.
Организации могут также захотеть рассмотреть возможность последовательного размещения элементов управления, чтобы с течением времени дополнительно ограничить доступ к сеансу без присмотра. Например, заставка может активироваться через 15 минут, а пользователь может выйти из системы через час.
Однако контроль времени ожидания должен сбалансировать риск доступа и воздействия с воздействием на пользователя и целью доступа.
Если пользователю необходимо запустить программу с компьютера, находящегося без присмотра, пользователь может войти в систему, чтобы запустить программу, а затем “заблокировать” компьютер, чтобы никто другой не мог использовать логин пользователя, пока компьютер находится без присмотра.
Примеры:
Один из способов выполнить это требование - настроить автоматическую заставку, которая будет запускаться всякий раз, когда консоль простаивает в течение 15 минут, и требовать от вошедшего в систему пользователя ввода пароля для разблокировки экрана.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.18
А.8.18 Использование привилегированных приложений
Должно быть ограничено и строго контролироваться использование приложений, способных преодолеть средства управления ИБ систем и приложений.
Должно быть ограничено и строго контролироваться использование приложений, способных преодолеть средства управления ИБ систем и приложений.
SWIFT Customer Security Controls Framework v2022:
2 - 2.6 Operator Confidentiality and Integrity
2.6 Operator Session Confidentiality and Integrity
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.8.18
А.8.18 Use of privileged utility programs
The use of utility programs that can be capable of overriding system and application controls shall be restricted and tightly controlled.
The use of utility programs that can be capable of overriding system and application controls shall be restricted and tightly controlled.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.