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

Положение Банка России № 779-П от 15.11.2021

Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"

п. 1.4.

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

Список требований

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

CIS Critical Security Controls v8 (The 18 CIS CSC):
11.1
11.1 Establish and Maintain a Data Recovery Process
Establish and maintain a data recovery process. In the process, address the scope of data recovery activities, recovery prioritization, and the security of backup data. Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard. 
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 6. п.п. 1
6.1. Кредитные организации должны обеспечивать организацию учета и контроля состава следующих элементов (далее при совместном упоминании - критичная архитектура):
  • технологических процессов, реализуемых непосредственно кредитной организацией;
  • подразделений (работников) кредитной организации, ответственных за разработку технологических процессов, поддержание их выполнения, реализацию технологических процессов (далее - подразделения кредитной организации);
  • объектов информационной инфраструктуры кредитной организации, задействованных при выполнении каждого технологического процесса;
  • технологических участков технологических процессов, установленных в абзацах втором - шестом подпункта 5.2 пункта 5 Положения Банка России от 17 апреля 2019 года N 683-П "Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента" (далее соответственно - Положение Банка России N 683-П, технологические участки технологических процессов);
  • технологических процессов, технологических участков технологических процессов, реализуемых поставщиками услуг в сфере информационных технологий;
  • работников кредитных организаций или иных лиц, осуществляющих физический и (или) логический доступ, или программных сервисов, осуществляющих логический доступ к объектам информационной инфраструктуры (далее - субъекты доступа), задействованных при выполнении каждого технологического процесса;
  • взаимосвязей и взаимозависимостей кредитной организации с иными кредитными организациями, некредитными финансовыми организациями, поставщиками услуг в сфере информационных технологий в рамках выполнения технологических процессов (далее при совместном упоминании - участники технологического процесса);
  • каналов передачи защищаемой информации, установленной в абзацах первом - пятом пункта 1 Положения Банка России N 683-П, обрабатываемой и передаваемой в рамках технологических процессов участниками технологического процесса.
В целях организации учета и контроля состава технологических процессов, технологических участков технологических процессов, реализуемых поставщиками услуг в сфере информационных технологий, кредитные организации должны обеспечивать ведение отдельного реестра в соответствии с внутренними документами.

Кредитные организации в отношении элементов, указанных в подпункте 6.1 настоящего пункта, являющихся значимыми объектами критической информационной инфраструктуры в соответствии с пунктом 3 статьи 2 Федерального закона от 26 июля 2017 года N 187-ФЗ "О безопасности критической информационной инфраструктуры Российской Федерации" (далее - Федеральный закон от 26 июля 2017 года N 187-ФЗ), должны выполнять требования по обеспечению безопасности значимых объектов критической информационной инфраструктуры, установленные в соответствии с пунктом 4 части 3 статьи 6 Федерального закона от 26 июля 2017 года N 187-ФЗ 7.
NIST Cybersecurity Framework (RU):
ID.AM-1
ID.AM-1:  В организации инвентаризированы системы и физическое оборудование 
ID.AM-2
ID.AM-2:  В организации инвентаризированы программные платформы и приложения 
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
ИКА.1.6
ИКА.1.6 Субъектов доступа, задействованных при выполнении каждого бизнес- и технологического процесса;
ИКА.1.3
ИКА.1.3 Подразделений финансовой организации, ответственных за разработку бизнес- и технологических процессов, поддержание их реализации бизнес- и технологических процессов;
ИКА.1.5
ИКА.1.5 Объектов информатизации (прикладного и инфраструктурного уровней) финансовой организации, задействованных при выполнении каждого бизнес- и технологического процесса, в том числе их конфигураций;
ИКА.1.8
ИКА.1.8 Каналов передачи (информационных потоков) защищаемой информации***, обрабатываемой и передаваемой в рамках бизнес- и технологических процессов.
УИ.13
УИ.13 Определение области применения процесса управления изменениями в части управления конфигурациями, включающей  определение:
  • настраиваемых объектов информатизации* и устанавливаемых настроек**;
  • настраиваемых функций, портов, протоколов (включая протоколы удаленного доступа), служб (сервисов) для настраиваемых объектов информатизации;
  • состава ПО (в том числе прикладного ПО и приложений) на автоматизированных рабочих местах работников финансовой организации;
  • объектов информатизации, для которых невозможно обеспечить централизованную установку, применение и контроль внутренних стандартов конфигурирования объектов информатизации (стандартов конфигурирования);
  • состава используемых сервисов поставщиков облачных услуг (в случае наличия возможности определить состав таких сервисов).
ИКА.1.7
ИКА.1.7 Взаимосвязей и взаимозависимостей между финансовой организацией и причастными сторонами (за исключением клиентов финансовой организации) в рамках выполнения бизнес- и технологических процессов, в том числе взаимосвязей и взаимозависимостей между задействованными при этом объектами информатизации;
ИКА.1.4
ИКА.1.4 Технологических операций (участков) в рамках каждого бизнес- и технологического процесса;
ИКА.1.2
ИКА.1.2 Бизнес- и технологических процессов, технологических операций (участков), реализуемых поставщиками услуг (переданных на аутсорсинг и (или) выполняемых с применением сторонних информационных сервисов, предоставляемых поставщиками услуг);
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
11.1
11.1 Реализован и поддерживается процесс восстановления данных
Создан документ, в котором прописана область применения процедур восстановления данных, указаны приоритеты и меры защиты для резервных копий.
Документ пересматривается раз в год или чаще.
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. 
Requirement 12.5.1
12.5.1
Defined Approach Requirements: 
An inventory of system components that are in scope for PCI DSS, including a description of function/use, is maintained and kept current. 

Customized Approach Objective:
All system components in scope for PCI DSS are identified and known. 

Defined Approach Testing Procedures:
  • 12.5.1.a Examine the inventory to verify it includes all in-scope system components and a description of function/use for each. 12.5.1.b Interview personnel to verify the inventory is kept current. 
Purpose:
Maintaining a current list of all system components will enable an organization to define the scope of its environment and implement PCI DSS requirements accurately and efficiently. Without an inventory, some system components could be overlooked and be inadvertently excluded from the organization’s configuration standards 
Good Practice:
If an entity keeps an inventory of all assets, those system components in scope for PCI DSS should be clearly identifiable among the other assets. 
Inventories should include containers or images that may be instantiated. 
Assigning an owner to the inventory helps to ensure the inventory stays current. 

Examples:
Methods to maintain an inventory include as a database, as a series of files, or in an inventorymanagement tool. 
Requirement 9.4.5
9.4.5
Defined Approach Requirements: 
Inventory logs of all electronic media with cardholder data are maintained. 

Customized Approach Objective:
Accurate inventories of stored electronic media are maintained. 

Defined Approach Testing Procedures:
  • 9.4.5.a Examine documentation to verify that procedures are defined to maintain electronic media inventory logs. 
  • 9.4.5.b Examine electronic media inventory logs and interview responsible personnel to verify that logs are maintained. 
Purpose:
Without careful inventory methods and storage controls, stolen or missing electronic media could go unnoticed for an indefinite amount of time. 
Requirement 9.4.5.1
9.4.5.1
Defined Approach Requirements: 
Inventories of electronic media with cardholder data are conducted at least once every 12 months. 

Customized Approach Objective:
Media inventories are verified periodically. 

Defined Approach Testing Procedures:
  • 9.4.5.1.a Examine documentation to verify that procedures are defined to conduct inventories of electronic media with cardholder data at least once every 12 months. 
  • 9.4.5.1.b Examine electronic media inventory logs and interview personnel to verify that electronic media inventories are performed at least once every 12 months. 
Purpose:
Without careful inventory methods and storage controls, stolen or missing electronic media could go unnoticed for an indefinite amount of time. 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.8.1.1
A.8.1.1  Инвентаризация активов 
Мера обеспечения информационной безопасности: Информация, средства обработки информации и другие активы, связанные с информацией, должны быть идентифицированы, а также должен быть составлен и поддерживаться в актуальном состоянии перечень этих активов (Пункт А.8.1.1 приведен с учетом технической правки 1 к ISO/IEC 27001:2013) 
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 1.4 CSC 1.4 Maintain Detailed Asset Inventory
Maintain an accurate and up-to-date inventory of all technology assets with the potential to store or process information. This inventory shall include all hardware assets, whether connected to the organization's network or not.
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)".
Requirement 12.5.1
12.5.1
Определенные Требования к Подходу:
Ведется и поддерживается в актуальном состоянии перечень системных компонентов, подпадающих под действие стандарта PCI DSS, включая описание функций/использования.

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

Определенные Процедуры Тестирования Подхода:
  • 12.5.1.a Изучите перечень, чтобы убедиться, что он включает все компоненты системы, входящие в комплект поставки, и описание функций/использования для каждого из них. 12.5.1.b Опросите персонал, чтобы убедиться, что инвентаризация ведется в актуальном состоянии.
Цель:
Ведение текущего списка всех компонентов системы позволит организации определить область применения своей среды и точно и эффективно выполнять требования PCI DSS. Без инвентаризации некоторые компоненты системы могут быть упущены из виду и непреднамеренно исключены из стандартов конфигурации организации
Надлежащая практика:
Если организация ведет инвентаризацию всех активов, те системные компоненты, которые подпадают под действие стандарта PCI DSS, должны быть четко идентифицированы среди других активов.
Описи должны включать контейнеры или изображения, которые могут быть созданы.
Назначение владельца инвентарю помогает обеспечить актуальность инвентаря.

Примеры:
Методы ведения инвентаризации включают в себя в виде базы данных, в виде серии файлов или в инструменте управления запасами.
Requirement 9.4.5
9.4.5
Определенные Требования к Подходу:
Ведутся журналы инвентаризации всех электронных носителей с данными о держателях карт.

Цель Индивидуального подхода:
Ведется точный учет хранящихся электронных носителей.

Определенные Процедуры Тестирования Подхода:
  • 9.4.5.a Изучите документацию, чтобы убедиться, что определены процедуры ведения журналов инвентаризации электронных носителей. 
  • 9.4.5.b Изучите журналы инвентаризации электронных носителей и опросите ответственный персонал, чтобы убедиться, что журналы ведутся.
Цель:
Без тщательных методов инвентаризации и контроля за хранением украденные или пропавшие электронные носители могут оставаться незамеченными в течение неопределенного периода времени.
Requirement 9.4.5.1
9.4.5.1
Определенные Требования к Подходу:
Инвентаризация электронных носителей с данными о держателях карт проводится не реже одного раза в 12 месяцев.

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

Определенные Процедуры Тестирования Подхода:
  • 9.4.5.1.a Изучает документацию, чтобы убедиться в том, что определены процедуры для проведения инвентаризации электронных носителей с данными о держателях карт не реже одного раза в 12 месяцев.
  • 9.4.5.1.b Изучите журналы инвентаризации электронных носителей и опросите персонал, чтобы убедиться, что инвентаризация электронных носителей проводится не реже одного раза в 12 месяцев.
Цель:
Без тщательных методов инвентаризации и контроля за хранением украденные или пропавшие электронные носители могут оставаться незамеченными в течение неопределенного периода времени.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.9
А.5.9 Инвентаризации информационных и иных связанных с ними активов
Должен быть разработан и поддерживаться реестр информационных и иных, связанных с ними активов,  а также их владельцев.
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
АУД.1 АУД.1 Инвентаризация информационных ресурсов
NIST Cybersecurity Framework (EN):
ID.AM-1 ID.AM-1: Physical devices and systems within the organization are inventoried
ID.AM-2 ID.AM-2: Software platforms and applications within the organization are inventoried
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
АУД.1 АУД.1 Инвентаризация информационных ресурсов
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
8.1.1
8.1.1 Инвентаризация активов

Мера обеспечения ИБ
Информация, средства обработки информации и другие активы, связанные с информацией, должны быть идентифицированы, а также должен быть составлен и поддерживаться в актуальном состоянии перечень этих активов. (Внесена техническая поправка Cor.1:2014).

Руководство по применению
Организация должна идентифицировать активы, относящиеся к жизненному циклу информации, и задокументировать их значимость. Жизненный цикл информации должен включать в себя создание, обработку, хранение, передачу, удаление и уничтожение. Документация должна храниться в специально созданных или уже существующих перечнях, в зависимости от ситуации.
Перечень активов должен быть точным, актуальным, полным и согласованным с другими инвентаризационными перечнями.
Для каждого актива, включенного в перечень, должен быть определен его владелец (см. 8.1.2) и проведено категорирование (см. 8.2).

Дополнительная информация
Инвентаризация активов помогает обеспечить эффективную защиту и может также потребоваться для других целей, таких как здоровье и безопасность, страхование или финансы (управление активами).
ИСО/МЭК 27005 [11] предоставляет примеры активов, которые могут быть приняты во внимание организацией в процессе идентификации активов. Процесс составления перечня активов является важной предпосылкой управления рисками (см. также ИСО/МЭК 27001 [10] и ИСО/МЭК 27005 [11]).
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.5.9
А.5.9 Inventory of information and other associated assets
An inventory of information and other associated assets, including owners, shall be developed and maintained

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