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

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

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

A.18.1.5

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

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

Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 7 п. 7 п.п. 5
7.7.5. Для обеспечения безопасности необходимо использовать СКЗИ, которые:
  • допускают встраивание в технологические процессы обработки электронных сообщений, обеспечивают взаимодействие с прикладным программным обеспечением на уровне обработки запросов на криптографические преобразования и выдачи результатов;
  • обладают полным комплектом эксплуатационной документации, предоставляемых разработчиком СКЗИ, включая описание ключевой системы, правил работы с ней и обоснование необходимого организационно-штатного обеспечения;
  • сертифицированы уполномоченным государственным органом либо имеют разрешение ФСБ России.
CIS Critical Security Controls v8 (The 18 CIS CSC):
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. 
NIST Cybersecurity Framework (RU):
ID.GV-3
ID.GV-3: Управляются и доступны для понимания правовые и нормативные требования в отношении кибербезопасности, в том числе  обязательства в отношении конфиденциальности и гражданских свобод
Приказ ФАПСИ № 152 от 13.06.2001 "Инструкция об организации и обеспечении безопасности хранения, обработки и передачи по каналам связи с использованием средств криптографической защиты информации с ограниченным доступом, не содержащей сведений, составляющих государственную тайну":
Глава II п. 16
16. При определении обязанностей сотрудников органов криптографической защиты лицензиаты ФАПСИ должны учитывать, что безопасность хранения, обработки и передачи по каналам связи с использованием СКЗИ конфиденциальной информации обеспечивается:
  • соблюдением сотрудниками органов криптографической защиты режима конфиденциальности при обращении со сведениями, которые им доверены или стали известны по работе, в том числе со сведениями о функционировании и порядке обеспечения безопасности применяемых СКЗИ и ключевых документах к ним;
  • точным выполнением сотрудниками органов криптографической защиты требований к обеспечению безопасности конфиденциальной информации;
  • надежным хранением сотрудниками органов криптографической защиты СКЗИ, эксплуатационной и технической документации к ним, ключевых документов, носителей конфиденциальной информации;
  • своевременным выявлением сотрудниками органов криптографической защиты попыток посторонних лиц получить сведения о защищаемой конфиденциальной информации, об используемых СКЗИ или ключевых документах к ним;
  • немедленным принятием сотрудниками органов криптографической защиты мер по предупреждению разглашения защищаемых сведений конфиденциального характера, а также возможной утечки таких сведений при выявлении фактов утраты или недостачи СКЗИ, ключевых документов к ним, удостоверений, пропусков, ключей от помещений, хранилищ, сейфов (металлических шкафов), личных печатей и т.п.
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
16.11
16.11 Используются проверенные модули или службы в приложениях для компонентов обеспечения безопасности
Используются проверенные модули для шифрования, ведения журналов и управления идентификацией пользователей.

Для обеспечения критичных компонентов безопасности используются платформенные функции.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
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.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. 
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. 
Постановление Правительства РФ № 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.
Приказ Минздрава № 911н от 24.12.2018 "Требования к государственным информационным системам в сфере здравоохранения субъектов Российской Федерации, медицинским информационным системам медицинских организаций и информационным системам":
Раздел II п. 9 п.п. в) в) быть сертифицированными Федеральной службой безопасности Российской Федерации и (или) Федеральной службой по техническому и экспортному контролю в отношении входящих в их состав средств защиты информации, включающих программно-аппаратные средства, средства антивирусной и криптографической защиты информации и средства защиты информации от несанкционированного доступа, уничтожения, модификации и блокирования доступа к ней, а также от иных неправомерных действий в отношении такой информации (в том числе сведения, составляющие врачебную тайну);
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.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.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.
Приказ ФСБ России № 196 от 06.05.2019 "Требования к средствам, предназначенным для обнаружения, предупреждения и ликвидации последствий компьютерных атак и реагирования на компьютерные инциденты":
VII п.20
20. Криптографические средства защиты информации, необходимой субъектам критической информационной инфраструктуры при обнаружении, предупреждении и (или) ликвидации последствий компьютерных атак, должны быть сертифицированы в системе сертификации средств криптографической защиты информации.
NIST Cybersecurity Framework (EN):
ID.GV-3 ID.GV-3: Legal and regulatory requirements regarding cybersecurity, including privacy and civil liberties obligations, are understood and managed

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

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

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