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

Приказ ФСТЭК России № 21 от 18.02.2013

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

АНЗ.1

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

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

Положение Банка России № 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-Т
ЦЗИ.6
ЦЗИ.6 Контроль отсутствия и обеспечение оперативного устранения известных (описанных) уязвимостей защиты информации, использование которых может позволить осуществить несанкционированный логический доступ к ресурсам доступа, размещенным во внутренних вычислительных сетях финансовой организации
3-Н 2-Т 1-Т
ЦЗИ.4
ЦЗИ.4 Контроль отсутствия и обеспечение оперативного устранения известных (описанных) уязвимостей защиты информации, использование которых может позволить осуществить несанкционированный логический доступ к ресурсам доступа, размещенным в вычислительных сетях финансовой организации, подключенных к сети Интернет
3-О 2-Т 1-Т
ЦЗИ.1
ЦЗИ.1 Контроль отсутствия и обеспечение оперативного устранения известных (описанных) уязвимостей защиты информации, использование которых может позволить осуществить несанкционированное (неконтролируемое) информационное взаимодействие между сегментами контуров безопасности и иными внутренними сетями финансовой организации
3-Н 2-Т 1-Т
ЦЗИ.3
ЦЗИ.3 Контроль отсутствия и обеспечение оперативного устранения известных (описанных) уязвимостей защиты информации, использование которых может позволить осуществить несанкционированное (неконтролируемое) информационное взаимодействие между сегментами, предназначенными для размещения общедоступных объектов доступа (в том числе банкоматов, платежных терминалов), и сетью Интернет
3-О 2-Т 1-Т
ЦЗИ.2
ЦЗИ.2 Контроль отсутствия и обеспечение оперативного устранения известных (описанных) уязвимостей защиты информации, использование которых может позволить осуществить несанкционированное (неконтролируемое) информационное взаимодействие между внутренними вычислительными сетями финансовой организации и сетью Интернет
3-О 2-Т 1-Т
ЦЗИ.5
ЦЗИ.5 Контроль отсутствия и обеспечение оперативного устранения известных (описанных) уязвимостей защиты информации, использование которых может позволить осуществить несанкционированный удаленный доступ
3-О 2-Т 1-Т
ЦЗИ.7
ЦЗИ.7 Контроль отсутствия и обеспечение оперативного устранения известных (описанных) уязвимостей, предусмотренных мерами ЦЗИ.1-ЦЗИ.6 настоящей таблицы, путем сканирования и анализа параметров настроек серверного и сетевого оборудования
3-Н 2-Т 1-Т
NIST Cybersecurity Framework (RU):
DE.CM-8
DE.CM-8: Выполняется сканирование уязвимостей
ID.RA-1
ID.RA-1: Идентифицированы и задокументированы уязвимости активов 
PR.IP-12
PR.IP-12: Разработан и внедрен план управления уязвимостями
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
УИ.22.1
УИ.22.1 Реализации бизнес- и технологических процессов;
УИ.37
УИ.37 Организация мониторинга статуса работ по устранению уязвимостей.
УИ.27
УИ.27 Регулярный****** анализ уязвимостей (сканирование на уязвимости) объектов информатизации инфраструктурного уровня, в том числе:
  • сканирование на уязвимости объектов информатизации, непосредственно взаимодействующих с сетью Интернет;
  • сканирование на уязвимости «внутренних» объектов информатизации, в том числе вычислительных сетей, на «границах» контуров безопасности.
УИ.30
УИ.30 Проведение сканирования на уязвимости и (или) тестирование на проникновение при существенных изменениях в критичной архитектуре и (или) внедрении новых объектов информатизации (автоматизированных систем).
УИ.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 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 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 
Requirement 2.2.1
2.2.1 
Defined Approach Requirements: 
Configuration standards are developed, implemented, and maintained to:
  • Cover all system components.
  • Address all known security vulnerabilities.
  • Be consistent with industry-accepted system hardening standards or vendor hardening recommendations.
  • Be updated as new vulnerability issues are identified, as defined in Requirement 6.3.1.
  • Be applied when new systems are configured and verified as in place before or immediately after a system component is connected to a production environment. 
Customized Approach Objective:
All system components are configured securely and consistently and in accordance with industryaccepted hardening standards or vendor recommendations. 

Defined Approach Testing Procedures:
  •  2.2.1.a Examine system configuration standards to verify they define processes that include all elements specified in this requirement. 
  • 2.2.1.b Examine policies and procedures and interview personnel to verify that system configuration standards are updated as new vulnerability issues are identified, as defined in Requirement 6.3.1. 
  • 2.2.1.c Examine configuration settings and interview personnel to verify that system configuration standards are applied when new systems are configured and verified as being in place before or immediately after a system component is connected to a production environment. 
Purpose:
There are known weaknesses with many operating systems, databases, network devices, software, applications, container images, and other devices used by an entity or within an entity’s environment. There are also known ways to configure these system components to fix security vulnerabilities. Fixing security vulnerabilities reduces the opportunities available to an attacker. 
By developing standards, entities ensure their system components will be configured consistently and securely, and address the protection of devices for which full hardening may be more difficult. 

Good Practice:
Keeping up to date with current industry guidance will help the entity maintain secure configurations. 
The specific controls to be applied to a system will vary and should be appropriate for the type and function of the system. 
Numerous security organizations have established system-hardening guidelines and recommendations, which advise how to correct common, known weaknesses. 

Further:
Information Sources for guidance on configuration standards include but are not limited to: Center for Internet Security (CIS), International Organization for Standardization (ISO), National Institute of Standards and Technology (NIST), Cloud Security Alliance, and product vendors. 

ГОСТ Р № ИСО/МЭК 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 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.
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 2.2.1
2.2.1
Определенные Требования к Подходу:
Стандарты конфигурации разрабатываются, внедряются и поддерживаются в соответствии с рекомендациями:
  • Охватите все компоненты системы.
  • Устраните все известные уязвимости в системе безопасности.
  • Должны соответствовать принятым в отрасли стандартам упрочнения систем или рекомендациям поставщиков по настройке.
  • Обновляться по мере выявления новых уязвимостей, как определено в требовании 6.3.1.
  • Может применяться при настройке и проверке работоспособности новых систем до или сразу после подключения системного компонента к производственной среде.
Цель Индивидуального подхода:
Все компоненты системы сконфигурированы надежно и последовательно в соответствии с принятыми в отрасли стандартами безопасности или рекомендациями поставщиков.

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

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

Дополнительная информация:
Источники информации для руководства по стандартам конфигурации включают, но не ограничиваются ими: Центр безопасности Интернета (CIS), Международная организация по стандартизации (ISO), Национальный институт стандартов и технологий (NIST), Альянс облачной безопасности и поставщики продуктов.
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
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. Банковские платежные агенты (субагенты), осуществляющие операции платежного агрегатора, должны на основе критериев, установленных операторами по переводу денежных средств, проводить тестирование на проникновение и анализ уязвимостей информационной безопасности объектов информационной инфраструктуры, сертификацию или оценку соответствия прикладного программного обеспечения автоматизированных систем и приложений.

Методика экспресс-оценки уровня кибербезопасности организации РезБез:
5.3.2.
Контроль устранения уязвимостей осуществляется на регулярной основе
5.3.1.1.
Контроль устранения уязвимостей осуществляется на регулярной основе и автоматизирован с помощью решения класса vulnerability management (VM)
SWIFT Customer Security Controls Framework v2022:
2 - 2.2 Security Updates
2.2 Security Updates
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):
PR.IP-12 PR.IP-12: A vulnerability management plan is developed and implemented
ID.RA-1 ID.RA-1: Asset vulnerabilities are identified and documented
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.
Положение Банка России № 716-П от 08.04.2022 "О требованиях к системе управления операционным риском в кредитной организации и банковской группе":
Глава 8. Пункт 8.7
8.8.7. Ежегодное тестирование уязвимостей информационных систем и (или) их компонентов и других источников риска информационных систем, а также разработка комплекса мероприятий, направленных на устранение выявленных уязвимостей информационных систем и (или) других источников риска информационных систем.