Раздел А.8.8 ISO/IEC 27001:2022 (En) Annex A - Контроль соответствия

ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 9. Требования к защите информации на этапах жизненного цикла автоматизированных систем и приложений":

ЖЦ.20

ЖЦ.20 Реализация проведения ежегодного контроля защищенности АС, включающего: - тестирование на проникновение; - анализ уязвимостей системы защиты информации АС и информационной инфраструктуры промышленной среды
3-Н 2-О 1-О

ЖЦ.21

ЖЦ.21 Обеспечение оперативного устранения выявленных уязвимостей защиты информации АС, включая уязвимости прикладного ПО
3-О 2-О 1-О

ЖЦ.14

ЖЦ.14 Реализация контроля защищенности АС, включающего (по решению финансовой организации при модернизации АС проводится контроль защищенности только элементов информационной инфраструктуры, подвергнутых модернизации): - тестирование на проникновение; - анализ уязвимостей системы защиты информации АС и информационной инфраструктуры промышленной среды
3-Н 2-О 1-О

Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":

Р. 7 п. 3 п.п. 9

7.3.9. На стадии эксплуатации АБС должны быть определены, выполняться и регистрироваться процедуры:

контроля работоспособности (функционирования, эффективности) реализованных в АБС защитных мер, в том числе контроль реализации организационных защитных мер, контроль состава и параметров настройки применяемых технических защитных мер;
контроля отсутствия уязвимостей в оборудовании и программном обеспечении АБС;
контроля внесения изменений в параметры настройки АБС и применяемых технических защитных мер;
контроля необходимого обновления программного обеспечения АБС, включая программное обеспечение технических защитных мер.

Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":

п. 6. п.п. 2

6.2. Кредитные организации должны обеспечивать выполнение следующих требований к управлению изменениями критичной архитектуры:

управление уязвимостями в критичной архитектуре, из-за которых могут реализоваться информационные угрозы и которые могут повлечь превышение значений целевых показателей операционной надежности;
планирование и внедрение изменений в критичной архитектуре, направленных на обеспечение недопустимости неоказания или ненадлежащего оказания банковских услуг;
управление конфигурациями (настраиваемыми параметрами) объектов информационной инфраструктуры;
управление уязвимостями и обновлениями (исправлениями) объектов информационной инфраструктуры.

ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":

ЦЗИ.27

ЦЗИ.27 Регистрация фактов выявления уязвимостей защиты информации
3-Н 2-Т 1-Т

ЦЗИ.8

ЦЗИ.8 Контроль отсутствия и обеспечение оперативного устранения известных (описанных) уязвимостей, указанных в пунктах ЦЗИ.1-ЦЗИ.6 настоящей таблицы, путем сканирования и анализа состава, версий и параметров настроек прикладного ПО, ПО АС и системного ПО, реализующего функции обеспечения защиты информации и (или) влияющего на обеспечение защиты информации (далее в настоящем разделе - системное ПО, в том числе ПО операционных систем, ПО СУБД, ПО серверов приложений, ПО систем виртуализации), установленного на серверном и сетевом оборудовании
3-Н 2-Т 1-Т

ЦЗИ.10

ЦЗИ.10 Контроль отсутствия и обеспечение оперативного устранения известных (описанных) уязвимостей, предусмотренных мерами ЦЗИ.1-ЦЗИ.6 настоящей таблицы, путем сканирования и анализа состава, версий и параметров настроек средств и систем защиты информации
3-Н 2-Т 1-Т

ЦЗИ.9

ЦЗИ.9 Контроль отсутствия и обеспечение оперативного устранения известных (описанных) уязвимостей, предусмотренных мерами ЦЗИ.1-ЦЗИ.6 настоящей таблицы, путем сканирования и анализа состава, версий и параметров настроек прикладного ПО, ПО АС и (или) системного ПО, установленного на АРМ пользователей и эксплуатационного персонала
3-Н 2-Т 1-Т

NIST Cybersecurity Framework (RU):

RS.MI-3

RS.MI-3: Вновь выявленные уязвимости смягчаются или документируются как принятые риски

DE.CM-8

DE.CM-8: Выполняется сканирование уязвимостей

ID.RA-1

ID.RA-1: Идентифицированы и задокументированы уязвимости активов

ID.RA-5

ID.RA-5: Угрозы, уязвимости, вероятности и воздействия используются для определения риска

PR.IP-12

PR.IP-12: Разработан и внедрен план управления уязвимостями

Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":

АНЗ.1 АНЗ.1 Выявление, анализ уязвимостей информационной системы и оперативное устранение вновь выявленных уязвимостей

ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":

УИ.22.1

УИ.22.1 Реализации бизнес- и технологических процессов;

УИ.27

УИ.27 Регулярный****** анализ уязвимостей (сканирование на уязвимости) объектов информатизации инфраструктурного уровня, в том числе:

сканирование на уязвимости объектов информатизации, непосредственно взаимодействующих с сетью Интернет;
сканирование на уязвимости «внутренних» объектов информатизации, в том числе вычислительных сетей, на «границах» контуров безопасности.

УИ.36

УИ.36 Оценка эффективности********* деятельности по управлению уязвимостями (как минимум с учетом времени, затрачиваемого на устранение уязвимостей с момента их выявления).

УИ.22.3

УИ.22.3 Объектам информатизации инфраструктурного уровня.

УИ.22.2

УИ.22.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:

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:

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.

Requirement 11.3.1.2

11.3.1.2
Defined Approach Requirements:
Internal vulnerability scans are performed via authenticated scanning as follows:

Systems that are unable to accept credentials for authenticated scanning are documented.
Sufficient privileges are used for those systems that accept credentials for scanning.
If accounts used for authenticated scanning can be used for interactive login, they are managed in accordance with Requirement 8.2.2.

Customized Approach Objective:
Automated tools used to detect vulnerabilities can detect vulnerabilities local to each system, which are not visible remotely.

Applicability Notes:
The authenticated scanning tools can be either host-based or network-based.
“Sufficient” privileges are those needed to access system resources such that a thorough scan can be conducted that detects known vulnerabilities.
This requirement does not apply to system components that cannot accept credentials for scanning. Examples of systems that may not accept credentials for scanning include some network and security appliances, mainframes, and containers.
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Defined Approach Testing Procedures:

11.3.1.2.a Examine scan tool configurations to verify that authenticated scanning is used for internal scans, with sufficient privileges, for those systems that accept credentials for scanning.
11.3.1.2.b Examine scan report results and interview personnel to verify that authenticated scans are performed.
11.3.1.2.c If accounts used for authenticated scanning can be used for interactive login, examine the accounts and interview personnel to verify the accounts are managed following all elements specified in Requirement 8.2.2.
11.3.1.2.d Examine documentation to verify that systems that are unable to accept credentials for authenticated scanning are defined.

Purpose:
Authenticated scanning provides greater insight into an entity’s vulnerability landscape since it can detect vulnerabilities that unauthenticated scans cannot detect. Attackers may leverage vulnerabilities that an entity is unaware of because certain vulnerabilities will only be detected with authenticated scanning.
Authenticated scanning can yield significant additional information about an organization’s vulnerabilities.

Good Practice:
The credentials used for these scans should be considered highly privileged. They should be protected and controlled as such, following PCI DSS Requirements 7 and 8 (except for those requirements for multi-factor authentication and application and system accounts).

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:

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:

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.

Requirement 11.3.1.3

11.3.1.3
Defined Approach Requirements:
Internal vulnerability scans are performed after any significant change as follows:

High-risk and critical vulnerabilities (per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved.
Rescans are conducted as needed.
Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV).

Customized Approach Objective:
The security posture of all system components is verified following significant changes to the network or systems, by 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:
Authenticated internal vulnerability scanning per Requirement 11.3.1.2 is not required for scans performed after significant changes.

Defined Approach Testing Procedures:

11.3.1.3.a Examine change control documentation and internal scan reports to verify that system components were scanned after any significant changes.
11.3.1.3.b Interview personnel and examine internal scan and rescan reports to verify that internal scans were performed after significant changes and that high-risk and critical vulnerabilities as defined in Requirement 6.3.1 were resolved.
11.3.1.3.c Interview personnel to verify that internal scans are performed by a qualified internal resource(s) or qualified external third party and that organizational independence of the tester exists.

Purpose:
Scanning an environment after any significant changes ensures that changes were completed appropriately such that the security of the environment was not compromised because of the change.

Good Practice:
Entities should perform scans after significant changes as part of the change process per Requirement 6.5.2 and before considering the change complete. All system components affected by the change will need to be scanned.

Requirement 11.3.1.1

11.3.1.1
Defined Approach Requirements:
All other applicable vulnerabilities (those not ranked as high-risk or critical per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are managed as follows:

Addressed based on the risk defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.
Rescans are conducted as needed.

Customized Approach Objective:
Lower ranked vulnerabilities (lower than high or critical) are addressed at a frequency in accordance with the entity’s risk.

Applicability Notes:
The timeframe for addressing lower-risk vulnerabilities is subject to the results of a risk analysis per Requirement 12.3.1 that includes (minimally) identification of assets being protected, threats, and likelihood and/or impact of a threat being realized.
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Defined Approach Testing Procedures:

11.3.1.1.a Examine the entity’s targeted risk analysis that defines the risk for addressing all other applicable vulnerabilities (those not ranked as high-risk or critical per the entity’s vulnerability risk rankings at Requirement 6.3.1) to verify the risk analysis was performed in accordance with all elements specified at Requirement 12.3.1.
11.3.1.1.b Interview responsible personnel and examine internal scan report results or other documentation to verify that all other applicable vulnerabilities (those not ranked as high-risk or critical per the entity’s vulnerability risk rankings at Requirement 6.3.1) are addressed based on the risk defined in the entity’s targeted risk analysis, and that the scan process includes rescans as needed to confirm the vulnerabilities have been addressed.

Purpose:
All vulnerabilities, regardless of criticality, provide a potential avenue of attack and must therefore be addressed periodically, with the vulnerabilities that expose the most risk addressed more quickly to limit the potential window of attack.

ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":

A.12.6.1

A.12.6.1 Процесс управления техническими уязвимостями
Мера обеспечения информационной безопасности: Должна быть своевременно получена информация о технических уязвимостях используемых информационных систем, оценена подверженность организации таким уязвимостям, и должны быть приняты соответствующие меры в отношении связанного с этим риска информационной безопасности

CIS Critical Security Controls v7.1 (SANS Top 20):

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.

CSC 20.6 CSC 20.6 Use Vulnerability Scanning and Penetration Testing Tools in Concert
Use vulnerability scanning and penetration testing tools in concert. The results of vulnerability scanning assessments should be used as a starting point to guide and focus penetration testing efforts.

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.

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.

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.

CSC 3.7 CSC 3.7 Utilize a Risk-Rating Process
Utilize a risk-rating process to prioritize the remediation of discovered vulnerabilities.

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.
Внутреннее сканирование уязвимостей может выполняться квалифицированным внутренним персоналом, который разумно независим от проверяемого системного компонента (компонентов) (например, сетевой администратор не должен нести ответственность за сканирование сети), или организация может выбрать, чтобы внутреннее сканирование уязвимостей выполнялось фирмой, специализирующейся на сканировании уязвимостей.

Определенные Процедуры Тестирования Подхода:

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), должны быть устранены с наивысшим приоритетом.
Несколько отчетов о проверке можно объединить для ежеквартального процесса проверки, чтобы показать, что все системы были проверены и все применимые уязвимости были устранены в рамках трехмесячного цикла проверки уязвимостей. Однако может потребоваться дополнительная документация для подтверждения того, что устраняемые уязвимости находятся в процессе устранения.
Хотя проверки требуются не реже одного раза в три месяца, рекомендуется проводить более частые проверки в зависимости от сложности сети, частоты изменений и типов используемых устройств, программного обеспечения и операционных систем.

Определения:
Проверка на уязвимость - это комбинация автоматизированных инструментов, методов и/или методов, выполняемых против внешних и внутренних устройств и серверов, предназначенных для выявления потенциальных уязвимостей в приложениях, операционных системах и сетевых устройствах, которые могут быть обнаружены и использованы злоумышленниками.

Requirement 11.3.1.2

11.3.1.2
Определенные Требования к Подходу:
Проверка внутренних уязвимостей выполняется с помощью проверки подлинности следующим образом:

Системы, которые не могут принять учетные данные для проверки подлинности, документируются.
Достаточные привилегии используются для тех систем, которые принимают учетные данные для сканирования.
Если учетные записи, используемые для проверки подлинности, могут использоваться для интерактивного входа в систему, управление ими осуществляется в соответствии с требованием 8.2.2.

Цель Индивидуального подхода:
Автоматизированные инструменты, используемые для обнаружения уязвимостей, могут обнаруживать уязвимости, локальные для каждой системы, которые не видны удаленно.

Примечания по применению:
Средства проверки подлинности могут быть как на базе хоста, так и на основе сети.
“Достаточные” привилегии - это те, которые необходимы для доступа к системным ресурсам, чтобы можно было провести тщательное сканирование, обнаруживающее известные уязвимости.
Это требование не распространяется на системные компоненты, которые не могут принимать учетные данные для сканирования. Примерами систем, которые могут не принимать учетные данные для сканирования, являются некоторые сетевые устройства и устройства безопасности, мэйнфреймы и контейнеры.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:

11.3.1.2.a Проверьте конфигурации средства сканирования, чтобы убедиться, что аутентифицированное сканирование используется для внутренних проверок с достаточными привилегиями для тех систем, которые принимают учетные данные для сканирования.
11.3.1.2.b Изучите результаты отчета о сканировании и опросите персонал, чтобы убедиться, что аутентифицированные сканирования выполнены.
11.3.1.2.c Если учетные записи, используемые для проверки подлинности, могут использоваться для интерактивного входа в систему, проверьте учетные записи и опросите персонал, чтобы убедиться, что управление учетными записями осуществляется в соответствии со всеми элементами, указанными в Требовании 8.2.2.
11.3.1.2.d Изучите документацию, чтобы убедиться, что определены системы, которые не могут принимать учетные данные для проверки подлинности.

Цель:
Аутентифицированное сканирование обеспечивает более глубокое понимание ландшафта уязвимостей объекта, поскольку оно может обнаруживать уязвимости, которые не могут быть обнаружены при проверке подлинности. Злоумышленники могут использовать уязвимости, о которых организация не знает, поскольку определенные уязвимости будут обнаружены только при проверке подлинности.
Аутентифицированное сканирование может дать значительную дополнительную информацию об уязвимостях организации.

Надлежащая практика:
Учетные данные, используемые для этих сканирований, должны считаться очень привилегированными. Они должны быть защищены и контролироваться как таковые в соответствии с требованиями PCI DSS 7 и 8 (за исключением требований к многофакторной аутентификации и учетным записям приложений и систем).

Requirement 11.3.1.1

11.3.1.1
Определенные Требования к Подходу:
Все другие применимые уязвимости (те, которые не классифицируются как высокорисковые или критические в соответствии с ранжированием рисков уязвимости организации, определенным в требовании 6.3.1) управляются следующим образом:

Рассматриваются на основе риска, определенного в целевом анализе рисков организации, который выполняется в соответствии со всеми элементами, указанными в Требовании 12.3.1.
Повторные сканирования проводятся по мере необходимости.

Цель Индивидуального подхода:
Уязвимости с более низким рейтингом (ниже высокого или критического) устраняются с определенной периодичностью в соответствии с риском организации.

Примечания по применению:
Временные рамки для устранения уязвимостей с низким уровнем риска зависят от результатов анализа рисков в соответствии с требованием 12.3.1, которое включает (минимально) идентификацию защищаемых активов, угроз и вероятности и/или воздействия реализуемой угрозы.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:

11.3.1.1.a Изучите целевой анализ рисков организации, который определяет риск для устранения всех других применимых уязвимостей (тех, которые не классифицируются как высокорисковые или критические в соответствии с рейтингом рисков уязвимости организации в Требовании 6.3.1), чтобы убедиться, что анализ рисков был выполнен в соответствии со всеми элементами, указанными в Требовании 12.3.1.
11.3.1.1.b Опросите ответственный персонал и изучите результаты отчета о внутреннем сканировании или другую документацию, чтобы убедиться, что все другие применимые уязвимости (те, которые не классифицируются как высокорисковые или критические в соответствии с рейтингом рисков уязвимости организации в соответствии с требованием 6.3.1) устранены на основе риска, определенного в целевом анализе рисков организации, и что процесс сканирования включает повторное сканирование по мере необходимости для подтверждения устранения уязвимостей.

Цель:
Все уязвимости, независимо от их критичности, представляют собой потенциальный путь атаки и поэтому должны периодически устраняться, при этом уязвимости, которые представляют наибольший риск, устраняются быстрее, чтобы ограничить потенциальное окно атаки.

Requirement 11.3.1.3

11.3.1.3
Определенные Требования к Подходу:
Внутреннее сканирование уязвимостей выполняется после любого существенного изменения следующим образом:

Устраняются уязвимости высокого риска и критические уязвимости (в соответствии с ранжированием рисков уязвимости организации, определенным в требовании 6.3.1).
Повторные сканирования проводятся по мере необходимости.
Сканирование выполняется квалифицированным персоналом, и существует организационная независимость тестировщика (не обязательно быть QSA или ASV).

Цель Индивидуального подхода:
Состояние безопасности всех компонентов системы проверяется после значительных изменений в сети или системах с помощью автоматизированных инструментов, предназначенных для обнаружения уязвимостей, действующих внутри сети. Обнаруженные уязвимости оцениваются и устраняются на основе формальной системы оценки рисков.

Примечания по применению:
Проверка внутренних уязвимостей с проверкой подлинности в соответствии с требованием 11.3.1.2 не требуется для проверок, выполняемых после значительных изменений.

Определенные Процедуры Тестирования Подхода:

11.3.1.3.a Изучите документацию по контролю изменений и отчеты о внутреннем сканировании, чтобы убедиться, что компоненты системы были проверены после любых существенных изменений.
11.3.1.3.b Опросите персонал и изучите отчеты о внутреннем сканировании и повторном сканировании, чтобы убедиться, что внутреннее сканирование было выполнено после значительных изменений и что были устранены уязвимости высокого риска и критические уязвимости, определенные в Требовании 6.3.1.
11.3.1.3.c Опросить персонал, чтобы убедиться, что внутреннее сканирование выполняется квалифицированным внутренним ресурсом (ресурсами) или квалифицированной внешней третьей стороной и что существует организационная независимость тестировщика.

Цель:
Сканирование среды после любых существенных изменений гарантирует, что изменения были выполнены надлежащим образом, чтобы безопасность среды не была нарушена из-за изменений.

Надлежащая практика:
Субъекты должны выполнять сканирование после существенных изменений как часть процесса изменения в соответствии с требованием 6.5.2 и до того, как считать изменение завершенным. Необходимо будет просканировать все системные компоненты, затронутые этим изменением.

Requirement 6.4.1

6.4.1
Определенные Требования к Подходу:
Для общедоступных веб-приложений новые угрозы и уязвимости устраняются на постоянной основе, и эти приложения защищены от известных атак следующим образом:

Проверка общедоступных веб-приложений с помощью ручных или автоматизированных инструментов или методов оценки безопасности уязвимостей приложений следующим образом:
- Не реже одного раза в 12 месяцев и после значительных изменений.
- Организацией, специализирующейся на безопасности приложений.
- Включая, как минимум, все распространенные программные атаки в требовании 6.2.4.
- Все уязвимости ранжируются в соответствии с требованием 6.3.1.
- Все уязвимости исправлены.
- Заявка повторно оценивается после внесения исправлений

ИЛИ

Установка автоматизированного технического решения (решений), которое постоянно обнаруживает и предотвращает веб-атаки следующим образом:
- Устанавливается перед общедоступными веб-приложениями для обнаружения и предотвращения веб-атак.
- Активно работает и обновляется по мере необходимости.
- Создание журналов аудита.
- Настроен либо на блокировку веб-атак, либо на генерацию предупреждения, которое немедленно проверяется.

Цель Индивидуального подхода:
Общедоступные веб-приложения защищены от вредоносных атак.

Примечания по применению:
Эта оценка отличается от проверки уязвимостей, выполненной для требований 11.3.1 и 11.3.2.
Это требование будет заменено Требованием 6.4.2 после 31 марта 2025 года, когда Требование 6.4.2 вступит в силу.

Определенные Процедуры Тестирования Подхода:

6.4.1 Для общедоступных веб-приложений убедитесь, что используется один из требуемых методов следующим образом:
Если используются ручные или автоматические инструменты или методы оценки безопасности уязвимостей, изучите документированные процессы, опросите персонал и изучите записи оценок безопасности приложений, чтобы убедиться, что общедоступные веб-приложения проверяются в соответствии со всеми элементами этого требования, специфичного для инструмента / метода.

ИЛИ

Если установлено автоматизированное техническое решение (решения), которое постоянно обнаруживает и предотвращает веб-атаки, изучите параметры конфигурации системы и журналы аудита и опросите ответственный персонал, чтобы убедиться, что автоматизированное техническое решение (решения) установлено в соответствии со всеми элементами этого требования, специфичного для решения (решений).

Цель:
Общедоступные веб-приложения - это те, которые доступны для общественности (не только для внутреннего использования). Эти приложения являются основными целями для злоумышленников, а плохо закодированные веб-приложения обеспечивают злоумышленникам легкий путь для получения доступа к конфиденциальным данным и системам.

Надлежащая практика:
Ручные или автоматические инструменты или методы оценки безопасности уязвимостей проверяют и/или тестируют приложение на наличие уязвимостей.
Распространенные инструменты оценки включают специализированные веб-сканеры, которые выполняют автоматический анализ защиты веб-приложений.
При использовании автоматизированных технических решений важно включить процессы, которые облегчают своевременное реагирование на предупреждения, генерируемые решениями, чтобы можно было смягчить любые обнаруженные атаки.

Примеры:
Брандмауэр веб-приложений (WAF), установленный перед общедоступными веб-приложениями для проверки всего трафика, является примером автоматизированного технического решения, которое обнаруживает и предотвращает веб-атаки (например, атаки, включенные в требование 6.2.4). WAFS фильтруют и блокируют несущественный трафик на прикладном уровне. Правильно настроенный WAF помогает предотвратить атаки прикладного уровня на приложения, которые неправильно закодированы или настроены.
Другим примером автоматизированного технического решения являются технологии самозащиты приложений во время выполнения (RASP). При правильной реализации решения RASP могут обнаруживать и блокировать аномальное поведение программного обеспечения во время выполнения. В то время как WAFs обычно отслеживают периметр приложения, решения RASP отслеживают и блокируют поведение внутри приложения.

Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":

АНЗ.1 АНЗ.1 Выявление, анализ уязвимостей информационной системы и оперативное устранение вновь выявленных уязвимостей

Strategies to Mitigate Cyber Security Incidents (EN):

1.2.

Patch applications (e.g. Flash, web browsers, Microsoft Office, Java and PDF viewers). Patch/mitigate computers with ‘extreme risk’ security vulnerabilities within 48 hours. Use the latest version of applications.
Relative Security Effectiveness: Essential | Potential User Resistance: Low | Upfront Cost: High | Ongoing Maintenance Cost: High

2.2.

Patch operating systems. Patch/mitigate computers (including network devices) with ‘extreme risk’ security vulnerabilities within 48 hours. Use the latest operating system version. Don’t use unsupported versions.
Relative Security Effectiveness: Essential | Potential User Resistance: Low | Upfront Cost: Medium | Ongoing Maintenance Cost: Medium

Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":

А.8.8

А.8.8 Управление техническими уязвимостями
Должна своевременно получаться информация о технических уязвимостях используемых информационных систем, также должно оцениваться воздействие таких уязвимостей на организацию, и должны предприниматься соответствующие меры.

Положение Банка России № 719-П от 04.06.2020 "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств":

Глава 1 п. 1

1.1. Операторы по переводу денежных средств, банковские платежные агенты (субагенты), операторы услуг информационного обмена, операторы услуг платежной инфраструктуры в части требований к обеспечению защиты информации при осуществлении переводов денежных средств, применяемых в отношении автоматизированных систем, программного обеспечения, средств вычислительной техники, телекоммуникационного оборудования, эксплуатация и использование которых обеспечивается при осуществлении переводов денежных средств операторами по переводу денежных средств (далее - объекты информационной инфраструктуры), должны обеспечивать:

реализацию установленных настоящим Положением уровней защиты информации для объектов информационной инфраструктуры, используемых для обработки, передачи, хранения информации, указанной в абзаце первом пункта 1.3 настоящего Положения, в целях осуществления переводов денежных средств, определенных национальным стандартом Российской Федерации ГОСТ Р 57580.1-2017 «Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер», утвержденным приказом Федерального агентства по техническому регулированию и метрологии от 8 августа 2017 года № 822-ст «Об утверждении национального стандарта Российской Федерации» (М., ФГУП «Стандартинформ», 2017) (далее - ГОСТ Р 57580.1-2017);
ежегодное тестирование на проникновение и анализ уязвимостей информационной безопасности объектов информационной инфраструктуры с учетом особенностей, предусмотренных пунктами 3.8 и 3.9 настоящего Положения;
проведение оценки соответствия уровням защиты информации, установленным настоящим Положением (далее - оценка соответствия защиты информации), в соответствии с национальным стандартом Российской Федерации ГОСТ Р 57580.2-2018 «Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Методика оценки соответствия», утвержденным приказом Федерального агентства по техническому регулированию и метрологии от 28 марта 2018 года № 156-ст «Об утверждении национального стандарта Российской Федерации» (М., ФГУП «Стандартинформ», 2018) (далее - ГОСТ Р 57580.2-2018), с учетом особенностей, предусмотренных пунктами 2.3, 2.4, 3.6 - 3.9, 4.4, 4.5, 6.7 и 6.8 настоящего Положения.

Оценка соответствия защиты информации должна осуществляться с привлечением сторонних организаций, имеющих лицензию на осуществление деятельности по технической защите конфиденциальной информации на проведение работ и услуг, предусмотренных подпунктами «б», «д» или «е» пункта 4 Положения о лицензировании деятельности по технической защите конфиденциальной информации, утвержденного постановлением Правительства Российской Федерации от 3 февраля 2012 года № 79 «О лицензировании деятельности по технической защите конфиденциальной информации» (Собрание законодательства Российской Федерации, 2012, № 7, ст. 863; 2016, № 26, ст. 4049) (далее соответственно - проверяющая организация, постановление Правительства Российской Федерации № 79).
Операторы по переводу денежных средств, банковские платежные агенты (субагенты), операторы услуг информационного обмена, операторы услуг платежной инфраструктуры должны обеспечивать хранение отчета, подготовленного проверяющей организацией по результатам оценки соответствия защиты информации, не менее пяти лет начиная с даты его выдачи проверяющей организацией.

Глава 3 п.8

3.8. Банковские платежные агенты (субагенты), за исключением банковских платежных агентов, осуществляющих операции платежного агрегатора, должны на основе критериев, установленных операторами по переводу денежных средств, проводить тестирование на проникновение и анализ уязвимостей информационной безопасности объектов информационной инфраструктуры, оценку соответствия защиты информации, сертификацию или оценку соответствия прикладного программного обеспечения автоматизированных систем и приложений.

Глава 3 п.9

3.9. Банковские платежные агенты (субагенты), осуществляющие операции платежного агрегатора, должны на основе критериев, установленных операторами по переводу денежных средств, проводить тестирование на проникновение и анализ уязвимостей информационной безопасности объектов информационной инфраструктуры, сертификацию или оценку соответствия прикладного программного обеспечения автоматизированных систем и приложений.

SWIFT Customer Security Controls Framework v2022:

2 - 2.7 Vulnerability Scanning

2.7 Vulnerability Scanning

Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":

АУД.2 АУД.2 Анализ уязвимостей и их устранение

Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":

п. 1.5.

1.5. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны обеспечивать выполнение следующих требований в отношении управления изменениями критичной архитектуры:

управление уязвимостями в критичной архитектуре, с использованием которых могут реализоваться информационные угрозы и которые могут повлечь отклонение от значений целевых показателей операционной надежности, указанных в пункте 1.3 настоящего Положения;
планирование и внедрение изменений в критичной архитектуре, направленных на обеспечение непрерывного оказания финансовых услуг;
управление конфигурациями объектов информационной инфраструктуры некредитных финансовых организаций;
управление уязвимостями и обновлениями (исправлениями) объектов информационной инфраструктуры некредитных финансовых организаций.

NIST Cybersecurity Framework (EN):

RS.MI-3 RS.MI-3: Newly identified vulnerabilities are mitigated or documented as accepted risks

DE.CM-8 DE.CM-8: Vulnerability scans are performed

ID.RA-1 ID.RA-1: Asset vulnerabilities are identified and documented

ID.RA-5 ID.RA-5: Threats, vulnerabilities, likelihoods, and impacts are used to determine risk

PR.IP-12 PR.IP-12: A vulnerability management plan is developed and implemented

Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":

АУД.2 АУД.2 Анализ уязвимостей и их устранение

Положение Банка России № 716-П от 08.04.2022 "О требованиях к системе управления операционным риском в кредитной организации и банковской группе":

Глава 8. Пункт 8.7

8.8.7. Ежегодное тестирование уязвимостей информационных систем и (или) их компонентов и других источников риска информационных систем, а также разработка комплекса мероприятий, направленных на устранение выявленных уязвимостей информационных систем и (или) других источников риска информационных систем.

Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022

Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A

А.8.8

Список требований

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

Связанные защитные меры