Куда я попал?
Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014
Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения
Р. 7 п. 3 п.п. 9
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 8":
РОН.1
РОН.1 Реализация эксплуатации (в том числе использования по назначению) технических мер обеспечения операционной надежности.
КОН.3
КОН.3 Периодический контроль (тестирование) полноты реализации технических мер обеспечения операционной надежности.
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 6. п.п. 2
6.2. Кредитные организации должны обеспечивать выполнение следующих требований к управлению изменениями критичной архитектуры:
- управление уязвимостями в критичной архитектуре, из-за которых могут реализоваться информационные угрозы и которые могут повлечь превышение значений целевых показателей операционной надежности;
- планирование и внедрение изменений в критичной архитектуре, направленных на обеспечение недопустимости неоказания или ненадлежащего оказания банковских услуг;
- управление конфигурациями (настраиваемыми параметрами) объектов информационной инфраструктуры;
- управление уязвимостями и обновлениями (исправлениями) объектов информационной инфраструктуры.
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
УИ.18.1
УИ.18.1 Контроля и выявления несанкционированного изменения текущих конфигураций объектов информатизации, а также их несоответствия стандартам конфигурирования;
УИ.6.4
УИ.6.4 Контроля отсутствия известных (описанных) уязвимостей объектов информатизации.
УИ.6.1
УИ.6.1 Контроля соответствия заявленным целям внесения изменений;
УИ.6.2
УИ.6.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:
Defined Approach Requirements:
Internal vulnerability scans are performed as follows:
- At least once every three months.
- High-risk and critical vulnerabilities (per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved.
- Rescans are performed that confirm all highrisk and critical vulnerabilities (as noted above) have been resolved.
- Scan tool is kept up to date with latest vulnerability information.
- Scans are performed by qualified personnel and organizational independence of the tester exists.
Customized Approach Objective:
The security posture of all system components is verified periodically using automated tools designed to detect vulnerabilities operating inside the network. Detected vulnerabilities are assessed and rectified based on a formal risk assessment framework
Applicability Notes:
It is not required to use a QSA or ASV to conduct internal vulnerability scans.
Internal vulnerability scans can be performed by qualified, internal staff that are reasonably independent of the system component(s) being scanned (for example, a network administrator should not be responsible for scanning the network), or an entity may choose to have internal vulnerability scans performed by a firm specializing in vulnerability scanning.
Defined Approach Testing Procedures:
The security posture of all system components is verified periodically using automated tools designed to detect vulnerabilities operating inside the network. Detected vulnerabilities are assessed and rectified based on a formal risk assessment framework
Applicability Notes:
It is not required to use a QSA or ASV to conduct internal vulnerability scans.
Internal vulnerability scans can be performed by qualified, internal staff that are reasonably independent of the system component(s) being scanned (for example, a network administrator should not be responsible for scanning the network), or an entity may choose to have internal vulnerability scans performed by a firm specializing in vulnerability scanning.
Defined Approach Testing Procedures:
- 11.3.1.a Examine internal scan report results from the last 12 months to verify that internal scans occurred at least once every three months in the most recent 12-month period.
- 11.3.1.b Examine internal scan report results from each scan and rescan run in the last 12 months to verify that all high-risk and critical vulnerabilities (identified in PCI DSS Requirement 6.3.1) are resolved.
- 11.3.1.c Examine scan tool configurations and interview personnel to verify that the scan tool is kept up to date with the latest vulnerability information.
- 11.3.1.d Interview responsible personnel to verify that the scan was performed by a qualified internal resource(s) or qualified external third party and that organizational independence of the tester exists.
Purpose:
Identifying and addressing vulnerabilities promptly reduces the likelihood of a vulnerability being exploited and the potential compromise of a system component or cardholder data. Vulnerability scans conducted at least every three months provide this detection and identification.
Good Practice:
Vulnerabilities posing the greatest risk to the environment (for example, ranked high or critical per Requirement 6.3.1) should be resolved with the highest priority.
Multiple scan reports can be combined for the quarterly scan process to show that all systems were scanned and all applicable vulnerabilities were resolved as part of the three-month vulnerability scan cycle. However, additional, documentation may be required to verify nonremediated vulnerabilities are in the process of being resolved.
While scans are required at least once every three months, more frequent scans are recommended depending on the network complexity, frequency of change, and types of devices, software, and operating systems used.
Definitions:
A vulnerability scan is a combination of automated tools, techniques, and/or methods run against external and internal devices and servers, designed to expose potential vulnerabilities in applications, operating systems, and network devices that could be found and exploited by malicious individuals.
Identifying and addressing vulnerabilities promptly reduces the likelihood of a vulnerability being exploited and the potential compromise of a system component or cardholder data. Vulnerability scans conducted at least every three months provide this detection and identification.
Good Practice:
Vulnerabilities posing the greatest risk to the environment (for example, ranked high or critical per Requirement 6.3.1) should be resolved with the highest priority.
Multiple scan reports can be combined for the quarterly scan process to show that all systems were scanned and all applicable vulnerabilities were resolved as part of the three-month vulnerability scan cycle. However, additional, documentation may be required to verify nonremediated vulnerabilities are in the process of being resolved.
While scans are required at least once every three months, more frequent scans are recommended depending on the network complexity, frequency of change, and types of devices, software, and operating systems used.
Definitions:
A vulnerability scan is a combination of automated tools, techniques, and/or methods run against external and internal devices and servers, designed to expose potential vulnerabilities in applications, operating systems, and network devices that could be found and exploited by malicious individuals.
Requirement 6.3.3
6.3.3
Defined Approach Requirements:
All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows:
Defined Approach Requirements:
All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows:
- Critical or high-security patches/updates (identified according to the risk ranking process at Requirement 6.3.1) are installed within one month of release.
- All other applicable security patches/updates are installed within an appropriate time frame as determined by the entity (for example, within three months of release).
Customized Approach Objective:
System components cannot be compromised via the exploitation of a known vulnerability.
Defined Approach Testing Procedures:
System components cannot be compromised via the exploitation of a known vulnerability.
Defined Approach Testing Procedures:
- 6.3.3.a Examine policies and procedures to verify processes are defined for addressing vulnerabilities by installing applicable security patches/updates in accordance with all elements specified in this requirement.
- 6.3.3.b Examine system components and related software and compare the list of installed security patches/updates to the most recent security patch/update information to verify vulnerabilities are addressed in accordance with all elements specified in this requirement.
Purpose:
New exploits are constantly being discovered, and these can permit attacks against systems that have previously been considered secure. If the most recent security patches/updates are not implemented on critical systems as soon as possible, a malicious actor can use these exploits to attack or disable a system or gain access to sensitive data.
Good Practice:
Prioritizing security patches/updates for critical infrastructure ensures that high-priority systems and devices are protected from vulnerabilities as soon as possible after a patch is released.
An entity’s patching cadence should factor in any re-evaluation of vulnerabilities and subsequent changes in the criticality of a vulnerability per Requirement 6.3.1. 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.
New exploits are constantly being discovered, and these can permit attacks against systems that have previously been considered secure. If the most recent security patches/updates are not implemented on critical systems as soon as possible, a malicious actor can use these exploits to attack or disable a system or gain access to sensitive data.
Good Practice:
Prioritizing security patches/updates for critical infrastructure ensures that high-priority systems and devices are protected from vulnerabilities as soon as possible after a patch is released.
An entity’s patching cadence should factor in any re-evaluation of vulnerabilities and subsequent changes in the criticality of a vulnerability per Requirement 6.3.1. 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.
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:
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).
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 2.2.1
2.2.1
Defined Approach Requirements:
Configuration standards are developed, implemented, and maintained to:
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:
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.
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.
Guideline for a healthy information system v.2.0 (EN):
38 STANDARD
/STANDARD
Carrying out regular audits (at least once per year) of the information system is essential as this makes it possible to correctly assess the effectiveness of measures implemented and their maintenance over time. These controls and audits are also able to measure the gaps that may remain between the theory and the practice.
They can be carried out by possible internal audit teams or by specialised external companies. Depending on the scope to test, technical and/or organisational audits will be carried out by the professionals called upon. These audits are especially necessary as the organization must comply with the regulations and legal obligations directly linked to its activities.
Following these audits, corrective actions must be identified, their application planned and monitoring points organised at regular intervals. For higher efficiency, indicators on the state of progress of the action plan may be integrated into the overview for the management.
Although security audits participate in the security of the information system by being able to show possible vulnerabilities, they are never proof of their absence and therefore do not negate the need for other control measures.
Carrying out regular audits (at least once per year) of the information system is essential as this makes it possible to correctly assess the effectiveness of measures implemented and their maintenance over time. These controls and audits are also able to measure the gaps that may remain between the theory and the practice.
They can be carried out by possible internal audit teams or by specialised external companies. Depending on the scope to test, technical and/or organisational audits will be carried out by the professionals called upon. These audits are especially necessary as the organization must comply with the regulations and legal obligations directly linked to its activities.
Following these audits, corrective actions must be identified, their application planned and monitoring points organised at regular intervals. For higher efficiency, indicators on the state of progress of the action plan may be integrated into the overview for the management.
Although security audits participate in the security of the information system by being able to show possible vulnerabilities, they are never proof of their absence and therefore do not negate the need for other control measures.
34 STANDARD
/STANDARD
New flaws are regularly discovered at the heart of systems and software. These are generally access doors that a hacker can exploit for a successful intrusion into the information system. It is, therefore, vital to stay informed of new vulnerabilities (follow CERT- FR alerts) and to apply the corrective security actions over all of the components of the system within the month following their publication. An update policy must therefore be defined and be a part of operational procedures.
These must specify:
New flaws are regularly discovered at the heart of systems and software. These are generally access doors that a hacker can exploit for a successful intrusion into the information system. It is, therefore, vital to stay informed of new vulnerabilities (follow CERT- FR alerts) and to apply the corrective security actions over all of the components of the system within the month following their publication. An update policy must therefore be defined and be a part of operational procedures.
These must specify:
- the way in which the inventory of the information system components is carried out;
- the sources of information relating to the publication of updates;
- the tools to deploy the corrective actions over the stock (for examples WSUS for updates for Microsoft components, free or paid tools for third party components and other operating systems);
- the possible qualification of corrective measure and their gradual deployement over the stock.
The obsolete components which are no longer supported by their manufacturers must be isolated from the rest of the system. This recommendation applies as much on the network level, by strict filtering of flows, as it does as regards the authentication secrets which must be dedicated to these systems.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.17.2.1
A.17.2.1 Доступность средств обработки информации
Мера обеспечения информационной безопасности: Средства обработки информации должны быть внедрены с учетом резервирования, достаточного для выполнения требований доступности
Мера обеспечения информационной безопасности: Средства обработки информации должны быть внедрены с учетом резервирования, достаточного для выполнения требований доступности
A.12.6.1
A.12.6.1 Процесс управления техническими уязвимостями
Мера обеспечения информационной безопасности: Должна быть своевременно получена информация о технических уязвимостях используемых информационных систем, оценена подверженность организации таким уязвимостям, и должны быть приняты соответствующие меры в отношении связанного с этим риска информационной безопасности
Мера обеспечения информационной безопасности: Должна быть своевременно получена информация о технических уязвимостях используемых информационных систем, оценена подверженность организации таким уязвимостям, и должны быть приняты соответствующие меры в отношении связанного с этим риска информационной безопасности
A.14.2.3
A.14.2.3 Техническая экспертиза приложений (прикладных программ) после изменений операционной платформы
Мера обеспечения информационной безопасности: При внесении изменений в операционные платформы критически важные для бизнеса приложения должны быть проверены и протестированы, чтобы обеспечить уверенность в отсутствии неблагоприятного воздействия на деятельность или безопасность организации
Мера обеспечения информационной безопасности: При внесении изменений в операционные платформы критически важные для бизнеса приложения должны быть проверены и протестированы, чтобы обеспечить уверенность в отсутствии неблагоприятного воздействия на деятельность или безопасность организации
A.17.1.3
A.17.1.3 Проверка, анализ и оценивание непрерывности информационной безопасности
Мера обеспечения информационной безопасности: Организация должна регулярно проверять установленные и реализованные меры обеспечения непрерывности информационной безопасности, чтобы обеспечить уверенность в их актуальности и эффективности при возникновении неблагоприятных ситуаций
Мера обеспечения информационной безопасности: Организация должна регулярно проверять установленные и реализованные меры обеспечения непрерывности информационной безопасности, чтобы обеспечить уверенность в их актуальности и эффективности при возникновении неблагоприятных ситуаций
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 6.3.3
6.3.3
Определенные Требования к Подходу:
Все компоненты системы защищены от известных уязвимостей путем установки соответствующих исправлений/обновлений безопасности следующим образом:
Определенные Требования к Подходу:
Все компоненты системы защищены от известных уязвимостей путем установки соответствующих исправлений/обновлений безопасности следующим образом:
- Критические или высокозащищенные исправления/обновления (идентифицированные в соответствии с процессом ранжирования рисков в требовании 6.3.1) устанавливаются в течение одного месяца после выпуска.
- Все другие применимые исправления/обновления безопасности устанавливаются в течение соответствующего периода времени, определенного организацией (например, в течение трех месяцев после выпуска).
Цель Индивидуального подхода:
Компоненты системы не могут быть скомпрометированы путем использования известной уязвимости.
Определенные Процедуры Тестирования Подхода:
Компоненты системы не могут быть скомпрометированы путем использования известной уязвимости.
Определенные Процедуры Тестирования Подхода:
- 6.3.3.a Изучить политики и процедуры для проверки того, определены ли процессы для устранения уязвимостей путем установки соответствующих исправлений/обновлений безопасности в соответствии со всеми элементами, указанными в этом требовании.
- 6.3.3.b Изучите системные компоненты и связанное с ними программное обеспечение и сравните список установленных исправлений/обновлений безопасности с самой последней информацией об исправлениях/обновлениях безопасности, чтобы убедиться, что уязвимости устранены в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Постоянно обнаруживаются новые эксплойты, которые могут позволить проводить атаки на системы, ранее считавшиеся безопасными. Если самые последние исправления/обновления безопасности не будут внедрены в критические системы как можно скорее, злоумышленник может использовать эти эксплойты для атаки или отключения системы или получения доступа к конфиденциальным данным.
Надлежащая практика:
Приоритизация исправлений/обновлений безопасности для критической инфраструктуры гарантирует, что высокоприоритетные системы и устройства будут защищены от уязвимостей как можно скорее после выпуска исправления.
Частота исправлений организации должна учитывать любую переоценку уязвимостей и последующие изменения критичности уязвимости в соответствии с требованием 6.3.1. Например, уязвимость, первоначально идентифицированная как низкая степень риска, позже может стать более высокой степенью риска. Кроме того, уязвимости, которые по отдельности считаются уязвимостями низкого или среднего риска, могут в совокупности представлять высокий или критический риск, если они присутствуют в одной и той же системе или если они используются в системе с низким уровнем риска, что может привести к доступу к CDE.
Постоянно обнаруживаются новые эксплойты, которые могут позволить проводить атаки на системы, ранее считавшиеся безопасными. Если самые последние исправления/обновления безопасности не будут внедрены в критические системы как можно скорее, злоумышленник может использовать эти эксплойты для атаки или отключения системы или получения доступа к конфиденциальным данным.
Надлежащая практика:
Приоритизация исправлений/обновлений безопасности для критической инфраструктуры гарантирует, что высокоприоритетные системы и устройства будут защищены от уязвимостей как можно скорее после выпуска исправления.
Частота исправлений организации должна учитывать любую переоценку уязвимостей и последующие изменения критичности уязвимости в соответствии с требованием 6.3.1. Например, уязвимость, первоначально идентифицированная как низкая степень риска, позже может стать более высокой степенью риска. Кроме того, уязвимости, которые по отдельности считаются уязвимостями низкого или среднего риска, могут в совокупности представлять высокий или критический риск, если они присутствуют в одной и той же системе или если они используются в системе с низким уровнем риска, что может привести к доступу к CDE.
Requirement 11.3.1
11.3.1
Определенные Требования к Подходу:
Проверка внутренних уязвимостей выполняется следующим образом:
Определенные Требования к Подходу:
Проверка внутренних уязвимостей выполняется следующим образом:
- По крайней мере, раз в три месяца.
- Устраняются уязвимости высокого риска и критические уязвимости (в соответствии с ранжированием рисков уязвимости организации, определенным в требовании 6.3.1).
- Выполняется повторное сканирование, которое подтверждает, что все уязвимости с высоким уровнем риска и критические уязвимости (как отмечено выше) были устранены.
- Средство сканирования постоянно обновляется с последней информацией об уязвимостях.
- Сканирование выполняется квалифицированным персоналом, и существует организационная независимость тестировщика.
Цель Индивидуального подхода:
Состояние безопасности всех компонентов системы периодически проверяется с помощью автоматизированных инструментов, предназначенных для обнаружения уязвимостей, действующих внутри сети. Обнаруженные уязвимости оцениваются и устраняются на основе формальной системы оценки рисков
Примечания по применению:
Для проведения внутреннего сканирования уязвимостей не требуется использовать QSA или ASV.
Внутреннее сканирование уязвимостей может выполняться квалифицированным внутренним персоналом, который разумно независим от проверяемого системного компонента (компонентов) (например, сетевой администратор не должен нести ответственность за сканирование сети), или организация может выбрать, чтобы внутреннее сканирование уязвимостей выполнялось фирмой, специализирующейся на сканировании уязвимостей.
Определенные Процедуры Тестирования Подхода:
Состояние безопасности всех компонентов системы периодически проверяется с помощью автоматизированных инструментов, предназначенных для обнаружения уязвимостей, действующих внутри сети. Обнаруженные уязвимости оцениваются и устраняются на основе формальной системы оценки рисков
Примечания по применению:
Для проведения внутреннего сканирования уязвимостей не требуется использовать QSA или ASV.
Внутреннее сканирование уязвимостей может выполняться квалифицированным внутренним персоналом, который разумно независим от проверяемого системного компонента (компонентов) (например, сетевой администратор не должен нести ответственность за сканирование сети), или организация может выбрать, чтобы внутреннее сканирование уязвимостей выполнялось фирмой, специализирующейся на сканировании уязвимостей.
Определенные Процедуры Тестирования Подхода:
- 11.3.1.a Изучите результаты отчета о внутреннем сканировании за последние 12 месяцев, чтобы убедиться, что внутренние проверки проводились не реже одного раза в три месяца в течение последнего 12-месячного периода.
- 11.3.1.b Изучите результаты отчета о внутреннем сканировании после каждого сканирования и повторного сканирования за последние 12 месяцев, чтобы убедиться, что все уязвимости высокого риска и критические уязвимости (определенные в требовании PCI DSS 6.3.1) устранены.
- 11.3.1.c Изучите конфигурации средства сканирования и опросите персонал, чтобы убедиться, что средство сканирования обновляется с учетом последней информации об уязвимостях.
- 11.3.1.d Опросите ответственный персонал, чтобы убедиться, что сканирование было выполнено квалифицированным внутренним ресурсом (ресурсами) или квалифицированной внешней третьей стороной и что существует организационная независимость тестировщика.
Цель:
Быстрое выявление и устранение уязвимостей снижает вероятность использования уязвимости и потенциальной компрометации системного компонента или данных о держателях карт. Сканирование уязвимостей, проводимое не реже одного раза в три месяца, обеспечивает такое обнаружение и идентификацию.
Надлежащая практика:
Уязвимости, представляющие наибольший риск для окружающей среды (например, имеющие высокий или критический рейтинг в соответствии с требованием 6.3.1), должны быть устранены с наивысшим приоритетом.
Несколько отчетов о проверке можно объединить для ежеквартального процесса проверки, чтобы показать, что все системы были проверены и все применимые уязвимости были устранены в рамках трехмесячного цикла проверки уязвимостей. Однако может потребоваться дополнительная документация для подтверждения того, что устраняемые уязвимости находятся в процессе устранения.
Хотя проверки требуются не реже одного раза в три месяца, рекомендуется проводить более частые проверки в зависимости от сложности сети, частоты изменений и типов используемых устройств, программного обеспечения и операционных систем.
Определения:
Проверка на уязвимость - это комбинация автоматизированных инструментов, методов и/или методов, выполняемых против внешних и внутренних устройств и серверов, предназначенных для выявления потенциальных уязвимостей в приложениях, операционных системах и сетевых устройствах, которые могут быть обнаружены и использованы злоумышленниками.
Быстрое выявление и устранение уязвимостей снижает вероятность использования уязвимости и потенциальной компрометации системного компонента или данных о держателях карт. Сканирование уязвимостей, проводимое не реже одного раза в три месяца, обеспечивает такое обнаружение и идентификацию.
Надлежащая практика:
Уязвимости, представляющие наибольший риск для окружающей среды (например, имеющие высокий или критический рейтинг в соответствии с требованием 6.3.1), должны быть устранены с наивысшим приоритетом.
Несколько отчетов о проверке можно объединить для ежеквартального процесса проверки, чтобы показать, что все системы были проверены и все применимые уязвимости были устранены в рамках трехмесячного цикла проверки уязвимостей. Однако может потребоваться дополнительная документация для подтверждения того, что устраняемые уязвимости находятся в процессе устранения.
Хотя проверки требуются не реже одного раза в три месяца, рекомендуется проводить более частые проверки в зависимости от сложности сети, частоты изменений и типов используемых устройств, программного обеспечения и операционных систем.
Определения:
Проверка на уязвимость - это комбинация автоматизированных инструментов, методов и/или методов, выполняемых против внешних и внутренних устройств и серверов, предназначенных для выявления потенциальных уязвимостей в приложениях, операционных системах и сетевых устройствах, которые могут быть обнаружены и использованы злоумышленниками.
Requirement 1.2.6
1.2.6
Определенные Требования к Подходу:
Функции безопасности определяются и реализуются для всех служб, протоколов и портов, которые используются и считаются небезопасными, таким образом, чтобы снизить риск.
Цель Индивидуального подхода:
Конкретные риски, связанные с использованием небезопасных служб, протоколов и портов, понимаются, оцениваются и соответствующим образом смягчаются.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Функции безопасности определяются и реализуются для всех служб, протоколов и портов, которые используются и считаются небезопасными, таким образом, чтобы снизить риск.
Цель Индивидуального подхода:
Конкретные риски, связанные с использованием небезопасных служб, протоколов и портов, понимаются, оцениваются и соответствующим образом смягчаются.
Определенные Процедуры Тестирования Подхода:
- 1.2.6.a Изучите документацию, в которой указаны все используемые небезопасные службы, протоколы и порты, чтобы убедиться, что для каждого из них определены функции безопасности для снижения риска.
- 1.2.6.b Изучите параметры конфигурации для NSCS, чтобы убедиться, что определенные функции безопасности реализованы для каждой идентифицированной небезопасной службы, протокола и порта.
Цель:
Компрометируются небезопасные сетевые конфигурации.
Надлежащая практика:
Если для бизнеса необходимы небезопасные службы, протоколы или порты, организация должна четко понимать и принимать риски, связанные с этими службами, протоколами и портами. Использование службы, протокола или порта должно быть оправдано, а функции безопасности, которые снижают риск использования этих служб, протоколов и портов должны быть определены и реализованы организацией.
Дополнительная информация:
Для получения рекомендаций по службам, протоколам или портам, которые считаются небезопасными, обратитесь к отраслевым стандартам и рекомендациям (например, от NIST, ENISA, OWASP).
Компрометируются небезопасные сетевые конфигурации.
Надлежащая практика:
Если для бизнеса необходимы небезопасные службы, протоколы или порты, организация должна четко понимать и принимать риски, связанные с этими службами, протоколами и портами. Использование службы, протокола или порта должно быть оправдано, а функции безопасности, которые снижают риск использования этих служб, протоколов и портов должны быть определены и реализованы организацией.
Дополнительная информация:
Для получения рекомендаций по службам, протоколам или портам, которые считаются небезопасными, обратитесь к отраслевым стандартам и рекомендациям (например, от 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), Альянс облачной безопасности и поставщики продуктов.
Известны уязвимости многих операционных систем, баз данных, сетевых устройств, программного обеспечения, приложений, образов контейнеров и других устройств, используемых организацией или в среде организации. Существуют также известные способы настройки этих системных компонентов для устранения уязвимостей. Устранение уязвимостей уменьшает возможности, доступные злоумышленнику.
Разрабатывая стандарты, организации гарантируют, что их системные компоненты будут сконфигурированы последовательно и надежно, и обеспечивают защиту устройств, для которых полная защита может быть более сложной.
Надлежащая практика:
Соответствие текущим отраслевым рекомендациям поможет организации поддерживать безопасные конфигурации.
Конкретные средства управления, которые будут применяться к системе, будут различаться и должны соответствовать типу и функциям системы.
Многочисленные организации, занимающиеся вопросами безопасности, разработали руководящие принципы и рекомендации по настройкам системы, в которых содержится информация о том, как исправить известные недостатки.
Дополнительная информация:
Источники информации для руководства по стандартам конфигурации включают, но не ограничиваются ими: Центр безопасности Интернета (CIS), Международная организация по стандартизации (ISO), Национальный институт стандартов и технологий (NIST), Альянс облачной безопасности и поставщики продуктов.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.30
А.5.30 Готовность ИКТ к непрерывности бизнеса
Доступность ИКТ должна планироваться, внедряться, поддерживаться и тестироваться на основании целей обеспечения непрерывности бизнеса, а также требований к обеспечению непрерывности ИКТ.
Доступность ИКТ должна планироваться, внедряться, поддерживаться и тестироваться на основании целей обеспечения непрерывности бизнеса, а также требований к обеспечению непрерывности ИКТ.
А.8.8
А.8.8 Управление техническими уязвимостями
Должна своевременно получаться информация о технических уязвимостях используемых информационных систем, также должно оцениваться воздействие таких уязвимостей на организацию, и должны предприниматься соответствующие меры.
Должна своевременно получаться информация о технических уязвимостях используемых информационных систем, также должно оцениваться воздействие таких уязвимостей на организацию, и должны предприниматься соответствующие меры.
SWIFT Customer Security Controls Framework v2022:
2 - 2.2 Security Updates
2.2 Security Updates
2 - 2.7 Vulnerability Scanning
2.7 Vulnerability Scanning
Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":
п. 1.5.
1.5. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны обеспечивать выполнение следующих требований в отношении управления изменениями критичной архитектуры:
- управление уязвимостями в критичной архитектуре, с использованием которых могут реализоваться информационные угрозы и которые могут повлечь отклонение от значений целевых показателей операционной надежности, указанных в пункте 1.3 настоящего Положения;
- планирование и внедрение изменений в критичной архитектуре, направленных на обеспечение непрерывного оказания финансовых услуг;
- управление конфигурациями объектов информационной инфраструктуры некредитных финансовых организаций;
- управление уязвимостями и обновлениями (исправлениями) объектов информационной инфраструктуры некредитных финансовых организаций.
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
17.2.1
17.2.1 Доступность средств обработки информации
Мера обеспечения ИБ
Средства обработки информации должны быть внедрены с учетом резервирования, достаточного для выполнения требований доступности.
Руководство по применению
Организации должны определить требования бизнеса к доступности информационных систем. В тех случаях, когда доступность не может быть обеспечена существующей системной архитектурой, следует рассмотреть возможность добавления избыточности компонентам и архитектуре.
Там, где это применимо, обеспечивающие избыточность информационные системы должны быть проверены для гарантии того, что переключение с одного компонента на другой функционирует должным образом.
Дополнительная информация
Внедрение избыточности может порождать риски нарушения целостности или конфиденциальности информации и информационных систем. Их необходимо учитывать при проектировании информационных систем.
12.6.1
В ответ на выявление потенциальных технических уязвимостей должны быть предприняты надлежащие и своевременные действия. Необходимо придерживаться следующих указаний для создания эффективного процесса управления техническими уязвимостями:
12.6.1 Процесс управления техническими уязвимостями
Мера обеспечения ИБ
Должна быть своевременно получена информация о технических уязвимостях используемых информационных систем, оценена подверженность организации таким уязвимостям и приняты соответствующие меры в отношении связанного с этим риска ИБ.
Руководство по применению
Актуальный и полный перечень активов (раздел 8) является необходимым условием для эффективного управления техническими уязвимостями. Специальная информация, необходимая для поддержки управления техническими уязвимостями, включает в себя информацию о поставщике программного обеспечения, номерах версий, текущем состоянии развертывания (например, какое программное обеспечение установлено в каких системах) и работниках, ответственных за программное обеспечение в организации.
В ответ на выявление потенциальных технических уязвимостей должны быть предприняты надлежащие и своевременные действия. Необходимо придерживаться следующих указаний для создания эффективного процесса управления техническими уязвимостями:
- a) организация должна определить и установить роли и обязанности, связанные с управлением техническими уязвимостями, включая их мониторинг, оценку риска, исправление ошибок, отслеживание активов и любые необходимые обязанности по координации процесса;
- b) для программного обеспечения и других технологий (на основе перечня активов, см. 8.1.1) следует идентифицировать информационные ресурсы, которые будут использоваться для выявления соответствующих технических уязвимостей и поддержания осведомленности о них; эти информационные ресурсы должны обновляться в соответствии с изменениями в перечне активов или при обнаружении новых и полезных ресурсов;
- c) следует определить сроки реагирования на уведомления о потенциально значимых технических уязвимостях;
- d) после выявления потенциальной технической уязвимости организация должна определить связанные с ней риски и действия, которые необходимо предпринять; такие действия могут включать применение пакетов исправлений к уязвимым системам или применение компенсирующих мер обеспечения ИБ;
- e) в зависимости от того, насколько срочно необходимо устранить техническую уязвимость, предпринимаемые действия должны проводиться в соответствии с мерами по управлению изменениями (см. 12.1.2) или в соответствии с процедурами реагирования на инциденты ИБ (см. 16.1.5);
- f) если доступно официальное исправление, следует оценить риски, связанные с его установкой (риски, связанные с уязвимостью, следует сравнить с рисками, которые могут возникнуть вследствие установки исправления);
- g) пакеты исправлений должны быть проверены и оценены до их установки, чтобы быть уверенным в том, что они не приведут к недопустимым побочным эффектам; если исправлений не выпущено, следует рассмотреть иные меры обеспечения информационной безопасности, такие как:
- отключение сервисов и возможностей, связанных с уязвимостью;
- настройка или добавление мер контроля доступа, например межсетевые экраны на границах сети (см. 13.1);
- усиление мониторинга для выявления реальных атак;
- повышение осведомленности об уязвимостях;
- h) следует вести журнал всех предпринятых действий;
- i) процесс управления техническими уязвимостями следует регулярно контролировать и оценивать для обеспечения его эффективности и результативности;
- j) в первую очередь следует обращать внимание на системы с высоким уровнем риска;
- k) эффективный процесс управления техническими уязвимостями должен быть согласован с действиями по управлению инцидентами, что позволит передавать данные об уязвимостях группе реагирования на инциденты и дополнит процесс техническими процедурами, которые должны быть выполнены в случае инцидента;
- l) необходимо определить процедуру для решения ситуации, когда уязвимость была выявлена, но подходящих мер еще не существует. В этой ситуации организация должна оценить риски, связанные с известной уязвимостью, и определить соответствующие действия по обнаружению и корректировке.
Дополнительная информация
Управление техническими уязвимостями может рассматриваться как подфункция процесса управления изменениями и, как следствие, может использовать преимущества процессов и процедур управления изменениями (см. 12.1.2 и 14.2.2).
Производители часто испытывают на себе значительное давление, заключающееся в требовании выпускать пакеты исправлений как можно скорее. Следовательно существует вероятность того, что исправление не решает проблему должным образом и имеет отрицательные побочные эффекты. Кроме того, в некоторых случаях после применения исправления его удаление может оказаться проблематичным.
Если адекватное тестирование исправлений невозможно, например из-за затрат или нехватки ресурсов, то следует рассмотреть возможность задержки его применения и оценить связанные с этим риски, основываясь на опыте, полученном от других пользователей. Может оказаться полезным использование ИСО/МЭК 27031 [14].
17.1.3
17.1.3 Проверка, анализ и оценивание непрерывности информационной безопасности
Мера обеспечения ИБ
Организация должна регулярно проверять установленные и реализованные меры по обеспечению непрерывности ИБ, чтобы обеспечить уверенность в их актуальности и эффективности при возникновении неблагоприятных ситуаций.
Руководство по применению
Организационные, технические, процедурные изменения или изменения в процессах как в контексте эксплуатации, так и непрерывности, могут привести к изменениям требований непрерывности ИБ. В таких случаях непрерывность процессов, процедур и мер обеспечения ИБ должна быть проанализирована с точки зрения изменений в требованиях.
Организации должны проверять непрерывность менеджмента ИБ путем:
- a) осуществления и тестирования функциональности процессов, процедур и мер непрерывности ИБ для гарантии их соответствия целям обеспечения непрерывности ИБ;
- b) осуществления и тестирования осведомленности и порядка управления процессами, процедурами и мерами непрерывности ИБ для гарантии того, что их выполнение соответствует целям обеспечения непрерывности ИБ;
- c) анализа пригодности и эффективности мер непрерывности ИБ при изменении информационных систем, процессов, процедур и мер обеспечения ИБ или процессов и решений менеджмента непрерывности бизнеса/восстановления после аварий.
Дополнительная информация
Проверка мер непрерывности ИБ отличается от общей проверки ИБ и должна проводиться вне рамок тестирования изменений. По возможности желательно интегрировать проверку мер непрерывности ИБ в проверку непрерывности бизнеса организации или проверку восстановления после аварийной ситуации.
14.2.3
14.2.3 Техническая экспертиза приложений (прикладных программ) после изменений операционной платформы
Мера обеспечения ИБ
При внесении изменений в операционные платформы критически важные для бизнеса приложения должны быть проверены и протестированы, чтобы обеспечить уверенность в отсутствии неблагоприятного воздействия на деятельность или безопасность организации.
Руководство по применению
Этот процесс должен охватывать:
- a) пересмотр мер защиты приложения и процедур целостности для гарантии того, что они не будут нарушены изменениями в эксплуатируемой среде;
- b) обеспечение своевременного уведомления об изменениях эксплуатируемой платформы с учетом времени проведения соответствующих тестов и проверки перед внедрением;
- c) обеспечение внесения соответствующих изменений в планы обеспечения непрерывности бизнеса (раздел 17).
Дополнительная информация
Эксплуатируемые платформы включают в себя операционные системы, базы данных и связующее программное обеспечение. Меры обеспечения ИБ также должны применяться для процесса изменения приложений.
Стандарт № 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.
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.
А.5.30
А.5.30 ICT readiness for business continuity
ICT readiness shall be planned, implemented, maintained and tested based on business continuity objectives and ICT continuity requirements.
ICT readiness shall be planned, implemented, maintained and tested based on business continuity objectives and ICT continuity requirements.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.