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

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

Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах

ЗИС.3

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

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

ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
ЗБС.8
ЗБС.8 Блокирование попыток подключения к беспроводным точкам доступа с незарегистрированных устройств доступа, в том числе из-за пределов зданий и сооружений финансовой организации
3-Н 2-Н 1-Т
NIST Cybersecurity Framework (RU):
PR.DS-2
PR.DS-2: Данные при передаче защищаются  
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ЗИС.3 ЗИС.3 Обеспечение защиты персональных данных от раскрытия, модификации и навязывания (ввода ложной информации) при ее передаче (подготовке к передаче) по каналам связи, имеющим выход за пределы контролируемой зоны, в том числе беспроводным каналам связи
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 9.4.3
9.4.3
Defined Approach Requirements: 
 Media with cardholder data sent outside the facility is secured as follows:
  • Media sent outside the facility is logged.
  • Media is sent by secured courier or other delivery method that can be accurately tracked.
  • Offsite tracking logs include details about media location. 
Customized Approach Objective:
Media is secured and tracked when transported outside the facility. 

Defined Approach Testing Procedures:
  • 9.4.3.a Examine documentation to verify that procedures are defined for securing media sent outside the facility in accordance with all elements specified in this requirement. 
  • 9.4.3.b Interview personnel and examine records to verify that all media sent outside the facility is logged and sent via secured courier or other delivery method that can be tracked. 
  • 9.4.3.c Examine offsite tracking logs for all media to verify tracking details are documented. 
Purpose:
Media may be lost or stolen if sent via a nontrackable method such as regular postal mail. The use of secure couriers to deliver any media that contains cardholder data allows organizations to use their tracking systems to maintain inventory and location of shipments. 
Requirement 4.2.1.2
4.2.1.2
Defined Approach Requirements: 
Wireless networks transmitting PAN or connected to the CDE use industry best practices to implement strong cryptography for authentication and transmission. 

Customized Approach Objective:
Cleartext PAN cannot be read or intercepted from wireless network transmissions. 

Defined Approach Testing Procedures:
  • 4.2.1.2 Examine system configurations to verify that wireless networks transmitting PAN or connected to the CDE use industry best practices to implement strong cryptography for authentication and transmission. 
Purpose:
Since wireless networks do not require physical media to connect, it is important to establish controls limiting who can connect and what transmission protocols will be used. Malicious users use free and widely available tools to eavesdrop on wireless communications. Use of strong cryptography can help limit disclosure of sensitive information across wireless networks. 
Wireless networks present unique risks to an organization; therefore, they must be identified and protected according to industry requirements. Strong cryptography for authentication and transmission of PAN is required to prevent malicious users from gaining access to the wireless network or utilizing wireless networks to access other internal networks or data. 

Good Practice:
Wireless networks should not permit fallback or downgrade to an insecure protocol or lower encryption strength that does not meet the intent of strong cryptography. 

Further Information:
Review the vendor’s specific documentation for more details on the choice of protocols, configurations, and settings related to cryptography 
Requirement 1.4.5
1.4.5
Defined Approach Requirements: 
The disclosure of internal IP addresses and routing information is limited to only authorized parties. 

Customized Approach Objective:
Internal network information is protected from unauthorized disclosure. 

Defined Approach Testing Procedures:
  •  1.4.5.a Examine configurations of NSCs to verify that the disclosure of internal IP addresses and routing information is limited to only authorized parties. 
  • 1.4.5.b Interview personnel and examine documentation to verify that controls are implemented such that any disclosure of internal IP addresses and routing information is limited to only authorized parties. 
Purpose:
Restricting the disclosure of internal, private, and local IP addresses is useful to prevent a hacker from obtaining knowledge of these IP addresses and using that information to access the network. 

Good Practice:
Methods used to meet the intent of this requirement may vary, depending on the specific networking technology being used. For example, the controls used to meet this requirement may be different for IPv4 networks than for IPv6 networks. 

Examples Methods to obscure IP addressing may include, but are not limited to:
  • IPv4 Network Address Translation (NAT).
  • Placing system components behind proxy servers/NSCs.
  • Removal or filtering of route advertisements for internal networks that use registered addressing.
  • Internal use of RFC 1918 (IPv4) or use IPv6 privacy extension (RFC 4941) when initiating outgoing sessions to the internet. 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.14.1.3
A.14.1.3 Защита транзакций прикладных сервисов 
Мера обеспечения информационной безопасности: Информацию, используемую в транзакциях прикладных сервисов, следует защищать для предотвращения неполной передачи, ложной маршрутизации, несанкционированного изменения, раскрытия, дублирования или воспроизведения сообщений 
A.14.1.2
A.14.1.2 Обеспечение безопасности прикладных сервисов, предоставляемых с использованием сетей общего пользования 
Мера обеспечения информационной безопасности: Информация, используемая в прикладных сервисах и передаваемая по сетям общего пользования, должна быть защищена от мошеннической деятельности, оспаривания договоров, а также несанкционированного раскрытия и модификации 
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 15.7 CSC 15.7 Leverage the Advanced Encryption Standard (AES) to Encrypt Wireless Data
Leverage the Advanced Encryption Standard (AES) to encrypt wireless data in transit.
CSC 14.4 CSC 14.4 Encrypt All Sensitive Information in Transit
Encrypt all sensitive information in transit.
Положение Банка России № 802-П от 25.07.2022 "О требованиях к защите информации в платежной системе Банка России":
П. 7 п.п. 3
7.3. Участники СБП, ОПКЦ СБП и ОУИО СБП должны определить во внутренних документах состав и правила применения технологических мер защиты информации, используемых для контроля целостности и подтверждения подлинности электронных сообщений и информационных сообщений (при их наличии), при осуществлении перевода денежных средств с использованием сервиса быстрых платежей на этапах формирования (подготовки), обработки, передачи и хранения электронных сообщений и информационных сообщений (при их наличии).
Участники СБП, ОПКЦ СБП и ОУИО СБП должны применять технологические меры защиты информации, используемые для контроля целостности и подтверждения подлинности электронных сообщений и информационных сообщений на этапах их формирования (подготовки), обработки, передачи и хранения (при их наличии).
П. 14.1
14.1. Участники СБП должны удостоверять электронной подписью электронные сообщения при их передаче клиентами участника СБП.
П. 14.4
14.4. ОПКЦ СБП должен обеспечивать защиту электронных сообщений при их передаче в Банк России посредством:
  • обработки электронных сообщений и контроля реквизитов электронных сообщений в информационной инфраструктуре ОПКЦ СБП в соответствии с пунктом 2 приложения к настоящему Положению;
  • использования двух усиленных электронных подписей - электронной подписи, применяемой в контуре обработки электронных сообщений, и электронной подписи, применяемой в контуре контроля реквизитов электронных сообщений, - для контроля целостности и подтверждения подлинности электронных сообщений;
  • шифрования электронных сообщений на прикладном уровне в соответствии с эталонной моделью взаимосвязи открытых систем, предусмотренной пунктом 1.7 раздела 1 ГОСТ Р ИСО/МЭК 7498-1-99, с использованием СКЗИ, прошедших процедуру оценки соответствия требованиям, установленным федеральным органом исполнительной власти в области обеспечения безопасности;
  • применения средств защиты информации, реализующих двухстороннюю аутентификацию и шифрование информации на уровне звена данных или сетевом уровне в соответствии с эталонной моделью взаимосвязи открытых систем, предусмотренной пунктом 1.7 раздела 1 ГОСТ Р ИСО/МЭК 7498-1-99, прошедших процедуру оценки соответствия требованиям, установленным федеральным органом исполнительной власти в области обеспечения безопасности.
П. 14.3
14.3. Участники ССНП должны обеспечивать защиту электронных сообщений при их передаче в Банк России посредством:
  • формирования электронных сообщений и контроля реквизитов электронных сообщений с использованием объектов информационной инфраструктуры участника ССНП в соответствии с пунктом 1 приложения к настоящему Положению, в котором установлены Правила материально-технического обеспечения формирования электронных сообщений и контроля реквизитов электронных сообщений в информационной инфраструктуре участника ССНП, а также правила материально-технического обеспечения обработки электронных сообщений и контроля реквизитов электронных сообщений в информационной инфраструктуре ОПКЦ СБП в соответствии с частью пятой статьи 5 Федерального закона от 2 декабря 1990 года N 395-I "О банках и банковской деятельности" (в редакции Федерального закона от 3 февраля 1996 года N 17-ФЗ);
  • использования двух усиленных электронных подписей - электронной подписи, применяемой в контуре формирования электронных сообщений, и электронной подписи, применяемой в контуре контроля реквизитов электронных сообщений, - для контроля целостности и подтверждения подлинности электронных сообщений;
  • применения третьего варианта защиты, указанного в Альбоме электронных сообщений, ведение которого осуществляется Банком России в соответствии с абзацами вторым, третьим и подпунктом 5.2.1 пункта 5.2 Положения Банка России N 732-П;
  • шифрования электронных сообщений на прикладном уровне в соответствии с эталонной моделью взаимосвязи открытых систем, предусмотренной пунктом 1.7 раздела 1 ГОСТ Р ИСО/МЭК 7498-1-99, с использованием СКЗИ, прошедших процедуру оценки соответствия требованиям, установленным федеральным органом исполнительной власти в области обеспечения безопасности;
  • применения средств защиты информации, реализующих двухстороннюю аутентификацию и шифрование информации на уровне звена данных или сетевом уровне в соответствии с эталонной моделью взаимосвязи открытых систем, предусмотренной пунктом 1.7 раздела 1 ГОСТ Р ИСО/МЭК 7498-1-99, прошедших процедуру оценки соответствия требованиям, установленным федеральным органом исполнительной власти в области обеспечения безопасности.
П. 14.2
14.2. Участники СБП и ОПКЦ СБП должны обеспечивать защиту электронных сообщений при передаче между участниками СБП и ОПКЦ СБП посредством:
  • использования усиленной электронной подписи для контроля целостности и подтверждения подлинности электронных сообщений, состав которых определен договором об оказании операционных услуг, услуг платежного клиринга при осуществлении перевода денежных средств с использованием сервиса быстрых платежей, заключенным между участником СБП и ОПКЦ СБП в соответствии с частью 1 статьи 17, частью 1 статьи 18 Федерального закона от 27 июня 2011 года N 161-ФЗ (далее - договор об оказании услуг между участником СБП и ОПКЦ СБП);
  • шифрования электронных сообщений на прикладном уровне в соответствии с эталонной моделью взаимосвязи открытых систем, предусмотренной пунктом 1.7 раздела 1 государственного стандарта Российской Федерации ГОСТ Р ИСО/МЭК 7498-1-99 "Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель", принятого постановлением Государственного комитета Российской Федерации по стандартизации и метрологии от 18 марта 1999 года N 78  и введенного в действие 1 января 2000 года (далее - ГОСТ Р ИСО/МЭК 7498-1-99), с использованием СКЗИ, прошедших процедуру оценки соответствия требованиям, установленным федеральным органом исполнительной власти в области обеспечения безопасности;
  • применения средств защиты информации, посредством использования которых реализуется двухсторонняя аутентификация и шифрование информации на уровне представления или ниже, в соответствии с эталонной моделью взаимосвязи открытых систем, предусмотренной пунктом 1.7 раздела 1 ГОСТ Р ИСО/МЭК 7498-1-99, прошедших процедуру оценки соответствия требованиям, установленным федеральным органом исполнительной власти в области обеспечения безопасности.
Участники СБП, ОПКЦ СБП и ОУИО СБП должны обеспечивать защиту электронных сообщений при их передаче между ОПКЦ СБП, участниками СБП и ОУИО СБП в соответствии с требованиями, установленными абзацами вторым - четвертым настоящего подпункта.
Участники СБП должны реализовать технологии подготовки, обработки и передачи электронных сообщений и защищаемой информации, обеспечивающие проверку соответствия (сверку) реквизитов исходящих в адрес ОПКЦ СБП электронных сообщений с реквизитами соответствующих им входящих электронных сообщений клиентов участников СБП и реквизитами электронных сообщений, на основе которых участником СБП осуществляются операции по списанию денежных средств со счетов клиентов.
П. 12
12. При обмене электронными сообщениями между Банком России и ОПКЦ СБП, Банком России и участниками ССНП должна применяться электронная подпись, сертификаты ключа проверки которой выданы Банком России участникам ССНП и ОПКЦ СБП, в соответствии с частью 2 статьи 6 Федерального закона от 6 апреля 2011 года N 63-ФЗ "Об электронной подписи".
При обмене электронными сообщениями между ОПКЦ СБП и участниками СБП должна применяться электронная подпись, сертификат ключа проверки которой выдан ОПКЦ СБП участникам СБП.
При обмене электронными сообщениями между ОПКЦ СБП, участниками СБП и ОУИО СБП должна применяться электронная подпись, сертификат ключа проверки которой выдан ОПКЦ СБП участнику СБП, в том числе при обмене электронными сообщениями между ОПКЦ СБП и ОУИО СБП, оказывающим участнику СБП услуги по обеспечению подписания исходящих электронных сообщений и (или) зашифрования на прикладном уровне электронных сообщений, проверки электронной подписи во входящих электронных сообщениях и (или) расшифрования на прикладном уровне входящих электронных сообщений.
Хранение и использование криптографических ключей участника СБП, предназначенных для подписания исходящих электронных сообщений и (или) расшифрования на прикладном уровне входящих электронных сообщений, должны осуществляться в аппаратных модулях безопасности информационной инфраструктуры ОУИО СБП, имеющих подтверждение соответствия требованиям, установленным федеральным органом исполнительной власти в области обеспечения безопасности при осуществлении регулирования в соответствии с пунктом "ш" части первой статьи 13 Федерального закона от 3 апреля 1995 года N 40-ФЗ "О федеральной службе безопасности" (далее - требования, установленные федеральным органом исполнительной власти в области обеспечения безопасности). Доступ к криптографическим ключам участника СБП должен быть обеспечен только для участника СБП как владельца сертификата ключа проверки электронной подписи.
При обмене электронными сообщениями между ОПКЦ СБП и ОУИО СБП криптографические ключи участника СБП, предназначенные для подписания исходящих электронных сообщений и (или) расшифрования на прикладном уровне входящих электронных сообщений, хранение и использование которых осуществляются в информационной инфраструктуре ОУИО СБП, изготавливаются участником СБП в аппаратных модулях безопасности самостоятельно. Для получения сертификата ключа проверки электронной подписи участник СБП обращается в ОПКЦ СБП самостоятельно.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 4.2.1.2
4.2.1.2
Определенные Требования к Подходу:
Беспроводные сети, передающие PAN или подключенные к CDE, используют лучшие отраслевые практики для реализации надежной криптографии для аутентификации и передачи.

Цель Индивидуального подхода:
Открытый текст PAN не может быть прочитан или перехвачен при передаче по беспроводной сети.

Определенные Процедуры Тестирования Подхода:
  • 4.2.1.2 Изучить системные конфигурации, чтобы убедиться, что беспроводные сети, передающие PAN или подключенные к CDE, используют лучшие отраслевые практики для реализации надежной криптографии для аутентификации и передачи.
Цель:
Поскольку для подключения к беспроводным сетям не требуются физические носители, важно установить элементы управления, ограничивающие, кто может подключаться и какие протоколы передачи будут использоваться. Злоумышленники используют бесплатные и широко доступные инструменты для подслушивания беспроводных сообщений. Использование надежной криптографии может помочь ограничить раскрытие конфиденциальной информации в беспроводных сетях.
Беспроводные сети представляют уникальные риски для организации; поэтому они должны быть идентифицированы и защищены в соответствии с отраслевыми требованиями. Надежная криптография для аутентификации и передачи PAN требуется для предотвращения получения злоумышленниками доступа к беспроводной сети или использования беспроводных сетей для доступа к другим внутренним сетям или данным.

Надлежащая практика:
Беспроводные сети не должны допускать отката или понижения до небезопасного протокола или снижения уровня шифрования, что не соответствует целям надежной криптографии.

Дополнительная информация:
Ознакомьтесь с конкретной документацией поставщика для получения более подробной информации о выборе протоколов, конфигураций и параметров, связанных с криптографией
Requirement 9.4.3
9.4.3
Определенные Требования к Подходу:
Носитель с данными о держателях карт, отправляемый за пределы учреждения, защищается следующим образом:
  • Носители, отправленные за пределы объекта, регистрируются.
  • Носитель отправляется защищенным курьером или другим способом доставки, который можно точно отследить.
  • Журналы отслеживания за пределами сайта содержат подробную информацию о местоположении носителя.
Цель Индивидуального подхода:
Носитель защищен и отслеживается при транспортировке за пределы объекта.

Определенные Процедуры Тестирования Подхода:
  • 9.4.3.a Изучите документацию, чтобы убедиться, что процедуры определены для обеспечения безопасности носителей, отправляемых за пределы объекта, в соответствии со всеми элементами, указанными в этом требовании.
  • 9.4.3.b Опросите персонал и изучите записи, чтобы убедиться, что все материалы, отправленные за пределы объекта, регистрируются и отправляются через защищенного курьера или другим способом доставки, который можно отследить.
  • 9.4.3.c Изучите журналы отслеживания за пределами сайта для всех носителей, чтобы убедиться, что детали отслеживания задокументированы.
Цель:
Носитель может быть утерян или украден, если он отправлен с помощью не отслеживаемого способа, такого как обычная почтовая почта. Использование надежных курьеров для доставки любых носителей, содержащих данные о держателях карт, позволяет организациям использовать свои системы отслеживания для ведения инвентаризации и определения местоположения отправлений.
Requirement 1.4.5
1.4.5
Определенные Требования к Подходу:
Раскрытие внутренних IP-адресов и информации о маршруте только авторизованным сторонам.

Цель Индивидуального подхода:
Внутренняя сетевая информация защищена от несанкционированного раскрытия.

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

Надлежащая практика:
Методы, используемые для выполнения этого требования, могут варьироваться в зависимости от конкретной используемой сетевой технологии. Например, элементы управления, используемые для выполнения этого требования, могут отличаться для сетей IPv4 от сетей IPv6.

Примеры:
Способы скрытия IP-адресации могут включать, но не ограничиваться ими:
  • Преобразование сетевых адресов IPv4 (NAT).
  • Размещение системных компонентов за прокси-серверами/NSCS.
  • Удаление или фильтрация маршрутных рекламных объявлений для внутренних сетей, использующих зарегистрированную адресацию.
  • Внутреннее использование RFC 1918 (IPv4) или использование расширения конфиденциальности IPv6 (RFC 4941) при инициировании исходящих сеансов в Интернет.
Положение Банка России № 719-П от 04.06.2020 "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств":
Глава 4 п.1
4.1. Операторы услуг информационного обмена должны обеспечивать защиту информации при оказании операторам по переводу денежных средств услуг информационного обмена на основании договоров в отношении следующих операций:
  • осуществление переводов денежных средств с использованием электронных средств платежа на основании электронных сообщений клиентов операторов по переводу денежных средств;
  • осуществление переводов денежных средств с использованием электронных средств платежа на основании электронных сообщений иностранных поставщиков платежных услуг.
Глава 6 п. 1
6.1. Операторы услуг платежной инфраструктуры, осуществляющие деятельность операционных центров (далее - ОЦ), при предоставлении операционных услуг должны обеспечивать защиту информации при осуществлении обмена электронными сообщениями между операторами по переводу денежных средств, между операторами по переводу денежных средств и их клиентами, операторами услуг платежной инфраструктуры, осуществляющими деятельность платежных клиринговых центров (далее - ПКЦ), операторами услуг платежной инфраструктуры, осуществляющими деятельность расчетных центров (далее - РЦ), между ПКЦ и РЦ.
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ЗИС.19 ЗИС.19 Защита информации при ее передаче по каналам связи
NIST Cybersecurity Framework (EN):
PR.DS-2 PR.DS-2: Data-in-transit is protected
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ЗИС.19 ЗИС.19 Защита информации при ее передаче по каналам связи
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
14.1.3
14.1.3 Защита транзакций прикладных сервисов

Мера обеспечения ИБ
Информацию, используемую в транзакциях прикладных сервисов, следует защищать для предотвращения неполной передачи, ложной маршрутизации, несанкционированного изменения, раскрытия, дублирования или воспроизведения сообщений.

Руководство по применению
Вопросы безопасности для транзакций прикладных сервисов должны включать следующее:
  • a) использование электронных подписей каждой из сторон, участвующих в транзакции;
  • b) все аспекты транзакции, то есть обеспечение того, что:
  1. секретная аутентификационная информация пользователей с каждой стороны проверена и действительна;
  2. транзакция остается конфиденциальной;
  3. сохраняется конфиденциальность всех вовлеченных сторон;
  • c) канал связи между всеми вовлеченными сторонами защищен;
  • d) протоколы, используемые для связи между всеми вовлеченными сторонами, защищены;
  • e) обеспечение того, чтобы хранение деталей транзакции находилось за пределами какой-либо общедоступной среды, например в хранилище интрасети организации, которое не доступно непосредственно из сети Интернет;
  • f) если используется доверенный орган (например, для целей выдачи и поддержки электронных подписей или цифровых сертификатов), обеспечение безопасности интегрируется и становится частью процесса управления сертификатами/подписями на протяжении всего жизненного цикла такого процесса.

Дополнительная информация
Объем принятых мер обеспечения ИБ должен соответствовать уровню риска, связанного с каждой формой транзакции прикладных сервисов.
Транзакции должны соответствовать юридическим и нормативным требованиям той юрисдикции, где их формируют, обрабатывают, завершают или хранят.
14.1.2
14.1.2 Обеспечение безопасности прикладных сервисов, предоставляемых с использованием сетей общего пользования

Мера обеспечения ИБ
Информация, используемая в прикладных сервисах и передаваемая по сетям общего пользования, должна быть защищена от мошеннической деятельности, оспаривания договоров, а также несанкционированного раскрытия и модификации.

Руководство по применению
ИБ прикладных сервисов, проходящих через общедоступные сети, следует обеспечивать исходя из следующих соображений:
  • a) уровень доверия, который требует каждая сторона в отношении друг друга, например посредством аутентификации;
  • b) процессы авторизации, связанные с тем, кто может утверждать содержание, выпускать или подписывать ключевые деловые документы;
  • c) обеспечение того, чтобы взаимодействующие стороны были полностью проинформированы о своих правах на предоставление и использование сервиса;
  • d) определение и соблюдение требований в отношении конфиденциальности, целостности, подтверждения отправки и получения ключевых документов, а также невозможности отказа от совершенных сделок, например связанных с процессами заключения контрактов и проведения тендеров;
  • e) уровень доверия, необходимый для целостности ключевых документов;
  • f) требования по защите любой конфиденциальной информации;
  • g) конфиденциальность и целостность любых операций с заказом, платежной информации, адреса доставки и подтверждения получения;
  • h) степень проверки платежной информации, предоставленной клиентом;
  • i) выбор наиболее подходящей формы расчета для защиты от мошенничества;
  • j) уровень защиты, необходимый для сохранения конфиденциальности и целостности информации о заказе;
  • k) предотвращение потери или дублирования информации об операции;
  • l) ответственность за мошеннические операции;
  • m) страховые требования.
Многие из вышеперечисленных соображений могут быть выполнены с применением криптографических мер обеспечения ИБ (раздел 10), принимая во внимание требования законодательства (раздел 18, особенно 18.1.5 для законодательства о криптографии).
Механизмы предоставления услуг между участниками должны быть закреплены документально оформленным соглашением, в котором обе стороны соглашаются с условиями предоставления сервисов, включая детали авторизации (перечисление b).
Следует учитывать требования устойчивости к атакам, которые могут включать в себя требования по защите используемых серверов приложений или обеспечению доступности сетевых соединений, необходимых для предоставления сервиса.

Дополнительная информация
Приложения, доступные через сети общего пользования, подвержены целому ряду угроз, таких как мошеннические действия, нарушение условий договора или публичное разглашение информации. Поэтому обязательным здесь является детальная оценка риска и правильный выбор мер обеспечения ИБ. Необходимые меры обеспечения ИБ часто включают в себя криптографические методы для аутентификации и защиты данных при передаче.
Прикладные сервисы могут использовать безопасные методы аутентификации, например использование криптографии с открытым ключом и электронных подписей (раздел 10) для снижения рисков. Кроме того, при необходимости, могут быть задействованы доверенные третьи стороны.

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

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

Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.