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

SWIFT Customer Security Controls Framework v2022

Framework

2 - 2.6 Operator Confidentiality and Integrity

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

Список требований

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

Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 7 п. 6 п.п. 7
7.6.7. Все операции клиентов в течение всего сеанса работы с системами дистанционного банковского обслуживания, в том числе операции по переводу денежных средств, должны выполняться только после выполнения процедур идентификации, аутентификации и авторизации. В случаях нарушения или разрыва соединения необходимо обеспечить закрытие текущей сессии и повторное выполнение процедур идентификации, аутентификации и авторизации.
Для доступа пользователей к системам дистанционного банковского обслуживания рекомендуется использовать специализированное клиентское программное обеспечение.
NIST Cybersecurity Framework (RU):
PR.DS-2
PR.DS-2: Данные при передаче защищаются  
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ЗИС.11 ЗИС.11 Обеспечение подлинности сетевых соединений (сеансов взаимодействия), в том числе для защиты от подмены сетевых устройств и сервисов
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
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:
  • 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. 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.9.4.2
A.9.4.2 Безопасные процедуры входа в систему 
Мера обеспечения информационной безопасности: Когда этого требует политика управления доступом, доступ к системам и приложениям должен управляться посредством безопасной процедуры входа в систему 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 8.2.8
8.2.8
Определенные Требования к Подходу:
Если сеанс пользователя простаивает более 15 минут, пользователю необходимо повторно пройти аутентификацию, чтобы повторно активировать терминал или сеанс.

Цель Индивидуального подхода:
Сеанс пользователя может быть использован только авторизованным пользователем.

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

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

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

Примеры:
Один из способов выполнить это требование - настроить автоматическую заставку, которая будет запускаться всякий раз, когда консоль простаивает в течение 15 минут, и требовать от вошедшего в систему пользователя ввода пароля для разблокировки экрана.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
ЗИС.11 ЗИС.11 Обеспечение подлинности сетевых соединений (сеансов взаимодействия), в том числе для защиты от подмены сетевых устройств и сервисов
NIST Cybersecurity Framework (EN):
PR.DS-2 PR.DS-2: Data-in-transit is protected
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
9.4.2
9.4.2 Безопасные процедуры входа в систему

Мера обеспечения ИБ
Когда этого требует политика управления доступом, доступ к системам и приложениям должен управляться посредством безопасной процедуры входа в систему.

Руководство по применению
Должны быть выбраны подходящие методы аутентификации для подтверждения заявленной личности пользователя.
Там, где требуется строгая аутентификация и проверка личности, должны использоваться методы аутентификации, альтернативные паролям, такие как криптографические средства, смарт-карты, токены или биометрические средства.
Процедура входа в систему или приложение должна быть разработана таким образом, чтобы минимизировать возможность несанкционированного доступа. Таким образом, процедура входа в систему должна раскрывать минимум информации о системе или приложении, во избежание оказания какой-либо неумышленной помощи неавторизованному пользователю. Разработанная надлежащим образом процедура входа должна:
  • a) не отображать идентификаторы системы или приложения до тех пор, пока процесс входа успешно не завершен;
  • b) выводить общее предупреждение, что доступ к компьютеру предоставляется только авторизованным пользователям;
  • c) не предоставлять подсказок во время процедуры входа, которые могли бы помочь неавторизованному пользователю;
  • d) осуществлять подтверждение информации для входа только после завершения ввода всех данных. Если возникает ошибка, система не должна указывать, какая часть данных для входа является правильной или неправильной;
  • e) защищать от попыток входа в систему методом полного перебора (грубой силы);
  • f) регистрировать неуспешные и успешные попытки входа;
  • g) фиксировать событие безопасности при обнаружении попыток или фактов успешного нарушения процедуры входа;
  • h) отображать следующую информацию по завершении успешного входа в систему:
  1. - дата и время предыдущего успешного входа;
  2. - сведения всех неудачных попыток входа с момента последнего успешного входа;
  • i) не отображать вводимый пароль;
  • j) не передавать пароли в открытом виде по сети;
  • k) завершать неактивные сессии после определенного периода бездействия, особенно в местах повышенного риска, таких как общественные места или точки за пределами организации, которые не попадают под контроль системы менеджмента информационной безопасности организации, или на мобильных устройствах;
  • l) ограничивать время соединения для обеспечения дополнительной защиты приложений с высоким риском и снижения возможности несанкционированного доступа.

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

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

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

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