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

Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022

Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А

А.8.24

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

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

Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 7 п. 6 п.п. 4
7.6.4. В организациях БС РФ в связи с повышенными рисками нарушения ИБ при взаимодействии с сетью Интернет должны применяться защитные меры, в том числе межсетевые экраны, антивирусные средства, средства обнаружения вторжений, средства криптографической защиты информации, обеспечивающие, среди прочего, прием и передачу информации только в установленном формате и только для конкретной технологии.
Должны быть разработаны и введены в действие инструкции и рекомендации по использованию сети Интернет, учитывающие особенности банковских технологических процессов.
Должны быть определены и выполняться процедуры протоколирования посещения ресурсов сети Интернет работниками организации БС РФ. Данные о посещенных работниками организации БС РФ ресурсов сети Интернет должны быть доступны работникам службы ИБ.
Р. 7 п. 7 п.п. 8
7.7.8. ИБ процессов изготовления криптографических ключей СКЗИ должна обеспечиваться комплексом технологических, организационных, технических и программных мер и средств защиты, предусмотренных технической документацией на СКЗИ.
CIS Critical Security Controls v8 (The 18 CIS CSC):
3.11
3.11 Encrypt Sensitive Data at Rest 
Encrypt sensitive data at rest on servers, applications, and databases containing sensitive data. Storage-layer encryption, also known as server-side encryption, meets the minimum requirement of this Safeguard. Additional encryption methods may include application-layer encryption, also known as client-side encryption, where access to the data storage device(s) does not permit access to the plain-text data. 
3.9
3.9 Encrypt Data on Removable Media 
Encrypt data on removable media. 
16.11
16.11 Leverage Vetted Modules or Services for Application Security Components
Leverage vetted modules or services for application security components, such as identity management, encryption, and auditing and logging. Using platform features in critical security functions will reduce developers’ workload and minimize the likelihood of design or implementation errors. Modern operating systems provide effective mechanisms for identification, authentication, and authorization and make those mechanisms available to applications. Use only standardized, currently accepted, and extensively reviewed encryption algorithms. Operating systems also provide mechanisms to create and maintain secure audit logs. 
3.10
3.10 Encrypt Sensitive Data in Transit 
Encrypt sensitive data in transit. Example implementations can include: Transport Layer Security (TLS) and Open Secure Shell (OpenSSH). 
3.6
3.6 Encrypt Data on End-User Devices 
Encrypt data on end-user devices containing sensitive data. Example implementations can include: Windows BitLocker®, Apple FileVault®, Linux® dm-crypt. 
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
ПУИ.27
ПУИ.27 Шифрование информации конфиденциального характера при ее хранении на МНИ, выносимых за пределы финансовой организации
3-Н 2-Н 1-Т
ЗСВ.27
ЗСВ.27 Запрет на копирование текущих образов виртуальных машин, использующих СКЗИ, с загруженными криптографическими ключами
3-О 2-О 1-О
Приказ ФАПСИ № 152 от 13.06.2001 "Инструкция об организации и обеспечении безопасности хранения, обработки и передачи по каналам связи с использованием средств криптографической защиты информации с ограниченным доступом, не содержащей сведений, составляющих государственную тайну":
Глава II п. 16
16. При определении обязанностей сотрудников органов криптографической защиты лицензиаты ФАПСИ должны учитывать, что безопасность хранения, обработки и передачи по каналам связи с использованием СКЗИ конфиденциальной информации обеспечивается:
  • соблюдением сотрудниками органов криптографической защиты режима конфиденциальности при обращении со сведениями, которые им доверены или стали известны по работе, в том числе со сведениями о функционировании и порядке обеспечения безопасности применяемых СКЗИ и ключевых документах к ним;
  • точным выполнением сотрудниками органов криптографической защиты требований к обеспечению безопасности конфиденциальной информации;
  • надежным хранением сотрудниками органов криптографической защиты СКЗИ, эксплуатационной и технической документации к ним, ключевых документов, носителей конфиденциальной информации;
  • своевременным выявлением сотрудниками органов криптографической защиты попыток посторонних лиц получить сведения о защищаемой конфиденциальной информации, об используемых СКЗИ или ключевых документах к ним;
  • немедленным принятием сотрудниками органов криптографической защиты мер по предупреждению разглашения защищаемых сведений конфиденциального характера, а также возможной утечки таких сведений при выявлении фактов утраты или недостачи СКЗИ, ключевых документов к ним, удостоверений, пропусков, ключей от помещений, хранилищ, сейфов (металлических шкафов), личных печатей и т.п.
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
3.6
3.6 Реализовано шифрование данных на устройствах конечных пользователей
Примеры решений: Windows BitLocker​, Apple FileVault​, Linux​ dm-crypt.
3.11
3.11 Реализовано шифрование чувствительных данных при хранении
Шифрование используется на серверах, в прикладном ПО и базах данных с конфиденциальными данными.
Как минимум, используется шифрование на стороне сервера (SSE).
Дополнительно может использоваться шифрование на стороне клиента.
3.9
3.9 Реализовано шифрование данных на съемных носителях
Шифровать данные на съемных носителях 
3.10
3.10 Реализовано шифрование чувствительных данных при передаче
Примеры решений: Transport Layer Security (TLS), Open Secure Shell (OpenSSH).
16.11
16.11 Используются проверенные модули или службы в приложениях для компонентов обеспечения безопасности
Используются проверенные модули для шифрования, ведения журналов и управления идентификацией пользователей.

Для обеспечения критичных компонентов безопасности используются платформенные функции.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 3.5.1
3.5.1 
Defined Approach Requirements: 
PAN is rendered unreadable anywhere it is stored by using any of the following approaches:
  • One-way hashes based on strong cryptography of the entire PAN.
  • Truncation (hashing cannot be used to replace the truncated segment of PAN).
    • If hashed and truncated versions of the same PAN, or different truncation formats of the same PAN, are present in an environment, additional controls are in place such that the different versions cannot be correlated to reconstruct the original PAN.
  • Index tokens.
  • Strong cryptography with associated keymanagement processes and procedures. 
Customized Approach Objective:
Cleartext PAN cannot be read from storage media. 

Applicability Notes:
It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. 
This requirement applies to PANs stored in primary storage (databases, or flat files such as text files spreadsheets) as well as non-primary storage (backup, audit logs, exception, or troubleshooting logs) must all be protected. 
This requirement does not preclude the use of temporary files containing cleartext PAN while encrypting and decrypting PAN. 

Defined Approach Testing Procedures:
  • 3.5.1.a Examine documentation about the system used to render PAN unreadable, including the vendor, type of system/process, and the encryption algorithms (if applicable) to verify that the PAN is rendered unreadable using any of the methods specified in this requirement. 
  • 3.5.1.b Examine data repositories and audit logs, including payment application logs, to verify the PAN is rendered unreadable using any of the methods specified in this requirement. 
  • 3.5.1.c If hashed and truncated versions of the same PAN are present in the environment, examine implemented controls to verify that the hashed and truncated versions cannot be correlated to reconstruct the original PAN. 
Purpose:
The removal of cleartext stored PAN is a defense in depth control designed to protect the data if an unauthorized individual gains access to stored data by taking advantage of a vulnerability or misconfiguration of an entity’s primary access control. 
Secondary independent control systems (for example governing access to, and use of, cryptography and decryption keys) prevent the failure of a primary access control system leading to a breach of confidentiality of stored PAN. If hashing is used to remove stored cleartext PAN, by correlating hashed and truncated versions of a given PAN, a malicious individual can easily derive the original PAN value. Controls that prevent the correlation of this data will help ensure that the original PAN remains unreadable. 

Further Informatio:
For information about truncation formats and truncation in general, see PCI SSC’s FAQs on the topic.
Sources for information about index tokens include: 
  • PCI SSC’s Tokenization Product Security Guidelines
  • ANSI X9.119-2-2017: Retail Financial Services - Requirements For Protection Of Sensitive Payment Card Data - Part 2: Implementing Post-Authorization Tokenization Systems 
Requirement 12.3.3
12.3.3
Defined Approach Requirements: 
Cryptographic cipher suites and protocols in use are documented and reviewed at least once every 12 months, including at least the following:
  • An up-to-date inventory of all cryptographic cipher suites and protocols in use, including purpose and where used. 
  • Active monitoring of industry trends regarding continued viability of all cryptographic cipher suites and protocols in use. 
  • A documented strategy to respond to anticipated changes in cryptographic vulnerabilities. 
Customized Approach Objective:
The entity is able to respond quickly to any vulnerabilities in cryptographic protocols or algorithms, where those vulnerabilities affect protection of cardholder data. 

Applicability Notes:
The requirement applies to all cryptographic suites and protocols used to meet PCI DSS requirements. 
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:
  • 12.3.3 Examine documentation for cryptographic suites and protocols in use and interview personnel to verify the documentation and review is in accordance with all elements specified in this requirement. 
Purpose:
Protocols and encryption strengths may quickly change or be deprecated due to identification of vulnerabilities or design flaws. In order to support current and future data security needs, entities need to know where cryptography is used and understand how they would be able to respond rapidly to changes impacting the strength of their cryptographic implementations. 

Good Practice:
Cryptographic agility is important to ensure an alternative to the original encryption method or cryptographic primitive is available, with plans to upgrade to the alternative without significant change to system infrastructure. For example, if the entity is aware of when protocols or algorithms will be deprecated by standards bodies, it can make proactive plans to upgrade before the deprecation is impactful to operations. 

Definitions:
“Cryptographic agility” refers to the ability to monitor and manage the encryption and related verification technologies deployed across an organization. 

Further Information:
Refer to NIST SP 800-131a, Transitioning the Use of Cryptographic Algorithms and Key Lengths. 
Requirement 3.2.1
3.2.1 
Defined Approach Requirements: 
Account data storage is kept to a minimum through implementation of data retention and disposal policies, procedures, and processes that include at least the following: 
  • Coverage for all locations of stored account data. 
  • Coverage for any sensitive authentication data (SAD) stored prior to completion of authorization. This bullet is a best practice until its effective date; refer to Applicability Notes below for details.
  • Limiting data storage amount and retention time to that which is required for legal or regulatory, and/or business requirements.
  • Specific retention requirements for stored account data that defines length of retention period and includes a documented business justification.
  • Processes for secure deletion or rendering account data unrecoverable when no longer needed per the retention policy.
  • A process for verifying, at least once every three months, that stored account data exceeding the defined retention period has been securely deleted or rendered unrecoverable. 
Customized Approach Objective:
Account data is retained only where necessary and for the least amount of time needed and is securely deleted or rendered unrecoverable when no longer needed. 

Applicability Notes:
Where account data is stored by a TPSP (for example, in a cloud environment), entities are responsible for working with their service providers to understand how the TPSP meets this requirement for the entity. Considerations include ensuring that all geographic instances of a data element are securely deleted. The bullet above (for coverage of SAD stored prior to completion of authorization) is a best practice until 31 March 2025, after which it will be required as part of Requirement 3.2.1 and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:
  •  3.2.1.a Examine the data retention and disposal policies, procedures, and processes and interview personnel to verify processes are defined to include all elements specified in this requirement. 
  • 3.2.1.b Examine files and system records on system components where account data is stored to verify that the data storage amount and retention time does not exceed the requirements defined in the data retention policy. 
  • 3.2.1.c Observe the mechanisms used to render account data unrecoverable to verify data cannot be recovered. 
Purpose:
A formal data retention policy identifies what data needs to be retained, for how long, and where that data resides so it can be securely destroyed or deleted as soon as it is no longer needed. The only account data that may be stored after authorization is the primary account number or PAN (rendered unreadable), expiration date, cardholder name, and service code. 
The storage of SAD data prior to the completion of the authorization process is also included in the data retention and disposal policy so that storage of this sensitive data is kept to minimum, and only retained for the defined amount of time. 

Good Practice:
When identifying locations of stored account data, consider all processes and personnel with access to the data, as data could have been moved and stored in different locations than originally defined. Storage locations that are often overlooked include backup and archive systems, removable data storage devices, paper-based media, and audio recordings.
To define appropriate retention requirements, an entity first needs to understand its own business needs as well as any legal or regulatory obligations that apply to its industry or to the type of data being retained. Implementing an automated process to ensure data is automatically and securely deleted upon its defined retention limit can help ensure that account data is not retained beyond what is necessary for business, legal, or regulatory purposes. 
Methods of eliminating data when it exceeds the retention period include secure deletion to complete removal of the data or rendering it unrecoverable and unable to be reconstructed. Identifying and securely eliminating stored data that has exceeded its specified retention period prevents unnecessary retention of data that is no longer needed. This process may be automated, manual, or a combination of both. 
The deletion function in most operating systems is not “secure deletion” as it allows deleted data to be recovered, so instead, a dedicated secure deletion function or application must be used to make data unrecoverable. 
Remember, if you don't need it, don't store it! 

Examples:
An automated, programmatic procedure could be run to locate and remove data, or a manual review of data storage areas could be performed. Whichever method is used, it is a good idea to monitor the process to ensure it is completed successfully, and that the results are recorded and validated as being complete. Implementing secure deletion methods ensures that the data cannot be retrieved when it is no longer needed. 

Further Information:
See NIST SP 800-88 Rev. 1, Guidelines for Media Sanitization. 
Requirement 3.3.2
3.3.2 
Defined Approach Requirements: 
SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography. 

Customized Approach Objective:
This requirement is not eligible for the customized approach. 

Applicability Notes:
Whether SAD is permitted to be stored prior to authorization is determined by the organizations that manage compliance programs (for example, payment brands and acquirers). Contact the organizations of interest for any additional criteria.
This requirement applies to all storage of SAD, even if no PAN is present in the environment. 
Refer to Requirement 3.2.1 for an additional requirement that applies if SAD is stored prior to completion of authorization. 
This requirement does not apply to issuers and companies that support issuing services where there is a legitimate issuing business justification to store SAD). 
Refer to Requirement 3.3.3 for requirements specifically for issuers. 
This requirement does not replace how PIN blocks are required to be managed, nor does it mean that a properly encrypted PIN block needs to be encrypted again. 
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:
  • 3.3.2 Examine data stores, system configurations, and/or vendor documentation to verify that all SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography 
Purpose:
SAD can be used by malicious individuals to increase the probability of successfully generating counterfeit payment cards and creating fraudulent transactions. 

Good Practice:
Entities should consider encrypting SAD with a different cryptographic key than is used to encrypt PAN. Note that this does not mean that PAN present in SAD (as part of track data) would need to be separately encrypted. 

Definitions:
The authorization process is completed as soon as the response to an authorization request response—that is, an approval or decline—is received. 
Requirement 3.6.1
3.6.1
Defined Approach Requirements: 
Procedures are defined and implemented to protect cryptographic keys used to protect stored account data against disclosure and misuse that include:
  • Access to keys is restricted to the fewest number of custodians necessary.
  • 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.
  • Keys are stored securely in the fewest possible locations and forms. 
Customized Approach Objective:
Processes that protect cryptographic keys used to protect stored account data against disclosure and misuse are defined and implemented. 

Applicability Notes:
This requirement applies to keys used to encrypt stored account data and to key-encrypting keys used to protect data-encrypting keys. 
The requirement to protect keys used to protect stored account data from disclosure and misuse applies to both data-encrypting keys and keyencrypting keys. Because one key-encrypting key may grant access to many data-encrypting keys, the key-encrypting keys require strong protection measures. 

Defined Approach Testing Procedures:
  • 3.6.1 Examine documented key-management policies and procedures to verify that processes to protect cryptographic keys used to protect stored account data against disclosure and misuse are defined to include all elements specified in this requirement. 
Purpose:
 Cryptographic keys must be strongly protected because those who obtain access will be able to decrypt data. 

Good Practice:
 Having a centralized key management system based on industry standards is recommended for managing cryptographic keys. 

Further Information:
The entity’s key management procedures will benefit through alignment with industry requirements, Sources for information on cryptographic key management life cycles include: 
  • ISO 11568-1 Banking — Key management (retail) — Part 1: Principles (specifically Chapter 10 and the referenced Parts 2 & 4) 
  • NIST SP 800-57 Part 1 Revision 5— Recommendation for Key Management, Part 1: General. 
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. 
Requirement 3.6.1.1
3.6.1.1
Defined Approach Requirements: 
Additional requirement for service providers only: A documented description of the cryptographic architecture is maintained that includes:
  • Details of all algorithms, protocols, and keys used for the protection of stored account data, including key strength and expiry date. 
  • Preventing the use of the same cryptographic keys in production and test environments. This bullet is a best practice until its effective date; refer to Applicability Notes below for details.
  • Description of the key usage for each key.
  • Inventory of any hardware security modules (HSMs), key management systems (KMS), and other secure cryptographic devices (SCDs) used for key management, including type and location of devices, as outlined in Requirement 12.3.4. 
Customized Approach Objective:
Accurate details of the cryptographic architecture are maintained and available. 

Applicability Notes:
This requirement applies only when the entity being assessed is a service provider. 
In cloud HSM implementations, responsibility for the cryptographic architecture according to this Requirement will be shared between the cloud provider and the cloud customer. 
The bullet above (for including, in the cryptographic architecture, that the use of the same cryptographic keys in production and test is prevented) is a best practice until 31 March 2025, after which it will be required as part of Requirement 3.6.1.1 and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:
  •  3.6.1.1 Additional testing procedure for service provider assessments only: Interview responsible personnel and examine documentation to verify that a document exists to describe the cryptographic architecture that includes all elements specified in this requirement. 
Purpose:
Maintaining current documentation of the cryptographic architecture enables an entity to understand the algorithms, protocols, and cryptographic keys used to protect stored account data, as well as the devices that generate, use, and protect the keys. This allows an entity to keep pace with evolving threats to its architecture and plan for updates as the assurance level provided by different algorithms and key strengths changes. Maintaining such documentation also allows an entity to detect lost or missing keys or key-management devices and identify unauthorized additions to its cryptographic architecture. 
 The use of the same cryptographic keys in both production and test environments introduces a risk of exposing the key if the test environment is not at the same security level as the production environment. 

Good Practice:
Having an automated reporting mechanism can assist with maintenance of the cryptographic attributes. 
Requirement 3.7.2
3.7.2
Defined Approach Requirements: 
Key-management policies and procedures are implemented to include secure distribution of cryptographic keys used to protect stored account data. 

Customized Approach Objective:
Cryptographic keys are secured during distribution 

Defined Approach Testing Procedures:
  • 3.7.2.a Examine the documented key-management policies and procedures for keys used for protection of stored account data to verify that they define secure distribution of cryptographic keys. 
  • 3.7.2.b Observe the method for distributing keys to verify that keys are distributed securely. 
Purpose:
Secure distribution or conveyance of secret or private cryptographic keys means that keys are distributed only to authorized custodians, as identified in Requirement 3.6.1.2, and are never distributed insecurely. 
Requirement 3.6.1.4
3.6.1.4
Defined Approach Requirements: 
Cryptographic keys are stored in the fewest possible locations. 

Customized Approach Objective:
Cryptographic keys are retained only where necessary. 

Defined Approach Testing Procedures:
  • 3.6.1.4 Examine key storage locations and observe processes to verify that keys are stored in the fewest possible locations. 
Purpose:
Storing any cryptographic keys in the fewest locations helps an organization track and monitor all key locations and minimizes the potential for keys to be exposed to unauthorized parties. 
Requirement 3.6.1.3
3.6.1.3
Defined Approach Requirements: 
Access to cleartext cryptographic key components is restricted to the fewest number of custodians necessary. 

Customized Approach Objective:
Access to cleartext cryptographic key components is restricted to necessary personnel. 

Defined Approach Testing Procedures:
  •  3.6.1.3 Examine user access lists to verify that access to cleartext cryptographic key components is restricted to the fewest number of custodians necessary. 
Purpose:
Restricting the number of people who have access to cleartext cryptographic key components reduces the risk of stored account data being retrieved or rendered visible by unauthorized parties. 

Good Practice:
Only personnel with defined key custodian responsibilities (creating, altering, rotating, distributing, or otherwise maintaining encryption keys) should be granted access to key components. 
Ideally this will be a very small number of people. 
Requirement 4.2.1.1
4.2.1.1
Defined Approach Requirements: 
An inventory of the entity’s trusted keys and certificates used to protect PAN during transmission is maintained. 

Customized Approach Objective:
All keys and certificates used to protect PAN during transmission are identified and confirmed as trusted. 

Applicability Notes:
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:
  • 4.2.1.1.a Examine documented policies and procedures to verify processes are defined for the entity to maintain an inventory of its trusted keys and certificates. 
  • 4.2.1.1.b Examine the inventory of trusted keys and certificates to verify it is kept up to date. 
Purpose:
The inventory of trusted keys helps the entity keep track of the algorithms, protocols, key strength, key custodians, and key expiry dates. This enables the entity to respond quickly to vulnerabilities discovered in encryption software, certificates, and cryptographic algorithms. 

Good Practice:
For certificates, the inventory should include the issuing CA and certification expiration date. 
Requirement 3.7.3
3.7.3
Defined Approach Requirements: 
Key-management policies and procedures are implemented to include secure storage of cryptographic keys used to protect stored account data. 

Customized Approach Objective:
Cryptographic keys are secured when stored. 

Defined Approach Testing Procedures:
  • 3.7.3.a Examine the documented key-management policies and procedures for keys used for protection of stored account data to verify that they define secure storage of cryptographic keys. 
  • 3.7.3.b Observe the method for storing keys to verify that keys are stored securely. 
Purpose:
Storing keys without proper protection could provide access to attackers, resulting in the decryption and exposure of account data. 

Good Practice:
Data encryption keys can be protected by encrypting them with a key-encrypting key. Keys can be stored in a Hardware Security Module (HSM). 
Secret or private keys that can decrypt data should never be present in source code. 
Requirement 3.7.1
3.7.1
Defined Approach Requirements: 
Key-management policies and procedures are implemented to include generation of strong cryptographic keys used to protect stored account data. 

Customized Approach Objective:
Strong cryptographic keys are generated. 

Defined Approach Testing Procedures:
  • 3.7.1.a Examine the documented key-management policies and procedures for keys used for protection of stored account data to verify that they define generation of strong cryptographic keys. 
  • 3.7.1.b Observe the method for generating keys to verify that strong keys are generated. 
Purpose:
 Use of strong cryptographic keys significantly increases the level of security of encrypted account data. 
Requirement 3.7.4
3.7.4
Defined Approach Requirements: 
Key management policies and procedures are implemented for cryptographic key changes for keys that have reached the end of their cryptoperiod, as defined by the associated application vendor or key owner, and based on industry best practices and guidelines, including the following:
  • A defined cryptoperiod for each key type in use.
  • A process for key changes at the end of the defined cryptoperiod. 
Customized Approach Objective:
Cryptographic keys are not used beyond their defined cryptoperiod. 

Defined Approach Testing Procedures:
  • 3.7.4.a Examine the documented key-management policies and procedures for keys used for protection of stored account data to verify that they define changes to cryptographic keys that have reached the end of their cryptoperiod and include all elements specified in this requirement. 
  • 3.7.4.b Interview personnel, examine documentation, and observe key storage locations to verify that keys are changed at the end of the defined cryptoperiod(s). 
Purpose:
Changing encryption keys when they reach the end of their cryptoperiod is imperative to minimize the risk of someone obtaining the encryption keys and using them to decrypt data. 

Definitions:
A cryptoperiod is the time span during which a cryptographic key can be used for its defined purpose. Cryptoperiods are often defined in terms of the period for which the key is active and/or the amount of cipher-text that has been produced by the key. Considerations for defining the cryptoperiod include, but are not limited to, the strength of the underlying algorithm, size or length of the key, risk of key compromise, and the sensitivity of the data being encrypted. 

Further Information:
NIST SP 800-57 Part 1, Revision 5, Section 5.3 Cryptoperiods - provides guidance for establishing the time span during which a specific key is authorized for use by legitimate entities, or the keys for a given system will remain in effect. See Table 1 of SP 800-57 Part 1 for suggested cryptoperiods for different key types. 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.10.1.1
A.10.1.1 Политика использования криптографических мер и средств защиты информации 
Мера обеспечения информационной безопасности: Должна быть разработана и внедрена политика использования криптографических мер и средств для обеспечения защиты информации 
A.10.1.2
A.10.1.2 Управление ключами 
Мера обеспечения информационной безопасности: Политика, определяющая использование, защиту и срок службы криптографических ключей, должна быть разработана и применяться на протяжении всего их жизненного цикла 
Постановление Правительства РФ № 584 от 13.06.2012 "Положение о защите информации в платежной системе":
п. 9
9. Применение шифровальных (криптографических) средств защиты информации операторами и агентами осуществляется в соответствии с законодательством Российской Федерации.
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 18.5 CSC 18.5 Use Only Standardized and Extensively Reviewed Encryption Algorithms
Use only standardized, currently accepted, and extensively reviewed encryption algorithms.
CSC 16.4 CSC 16.4 Encrypt or Hash all Authentication Credentials
Encrypt or hash with a salt all authentication credentials when stored.
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 16.5 CSC 16.5 Encrypt Transmittal of Username and Authentication Credentials
Ensure that all account usernames and authentication credentials are transmitted across networks using encrypted channels.
CSC 14.8 CSC 14.8 Encrypt Sensitive Information at Rest
Encrypt all sensitive information at rest using a tool that requires a secondary authentication mechanism not integrated into the operating system, in order to access the information.
CSC 13.9 CSC 13.9 Encrypt Data on USB Storage Devices
If USB storage devices are required, all data stored on such devices must be encrypted while at rest.
CSC 14.4 CSC 14.4 Encrypt All Sensitive Information in Transit
Encrypt all sensitive information in transit.
Положение Банка России № 802-П от 25.07.2022 "О требованиях к защите информации в платежной системе Банка России":
П. 7 п.п. 2
7.2. Участники ССНП, участники СБП, ОПКЦ СБП и ОУИО СБП должны определить во внутренних документах:
  • технологии подготовки, обработки, передачи и хранения электронных сообщений, содержащих распоряжения о переводе денежных средств в электронном виде (далее - электронные сообщения), и защищаемой информации на объектах информационной инфраструктуры;
  • состав и правила применения технологических мер защиты информации, используемых для контроля целостности и подтверждения подлинности электронных сообщений на этапах их формирования (подготовки), обработки, передачи и хранения, в том числе порядок применения средств криптографической защиты информации (далее - СКЗИ) и управления ключевой информацией СКЗИ;
  • план действий, направленных на обеспечение непрерывности и (или) восстановление деятельности, связанной с осуществлением переводов денежных средств;
  • сведения о лице или лицах, допущенных к работе со СКЗИ;
  • сведения о лице или лицах, ответственных за обеспечение функционирования и безопасности СКЗИ (ответственных пользователей СКЗИ);
  • сведения о лице или лицах, обладающих правами по управлению криптографическими ключами, в том числе ответственных за формирование криптографических ключей и обеспечение безопасности криптографических ключей.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 3.5.1
3.5.1
Определенные Требования к Подходу:
PAN становится нечитаемым в любом месте, где хранится, с использованием любого из следующих подходов:
  • Односторонние хэши, основанные на надежной криптографии всего PAN.
  • Усечение (хэширование не может быть использовано для замены усеченного сегмента PAN).
    • Если в среде присутствуют хэшированные и усеченные версии одного и того же PAN или разные форматы усечения одного и того же PAN, применяются дополнительные средства управления, позволяющие не сопоставлять разные версии для восстановления исходного PAN.
  • Индексные токены.
  • Надежная криптография с соответствующими процессами и процедурами управления ключами.
Цель Индивидуального подхода:
Открытый текстовый файл не может быть считан с носителя.

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

Определенные Процедуры Тестирования Подхода:
  • 3.5.1.a Изучите документацию о системе, используемой для обеспечения нечитаемости PAN, включая поставщика, тип системы/процесса и алгоритмы шифрования (если применимо), чтобы убедиться, что PAN становится нечитаемым с использованием любого из методов, указанных в этом требовании.
  • 3.5.1.b Проверьте хранилища данных и журналы аудита, включая журналы платежных приложений, чтобы убедиться, что PAN становится нечитаемым с использованием любого из методов, указанных в этом требовании.
  • 3.5.1.c Если в среде присутствуют хэшированные и усеченные версии одного и того же PAN, проверьте реализованные элементы управления, чтобы убедиться, что хэшированные и усеченные версии не могут быть сопоставлены для восстановления исходного PAN.
Цель:
Удаление сохраненных данных с открытым текстом - это углубленный контроль защиты, предназначенный для защиты данных, если неавторизованное лицо получит доступ к сохраненным данным, воспользовавшись уязвимостью или неправильной конфигурацией основного контроля доступа организации.
Вторичные независимые системы контроля (например, управляющие доступом к ключам шифрования и дешифрования и их использованием) предотвращают сбой первичной системы контроля доступа, приводящий к нарушению конфиденциальности хранимых данных. Если хэширование используется для удаления сохраненного открытого текста PAN, то путем сопоставления хэшированных и усеченных версий данного PAN злоумышленник может легко получить исходное значение PAN. Элементы управления, предотвращающие корреляцию этих данных, помогут гарантировать, что PAN останется нечитаемым.

Дополнительная информация:
Для получения информации о форматах усечения и усечении в целом см. Часто задаваемые вопросы PCI SSC по этой теме.
Источники информации о токенах индекса включают:
  • Рекомендации по безопасности продуктов для токенизации PCI SSC
  • ANSI X9.119-2-2017: Розничные Финансовые Услуги - Требования К Защите Конфиденциальных Данных Платежных Карт - Часть 2: Внедрение Систем Токенизации После Авторизации
Requirement 12.3.3
12.3.3
Определенные Требования к Подходу:
Используемые наборы криптографических шифров и протоколы документируются и пересматриваются не реже одного раза в 12 месяцев, включая, по крайней мере, следующее:
  • Актуальный перечень всех используемых наборов криптографических шифров и протоколов, включая назначение и место использования.
  • Активный мониторинг отраслевых тенденций в отношении сохранения жизнеспособности всех используемых наборов криптографических шифров и протоколов.
  • Документированная стратегия реагирования на ожидаемые изменения в криптографических уязвимостях.
Цель Индивидуального подхода:
Организация способна быстро реагировать на любые уязвимости в криптографических протоколах или алгоритмах, если эти уязвимости влияют на защиту данных о держателях карт.

Примечания по применению:
Это требование распространяется на все криптографические наборы и протоколы, используемые для удовлетворения требований PCI DSS.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

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

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

Определения:
“Криптографическая гибкость” относится к способности отслеживать и управлять технологиями шифрования и связанными с ними технологиями проверки, развернутыми в организации.

Дополнительная информация:
Обратитесь к NIST SP 800-131a, Переход к использованию криптографических алгоритмов и длин ключей.
Requirement 3.2.1
3.2.1
Определенные Требования к Подходу:
Хранение данных учетной записи сведено к минимуму благодаря внедрению политик, процедур и процессов хранения и удаления данных, которые включают, по крайней мере, следующее:
  • Охват всех мест хранения данных учетной записи.
  • Покрытие любых конфиденциальных аутентификационных данных (SAD), сохраненных до завершения авторизации. Этот бюллетень является наилучшей практикой до даты его вступления в силу; подробности см. в Примечаниях к применению ниже.
  • Ограничение объема и времени хранения данных до уровня, требуемого в соответствии с правовыми или нормативными и/или бизнес-требованиями.
  • Конкретные требования к хранению хранимых данных учетной записи, которые определяют продолжительность периода хранения и включают документированное бизнес-обоснование.
  • Процессы для безопасного удаления или восстановления данных учетной записи, когда они больше не нужны в соответствии с политикой хранения.
  • Процесс проверки, по крайней мере, один раз в три месяца, того, что сохраненные данные учетной записи, превышающие установленный срок хранения, были надежно удалены или восстановлены.
Цель Индивидуального подхода:
Данные учетной записи сохраняются только в случае необходимости и в течение наименьшего необходимого времени и надежно удаляются или становятся невосполнимыми, когда в них больше нет необходимости.

Примечания по применению:
Если данные учетной записи хранятся в TPSP (например, в облачной среде), организации несут ответственность за работу со своими поставщиками услуг, чтобы понять, как TPSP соответствует этому требованию для организации. Соображения включают обеспечение того, чтобы все географические экземпляры элемента данных были надежно удалены. Приведенный выше список (для охвата SAD, сохраненных до завершения авторизации) является наилучшей практикой до 31 марта 2025 года, после чего он потребуется как часть требования 3.2.1 и должен быть полностью рассмотрен во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:
  • 3.2.1.a Изучите политики, процедуры и процессы хранения и удаления данных и опросите персонал, чтобы убедиться, что процессы определены так, чтобы включать все элементы, указанные в этом требовании.
  • 3.2.1.b Проверьте файлы и системные записи на системных компонентах, где хранятся данные учетной записи, чтобы убедиться, что объем хранения данных и время хранения не превышают требований, определенных в политике хранения данных.
  • 3.2.1.c Соблюдайте механизмы, используемые для восстановления данных учетной записи, чтобы убедиться, что данные не могут быть восстановлены.
Цель:
Официальная политика хранения данных определяет, какие данные необходимо хранить, как долго и где эти данные хранятся, чтобы их можно было безопасно уничтожить или удалить, как только в них больше не будет необходимости. Единственными данными учетной записи, которые могут быть сохранены после авторизации, являются основной номер учетной записи или PAN (нечитаемый), дата истечения срока действия, имя владельца карты и код обслуживания.
Хранение данных SAD до завершения процесса авторизации также включено в политику хранения и удаления данных, так что хранение этих конфиденциальных данных сведено к минимуму и сохраняется только в течение определенного периода времени.

Надлежащая практика:
При определении мест хранения данных учетной записи учитывайте все процессы и персонал, имеющие доступ к данным, поскольку данные могли быть перемещены и сохранены в других местах, чем первоначально определено. Места хранения, которые часто упускаются из виду, включают системы резервного копирования и архивирования, съемные устройства хранения данных, бумажные носители и аудиозаписи.
Чтобы определить соответствующие требования к хранению, организация сначала должна понять свои собственные бизнес-потребности, а также любые юридические или нормативные обязательства, применимые к ее отрасли или к типу сохраняемых данных. Внедрение автоматизированного процесса для обеспечения автоматического и безопасного удаления данных по истечении установленного срока хранения может помочь гарантировать, что данные учетной записи не будут храниться сверх того, что необходимо для деловых, юридических или нормативных целей.
Методы удаления данных, когда они превышают срок хранения, включают безопасное удаление для полного удаления данных или их восстановления и невозможности восстановления. Идентификация и безопасное удаление сохраненных данных, срок хранения которых превысил установленный срок, предотвращает ненужное хранение данных, которые больше не нужны. Этот процесс может быть автоматизированным, ручным или сочетанием того и другого.
Функция удаления в большинстве операционных систем не является “безопасным удалением”, поскольку она позволяет восстановить удаленные данные, поэтому вместо этого необходимо использовать специальную функцию безопасного удаления или приложение, чтобы сделать данные невосстановимыми.
Помните, если он вам не нужен, не храните его!

Примеры:
Для поиска и удаления данных может быть запущена автоматизированная программная процедура или может быть выполнен ручной обзор областей хранения данных. Какой бы метод ни использовался, рекомендуется следить за процессом, чтобы убедиться, что он успешно завершен, а результаты записаны и подтверждены как завершенные. Внедрение безопасных методов удаления гарантирует, что данные не могут быть восстановлены, когда они больше не нужны.

Дополнительная информация:
См. NIST SP 800-88 Rev.1, Руководство по санитарной обработке носителей.
Requirement 3.3.2
3.3.2
Определенные Требования к Подходу:
Информация, хранящаяся в электронном виде до завершения авторизации, шифруется с использованием надежной криптографии.

Цель Индивидуального подхода:
Это требование не подходит для индивидуального подхода.

Примечания по применению:
Разрешено ли хранение SAD до авторизации, определяется организациями, которые управляют программами соответствия требованиям (например, платежными брендами и эквайерами). Свяжитесь с интересующими вас организациями для получения любых дополнительных критериев.
Это требование распространяется на все хранилища SAD, даже если в среде нет PAN.
Обратитесь к Требованию 3.2.1 для получения дополнительного требования, которое применяется, если SAD сохраняется до завершения авторизации.
Это требование не распространяется на эмитентов и компании, которые поддерживают услуги по выпуску, если существует законное коммерческое обоснование для хранения SAD).
Требования, предъявляемые конкретно к эмитентам, приведены в Требовании 3.3.3.
Это требование не заменяет порядок управления блоками PIN-кодов и не означает, что правильно зашифрованный блок PIN-кодов должен быть зашифрован снова.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

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

Надлежащая практика:
Организациям следует рассмотреть возможность шифрования SAD с помощью криптографического ключа, отличного от того, который используется для шифрования PAN. Обратите внимание, что это не означает, что PAN, присутствующий в SAD (как часть данных трека), должен быть зашифрован отдельно.

Определения:
Процесс авторизации завершается, как только получен ответ на запрос авторизации, то есть утверждение или отклонение.
Requirement 3.6.1.1
3.6.1.1
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Поддерживается документированное описание криптографической архитектуры, которое включает:
  • Подробная информация обо всех алгоритмах, протоколах и ключах, используемых для защиты сохраненных данных учетной записи, включая надежность ключа и дату истечения срока действия.
  • Предотвращение использования одних и тех же криптографических ключей в рабочей и тестовой средах. Этот бюллетень является наилучшей практикой до даты его вступления в силу; подробности см. в Примечаниях к применению ниже.
  • Описание использования ключа для каждого ключа.
  • Инвентаризация любых аппаратных модулей безопасности (HSM), систем управления ключами (KMS) и других защищенных криптографических устройств (SCDS), используемых для управления ключами, включая тип и местоположение устройств, как указано в требовании 12.3.4.
Цель Индивидуального подхода:
Поддерживаются и доступны точные сведения о криптографической архитектуре.

Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
В облачных реализациях HSM ответственность за криптографическую архитектуру в соответствии с этим требованием будет разделена между поставщиком облачных услуг и облачным заказчиком.
Вышеприведенный пункт (для включения в криптографическую архитектуру, чтобы предотвратить использование одних и тех же криптографических ключей в производстве и тестировании) является наилучшей практикой до 31 марта 2025 года, после чего он потребуется как часть требования 3.6.1.1 и должен быть полностью рассмотрен во время оценки PCI DSS.

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

Надлежащая практика:
Наличие автоматизированного механизма отчетности может помочь в поддержании криптографических атрибутов.
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 должен быть защищен, чтобы предотвратить перехват операций шифрования или дешифрования.
Requirement 3.6.1.4
3.6.1.4
Определенные Требования к Подходу:
Криптографические ключи хранятся в минимально возможном количестве мест.

Цель Индивидуального подхода:
Криптографические ключи сохраняются только там, где это необходимо.

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

Примечания по применению:
Это требование применяется к ключам, используемым для шифрования сохраненных данных учетной записи, и к ключам шифрования ключей, используемым для защиты ключей шифрования данных.
Требование о защите ключей, используемых для защиты сохраненных данных учетной записи от разглашения и неправильного использования, распространяется как на ключи шифрования данных, так и на ключи шифрования ключей. Поскольку один ключ шифрования ключа может предоставлять доступ ко многим ключам шифрования данных, ключи шифрования ключа требуют строгих мер защиты.

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

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

Дополнительная информация:
Процедуры управления ключами организации выиграют от согласования с отраслевыми требованиями, источники информации о жизненных циклах управления криптографическими ключами включают:
  • ISO 11568-1 Банковское дело — Управление ключами (розничная торговля) — Часть 1: Принципы (в частности, глава 10 и ссылки на Части 2 и 4)
  • NIST SP 800-57 Часть 1 Редакция 5 — Рекомендация для ключевых руководителей, Часть 1: Общие положения.
Requirement 3.6.1.3
3.6.1.3
Определенные Требования к Подходу:
Доступ к компонентам криптографических ключей с открытым текстом ограничен минимальным количеством необходимых хранителей.

Цель Индивидуального подхода:
Доступ к компонентам криптографического ключа открытого текста ограничен необходимым персоналом.

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

Надлежащая практика:
Доступ к ключевым компонентам должен предоставляться только персоналу с определенными обязанностями по хранению ключей (создание, изменение, ротация, распространение или иное обслуживание ключей шифрования).
В идеале это будет очень небольшое количество людей.
Requirement 4.2.1.1
4.2.1.1
Определенные Требования к Подходу:
Ведется учет доверенных ключей и сертификатов объекта, используемых для защиты PAN во время передачи.

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

Примечания по применению:
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

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

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

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

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

Цель Индивидуального подхода:
Криптографические ключи защищены при хранении.

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

Надлежащая практика:
Ключи шифрования данных можно защитить, зашифровав их с помощью ключа шифрования ключей. Ключи могут храниться в Аппаратном модуле безопасности (HSM).
Секретные или закрытые ключи, которые могут расшифровывать данные, никогда не должны присутствовать в исходном коде.
Requirement 3.7.1
3.7.1
Определенные Требования к Подходу:
Политики и процедуры управления ключами реализованы таким образом, чтобы включать генерацию надежных криптографических ключей, используемых для защиты хранимых данных учетной записи.

Цель Индивидуального подхода:
Генерируются надежные криптографические ключи.

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

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

Определения:
Криптопериод - это промежуток времени, в течение которого криптографический ключ может использоваться для определенной цели. Криптопериоды часто определяются в терминах периода, в течение которого ключ активен, и/или объема зашифрованного текста, который был создан ключом. Соображения при определении криптопериода включают, но не ограничиваются ими, надежность базового алгоритма, размер или длину ключа, риск компрометации ключа и критичность шифруемых данных.

Дополнительная информация: 
NIST SP 800-57 Часть 1, редакция 5, Раздел 5.3 Криптопериоды - содержит руководство по установлению периода времени, в течение которого конкретный ключ разрешен для использования законными субъектами, или ключи для данной системы будут оставаться в силе. Рекомендуемые криптопериоды для различных типов ключей приведены в таблице 1 SP 800-57, часть 1.
Положение Банка России № 683-П от 17.04.2019 "Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента":
6.2.
6.2. Криптографические ключи должны изготавливаться клиентом (самостоятельно) и (или) кредитной организацией.
6.3.
6.3. Безопасность процессов изготовления криптографических ключей СКЗИ должна обеспечиваться комплексом технологических мер защиты информации, организационных мер защиты информации и технических средств защиты информации в соответствии с технической документацией на СКЗИ.
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.8.24
А.8.24 Use of cryptography
Rules for the effective use of cryptography, including cryptographic key management, shall be defined and implemented.

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

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