Куда я попал?
Приказ ФСТЭК России № 239 от 25.12.2017
Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости
АУД.10
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
АУД.10 Проведение внутренних аудитовОбязательно для категории значимости К1 К2 К3
Похожие требования
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 8. Требования к организации и управлению защитой информации":
СЗИ.1
СЗИ.1 Проведение и фиксация результатов (свидетельств) анализа необходимости совершенствования процесса системы защиты информации в случаях:
- обнаружения инцидентов защиты информации;
- обнаружения недостатков в рамках контроля системы защиты информации
3-О 2-О 1-О
СЗИ.3
СЗИ.3 Проведение и фиксация результатов (свидетельств) анализа необходимости совершенствования процесса системы защиты информации в случаях:
- изменений требований к защите информации, определенных правилами платежной системы (применяется только для участников платежных систем);
- изменений, внесенных в законодательство Российской Федерации, в том числе нормативные акты Банка России
3-О 2-О 1-О
СЗИ.2
СЗИ.2 Проведение и фиксация результатов (свидетельств) анализа необходимости совершенствования процесса системы защиты информации в случаях изменения политики финансовой организации в отношении:
- области применения процесса системы защиты информации;
- основных принципов и приоритетов в реализации процесса системы защиты информации;
- целевых показателей величины допустимого остаточного операционного риска (риск-аппетита), связанного с обеспечением безопасности информации
3-О 2-О 1-О
ГОСТ Р № 57580.3-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Управление риском реализации информационных угроз и обеспечение операционной надежности. Общие положения.":
ВИО.12
ВИО.12 Организация и выполнение деятельности по оценке возможностей нарушителя безопасности информации в отношении:
- внутреннего нарушителя безопасности информации;
- внешнего нарушителя безопасности информации.
ВИО.9.2
ВИО.9.2 Оценки возможностей нарушителя безопасности информации;
ВИО.9.4
ВИО.9.4 Определения возможных сценариев реализации информационных угроз.
ВИО.9.1
ВИО.9.1 Выявления возможных источников информационных угроз;
ВИО.9.3
ВИО.9.3 Выявления возможных уязвимостей критичной архитектуры;
NIST Cybersecurity Framework (RU):
RS.AN-5
RS.AN-5: Установлены процессы для получения, анализа и реагирования на уязвимости организации обнаруженные с помощью анализа внутренних и внешних источников (например, внутреннее тестирование, бюллетени по безопасности или исследователи безопасности).
ID.RA-3
ID.RA-3: Идентифицированы и задокументированык внутренние и внешние угрозы
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
УИ.31
УИ.31 Проведение анализа системных журналов для выявления фактов эксплуатации в прошлом уязвимостей, аналогичных вновь выявленным.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Тело стандарта":
9.2.1 Общие положения
9.2.1 Общие положения
Организация должна проводить внутренний аудит в запланированные интервалы времени с целью предоставления информации от том, что система менеджмента информационной безопасности:
a) соответствует
Организация должна проводить внутренний аудит в запланированные интервалы времени с целью предоставления информации от том, что система менеджмента информационной безопасности:
a) соответствует
- собственным требованиям организации к ее системе менеджмента информационной безопасности; а также
- требованиям настоящего документа;
b) эффективно применяется и поддерживается.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 11.4.2
11.4.2
Defined Approach Requirements:
Internal penetration testing is performed:
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:
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:
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.
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:
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:
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.
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.
Guideline for a healthy information system v.2.0 (EN):
38 STANDARD
/STANDARD
Carrying out regular audits (at least once per year) of the information system is essential as this makes it possible to correctly assess the effectiveness of measures implemented and their maintenance over time. These controls and audits are also able to measure the gaps that may remain between the theory and the practice.
They can be carried out by possible internal audit teams or by specialised external companies. Depending on the scope to test, technical and/or organisational audits will be carried out by the professionals called upon. These audits are especially necessary as the organization must comply with the regulations and legal obligations directly linked to its activities.
Following these audits, corrective actions must be identified, their application planned and monitoring points organised at regular intervals. For higher efficiency, indicators on the state of progress of the action plan may be integrated into the overview for the management.
Although security audits participate in the security of the information system by being able to show possible vulnerabilities, they are never proof of their absence and therefore do not negate the need for other control measures.
Carrying out regular audits (at least once per year) of the information system is essential as this makes it possible to correctly assess the effectiveness of measures implemented and their maintenance over time. These controls and audits are also able to measure the gaps that may remain between the theory and the practice.
They can be carried out by possible internal audit teams or by specialised external companies. Depending on the scope to test, technical and/or organisational audits will be carried out by the professionals called upon. These audits are especially necessary as the organization must comply with the regulations and legal obligations directly linked to its activities.
Following these audits, corrective actions must be identified, their application planned and monitoring points organised at regular intervals. For higher efficiency, indicators on the state of progress of the action plan may be integrated into the overview for the management.
Although security audits participate in the security of the information system by being able to show possible vulnerabilities, they are never proof of their absence and therefore do not negate the need for other control measures.
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Body":
9.2.1 General
9.2.1 General
The organization shall conduct internal audits at planned intervals to provide information on whether the information security management system:
a) conforms to
The organization shall conduct internal audits at planned intervals to provide information on whether the information security management system:
a) conforms to
- the organization’s own requirements for its information security management system; and
- the requirements of this document;
b) is effectively implemented and maintained.
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 9.3
CSC 9.3 Perform Regular Automated Port Scans
Perform automated port scans on a regular basis against all systems and alert if unauthorized ports are detected on a system.
Perform automated port scans on a regular basis against all systems and alert if unauthorized ports are detected on a system.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 11.4.5
11.4.5
Определенные Требования к Подходу:
Если сегментация используется для изоляции CDE от других сетей, тесты на проникновение выполняются для элементов управления сегментацией следующим образом:
Определенные Требования к Подходу:
Если сегментация используется для изоляции CDE от других сетей, тесты на проникновение выполняются для элементов управления сегментацией следующим образом:
- Не реже одного раза в 12 месяцев и после любых изменений в элементах управления/методах сегментации
- Охватывающий все используемые элементы управления/методы сегментации.
- В соответствии с определенной организацией методологией тестирования на проникновение.
- Подтверждение того, что средства управления/методы сегментации являются работоспособными и эффективными, и изолируют CDE от всех систем, не входящих в сферу применения.
- Подтверждение эффективности любого использования изоляции для разделения систем с различными уровнями безопасности (см. Требование 2.2.3).
- Выполняется квалифицированным внутренним ресурсом или квалифицированной внешней третьей стороной. • Существует организационная независимость тестировщика (не обязательно быть QSA или ASV).
Цель Индивидуального подхода:
Если используется сегментация, она периодически проверяется техническим тестированием на постоянную эффективность, в том числе после любых изменений, в изоляции CDE от всех систем, не входящих в сферу применения.
Определенные Процедуры Тестирования Подхода:
Если используется сегментация, она периодически проверяется техническим тестированием на постоянную эффективность, в том числе после любых изменений, в изоляции CDE от всех систем, не входящих в сферу применения.
Определенные Процедуры Тестирования Подхода:
- 11.4.5.a Изучить элементы управления сегментацией и методологию тестирования на проникновение, чтобы убедиться, что процедуры тестирования на проникновение определены для тестирования всех методов сегментации в соответствии со всеми элементами, указанными в этом требовании.
- 11.4.5.b Изучите результаты последнего теста на проникновение, чтобы убедиться, что тест на проникновение охватывает и затрагивает все элементы, указанные в этом требовании.
- 11.4.5.c Провести собеседование с персоналом, чтобы убедиться, что тест был проведен квалифицированным внутренним ресурсом или квалифицированной внешней третьей стороной и что существует организационная независимость тестировщика (не обязательно быть QSA или ASV).
Цель:
Когда объект использует элементы управления сегментацией для изоляции CDE от внутренних ненадежных сетей, безопасность CDE зависит от функционирования этой сегментации. Во многих атаках злоумышленник перемещался вбок из того, что объект считал изолированной сетью, в CDE. Использование инструментов и методов тестирования на проникновение для проверки того, что ненадежная сеть действительно изолирована от CDE, может предупредить объект о сбое или неправильной конфигурации элементов управления сегментацией, которые затем могут быть исправлены.
Надлежащая практика:
Такие методы, как обнаружение хоста и сканирование портов, могут быть использованы для проверки того, что сегменты, находящиеся вне области видимости, не имеют доступа к CDE.
Когда объект использует элементы управления сегментацией для изоляции CDE от внутренних ненадежных сетей, безопасность CDE зависит от функционирования этой сегментации. Во многих атаках злоумышленник перемещался вбок из того, что объект считал изолированной сетью, в CDE. Использование инструментов и методов тестирования на проникновение для проверки того, что ненадежная сеть действительно изолирована от CDE, может предупредить объект о сбое или неправильной конфигурации элементов управления сегментацией, которые затем могут быть исправлены.
Надлежащая практика:
Такие методы, как обнаружение хоста и сканирование портов, могут быть использованы для проверки того, что сегменты, находящиеся вне области видимости, не имеют доступа к CDE.
Requirement 11.4.2
11.4.2
Определенные Требования к Подходу:
Выполняется внутреннее тестирование на проникновение:
Определенные Требования к Подходу:
Выполняется внутреннее тестирование на проникновение:
- В соответствии с определенной организацией методологией,
- Не реже одного раза в 12 месяцев
- После любого значительного обновления или изменения инфраструктуры или приложения
- Квалифицированным внутренним ресурсом или квалифицированной внешней третьей стороной
- Существует организационная независимость тестировщика (не обязательно быть QSA или ASV).
Цель Индивидуального подхода:
Внутренняя защита системы проверяется путем технического тестирования в соответствии с определенной организацией методологией так часто, как это необходимо для устранения возникающих и новых атак и угроз и обеспечения того, чтобы значительные изменения не приводили к появлению неизвестных уязвимостей
Определенные Процедуры Тестирования Подхода:
Внутренняя защита системы проверяется путем технического тестирования в соответствии с определенной организацией методологией так часто, как это необходимо для устранения возникающих и новых атак и угроз и обеспечения того, чтобы значительные изменения не приводили к появлению неизвестных уязвимостей
Определенные Процедуры Тестирования Подхода:
- 11.4.2.a Изучите объем работ и результаты последнего внутреннего теста на проникновение, чтобы убедиться, что тестирование на проникновение выполнено в соответствии со всеми элементами, указанными в этом требовании.
- 11.4.2.b Провести собеседование с персоналом, чтобы убедиться, что внутренний тест на проникновение был выполнен квалифицированным внутренним ресурсом или квалифицированной внешней третьей стороной и что существует организационная независимость тестировщика (не обязательно быть QSA или ASV).
Цель:
Внутреннее тестирование на проникновение служит двум целям. Во-первых, как и внешний тест на проникновение, он обнаруживает уязвимости и неправильные настройки, которые могут быть использованы злоумышленником, которому удалось получить некоторый доступ к внутренней сети, независимо от того, является ли это авторизованным пользователем, выполняющим несанкционированные действия, или внешним злоумышленником, которому удалось проникнуть в объектпериметр.
Во-вторых, внутреннее тестирование на проникновение также помогает организациям обнаружить, где их процесс управления изменениями потерпел неудачу, обнаруживая ранее неизвестные системы. Кроме того, он проверяет состояние многих элементов управления, работающих в CDE.
Тест на проникновение на самом деле не является “тестом”, потому что результат теста на проникновение - это не то, что можно классифицировать как “прошел” или “не прошел”. Лучший результат теста - это каталог уязвимостей и неправильных настроек, о которых организация не знала, а тестировщик на проникновение обнаружил их раньше, чем это смог бы сделать злоумышленник. Тест на проникновение, который ничего не обнаружил, обычно указывает на недостатки тестировщика на проникновение, а не является положительным отражением состояния безопасности организации.
Надлежащая практика:
Некоторые соображения при выборе квалифицированного ресурса для проведения тестирования на проникновение включают:
Внутреннее тестирование на проникновение служит двум целям. Во-первых, как и внешний тест на проникновение, он обнаруживает уязвимости и неправильные настройки, которые могут быть использованы злоумышленником, которому удалось получить некоторый доступ к внутренней сети, независимо от того, является ли это авторизованным пользователем, выполняющим несанкционированные действия, или внешним злоумышленником, которому удалось проникнуть в объектпериметр.
Во-вторых, внутреннее тестирование на проникновение также помогает организациям обнаружить, где их процесс управления изменениями потерпел неудачу, обнаруживая ранее неизвестные системы. Кроме того, он проверяет состояние многих элементов управления, работающих в CDE.
Тест на проникновение на самом деле не является “тестом”, потому что результат теста на проникновение - это не то, что можно классифицировать как “прошел” или “не прошел”. Лучший результат теста - это каталог уязвимостей и неправильных настроек, о которых организация не знала, а тестировщик на проникновение обнаружил их раньше, чем это смог бы сделать злоумышленник. Тест на проникновение, который ничего не обнаружил, обычно указывает на недостатки тестировщика на проникновение, а не является положительным отражением состояния безопасности организации.
Надлежащая практика:
Некоторые соображения при выборе квалифицированного ресурса для проведения тестирования на проникновение включают:
- Специальные сертификаты тестирования на проникновение, которые могут свидетельствовать об уровне квалификации и компетентности тестировщика.
- Предыдущий опыт проведения тестирования на проникновение — например, количество лет опыта, а также тип и объем предыдущих заданий могут помочь подтвердить, соответствует ли опыт тестировщика потребностям задания.
Дополнительная информация:
Дополнительные рекомендации см. в Информационном дополнении: Руководство по тестированию на проникновение на веб-сайте PCI SSC.
Дополнительные рекомендации см. в Информационном дополнении: Руководство по тестированию на проникновение на веб-сайте PCI SSC.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.34
А.8.34 Защита информационных систем при аудиторском тестировании
Аудиторские тесты и иные действия по обеспечению уверенности, связанные с оценкой операционных систем, должны планироваться и согласовываться между тестировщиком и соответствующим руководством.
Аудиторские тесты и иные действия по обеспечению уверенности, связанные с оценкой операционных систем, должны планироваться и согласовываться между тестировщиком и соответствующим руководством.
Положение Банка России № 719-П от 04.06.2020 "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств":
Глава 3 п.8
3.8. Банковские платежные агенты (субагенты), за исключением банковских платежных агентов, осуществляющих операции платежного агрегатора, должны на основе критериев, установленных операторами по переводу денежных средств, проводить тестирование на проникновение и анализ уязвимостей информационной безопасности объектов информационной инфраструктуры, оценку соответствия защиты информации, сертификацию или оценку соответствия прикладного программного обеспечения автоматизированных систем и приложений.
Глава 3 п.9
3.9. Банковские платежные агенты (субагенты), осуществляющие операции платежного агрегатора, должны на основе критериев, установленных операторами по переводу денежных средств, проводить тестирование на проникновение и анализ уязвимостей информационной безопасности объектов информационной инфраструктуры, сертификацию или оценку соответствия прикладного программного обеспечения автоматизированных систем и приложений.
SWIFT Customer Security Controls Framework v2022:
7 - 7.4A Scenario Risk Assessment
7.4A Scenario Risk Assessment
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
АУД.10
АУД.10 Проведение внутренних аудитов
NIST Cybersecurity Framework (EN):
ID.RA-3
ID.RA-3: Threats, both internal and external, are identified and documented
RS.AN-5
RS.AN-5: Processes are established to receive, analyze and respond to vulnerabilities disclosed to the organization from internal and external sources (e.g. internal testing, security bulletins, or security researchers)
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.8.34
А.8.34 Protection of information systems during audit testing
Audit tests and other assurance activities involving assessment of operational systems shall be planned and agreed between the tester and appropriate management.
Audit tests and other assurance activities involving assessment of operational systems shall be planned and agreed between the tester and appropriate management.
Положение Банка России № 716-П от 08.04.2022 "О требованиях к системе управления операционным риском в кредитной организации и банковской группе":
Глава 8. Пункт 8.6
8.8.6. Проведение кредитной организацией (головной кредитной организацией банковской группы) регулярных (не реже одного раза в год) оценок состава компонентов, архитектуры, информационной инфраструктуры и характеристик информационных систем на предмет их достаточности и эффективности для обеспечения функционирования процессов кредитной организации (головной кредитной организации банковской группы), по результатам которых кредитной организацией (головной кредитной организацией банковской группы) принимаются меры по устранению выявленных недостатков в информационных системах.
Глава 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-У. - См. предыдущую редакцию)
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.