Куда я попал?
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC)
Framework
18.1
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 6. п.п. 5
6.5. Кредитные организации в части тестирования операционной надежности технологических процессов должны принимать организационные и технические меры, направленные на проведение сценарного анализа (в части возможной реализации информационных угроз в отношении критичной архитектуры, а также возникновения сбоев объектов информационной инфраструктуры), с учетом требований подпункта 2.1.5 пункта 2.1 Положения Банка России N 716-П и проводить с использованием результатов сценарного анализа тестирование готовности кредитной организации противостоять реализации информационных угроз в отношении критичной архитектуры.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 11.4.1
11.4.1
Defined Approach Requirements:
A penetration testing methodology is defined, documented, and implemented by the entity, and includes:
Defined Approach Requirements:
A penetration testing methodology is defined, documented, and implemented by the entity, and includes:
- Industry-accepted penetration testing approaches.
- Coverage for the entire CDE perimeter and critical systems.
- Testing from both inside and outside the network.
- Testing to validate any segmentation and scopereduction controls.
- Application-layer penetration testing to identify, at a minimum, the vulnerabilities listed in Requirement 6.2.4.
- Network-layer penetration tests that encompass all components that support network functions as well as operating systems.
- Review and consideration of threats and vulnerabilities experienced in the last 12 months.
- Documented approach to assessing and addressing the risk posed by exploitable vulnerabilities and security weaknesses found during penetration testing.
- Retention of penetration testing results and remediation activities results for at least 12 months.
Customized Approach Objective:
A formal methodology is defined for thorough technical testing that attempts to exploit vulnerabilities and security weaknesses via simulated attack methods by a competent manual attacker.
Applicability Notes:
Testing from inside the network (or “internal penetration testing”) means testing from both inside the CDE and into the CDE from trusted and untrusted internal networks.
Testing from outside the network (or “external penetration testing”) means testing the exposed external perimeter of trusted networks, and critical systems connected to or accessible to public network infrastructures.
Defined Approach Testing Procedures:
A formal methodology is defined for thorough technical testing that attempts to exploit vulnerabilities and security weaknesses via simulated attack methods by a competent manual attacker.
Applicability Notes:
Testing from inside the network (or “internal penetration testing”) means testing from both inside the CDE and into the CDE from trusted and untrusted internal networks.
Testing from outside the network (or “external penetration testing”) means testing the exposed external perimeter of trusted networks, and critical systems connected to or accessible to public network infrastructures.
Defined Approach Testing Procedures:
- 11.4.1 Examine documentation and interview personnel to verify that the penetration-testing methodology defined, documented, and implemented by the entity includes all elements specified in this requirement.
Purpose:
Attackers spend a lot of time finding external and internal vulnerabilities to leverage to obtain access to cardholder data and then to exfiltrate that data. As such, entities need to test their networks thoroughly, just as an attacker would do. This testing allows the entity to identify and remediate weakness that might be leveraged to compromise the entity’s network and data, and then to take appropriate actions to protect the network and system components from such attacks.
Good Practice:
Penetration testing techniques will differ based on an organization’s needs and structure and should be suitable for the tested environment—for example, fuzzing, injection, and forgery tests might be appropriate. The type, depth, and complexity of the testing will depend on the specific environment and the needs of the organization.
Definitions:
Penetration tests simulate a real-world attack situation intending to identify how far an attacker could penetrate an environment, given differing amounts of information provided to the tester. This allows an entity to better understand its potential exposure and develop a strategy to defend against attacks. A penetration test differs from a vulnerability scan, as a penetration test is an active process that usually includes exploiting identified vulnerabilities.
Scanning for vulnerabilities alone is not a penetration test, nor is a penetration test adequate if the focus is solely on trying to exploit vulnerabilities found in a vulnerability scan. Conducting a vulnerability scan may be one of the first steps, but it is not the only step a penetration tester will perform to plan the testing strategy. Even if a vulnerability scan does not detect known vulnerabilities, the penetration tester will often gain enough knowledge about the system to identify possible security gaps.
Penetration testing is a highly manual process. While some automated tools may be used, the tester uses their knowledge of systems to gain access into an environment. Often the tester will chain several types of exploits together with the goal of breaking through layers of defenses. For example, if the tester finds a way to gain access to an application server, the tester will then use the compromised server as a point to stage a new attack based on the resources to which the server has access. In this way, a tester can simulate the techniques used by an attacker to identify areas of potential weakness in the environment. The testing of security monitoring and detection methods—for example, to confirm the effectiveness of logging and file integrity monitoring mechanisms, should also be considered.
Further Information:
Refer to the Information Supplement: Penetration Testing Guidance for additional guidance.
Industry-accepted penetration testing approaches include:
Attackers spend a lot of time finding external and internal vulnerabilities to leverage to obtain access to cardholder data and then to exfiltrate that data. As such, entities need to test their networks thoroughly, just as an attacker would do. This testing allows the entity to identify and remediate weakness that might be leveraged to compromise the entity’s network and data, and then to take appropriate actions to protect the network and system components from such attacks.
Good Practice:
Penetration testing techniques will differ based on an organization’s needs and structure and should be suitable for the tested environment—for example, fuzzing, injection, and forgery tests might be appropriate. The type, depth, and complexity of the testing will depend on the specific environment and the needs of the organization.
Definitions:
Penetration tests simulate a real-world attack situation intending to identify how far an attacker could penetrate an environment, given differing amounts of information provided to the tester. This allows an entity to better understand its potential exposure and develop a strategy to defend against attacks. A penetration test differs from a vulnerability scan, as a penetration test is an active process that usually includes exploiting identified vulnerabilities.
Scanning for vulnerabilities alone is not a penetration test, nor is a penetration test adequate if the focus is solely on trying to exploit vulnerabilities found in a vulnerability scan. Conducting a vulnerability scan may be one of the first steps, but it is not the only step a penetration tester will perform to plan the testing strategy. Even if a vulnerability scan does not detect known vulnerabilities, the penetration tester will often gain enough knowledge about the system to identify possible security gaps.
Penetration testing is a highly manual process. While some automated tools may be used, the tester uses their knowledge of systems to gain access into an environment. Often the tester will chain several types of exploits together with the goal of breaking through layers of defenses. For example, if the tester finds a way to gain access to an application server, the tester will then use the compromised server as a point to stage a new attack based on the resources to which the server has access. In this way, a tester can simulate the techniques used by an attacker to identify areas of potential weakness in the environment. The testing of security monitoring and detection methods—for example, to confirm the effectiveness of logging and file integrity monitoring mechanisms, should also be considered.
Further Information:
Refer to the Information Supplement: Penetration Testing Guidance for additional guidance.
Industry-accepted penetration testing approaches include:
- The Open Source Security Testing Methodology and Manual (OSSTMM)
- Open Web Application Security Project (OWASP) penetration testing programs.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.12.6.1
A.12.6.1 Процесс управления техническими уязвимостями
Мера обеспечения информационной безопасности: Должна быть своевременно получена информация о технических уязвимостях используемых информационных систем, оценена подверженность организации таким уязвимостям, и должны быть приняты соответствующие меры в отношении связанного с этим риска информационной безопасности
Мера обеспечения информационной безопасности: Должна быть своевременно получена информация о технических уязвимостях используемых информационных систем, оценена подверженность организации таким уязвимостям, и должны быть приняты соответствующие меры в отношении связанного с этим риска информационной безопасности
A.18.2.3
A.18.2.3 Анализ технического соответствия
Мера обеспечения информационной безопасности: Информационные системы должны регулярно проверяться на предмет соответствия стандартам и политикам информационной безопасности организации
Мера обеспечения информационной безопасности: Информационные системы должны регулярно проверяться на предмет соответствия стандартам и политикам информационной безопасности организации
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 20.1
CSC 20.1 Establish a Penetration Testing Program
Establish a program for penetration tests that includes a full scope of blended attacks, such as wireless, client-based, and web application attacks.
Establish a program for penetration tests that includes a full scope of blended attacks, such as wireless, client-based, and web application attacks.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 11.4.1
11.4.1
Определенные Требования к Подходу:
Методология тестирования на проникновение определяется, документируется и внедряется организацией и включает:
Определенные Требования к Подходу:
Методология тестирования на проникновение определяется, документируется и внедряется организацией и включает:
- Общепринятые в отрасли подходы к тестированию на проникновение.
- Охват всего периметра CDE и критически важных систем.
- Тестирование как внутри сети, так и за ее пределами.
- Тестирование для проверки любых элементов управления сегментацией и областью действия.
- Тестирование на проникновение на уровне приложений для выявления, как минимум, уязвимостей, перечисленных в требовании 6.2.4.
- Тесты на проникновение на сетевом уровне, которые охватывают все компоненты, поддерживающие сетевые функции, а также операционные системы.
- Обзор и рассмотрение угроз и уязвимостей, возникших за последние 12 месяцев.
- Документированный подход к оценке и устранению рисков, связанных с уязвимостями, которые могут быть использованы, и слабостями безопасности, обнаруженными в ходе тестирования на проникновение.
- Сохранение результатов тестирования на проникновение и результатов мероприятий по исправлению в течение как минимум 12 месяцев.
Цель Индивидуального подхода:
Официальная методология определена для тщательного технического тестирования, которое пытается использовать уязвимости и слабые места в системе безопасности с помощью имитируемых методов атаки компетентным злоумышленником вручную.
Примечания по применению:
Тестирование внутри сети (или “внутреннее тестирование на проникновение”) означает тестирование как внутри CDE, так и в CDE из доверенных и ненадежных внутренних сетей.
Тестирование извне сети (или “внешнее тестирование на проникновение”) означает тестирование открытого внешнего периметра доверенных сетей и критических систем, подключенных к общедоступным сетевым инфраструктурам или доступных для них.
Определенные Процедуры Тестирования Подхода:
Официальная методология определена для тщательного технического тестирования, которое пытается использовать уязвимости и слабые места в системе безопасности с помощью имитируемых методов атаки компетентным злоумышленником вручную.
Примечания по применению:
Тестирование внутри сети (или “внутреннее тестирование на проникновение”) означает тестирование как внутри CDE, так и в CDE из доверенных и ненадежных внутренних сетей.
Тестирование извне сети (или “внешнее тестирование на проникновение”) означает тестирование открытого внешнего периметра доверенных сетей и критических систем, подключенных к общедоступным сетевым инфраструктурам или доступных для них.
Определенные Процедуры Тестирования Подхода:
- 11.4.1 Изучите документацию и опросите персонал, чтобы убедиться, что методология тестирования на проникновение, определенная, документированная и внедренная организацией, включает все элементы, указанные в этом требовании.
Цель:
Злоумышленники тратят много времени на поиск внешних и внутренних уязвимостей, которые можно использовать для получения доступа к данным о держателях карт, а затем для извлечения этих данных. Таким образом, субъектам необходимо тщательно протестировать свои сети, точно так же, как это сделал бы злоумышленник. Это тестирование позволяет организации выявить и устранить слабые места, которые могут быть использованы для компрометации сети и данных организации, а затем предпринять соответствующие действия для защиты сетевых и системных компонентов от таких атак.
Надлежащая практика:
Методы тестирования на проникновение будут отличаться в зависимости от потребностей и структуры организации и должны подходить для тестируемой среды — например, могут быть уместны тесты на размытие, внедрение и подделку. Тип, глубина и сложность тестирования будут зависеть от конкретной среды и потребностей организации.
Определения:
Тесты на проникновение имитируют реальную ситуацию атаки с целью определения того, как далеко злоумышленник может проникнуть в среду, учитывая различные объемы информации, предоставляемой тестировщику. Это позволяет организации лучше понять свою потенциальную уязвимость и разработать стратегию защиты от атак. Тест на проникновение отличается от сканирования уязвимостей, поскольку тест на проникновение - это активный процесс, который обычно включает в себя использование выявленных уязвимостей.
Сканирование на наличие уязвимостей само по себе не является тестом на проникновение, и тест на проникновение не является адекватным, если основное внимание уделяется исключительно попытке использовать уязвимости, обнаруженные при сканировании уязвимостей. Проведение проверки на уязвимость может быть одним из первых шагов, но это не единственный шаг, который тестировщик проникновения выполнит для планирования стратегии тестирования. Даже если проверка на уязвимость не обнаруживает известных уязвимостей, тестировщик проникновения часто получает достаточно знаний о системе, чтобы выявить возможные пробелы в безопасности.
Тестирование на проникновение - это в высшей степени ручной процесс. Хотя могут использоваться некоторые автоматизированные инструменты, тестировщик использует свои знания о системах для получения доступа к среде. Часто тестировщик связывает несколько типов эксплойтов вместе с целью прорыва через слои защиты. Например, если тестировщик найдет способ получить доступ к серверу приложений, он затем будет использовать скомпрометированный сервер в качестве точки для проведения новой атаки на основе ресурсов, к которым сервер имеет доступ. Таким образом, тестировщик может имитировать методы, используемые злоумышленником для выявления областей потенциальной уязвимости в среде. Следует также рассмотреть возможность тестирования методов мониторинга и обнаружения безопасности — например, для подтверждения эффективности механизмов ведения журнала и контроля целостности файлов.
Дополнительная информация:
Дополнительные указания см. в Информационном дополнении: Руководство по тестированию на проникновение.
Принятые в отрасли подходы к тестированию на проникновение включают:
Злоумышленники тратят много времени на поиск внешних и внутренних уязвимостей, которые можно использовать для получения доступа к данным о держателях карт, а затем для извлечения этих данных. Таким образом, субъектам необходимо тщательно протестировать свои сети, точно так же, как это сделал бы злоумышленник. Это тестирование позволяет организации выявить и устранить слабые места, которые могут быть использованы для компрометации сети и данных организации, а затем предпринять соответствующие действия для защиты сетевых и системных компонентов от таких атак.
Надлежащая практика:
Методы тестирования на проникновение будут отличаться в зависимости от потребностей и структуры организации и должны подходить для тестируемой среды — например, могут быть уместны тесты на размытие, внедрение и подделку. Тип, глубина и сложность тестирования будут зависеть от конкретной среды и потребностей организации.
Определения:
Тесты на проникновение имитируют реальную ситуацию атаки с целью определения того, как далеко злоумышленник может проникнуть в среду, учитывая различные объемы информации, предоставляемой тестировщику. Это позволяет организации лучше понять свою потенциальную уязвимость и разработать стратегию защиты от атак. Тест на проникновение отличается от сканирования уязвимостей, поскольку тест на проникновение - это активный процесс, который обычно включает в себя использование выявленных уязвимостей.
Сканирование на наличие уязвимостей само по себе не является тестом на проникновение, и тест на проникновение не является адекватным, если основное внимание уделяется исключительно попытке использовать уязвимости, обнаруженные при сканировании уязвимостей. Проведение проверки на уязвимость может быть одним из первых шагов, но это не единственный шаг, который тестировщик проникновения выполнит для планирования стратегии тестирования. Даже если проверка на уязвимость не обнаруживает известных уязвимостей, тестировщик проникновения часто получает достаточно знаний о системе, чтобы выявить возможные пробелы в безопасности.
Тестирование на проникновение - это в высшей степени ручной процесс. Хотя могут использоваться некоторые автоматизированные инструменты, тестировщик использует свои знания о системах для получения доступа к среде. Часто тестировщик связывает несколько типов эксплойтов вместе с целью прорыва через слои защиты. Например, если тестировщик найдет способ получить доступ к серверу приложений, он затем будет использовать скомпрометированный сервер в качестве точки для проведения новой атаки на основе ресурсов, к которым сервер имеет доступ. Таким образом, тестировщик может имитировать методы, используемые злоумышленником для выявления областей потенциальной уязвимости в среде. Следует также рассмотреть возможность тестирования методов мониторинга и обнаружения безопасности — например, для подтверждения эффективности механизмов ведения журнала и контроля целостности файлов.
Дополнительная информация:
Дополнительные указания см. в Информационном дополнении: Руководство по тестированию на проникновение.
Принятые в отрасли подходы к тестированию на проникновение включают:
- Методология и руководство по тестированию безопасности с открытым исходным кодом (OSSTMM)
- Программы тестирования на проникновение Open Web Application Security Project (OWASP).
Методика экспресс-оценки уровня кибербезопасности организации РезБез:
10.1.2.
Проводится регулярное тестирование на проникновение
Положение Банка России № 757-П от 20.04.2021 "Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций":
1.8.
1.8. Некредитные финансовые организации, реализующие усиленный и стандартный уровни защиты информации, должны обеспечить использование для осуществления финансовых операций прикладного программного обеспечения автоматизированных систем и приложений, распространяемых некредитными финансовыми организациями своим клиентам для совершения действий в целях осуществления финансовых операций, а также программного обеспечения, обрабатывающего защищаемую информацию при приеме электронных сообщений к исполнению в автоматизированных системах и приложениях с использованием информационно-телекоммуникационной сети "Интернет" (далее - сеть "Интернет"), прошедших сертификацию в системе сертификации Федеральной службы по техническому и экспортному контролю (далее - сертификация) или оценку соответствия по требованиям к оценочному уровню доверия (далее - ОУД) не ниже, чем ОУД 4, в соответствии с требованиями национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 15408-3-2013 "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности", утвержденного приказом Федерального агентства по техническому регулированию и метрологии от 8 ноября 2013 года N 1340-ст "Об утверждении национального стандарта" (далее - ГОСТ Р ИСО/МЭК 15408-3-2013) (далее - оценка соответствия прикладного программного обеспечения автоматизированных систем и приложений).
Некредитные финансовые организации, не реализующие усиленный и стандартный уровни защиты информации, должны самостоятельно определять необходимость сертификации или оценки соответствия прикладного программного обеспечения автоматизированных систем и приложений.
В отношении программного обеспечения и приложений, не указанных в абзаце первом настоящего пункта, некредитные финансовые организации должны самостоятельно определять необходимость сертификации или оценки соответствия прикладного программного обеспечения автоматизированных систем и приложений.
По решению некредитной финансовой организации оценка соответствия прикладного программного обеспечения автоматизированных систем и приложений проводится самостоятельно или с привлечением проверяющей организации.
Некредитные финансовые организации, реализующие усиленный уровень защиты информации, в случае сертификации прикладного программного обеспечения автоматизированных систем и приложений должны обеспечить их сертификацию не ниже 4 уровня доверия в соответствии с Требованиями по безопасности информации, устанавливающими уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий, утвержденными приказом Федеральной службы по техническому и экспортному контролю от 2 июня 2020 года N 76 "Об утверждении Требований по безопасности информации, устанавливающих уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий", зарегистрированным Министерством юстиции Российской Федерации 11 сентября 2020 года N 59772 (далее - приказ ФСТЭК России N 76).
Некредитные финансовые организации, реализующие стандартный уровень защиты информации, в случае сертификации прикладного программного обеспечения автоматизированных систем и приложений должны обеспечить их сертификацию не ниже 5 уровня доверия в соответствии с Требованиями по безопасности информации, устанавливающими уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий, утвержденными приказом ФСТЭК России N 76.
Некредитные финансовые организации, не реализующие усиленный и стандартный уровни защиты информации, должны самостоятельно определять необходимость сертификации или оценки соответствия прикладного программного обеспечения автоматизированных систем и приложений.
В отношении программного обеспечения и приложений, не указанных в абзаце первом настоящего пункта, некредитные финансовые организации должны самостоятельно определять необходимость сертификации или оценки соответствия прикладного программного обеспечения автоматизированных систем и приложений.
По решению некредитной финансовой организации оценка соответствия прикладного программного обеспечения автоматизированных систем и приложений проводится самостоятельно или с привлечением проверяющей организации.
Некредитные финансовые организации, реализующие усиленный уровень защиты информации, в случае сертификации прикладного программного обеспечения автоматизированных систем и приложений должны обеспечить их сертификацию не ниже 4 уровня доверия в соответствии с Требованиями по безопасности информации, устанавливающими уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий, утвержденными приказом Федеральной службы по техническому и экспортному контролю от 2 июня 2020 года N 76 "Об утверждении Требований по безопасности информации, устанавливающих уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий", зарегистрированным Министерством юстиции Российской Федерации 11 сентября 2020 года N 59772 (далее - приказ ФСТЭК России N 76).
Некредитные финансовые организации, реализующие стандартный уровень защиты информации, в случае сертификации прикладного программного обеспечения автоматизированных систем и приложений должны обеспечить их сертификацию не ниже 5 уровня доверия в соответствии с Требованиями по безопасности информации, устанавливающими уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий, утвержденными приказом ФСТЭК России N 76.
ГОСТ Р № ИСО/МЭК 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].
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.