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

NIST Cybersecurity Framework (EN)

Framework

RS.MI-3

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

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

NIST Cybersecurity Framework (RU):
RS.MI-3
RS.MI-3: Вновь выявленные уязвимости смягчаются или документируются как принятые риски 
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ИНЦ.6 ИНЦ.6 Планирование и принятие мер по предотвращению повторного возникновения инцидентов
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 1.2.6
1.2.6 
Defined Approach Requirements: 
Security features are defined and implemented for all services, protocols, and ports that are in use and considered to be insecure, such that the risk is mitigated. 

Customized Approach Objective:
The specific risks associated with the use of insecure services, protocols, and ports are understood, assessed, and appropriately mitigated. 

Defined Approach Testing Procedures:
  • 1.2.6.a Examine documentation that identifies all insecure services, protocols, and ports in use to verify that for each, security features are defined to mitigate the risk.
  • 1.2.6.b Examine configuration settings for NSCs to verify that the defined security features are implemented for each identified insecure service, protocol, and port. 
Purpose:
Compromises take advantage of insecure network configurations. 

Good Practice:
If insecure services, protocols, or ports are necessary for business, the risk posed by these services, protocols, and ports should be clearly understood and accepted by the organization, the use of the service, protocol, or port should be justified, and the security features that mitigate the risk of using these services, protocols, and ports should be defined and implemented by the entity. 

Further Information:
For guidance on services, protocols, or ports considered to be insecure, refer to industry standards and guidance (for example, from NIST, ENISA, OWASP). 
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. 

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.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.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 1.2.6
1.2.6
Определенные Требования к Подходу:
Функции безопасности определяются и реализуются для всех служб, протоколов и портов, которые используются и считаются небезопасными, таким образом, чтобы снизить риск.

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

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

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

Дополнительная информация:
Для получения рекомендаций по службам, протоколам или портам, которые считаются небезопасными, обратитесь к отраслевым стандартам и рекомендациям (например, от NIST, ENISA, OWASP).
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), Альянс облачной безопасности и поставщики продуктов.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.8
А.8.8 Управление техническими уязвимостями
Должна своевременно получаться информация о технических уязвимостях используемых информационных систем, также должно оцениваться воздействие таких уязвимостей на организацию, и должны предприниматься соответствующие меры.
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ИНЦ.5 ИНЦ.5 Принятие мер по предотвращению повторного возникновения компьютерных инцидентов
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ИНЦ.5 ИНЦ.5 Принятие мер по предотвращению повторного возникновения компьютерных инцидентов
Стандарт № 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.

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

Ничего не найдено