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

ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022

Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А

A.10.1.1

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

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

Стандарт Банка России № СТО БР ИББС-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-Т
NIST Cybersecurity Framework (RU):
PR.DS-5
PR.DS-5:  Реализована защита от утечки данных
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. 
Guideline for a healthy information system v.2.0 (EN):
2 STRENGTHENED
/STRENGTHENED
To strengthen these measures, the creation and signature of an IT resource charter specifying the rules and instructions that must be adhered to by users may be considered. 
Постановление Правительства РФ № 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 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.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: Внедрение Систем Токенизации После Авторизации
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.24
А.8.24 Использование криптографии
Должны быть определены и внедрены правила эффективного использования криптографии, включая управление криптографическими ключами.
Приказ Минцифры № 930 Приложение 1 от 10.09.2021 "Порядок обработки, включая сбор и хранение, параметров биометрических персональных данных":
П. 17
17. При обработке, включая сбор и хранение, параметров биометрических персональных данных должны применяться средства защиты информации (в том числе средства криптографической защиты информации), обеспечивающие нейтрализацию актуальных угроз безопасности, определенных в соответствии с пунктами 4, 6 части 13 и частями 14, 14.1 статьи 14.1 Федерального закона № 149-ФЗ. 
NIST Cybersecurity Framework (EN):
PR.DS-5 PR.DS-5: Protections against data leaks are implemented
Стандарт № 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.

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

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