Раздел ЖЦ.20 ГОСТА Р 57580.1 Раздела 9 - Контроль соответствия

ГОСТ Р № 57580.3-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Управление риском реализации информационных угроз и обеспечение операционной надежности. Общие положения.":

ВИО.9.2

ВИО.9.2 Оценки возможностей нарушителя безопасности информации;

ВИО.9.4

ВИО.9.4 Определения возможных сценариев реализации информационных угроз.

ВИО.9.3

ВИО.9.3 Выявления возможных уязвимостей критичной архитектуры;

Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":

п. 6. п.п. 2

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

управление уязвимостями в критичной архитектуре, из-за которых могут реализоваться информационные угрозы и которые могут повлечь превышение значений целевых показателей операционной надежности;
планирование и внедрение изменений в критичной архитектуре, направленных на обеспечение недопустимости неоказания или ненадлежащего оказания банковских услуг;
управление конфигурациями (настраиваемыми параметрами) объектов информационной инфраструктуры;
управление уязвимостями и обновлениями (исправлениями) объектов информационной инфраструктуры.

ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":

ТОН.4

ТОН.4 Организация и выполнение деятельности по тестированию готовности финансовой организации противостоять реализации информационных угроз на основе сформированных сценариев, включая:

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

УИ.28

УИ.28 Регулярное******* тестирование на проникновение (симуляция компьютерных атак), в том числе:

тестирование на проникновение объектов информатизации, непосредственно взаимодействующих с сетью Интернет;
тестирование на проникновение «внутренних» объектов информатизации, в том числе вычислительных сетей, на «границах» контуров безопасности.

УИ.30

УИ.30 Проведение сканирования на уязвимости и (или) тестирование на проникновение при существенных изменениях в критичной архитектуре и (или) внедрении новых объектов информатизации (автоматизированных систем).

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 11.3.1

11.3.1
Defined Approach Requirements:
Internal vulnerability scans are performed as follows:

At least once every three months.
High-risk and critical vulnerabilities (per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved.
Rescans are performed that confirm all highrisk and critical vulnerabilities (as noted above) have been resolved.
Scan tool is kept up to date with latest vulnerability information.
Scans are performed by qualified personnel and organizational independence of the tester exists.

Customized Approach Objective:
The security posture of all system components is verified periodically using automated tools designed to detect vulnerabilities operating inside the network. Detected vulnerabilities are assessed and rectified based on a formal risk assessment framework

Applicability Notes:
It is not required to use a QSA or ASV to conduct internal vulnerability scans.
Internal vulnerability scans can be performed by qualified, internal staff that are reasonably independent of the system component(s) being scanned (for example, a network administrator should not be responsible for scanning the network), or an entity may choose to have internal vulnerability scans performed by a firm specializing in vulnerability scanning.

Defined Approach Testing Procedures:

11.3.1.a Examine internal scan report results from the last 12 months to verify that internal scans occurred at least once every three months in the most recent 12-month period.
11.3.1.b Examine internal scan report results from each scan and rescan run in the last 12 months to verify that all high-risk and critical vulnerabilities (identified in PCI DSS Requirement 6.3.1) are resolved.
11.3.1.c Examine scan tool configurations and interview personnel to verify that the scan tool is kept up to date with the latest vulnerability information.
11.3.1.d Interview responsible personnel to verify that the scan was performed by a qualified internal resource(s) or qualified external third party and that organizational independence of the tester exists.

Purpose:
Identifying and addressing vulnerabilities promptly reduces the likelihood of a vulnerability being exploited and the potential compromise of a system component or cardholder data. Vulnerability scans conducted at least every three months provide this detection and identification.

Good Practice:
Vulnerabilities posing the greatest risk to the environment (for example, ranked high or critical per Requirement 6.3.1) should be resolved with the highest priority.
Multiple scan reports can be combined for the quarterly scan process to show that all systems were scanned and all applicable vulnerabilities were resolved as part of the three-month vulnerability scan cycle. However, additional, documentation may be required to verify nonremediated vulnerabilities are in the process of being resolved.
While scans are required at least once every three months, more frequent scans are recommended depending on the network complexity, frequency of change, and types of devices, software, and operating systems used.

Definitions:
A vulnerability scan is a combination of automated tools, techniques, and/or methods run against external and internal devices and servers, designed to expose potential vulnerabilities in applications, operating systems, and network devices that could be found and exploited by malicious individuals.

Requirement 11.4.3

11.4.3
Defined Approach Requirements:
External penetration testing is performed:

Per the entity’s defined methodology
At least once every 12 months
After any significant infrastructure or application upgrade or change
By a qualified internal resource or qualified external third party
Organizational independence of the tester exists (not required to be a QSA or ASV).

Customized Approach Objective:
External system defenses are verified by technical testing according to the entity’s defined methodology as frequently as needed to address evolving and new attacks and threats, and to ensure that significant changes do not introduce unknown vulnerabilities.

Defined Approach Testing Procedures:

11.4.3.a Examine the scope of work and results from the most recent external penetration test to verify that penetration testing is performed according to all elements specified in this requirement.
11.4.3.b Interview personnel to verify that the external penetration test was performed by a qualified internal resource or qualified external third-party and that organizational independence of the tester exists (not required to be a QSA or ASV).

Requirement 11.4.2

11.4.2
Defined Approach Requirements:
Internal penetration testing is performed:

Per the entity’s defined methodology,
At least once every 12 months
After any significant infrastructure or application upgrade or change
By a qualified internal resource or qualified external third-party
Organizational independence of the tester exists (not required to be a QSA or ASV).

Customized Approach Objective:
Internal system defenses are verified by technical testing according to the entity’s defined methodology as frequently as needed to address evolving and new attacks and threats and ensure that significant changes do not introduce unknown vulnerabilities

Defined Approach Testing Procedures:

11.4.2.a Examine the scope of work and results from the most recent internal penetration test to verify that penetration testing is performed in accordance with all elements specified in this requirement.
11.4.2.b Interview personnel to verify that the internal penetration test was performed by a qualified internal resource or qualified external third-party and that organizational independence of the tester exists (not required to be a QSA or ASV).

Purpose:
Internal penetration testing serves two purposes. Firstly, just like an external penetration test, it discovers vulnerabilities and misconfigurations that could be used by an attacker that had managed to get some degree of access to the internal network, whether that is because the attacker is an authorized user conducting unauthorized activities, or an external attacker that had managed to penetrate the entity’s perimeter.
Secondly, internal penetration testing also helps entities to discover where their change control process failed by detecting previously unknown systems. Additionally, it verifies the status of many of the controls operating within the CDE.
A penetration test is not truly a “test” because the outcome of a penetration test is not something that can be classified as a “pass” or a “fail.” The best outcome of a test is a catalog of vulnerabilities and misconfigurations that an entity did not know about and the penetration tester found them before an attacker could. A penetration test that found nothing is typically indicative of shortcomings of the penetration tester, rather than being a positive reflection of the security posture of the entity.

Good Practice:
Some considerations when choosing a qualified resource to perform penetration testing include:

Specific penetration testing certifications, which may be an indication of the tester’s skill level and competence.
Prior experience conducting penetration testing—for example, the number of years of experience, and the type and scope of prior engagements can help confirm whether the tester’s experience is appropriate for the needs of the engagement.

Further Information:
Refer to the Information Supplement: Penetration Testing Guidance on the PCI SSC website for additional guidance.

Requirement 11.4.5

11.4.5
Defined Approach Requirements:
If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls as follows:

At least once every 12 months and after any changes to segmentation controls/methods
Covering all segmentation controls/methods in use.
According to the entity’s defined penetration testing methodology.
Confirming that the segmentation controls/methods are operational and effective, and isolate the CDE from all out-of-scope systems.
Confirming effectiveness of any use of isolation to separate systems with differing security levels (see Requirement 2.2.3).
Performed by a qualified internal resource or qualified external third party. • Organizational independence of the tester exists (not required to be a QSA or ASV).

Customized Approach Objective:
If segmentation is used, it is verified periodically by technical testing to be continually effective, including after any changes, in isolating the CDE from all outof-scope systems.

Defined Approach Testing Procedures:

11.4.5.a Examine segmentation controls and review penetration-testing methodology to verify that penetration-testing procedures are defined to test all segmentation methods in accordance with all elements specified in this requirement.
11.4.5.b Examine the results from the most recent penetration test to verify the penetration test covers and addresses all elements specified in this requirement.
11.4.5.c Interview personnel to verify that the test was performed by a qualified internal resource or qualified external third party and that organizational independence of the tester exists (not required to be a QSA or ASV).

Purpose:
When an entity uses segmentation controls to isolate the CDE from internal untrusted networks, the security of the CDE is dependent on that segmentation functioning. Many attacks have involved the attacker moving laterally from what an entity deemed an isolated network into the CDE. Using penetration testing tools and techniques to validate that an untrusted network is indeed isolated from the CDE can alert the entity to a failure or misconfiguration of the segmentation controls, which can then be rectified.

Good Practice:
Techniques such as host discovery and port scanning can be used to verify out-of-scope segments have no access to the CDE.

ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":

A.12.6.1

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

Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":

Requirement 11.4.5

11.4.5
Определенные Требования к Подходу:
Если сегментация используется для изоляции CDE от других сетей, тесты на проникновение выполняются для элементов управления сегментацией следующим образом:

Не реже одного раза в 12 месяцев и после любых изменений в элементах управления/методах сегментации
Охватывающий все используемые элементы управления/методы сегментации.
В соответствии с определенной организацией методологией тестирования на проникновение.
Подтверждение того, что средства управления/методы сегментации являются работоспособными и эффективными, и изолируют CDE от всех систем, не входящих в сферу применения.
Подтверждение эффективности любого использования изоляции для разделения систем с различными уровнями безопасности (см. Требование 2.2.3).
Выполняется квалифицированным внутренним ресурсом или квалифицированной внешней третьей стороной. • Существует организационная независимость тестировщика (не обязательно быть QSA или ASV).

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

Определенные Процедуры Тестирования Подхода:

11.4.5.a Изучить элементы управления сегментацией и методологию тестирования на проникновение, чтобы убедиться, что процедуры тестирования на проникновение определены для тестирования всех методов сегментации в соответствии со всеми элементами, указанными в этом требовании.
11.4.5.b Изучите результаты последнего теста на проникновение, чтобы убедиться, что тест на проникновение охватывает и затрагивает все элементы, указанные в этом требовании.
11.4.5.c Провести собеседование с персоналом, чтобы убедиться, что тест был проведен квалифицированным внутренним ресурсом или квалифицированной внешней третьей стороной и что существует организационная независимость тестировщика (не обязательно быть QSA или ASV).

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

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

Requirement 11.4.3

11.4.3
Определенные Требования к Подходу:
Выполняется внешнее тестирование на проникновение:

В соответствии с определенной организацией методологией
Не реже одного раза в 12 месяцев
После любого значительного обновления или изменения инфраструктуры или приложения
Квалифицированным внутренним ресурсом или квалифицированной внешней третьей стороной
Существует организационная независимость тестировщика (не обязательно быть QSA или ASV).

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

Определенные Процедуры Тестирования Подхода:

11.4.3.a Изучите объем работ и результаты последнего внешнего теста на проникновение, чтобы убедиться, что тестирование на проникновение выполнено в соответствии со всеми элементами, указанными в этом требовании.
11.4.3.b Провести собеседование с персоналом, чтобы убедиться, что внешний тест на проникновение был выполнен квалифицированным внутренним ресурсом или квалифицированной внешней третьей стороной и что существует организационная независимость тестировщика (не обязательно быть QSA или ASV).

Requirement 11.4.2

11.4.2
Определенные Требования к Подходу:
Выполняется внутреннее тестирование на проникновение:

В соответствии с определенной организацией методологией,
Не реже одного раза в 12 месяцев
После любого значительного обновления или изменения инфраструктуры или приложения
Квалифицированным внутренним ресурсом или квалифицированной внешней третьей стороной
Существует организационная независимость тестировщика (не обязательно быть QSA или ASV).

Цель Индивидуального подхода:
Внутренняя защита системы проверяется путем технического тестирования в соответствии с определенной организацией методологией так часто, как это необходимо для устранения возникающих и новых атак и угроз и обеспечения того, чтобы значительные изменения не приводили к появлению неизвестных уязвимостей

Определенные Процедуры Тестирования Подхода:

11.4.2.a Изучите объем работ и результаты последнего внутреннего теста на проникновение, чтобы убедиться, что тестирование на проникновение выполнено в соответствии со всеми элементами, указанными в этом требовании.
11.4.2.b Провести собеседование с персоналом, чтобы убедиться, что внутренний тест на проникновение был выполнен квалифицированным внутренним ресурсом или квалифицированной внешней третьей стороной и что существует организационная независимость тестировщика (не обязательно быть QSA или ASV).

Цель:
Внутреннее тестирование на проникновение служит двум целям. Во-первых, как и внешний тест на проникновение, он обнаруживает уязвимости и неправильные настройки, которые могут быть использованы злоумышленником, которому удалось получить некоторый доступ к внутренней сети, независимо от того, является ли это авторизованным пользователем, выполняющим несанкционированные действия, или внешним злоумышленником, которому удалось проникнуть в объектпериметр.
Во-вторых, внутреннее тестирование на проникновение также помогает организациям обнаружить, где их процесс управления изменениями потерпел неудачу, обнаруживая ранее неизвестные системы. Кроме того, он проверяет состояние многих элементов управления, работающих в CDE.
Тест на проникновение на самом деле не является “тестом”, потому что результат теста на проникновение - это не то, что можно классифицировать как “прошел” или “не прошел”. Лучший результат теста - это каталог уязвимостей и неправильных настроек, о которых организация не знала, а тестировщик на проникновение обнаружил их раньше, чем это смог бы сделать злоумышленник. Тест на проникновение, который ничего не обнаружил, обычно указывает на недостатки тестировщика на проникновение, а не является положительным отражением состояния безопасности организации.

Надлежащая практика:
Некоторые соображения при выборе квалифицированного ресурса для проведения тестирования на проникновение включают:

Специальные сертификаты тестирования на проникновение, которые могут свидетельствовать об уровне квалификации и компетентности тестировщика.
Предыдущий опыт проведения тестирования на проникновение — например, количество лет опыта, а также тип и объем предыдущих заданий могут помочь подтвердить, соответствует ли опыт тестировщика потребностям задания.

Дополнительная информация:
Дополнительные рекомендации см. в Информационном дополнении: Руководство по тестированию на проникновение на веб-сайте PCI SSC.

Requirement 11.3.1

11.3.1
Определенные Требования к Подходу:
Проверка внутренних уязвимостей выполняется следующим образом:

По крайней мере, раз в три месяца.
Устраняются уязвимости высокого риска и критические уязвимости (в соответствии с ранжированием рисков уязвимости организации, определенным в требовании 6.3.1).
Выполняется повторное сканирование, которое подтверждает, что все уязвимости с высоким уровнем риска и критические уязвимости (как отмечено выше) были устранены.
Средство сканирования постоянно обновляется с последней информацией об уязвимостях.
Сканирование выполняется квалифицированным персоналом, и существует организационная независимость тестировщика.

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

Примечания по применению:
Для проведения внутреннего сканирования уязвимостей не требуется использовать QSA или ASV.
Внутреннее сканирование уязвимостей может выполняться квалифицированным внутренним персоналом, который разумно независим от проверяемого системного компонента (компонентов) (например, сетевой администратор не должен нести ответственность за сканирование сети), или организация может выбрать, чтобы внутреннее сканирование уязвимостей выполнялось фирмой, специализирующейся на сканировании уязвимостей.

Определенные Процедуры Тестирования Подхода:

11.3.1.a Изучите результаты отчета о внутреннем сканировании за последние 12 месяцев, чтобы убедиться, что внутренние проверки проводились не реже одного раза в три месяца в течение последнего 12-месячного периода.
11.3.1.b Изучите результаты отчета о внутреннем сканировании после каждого сканирования и повторного сканирования за последние 12 месяцев, чтобы убедиться, что все уязвимости высокого риска и критические уязвимости (определенные в требовании PCI DSS 6.3.1) устранены.
11.3.1.c Изучите конфигурации средства сканирования и опросите персонал, чтобы убедиться, что средство сканирования обновляется с учетом последней информации об уязвимостях.
11.3.1.d Опросите ответственный персонал, чтобы убедиться, что сканирование было выполнено квалифицированным внутренним ресурсом (ресурсами) или квалифицированной внешней третьей стороной и что существует организационная независимость тестировщика.

Цель:
Быстрое выявление и устранение уязвимостей снижает вероятность использования уязвимости и потенциальной компрометации системного компонента или данных о держателях карт. Сканирование уязвимостей, проводимое не реже одного раза в три месяца, обеспечивает такое обнаружение и идентификацию.

Надлежащая практика:
Уязвимости, представляющие наибольший риск для окружающей среды (например, имеющие высокий или критический рейтинг в соответствии с требованием 6.3.1), должны быть устранены с наивысшим приоритетом.
Несколько отчетов о проверке можно объединить для ежеквартального процесса проверки, чтобы показать, что все системы были проверены и все применимые уязвимости были устранены в рамках трехмесячного цикла проверки уязвимостей. Однако может потребоваться дополнительная документация для подтверждения того, что устраняемые уязвимости находятся в процессе устранения.
Хотя проверки требуются не реже одного раза в три месяца, рекомендуется проводить более частые проверки в зависимости от сложности сети, частоты изменений и типов используемых устройств, программного обеспечения и операционных систем.

Определения:
Проверка на уязвимость - это комбинация автоматизированных инструментов, методов и/или методов, выполняемых против внешних и внутренних устройств и серверов, предназначенных для выявления потенциальных уязвимостей в приложениях, операционных системах и сетевых устройствах, которые могут быть обнаружены и использованы злоумышленниками.

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).

Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":

А.8.8

А.8.8 Управление техническими уязвимостями
Должна своевременно получаться информация о технических уязвимостях используемых информационных систем, также должно оцениваться воздействие таких уязвимостей на организацию, и должны предприниматься соответствующие меры.

Положение Банка России № 719-П от 04.06.2020 "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств":

Глава 1 п. 1

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

реализацию установленных настоящим Положением уровней защиты информации для объектов информационной инфраструктуры, используемых для обработки, передачи, хранения информации, указанной в абзаце первом пункта 1.3 настоящего Положения, в целях осуществления переводов денежных средств, определенных национальным стандартом Российской Федерации ГОСТ Р 57580.1-2017 «Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер», утвержденным приказом Федерального агентства по техническому регулированию и метрологии от 8 августа 2017 года № 822-ст «Об утверждении национального стандарта Российской Федерации» (М., ФГУП «Стандартинформ», 2017) (далее - ГОСТ Р 57580.1-2017);
ежегодное тестирование на проникновение и анализ уязвимостей информационной безопасности объектов информационной инфраструктуры с учетом особенностей, предусмотренных пунктами 3.8 и 3.9 настоящего Положения;
проведение оценки соответствия уровням защиты информации, установленным настоящим Положением (далее - оценка соответствия защиты информации), в соответствии с национальным стандартом Российской Федерации ГОСТ Р 57580.2-2018 «Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Методика оценки соответствия», утвержденным приказом Федерального агентства по техническому регулированию и метрологии от 28 марта 2018 года № 156-ст «Об утверждении национального стандарта Российской Федерации» (М., ФГУП «Стандартинформ», 2018) (далее - ГОСТ Р 57580.2-2018), с учетом особенностей, предусмотренных пунктами 2.3, 2.4, 3.6 - 3.9, 4.4, 4.5, 6.7 и 6.8 настоящего Положения.

Оценка соответствия защиты информации должна осуществляться с привлечением сторонних организаций, имеющих лицензию на осуществление деятельности по технической защите конфиденциальной информации на проведение работ и услуг, предусмотренных подпунктами «б», «д» или «е» пункта 4 Положения о лицензировании деятельности по технической защите конфиденциальной информации, утвержденного постановлением Правительства Российской Федерации от 3 февраля 2012 года № 79 «О лицензировании деятельности по технической защите конфиденциальной информации» (Собрание законодательства Российской Федерации, 2012, № 7, ст. 863; 2016, № 26, ст. 4049) (далее соответственно - проверяющая организация, постановление Правительства Российской Федерации № 79).
Операторы по переводу денежных средств, банковские платежные агенты (субагенты), операторы услуг информационного обмена, операторы услуг платежной инфраструктуры должны обеспечивать хранение отчета, подготовленного проверяющей организацией по результатам оценки соответствия защиты информации, не менее пяти лет начиная с даты его выдачи проверяющей организацией.

Глава 3 п.8

3.8. Банковские платежные агенты (субагенты), за исключением банковских платежных агентов, осуществляющих операции платежного агрегатора, должны на основе критериев, установленных операторами по переводу денежных средств, проводить тестирование на проникновение и анализ уязвимостей информационной безопасности объектов информационной инфраструктуры, оценку соответствия защиты информации, сертификацию или оценку соответствия прикладного программного обеспечения автоматизированных систем и приложений.

Глава 3 п.9

3.9. Банковские платежные агенты (субагенты), осуществляющие операции платежного агрегатора, должны на основе критериев, установленных операторами по переводу денежных средств, проводить тестирование на проникновение и анализ уязвимостей информационной безопасности объектов информационной инфраструктуры, сертификацию или оценку соответствия прикладного программного обеспечения автоматизированных систем и приложений.

Методика экспресс-оценки уровня кибербезопасности организации РезБез:

10.1.2.

Проводится регулярное тестирование на проникновение

Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":

п. 1.5.

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

управление уязвимостями в критичной архитектуре, с использованием которых могут реализоваться информационные угрозы и которые могут повлечь отклонение от значений целевых показателей операционной надежности, указанных в пункте 1.3 настоящего Положения;
планирование и внедрение изменений в критичной архитектуре, направленных на обеспечение непрерывного оказания финансовых услуг;
управление конфигурациями объектов информационной инфраструктуры некредитных финансовых организаций;
управление уязвимостями и обновлениями (исправлениями) объектов информационной инфраструктуры некредитных финансовых организаций.

Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":

А.8.8

А.8.8 Management of technical vulnerabilities
Information about technical vulnerabilities of information systems in use shall be obtained, the organization’s exposure to such vulnerabilities shall be evaluated and appropriate measures shall be taken.

Положение Банка России № 716-П от 08.04.2022 "О требованиях к системе управления операционным риском в кредитной организации и банковской группе":

Глава 7. Пункт 7.

7.7. Кредитная организация (головная кредитная организация банковской группы) в целях управления риском информационной безопасности определяет во внутренних документах порядок функционирования системы информационной безопасности и обеспечивает его выполнение, в том числе:

политику информационной безопасности;
выявление и идентификацию риска информационной безопасности, а также его оценку;
участие совета директоров (наблюдательного совета) и коллегиального исполнительного органа кредитной организации (головной кредитной организации банковской группы) в решении вопросов управления риском информационной безопасности;
распределение функций и ответственности коллегиального исполнительного органа и работников кредитной организации (головной кредитной организации банковской группы), в том числе исключающее конфликт интересов в рамках организационной структуры обеспечения информационной безопасности, а также предполагающее определение должностного лица (лица, его замещающего), ответственного за функционирование системы обеспечения информационной безопасности (с прямым подчинением лицу, осуществляющему функции единоличного исполнительного органа кредитной организации (головной кредитной организации банковской группы) и не участвующего в совершении операций, сделок, организации бухгалтерского и управленческого учета, обеспечении функционирования информационных систем; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
выявление событий риска информационной безопасности, включая рассмотрение обращений клиентов, контрагентов, работников и третьих лиц, связанных с нарушением информационной безопасности, выявление и регистрацию инцидентов защиты информации, выявление фактов компрометации объектов информационной инфраструктуры; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
обеспечение осведомленности кредитной организации (головной кредитной организации банковской группы) и участников технологических процессов об актуальных угрозах безопасности информации, обмен информацией о событиях риска информационной безопасности, в том числе об инцидентах защиты информации, и представление данных в Банк России в соответствии с требованиями пункта 8 Положения Банка России N 683-П; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
организацию ресурсного (кадрового и финансового) обеспечения, включая установление требований к квалификации работников кредитной организации (головной кредитной организации банковской группы), в том числе должностного лица (лица, его замещающего), ответственного за функционирование системы обеспечения информационной безопасности; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
повышение осведомленности, обучение и развитие навыков работников кредитной организации (головной кредитной организации банковской группы) в области противодействия угрозам безопасности информации; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
установление и реализацию программ контроля, в том числе программ аудита, включая независимую оценку соответствия уровня защиты информации в отношении объектов информационной инфраструктуры кредитной организации (головной кредитной организации банковской группы) в соответствии с требованиями пункта 9 Положения Банка России N 683-П; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
проведение мониторинга риска информационной безопасности; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
соответствие фактических значений контрольных показателей уровня риска информационной безопасности принятым в кредитной организации (головной кредитной организации банковской группы) значениям; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
планирование, разработку, реализацию, контроль и совершенствование комплекса мероприятий, направленных на повышение эффективности управления риском информационной безопасности и уменьшение негативного влияния риска информационной безопасности, в том числе в соответствии с реализуемыми уровнями защиты информации в отношении объектов информационной инфраструктуры кредитной организации (головной кредитной организации банковской группы) в соответствии с требованиями подпункта 3.1 пункта 3 Положения Банка России N 683-П;(Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
обеспечение защиты от угроз безопасности информации, включая обеспечение защиты информации, управление риском информационной безопасности при передаче третьим лицам (внешним подрядчикам, контрагентам, участникам банковской группы) выполнения отдельных функций кредитной организации (головной кредитной организации банковской группы) и (или) использовании внешних информационных систем в рамках реализации направлений деятельности, в том числе в разрезе составляющих их процессов, кредитной организации (головной кредитной организации банковской группы), управление риском несанкционированного доступа внутреннего нарушителя, являющегося работником кредитной организации (головной кредитной организации банковской группы) или третьим лицом, обладающими полномочиями по доступу к объектам информационной инфраструктуры кредитной организации (далее - внутренний нарушитель), предотвращение не контролируемого кредитной организацией (головной кредитной организацией банковской группы) распространения сведений, составляющих банковскую тайну, а также обеспечение операционной надежности; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
порядок реагирования на выявленные события риска информационной безопасности, в том числе инциденты защиты информации, и восстановления деятельности кредитной организации (головной кредитной организации банковской группы) в случае реализации таких событий, включая порядок взаимодействия кредитной организации (головной кредитной организации банковской группы) с клиентами и третьими лицами, в том числе в случае получения уведомлений, связанных с осуществлением перевода денежных средств без согласия клиентов; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
выполнение требований к обеспечению защиты информации при осуществлении банковской деятельности, связанной с осуществлением перевода денежных средств, в соответствии с пунктом 5 Положения Банка России N 683-П; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
процессы применения прикладного программного обеспечения автоматизированных систем и приложений, соответствующих требованиям пункта 4 Положения Банка России N 683-П; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
ежегодное тестирование на проникновение и анализ уязвимостей информационной безопасности объектов информационной инфраструктуры в соответствии с подпунктом 3.2 пункта 3 Положения Банка России N 683-П. (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)

ГОСТ Р № 57580.1-2017 от 01.01.2018

ЖЦ.20

Список требований

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

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