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

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

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

УПД.6

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

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

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

ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
РД.11
РД.11 Временная блокировка учетной записи пользователей после выполнения ряда неуспешных последовательных попыток аутентификации на период времени не менее 30 мин
3-Т 2-Т 1-Т
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 8.3.4
8.3.4
Defined Approach Requirements: 
Invalid authentication attempts are limited by:
  • Locking out the user ID after not more than 10 attempts.
  • Setting the lockout duration to a minimum of 30 minutes or until the user’s identity is confirmed. 
Customized Approach Objective:
An authentication factor cannot be guessed in a brute force, online attack. 

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). 

Defined Approach Testing Procedures:
  • 8.3.4.a Examine system configuration settings to verify that authentication parameters are set to require that user accounts be locked out after not more than 10 invalid logon attempts. 
  • 8.3.4.b Examine system configuration settings to verify that password parameters are set to require that once a user account is locked out, it remains locked for a minimum of 30 minutes or until the user’s identity is confirmed. 
Purpose:
Without account-lockout mechanisms in place, an attacker can continually try to guess a password through manual or automated tools (for example, password cracking) until the attacker succeeds and gains access to a user’s account.
If an account is locked out due to someone continually trying to guess a password, controls to delay reactivation of the locked account stop the malicious individual from guessing the password, as they will have to stop for a minimum of 30 minutes until the account is reactivated. 

Good Practice:
Before reactivating a locked account, the user’s identity should be confirmed. For example, the administrator or help desk personnel can validate that the actual account owner is requesting reactivation, or there may be password reset selfservice mechanisms that the account owner uses to verify their identity 
Guideline for a healthy information system v.2.0 (EN):
10 STANDARD
/STANDARD 
ANSSI sets out a collection of rules and best practices in terms of the choice and size of passwords. The most critical one is to make users aware of the risks involved in choosing a password that is too easy to guess, and even the risks of reusing the same password from one application to another, especially for personal and professional mailboxes. 

To supervise and confirm that these choice and size rules are being applied, the organization may use different measures, including: 
  • blocking accounts following several failed logins; 
  • deactivating anonymous login options;
  • using a password robustness checking tool. 
In advance of such procedures, communication aiming to explain the reason for these rules and raise awareness of their importance is fundamental. 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 8.3.4
8.3.4
Определенные Требования к Подходу:
Недопустимые попытки аутентификации ограничены:
  • Блокировкой идентификатора пользователя не более чем после 10 попыток.
  • Установка продолжительности блокировки минимум на 30 минут или до тех пор, пока не будет подтверждена личность пользователя.
Цель Индивидуального подхода:
Фактор аутентификации не может быть угадан при переборе, онлайн-атаке.

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

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

Надлежащая практика:
Перед повторной активацией заблокированной учетной записи необходимо подтвердить личность пользователя. Например, администратор или сотрудники службы поддержки могут подтвердить, что фактический владелец учетной записи запрашивает повторную активацию, или могут быть механизмы самообслуживания сброса пароля, которые владелец учетной записи использует для проверки своей личности
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
УПД.6 УПД.6 Ограничение неуспешных попыток входа в информационную систему (доступа к информационной системе)
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
УПД.6 УПД.6 Ограничение неуспешных попыток доступа в информационную (автоматизированную) систему
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
УПД.6 УПД.6 Ограничение неуспешных попыток доступа в информационную (автоматизированную) систему

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

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