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

Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022

Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Body

7.5.1 General

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

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

ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 9. Требования к защите информации на этапах жизненного цикла автоматизированных систем и приложений":
ЖЦ.11
ЖЦ.11 Документарное определение в проектной и эксплуатационной документации на систему защиты информации АС (документарное определение в соответствии с мерой ЖЦ.11 выполняется в случае необходимости): 
  • состава и порядка применения клиентами финансовой организации прикладного ПО и (или) технических и (или) организационных мер защиты информации (далее при совместном упоминании - клиентские компоненты); 
  • параметров настроек клиентских компонентов и информационной инфраструктуры клиентов финансовой организации, предназначенной для размещения клиентских компонентов; 
  • описания мер по обеспечению использования клиентом определенных доверенных версий (сборок) прикладного ПО
3-О 2-О 1-О
ЖЦ.3
ЖЦ.3 Документарное определение в проектной и эксплуатационной документации на систему защиты информации АС: 
  • состава и порядка применения технических и (или) организационных мер системы защиты информации АС; 
  • параметров настроек технических мер системы защиты информации АС и компонентов информационной инфраструктуры, предназначенных для размещения указанных технических мер (параметры настроек компонентов информационной инфраструктуры, предназначенных для размещения технических мер защиты информации, определяются в случае необходимости)
3-О 2-О 1-О
ГОСТ Р № 22301 от 01.01.2022 "Надежность в технике. Системы менеджмента непрерывности деятельности. Требования":
Р. 7 п. 5 пп. 1
 7.5.1 Общие положения 
СМНД организации должна включать следующее: 
  • а ) документированную информацию, соответствующую требованиям настоящего стандарта; 
  • b ) определенную организацией документированную информацию, необходимую для обеспечения результативности СМНД. 
Примечание — Объем документированной информации СМНД может отличаться в разных организациях вследствие: 
  •  размера организации и особенностей ее видов деятельности, процессов, продукции, услуг и доступных ресурсов; 
  •  сложности процессов организации, ее СМНД и их взаимодействия; 
  •  компетентности персонала. 
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Тело стандарта":
7.5.1 Общие положения
7.5.1 Общие положения
Система менеджмента информационной безопасности организации должна содержать:
  • a) документированную информацию, требуемую настоящим документом; а также
  • b) документированную информацию, определенную организацией как необходимой для обеспечения эффективности системы менеджмента информационной безопасности.
ПРИМЕЧАНИЕ Количество документированной информации для системы менеджмента информационной безопасности может отличаться для разных организаций в зависимости от:
  • 1) размера организации и типа ее деятельности, процессов, продуктов и сервисов;
  • 2) сложности процессов и их взаимодействия; а также
  • 3) компетентности лиц.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования":
7.5.1
 7.5.1 Общие положения
Система менеджмента информационной безопасности организации должна включать:
а) документированную информацию, требуемую в соответствии с настоящим стандартом;
b) документированную информацию, определяемую организацией как необходимую для обеспечения результативности системы менеджмента информационной безопасности.

Примечание — Объем документированной информации, относящейся к системе менеджмента информационной безопасности, в разных организациях может быть различным, в зависимости: 
а) от размеров организации и вида ее деятельности, процессов, продуктов и услуг; 
b) сложности процессов и их взаимодействия; 
с) квалификации персонала. 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 11.4.1
11.4.1
Defined Approach Requirements: 
A penetration testing methodology is defined, documented, and implemented by the entity, and includes:
  • Industry-accepted penetration testing approaches.
  • Coverage for the entire CDE perimeter and critical systems.
  • Testing from both inside and outside the network.
  • Testing to validate any segmentation and scopereduction controls.
  • Application-layer penetration testing to identify, at a minimum, the vulnerabilities listed in Requirement 6.2.4.
  • Network-layer penetration tests that encompass all components that support network functions as well as operating systems.
  • Review and consideration of threats and vulnerabilities experienced in the last 12 months.
  • Documented approach to assessing and addressing the risk posed by exploitable vulnerabilities and security weaknesses found during penetration testing.
  • Retention of penetration testing results and remediation activities results for at least 12 months. 
Customized Approach Objective:
A formal methodology is defined for thorough technical testing that attempts to exploit vulnerabilities and security weaknesses via simulated attack methods by a competent manual attacker. 

Applicability Notes:
Testing from inside the network (or “internal penetration testing”) means testing from both inside the CDE and into the CDE from trusted and untrusted internal networks. 
Testing from outside the network (or “external penetration testing”) means testing the exposed external perimeter of trusted networks, and critical systems connected to or accessible to public network infrastructures. 

Defined Approach Testing Procedures:
  • 11.4.1 Examine documentation and interview personnel to verify that the penetration-testing methodology defined, documented, and implemented by the entity includes all elements specified in this requirement. 
Purpose:
Attackers spend a lot of time finding external and internal vulnerabilities to leverage to obtain access to cardholder data and then to exfiltrate that data. As such, entities need to test their networks thoroughly, just as an attacker would do. This testing allows the entity to identify and remediate weakness that might be leveraged to compromise the entity’s network and data, and then to take appropriate actions to protect the network and system components from such attacks. 

Good Practice:
Penetration testing techniques will differ based on an organization’s needs and structure and should be suitable for the tested environment—for example, fuzzing, injection, and forgery tests might be appropriate. The type, depth, and complexity of the testing will depend on the specific environment and the needs of the organization. 

Definitions:
Penetration tests simulate a real-world attack situation intending to identify how far an attacker could penetrate an environment, given differing amounts of information provided to the tester. This allows an entity to better understand its potential exposure and develop a strategy to defend against attacks. A penetration test differs from a vulnerability scan, as a penetration test is an active process that usually includes exploiting identified vulnerabilities. 
Scanning for vulnerabilities alone is not a penetration test, nor is a penetration test adequate if the focus is solely on trying to exploit vulnerabilities found in a vulnerability scan. Conducting a vulnerability scan may be one of the first steps, but it is not the only step a penetration tester will perform to plan the testing strategy. Even if a vulnerability scan does not detect known vulnerabilities, the penetration tester will often gain enough knowledge about the system to identify possible security gaps. 
Penetration testing is a highly manual process. While some automated tools may be used, the tester uses their knowledge of systems to gain access into an environment. Often the tester will chain several types of exploits together with the goal of breaking through layers of defenses. For example, if the tester finds a way to gain access to an application server, the tester will then use the compromised server as a point to stage a new attack based on the resources to which the server has access. In this way, a tester can simulate the techniques used by an attacker to identify areas of potential weakness in the environment. The testing of security monitoring and detection methods—for example, to confirm the effectiveness of logging and file integrity monitoring mechanisms, should also be considered. 

Further Information:
Refer to the Information Supplement: Penetration Testing Guidance for additional guidance. 
Industry-accepted penetration testing approaches include: 
  • The Open Source Security Testing Methodology and Manual (OSSTMM) 
  • Open Web Application Security Project (OWASP) penetration testing programs. 
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. 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 11.4.1
11.4.1
Определенные Требования к Подходу:
Методология тестирования на проникновение определяется, документируется и внедряется организацией и включает:
  • Общепринятые в отрасли подходы к тестированию на проникновение.
  • Охват всего периметра CDE и критически важных систем.
  • Тестирование как внутри сети, так и за ее пределами.
  • Тестирование для проверки любых элементов управления сегментацией и областью действия.
  • Тестирование на проникновение на уровне приложений для выявления, как минимум, уязвимостей, перечисленных в требовании 6.2.4.
  • Тесты на проникновение на сетевом уровне, которые охватывают все компоненты, поддерживающие сетевые функции, а также операционные системы.
  • Обзор и рассмотрение угроз и уязвимостей, возникших за последние 12 месяцев.
  • Документированный подход к оценке и устранению рисков, связанных с уязвимостями, которые могут быть использованы, и слабостями безопасности, обнаруженными в ходе тестирования на проникновение.
  • Сохранение результатов тестирования на проникновение и результатов мероприятий по исправлению в течение как минимум 12 месяцев.
Цель Индивидуального подхода:
Официальная методология определена для тщательного технического тестирования, которое пытается использовать уязвимости и слабые места в системе безопасности с помощью имитируемых методов атаки компетентным злоумышленником вручную.

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

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

Надлежащая практика:
Методы тестирования на проникновение будут отличаться в зависимости от потребностей и структуры организации и должны подходить для тестируемой среды — например, могут быть уместны тесты на размытие, внедрение и подделку. Тип, глубина и сложность тестирования будут зависеть от конкретной среды и потребностей организации.

Определения:
Тесты на проникновение имитируют реальную ситуацию атаки с целью определения того, как далеко злоумышленник может проникнуть в среду, учитывая различные объемы информации, предоставляемой тестировщику. Это позволяет организации лучше понять свою потенциальную уязвимость и разработать стратегию защиты от атак. Тест на проникновение отличается от сканирования уязвимостей, поскольку тест на проникновение - это активный процесс, который обычно включает в себя использование выявленных уязвимостей.
Сканирование на наличие уязвимостей само по себе не является тестом на проникновение, и тест на проникновение не является адекватным, если основное внимание уделяется исключительно попытке использовать уязвимости, обнаруженные при сканировании уязвимостей. Проведение проверки на уязвимость может быть одним из первых шагов, но это не единственный шаг, который тестировщик проникновения выполнит для планирования стратегии тестирования. Даже если проверка на уязвимость не обнаруживает известных уязвимостей, тестировщик проникновения часто получает достаточно знаний о системе, чтобы выявить возможные пробелы в безопасности.
Тестирование на проникновение - это в высшей степени ручной процесс. Хотя могут использоваться некоторые автоматизированные инструменты, тестировщик использует свои знания о системах для получения доступа к среде. Часто тестировщик связывает несколько типов эксплойтов вместе с целью прорыва через слои защиты. Например, если тестировщик найдет способ получить доступ к серверу приложений, он затем будет использовать скомпрометированный сервер в качестве точки для проведения новой атаки на основе ресурсов, к которым сервер имеет доступ. Таким образом, тестировщик может имитировать методы, используемые злоумышленником для выявления областей потенциальной уязвимости в среде. Следует также рассмотреть возможность тестирования методов мониторинга и обнаружения безопасности — например, для подтверждения эффективности механизмов ведения журнала и контроля целостности файлов.

Дополнительная информация:
Дополнительные указания см. в Информационном дополнении: Руководство по тестированию на проникновение.
Принятые в отрасли подходы к тестированию на проникновение включают:
  • Методология и руководство по тестированию безопасности с открытым исходным кодом (OSSTMM)
  • Программы тестирования на проникновение Open Web Application Security Project (OWASP).
Requirement 12.3.3
12.3.3
Определенные Требования к Подходу:
Используемые наборы криптографических шифров и протоколы документируются и пересматриваются не реже одного раза в 12 месяцев, включая, по крайней мере, следующее:
  • Актуальный перечень всех используемых наборов криптографических шифров и протоколов, включая назначение и место использования.
  • Активный мониторинг отраслевых тенденций в отношении сохранения жизнеспособности всех используемых наборов криптографических шифров и протоколов.
  • Документированная стратегия реагирования на ожидаемые изменения в криптографических уязвимостях.
Цель Индивидуального подхода:
Организация способна быстро реагировать на любые уязвимости в криптографических протоколах или алгоритмах, если эти уязвимости влияют на защиту данных о держателях карт.

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

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

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

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

Дополнительная информация:
Обратитесь к NIST SP 800-131a, Переход к использованию криптографических алгоритмов и длин ключей.

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

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