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

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

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

ЗВС.1

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

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

Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ЗИС.11 ЗИС.11 Обеспечение подлинности сетевых соединений (сеансов взаимодействия), в том числе для защиты от подмены сетевых устройств и сервисов
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 8.5.1
8.5.1
Defined Approach Requirements: 
MFA systems are implemented as follows:
  • The MFA system is not susceptible to replay attacks.
  • MFA systems cannot be bypassed by any users, including administrative users unless specifically documented, and authorized by management on an exception basis, for a limited time period.
  • At least two different types of authentication factors are used.
  • Success of all authentication factors is required before access is granted. 
Customized Approach Objective:
MFA systems are resistant to attack and strictly control any administrative overrides. 

Applicability Notes:
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:
  • 8.5.1.a Examine vendor system documentation to verify that the MFA system is not susceptible to replay attacks. 
  • 8.5.1.b Examine system configurations for the MFA implementation to verify it is configured in accordance with all elements specified in this requirement. 
  • 8.5.1.c Interview responsible personnel and observe processes to verify that any requests to bypass MFA are specifically documented and authorized by management on an exception basis, for a limited time period. 
  • 8.5.1.d Observe personnel logging into system components in the CDE to verify that access is granted only after all authentication factors are successful. 
  • 8.5.1.e Observe personnel connecting remotely from outside the entity’s network to verify that access is granted only after all authentication factors are successful. 
Purpose:
Poorly configured MFA systems can be bypassed by attackers. This requirement therefore addresses configuration of MFA system(s) that provide MFA for users accessing system components in the CDE. 

Definitions: 
Using one type of factor twice (for example, using two separate passwords) is not considered multifactor authentication. 

Further Information:
For more information about MFA systems and features, refer to the following: 
  • PCI SSC’s Information Supplement: Multi-Factor Authentication 
  • PCI SSC’s Frequently Asked Questions (FAQs) on this topic. 
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: 
  • 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:
  • 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. 
Guideline for a healthy information system v.2.0 (EN):
21 STANDARD
/STANDARD
Although security is no longer optional today, this has not always been the case. This is why numerous network protocols had to evolve to integrate this component and respond to the confidentiality and integrity requirements that exchanging data requires. Secure network protocols must be used as soon as possible, whether on public networks (the Internet for example) or on the organization’s internal network. 

Although it may be difficult to provide an exhaustive list, the most common protocols rely on the use of TLS and are often identifiable by the addition of the letter "s" (for secure) in the protocol acronym. As an example HTTPS for web browsing or IMAPS, SMTPS or POP3S for email. 

Other protocols were designed securely from their creation to replace prior, insecure protocols. As an example SSH (Secure SHell) which came to replace the TELNET and RLOGIN historic communication protocols.. 
25 STANDARD
/STANDARD
For operational needs, an organization can be required to establish a dedicated network interconnection with a supplier or customer (e.g.: managed services, electronic data interchange, financial flows, etc.) 

This interconnection can be done by a link to a private network of the organization or directly online. In the latter case, it is advisable to establish a site to site tunnel, ideally IPsec, adhering to ANSSI’s recommendations. 

The partner is, by default, considered as unsafe, so it is essential to carry out IP filtering with the assistance of a firewall as close as possible to the flows’ entrance into the organization’s network. The flow matrix (incoming and outgoing) must be strictly reduced to the operational need, maintained over time and the devices’ configuration must be in accordance with it. 
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.
Если удаленный доступ осуществляется к части сети организации, которая должным образом сегментирована от CDE, так что удаленные пользователи не могут получить доступ к CDE или повлиять на него, MFA для удаленного доступа к этой части сети не требуется. Однако MFA требуется для любого удаленного доступа к сетям с доступом к CDE и рекомендуется для всего удаленного доступа к сетям организации.
Требования MFA применяются ко всем типам системных компонентов, включая облачные, размещенные системы и локальные приложения, устройства сетевой безопасности, рабочие станции, серверы и конечные точки, и включают прямой доступ к сетям или системам организации, а также веб-доступ к приложению или функции.

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

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

Примечания по применению:
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

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

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

Дополнительная информация:
Для получения дополнительной информации о системах и функциях MFA обратитесь к следующему:
  • Информационное дополнение PCI SSC: Многофакторная аутентификация
  • Часто задаваемые вопросы (часто задаваемые вопросы) PCI SSC по этой теме.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
ЗИС.11 ЗИС.11 Обеспечение подлинности сетевых соединений (сеансов взаимодействия), в том числе для защиты от подмены сетевых устройств и сервисов
SWIFT Customer Security Controls Framework v2022:
2 - 2.9 Transaction Business Controls
2.9 Transaction Business Controls
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ЗИС.19 ЗИС.19 Защита информации при ее передаче по каналам связи
ЗИС.20 ЗИС.20 Обеспечение доверенных канала, маршрута
ЗИС.27 ЗИС.27 Обеспечение подлинности сетевых соединений
ЗИС.32 ЗИС.32 Защита беспроводных соединений
Положение Банка России № N 757-П от 20.04.2021 "Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций":
1.9.
1.9. Некредитные финансовые организации, реализующие усиленный и стандартный уровни защиты информации, должны обеспечить целостность электронных сообщений и подтвердить их составление уполномоченным на это лицом.
В целях обеспечения целостности электронных сообщений и подтверждения их составления уполномоченным на это лицом некредитные финансовые организации, реализующие усиленный и стандартный уровни защиты информации, должны обеспечивать реализацию мер по использованию усиленной квалифицированной электронной подписи, усиленной неквалифицированной электронной подписи или иных СКЗИ, реализующих функцию имитозащиты информации с аутентификацией отправителя сообщения.
Указанные в абзаце втором настоящего пункта требования по реализации мер по использованию усиленной квалифицированной электронной подписи, усиленной неквалифицированной электронной подписи или иных СКЗИ, реализующих функцию имитозащиты информации с аутентификацией отправителя сообщения, не применяются в случае, если в целях обеспечения целостности электронных сообщений и подтверждения их составления уполномоченным на это лицом при передаче электронных сообщений используются выделенные сегменты вычислительных сетей и указанные меры определены некредитными финансовыми организациями, реализующими усиленный и стандартный уровни защиты информации, как неактуальные в модели угроз и нарушителей безопасности информации.
Признание электронных сообщений, подписанных электронной подписью, равнозначными документам на бумажном носителе, подписанным собственноручной подписью, должно осуществляться в соответствии со статьей 6 Федерального закона "Об электронной подписи" (Собрание законодательства Российской Федерации, 2011, N 15, ст.2036; 2019, N 52, ст.7794).
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ЗИС.20 ЗИС.20 Обеспечение доверенных канала, маршрута
ЗИС.27 ЗИС.27 Обеспечение подлинности сетевых соединений
ЗИС.19 ЗИС.19 Защита информации при ее передаче по каналам связи
ЗИС.32 ЗИС.32 Защита беспроводных соединений

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

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