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

NIST Cybersecurity Framework (RU)

Framework

PR.DS-1

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

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

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. 
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. 
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ЗНИ.4 ЗНИ.4 Исключение возможности несанкционированного ознакомления с содержанием персональных данных,хранящихся на машинных носителях, и (или) использования носителей персональных данных в иных информационных системах
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 Реализовано шифрование данных на съемных носителях
Шифровать данные на съемных носителях 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 3.5.1.2
3.5.1.2
Defined Approach Requirements: 
 If disk-level or partition-level encryption (rather than file-, column-, or field-level database encryption) is used to render PAN unreadable, it is implemented only as follows: 
  • On removable electronic media 
OR 
  • If used for non-removable electronic media, PAN is also rendered unreadable via another mechanism that meets Requirement 3.5.1. 
Customized Approach Objective:
This requirement is not eligible for the customized approach. 

Applicability Notes:
While disk encryption may still be present on these types of devices, it cannot be the only mechanism used to protect PAN stored on those systems. Any stored PAN must also be rendered unreadable per Requirement 3.5.1—for example, through truncation or a data-level encryption mechanism. Full disk encryption helps to protect data in the event of physical loss of a disk and therefore its use is appropriate only for removable electronic media storage devices. 
Media that is part of a data center architecture (for example, hot-swappable drives, bulk tape-backups) is considered non-removable electronic media to which Requirement 3.5.1 applies 
Disk or partition encryption implementations must also meet all other PCI DSS encryption and keymanagement requirements 

Defined Approach Testing Procedures:
  • 3.5.1.2.a Examine encryption processes to verify that, if disk-level or partition-level encryption is used to render PAN unreadable, it is implemented only as follows: 
    • On removable electronic media, OR
    • If used for non-removable electronic media, examine encryption processes used to verify that PAN is also rendered unreadable via another method that meets Requirement 3.5.1. 
  • 3.5.1.2.b Examine configurations and/or vendor documentation and observe encryption processes to verify the system is configured according to vendor documentation the result is that the disk or the partition is rendered unreadable. 
Purpose:
Disk-level and partition-level encryption typically encrypts the entire disk or partition using the same key, with all data automatically decrypted when the system runs or when an authorized user requests it. For this reason, disk-level encryption is not appropriate to protect stored PAN on computers, laptops, servers, storage arrays, or any other system that provides transparent decryption upon user authentication. 

Further Information:
Where available, following vendors’ hardening and industry best practice guidelines can assist in securing PAN on these devices. 
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 9.4.1
9.4.1
Defined Approach Requirements: 
All media with cardholder data is physically secured. 

Customized Approach Objective:
Media with cardholder data cannot be accessed by unauthorized personnel. 

Defined Approach Testing Procedures:
  • 9.4.1. Examine documentation to verify that the procedures defined for protecting cardholder data include controls for physically securing all media. 
Purpose:
Controls for physically securing media are intended to prevent unauthorized persons from gaining access to cardholder data on any media. Cardholder data is susceptible to unauthorized viewing, copying, or scanning if it is unprotected while it is on removable or portable media, printed out, or left on someone’s desk. 
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.5.1.1
3.5.1.1
Defined Approach Requirements: 
Hashes used to render PAN unreadable (per the first bullet of Requirement 3.5.1) are keyed cryptographic hashes of the entire PAN, with associated key-management processes and procedures in accordance with Requirements 3.6 and 3.7. 

Applicability Notes:
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. 
This requirement is considered 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.5.1.1.a Examine documentation about the hashing method used to render PAN unreadable, including the vendor, type of system/process, and the encryption algorithms (as applicable) to verify that the hashing method results in keyed cryptographic hashes of the entire PAN, with associated key management processes and procedures. 
  • 3.5.1.1.b Examine documentation about the key management procedures and processes associated with the keyed cryptographic hashes to verify keys are managed in accordance with Requirements 3.6 and 3.7. 
  • 3.5.1.1.c Examine data repositories to verify the PAN is rendered unreadable. 
  • 3.5.1.1.d Examine audit logs, including payment application logs, to verify the PAN is rendered unreadable. 
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. 

Good Practice:
A hashing function that incorporates a randomly generated secret key provides brute force attack resistance and secret authentication integrity. 

Further Information:
Appropriate keyed cryptographic hashing algorithms include but are not limited to: HMAC, CMAC, and GMAC, with an effective cryptographic strength of at least 128-bits (NIST SP 800-131Ar2). 
Refer to the following for more information about HMAC, CMAC, and GMAC, respectively: NIST SP 800-107r1, NIST SP 800-38B, and NIST SP 800-38D). 
See NIST SP 800-107 (Revision 1): Recommendation for Applications Using Approved Hash Algorithms §5.3. 
Guideline for a healthy information system v.2.0 (EN):
31 STANDARD
/STANDARD
Frequent journeys in a professional context and the miniaturisation of IT hardware often lead to their loss or theft in a public space. This may put the sensitive data of the organization which is stored on it at risk. 

Therefore, on all mobile hardware (laptops, smartphones, USB keys, external hard drives, etc.), only data that has already been encrypted must be stored, in order to maintain its confidentiality. Only confidential information (password, smart card, PIN code, etc.) will allow the person who has it to access this data. 

A partition, archive or file encryption solution may be considered depending on the needs. Here, once again, it is essential to ensure the uniqueness and robustness of the decryption method used. 

As far as possible, it is advisable to start by a complete disk encryption before considering archive and file encryption. These last two respond to different needs and can potentially leave the data storage medium unencrypted (backup files from office suites for example). 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.8.2.3
A.8.2.3 Обращение с активами 
Мера обеспечения информационной безопасности: Должны быть разработаны и реализованы процедуры обращения с активами в соответствии с принятой в организации системой категорирования информации.
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 5.3 CSC 5.3 Securely Store Master Images
Store the master images and templates on securely configured servers, validated with integrity monitoring tools, to ensure that only authorized changes to the images are possible.
CSC 13.6 CSC 13.6 Encrypt Mobile Device Data
Utilize approved cryptographic mechanisms to protect enterprise data stored on all mobile devices.
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.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 3.5.1.2
3.5.1.2
Определенные Требования к Подходу:
Если шифрование на уровне диска или раздела (а не шифрование базы данных на уровне файлов, столбцов или полей) используется для того, чтобы сделать PAN нечитаемым, оно реализуется только следующим образом:
  • На съемных электронных носителях
ИЛИ
  • При использовании для несъемных электронных носителей PAN также становится нечитаемым с помощью другого механизма, который соответствует требованию 3.5.1.
Цель Индивидуального подхода:
Это требование не подходит для индивидуального подхода.

Примечания по применению:
Хотя шифрование диска все еще может присутствовать на устройствах такого типа, оно не может быть единственным механизмом, используемым для защиты данных, хранящихся в этих системах. Любой сохраненный PAN также должен быть сделан нечитаемым в соответствии с требованием 3.5.1 — например, с помощью усечения или механизма шифрования на уровне данных. Полное шифрование диска помогает защитить данные в случае физической потери диска, и поэтому его использование подходит только для съемных устройств хранения электронных носителей.
Носители, являющиеся частью архитектуры центра обработки данных (например, диски с возможностью горячей замены, массовые резервные копии на магнитной ленте), считаются несъемными электронными носителями, к которым применяется требование 3.5.1
Реализации шифрования диска или раздела также должны соответствовать всем другим требованиям к шифрованию PCI DSS и управлению ключами

Определенные Процедуры Тестирования Подхода:
  • 3.5.1.2.a Изучите процессы шифрования, чтобы убедиться, что, если шифрование на уровне диска или раздела используется для того, чтобы сделать PAN нечитаемым, оно реализуется только следующим образом:
    • На съемных электронных носителях ИЛИ
    • Если используется для несъемных электронных носителей, изучите процессы шифрования, используемые для проверки того, что PAN также становится нечитаемым с помощью другого метода, который соответствует требованию 3.5.1.
  • 3.5.1.2.b Изучите конфигурации и/или документацию поставщика и соблюдайте процессы шифрования, чтобы убедиться, что система настроена в соответствии с документацией поставщика. Результатом является то, что диск или раздел становятся нечитаемыми.
Цель:
Шифрование на уровне диска и раздела обычно шифрует весь диск или раздел с использованием одного и того же ключа, при этом все данные автоматически расшифровываются при запуске системы или по запросу авторизованного пользователя. По этой причине шифрование на уровне диска не подходит для защиты сохраненных данных на компьютерах, ноутбуках, серверах, массивах хранения или в любой другой системе, которая обеспечивает прозрачное дешифрование при аутентификации пользователя.

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

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

Определенные Процедуры Тестирования Подхода:
  • 9.4.1. Изучите документацию, чтобы убедиться, что процедуры, определенные для защиты данных о держателях карт, включают средства контроля физической защиты всех носителей.
Цель:
Средства контроля физической защиты носителей предназначены для предотвращения несанкционированного доступа посторонних лиц к данным о держателях карт на любых носителях. Данные о держателях карт подвержены несанкционированному просмотру, копированию или сканированию, если они не защищены, когда находятся на съемном или портативном носителе, распечатаны или оставлены на чьем-либо столе.
Requirement 3.5.1.1
3.5.1.1
Определенные Требования к Подходу:
Хэши, используемые для того, чтобы сделать PAN нечитаемым (согласно первому пункту Требования 3.5.1), представляют собой криптографические хэши с ключом для всего PAN, с соответствующими процессами и процедурами управления ключами в соответствии с требованиями 3.6 и 3.7.

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

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

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

Дополнительная информация:
Соответствующие алгоритмы криптографического хеширования с ключом включают, но не ограничиваются ими: HMAC, CMAC и GMAC с эффективной криптографической надежностью не менее 128 бит (NIST SP 800-131Ar2).
Обратитесь к следующему для получения дополнительной информации о HMAC, CMAC и GMAC, соответственно: NIST SP 800-107r1, NIST SP 800-38B и NIST SP 800-38D).
См. NIST SP 800-107 (Редакция 1): Рекомендация для приложений, использующих одобренные алгоритмы хэширования §5.3.
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: Внедрение Систем Токенизации После Авторизации
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
ЗНИ.4 ЗНИ.4 Исключение возможности несанкционированного ознакомления с содержанием информации, хранящейся на машинных носителях, и (или) использования носителей информации в иных информационных системах
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.33
А.5.33 Защита записей
Записи должны быть защищены от потери, уничтожения, подделки, несанкционированных доступа и опубликования.
SWIFT Customer Security Controls Framework v2022:
5 - 5.4 Physical and Logical Password Storage
5.4 Physical and Logical Password Storage
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ЗНИ.4 ЗНИ.4 Исключение возможности несанкционированного чтения информации на машинных носителях информации
Положение Банка России № 757-П от 20.04.2021 "Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций":
2.1.
2.1. Оператор финансовой платформы, регистратор финансовых транзакций дополнительно к информации, указанной в пункте 1.1 настоящего Положения, должны осуществлять защиту следующей информации, получаемой, подготавливаемой, обрабатываемой, передаваемой и хранимой в используемых ими автоматизированных системах:
  • информации, обрабатываемой оператором финансовой платформы при совершении финансовых сделок с использованием финансовой платформы;
  • информации, обрабатываемой регистратором финансовых транзакций при осуществлении репозитарной деятельности в отношении финансовых сделок;
  • информации, содержащейся в электронных сообщениях, составляемых участниками финансовой платформы, оператором финансовой платформы и регистратором финансовых транзакций при заключении и исполнении финансовых сделок с использованием финансовой платформы, в том числе содержащейся в электронных сообщениях - указаниях потребителей финансовых услуг;
  • информации о размещенных с использованием финансовой платформы банковских вкладах и об операциях с денежными средствами по ним, информации о совершении иных финансовых сделок и об операциях по ним, предоставленной оператором финансовой платформы регистратору финансовых транзакций;
  • электронных сообщений, которые содержат распоряжения оператора финансовой платформы в кредитную организацию о совершении операций по специальному счету на основании указания потребителя финансовых услуг.
Положение Банка России № 683-П от 17.04.2019 "Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента":
5.2.5.
5.2.5. Кредитные организации должны обеспечивать хранение:
  • информации, указанной в абзацах втором, четвертом пункта 1 настоящего Положения;
  • информации, указанной в подпунктах 5.2.3 и 5.2.4 настоящего пункта, пункте 8 настоящего Положения.
Кредитные организации должны обеспечивать целостность и доступность информации, указанной в настоящем подпункте, не менее пяти лет начиная с даты ее формирования (поступления).
NIST Cybersecurity Framework (EN):
PR.DS-1 PR.DS-1: Data-at-rest is protected
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ЗНИ.4 ЗНИ.4 Исключение возможности несанкционированного чтения информации на машинных носителях информации
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.5.33
А.5.33 Protection of records
Records shall be protected from loss, destruction, falsification, unauthorized access and unauthorized release.
Положение Банка России № 716-П от 08.04.2022 "О требованиях к системе управления операционным риском в кредитной организации и банковской группе":
Глава 8. Пункт 6.
8.6. Кредитная организация (головная кредитная организация банковской группы) обеспечивает проведение подразделениями кредитной организации (головной кредитной организации банковской группы) мероприятий, направленных на выявление, оценку, разработку форм (способов) контроля, и мероприятий, направленных на повышение качества системы управления риском информационных систем и снижение уровня риска информационных систем и сопряженных с ним рисков информационной безопасности, влияющих на информационные системы (в том числе рисков уничтожения (искажения, безвозвратного удаления) носителей и (или) хранилищ информации и данных, хранящихся в информационных системах).

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

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

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