Куда я попал?
NIST Cybersecurity Framework (EN)
Framework
ID.RA-5
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
ГОСТ Р № 57580.3-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Управление риском реализации информационных угроз и обеспечение операционной надежности. Общие положения.":
ОПР.1.5
ОПР.1.5 Порядок утверждения и условия пересмотра структуры и организации систем управления риском реализации информационных угроз, операционной надежности и защиты информации.
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 3
3. Кредитные организации с учетом требований главы 5 Положения Банка России N 716-П должны определить во внутренних документах для каждого технологического процесса и соблюдать значения следующих контрольных показателей уровня операционного риска для целей обеспечения операционной надежности (далее - целевые показатели операционной надежности):
- допустимого отношения общего количества банковских операций и иных операций, осуществляемых в рамках технологического процесса, совершенных во время нарушений технологических процессов, приводящих к неоказанию или ненадлежащему оказанию банковских услуг (далее - деградация технологического процесса (технологических процессов), в рамках события операционного риска или серии связанных событий операционного риска, вызванных информационными угрозами и (или) сбоями объектов информационной инфраструктуры, которые привели к неоказанию или ненадлежащему оказанию банковских услуг (далее - инцидент операционной надежности), к ожидаемому количеству банковских операций и иных операций, осуществляемых в рамках технологических процессов, за тот же период в случае непрерывного оказания банковских услуг, установленного кредитной организацией (далее - допустимая доля деградации технологического процесса);
- допустимого времени простоя и (или) деградации технологических процессов кредитных организаций в рамках инцидента операционной надежности (в случае превышения допустимой доли деградации технологического процесса). Значение данного целевого показателя устанавливается кредитной организацией не выше значений, предусмотренных приложением к настоящему Положению;
- допустимого суммарного времени простоя и (или) деградации технологического процесса кредитной организации (в случае превышения допустимой доли деградации технологического процесса) в течение очередного календарного года;
- показателя соблюдения режима работы (функционирования) технологического процесса (времени начала, времени окончания, продолжительности и последовательности процедур в рамках технологического процесса).
Значение допустимой доли деградации технологических процессов должно рассчитываться кредитной организацией на основании статистических данных за период не менее двенадцати календарных месяцев, предшествующих дате определения значения целевого показателя операционной надежности, за исключением случая, предусмотренного абзацем седьмым настоящего пункта, и (или) иных данных, обосновывающих их определение (по выбору кредитной организации).
В случае если технологический процесс функционирует менее двенадцати календарных месяцев, кредитные организации должны определять значение допустимой доли деградации технологических процессов на основании статистических данных за период с даты начала его функционирования и (или) иных данных, обосновывающих их определение (по выбору кредитной организации).
NIST Cybersecurity Framework (RU):
ID.RA-5
ID.RA-5: Угрозы, уязвимости, вероятности и воздействия используются для определения риска
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
УИ.4
УИ.4 Привлечение службы ИБ, а также, при необходимости, иных подразделений, формирующих «вторую линию защиты», в рамках процесса управления изменениями для:
- выявления и идентификации риска реализации информационных угроз;
- участия в разработке мероприятий, направленных на уменьшение негативного влияния от выявленного и идентифицированного риска реализации информационных угроз;
- контроля за реализацией мероприятий, направленных на уменьшение негативного влияния от выявленного и идентифицированного риска реализации информационных угроз.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 11.3.2.1
11.3.2.1
Defined Approach Requirements:
External vulnerability scans are performed after any significant change as follows:
Defined Approach Requirements:
External vulnerability scans are performed after any significant change as follows:
- Vulnerabilities that are scored 4.0 or higher by the CVSS are resolved.
- Rescans are conducted as needed.
- Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV).
Customized Approach Objective:
The security posture of all system components is verified following significant changes to the network or systems, by using tools designed to detect vulnerabilities operating from outside the network. Detected vulnerabilities are assessed and rectified based on a formal risk assessment framework.
Defined Approach Testing Procedures:
The security posture of all system components is verified following significant changes to the network or systems, by using tools designed to detect vulnerabilities operating from outside the network. Detected vulnerabilities are assessed and rectified based on a formal risk assessment framework.
Defined Approach Testing Procedures:
- 11.3.2.1.a Examine change control documentation and external scan reports to verify that system components were scanned after any significant changes.
- 11.3.2.1.b Interview personnel and examine external scan and rescan reports to verify that external scans were performed after significant changes and that vulnerabilities scored 4.0 or higher by the CVSS were resolved.
- 11.3.2.1.c Interview personnel to verify that external scans are performed by a qualified internal resource(s) or qualified external third party and that organizational independence of the tester exists.
Purpose:
Scanning an environment after any significant changes ensures that changes were completed appropriately such that the security of the environment was not compromised because of the change.
Good Practice:
Entities should include the need to perform scans after significant changes as part of the change process and before the change is considered complete. All system components affected by the change will need to be scanned.
Scanning an environment after any significant changes ensures that changes were completed appropriately such that the security of the environment was not compromised because of the change.
Good Practice:
Entities should include the need to perform scans after significant changes as part of the change process and before the change is considered complete. All system components affected by the change will need to be scanned.
Requirement 11.3.2
11.3.2
Defined Approach Requirements:
External vulnerability scans are performed as follows:
Defined Approach Requirements:
External vulnerability scans are performed as follows:
- At least once every three months.
- By a PCI SSC Approved Scanning Vendor (ASV).
- Vulnerabilities are resolved and ASV Program Guide requirements for a passing scan are met.
- Rescans are performed as needed to confirm that vulnerabilities are resolved per the ASV Program Guide requirements for a passing scan.
Customized Approach Objective:
This requirement is not eligible for the customized approach.
Applicability Notes:
For initial PCI DSS compliance, it is not required that four passing scans be completed within 12 months if the assessor verifies: 1) the most recent scan result was a passing scan, 2) the entity has documented policies and procedures requiring scanning at least once every three months, and 3) vulnerabilities noted in the scan results have been corrected as shown in a re-scan(s).
However, for subsequent years after the initial PCI DSS assessment, passing scans at least every three months must have occurred.
ASV scanning tools can scan a vast array of network types and topologies. Any specifics about the target environment (for example, load balancers, third-party providers, ISPs, specific configurations, protocols in use, scan interference) should be worked out between the ASV and scan customer.
Refer to the ASV Program Guide published on the PCI SSC website for scan customer responsibilities, scan preparation, etc.
Defined Approach Testing Procedures:
This requirement is not eligible for the customized approach.
Applicability Notes:
For initial PCI DSS compliance, it is not required that four passing scans be completed within 12 months if the assessor verifies: 1) the most recent scan result was a passing scan, 2) the entity has documented policies and procedures requiring scanning at least once every three months, and 3) vulnerabilities noted in the scan results have been corrected as shown in a re-scan(s).
However, for subsequent years after the initial PCI DSS assessment, passing scans at least every three months must have occurred.
ASV scanning tools can scan a vast array of network types and topologies. Any specifics about the target environment (for example, load balancers, third-party providers, ISPs, specific configurations, protocols in use, scan interference) should be worked out between the ASV and scan customer.
Refer to the ASV Program Guide published on the PCI SSC website for scan customer responsibilities, scan preparation, etc.
Defined Approach Testing Procedures:
- 11.3.2.a Examine ASV scan reports from the last 12 months to verify that external vulnerability scans occurred at least once every three months in the most recent 12-month period.
- 11.3.2.b Examine the ASV scan report from each scan and rescan run in the last 12 months to verify that vulnerabilities are resolved and the ASV Program Guide requirements for a passing scan are met.
- 11.3.2.c Examine the ASV scan reports to verify that the scans were completed by a PCI SSC Approved Scanning Vendor (ASV).
Purpose:
Attackers routinely look for unpatched or vulnerable externally facing servers, which can be leveraged to launch a directed attack. Organizations must ensure these externally facing devices are regularly scanned for weaknesses and that vulnerabilities are patched or remediated to protect the entity.
Because external networks are at greater risk of compromise, external vulnerability scanning must be performed at least once every three months by a PCI SSC Approved Scanning Vendor (ASV).
Good Practice:
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.
Multiple scan reports can be combined to show that all systems were scanned and that all applicable vulnerabilities were resolved as part of the three-month vulnerability scan cycle. However, additional documentation may be required to verify non-remediated vulnerabilities are in the process of being resolved.
Attackers routinely look for unpatched or vulnerable externally facing servers, which can be leveraged to launch a directed attack. Organizations must ensure these externally facing devices are regularly scanned for weaknesses and that vulnerabilities are patched or remediated to protect the entity.
Because external networks are at greater risk of compromise, external vulnerability scanning must be performed at least once every three months by a PCI SSC Approved Scanning Vendor (ASV).
Good Practice:
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.
Multiple scan reports can be combined to show that all systems were scanned and that all applicable vulnerabilities were resolved as part of the three-month vulnerability scan cycle. However, additional documentation may be required to verify non-remediated vulnerabilities are in the process of being resolved.
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:
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:
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.
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.
Guideline for a healthy information system v.2.0 (EN):
41 STANDARD
/STANDARD
Each organization develops within a complex computing environment specific to itself. As such, any position taken or action plan involving the information system security must be considered in light of the risks foreseen by the management. Whether it is organisational or technical measures, their implementation represents a cost for the organization, which needs to ensure that they are able to reduce an identified risk to an acceptable level.
In the most sensitive cases, the risk analysis may call into question certain previous choices. This may be the case if the probability of an event appearing and its potential consequences prove critical for the organization and there is no preventive action to control it.
The recommended approach consists, in broad terms, of defining the context, assessing the risks and dealing with them. The risk assessment generally works by considering two areas: the likelihood and the impacts. This is then followed by the creation of a risk treatment plan to be validated by a designated authority at a higher level.
Three kinds of approach can be considered to control the risks associated with the information system:
In the most sensitive cases, the risk analysis may call into question certain previous choices. This may be the case if the probability of an event appearing and its potential consequences prove critical for the organization and there is no preventive action to control it.
The recommended approach consists, in broad terms, of defining the context, assessing the risks and dealing with them. The risk assessment generally works by considering two areas: the likelihood and the impacts. This is then followed by the creation of a risk treatment plan to be validated by a designated authority at a higher level.
Three kinds of approach can be considered to control the risks associated with the information system:
- the recourse to best IT security practices;
- a systematic risk analysis based on feedback from users;
- a structured risk management formalised by a dedicated methodology.
In this last case, the EBIOS method referenced by ANSSI is recommended. It is able to write down security needs, identify the security objectives and determine the security demands
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.12.6.1
A.12.6.1 Процесс управления техническими уязвимостями
Мера обеспечения информационной безопасности: Должна быть своевременно получена информация о технических уязвимостях используемых информационных систем, оценена подверженность организации таким уязвимостям, и должны быть приняты соответствующие меры в отношении связанного с этим риска информационной безопасности
Мера обеспечения информационной безопасности: Должна быть своевременно получена информация о технических уязвимостях используемых информационных систем, оценена подверженность организации таким уязвимостям, и должны быть приняты соответствующие меры в отношении связанного с этим риска информационной безопасности
A.16.1.6
A.16.1.6 Анализ инцидентов информационной безопасности
Мера обеспечения информационной безопасности: Знания, приобретенные в результате анализа и урегулирования инцидентов информационной безопасности, должны использоваться для уменьшения вероятности или влияния будущих инцидентов
Мера обеспечения информационной безопасности: Знания, приобретенные в результате анализа и урегулирования инцидентов информационной безопасности, должны использоваться для уменьшения вероятности или влияния будущих инцидентов
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 3.7
CSC 3.7 Utilize a Risk-Rating Process
Utilize a risk-rating process to prioritize the remediation of discovered vulnerabilities.
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.2.1
11.3.2.1
Определенные Требования к Подходу:
Проверка внешних уязвимостей выполняется после любого существенного изменения следующим образом:
Определенные Требования к Подходу:
Проверка внешних уязвимостей выполняется после любого существенного изменения следующим образом:
- Уязвимости, получившие оценку CVSS 4.0 или выше, устраняются.
- Повторные сканирования проводятся по мере необходимости.
- Сканирование выполняется квалифицированным персоналом, и существует организационная независимость тестировщика (не обязательно быть QSA или ASV).
Цель Индивидуального подхода:
Состояние безопасности всех компонентов системы проверяется после значительных изменений в сети или системах с помощью инструментов, предназначенных для обнаружения уязвимостей, действующих извне сети. Обнаруженные уязвимости оцениваются и устраняются на основе формальной системы оценки рисков.
Определенные Процедуры Тестирования Подхода:
Состояние безопасности всех компонентов системы проверяется после значительных изменений в сети или системах с помощью инструментов, предназначенных для обнаружения уязвимостей, действующих извне сети. Обнаруженные уязвимости оцениваются и устраняются на основе формальной системы оценки рисков.
Определенные Процедуры Тестирования Подхода:
- 11.3.2.1.a Изучите документацию по контролю изменений и отчеты о внешнем сканировании, чтобы убедиться, что компоненты системы были проверены после любых существенных изменений.
- 11.3.2.1.b Опросите персонал и изучите отчеты о внешнем сканировании и повторном сканировании, чтобы убедиться, что внешнее сканирование было выполнено после значительных изменений и что уязвимости, оцененные CVSS 4.0 или выше, были устранены.
- 11.3.2.1.c Опросить персонал, чтобы убедиться, что внешние проверки выполняются квалифицированным внутренним ресурсом (ресурсами) или квалифицированной внешней третьей стороной и что существует организационная независимость тестировщика.
Цель:
Сканирование среды после любых существенных изменений гарантирует, что изменения были выполнены надлежащим образом, чтобы безопасность среды не была нарушена из-за изменений.
Надлежащая практика:
Объекты должны включать необходимость выполнения сканирования после существенных изменений как часть процесса изменения и до того, как изменение будет считаться завершенным. Необходимо будет просканировать все системные компоненты, затронутые этим изменением.
Сканирование среды после любых существенных изменений гарантирует, что изменения были выполнены надлежащим образом, чтобы безопасность среды не была нарушена из-за изменений.
Надлежащая практика:
Объекты должны включать необходимость выполнения сканирования после существенных изменений как часть процесса изменения и до того, как изменение будет считаться завершенным. Необходимо будет просканировать все системные компоненты, затронутые этим изменением.
Requirement 11.3.1.1
11.3.1.1
Определенные Требования к Подходу:
Все другие применимые уязвимости (те, которые не классифицируются как высокорисковые или критические в соответствии с ранжированием рисков уязвимости организации, определенным в требовании 6.3.1) управляются следующим образом:
Определенные Требования к Подходу:
Все другие применимые уязвимости (те, которые не классифицируются как высокорисковые или критические в соответствии с ранжированием рисков уязвимости организации, определенным в требовании 6.3.1) управляются следующим образом:
- Рассматриваются на основе риска, определенного в целевом анализе рисков организации, который выполняется в соответствии со всеми элементами, указанными в Требовании 12.3.1.
- Повторные сканирования проводятся по мере необходимости.
Цель Индивидуального подхода:
Уязвимости с более низким рейтингом (ниже высокого или критического) устраняются с определенной периодичностью в соответствии с риском организации.
Примечания по применению:
Временные рамки для устранения уязвимостей с низким уровнем риска зависят от результатов анализа рисков в соответствии с требованием 12.3.1, которое включает (минимально) идентификацию защищаемых активов, угроз и вероятности и/или воздействия реализуемой угрозы.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
Уязвимости с более низким рейтингом (ниже высокого или критического) устраняются с определенной периодичностью в соответствии с риском организации.
Примечания по применению:
Временные рамки для устранения уязвимостей с низким уровнем риска зависят от результатов анализа рисков в соответствии с требованием 12.3.1, которое включает (минимально) идентификацию защищаемых активов, угроз и вероятности и/или воздействия реализуемой угрозы.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
- 11.3.1.1.a Изучите целевой анализ рисков организации, который определяет риск для устранения всех других применимых уязвимостей (тех, которые не классифицируются как высокорисковые или критические в соответствии с рейтингом рисков уязвимости организации в Требовании 6.3.1), чтобы убедиться, что анализ рисков был выполнен в соответствии со всеми элементами, указанными в Требовании 12.3.1.
- 11.3.1.1.b Опросите ответственный персонал и изучите результаты отчета о внутреннем сканировании или другую документацию, чтобы убедиться, что все другие применимые уязвимости (те, которые не классифицируются как высокорисковые или критические в соответствии с рейтингом рисков уязвимости организации в соответствии с требованием 6.3.1) устранены на основе риска, определенного в целевом анализе рисков организации, и что процесс сканирования включает повторное сканирование по мере необходимости для подтверждения устранения уязвимостей.
Цель:
Все уязвимости, независимо от их критичности, представляют собой потенциальный путь атаки и поэтому должны периодически устраняться, при этом уязвимости, которые представляют наибольший риск, устраняются быстрее, чтобы ограничить потенциальное окно атаки.
Все уязвимости, независимо от их критичности, представляют собой потенциальный путь атаки и поэтому должны периодически устраняться, при этом уязвимости, которые представляют наибольший риск, устраняются быстрее, чтобы ограничить потенциальное окно атаки.
Requirement 11.3.2
11.3.2
Определенные Требования к Подходу:
Проверка внешних уязвимостей выполняется следующим образом:
Определенные Требования к Подходу:
Проверка внешних уязвимостей выполняется следующим образом:
- По крайней мере, раз в три месяца.
- Поставщиком сканирования, одобренным PCI SSC (ASV).
- Уязвимости устранены, и требования Руководства по программе ASV для прохождения проверки выполнены.
- Повторное сканирование выполняется по мере необходимости, чтобы подтвердить, что уязвимости устранены в соответствии с требованиями Руководства по программе ASV для проходящего сканирования.
Цель Индивидуального подхода:
Это требование не подходит для индивидуального подхода.
Примечания по применению:
Для первоначального соответствия требованиям PCI DSS не требуется, чтобы в течение 12 месяцев было выполнено четыре проходных сканирования, если оценщик проверяет: 1) самым последним результатом сканирования было проходное сканирование, 2) организация имеет задокументированные политики и процедуры, требующие проверки не реже одного раза в три месяца, и 3) уязвимости, отмеченные в результаты сканирования были исправлены, как показано в повторном сканировании (-ах).
Однако в последующие годы после первоначальной оценки PCI DSS необходимо проходить сканирование не реже одного раза в три месяца.
Инструменты сканирования ASV могут сканировать широкий спектр типов и топологий сетей. Любые особенности целевой среды (например, балансировщики нагрузки, сторонние поставщики, интернет-провайдеры, конкретные конфигурации, используемые протоколы, помехи при сканировании) должны быть согласованы между ASV и клиентом сканирования.
Обратитесь к Руководству по программе ASV, опубликованному на веб-сайте PCI SSC, для получения информации об обязанностях клиента сканирования, подготовке к сканированию и т.д.
Определенные Процедуры Тестирования Подхода:
Это требование не подходит для индивидуального подхода.
Примечания по применению:
Для первоначального соответствия требованиям PCI DSS не требуется, чтобы в течение 12 месяцев было выполнено четыре проходных сканирования, если оценщик проверяет: 1) самым последним результатом сканирования было проходное сканирование, 2) организация имеет задокументированные политики и процедуры, требующие проверки не реже одного раза в три месяца, и 3) уязвимости, отмеченные в результаты сканирования были исправлены, как показано в повторном сканировании (-ах).
Однако в последующие годы после первоначальной оценки PCI DSS необходимо проходить сканирование не реже одного раза в три месяца.
Инструменты сканирования ASV могут сканировать широкий спектр типов и топологий сетей. Любые особенности целевой среды (например, балансировщики нагрузки, сторонние поставщики, интернет-провайдеры, конкретные конфигурации, используемые протоколы, помехи при сканировании) должны быть согласованы между ASV и клиентом сканирования.
Обратитесь к Руководству по программе ASV, опубликованному на веб-сайте PCI SSC, для получения информации об обязанностях клиента сканирования, подготовке к сканированию и т.д.
Определенные Процедуры Тестирования Подхода:
- 11.3.2.a Изучите отчеты о проверке ASV за последние 12 месяцев, чтобы убедиться, что проверка внешних уязвимостей проводилась не реже одного раза в три месяца в течение последнего 12-месячного периода.
- 11.3.2.b Изучите отчет о проверке ASV после каждого сканирования и повторного сканирования, выполненного за последние 12 месяцев, чтобы убедиться, что уязвимости устранены и требования Руководства по программе ASV для прохождения проверки выполнены.
- 11.3.2.c Изучите отчеты о сканировании ASV, чтобы убедиться, что сканирование было выполнено Поставщиком сканирования, одобренным PCI SSC (ASV).
Цель:
Злоумышленники обычно ищут незащищенные или уязвимые внешние серверы, которые можно использовать для проведения направленной атаки. Организации должны убедиться, что эти внешние устройства регулярно проверяются на наличие слабых мест и что уязвимости исправляются или устраняются для защиты организации.
Поскольку внешние сети подвергаются большему риску компрометации, проверка внешних уязвимостей должна выполняться по крайней мере раз в три месяца поставщиком сканирования, одобренным PCI SSC (ASV).
Надлежащая практика:
Хотя проверки требуются не реже одного раза в три месяца, рекомендуется проводить более частые проверки в зависимости от сложности сети, частоты изменений и типов используемых устройств, программного обеспечения и операционных систем.
Можно объединить несколько отчетов о проверке, чтобы показать, что все системы были проверены и что все применимые уязвимости были устранены в рамках трехмесячного цикла проверки уязвимостей. Однако может потребоваться дополнительная документация для подтверждения того, что не устраненные уязвимости находятся в процессе устранения.
Злоумышленники обычно ищут незащищенные или уязвимые внешние серверы, которые можно использовать для проведения направленной атаки. Организации должны убедиться, что эти внешние устройства регулярно проверяются на наличие слабых мест и что уязвимости исправляются или устраняются для защиты организации.
Поскольку внешние сети подвергаются большему риску компрометации, проверка внешних уязвимостей должна выполняться по крайней мере раз в три месяца поставщиком сканирования, одобренным PCI SSC (ASV).
Надлежащая практика:
Хотя проверки требуются не реже одного раза в три месяца, рекомендуется проводить более частые проверки в зависимости от сложности сети, частоты изменений и типов используемых устройств, программного обеспечения и операционных систем.
Можно объединить несколько отчетов о проверке, чтобы показать, что все системы были проверены и что все применимые уязвимости были устранены в рамках трехмесячного цикла проверки уязвимостей. Однако может потребоваться дополнительная документация для подтверждения того, что не устраненные уязвимости находятся в процессе устранения.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.8
А.8.8 Управление техническими уязвимостями
Должна своевременно получаться информация о технических уязвимостях используемых информационных систем, также должно оцениваться воздействие таких уязвимостей на организацию, и должны предприниматься соответствующие меры.
Должна своевременно получаться информация о технических уязвимостях используемых информационных систем, также должно оцениваться воздействие таких уязвимостей на организацию, и должны предприниматься соответствующие меры.
SWIFT Customer Security Controls Framework v2022:
7 - 7.4A Scenario Risk Assessment
7.4A Scenario Risk Assessment
Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":
п. 1.3.
1.3. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны определить во внутренних документах для каждого осуществляемого ими технологического процесса, указанного в приложении к настоящему Положению, значения следующих целевых показателей операционной надежности:
- допустимого отношения общего количества финансовых операций, совершенных во время деградации технологического процесса в рамках события операционного риска или серии связанных событий операционного риска, вызванных информационными угрозами, которые привели к неоказанию или ненадлежащему оказанию финансовых услуг (далее - события операционного риска, связанные с нарушением операционной надежности), к ожидаемому количеству финансовых операций за тот же период в случае непрерывного оказания финансовых услуг (далее - доля деградации технологических процессов);
- допустимого времени простоя и (или) деградации технологического процесса в рамках события операционного риска, связанного с нарушением операционной надежности (в случае превышения допустимой доли деградации технологического процесса), не выше порогового уровня, установленного в приложении к настоящему Положению;
- допустимого суммарного времени простоя и (или) деградации технологического процесса (в случае превышения допустимой доли деградации технологического процесса) в течение последних двенадцати календарных месяцев к первому числу каждого календарного месяца;
- показателя соблюдения режима работы (функционирования) технологического процесса (времени начала, времени окончания, продолжительности и последовательности процедур в рамках технологического процесса).
Значение допустимой доли деградации технологических процессов должно рассчитываться некредитной финансовой организацией, обязанной соблюдать усиленный, стандартный или минимальный уровень защиты информации, на основании статистических данных за период не менее двенадцати календарных месяцев, предшествующих дате определения значения целевого показателя операционной надежности, за исключением случая, предусмотренного абзацем седьмым настоящего пункта, и (или) иных данных, обосновывающих их определение (по выбору некредитной финансовой организации).
В случае если технологический процесс функционирует менее двенадцати календарных месяцев, некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, должны определять значение допустимой доли деградации технологических процессов на основании статистических данных за период с даты начала его функционирования и (или) иных данных, обосновывающих их определение (по выбору некредитной финансовой организации).
В случае превышения допустимой доли деградации технологических процессов некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, должны обеспечить фиксацию:
- фактического времени простоя и (или) деградации технологического процесса, исчисляемого по каждому событию операционного риска, связанному с нарушением операционной надежности (с момента нарушения технологического процесса по причине реализации события операционного риска, связанного с нарушением операционной надежности, до момента восстановления выполнения технологического процесса);
- фактической доли деградации технологического процесса, исчисляемой по каждому событию операционного риска, связанному с нарушением операционной надежности;
- суммарного времени простоя и (или) деградации технологического процесса за последние двенадцать календарных месяцев, предшествующих событию операционного риска, связанному с нарушением операционной надежности.
При определении времени простоя и (или) деградации технологических процессов в расчет не включаются периоды времени проведения плановых технологических операций, связанных с приостановлением (частичным приостановлением) технологических процессов.
Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, должны обеспечить контроль за соблюдением значений целевых показателей операционной надежности.
Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, должны не реже одного раза в год проводить анализ необходимости пересмотра значений целевых показателей операционной надежности, по итогам которого указанные некредитные финансовые организации должны пересмотреть значения целевых показателей операционной надежности либо принять мотивированное решение об отсутствии необходимости в пересмотре указанных значений.
В случае если законодательством Российской Федерации, регулирующим деятельность некредитных финансовых организаций, обязанных соблюдать усиленный, стандартный или минимальный уровень защиты информации, установлена обязательность наличия у них системы управления рисками, указанные некредитные финансовые организации должны выполнять требования настоящего пункта в рамках системы управления рисками.
Стандарт № 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.
Связанные защитные меры
| Название | Дата | Влияние | ||
|---|---|---|---|---|
|
Community
48 / 170
|
Внедрение процесса управления рисками информационной безопасности
Вручную
Организационная
Детективная
08.05.2022
|
08.05.2022 | 48 / 170 |