Куда я попал?
SWIFT Customer Security Controls Framework v2022
Framework
1 - 1.4 Restriction of Internet Access
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
1.4 Restriction of Internet AccessОбязательно для типа архитектуры A1 A2 A3 A4 BОбласть требования: Коннектор SWIFT | Коммуникационный интерфейс SWIFT | Универсальный компьютер оператора SWIFT | Соединение SWIFTNet | Интерфейс обмена сообщениями SWIFT | Графический пользовательский интерфейс SWIFT | Jump Server SWIFT | Выделенный компьютер оператора SWIFT | Промежуточный сервер SWIFT
Похожие требования
Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 7 п. 6 п.п. 4
7.6.4. В организациях БС РФ в связи с повышенными рисками нарушения ИБ при взаимодействии с сетью Интернет должны применяться защитные меры, в том числе межсетевые экраны, антивирусные средства, средства обнаружения вторжений, средства криптографической защиты информации, обеспечивающие, среди прочего, прием и передачу информации только в установленном формате и только для конкретной технологии.
Должны быть разработаны и введены в действие инструкции и рекомендации по использованию сети Интернет, учитывающие особенности банковских технологических процессов.
Должны быть определены и выполняться процедуры протоколирования посещения ресурсов сети Интернет работниками организации БС РФ. Данные о посещенных работниками организации БС РФ ресурсов сети Интернет должны быть доступны работникам службы ИБ.
Должны быть разработаны и введены в действие инструкции и рекомендации по использованию сети Интернет, учитывающие особенности банковских технологических процессов.
Должны быть определены и выполняться процедуры протоколирования посещения ресурсов сети Интернет работниками организации БС РФ. Данные о посещенных работниками организации БС РФ ресурсов сети Интернет должны быть доступны работникам службы ИБ.
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
ПУИ.29
ПУИ.29 Регистрация операций, связанных с осуществлением доступа работниками финансовой организации к ресурсам сети Интернет
3-Н 2-Т 1-Т
3-Н 2-Т 1-Т
ВСА.3
ВСА.3 Контроль отсутствия (выявление) аномальной сетевой активности, связанной с возможным несанкционированным информационным взаимодействием между сегментами, предназначенными для размещения общедоступных объектов доступа (в том числе банкоматов, платежных терминалов), и сетью Интернет
3-Н 2-Н 1-Т
3-Н 2-Н 1-Т
ЦЗИ.3
ЦЗИ.3 Контроль отсутствия и обеспечение оперативного устранения известных (описанных) уязвимостей защиты информации, использование которых может позволить осуществить несанкционированное (неконтролируемое) информационное взаимодействие между сегментами, предназначенными для размещения общедоступных объектов доступа (в том числе банкоматов, платежных терминалов), и сетью Интернет
3-О 2-Т 1-Т
3-О 2-Т 1-Т
NIST Cybersecurity Framework (RU):
PR.AC-5
PR.AC-5: Защищена целостность сети, включая сегрегацию сети при необходимости
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ЗИС.17
ЗИС.17 Разбиение информационной системы на сегменты (сегментирование информационной системы) и обеспечение защиты периметров сегментов информационной системы
ЗСВ.10
ЗСВ.10 Разбиение виртуальной инфраструктуры на сегменты (сегментирование виртуальной инфраструктуры) для обработки персональных данных отдельным пользователем и (или) группой пользователей
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 1.4.4
1.4.4
Defined Approach Requirements:
System components that store cardholder data are not directly accessible from untrusted networks.
Customized Approach Objective:
Stored cardholder data cannot be accessed from untrusted networks.
Applicability Notes:
This requirement is not intended to apply to storage of account data in volatile memory but does apply where memory is being treated as persistent storage (for example, RAM disk). Account data can only be stored in volatile memory during the time necessary to support the associated business process (for example, until completion of the related payment card transaction).
Defined Approach Testing Procedures:
Defined Approach Requirements:
System components that store cardholder data are not directly accessible from untrusted networks.
Customized Approach Objective:
Stored cardholder data cannot be accessed from untrusted networks.
Applicability Notes:
This requirement is not intended to apply to storage of account data in volatile memory but does apply where memory is being treated as persistent storage (for example, RAM disk). Account data can only be stored in volatile memory during the time necessary to support the associated business process (for example, until completion of the related payment card transaction).
Defined Approach Testing Procedures:
- 1.4.4.a Examine the data-flow diagram and network diagram to verify that it is documented that system components storing cardholder data are not directly accessible from the untrusted networks.
- 1.4.4.b Examine configurations of NSCs to verify that controls are implemented such that system components storing cardholder data are not directly accessible from untrusted networks.
Purpose:
Cardholder data that is directly accessible from an untrusted network, for example, because it is stored on a system within the DMZ or in a cloud database service, is easier for an external attacker to access because there are fewer defensive layers to penetrate. Using NSCs to ensure that system components that store cardholder data (such as a database or a file) can only be directly accessed from trusted networks can prevent unauthorized network traffic from reaching the system component.
Cardholder data that is directly accessible from an untrusted network, for example, because it is stored on a system within the DMZ or in a cloud database service, is easier for an external attacker to access because there are fewer defensive layers to penetrate. Using NSCs to ensure that system components that store cardholder data (such as a database or a file) can only be directly accessed from trusted networks can prevent unauthorized network traffic from reaching the system component.
Requirement 1.4.1
1.4.1
Defined Approach Requirements:
NSCs are implemented between trusted and untrusted networks.
Customized Approach Objective:
Unauthorized traffic cannot traverse network boundaries between trusted and untrusted networks.
Defined Approach Testing Procedures:
Defined Approach Requirements:
NSCs are implemented between trusted and untrusted networks.
Customized Approach Objective:
Unauthorized traffic cannot traverse network boundaries between trusted and untrusted networks.
Defined Approach Testing Procedures:
- 1.4.1.a Examine configuration standards and network diagrams to verify that NSCs are defined between trusted and untrusted networks.
- 1.4.1.b Examine network configurations to verify that NSCs are in place between trusted and untrusted networks, in accordance with the documented configuration standards and network diagrams.
Purpose:
Implementing NSCs at every connection coming into and out of trusted networks allows the entity to monitor and control access and minimizes the chances of a malicious individual obtaining access to the internal network via an unprotected connection.
Examples:
An entity could implement a DMZ, which is a part of the network that manages connections between an untrusted network (for examples of untrusted networks refer to the Requirement 1 Overview) and services that an organization needs to have available to the public, such as a web server. Please note that if an entity’s DMZ processes or transmits account data (for example, e-commerce website), it is also considered a CDE
Implementing NSCs at every connection coming into and out of trusted networks allows the entity to monitor and control access and minimizes the chances of a malicious individual obtaining access to the internal network via an unprotected connection.
Examples:
An entity could implement a DMZ, which is a part of the network that manages connections between an untrusted network (for examples of untrusted networks refer to the Requirement 1 Overview) and services that an organization needs to have available to the public, such as a web server. Please note that if an entity’s DMZ processes or transmits account data (for example, e-commerce website), it is also considered a CDE
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.13.1.3
A.13.1.3 Разделение в сетях
Мера обеспечения информационной безопасности: Группы информационных сервисов, пользователей и информационных систем в сети должны быть разделены
Мера обеспечения информационной безопасности: Группы информационных сервисов, пользователей и информационных систем в сети должны быть разделены
Положение Банка России № 802-П от 25.07.2022 "О требованиях к защите информации в платежной системе Банка России":
П. 5
5. ОПКЦ СБП должен размещать объекты информационной инфраструктуры, используемые при предоставлении операционных услуг и услуг платежного клиринга участникам СБП, в выделенных (отдельных) сегментах (группах сегментов) вычислительных сетей.
Для объектов информационной инфраструктуры в пределах выделенного (отдельного) сегмента (группы сегментов) вычислительных сетей ОПКЦ СБП должен применять меры защиты информации, посредством выполнения которых обеспечивается реализация усиленного уровня (уровня 1) защиты информации, предусмотренного пунктом 6.7 раздела 6 ГОСТ Р 57580.1-2017.
П. 6
6. ОУИО СБП должен размещать объекты информационной инфраструктуры, используемые при предоставлении услуг информационного обмена участникам СБП, в выделенных (отдельных) сегментах (группах сегментов) вычислительных сетей.
Для объектов информационной инфраструктуры в пределах выделенного (отдельного) сегмента (группы сегментов) вычислительных сетей ОУИО СБП должен применять меры защиты информации, посредством выполнения которых обеспечивается реализация стандартного уровня (уровня 2) защиты информации, предусмотренного пунктом 6.7 раздела 6 ГОСТ Р 57580.1-2017.
П. 4
4. Участники обмена, международные финансовые организации при осуществлении переводов денежных средств с использованием сервиса быстрых платежей (далее при совместном упоминании - участники СБП) должны размещать объекты информационной инфраструктуры, используемые при осуществлении переводов денежных средств с использованием сервиса быстрых платежей, в выделенных (отдельных) сегментах (группах сегментов) вычислительных сетей.
Для объектов информационной инфраструктуры в пределах выделенного (отдельного) сегмента (группы сегментов) вычислительных сетей участники СБП должны применять меры защиты информации, посредством выполнения которых обеспечивается реализация стандартного уровня (уровня 2) защиты информации, предусмотренного пунктом 6.7 раздела 6 ГОСТ Р 57580.1-2017.
П. 3
3. Участники обмена при осуществлении переводов денежных средств в платежной системе Банка России (далее - осуществление переводов денежных средств) с использованием сервиса срочного перевода и сервиса несрочного перевода (далее - участники ССНП) должны размещать объекты информационной инфраструктуры, используемые при осуществлении переводов денежных средств с использованием сервиса срочного перевода и сервиса несрочного перевода, в выделенных (отдельных) сегментах (группах сегментов) вычислительных сетей.
Для объектов информационной инфраструктуры в пределах выделенного (отдельного) сегмента (группы сегментов) вычислительных сетей участники ССНП должны применять меры защиты информации, посредством выполнения которых обеспечивается реализация стандартного уровня (уровня 2) защиты информации, предусмотренного пунктом 6.7 раздела 6 национального стандарта Российской Федерации ГОСТ Р 57580.1-2017 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер", утвержденного приказом Федерального агентства по техническому регулированию и метрологии от 8 августа 2017 года N 822-ст и введенного в действие 1 января 2018 года (далее - ГОСТ Р 57580.1-2017).
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 1.4.1
1.4.1
Определенные Требования к Подходу:
NSCs реализуются между доверенными и ненадежными сетями.
Цель Индивидуального подхода:
Несанкционированный трафик не может пересекать границы сети между доверенными и ненадежными сетями.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
NSCs реализуются между доверенными и ненадежными сетями.
Цель Индивидуального подхода:
Несанкционированный трафик не может пересекать границы сети между доверенными и ненадежными сетями.
Определенные Процедуры Тестирования Подхода:
- 1.4.1.a Изучите стандарты конфигурации и схемы сети, чтобы убедиться, что NSC определены между доверенными и ненадежными сетями.
- 1.4.1.b Изучите сетевые конфигурации, чтобы убедиться, что NSC установлены между доверенными и ненадежными сетями в соответствии с документированными стандартами конфигураций и сетевыми схемами.
Цель:
Внедрение NSCS при каждом подключении, входящем в доверенные сети и выходящем из них, позволяет организации отслеживать и контролировать доступ и сводит к минимуму вероятность получения злоумышленником доступа к внутренней сети через незащищенное соединение.
Примеры:
Организация может внедрить DMZ, которая является частью сети, которая управляет соединениями между ненадежной сетью (примеры ненадежных сетей см. в обзоре Требования 1) и службами, которые организация должна иметь общедоступными, такими как веб-сервер. Пожалуйста, обратите внимание, что если DMZ организации обрабатывает или передает данные учетной записи (например, веб-сайт электронной коммерции), это также считается CDE
Внедрение NSCS при каждом подключении, входящем в доверенные сети и выходящем из них, позволяет организации отслеживать и контролировать доступ и сводит к минимуму вероятность получения злоумышленником доступа к внутренней сети через незащищенное соединение.
Примеры:
Организация может внедрить DMZ, которая является частью сети, которая управляет соединениями между ненадежной сетью (примеры ненадежных сетей см. в обзоре Требования 1) и службами, которые организация должна иметь общедоступными, такими как веб-сервер. Пожалуйста, обратите внимание, что если DMZ организации обрабатывает или передает данные учетной записи (например, веб-сайт электронной коммерции), это также считается CDE
Requirement 1.4.4
1.4.4
Определенные Требования к Подходу:
Системные компоненты, в которых хранятся данные о держателях карт, недоступны напрямую из ненадежных сетей.
Цель Индивидуального подхода:
Сохраненные данные о держателях карт не могут быть доступны из ненадежных сетей.
Примечания по применению:
Это требование не предназначено для хранения данных учетной записи в энергозависимой памяти, но применяется там, где память используется как постоянное хранилище (например, RAM-диск). Данные учетной записи могут храниться в энергонезависимой памяти только в течение времени, необходимого для поддержки соответствующего бизнес-процесса (например, до завершения соответствующей транзакции по платежной карте).
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Системные компоненты, в которых хранятся данные о держателях карт, недоступны напрямую из ненадежных сетей.
Цель Индивидуального подхода:
Сохраненные данные о держателях карт не могут быть доступны из ненадежных сетей.
Примечания по применению:
Это требование не предназначено для хранения данных учетной записи в энергозависимой памяти, но применяется там, где память используется как постоянное хранилище (например, RAM-диск). Данные учетной записи могут храниться в энергонезависимой памяти только в течение времени, необходимого для поддержки соответствующего бизнес-процесса (например, до завершения соответствующей транзакции по платежной карте).
Определенные Процедуры Тестирования Подхода:
- 1.4.4.a Изучите схему потока данных и сетевую схему, чтобы убедиться, что документально подтверждено, что компоненты системы, хранящие данные о держателях карт, недоступны напрямую из ненадежных сетей.
- 1.4.4.b Изучите конфигурации NSCS, чтобы убедиться, что средства управления реализованы таким образом, чтобы компоненты системы, хранящие данные о держателях карт, не были доступны напрямую из ненадежных сетей.
Цель:
Данные о держателях карт, к которым можно получить прямой доступ из ненадежной сети, например, потому, что они хранятся в системе в пределах DMZ или в облачной службе баз данных, легче получить доступ внешнему злоумышленнику, поскольку существует меньше защитных уровней для проникновения. Использование NSCS для обеспечения того, чтобы к компонентам системы, в которых хранятся данные о держателях карт (например, к базе данных или файлу), можно было получить прямой доступ только из доверенных сетей, может предотвратить попадание несанкционированного сетевого трафика на системный компонент.
Данные о держателях карт, к которым можно получить прямой доступ из ненадежной сети, например, потому, что они хранятся в системе в пределах DMZ или в облачной службе баз данных, легче получить доступ внешнему злоумышленнику, поскольку существует меньше защитных уровней для проникновения. Использование NSCS для обеспечения того, чтобы к компонентам системы, в которых хранятся данные о держателях карт (например, к базе данных или файлу), можно было получить прямой доступ только из доверенных сетей, может предотвратить попадание несанкционированного сетевого трафика на системный компонент.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
ЗИС.17
ЗИС.17 Разбиение информационной системы на сегменты (сегментирование информационной системы) и обеспечение защиты периметров сегментов информационной системы
ЗСВ.10
ЗСВ.10 Разбиение виртуальной инфраструктуры на сегменты (сегментирование виртуальной инфраструктуры) для обработки информации отдельным пользователем и (или) группой пользователей
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.22
А.8.22 Сегментирование сетей
Сеть организации должны быть сегментирована на группы информационных сервисов, пользователей и информационных систем.
Сеть организации должны быть сегментирована на группы информационных сервисов, пользователей и информационных систем.
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ЗИС.4
ЗИС.4 Сегментирование информационной (автоматизированной) системы
NIST Cybersecurity Framework (EN):
PR.AC-5
PR.AC-5: Network integrity is protected (e.g., network segregation, network segmentation)
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ЗИС.4
ЗИС.4 Сегментирование информационной (автоматизированной) системы
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
13.1.3
13.1.3 Разделение в сетях
Мера обеспечения ИБ
Группы информационных сервисов, пользователей и информационных систем в сети должны быть разделены.
Руководство по применению
Одним из методов управления безопасностью больших сетей является разделение их на отдельные сетевые домены. Домены могут быть выбраны на основе уровней доверия (например, общедоступный домен, домен рабочих станций, домен сервера), на основе организационных подразделений (например, кадры, финансы, маркетинг) или на основе некоторой комбинации признаков (например, домен сервера, соединенный с несколькими организационными подразделениями). Разделение может быть выполнено физическим разделением на разные сети либо логическим (например, виртуальные частные сети).
Границы каждого домена должны быть четко определены. Доступ между сетевыми доменами может быть разрешен, но должен контролироваться на границе с использованием шлюза (например, межсетевого экрана, фильтрующего маршрутизатора). Критерии разделения сетей на домены и разрешение доступа через шлюзы должны основываться на оценке требований по безопасности каждого домена. Оценка должна проводиться в соответствии с политикой управления доступом (см. 9.1.1) и требованиями к доступу, в соответствии с ценностью и категорией обрабатываемой информации, а также с учетом относительной стоимости и влияния применяемой технологии шлюза на производительность.
Беспроводные сети требуют особого подхода в силу того, что их границы не являются достаточно определенными. В отношении чувствительных сегментов следует принять подход, при котором все запросы на беспроводной доступ следует рассматривать как внешние и отделять их от запросов внутренних сетей до тех пор, пока запрос не пройдет шлюз и не будет разрешен доступ к внутренним системам в соответствии с политикой обеспечения ИБ сетей (см. 13.1.1).
Технологии аутентификации, шифрования и управления доступом к сети на уровне пользователя, основанные на современных стандартах беспроводных сетей, при должной реализации могут быть достаточными для прямого подключения к внутренней сети организации.
Дополнительная информация
Сети часто выходят за границы организации, поскольку создаются деловые отношения, которые требуют объединения или совместного использования сетевого оборудования и устройств обработки информации. Такие действия могут увеличивать риск неавторизованного доступа к информационным системам организации, использующим сеть, причем в отношении некоторых из этих систем может потребоваться защита от пользователей другой сети в силу их чувствительности или критичности.
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.8.22
А.8.22 Segregation of networks
Groups of information services, users and information systems shall be segregated in the organization’s networks.
Groups of information services, users and information systems shall be segregated in the organization’s networks.
Связанные защитные меры
| Название | Дата | Влияние | ||
|---|---|---|---|---|
|
Community
1
3 / 44
|
Ограничение (блокировка) доступа к некорпоративным облачным сервисам
Автоматически
Техническая
Превентивная
09.11.2021
|
09.11.2021 | 1 3 / 44 | |
|
Community
1
3 / 44
|
Обнаружение записи рабочей информации в некорпоративные облачные сервисы
Автоматически
Техническая
09.11.2021
|
09.11.2021 | 1 3 / 44 |
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.