Куда я попал?
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC)
Framework
6.4
Для проведения оценки соответствия по документу войдите в систему.
Похожие требования
NIST Cybersecurity Framework (RU):
PR.AC-7
PR.AC-7: Пользователи, устройства и другие активы проходят аутентификацию (например, однофакторную, многофакторную), соизмеримую с риском транзакции (например, рисками безопасности и конфиденциальности отдельных лиц и другими организационными рисками)
PR.AC-3
PR.AC-3: Управляется процесс предоставления удаленного доступа
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 2.2.7
2.2.7
Defined Approach Requirements:
All non-console administrative access is encrypted using strong cryptography.
Customized Approach Objective:
Cleartext administrative authorization factors cannot be read or intercepted from any network transmissions.
Applicability Notes:
This includes administrative access via browserbased interfaces and application programming interfaces (APIs).
Defined Approach Testing Procedures:
Defined Approach Requirements:
All non-console administrative access is encrypted using strong cryptography.
Customized Approach Objective:
Cleartext administrative authorization factors cannot be read or intercepted from any network transmissions.
Applicability Notes:
This includes administrative access via browserbased interfaces and application programming interfaces (APIs).
Defined Approach Testing Procedures:
- 2.2.7.a Examine system configuration standards to verify they include encrypting all non-console administrative access using strong cryptography.
- 2.2.7.b Observe an administrator log on to system components and examine system configurations to verify that non-console administrative access is managed in accordance with this requirement.
- 2.2.7.c Examine settings for system components and authentication services to verify that insecure remote login services are not available for nonconsole administrative access.
- 2.2.7.d Examine vendor documentation and interview personnel to verify that strong cryptography for the technology in use is implemented according to industry best practices and/or vendor recommendations.
rpose:
If non-console (including remote) administration does not use encrypted communications, administrative authorization factors (such as IDs and passwords) can be revealed to an eavesdropper. A malicious individual could use this information to access the network, become administrator, and steal data.
Good Practice:
Whichever security protocol is used, it should be configured to use only secure versions and configurations to prevent use of an insecure connection—for example, by using only trusted certificates, supporting only strong encryption, and not supporting fallback to weaker, insecure protocols or methods.
Examples:
Cleartext protocols (such as HTTP, telnet, etc.) do not encrypt traffic or logon details, making it easy for an eavesdropper to intercept this information. Non-console access may be facilitated by technologies that provide alternative access to systems, including but not limited to, out-of-band (OOB), lights-out management (LOM), Intelligent Platform Management Interface (IPMI), and keyboard, video, mouse (KVM) switches with remote capabilities. These and other non-console access technologies and methods must be secured with strong cryptography
Further Information:
Refer to industry standards and best practices such as NIST SP 800-52 and SP 800-57.
If non-console (including remote) administration does not use encrypted communications, administrative authorization factors (such as IDs and passwords) can be revealed to an eavesdropper. A malicious individual could use this information to access the network, become administrator, and steal data.
Good Practice:
Whichever security protocol is used, it should be configured to use only secure versions and configurations to prevent use of an insecure connection—for example, by using only trusted certificates, supporting only strong encryption, and not supporting fallback to weaker, insecure protocols or methods.
Examples:
Cleartext protocols (such as HTTP, telnet, etc.) do not encrypt traffic or logon details, making it easy for an eavesdropper to intercept this information. Non-console access may be facilitated by technologies that provide alternative access to systems, including but not limited to, out-of-band (OOB), lights-out management (LOM), Intelligent Platform Management Interface (IPMI), and keyboard, video, mouse (KVM) switches with remote capabilities. These and other non-console access technologies and methods must be secured with strong cryptography
Further Information:
Refer to industry standards and best practices such as NIST SP 800-52 and SP 800-57.
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:
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:
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.
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 8.4.3
8.4.3
Defined Approach Requirements:
MFA is implemented for all remote network access originating from outside the entity’s network that could access or impact the CDE as follows:
Defined Approach Requirements:
MFA is implemented for all remote network access originating from outside the entity’s network that could access or impact the CDE as follows:
- All remote access by all personnel, both users and administrators, originating from outside the entity’s network.
- All remote access by third parties and vendors.
Customized Approach Objective:
Remote access to the entity’s network cannot be obtained by using a single authentication factor.
Applicability Notes:
The requirement for MFA for remote access originating from outside the entity’s network applies to all user accounts that can access the network remotely, where that remote access leads to or could lead to access into the CDE.
If remote access is to a part of the entity’s network that is properly segmented from the CDE, such that remote users cannot access or impact the CDE, MFA for remote access to that part of the network is not required. However, MFA is required for any remote access to networks with access to the CDE and is recommended for all remote access to the entity’s networks.
The MFA requirements apply for all types of system components, including cloud, hosted systems, and on-premises applications, network security devices, workstations, servers, and endpoints, and includes access directly to an entity’s networks or systems as well as web-based access to an application or function.
Defined Approach Testing Procedures:
Remote access to the entity’s network cannot be obtained by using a single authentication factor.
Applicability Notes:
The requirement for MFA for remote access originating from outside the entity’s network applies to all user accounts that can access the network remotely, where that remote access leads to or could lead to access into the CDE.
If remote access is to a part of the entity’s network that is properly segmented from the CDE, such that remote users cannot access or impact the CDE, MFA for remote access to that part of the network is not required. However, MFA is required for any remote access to networks with access to the CDE and is recommended for all remote access to the entity’s networks.
The MFA requirements apply for all types of system components, including cloud, hosted systems, and on-premises applications, network security devices, workstations, servers, and endpoints, and includes access directly to an entity’s networks or systems as well as web-based access to an application or function.
Defined Approach Testing Procedures:
- 8.4.3.a Examine network and/or system configurations for remote access servers and systems to verify MFA is required in accordance with all elements specified in this requirement.
- 8.4.3.b Observe personnel (for example, users and administrators) connecting remotely to the network and verify that multi-factor authentication is required.
Purpose:
Requiring more than one type of authentication factor reduces the probability that an attacker can gain access to a system by masquerading as a legitimate user, because the attacker would need to compromise multiple authentication factors. This is especially true in environments where traditionally the single authentication factor employed was something a user knows, such as a password or passphrase.
Definitions:
Multi-factor authentication (MFA) requires an individual to present a minimum of two of the three authentication factors specified in Requirement 8.3.1 before access is granted. Using one factor twice (for example, using two separate passwords) is not considered multifactor authentication.
Requiring more than one type of authentication factor reduces the probability that an attacker can gain access to a system by masquerading as a legitimate user, because the attacker would need to compromise multiple authentication factors. This is especially true in environments where traditionally the single authentication factor employed was something a user knows, such as a password or passphrase.
Definitions:
Multi-factor authentication (MFA) requires an individual to present a minimum of two of the three authentication factors specified in Requirement 8.3.1 before access is granted. Using one factor twice (for example, using two separate passwords) is not considered multifactor authentication.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.9.4.2
A.9.4.2 Безопасные процедуры входа в систему
Мера обеспечения информационной безопасности: Когда этого требует политика управления доступом, доступ к системам и приложениям должен управляться посредством безопасной процедуры входа в систему
Мера обеспечения информационной безопасности: Когда этого требует политика управления доступом, доступ к системам и приложениям должен управляться посредством безопасной процедуры входа в систему
A.6.2.2
A.6.2.2 Дистанционная работа
Мера обеспечения информационной безопасности: Следует определить политику и реализовать поддерживающие меры безопасности для защиты информации, доступ к которой, обработка или хранение осуществляются в местах дистанционной работы
Мера обеспечения информационной безопасности: Следует определить политику и реализовать поддерживающие меры безопасности для защиты информации, доступ к которой, обработка или хранение осуществляются в местах дистанционной работы
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 12.11
CSC 12.11 Require All Remote Login to Use Multi-Factor Authentication
Require all remote login access to the organization's network to encrypt data in transit and use multi-factor authentication.
Require all remote login access to the organization's network to encrypt data in transit and use multi-factor authentication.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 8.4.3
8.4.3
Определенные Требования к Подходу:
MFA реализуется для всего удаленного доступа к сети, исходящего из-за пределов сети организации, который может получить доступ к CDE или повлиять на него следующим образом:
Определенные Требования к Подходу:
MFA реализуется для всего удаленного доступа к сети, исходящего из-за пределов сети организации, который может получить доступ к CDE или повлиять на него следующим образом:
- Весь удаленный доступ для всего персонала, как пользователей, так и администраторов, исходящий из-за пределов сети организации.
- Весь удаленный доступ третьих сторон и поставщиков.
Цель Индивидуального подхода:
Удаленный доступ к сети объекта не может быть получен с помощью одного фактора аутентификации.
Примечания по применению:
Требование для MFA для удаленного доступа, исходящего из-за пределов сети организации, применяется ко всем учетным записям пользователей, которые могут получать удаленный доступ к сети, если этот удаленный доступ ведет или может привести к доступу к CDE.
Если удаленный доступ осуществляется к части сети организации, которая должным образом сегментирована от CDE, так что удаленные пользователи не могут получить доступ к CDE или повлиять на него, MFA для удаленного доступа к этой части сети не требуется. Однако MFA требуется для любого удаленного доступа к сетям с доступом к CDE и рекомендуется для всего удаленного доступа к сетям организации.
Требования MFA применяются ко всем типам системных компонентов, включая облачные, размещенные системы и локальные приложения, устройства сетевой безопасности, рабочие станции, серверы и конечные точки, и включают прямой доступ к сетям или системам организации, а также веб-доступ к приложению или функции.
Определенные Процедуры Тестирования Подхода:
Удаленный доступ к сети объекта не может быть получен с помощью одного фактора аутентификации.
Примечания по применению:
Требование для MFA для удаленного доступа, исходящего из-за пределов сети организации, применяется ко всем учетным записям пользователей, которые могут получать удаленный доступ к сети, если этот удаленный доступ ведет или может привести к доступу к CDE.
Если удаленный доступ осуществляется к части сети организации, которая должным образом сегментирована от CDE, так что удаленные пользователи не могут получить доступ к CDE или повлиять на него, MFA для удаленного доступа к этой части сети не требуется. Однако MFA требуется для любого удаленного доступа к сетям с доступом к CDE и рекомендуется для всего удаленного доступа к сетям организации.
Требования MFA применяются ко всем типам системных компонентов, включая облачные, размещенные системы и локальные приложения, устройства сетевой безопасности, рабочие станции, серверы и конечные точки, и включают прямой доступ к сетям или системам организации, а также веб-доступ к приложению или функции.
Определенные Процедуры Тестирования Подхода:
- 8.4.3. Требуется проверка сетевых и/или системных конфигураций серверов и систем удаленного доступа для проверки MFA в соответствии со всеми элементами, указанными в этом требовании.
- 8.4.3.b Наблюдайте за персоналом (например, пользователями и администраторами), удаленно подключающимся к сети, и убедитесь, что требуется многофакторная аутентификация.
Цель:
Требование более одного типа фактора аутентификации снижает вероятность того, что злоумышленник сможет получить доступ к системе, выдавая себя за законного пользователя, поскольку злоумышленнику потребуется скомпрометировать несколько факторов аутентификации. Это особенно верно в средах, где традиционно единственным фактором аутентификации было то, что известно пользователю, например пароль или кодовая фраза.
Определения:
Многофакторная аутентификация (MFA) требует, чтобы пользователь представил минимум два из трех факторов аутентификации, указанных в требовании 8.3.1, прежде чем будет предоставлен доступ. Использование одного фактора дважды (например, использование двух отдельных паролей) не считается многофакторной аутентификацией.
Требование более одного типа фактора аутентификации снижает вероятность того, что злоумышленник сможет получить доступ к системе, выдавая себя за законного пользователя, поскольку злоумышленнику потребуется скомпрометировать несколько факторов аутентификации. Это особенно верно в средах, где традиционно единственным фактором аутентификации было то, что известно пользователю, например пароль или кодовая фраза.
Определения:
Многофакторная аутентификация (MFA) требует, чтобы пользователь представил минимум два из трех факторов аутентификации, указанных в требовании 8.3.1, прежде чем будет предоставлен доступ. Использование одного фактора дважды (например, использование двух отдельных паролей) не считается многофакторной аутентификацией.
Requirement 8.3.1
8.3.1
Определенные Требования к Подходу:
Весь пользовательский доступ к системным компонентам для пользователей и администраторов проверяется с помощью по крайней мере одного из следующих факторов аутентификации:
Определенные Требования к Подходу:
Весь пользовательский доступ к системным компонентам для пользователей и администраторов проверяется с помощью по крайней мере одного из следующих факторов аутентификации:
- Что-то, что вы знаете, например, пароль или кодовую фразу.
- Что-то, что у вас есть, например, токен-устройство или смарт-карта.
- Что-то, чем вы являетесь, например, биометрический элемент.
Цель Индивидуального подхода:
Доступ к учетной записи возможен только с использованием комбинации идентификатора пользователя и фактора аутентификации.
Примечания по применению:
Это требование не предназначено для применения к учетным записям пользователей в торговых терминалах, которые имеют доступ только к одному номеру карты одновременно для облегчения одной транзакции (например, идентификаторы, используемые кассирами в торговых терминалах).
Это требование не заменяет требования к многофакторной аутентификации (MFA), но применяется к тем системам, которые в других случаях не подпадают под требования MFA.
Цифровой сертификат является допустимым вариантом для “того, что у вас есть”, если он уникален для конкретного пользователя.
Определенные Процедуры Тестирования Подхода:
Доступ к учетной записи возможен только с использованием комбинации идентификатора пользователя и фактора аутентификации.
Примечания по применению:
Это требование не предназначено для применения к учетным записям пользователей в торговых терминалах, которые имеют доступ только к одному номеру карты одновременно для облегчения одной транзакции (например, идентификаторы, используемые кассирами в торговых терминалах).
Это требование не заменяет требования к многофакторной аутентификации (MFA), но применяется к тем системам, которые в других случаях не подпадают под требования MFA.
Цифровой сертификат является допустимым вариантом для “того, что у вас есть”, если он уникален для конкретного пользователя.
Определенные Процедуры Тестирования Подхода:
- 8.3.1.a Изучить документацию, описывающую фактор (ы) аутентификации, используемый(ые) для проверки того, что доступ пользователя к компонентам системы аутентифицируется по крайней мере с помощью одного фактора аутентификации, указанного в этом требовании.
- 8.3.1.b Для каждого типа фактора аутентификации, используемого с каждым типом системного компонента, соблюдайте аутентификацию, чтобы убедиться, что аутентификация работает в соответствии с задокументированным фактором (факторами) аутентификации.
Цель:
При использовании в дополнение к уникальным идентификаторам фактор аутентификации помогает защитить идентификаторы пользователей от взлома, поскольку злоумышленнику необходимо иметь уникальный идентификатор и скомпрометировать связанные с ним факторы аутентификации.
Надлежащая практика:
Распространенный подход злоумышленника к компрометации системы заключается в использовании слабых или несуществующих факторов аутентификации (например, паролей/парольных фраз). Требование надежных факторов аутентификации помогает защититься от этой атаки.
Дополнительная информация:
См. fidoalliance.org дополнительные сведения об использовании токенов, смарт-карт или биометрических данных в качестве факторов аутентификации см.
При использовании в дополнение к уникальным идентификаторам фактор аутентификации помогает защитить идентификаторы пользователей от взлома, поскольку злоумышленнику необходимо иметь уникальный идентификатор и скомпрометировать связанные с ним факторы аутентификации.
Надлежащая практика:
Распространенный подход злоумышленника к компрометации системы заключается в использовании слабых или несуществующих факторов аутентификации (например, паролей/парольных фраз). Требование надежных факторов аутентификации помогает защититься от этой атаки.
Дополнительная информация:
См. fidoalliance.org дополнительные сведения об использовании токенов, смарт-карт или биометрических данных в качестве факторов аутентификации см.
Requirement 2.2.7
2.2.7
Определенные Требования к Подходу:
Весь административный доступ, не связанный с консольным доступом, шифруется с использованием надежной криптографии.
Цель Индивидуального подхода:
Открытые текстовые факторы авторизации администратора не могут быть прочитаны или перехвачены из любых сетевых передач.
Примечания по применению:
Это включает в себя административный доступ через браузерные интерфейсы и интерфейсы прикладного программирования (API).
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Весь административный доступ, не связанный с консольным доступом, шифруется с использованием надежной криптографии.
Цель Индивидуального подхода:
Открытые текстовые факторы авторизации администратора не могут быть прочитаны или перехвачены из любых сетевых передач.
Примечания по применению:
Это включает в себя административный доступ через браузерные интерфейсы и интерфейсы прикладного программирования (API).
Определенные Процедуры Тестирования Подхода:
- 2.2.7.a Изучите стандарты конфигурации системы, чтобы убедиться, что они включают шифрование всего неконсольного административного доступа с использованием надежной криптографии.
- 2.2.7.b Наблюдайте за входом администратора в системные компоненты и изучайте системные конфигурации, чтобы убедиться, что административный доступ, не связанный с консолью, управляется в соответствии с этим требованием.
- 2.2.7.c Проверьте настройки системных компонентов и служб аутентификации, чтобы убедиться, что небезопасные службы удаленного входа недоступны для неконсольного административного доступа.
- 2.2.7.d Изучите документацию поставщика и опросите персонал, чтобы убедиться, что надежная криптография для используемой технологии реализована в соответствии с лучшими отраслевыми практиками и/или рекомендациями поставщика.
Цель:
Если неконсольное (в том числе удаленное) администрирование не использует зашифрованные сообщения, факторы авторизации администратора (такие как идентификаторы и пароли) могут быть раскрыты злоумышленнику. Злоумышленник может использовать эту информацию для доступа к сети, стать администратором и украсть данные.
Надлежащая практика:
Какой бы протокол безопасности ни использовался, он должен быть настроен на использование только безопасных версий и конфигураций, чтобы предотвратить использование небезопасного соединения — например, используя только доверенные сертификаты, поддерживая только надежное шифрование и не поддерживая возврат к более слабым, небезопасным протоколам или методам.
Примеры:
Протоколы открытого текста (такие как HTTP, telnet и т.д.) не шифруют трафик или данные входа в систему, что упрощает перехват этой информации злоумышленником. Неконсольный доступ может быть облегчен с помощью технологий, обеспечивающих альтернативный доступ к системам, включая, но не ограничиваясь этим, внеполосный (OOB), управление отключением света (LOM), Интеллектуальный интерфейс управления платформой (IPMI) и переключатели клавиатуры, видео, мыши (KVM) с удаленными возможностями. Эти и другие технологии и методы, не связанные с консольным доступом, должны быть защищены надежной криптографией
Дополнительная информация:
Обратитесь к отраслевым стандартам и передовой практике, таким как NIST SP 800-52 и SP 800-57.
Если неконсольное (в том числе удаленное) администрирование не использует зашифрованные сообщения, факторы авторизации администратора (такие как идентификаторы и пароли) могут быть раскрыты злоумышленнику. Злоумышленник может использовать эту информацию для доступа к сети, стать администратором и украсть данные.
Надлежащая практика:
Какой бы протокол безопасности ни использовался, он должен быть настроен на использование только безопасных версий и конфигураций, чтобы предотвратить использование небезопасного соединения — например, используя только доверенные сертификаты, поддерживая только надежное шифрование и не поддерживая возврат к более слабым, небезопасным протоколам или методам.
Примеры:
Протоколы открытого текста (такие как HTTP, telnet и т.д.) не шифруют трафик или данные входа в систему, что упрощает перехват этой информации злоумышленником. Неконсольный доступ может быть облегчен с помощью технологий, обеспечивающих альтернативный доступ к системам, включая, но не ограничиваясь этим, внеполосный (OOB), управление отключением света (LOM), Интеллектуальный интерфейс управления платформой (IPMI) и переключатели клавиатуры, видео, мыши (KVM) с удаленными возможностями. Эти и другие технологии и методы, не связанные с консольным доступом, должны быть защищены надежной криптографией
Дополнительная информация:
Обратитесь к отраслевым стандартам и передовой практике, таким как NIST SP 800-52 и SP 800-57.
Методика экспресс-оценки уровня кибербезопасности организации РезБез:
6.3.1.
Разработаны и внедрены сценарные условия удаленного доступа к системам и приложениям организации
6.3.1.2.
Для удаленного доступа к системам и приложениям используется многофакторная аутентификация
SWIFT Customer Security Controls Framework v2022:
4 - 4.2 Multi-Factor Authentication
4.2 Multi-Factor Authentication
NIST Cybersecurity Framework (EN):
PR.AC-7
PR.AC-7: Users, devices, and other assets are authenticated (e.g., single-factor, multi-factor) commensurate with the risk of the transaction (e.g., individuals’ security and privacy risks and other organizational risks)
PR.AC-3
PR.AC-3: Remote access is managed
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
9.4.2
9.4.2 Безопасные процедуры входа в систему
Мера обеспечения ИБ
Когда этого требует политика управления доступом, доступ к системам и приложениям должен управляться посредством безопасной процедуры входа в систему.
Руководство по применению
Должны быть выбраны подходящие методы аутентификации для подтверждения заявленной личности пользователя.
Там, где требуется строгая аутентификация и проверка личности, должны использоваться методы аутентификации, альтернативные паролям, такие как криптографические средства, смарт-карты, токены или биометрические средства.
Процедура входа в систему или приложение должна быть разработана таким образом, чтобы минимизировать возможность несанкционированного доступа. Таким образом, процедура входа в систему должна раскрывать минимум информации о системе или приложении, во избежание оказания какой-либо неумышленной помощи неавторизованному пользователю. Разработанная надлежащим образом процедура входа должна:
- a) не отображать идентификаторы системы или приложения до тех пор, пока процесс входа успешно не завершен;
- b) выводить общее предупреждение, что доступ к компьютеру предоставляется только авторизованным пользователям;
- c) не предоставлять подсказок во время процедуры входа, которые могли бы помочь неавторизованному пользователю;
- d) осуществлять подтверждение информации для входа только после завершения ввода всех данных. Если возникает ошибка, система не должна указывать, какая часть данных для входа является правильной или неправильной;
- e) защищать от попыток входа в систему методом полного перебора (грубой силы);
- f) регистрировать неуспешные и успешные попытки входа;
- g) фиксировать событие безопасности при обнаружении попыток или фактов успешного нарушения процедуры входа;
- h) отображать следующую информацию по завершении успешного входа в систему:
- - дата и время предыдущего успешного входа;
- - сведения всех неудачных попыток входа с момента последнего успешного входа;
- i) не отображать вводимый пароль;
- j) не передавать пароли в открытом виде по сети;
- k) завершать неактивные сессии после определенного периода бездействия, особенно в местах повышенного риска, таких как общественные места или точки за пределами организации, которые не попадают под контроль системы менеджмента информационной безопасности организации, или на мобильных устройствах;
- l) ограничивать время соединения для обеспечения дополнительной защиты приложений с высоким риском и снижения возможности несанкционированного доступа.
Дополнительная информация
Пароли являются наиболее распространенным способом обеспечения идентификации и аутентификации на основе использования секрета, который знает только пользователь. То же самое может быть достигнуто при использовании криптографических средств и протоколов аутентификации. Надежность аутентификации пользователя должна соответствовать категории информации, к которой осуществляется доступ.
Если пароли передаются по сети в открытом виде во время процедуры входа, они могут быть перехвачены программой анализа сетевого трафика.
6.2.2
6.2.2 Дистанционная работа
Мера обеспечения ИБ
Должна быть определена политика и реализованы поддерживающие меры безопасности для защиты информации, доступ к которой, обработку или хранение осуществляют в местах дистанционной работы.
Руководство по применению
В организациях, предусматривающих возможность дистанционной работы, должна издаваться политика, определяющая условия и ограничения для дистанционной работы. В тех случаях, когда это применимо и разрешено законом, следует рассмотреть следующие вопросы:
- a) существующая физическая защита удаленного места работы с учетом физической безопасности здания и местности;
- b) предлагаемая физическая среда дистанционной работы;
- c) требования к безопасности связи с учетом необходимости удаленного доступа к внутренним системам организации, чувствительности этих систем, а также с учетом информации ограниченного доступа, к которой будут осуществлять доступ и которую будут передавать по линиям связи;
- d) предоставление доступа к виртуальному рабочему столу, который предотвращает обработку и хранение информации на личном оборудовании;
- e) угроза несанкционированного доступа к информации или ресурсам со стороны других лиц, находящихся в этом же помещении, например членов семьи или друзей;
- f) использование домашних сетей и установление требований или ограничений на конфигурацию сервисов беспроводных сетей;
- g) политики и процедуры для предотвращения споров, касающихся прав на интеллектуальную собственность, разработанную на личном оборудовании;
- h) доступ к личному оборудованию (для проверки его безопасности или в ходе расследования) может быть запрещен законодательством;
- i) лицензионные соглашения на программное обеспечение, в соответствии с которыми организация может нести ответственность за лицензирование клиентского программного обеспечения на личных рабочих станциях работников или внешних пользователей;
- j) требования к защите от вредоносных программ и межсетевым экранам.
Руководящие принципы и меры, которые следует учитывать, должны включать в себя:
- a) предоставление подходящего оборудования для дистанционной работы и устройств хранения в тех случаях, когда использование личного оборудования, не находящегося под контролем организации, не допускается;
- b) определение разрешенных работ, часов работы, категорий информации, которую можно обрабатывать, а также определение внутренних систем и сервисов, к которым разрешен доступ дистанционному работнику;
- c) предоставление соответствующего коммуникационного оборудования, включая способы обеспечения безопасного удаленного доступа;
- d) физическую безопасность;
- e) правила и рекомендации по доступу членов семьи и посетителей к оборудованию и информации;
- f) предоставление технической и программной поддержки и обслуживания;
- g) страхование;
- h) процедуры резервного копирования и обеспечения непрерывности бизнеса;
- i) аудит и мониторинг безопасности;
- j) аннулирование полномочий и прав доступа, а также возврат оборудования по окончании дистанционной работы;
- k) предоставление доступа к корпоративной информации.
Дополнительная информация
К термину "дистанционная работа" относятся все формы работы вне офиса, в том числе нетрадиционная рабочая среда, такая как "работа на дому", "гибкое рабочее место" и "виртуальное рабочее место".
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.