Куда я попал?
Framework № PCI DSS 4.0 от 01.03.2022
Payment Card Industry Data Security Standard (RU)
Requirement 11.3.1
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 9. Требования к защите информации на этапах жизненного цикла автоматизированных систем и приложений":
ЖЦ.20
ЖЦ.20 Реализация проведения ежегодного контроля защищенности АС, включающего: - тестирование на проникновение; - анализ уязвимостей системы защиты информации АС и информационной инфраструктуры промышленной среды
3-Н 2-О 1-О
3-Н 2-О 1-О
ЖЦ.21
ЖЦ.21 Обеспечение оперативного устранения выявленных уязвимостей защиты информации АС, включая уязвимости прикладного ПО
3-О 2-О 1-О
3-О 2-О 1-О
ЖЦ.14
ЖЦ.14 Реализация контроля защищенности АС, включающего (по решению финансовой организации при модернизации АС проводится контроль защищенности только элементов информационной инфраструктуры, подвергнутых модернизации): - тестирование на проникновение; - анализ уязвимостей системы защиты информации АС и информационной инфраструктуры промышленной среды
3-Н 2-О 1-О
3-Н 2-О 1-О
Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 7 п. 3 п.п. 9
7.3.9. На стадии эксплуатации АБС должны быть определены, выполняться и регистрироваться процедуры:
- контроля работоспособности (функционирования, эффективности) реализованных в АБС защитных мер, в том числе контроль реализации организационных защитных мер, контроль состава и параметров настройки применяемых технических защитных мер;
- контроля отсутствия уязвимостей в оборудовании и программном обеспечении АБС;
- контроля внесения изменений в параметры настройки АБС и применяемых технических защитных мер;
- контроля необходимого обновления программного обеспечения АБС, включая программное обеспечение технических защитных мер.
CIS Critical Security Controls v8 (The 18 CIS CSC):
7.7
7.7 Remediate Detected Vulnerabilities
Remediate detected vulnerabilities in software through processes and tooling on a monthly, or more frequent, basis, based on the remediation process.
Remediate detected vulnerabilities in software through processes and tooling on a monthly, or more frequent, basis, based on the remediation process.
16.6
16.6 Establish and Maintain a Severity Rating System and Process for Application Vulnerabilities
Establish and maintain a severity rating system and process for application vulnerabilities that facilitates prioritizing the order in which discovered vulnerabilities are fixed. This process includes setting a minimum level of security acceptability for releasing code or applications. Severity ratings bring a systematic way of triaging vulnerabilities that improves risk management and helps ensure the most severe bugs are fixed first. Review and update the system and process annually.
Establish and maintain a severity rating system and process for application vulnerabilities that facilitates prioritizing the order in which discovered vulnerabilities are fixed. This process includes setting a minimum level of security acceptability for releasing code or applications. Severity ratings bring a systematic way of triaging vulnerabilities that improves risk management and helps ensure the most severe bugs are fixed first. Review and update the system and process annually.
7.1
7.1 Establish and Maintain a Vulnerability Management Process
Establish and maintain a documented vulnerability management process for enterprise assets. Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard.
Establish and maintain a documented vulnerability management process for enterprise assets. Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard.
7.6
7.6 Perform Automated Vulnerability Scans of Externally-Exposed Enterprise Assets
Perform automated vulnerability scans of externally-exposed enterprise assets using a SCAP-compliant vulnerability scanning tool. Perform scans on a monthly, or more frequent, basis.
Perform automated vulnerability scans of externally-exposed enterprise assets using a SCAP-compliant vulnerability scanning tool. Perform scans on a monthly, or more frequent, basis.
16.2
16.2 Establish and Maintain a Process to Accept and Address Software Vulnerabilities
Establish and maintain a process to accept and address reports of software vulnerabilities, including providing a means for external entities to report. The process is to include such items as: a vulnerability handling policy that identifies reporting process, responsible party for handling vulnerability reports, and a process for intake, assignment, remediation, and remediation testing. As part of the process, use a vulnerability tracking system that includes severity ratings, and metrics for measuring timing for identification, analysis, and remediation of vulnerabilities. Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard. Third-party application developers need to consider this an externally-facing policy that helps to set expectations for outside stakeholders.
Establish and maintain a process to accept and address reports of software vulnerabilities, including providing a means for external entities to report. The process is to include such items as: a vulnerability handling policy that identifies reporting process, responsible party for handling vulnerability reports, and a process for intake, assignment, remediation, and remediation testing. As part of the process, use a vulnerability tracking system that includes severity ratings, and metrics for measuring timing for identification, analysis, and remediation of vulnerabilities. Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard. Third-party application developers need to consider this an externally-facing policy that helps to set expectations for outside stakeholders.
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
ЦЗИ.27
ЦЗИ.27 Регистрация фактов выявления уязвимостей защиты информации
3-Н 2-Т 1-Т
3-Н 2-Т 1-Т
ЦЗИ.8
ЦЗИ.8 Контроль отсутствия и обеспечение оперативного устранения известных (описанных) уязвимостей, указанных в пунктах ЦЗИ.1-ЦЗИ.6 настоящей таблицы, путем сканирования и анализа состава, версий и параметров настроек прикладного ПО, ПО АС и системного ПО, реализующего функции обеспечения защиты информации и (или) влияющего на обеспечение защиты информации (далее в настоящем разделе - системное ПО, в том числе ПО операционных систем, ПО СУБД, ПО серверов приложений, ПО систем виртуализации), установленного на серверном и сетевом оборудовании
3-Н 2-Т 1-Т
3-Н 2-Т 1-Т
ЦЗИ.10
ЦЗИ.10 Контроль отсутствия и обеспечение оперативного устранения известных (описанных) уязвимостей, предусмотренных мерами ЦЗИ.1-ЦЗИ.6 настоящей таблицы, путем сканирования и анализа состава, версий и параметров настроек средств и систем защиты информации
3-Н 2-Т 1-Т
3-Н 2-Т 1-Т
ЦЗИ.9
ЦЗИ.9 Контроль отсутствия и обеспечение оперативного устранения известных (описанных) уязвимостей, предусмотренных мерами ЦЗИ.1-ЦЗИ.6 настоящей таблицы, путем сканирования и анализа состава, версий и параметров настроек прикладного ПО, ПО АС и (или) системного ПО, установленного на АРМ пользователей и эксплуатационного персонала
3-Н 2-Т 1-Т
3-Н 2-Т 1-Т
ЦЗИ.15
ЦЗИ.15 Контроль отсутствия и обеспечение оперативного устранения известных (описанных) уязвимостей защиты информации после выполнения обновлений ПО, предусмотренного мерой ЦЗИ.12 настоящей таблицы
3-О 2-Т 1-Т
3-О 2-Т 1-Т
ЦЗИ.6
ЦЗИ.6 Контроль отсутствия и обеспечение оперативного устранения известных (описанных) уязвимостей защиты информации, использование которых может позволить осуществить несанкционированный логический доступ к ресурсам доступа, размещенным во внутренних вычислительных сетях финансовой организации
3-Н 2-Т 1-Т
3-Н 2-Т 1-Т
ЦЗИ.4
ЦЗИ.4 Контроль отсутствия и обеспечение оперативного устранения известных (описанных) уязвимостей защиты информации, использование которых может позволить осуществить несанкционированный логический доступ к ресурсам доступа, размещенным в вычислительных сетях финансовой организации, подключенных к сети Интернет
3-О 2-Т 1-Т
3-О 2-Т 1-Т
ЦЗИ.1
ЦЗИ.1 Контроль отсутствия и обеспечение оперативного устранения известных (описанных) уязвимостей защиты информации, использование которых может позволить осуществить несанкционированное (неконтролируемое) информационное взаимодействие между сегментами контуров безопасности и иными внутренними сетями финансовой организации
3-Н 2-Т 1-Т
3-Н 2-Т 1-Т
ЦЗИ.3
ЦЗИ.3 Контроль отсутствия и обеспечение оперативного устранения известных (описанных) уязвимостей защиты информации, использование которых может позволить осуществить несанкционированное (неконтролируемое) информационное взаимодействие между сегментами, предназначенными для размещения общедоступных объектов доступа (в том числе банкоматов, платежных терминалов), и сетью Интернет
3-О 2-Т 1-Т
3-О 2-Т 1-Т
ЦЗИ.2
ЦЗИ.2 Контроль отсутствия и обеспечение оперативного устранения известных (описанных) уязвимостей защиты информации, использование которых может позволить осуществить несанкционированное (неконтролируемое) информационное взаимодействие между внутренними вычислительными сетями финансовой организации и сетью Интернет
3-О 2-Т 1-Т
3-О 2-Т 1-Т
ЦЗИ.5
ЦЗИ.5 Контроль отсутствия и обеспечение оперативного устранения известных (описанных) уязвимостей защиты информации, использование которых может позволить осуществить несанкционированный удаленный доступ
3-О 2-Т 1-Т
3-О 2-Т 1-Т
ЦЗИ.7
ЦЗИ.7 Контроль отсутствия и обеспечение оперативного устранения известных (описанных) уязвимостей, предусмотренных мерами ЦЗИ.1-ЦЗИ.6 настоящей таблицы, путем сканирования и анализа параметров настроек серверного и сетевого оборудования
3-Н 2-Т 1-Т
3-Н 2-Т 1-Т
NIST Cybersecurity Framework (RU):
RS.MI-3
RS.MI-3: Вновь выявленные уязвимости смягчаются или документируются как принятые риски
DE.CM-8
DE.CM-8: Выполняется сканирование уязвимостей
RS.AN-5
RS.AN-5: Установлены процессы для получения, анализа и реагирования на уязвимости организации обнаруженные с помощью анализа внутренних и внешних источников (например, внутреннее тестирование, бюллетени по безопасности или исследователи безопасности).
ID.RA-1
ID.RA-1: Идентифицированы и задокументированы уязвимости активов
PR.IP-12
PR.IP-12: Разработан и внедрен план управления уязвимостями
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
АНЗ.1
АНЗ.1 Выявление, анализ уязвимостей информационной системы и оперативное устранение вновь выявленных уязвимостей
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
7.7
7.7 Реализовано устранение обнаруженных уязвимостей
Решение обнаруженных проблем раз в месяц или чаще.
Решение обнаруженных проблем раз в месяц или чаще.
7.1
7.1 Реализован и поддерживается процесс управления уязвимостями
Есть отдельный документ по управлению уязвимостями, который пересматривается ежегодно.
Есть отдельный документ по управлению уязвимостями, который пересматривается ежегодно.
16.6
16.6 Реализован и поддерживается процесс классификации уязвимостей программного обеспечения по степени критичности
Наиболее критичные замечания исправляются в первую очередь.
Определен минимально допустимый уровень уязвимостей, без соблюдения которого релиз не выходит.
Наиболее критичные замечания исправляются в первую очередь.
Определен минимально допустимый уровень уязвимостей, без соблюдения которого релиз не выходит.
7.6
7.6 Выполняется автоматизированное сканирование на уязвимости внутренних устройств и программного обеспечения предприятия, доступных извне
Используется совместимый со SCAP (Протокол автоматизации управления данными безопасности) сканер.
Сканирование проводится раз в месяц.
Используется совместимый со SCAP (Протокол автоматизации управления данными безопасности) сканер.
Сканирование проводится раз в месяц.
16.2
16.2 Реализован и поддерживается процесс обнаружения и устранения уязвимостей в программном обеспечении
Определен порядок фиксации замечаний по безопасности и последующего исправления багов с указанием ответственных.
Используется система обнаружения уязвимостей с рейтингом критичности и отслеживанием метрик: сколько времени требуется на обнаружение, анализ и устранение уязвимостей.
Определен порядок фиксации замечаний по безопасности и последующего исправления багов с указанием ответственных.
Используется система обнаружения уязвимостей с рейтингом критичности и отслеживанием метрик: сколько времени требуется на обнаружение, анализ и устранение уязвимостей.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 11.3.1
11.3.1
Defined Approach Requirements:
Internal vulnerability scans are performed as follows:
Defined Approach Requirements:
Internal vulnerability scans are performed as follows:
- At least once every three months.
- High-risk and critical vulnerabilities (per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved.
- Rescans are performed that confirm all highrisk and critical vulnerabilities (as noted above) have been resolved.
- Scan tool is kept up to date with latest vulnerability information.
- Scans are performed by qualified personnel and organizational independence of the tester exists.
Customized Approach Objective:
The security posture of all system components is verified periodically using automated tools designed to detect vulnerabilities operating inside the network. Detected vulnerabilities are assessed and rectified based on a formal risk assessment framework
Applicability Notes:
It is not required to use a QSA or ASV to conduct internal vulnerability scans.
Internal vulnerability scans can be performed by qualified, internal staff that are reasonably independent of the system component(s) being scanned (for example, a network administrator should not be responsible for scanning the network), or an entity may choose to have internal vulnerability scans performed by a firm specializing in vulnerability scanning.
Defined Approach Testing Procedures:
The security posture of all system components is verified periodically using automated tools designed to detect vulnerabilities operating inside the network. Detected vulnerabilities are assessed and rectified based on a formal risk assessment framework
Applicability Notes:
It is not required to use a QSA or ASV to conduct internal vulnerability scans.
Internal vulnerability scans can be performed by qualified, internal staff that are reasonably independent of the system component(s) being scanned (for example, a network administrator should not be responsible for scanning the network), or an entity may choose to have internal vulnerability scans performed by a firm specializing in vulnerability scanning.
Defined Approach Testing Procedures:
- 11.3.1.a Examine internal scan report results from the last 12 months to verify that internal scans occurred at least once every three months in the most recent 12-month period.
- 11.3.1.b Examine internal scan report results from each scan and rescan run in the last 12 months to verify that all high-risk and critical vulnerabilities (identified in PCI DSS Requirement 6.3.1) are resolved.
- 11.3.1.c Examine scan tool configurations and interview personnel to verify that the scan tool is kept up to date with the latest vulnerability information.
- 11.3.1.d Interview responsible personnel to verify that the scan was performed by a qualified internal resource(s) or qualified external third party and that organizational independence of the tester exists.
Purpose:
Identifying and addressing vulnerabilities promptly reduces the likelihood of a vulnerability being exploited and the potential compromise of a system component or cardholder data. Vulnerability scans conducted at least every three months provide this detection and identification.
Good Practice:
Vulnerabilities posing the greatest risk to the environment (for example, ranked high or critical per Requirement 6.3.1) should be resolved with the highest priority.
Multiple scan reports can be combined for the quarterly scan process to show that all systems were scanned and all applicable vulnerabilities were resolved as part of the three-month vulnerability scan cycle. However, additional, documentation may be required to verify nonremediated vulnerabilities are in the process of being resolved.
While scans are required at least once every three months, more frequent scans are recommended depending on the network complexity, frequency of change, and types of devices, software, and operating systems used.
Definitions:
A vulnerability scan is a combination of automated tools, techniques, and/or methods run against external and internal devices and servers, designed to expose potential vulnerabilities in applications, operating systems, and network devices that could be found and exploited by malicious individuals.
Identifying and addressing vulnerabilities promptly reduces the likelihood of a vulnerability being exploited and the potential compromise of a system component or cardholder data. Vulnerability scans conducted at least every three months provide this detection and identification.
Good Practice:
Vulnerabilities posing the greatest risk to the environment (for example, ranked high or critical per Requirement 6.3.1) should be resolved with the highest priority.
Multiple scan reports can be combined for the quarterly scan process to show that all systems were scanned and all applicable vulnerabilities were resolved as part of the three-month vulnerability scan cycle. However, additional, documentation may be required to verify nonremediated vulnerabilities are in the process of being resolved.
While scans are required at least once every three months, more frequent scans are recommended depending on the network complexity, frequency of change, and types of devices, software, and operating systems used.
Definitions:
A vulnerability scan is a combination of automated tools, techniques, and/or methods run against external and internal devices and servers, designed to expose potential vulnerabilities in applications, operating systems, and network devices that could be found and exploited by malicious individuals.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.12.6.1
A.12.6.1 Процесс управления техническими уязвимостями
Мера обеспечения информационной безопасности: Должна быть своевременно получена информация о технических уязвимостях используемых информационных систем, оценена подверженность организации таким уязвимостям, и должны быть приняты соответствующие меры в отношении связанного с этим риска информационной безопасности
Мера обеспечения информационной безопасности: Должна быть своевременно получена информация о технических уязвимостях используемых информационных систем, оценена подверженность организации таким уязвимостям, и должны быть приняты соответствующие меры в отношении связанного с этим риска информационной безопасности
Постановление Правительства РФ № 584 от 13.06.2012 "Положение о защите информации в платежной системе":
п. 4 п.п. в)
в) осуществление мероприятий, имеющих целью определение угроз безопасности информации и анализ уязвимости информационных систем;
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 18.8
CSC 18.8 Establish a Process to Accept and Address Reports of Software Vulnerabilities
Establish a process to accept and address reports of software vulnerabilities, including providing a means for external entities to contact your security group.
Establish a process to accept and address reports of software vulnerabilities, including providing a means for external entities to contact your security group.
CSC 3.2
CSC 3.2 Perform Authenticated Vulnerability Scanning
Perform authenticated vulnerability scanning with agents running locally on each system or with remote scanners that are configured with elevated rights on the system being tested.
Perform authenticated vulnerability scanning with agents running locally on each system or with remote scanners that are configured with elevated rights on the system being tested.
CSC 3.6
CSC 3.6 Compare Back-to-Back Vulnerability Scans
Regularly compare the results from consecutive vulnerability scans to verify that vulnerabilities have been remediated in a timely manner.
Regularly compare the results from consecutive vulnerability scans to verify that vulnerabilities have been remediated in a timely manner.
CSC 3.1
CSC 3.1 Run Automated Vulnerability Scanning Tools
Utilize an up-to-date Security Content Automation Protocol (SCAP) compliant vulnerability scanning tool to automatically scan all systems on the network on a weekly or more frequent basis to identify all potential vulnerabilities on the organization's systems.
Utilize an up-to-date Security Content Automation Protocol (SCAP) compliant vulnerability scanning tool to automatically scan all systems on the network on a weekly or more frequent basis to identify all potential vulnerabilities on the organization's systems.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
АНЗ.1
АНЗ.1 Выявление, анализ уязвимостей информационной системы и оперативное устранение вновь выявленных уязвимостей
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.8
А.8.8 Управление техническими уязвимостями
Должна своевременно получаться информация о технических уязвимостях используемых информационных систем, также должно оцениваться воздействие таких уязвимостей на организацию, и должны предприниматься соответствующие меры.
Должна своевременно получаться информация о технических уязвимостях используемых информационных систем, также должно оцениваться воздействие таких уязвимостей на организацию, и должны предприниматься соответствующие меры.
Методика экспресс-оценки уровня кибербезопасности организации РезБез:
5.3.1.
Установлены и соблюдаются сроки по устранению уязвимостей
SWIFT Customer Security Controls Framework v2022:
2 - 2.7 Vulnerability Scanning
2.7 Vulnerability Scanning
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
АУД.2
АУД.2 Анализ уязвимостей и их устранение
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
АУД.2
АУД.2 Анализ уязвимостей и их устранение
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
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].
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.8.8
А.8.8 Management of technical vulnerabilities
Information about technical vulnerabilities of information systems in use shall be obtained, the organization’s exposure to such vulnerabilities shall be evaluated and appropriate measures shall be taken.
Information about technical vulnerabilities of information systems in use shall be obtained, the organization’s exposure to such vulnerabilities shall be evaluated and appropriate measures shall be taken.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.