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

Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости

Приказ ФСТЭК России № 239 от 25.12.2017

АУД.10

Для проведения оценки соответствия по документу войдите в систему.
АУД.10 Проведение внутренних аудитов
Обязательно для категории значимости К1 К2 К3

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

ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 8. Требования к организации и управлению защитой информации":
СЗИ.1
СЗИ.1 Проведение и фиксация результатов (свидетельств) анализа необходимости совершенствования процесса системы защиты информации в случаях: 
- обнаружения инцидентов защиты информации; 
- обнаружения недостатков в рамках контроля системы защиты информации
СЗИ.3
СЗИ.3 Проведение и фиксация результатов (свидетельств) анализа необходимости совершенствования процесса системы защиты информации в случаях: 
- изменений требований к защите информации, определенных правилами платежной системы (применяется только для участников платежных систем); 
- изменений, внесенных в законодательство Российской Федерации, в том числе нормативные акты Банка России
СЗИ.2
СЗИ.2 Проведение и фиксация результатов (свидетельств) анализа необходимости совершенствования процесса системы защиты информации в случаях изменения политики финансовой организации в отношении: 
- области применения процесса системы защиты информации; - основных принципов и приоритетов в реализации процесса системы защиты информации; 
- целевых показателей величины допустимого остаточного операционного риска (риск-аппетита), связанного с обеспечением безопасности информации
NIST Cybersecurity Framework (RU):
RS.AN-5
RS.AN-5: Установлены процессы для получения, анализа и реагирования на уязвимости организации обнаруженные с помощью анализа внутренних и внешних источников (например, внутреннее тестирование, бюллетени по безопасности или исследователи безопасности).
ID.RA-3
ID.RA-3: Идентифицированы и задокументированык внутренние и внешние угрозы
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования":
9.2.1 Общие положения
9.2.1 Общие положения
Организация должна проводить внутренний аудит в запланированные интервалы времени с целью предоставления информации от том, что система менеджмента информационной безопасности:
a) соответствует
  1. собственным требованиям организации к ее системе менеджмента информационной безопасности; а также
  2. требованиям настоящего документа;
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:
  • 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. 
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. 
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements":
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
  1. the organization’s own requirements for its information security management system; and
  2. 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.
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.2
11.4.2
Определенные Требования к Подходу:
Выполняется внутреннее тестирование на проникновение:
  • В соответствии с определенной организацией методологией,
  • Не реже одного раза в 12 месяцев
  • После любого значительного обновления или изменения инфраструктуры или приложения
  • Квалифицированным внутренним ресурсом или квалифицированной внешней третьей стороной
  • Существует организационная независимость тестировщика (не обязательно быть QSA или ASV).
Цель Индивидуального подхода:
Внутренняя защита системы проверяется путем технического тестирования в соответствии с определенной организацией методологией так часто, как это необходимо для устранения возникающих и новых атак и угроз и обеспечения того, чтобы значительные изменения не приводили к появлению неизвестных уязвимостей

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

Надлежащая практика:
Некоторые соображения при выборе квалифицированного ресурса для проведения тестирования на проникновение включают:
  • Специальные сертификаты тестирования на проникновение, которые могут свидетельствовать об уровне квалификации и компетентности тестировщика.
  • Предыдущий опыт проведения тестирования на проникновение — например, количество лет опыта, а также тип и объем предыдущих заданий могут помочь подтвердить, соответствует ли опыт тестировщика потребностям задания.
Дополнительная информация:
Дополнительные рекомендации см. в Информационном дополнении: Руководство по тестированию на проникновение на веб-сайте 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.