Куда я попал?
CIS Critical Security Controls v7.1 (SANS Top 20)
Framework
CSC 20.2
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
CIS Critical Security Controls v8 (The 18 CIS CSC):
18.2
18.2 Perform Periodic External Penetration Tests
Perform periodic external penetration tests based on program requirements, no less than annually. External penetration testing must include enterprise and environmental reconnaissance to detect exploitable information. Penetration testing requires specialized skills and experience and must be conducted through a qualified party. The testing may be clear box or opaque box.
Perform periodic external penetration tests based on program requirements, no less than annually. External penetration testing must include enterprise and environmental reconnaissance to detect exploitable information. Penetration testing requires specialized skills and experience and must be conducted through a qualified party. The testing may be clear box or opaque box.
18.5
18.5 Perform Periodic Internal Penetration Tests
Perform periodic internal penetration tests based on program requirements, no less than annually. The testing may be clear box or opaque box.
Perform periodic internal penetration tests based on program requirements, no less than annually. The testing may be clear box or opaque box.
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 6. п.п. 5
6.5. Кредитные организации в части тестирования операционной надежности технологических процессов должны принимать организационные и технические меры, направленные на проведение сценарного анализа (в части возможной реализации информационных угроз в отношении критичной архитектуры, а также возникновения сбоев объектов информационной инфраструктуры), с учетом требований подпункта 2.1.5 пункта 2.1 Положения Банка России N 716-П и проводить с использованием результатов сценарного анализа тестирование готовности кредитной организации противостоять реализации информационных угроз в отношении критичной архитектуры.
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
ТОН.4
ТОН.4 Организация и выполнение деятельности по тестированию готовности финансовой организации противостоять реализации информационных угроз на основе сформированных сценариев, включая:
- выявление конфигураций объектов информатизации, имеющих уязвимости;
- выявление актуальных слабостей (уязвимостей) используемого программного обеспечения;
- определение актуальных компьютерных атак, которые могут быть реализованы путем эксплуатации выявленных слабостей и уязвимостей;
- определение вероятных инцидентов, связанных с реализацией информационных угроз, к которым может привести реализация актуальных компьютерных атак;
- определение потенциальных последствий от реализации инцидентов, в том числе максимально возможных финансовых потерь.
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
18.2
18.2 Реализовано регулярное проведение внешнего тестирования на проникновение
Проводить периодические внешние тесты на проникновение в соответствии с требованиями программы, не реже одного раза в год. Внешнее тестирование на проникновение должно включать в себя разведку предприятия и окружающей среды для обнаружения информации, пригодной для использования. Тестирование на проникновение требует специальных навыков и опыта и должно проводиться квалифицированной стороной. Тестирование может проводиться в прозрачной или непрозрачной коробке.
Проводить периодические внешние тесты на проникновение в соответствии с требованиями программы, не реже одного раза в год. Внешнее тестирование на проникновение должно включать в себя разведку предприятия и окружающей среды для обнаружения информации, пригодной для использования. Тестирование на проникновение требует специальных навыков и опыта и должно проводиться квалифицированной стороной. Тестирование может проводиться в прозрачной или непрозрачной коробке.
18.5
18.5 Реализовано регулярное проведение внутреннего тестирования на проникновение
Проводить периодические внутренние тесты на проникновение в соответствии с требованиями программы, не реже одного раза в год. Тестирование может проводиться в прозрачной или непрозрачной коробке.
Проводить периодические внутренние тесты на проникновение в соответствии с требованиями программы, не реже одного раза в год. Тестирование может проводиться в прозрачной или непрозрачной коробке.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 11.4.3
11.4.3
Defined Approach Requirements:
External penetration testing is performed:
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:
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:
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.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.12.6.1
A.12.6.1 Процесс управления техническими уязвимостями
Мера обеспечения информационной безопасности: Должна быть своевременно получена информация о технических уязвимостях используемых информационных систем, оценена подверженность организации таким уязвимостям, и должны быть приняты соответствующие меры в отношении связанного с этим риска информационной безопасности
Мера обеспечения информационной безопасности: Должна быть своевременно получена информация о технических уязвимостях используемых информационных систем, оценена подверженность организации таким уязвимостям, и должны быть приняты соответствующие меры в отношении связанного с этим риска информационной безопасности
A.18.2.3
A.18.2.3 Анализ технического соответствия
Мера обеспечения информационной безопасности: Информационные системы должны регулярно проверяться на предмет соответствия стандартам и политикам информационной безопасности организации
Мера обеспечения информационной безопасности: Информационные системы должны регулярно проверяться на предмет соответствия стандартам и политикам информационной безопасности организации
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.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.
Тест на проникновение на самом деле не является “тестом”, потому что результат теста на проникновение - это не то, что можно классифицировать как “прошел” или “не прошел”. Лучший результат теста - это каталог уязвимостей и неправильных настроек, о которых организация не знала, а тестировщик на проникновение обнаружил их раньше, чем это смог бы сделать злоумышленник. Тест на проникновение, который ничего не обнаружил, обычно указывает на недостатки тестировщика на проникновение, а не является положительным отражением состояния безопасности организации.
Надлежащая практика:
Некоторые соображения при выборе квалифицированного ресурса для проведения тестирования на проникновение включают:
Внутреннее тестирование на проникновение служит двум целям. Во-первых, как и внешний тест на проникновение, он обнаруживает уязвимости и неправильные настройки, которые могут быть использованы злоумышленником, которому удалось получить некоторый доступ к внутренней сети, независимо от того, является ли это авторизованным пользователем, выполняющим несанкционированные действия, или внешним злоумышленником, которому удалось проникнуть в объектпериметр.
Во-вторых, внутреннее тестирование на проникновение также помогает организациям обнаружить, где их процесс управления изменениями потерпел неудачу, обнаруживая ранее неизвестные системы. Кроме того, он проверяет состояние многих элементов управления, работающих в CDE.
Тест на проникновение на самом деле не является “тестом”, потому что результат теста на проникновение - это не то, что можно классифицировать как “прошел” или “не прошел”. Лучший результат теста - это каталог уязвимостей и неправильных настроек, о которых организация не знала, а тестировщик на проникновение обнаружил их раньше, чем это смог бы сделать злоумышленник. Тест на проникновение, который ничего не обнаружил, обычно указывает на недостатки тестировщика на проникновение, а не является положительным отражением состояния безопасности организации.
Надлежащая практика:
Некоторые соображения при выборе квалифицированного ресурса для проведения тестирования на проникновение включают:
- Специальные сертификаты тестирования на проникновение, которые могут свидетельствовать об уровне квалификации и компетентности тестировщика.
- Предыдущий опыт проведения тестирования на проникновение — например, количество лет опыта, а также тип и объем предыдущих заданий могут помочь подтвердить, соответствует ли опыт тестировщика потребностям задания.
Дополнительная информация:
Дополнительные рекомендации см. в Информационном дополнении: Руководство по тестированию на проникновение на веб-сайте PCI SSC.
Дополнительные рекомендации см. в Информационном дополнении: Руководство по тестированию на проникновение на веб-сайте PCI SSC.
Положение Банка России № 719-П от 04.06.2020 "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств":
Глава 3 п.8
3.8. Банковские платежные агенты (субагенты), за исключением банковских платежных агентов, осуществляющих операции платежного агрегатора, должны на основе критериев, установленных операторами по переводу денежных средств, проводить тестирование на проникновение и анализ уязвимостей информационной безопасности объектов информационной инфраструктуры, оценку соответствия защиты информации, сертификацию или оценку соответствия прикладного программного обеспечения автоматизированных систем и приложений.
Глава 3 п.9
3.9. Банковские платежные агенты (субагенты), осуществляющие операции платежного агрегатора, должны на основе критериев, установленных операторами по переводу денежных средств, проводить тестирование на проникновение и анализ уязвимостей информационной безопасности объектов информационной инфраструктуры, сертификацию или оценку соответствия прикладного программного обеспечения автоматизированных систем и приложений.
Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":
п. 1.8.
1.8. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны принимать организационные и технические меры, направленные на проведение сценарного анализа (в части возможной реализации информационных угроз) и тестирования с использованием его результатов своей готовности противостоять реализации информационных угроз в отношении критичной архитектуры.
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
18.2.3
18.2.3 Анализ технического соответствия
Мера обеспечения ИБ
Информационные системы должны регулярно проверяться на предмет соответствия стандартам и политикам ИБ организации.
Руководство по применению
Техническое соответствие должно проверяться предпочтительно с помощью автоматизированных инструментов, которые генерируют технические отчеты для последующей интерпретации техническим специалистом. Кроме этого, опытный системный инженер может проводить ручные проверки (с использованием соответствующих программных средств, при необходимости).
Если используются тесты на проникновение или оценка уязвимостей, следует проявлять осторожность, поскольку такие действия могут привести к нарушению безопасности системы. Такие тесты следует планировать, документировать и повторять.
Любая проверка технического соответствия должна проводиться только компетентными уполномоченными лицами или под их наблюдением.
Дополнительная информация
Проверки технического соответствия включают в себя экспертизу эксплуатируемых систем на предмет того, что аппаратные и программные меры обеспечения ИБ были правильно реализованы. Этот тип проверки соответствия требует наличия специалиста по технической экспертизе.
К проверкам соответствия относятся, например, тестирование на проникновение и оценка уязвимостей, которые могут проводиться независимыми экспертами, привлекаемыми на контрактной основе специально для этой цели. Это может быть полезным при обнаружении уязвимостей в системе и для проверки того, насколько эффективны меры обеспечения ИБ, направленные на предотвращение несанкционированного доступа, возможного вследствие использования этих уязвимостей.
Тесты на проникновение и оценка уязвимостей дают возможность получить мгновенный снимок системы в конкретном состоянии в конкретный момент времени. Снимок ограничен теми частями системы, которые фактически тестируются во время попытки(ок) осуществления проникновения. Тестирование на проникновение и оценка уязвимостей не заменяют оценку рисков.
ИСО/МЭК ТО 27008 [13] содержит конкретные рекомендации, связанные с проверками технического соответствия.
12.6.1
В ответ на выявление потенциальных технических уязвимостей должны быть предприняты надлежащие и своевременные действия. Необходимо придерживаться следующих указаний для создания эффективного процесса управления техническими уязвимостями:
12.6.1 Процесс управления техническими уязвимостями
Мера обеспечения ИБ
Должна быть своевременно получена информация о технических уязвимостях используемых информационных систем, оценена подверженность организации таким уязвимостям и приняты соответствующие меры в отношении связанного с этим риска ИБ.
Руководство по применению
Актуальный и полный перечень активов (раздел 8) является необходимым условием для эффективного управления техническими уязвимостями. Специальная информация, необходимая для поддержки управления техническими уязвимостями, включает в себя информацию о поставщике программного обеспечения, номерах версий, текущем состоянии развертывания (например, какое программное обеспечение установлено в каких системах) и работниках, ответственных за программное обеспечение в организации.
В ответ на выявление потенциальных технических уязвимостей должны быть предприняты надлежащие и своевременные действия. Необходимо придерживаться следующих указаний для создания эффективного процесса управления техническими уязвимостями:
- a) организация должна определить и установить роли и обязанности, связанные с управлением техническими уязвимостями, включая их мониторинг, оценку риска, исправление ошибок, отслеживание активов и любые необходимые обязанности по координации процесса;
- b) для программного обеспечения и других технологий (на основе перечня активов, см. 8.1.1) следует идентифицировать информационные ресурсы, которые будут использоваться для выявления соответствующих технических уязвимостей и поддержания осведомленности о них; эти информационные ресурсы должны обновляться в соответствии с изменениями в перечне активов или при обнаружении новых и полезных ресурсов;
- c) следует определить сроки реагирования на уведомления о потенциально значимых технических уязвимостях;
- d) после выявления потенциальной технической уязвимости организация должна определить связанные с ней риски и действия, которые необходимо предпринять; такие действия могут включать применение пакетов исправлений к уязвимым системам или применение компенсирующих мер обеспечения ИБ;
- e) в зависимости от того, насколько срочно необходимо устранить техническую уязвимость, предпринимаемые действия должны проводиться в соответствии с мерами по управлению изменениями (см. 12.1.2) или в соответствии с процедурами реагирования на инциденты ИБ (см. 16.1.5);
- f) если доступно официальное исправление, следует оценить риски, связанные с его установкой (риски, связанные с уязвимостью, следует сравнить с рисками, которые могут возникнуть вследствие установки исправления);
- g) пакеты исправлений должны быть проверены и оценены до их установки, чтобы быть уверенным в том, что они не приведут к недопустимым побочным эффектам; если исправлений не выпущено, следует рассмотреть иные меры обеспечения информационной безопасности, такие как:
- отключение сервисов и возможностей, связанных с уязвимостью;
- настройка или добавление мер контроля доступа, например межсетевые экраны на границах сети (см. 13.1);
- усиление мониторинга для выявления реальных атак;
- повышение осведомленности об уязвимостях;
- h) следует вести журнал всех предпринятых действий;
- i) процесс управления техническими уязвимостями следует регулярно контролировать и оценивать для обеспечения его эффективности и результативности;
- j) в первую очередь следует обращать внимание на системы с высоким уровнем риска;
- k) эффективный процесс управления техническими уязвимостями должен быть согласован с действиями по управлению инцидентами, что позволит передавать данные об уязвимостях группе реагирования на инциденты и дополнит процесс техническими процедурами, которые должны быть выполнены в случае инцидента;
- l) необходимо определить процедуру для решения ситуации, когда уязвимость была выявлена, но подходящих мер еще не существует. В этой ситуации организация должна оценить риски, связанные с известной уязвимостью, и определить соответствующие действия по обнаружению и корректировке.
Дополнительная информация
Управление техническими уязвимостями может рассматриваться как подфункция процесса управления изменениями и, как следствие, может использовать преимущества процессов и процедур управления изменениями (см. 12.1.2 и 14.2.2).
Производители часто испытывают на себе значительное давление, заключающееся в требовании выпускать пакеты исправлений как можно скорее. Следовательно существует вероятность того, что исправление не решает проблему должным образом и имеет отрицательные побочные эффекты. Кроме того, в некоторых случаях после применения исправления его удаление может оказаться проблематичным.
Если адекватное тестирование исправлений невозможно, например из-за затрат или нехватки ресурсов, то следует рассмотреть возможность задержки его применения и оценить связанные с этим риски, основываясь на опыте, полученном от других пользователей. Может оказаться полезным использование ИСО/МЭК 27031 [14].
Связанные защитные меры
| Название | Дата | Влияние | ||
|---|---|---|---|---|
|
Community
11 / 87
|
Проведение тестирования на проникновение
Вручную
Техническая
Детективная
02.06.2021
|
02.06.2021 | 11 / 87 |
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.