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

ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022

Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А

A.14.1.3

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

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

Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 7 п. 8 п.п. 6
7.8.6. Комплекс защитных мер банковского платежного технологического процесса должен предусматривать, в том числе:
  • защиту платежной информации от искажения, фальсификации, переадресации, несанкционированного уничтожения, ложной авторизации электронных платежных сообщений;
  • доступ работника организации БС РФ только к тем ресурсам банковского платежного технологического процесса, которые необходимы ему для исполнения должностных обязанностей или реализации прав, предусмотренных технологией обработки платежной информации;
  • контроль (мониторинг) исполнения установленной технологии подготовки, обработки, передачи и хранения платежной информации;
  • аутентификацию входящих электронных платежных сообщений;
  • двустороннюю аутентификацию автоматизированных рабочих мест (рабочих станций и серверов), участников обмена электронными платежными сообщениями;
  • возможность ввода платежной информации в АБС только для авторизованных пользователей;
  • контроль, направленный на исключение возможности совершения злоумышленных действий, в частности двойной ввод, сверка, установление ограничений в зависимости от суммы совершаемых операций;
  • восстановление платежной информации в случае ее умышленного (случайного) разрушения (искажения) или выхода из строя средств вычислительной техники;
  • сверку выходных электронных платежных сообщений с соответствующими входными и обработанными электронными платежными сообщениями при осуществлении межбанковских расчетов;
  • возможность блокирования приема к исполнению распоряжений клиентов;
  • доставку электронных платежных сообщений участникам обмена.
Кроме того, в организации БС РФ рекомендуется организовать авторизованный ввод платежной информации в АБС двумя работниками с последующей программной сверкой результатов ввода на совпадение (принцип "двойного управления").
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
MAC.11
MAC.11 Реализация защиты данных регистрации о событиях защиты информации от раскрытия и модификации, двухсторонней аутентификации при передаче данных регистрации с использованием сети Интернет
3-Н 2-Т 1-Т
ЗБС.2
ЗБС.2 Защита информации от раскрытия и модификации при ее передаче с использованием протоколов беспроводного доступа
3-Т 2-Т 1-Т
ЗВС.2
ЗВС.2 Реализация защиты информации от раскрытия и модификации, применение двухсторонней аутентификации при ее передаче с использованием сети Интернет, телекоммуникационных каналов и (или) линий связи, не контролируемых финансовой организацией
3-Т 2-Т 1-Т
NIST Cybersecurity Framework (RU):
PR.DS-6
PR.DS-6: Механизмы проверки целостности используются для проверки программного обеспечения, встроенного  программного обеспечения и целостности информации. 
PR.DS-5
PR.DS-5:  Реализована защита от утечки данных
PR.DS-2
PR.DS-2: Данные при передаче защищаются  
PR.PT-4
PR.PT-4: Защищены сети связи и управления 
PR.AC-5
PR.AC-5: Защищена целостность сети, включая сегрегацию сети при необходимости
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ЗИС.3 ЗИС.3 Обеспечение защиты персональных данных от раскрытия, модификации и навязывания (ввода ложной информации) при ее передаче (подготовке к передаче) по каналам связи, имеющим выход за пределы контролируемой зоны, в том числе беспроводным каналам связи
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 4.2.1
4.2.1
Defined Approach Requirements: 
Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open, public networks:
  • Only trusted keys and certificates are accepted.
  • Certificates used to safeguard PAN during transmission over open, public networks are confirmed as valid and are not expired or revoked. This bullet is a best practice until its effective date; refer to applicability notes below for details.
  • The protocol in use supports only secure versions or configurations and does not support fallback to, or use of insecure versions, algorithms, key sizes, or implementations.
  • The encryption strength is appropriate for the encryption methodology in use. 
Customized Approach Objective:
Cleartext PAN cannot be read or intercepted from any transmissions over open, public networks. 

Defined Approach Testing Procedures:
  • 4.2.1.a Examine documented policies and procedures and interview personnel to verify processes are defined to include all elements specified in this requirement. 
  • 4.2.1.b Examine system configurations to verify that strong cryptography and security protocols are implemented in accordance with all elements specified in this requirement. 
  • 4.2.1.c Examine cardholder data transmissions to verify that all PAN is encrypted with strong cryptography when it is transmitted over open, public networks. 
  • 4.2.1.d Examine system configurations to verify that keys and/or certificates that cannot be verified as trusted are rejected. 
Purpose:
Sensitive information must be encrypted during transmission over public networks because it is easy and common for a malicious individual to intercept and/or divert data while in transit. 

Good Practice:
The network and data-flow diagrams defined in Requirement 1 are useful resources for identifying all connection points where account data is transmitted or received over open, public networks. 
While not required, it is considered a good practice for entities to also encrypt PAN over their internal networks, and for entities to establish any new network implementations with encrypted communications. 
PAN transmissions can be protected by encrypting the data before it is transmitted, or by encrypting the session over which the data is transmitted, or both. While it is not required that strong cryptography be applied at both the data level and the session level, it is strongly recommended. If encrypted at the data level, the cryptographic keys used for protecting the data can be managed in accordance with Requirements 3.6 and 3.7. If the data is encrypted at the session level, designated key custodians should be assigned responsibility for managing transmission keys and certificates. 
Some protocol implementations (such as SSL, SSH v1.0, and early TLS) have known vulnerabilities that an attacker can use to gain access to the cleartext data. It is critical that entities maintain awareness of industry-defined deprecation dates for the cipher suites they are using and are prepared to migrate to newer versions or protocols when older ones are no longer deemed secure. 
Verifying that certificates are trusted helps ensure the integrity of the secure connection. To be considered trusted, a certificate should be issued from a trusted source, such as a trusted certificate authority (CA), and not be expired. Up-to-date Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) can be used to validate certificates. 
Techniques to validate certificates may include certificate and public key pinning, where the trusted certificate or a public key is pinned either during development or upon its first use. Entities can also confirm with developers or review source code to ensure that clients and servers reject connections if the certificate is bad. 
For browser-based TLS certificates, certificate trust can often be verified by clicking on the lock icon that appears next to the address bar. 

Examples:
 Open, public networks include, but are not limited to: 
  • The Internet and
  • Wireless technologies, including Wi-Fi, Bluetooth, cellular technologies, and satellite communications. 
Further Information:
Vendor recommendations and industry best practices can be consulted for information about the proper encryption strength specific to the encryption methodology in use. 
For more information about strong cryptography and secure protocols, see industry standards and best practices such as NIST SP 800-52 and SP 800-57. 
For more information about trusted keys and certificates, see NIST Cybersecurity Practice Guide Special Publication 1800-16, Securing Web Transactions: Transport Layer Security (TLS) Server Certificate Management. 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 4.2.1
4.2.1
Определенные Требования к Подходу:
Надежная криптография и протоколы безопасности реализованы следующим образом для защиты PAN во время передачи по открытым общедоступным сетям:
  • Принимаются только доверенные ключи и сертификаты.
  • Сертификаты, используемые для защиты PAN во время передачи по открытым сетям общего пользования, подтверждаются как действительные, срок действия которых не истек и не аннулирован. Этот бюллетень является наилучшей практикой до даты его вступления в силу; подробности см. в примечаниях к применению ниже.
  • Используемый протокол поддерживает только безопасные версии или конфигурации и не поддерживает резервное копирование или использование небезопасных версий, алгоритмов, размеров ключей или реализаций.
  • Надежность шифрования соответствует используемой методологии шифрования.
Цель Индивидуального подхода:
Открытый текст PAN не может быть прочитан или перехвачен из любых передач по открытым общедоступным сетям.

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

Надлежащая практика:
Схемы сети и потоков данных, определенные в требовании 1, являются полезными ресурсами для определения всех точек подключения, где данные учетной записи передаются или принимаются по открытым общедоступным сетям.
Хотя это и не требуется, считается хорошей практикой для организаций также шифровать PAN по своим внутренним сетям, а для организаций устанавливать любые новые сетевые реализации с зашифрованными сообщениями.
Передача PAN может быть защищена путем шифрования данных перед их передачей или путем шифрования сеанса, по которому передаются данные, или и того, и другого. Хотя не требуется, чтобы надежная криптография применялась как на уровне данных, так и на уровне сеанса, настоятельно рекомендуется. Если данные зашифрованы на уровне данных, криптографическими ключами, используемыми для защиты данных, можно управлять в соответствии с требованиями 3.6 и 3.7. Если данные зашифрованы на уровне сеанса, назначенным хранителям ключей следует назначить ответственность за управление ключами передачи и сертификатами.
Некоторые реализации протоколов (такие как SSL, SSH v1.0 и ранние версии TLS) имеют известные уязвимости, которые злоумышленник может использовать для получения доступа к открытым текстовым данным. Крайне важно, чтобы организации были осведомлены об установленных в отрасли датах устаревания используемых ими наборов шифров и были готовы перейти на более новые версии или протоколы, когда старые больше не считаются безопасными.
Проверка того, что сертификаты являются доверенными, помогает обеспечить целостность защищенного соединения. Чтобы считаться доверенным, сертификат должен быть выдан из надежного источника, такого как доверенный центр сертификации (CA), и срок его действия не истек. Для проверки сертификатов можно использовать обновленные Списки отзыва сертификатов (CRL) или Протокол онлайн-статуса сертификата (OCSP).
Методы проверки сертификатов могут включать закрепление сертификата и открытого ключа, при котором доверенный сертификат или открытый ключ закрепляются либо во время разработки, либо при его первом использовании. Организации также могут подтвердить это у разработчиков или просмотреть исходный код, чтобы убедиться, что клиенты и серверы отклоняют подключения, если сертификат неисправен.
Для сертификатов TLS на основе браузера доверие к сертификату часто можно проверить, нажав на значок блокировки, который появляется рядом с адресной строкой.

Примеры:
Открытые общедоступные сети включают, но не ограничиваются ими:
  • Интернет и
  • Беспроводные технологии, включая Wi-Fi, Bluetooth, сотовые технологии и спутниковую связь.
Дополнительная информация:
С рекомендациями поставщиков и лучшими отраслевыми практиками можно ознакомиться для получения информации о надлежащей надежности шифрования, специфичной для используемой методологии шифрования.
Для получения дополнительной информации о надежной криптографии и безопасных протоколах см. Отраслевые стандарты и рекомендации, такие как NIST SP 800-52 и SP 800-57.
Дополнительные сведения о доверенных ключах и сертификатах см. в Руководстве NIST по практике кибербезопасности Специальная публикация 1800-16 "Защита веб-транзакций: Управление сертификатами сервера безопасности транспортного уровня (TLS)".
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
ЗИС.3 ЗИС.3 Обеспечение защиты информации от раскрытия, модификации и навязывания (ввода ложной информации) при ее передаче (подготовке к передаче) по каналам связи, имеющим выход за пределы контролируемой зоны, в том числе беспроводным каналам связи
Положение Банка России № 719-П от 04.06.2020 "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств":
Глава 2 п. 9
2.9. Технологические меры, указанные в пункте 2.8 настоящего Положения, должны обеспечивать реализацию:
  • механизмов идентификации и аутентификации клиента оператора по переводу денежных средств при формировании (подготовке) и при подтверждении им электронных сообщений в соответствии с требованиями законодательства Российской Федерации;
  • механизмов двухфакторной аутентификации клиента оператора по переводу денежных средств при совершении им действий в целях осуществления переводов денежных средств;
  • механизмов и (или) протоколов формирования и обмена электронными сообщениями, обеспечивающих защиту электронных сообщений от искажения, фальсификации, переадресации, несанкционированного ознакомления и (или) уничтожения, ложной авторизации, в том числе аутентификацию входных электронных сообщений;
  • взаимной (двухсторонней) аутентификации участников обмена средствами вычислительной техники операторов по переводу денежных средств, банковских платежных агентов (субагентов), операторов услуг информационного обмена, операторов услуг платежной инфраструктуры, клиентов операторов по переводу денежных средств;
  • возможности использования клиентом оператора по переводу денежных средств независимых программных сред для формирования (подготовки) и подтверждения электронных сообщений;
  • возможности контроля клиентом оператора по переводу денежных средств реквизитов распоряжений о переводе денежных средств при формировании (подготовке) электронных сообщений (пакета электронных сообщений) и их подтверждении;
  • возможности установления временных ограничений на выполнение клиентом оператора по переводу денежных средств подтверждения электронных сообщений;
  • функций передаваемого клиенту оператора по переводу денежных средств программного обеспечения, используемого при осуществлении переводов денежных средств и предназначенного для установки на мобильные устройства клиента оператора по переводу денежных средств, связанных с выявлением модификации мобильного устройства клиента оператора по переводу денежных средств с использованием недекларируемых возможностей, в том числе деактивации (отключения) механизма разграничения доступа (далее - недекларируемая модификация мобильного устройства клиента), а также уведомлением клиента оператора по переводу денежных средств о случаях недекларируемой модификации мобильного устройства клиента с указанием рисков использования такого устройства (при наличии технической возможности).
Глава 6 п. 2
6.2. ПКЦ при предоставлении услуг платежного клиринга должен обеспечивать защиту информации при осуществлении следующих операций:
  • выполнение процедур приема к исполнению электронных сообщений операторов по переводу денежных средств, включая проверку соответствия электронных сообщений операторов по переводу денежных средств установленным требованиям, определение достаточности денежных средств для исполнения электронных сообщений операторов по переводу денежных средств и определение платежных клиринговых позиций;
  • передача РЦ для исполнения электронных сообщений ПКЦ, принятых электронных сообщений операторов по переводу денежных средств;
  • направление операторам по переводу денежных средств извещений (подтверждений), касающихся приема к исполнению электронных сообщений операторов по переводу денежных средств, а также передача извещений (подтверждений), касающихся исполнения электронных сообщений операторов по переводу денежных средств.
Глава 6 п. 1
6.1. Операторы услуг платежной инфраструктуры, осуществляющие деятельность операционных центров (далее - ОЦ), при предоставлении операционных услуг должны обеспечивать защиту информации при осуществлении обмена электронными сообщениями между операторами по переводу денежных средств, между операторами по переводу денежных средств и их клиентами, операторами услуг платежной инфраструктуры, осуществляющими деятельность платежных клиринговых центров (далее - ПКЦ), операторами услуг платежной инфраструктуры, осуществляющими деятельность расчетных центров (далее - РЦ), между ПКЦ и РЦ.
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ЗИС.19 ЗИС.19 Защита информации при ее передаче по каналам связи
NIST Cybersecurity Framework (EN):
PR.DS-5 PR.DS-5: Protections against data leaks are implemented
PR.DS-2 PR.DS-2: Data-in-transit is protected
PR.DS-6 PR.DS-6: Integrity checking mechanisms are used to verify software, firmware, and information integrity
PR.PT-4 PR.PT-4: Communications and control networks are protected
PR.AC-5 PR.AC-5: Network integrity is protected (e.g., network segregation, network segmentation)
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ЗИС.19 ЗИС.19 Защита информации при ее передаче по каналам связи

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

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