Куда я попал?
SECURITM это SGRC система, ? автоматизирующая процессы в службах информационной безопасности. SECURITM помогает построить и управлять ИСПДн, КИИ, ГИС, СМИБ/СУИБ, банковскими системами защиты.
А еще SECURITM это место для обмена опытом и наработками для служб безопасности.

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

Framework

CSC 3.2

Для проведения оценки соответствия по документу войдите в систему.

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

CIS Critical Security Controls v8 (The 18 CIS CSC):
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. 
7.5
7.5 Perform Automated Vulnerability Scans of Internal Enterprise Assets
Perform automated vulnerability scans of internal enterprise assets on a quarterly, or more frequent, basis. Conduct both authenticated and unauthenticated scans, using a SCAP-compliant vulnerability scanning tool. 
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 6. п.п. 2
6.2. Кредитные организации должны обеспечивать выполнение следующих требований к управлению изменениями критичной архитектуры:
  • управление уязвимостями в критичной архитектуре, из-за которых могут реализоваться информационные угрозы и которые могут повлечь превышение значений целевых показателей операционной надежности;
  • планирование и внедрение изменений в критичной архитектуре, направленных на обеспечение недопустимости неоказания или ненадлежащего оказания банковских услуг;
  • управление конфигурациями (настраиваемыми параметрами) объектов информационной инфраструктуры;
  • управление уязвимостями и обновлениями (исправлениями) объектов информационной инфраструктуры.
NIST Cybersecurity Framework (RU):
DE.CM-8
DE.CM-8: Выполняется сканирование уязвимостей
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
АНЗ.1 АНЗ.1 Выявление, анализ уязвимостей информационной системы и оперативное устранение вновь выявленных уязвимостей
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
7.5
7.5 Выполняется автоматизированное сканирование на уязвимости внутренних устройств и программного обеспечения предприятия
Используется совместимый со SCAP (Протокол автоматизации управления данными безопасности) сканер.
Сканирование проводится раз в квартал.
Используется сканирование без аутентификации и с аутентификацией.
7.6
7.6 Выполняется автоматизированное сканирование на уязвимости внутренних устройств и программного обеспечения предприятия, доступных извне
Используется совместимый со SCAP (Протокол автоматизации управления данными безопасности) сканер. 
Сканирование проводится раз в месяц.
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.3.1
6.3.1
Defined Approach Requirements: 
Security vulnerabilities are identified and managed as follows:
  • New security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs). 
  • Vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact. 
  • Risk rankings identify, at a minimum, all vulnerabilities considered to be a high-risk or critical to the environment.
  •  Vulnerabilities for bespoke and custom, and third-party software (for example operating systems and databases) are covered. 
Customized Approach Objective:
New system and software vulnerabilities that may impact the security of account data or the CDE are monitored, cataloged, and risk assessed. 

Applicability Notes:
This requirement is not achieved by, nor is it the same as, vulnerability scans performed for Requirements 11.3.1 and 11.3.2. This requirement is for a process to actively monitor industry sources for vulnerability information and for the entity to determine the risk ranking to be associated with each vulnerability. 

Defined Approach Testing Procedures:
  •  6.3.1.a Examine policies and procedures for identifying and managing security vulnerabilities to verify that processes are defined in accordance with all elements specified in this requirement. 
  • 6.3.1.b Interview responsible personnel, examine documentation, and observe processes to verify that security vulnerabilities are identified and managed in accordance with all elements specified in this requirement. 
Purpose:
Classifying the risks (for example, as critical, high, medium, or low) allows organizations to identify, prioritize, and address the highest risk items more quickly and reduce the likelihood that vulnerabilities posing the greatest risk will be exploited 

Good Practice:
Methods for evaluating vulnerabilities and assigning risk ratings will vary based on an organization’s environment and risk-assessment strategy. 
When an entity is assigning its risk rankings, it should consider using a formal, objective, justifiable methodology that accurately portrays the risks of the vulnerabilities pertinent to the organization and translates to an appropriate entity-assigned priority for resolution. 
An organization’s processes for managing vulnerabilities should be integrated with other management processes—for example, risk management, change management, patch management, incident response, application security, as well as proper monitoring and logging of these processes. This will help to ensure all vulnerabilities are properly identified and addressed. Processes should support ongoing evaluation of vulnerabilities. For example, a vulnerability initially identified as low risk could become a higher risk later. Additionally, vulnerabilities, individually considered to be low or medium risk, could collectively pose a high or critical risk if present on the same system, or if exploited on a low-risk system that could result in access to the CDE. 

Examples:
Some organizations that issue alerts to advise entities about urgent vulnerabilities requiring immediate patches/updates are national Computer Emergency Readiness/Response Teams (CERTs) and vendors. 
Criteria for ranking vulnerabilities may include criticality of a vulnerability identified in an alert from Forum of Incident Response and Security Teams (FIRST) or a CERT, consideration of the CVSS score, the classification by the vendor, and/or type of systems affected. 

Further Information:
Trustworthy sources for vulnerability information include vendor websites, industry newsgroups, mailing lists, etc. If software is developed inhouse, the internal development team should also consider sources of information about new vulnerabilities that may affect internally developed applications. Other methods to ensure new vulnerabilities are identified include solutions that automatically recognize and alert upon detection of unusual behavior. Processes should account for widely published exploits as well as “zero-day” attacks, which target previously unknown vulnerabilities. 
For bespoke and custom software, the organization may obtain information about libraries, frameworks, compilers, programming languages, etc. from public trusted sources (for example, special resources and resources from component developers). The organization may also independently analyze third-party components and identify vulnerabilities. 
For control over in-house developed software, the organization may receive such information from external sources. The organization can consider using a “bug bounty” program where it posts information (for example, on its website) so third parties can contact the organization with vulnerability information. External sources may include independent investigators or companies that report to the organization about identified vulnerabilities and may include sources such as the Common Vulnerability Scoring System (CVSS) or the OWASP Risk Rating Methodology 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.12.6.1
A.12.6.1 Процесс управления техническими уязвимостями 
Мера обеспечения информационной безопасности: Должна быть своевременно получена информация о технических уязвимостях используемых информационных систем, оценена подверженность организации таким уязвимостям, и должны быть приняты соответствующие меры в отношении связанного с этим риска информационной безопасности 
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 6.3.1
6.3.1
Определенные Требования к Подходу:
Уязвимости в системе безопасности выявляются и устраняются следующим образом:
  • Новые уязвимости в системе безопасности выявляются с использованием признанных в отрасли источников информации об уязвимостях системы безопасности, включая оповещения от международных и национальных групп реагирования на компьютерные чрезвычайные ситуации (CERT).
  • Уязвимостям присваивается рейтинг рисков на основе лучших отраслевых практик и учета потенциального воздействия.
  • Рейтинги рисков определяют, как минимум, все уязвимости, которые считаются высокорискованными или критичными для окружающей среды.
  • Рассматриваются уязвимости для индивидуального и пользовательского программного обеспечения, а также программного обеспечения сторонних производителей (например, операционных систем и баз данных).
Цель Индивидуального подхода:
Новые системные и программные уязвимости, которые могут повлиять на безопасность данных учетной записи или CDE, отслеживаются, каталогизируются и оцениваются риски.

Примечания по применению:
Это требование не достигается и не совпадает с проверками уязвимостей, выполняемыми для требований 11.3.1 и 11.3.2. Это требование касается процесса активного мониторинга отраслевых источников информации об уязвимостях и определения организацией ранжирования рисков, связанных с каждой уязвимостью.

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

Надлежащая практика:
Методы оценки уязвимостей и присвоения рейтингов рисков будут варьироваться в зависимости от среды организации и стратегии оценки рисков.
Когда организация присваивает свои рейтинги рисков, ей следует рассмотреть возможность использования формальной, объективной, обоснованной методологии, которая точно отражает риски уязвимостей, относящихся к организации, и переводит их в соответствующий приоритет, присвоенный организации для устранения.
Процессы организации по управлению уязвимостями должны быть интегрированы с другими процессами управления — например, управление рисками, управление изменениями, управление исправлениями, реагирование на инциденты, безопасность приложений, а также надлежащий мониторинг и протоколирование этих процессов. Это поможет обеспечить надлежащее выявление и устранение всех уязвимостей. Процессы должны поддерживать текущую оценку уязвимостей. Например, уязвимость, первоначально идентифицированная как низкая степень риска, может впоследствии стать более высокой степенью риска. Кроме того, уязвимости, которые по отдельности считаются низким или средним риском, могут в совокупности представлять высокий или критический риск, если они присутствуют в одной и той же системе или если они используются в системе с низким уровнем риска, что может привести к доступу к CDE.

Примеры:
Некоторые организации, которые выпускают предупреждения для информирования организаций о срочных уязвимостях, требующих немедленных исправлений/обновлений, - это национальные группы компьютерной готовности к чрезвычайным ситуациям/ реагирования (сертификаты) и поставщики.
Критерии ранжирования уязвимостей могут включать критичность уязвимости, выявленной в предупреждении от Форума Групп реагирования на инциденты и безопасности (FIRST) или сертификата, рассмотрение оценки CVSS, классификацию поставщиком и/или тип затронутых систем.

Дополнительная информация:
Надежные источники информации об уязвимостях включают веб-сайты поставщиков, отраслевые группы новостей, списки рассылки и т.д. Если программное обеспечение разрабатывается собственными силами, внутренняя команда разработчиков должна также рассмотреть источники информации о новых уязвимостях, которые могут повлиять на приложения, разработанные внутри компании. Другие методы обеспечения выявления новых уязвимостей включают решения, которые автоматически распознают и предупреждают об обнаружении необычного поведения. Процессы должны учитывать широко опубликованные эксплойты, а также атаки “нулевого дня”, нацеленные на ранее неизвестные уязвимости.
Для программного обеспечения, изготовленного на заказ и изготовленного на заказ, организация может получать информацию о библиотеках, фреймворках, компиляторах, языках программирования и т.д. из общедоступных надежных источников (например, специальных ресурсов и ресурсов от разработчиков компонентов). Организация также может самостоятельно анализировать сторонние компоненты и выявлять уязвимости.
Для контроля над программным обеспечением, разработанным собственными силами, организация может получать такую информацию из внешних источников. Организация может рассмотреть возможность использования программы “вознаграждение за ошибки”, в рамках которой она размещает информацию (например, на своем веб-сайте), чтобы третьи стороны могли связаться с организацией с информацией об уязвимостях. Внешние источники могут включать независимых исследователей или компании, которые сообщают организации о выявленных уязвимостях, и могут включать такие источники, как Общая система оценки уязвимостей (CVSS) или Методология оценки рисков OWASP
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
АНЗ.1 АНЗ.1 Выявление, анализ уязвимостей информационной системы и оперативное устранение вновь выявленных уязвимостей
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.8
А.8.8 Управление техническими уязвимостями
Должна своевременно получаться информация о технических уязвимостях используемых информационных систем, также должно оцениваться воздействие таких уязвимостей на организацию, и должны предприниматься соответствующие меры.
Положение Банка России № 719-П от 04.06.2020 "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств":
Глава 3 п.8
3.8. Банковские платежные агенты (субагенты), за исключением банковских платежных агентов, осуществляющих операции платежного агрегатора, должны на основе критериев, установленных операторами по переводу денежных средств, проводить тестирование на проникновение и анализ уязвимостей информационной безопасности объектов информационной инфраструктуры, оценку соответствия защиты информации, сертификацию или оценку соответствия прикладного программного обеспечения автоматизированных систем и приложений.

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

Приказ ФСТЭК России № 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):
DE.CM-8 DE.CM-8: Vulnerability scans are performed
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
АУД.2 АУД.2 Анализ уязвимостей и их устранение
Стандарт № 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.