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

CIS Critical Security Controls v7.1 (SANS Top 20)

Framework

CSC 14.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.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. 
NIST Cybersecurity Framework (RU):
PR.DS-1
PR.DS-1: Защищены данные находящиеся в состоянии покоя 
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ЗНИ.4 ЗНИ.4 Исключение возможности несанкционированного ознакомления с содержанием персональных данных,хранящихся на машинных носителях, и (или) использования носителей персональных данных в иных информационных системах
ИАФ.1 ИАФ.1 Идентификация и аутентификация пользователей, являющихся работниками оператора
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).
Дополнительно может использоваться шифрование на стороне клиента.
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 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. 
Guideline for a healthy information system v.2.0 (EN):
11 STANDARD
/STANDARD
 The complexity, the diversity and even the infrequent use of some passwords may encourage their storage on a physical (memo or post-it) or digital (password files, sending an email to yourself, recourse to "Remember password" buttons) medium in the event a password is lost or forgotten. 

Yet passwords are a preferred target for hackers wanting to access the system, whether it is following a theft or the possible sharing of a storage medium. This is why they must be protected by secure solutions, the best of which are using a digital safe and using encryption mechanisms. 

Of course, the password chosen for this digital safe must respect the rules set out previously and be memorised by the user, who only has to remember this password. 
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.10.1.1
A.10.1.1 Политика использования криптографических мер и средств защиты информации 
Мера обеспечения информационной безопасности: Должна быть разработана и внедрена политика использования криптографических мер и средств для обеспечения защиты информации 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
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.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 Исключение возможности несанкционированного ознакомления с содержанием информации, хранящейся на машинных носителях, и (или) использования носителей информации в иных информационных системах
ИАФ.1 ИАФ.1 Идентификация и аутентификация пользователей, являющихся работниками оператора
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.24
А.8.24 Использование криптографии
Должны быть определены и внедрены правила эффективного использования криптографии, включая управление криптографическими ключами.
А.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 Исключение возможности несанкционированного чтения информации на машинных носителях информации
ИАФ.1 ИАФ.1 Идентификация и аутентификация пользователей и инициируемых ими процессов
NIST Cybersecurity Framework (EN):
PR.DS-1 PR.DS-1: Data-at-rest is protected
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ЗНИ.4 ЗНИ.4 Исключение возможности несанкционированного чтения информации на машинных носителях информации
ИАФ.1 ИАФ.1 Идентификация и аутентификация пользователей и инициируемых ими процессов
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
10.1.1
10.1.1 Политика использования средств криптографической защиты информации

Мера обеспечения ИБ
Должна быть разработана и внедрена политика использования средств криптографической защиты информации.

Руководство по применению
При разработке политики следует учитывать следующее:
  • a) подход к управлению применением средств криптографической защиты информации в организации, включая главные принципы, на которых должна быть основана защита коммерческой информации;
  • b) определенный на основе оценки риска требуемый уровень защиты с учетом типа, стойкости и качества требуемого алгоритма шифрования;
  • c) использование шифрования для защиты информации, передаваемой с помощью мобильных или съемных носителей, или по линиям связи;
  • d) подход к управлению ключами, в том числе методы по защите криптографических ключей и восстановлению зашифрованной информации в случае утери, компрометации или повреждения ключей;
  • e) роли и обязанности, например, кто несет ответственность за:
  1. внедрение политики;
  2. управление ключами, включая их генерацию (см. 10.1.2);
  • f) стандарты, которые должны быть приняты для эффективной реализации во всей организации (какое решение используется и для каких бизнес-процессов);
  • g) влияние использования зашифрованной информации на меры обеспечения ИБ, которые базируются на проверке содержимого (например, обнаружение вредоносного ПО).
При внедрении политики криптографической защиты в организации следует учитывать требования законодательства и ограничения, которые могут применяться в отношении использования криптографических методов в разных странах, а также вопросы трансграничной передачи зашифрованной информации (см. 18.1.5).

Средства криптографической защиты информации могут использоваться для достижения различных целей, например:
  • a) обеспечение конфиденциальности: использование шифрования для защиты информации ограниченного доступа как при хранении, так и при передаче;
  • b) обеспечение целостности и аутентичности: использование электронных подписей или кодов аутентификации сообщений для проверки подлинности или целостности информации ограниченного доступа при ее передаче и хранении;
  • c) обеспечение неотказуемости: использование криптографических методов для подтверждения наличия или отсутствия события или действия;
  • d) аутентификация: использование криптографических методов для аутентификации пользователей и других системных объектов, запрашивающих доступ к пользователям, объектам и ресурсам системы или осуществляющих операции с ними.

Дополнительная информация
Принятие решения о применении криптографических решений следует рассматривать как часть более широкого процесса оценки риска и выбора мер обеспечения ИБ. Такая оценка может затем использоваться для определения того, является ли криптографическая мера подходящей, какой тип мер следует применять, с какой целью и для каких бизнес-процессов.
Политика использования криптографических мер необходима для достижения максимальных выгод и минимизации рисков использования криптографических мер, а также во избежание ненадлежащего или неправильного их использования.
Следует проконсультироваться со специалистами при выборе подходящих средств криптографической защиты информации для достижения целей политики ИБ.
Стандарт № 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.
А.5.33
А.5.33 Protection of records
Records shall be protected from loss, destruction, falsification, unauthorized access and unauthorized release.

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

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

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