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

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

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

ЗСВ.27

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

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

Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 3.6.1.2
3.6.1.2
Defined Approach Requirements: 
Secret and private keys used to encrypt/decrypt stored account data are stored in one (or more) of the following forms at all times:
  • Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the dataencrypting key.
  • Within a secure cryptographic device (SCD), such as a hardware security module (HSM) or PTS-approved point-of-interaction device. 
  • As at least two full-length key components or key shares, in accordance with an industry-accepted method. 
Customized Approach Objective:
Secret and private keys are stored in a secure form that prevents unauthorized retrieval or access. 

Applicability Notes:
It is not required that public keys be stored in one of these forms. 
Cryptographic keys stored as part of a key management system (KMS) that employs SCDs are acceptable. 
A cryptographic key that is split into two parts does not meet this requirement. Secret or private keys stored as key components or key shares must be generated via one of the following:
  • Using an approved random number generator and within an SCD, 
OR
  • According to ISO 19592 or equivalent industry standard for generation of secret key shares. 

Defined Approach Testing Procedures:
  • 3.6.1.2.a Examine documented procedures to verify it is defined that cryptographic keys used to encrypt/decrypt stored account data must exist only in one (or more) of the forms specified in this requirement. 
  • 3.6.1.2.b Examine system configurations and key storage locations to verify that cryptographic keys used to encrypt/decrypt stored account data exist in one (or more) of the forms specified in this requirement. 
  • 3.6.1.2.c Wherever key-encrypting keys are used, examine system configurations and key storage locations to verify: 
    • Key-encrypting keys are at least as strong as the data-encrypting keys they protect. 
    • Key-encrypting keys are stored separately from data-encrypting keys. 
Purpose:
Storing cryptographic keys securely prevents unauthorized or unnecessary access that could result in the exposure of stored account data. Storing keys separately means they are stored such that if the location of one key is compromised, the second key is not also compromised. 

Good Practice:
Where data-encrypting keys are stored in an HSM, the HSM interaction channel should be protected to prevent interception of encryption or decryption operations. 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 3.6.1.2
3.6.1.2
Определенные Требования к Подходу:
Секретные и закрытые ключи, используемые для шифрования/дешифрования сохраненных данных учетной записи, постоянно хранятся в одной (или нескольких) из следующих форм:
  • Зашифровано с помощью ключа шифрования ключа, который, по крайней мере, такой же надежный, как ключ шифрования данных, и который хранится отдельно от ключа шифрования данных.
  • В защищенном криптографическом устройстве (SCD), таком как аппаратный модуль безопасности (HSM) или устройство точки взаимодействия, одобренное PTS.
  • Как минимум два полноразмерных ключевых компонента или ключевых элемента в соответствии с принятым в отрасли методом.
Цель Индивидуального подхода:
Секретные и закрытые ключи хранятся в защищенной форме, которая предотвращает несанкционированное извлечение или доступ.

Примечания по применению:
Не требуется, чтобы открытые ключи хранились в одной из этих форм.
Криптографические ключи, хранящиеся как часть системы управления ключами (KMS), в которой используются SCDS, являются приемлемыми.
Криптографический ключ, разделенный на две части, не соответствует этому требованию. Секретные или закрытые ключи, хранящиеся в качестве ключевых компонентов или общих ключей, должны быть сгенерированы одним из следующих способов:
  • Используя одобренный генератор случайных чисел и в рамках SCD,
ИЛИ
  • В соответствии с ISO 19592 или эквивалентным отраслевым стандартом для генерации общих секретных ключей.
Определенные Процедуры Тестирования Подхода:
  • 3.6.1.2.изучить документированные процедуры для проверки того, определено ли, что криптографические ключи, используемые для шифрования/дешифрования сохраненных данных учетной записи, должны существовать только в одной (или более) из форм, указанных в этом требовании.
  • 3.6.1.2.b Изучите системные конфигурации и места хранения ключей, чтобы убедиться, что криптографические ключи, используемые для шифрования/дешифрования сохраненных данных учетной записи, существуют в одной (или нескольких) формах, указанных в этом требовании.
  • 3.6.1.2.c Везде, где используются ключи шифрования ключей, изучите системные конфигурации и места хранения ключей, чтобы убедиться: 
    • Ключи шифрования ключей, по крайней мере, такие же надежные, как ключи шифрования данных, которые они защищают. 
    • Ключи шифрования ключей хранятся отдельно от ключей шифрования данных.
Цель:
Безопасное хранение криптографических ключей предотвращает несанкционированный или ненужный доступ, который может привести к раскрытию сохраненных данных учетной записи. Хранение ключей отдельно означает, что они хранятся таким образом, что если местоположение одного ключа скомпрометировано, второй ключ также не скомпрометирован.

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

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

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