Куда я попал?
Методика экспресс-оценки уровня кибербезопасности организации РезБез
Framework
5.3.1.
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
Установлены и соблюдаются сроки по устранению уязвимостейОбязательно для уровня кибербезопасности Продвинутый Высокий
Похожие требования
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
7.7
7.7 Реализовано устранение обнаруженных уязвимостей
Решение обнаруженных проблем раз в месяц или чаще.
Решение обнаруженных проблем раз в месяц или чаще.
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.
Requirement 6.4.1
6.4.1
Defined Approach Requirements:
For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks as follows:
Defined Approach Requirements:
For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks as follows:
- Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods as follows:
- At least once every 12 months and after significant changes.
- By an entity that specializes in application security.
- Including, at a minimum, all common software attacks in Requirement 6.2.4.
- All vulnerabilities are ranked in accordance with requirement 6.3.1.
- All vulnerabilities are corrected.
- The application is re-evaluated after the corrections
OR
- Installing an automated technical solution(s) that continually detects and prevents web-based attacks as follows:
- Installed in front of public-facing web applications to detect and prevent webbased attacks.
- Actively running and up to date as applicable.
- Generating audit logs.
- Configured to either block web-based attacks or generate an alert that is immediately investigated.
Customized Approach Objective:
Public-facing web applications are protected against malicious attacks.
Applicability Notes:
This assessment is not the same as the vulnerability scans performed for Requirement 11.3.1 and 11.3.2.
This requirement will be superseded by Requirement 6.4.2 after 31 March 2025 when Requirement 6.4.2 becomes effective.
Defined Approach Testing Procedures:
Public-facing web applications are protected against malicious attacks.
Applicability Notes:
This assessment is not the same as the vulnerability scans performed for Requirement 11.3.1 and 11.3.2.
This requirement will be superseded by Requirement 6.4.2 after 31 March 2025 when Requirement 6.4.2 becomes effective.
Defined Approach Testing Procedures:
- 6.4.1 For public-facing web applications, ensure that either one of the required methods is in place as follows:
- If manual or automated vulnerability security assessment tools or methods are in use, examine documented processes, interview personnel, and examine records of application security assessments to verify that public-facing web applications are reviewed in accordance with all elements of this requirement specific to the tool/method. OR
- If an automated technical solution(s) is installed that continually detects and prevents webbased attacks, examine the system configuration settings and audit logs, and interview responsible personnel to verify that the automated technical solution(s) is installed in accordance with all elements of this requirement specific to the solution(s).
Purpose:
Public-facing web applications are those that are available to the public (not only for internal use). These applications are primary targets for attackers, and poorly coded web applications provide an easy path for attackers to gain access to sensitive data and systems.
Good Practice:
Manual or automated vulnerability security assessment tools or methods review and/or test the application for vulnerabilities.
Common assessment tools include specialized web scanners that perform automatic analysis of web application protection.
When using automated technical solutions, it is important to include processes that facilitate timely responses to alerts generated by the solutions so that any detected attacks can be mitigated.
Examples:
A web application firewall (WAF) installed in front of public-facing web applications to check all traffic is an example of an automated technical solution that detects and prevents web-based attacks (for example, the attacks included in Requirement 6.2.4). WAFs filter and block nonessential traffic at the application layer. A properly configured WAF helps to prevent application-layer attacks on applications that are improperly coded or configured.
Another example of an automated technical solution is Runtime Application Self-Protection (RASP) technologies. When implemented correctly, RASP solutions can detect and block anomalous behavior by the software during execution. While WAFs typically monitor the application perimeter, RASP solutions monitor and block behavior within the application.
Public-facing web applications are those that are available to the public (not only for internal use). These applications are primary targets for attackers, and poorly coded web applications provide an easy path for attackers to gain access to sensitive data and systems.
Good Practice:
Manual or automated vulnerability security assessment tools or methods review and/or test the application for vulnerabilities.
Common assessment tools include specialized web scanners that perform automatic analysis of web application protection.
When using automated technical solutions, it is important to include processes that facilitate timely responses to alerts generated by the solutions so that any detected attacks can be mitigated.
Examples:
A web application firewall (WAF) installed in front of public-facing web applications to check all traffic is an example of an automated technical solution that detects and prevents web-based attacks (for example, the attacks included in Requirement 6.2.4). WAFs filter and block nonessential traffic at the application layer. A properly configured WAF helps to prevent application-layer attacks on applications that are improperly coded or configured.
Another example of an automated technical solution is Runtime Application Self-Protection (RASP) technologies. When implemented correctly, RASP solutions can detect and block anomalous behavior by the software during execution. While WAFs typically monitor the application perimeter, RASP solutions monitor and block behavior within the application.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 11.3.1
11.3.1
Определенные Требования к Подходу:
Проверка внутренних уязвимостей выполняется следующим образом:
Определенные Требования к Подходу:
Проверка внутренних уязвимостей выполняется следующим образом:
- По крайней мере, раз в три месяца.
- Устраняются уязвимости высокого риска и критические уязвимости (в соответствии с ранжированием рисков уязвимости организации, определенным в требовании 6.3.1).
- Выполняется повторное сканирование, которое подтверждает, что все уязвимости с высоким уровнем риска и критические уязвимости (как отмечено выше) были устранены.
- Средство сканирования постоянно обновляется с последней информацией об уязвимостях.
- Сканирование выполняется квалифицированным персоналом, и существует организационная независимость тестировщика.
Цель Индивидуального подхода:
Состояние безопасности всех компонентов системы периодически проверяется с помощью автоматизированных инструментов, предназначенных для обнаружения уязвимостей, действующих внутри сети. Обнаруженные уязвимости оцениваются и устраняются на основе формальной системы оценки рисков
Примечания по применению:
Для проведения внутреннего сканирования уязвимостей не требуется использовать QSA или ASV.
Внутреннее сканирование уязвимостей может выполняться квалифицированным внутренним персоналом, который разумно независим от проверяемого системного компонента (компонентов) (например, сетевой администратор не должен нести ответственность за сканирование сети), или организация может выбрать, чтобы внутреннее сканирование уязвимостей выполнялось фирмой, специализирующейся на сканировании уязвимостей.
Определенные Процедуры Тестирования Подхода:
Состояние безопасности всех компонентов системы периодически проверяется с помощью автоматизированных инструментов, предназначенных для обнаружения уязвимостей, действующих внутри сети. Обнаруженные уязвимости оцениваются и устраняются на основе формальной системы оценки рисков
Примечания по применению:
Для проведения внутреннего сканирования уязвимостей не требуется использовать QSA или ASV.
Внутреннее сканирование уязвимостей может выполняться квалифицированным внутренним персоналом, который разумно независим от проверяемого системного компонента (компонентов) (например, сетевой администратор не должен нести ответственность за сканирование сети), или организация может выбрать, чтобы внутреннее сканирование уязвимостей выполнялось фирмой, специализирующейся на сканировании уязвимостей.
Определенные Процедуры Тестирования Подхода:
- 11.3.1.a Изучите результаты отчета о внутреннем сканировании за последние 12 месяцев, чтобы убедиться, что внутренние проверки проводились не реже одного раза в три месяца в течение последнего 12-месячного периода.
- 11.3.1.b Изучите результаты отчета о внутреннем сканировании после каждого сканирования и повторного сканирования за последние 12 месяцев, чтобы убедиться, что все уязвимости высокого риска и критические уязвимости (определенные в требовании PCI DSS 6.3.1) устранены.
- 11.3.1.c Изучите конфигурации средства сканирования и опросите персонал, чтобы убедиться, что средство сканирования обновляется с учетом последней информации об уязвимостях.
- 11.3.1.d Опросите ответственный персонал, чтобы убедиться, что сканирование было выполнено квалифицированным внутренним ресурсом (ресурсами) или квалифицированной внешней третьей стороной и что существует организационная независимость тестировщика.
Цель:
Быстрое выявление и устранение уязвимостей снижает вероятность использования уязвимости и потенциальной компрометации системного компонента или данных о держателях карт. Сканирование уязвимостей, проводимое не реже одного раза в три месяца, обеспечивает такое обнаружение и идентификацию.
Надлежащая практика:
Уязвимости, представляющие наибольший риск для окружающей среды (например, имеющие высокий или критический рейтинг в соответствии с требованием 6.3.1), должны быть устранены с наивысшим приоритетом.
Несколько отчетов о проверке можно объединить для ежеквартального процесса проверки, чтобы показать, что все системы были проверены и все применимые уязвимости были устранены в рамках трехмесячного цикла проверки уязвимостей. Однако может потребоваться дополнительная документация для подтверждения того, что устраняемые уязвимости находятся в процессе устранения.
Хотя проверки требуются не реже одного раза в три месяца, рекомендуется проводить более частые проверки в зависимости от сложности сети, частоты изменений и типов используемых устройств, программного обеспечения и операционных систем.
Определения:
Проверка на уязвимость - это комбинация автоматизированных инструментов, методов и/или методов, выполняемых против внешних и внутренних устройств и серверов, предназначенных для выявления потенциальных уязвимостей в приложениях, операционных системах и сетевых устройствах, которые могут быть обнаружены и использованы злоумышленниками.
Быстрое выявление и устранение уязвимостей снижает вероятность использования уязвимости и потенциальной компрометации системного компонента или данных о держателях карт. Сканирование уязвимостей, проводимое не реже одного раза в три месяца, обеспечивает такое обнаружение и идентификацию.
Надлежащая практика:
Уязвимости, представляющие наибольший риск для окружающей среды (например, имеющие высокий или критический рейтинг в соответствии с требованием 6.3.1), должны быть устранены с наивысшим приоритетом.
Несколько отчетов о проверке можно объединить для ежеквартального процесса проверки, чтобы показать, что все системы были проверены и все применимые уязвимости были устранены в рамках трехмесячного цикла проверки уязвимостей. Однако может потребоваться дополнительная документация для подтверждения того, что устраняемые уязвимости находятся в процессе устранения.
Хотя проверки требуются не реже одного раза в три месяца, рекомендуется проводить более частые проверки в зависимости от сложности сети, частоты изменений и типов используемых устройств, программного обеспечения и операционных систем.
Определения:
Проверка на уязвимость - это комбинация автоматизированных инструментов, методов и/или методов, выполняемых против внешних и внутренних устройств и серверов, предназначенных для выявления потенциальных уязвимостей в приложениях, операционных системах и сетевых устройствах, которые могут быть обнаружены и использованы злоумышленниками.
Requirement 11.3.2
11.3.2
Определенные Требования к Подходу:
Проверка внешних уязвимостей выполняется следующим образом:
Определенные Требования к Подходу:
Проверка внешних уязвимостей выполняется следующим образом:
- По крайней мере, раз в три месяца.
- Поставщиком сканирования, одобренным PCI SSC (ASV).
- Уязвимости устранены, и требования Руководства по программе ASV для прохождения проверки выполнены.
- Повторное сканирование выполняется по мере необходимости, чтобы подтвердить, что уязвимости устранены в соответствии с требованиями Руководства по программе ASV для проходящего сканирования.
Цель Индивидуального подхода:
Это требование не подходит для индивидуального подхода.
Примечания по применению:
Для первоначального соответствия требованиям PCI DSS не требуется, чтобы в течение 12 месяцев было выполнено четыре проходных сканирования, если оценщик проверяет: 1) самым последним результатом сканирования было проходное сканирование, 2) организация имеет задокументированные политики и процедуры, требующие проверки не реже одного раза в три месяца, и 3) уязвимости, отмеченные в результаты сканирования были исправлены, как показано в повторном сканировании (-ах).
Однако в последующие годы после первоначальной оценки PCI DSS необходимо проходить сканирование не реже одного раза в три месяца.
Инструменты сканирования ASV могут сканировать широкий спектр типов и топологий сетей. Любые особенности целевой среды (например, балансировщики нагрузки, сторонние поставщики, интернет-провайдеры, конкретные конфигурации, используемые протоколы, помехи при сканировании) должны быть согласованы между ASV и клиентом сканирования.
Обратитесь к Руководству по программе ASV, опубликованному на веб-сайте PCI SSC, для получения информации об обязанностях клиента сканирования, подготовке к сканированию и т.д.
Определенные Процедуры Тестирования Подхода:
Это требование не подходит для индивидуального подхода.
Примечания по применению:
Для первоначального соответствия требованиям PCI DSS не требуется, чтобы в течение 12 месяцев было выполнено четыре проходных сканирования, если оценщик проверяет: 1) самым последним результатом сканирования было проходное сканирование, 2) организация имеет задокументированные политики и процедуры, требующие проверки не реже одного раза в три месяца, и 3) уязвимости, отмеченные в результаты сканирования были исправлены, как показано в повторном сканировании (-ах).
Однако в последующие годы после первоначальной оценки PCI DSS необходимо проходить сканирование не реже одного раза в три месяца.
Инструменты сканирования ASV могут сканировать широкий спектр типов и топологий сетей. Любые особенности целевой среды (например, балансировщики нагрузки, сторонние поставщики, интернет-провайдеры, конкретные конфигурации, используемые протоколы, помехи при сканировании) должны быть согласованы между ASV и клиентом сканирования.
Обратитесь к Руководству по программе ASV, опубликованному на веб-сайте PCI SSC, для получения информации об обязанностях клиента сканирования, подготовке к сканированию и т.д.
Определенные Процедуры Тестирования Подхода:
- 11.3.2.a Изучите отчеты о проверке ASV за последние 12 месяцев, чтобы убедиться, что проверка внешних уязвимостей проводилась не реже одного раза в три месяца в течение последнего 12-месячного периода.
- 11.3.2.b Изучите отчет о проверке ASV после каждого сканирования и повторного сканирования, выполненного за последние 12 месяцев, чтобы убедиться, что уязвимости устранены и требования Руководства по программе ASV для прохождения проверки выполнены.
- 11.3.2.c Изучите отчеты о сканировании ASV, чтобы убедиться, что сканирование было выполнено Поставщиком сканирования, одобренным PCI SSC (ASV).
Цель:
Злоумышленники обычно ищут незащищенные или уязвимые внешние серверы, которые можно использовать для проведения направленной атаки. Организации должны убедиться, что эти внешние устройства регулярно проверяются на наличие слабых мест и что уязвимости исправляются или устраняются для защиты организации.
Поскольку внешние сети подвергаются большему риску компрометации, проверка внешних уязвимостей должна выполняться по крайней мере раз в три месяца поставщиком сканирования, одобренным PCI SSC (ASV).
Надлежащая практика:
Хотя проверки требуются не реже одного раза в три месяца, рекомендуется проводить более частые проверки в зависимости от сложности сети, частоты изменений и типов используемых устройств, программного обеспечения и операционных систем.
Можно объединить несколько отчетов о проверке, чтобы показать, что все системы были проверены и что все применимые уязвимости были устранены в рамках трехмесячного цикла проверки уязвимостей. Однако может потребоваться дополнительная документация для подтверждения того, что не устраненные уязвимости находятся в процессе устранения.
Злоумышленники обычно ищут незащищенные или уязвимые внешние серверы, которые можно использовать для проведения направленной атаки. Организации должны убедиться, что эти внешние устройства регулярно проверяются на наличие слабых мест и что уязвимости исправляются или устраняются для защиты организации.
Поскольку внешние сети подвергаются большему риску компрометации, проверка внешних уязвимостей должна выполняться по крайней мере раз в три месяца поставщиком сканирования, одобренным PCI SSC (ASV).
Надлежащая практика:
Хотя проверки требуются не реже одного раза в три месяца, рекомендуется проводить более частые проверки в зависимости от сложности сети, частоты изменений и типов используемых устройств, программного обеспечения и операционных систем.
Можно объединить несколько отчетов о проверке, чтобы показать, что все системы были проверены и что все применимые уязвимости были устранены в рамках трехмесячного цикла проверки уязвимостей. Однако может потребоваться дополнительная документация для подтверждения того, что не устраненные уязвимости находятся в процессе устранения.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.