Куда я попал?
SWIFT Customer Security Controls Framework v2022
Framework
7 - 7.1 Cyber Incident Response Planning
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
7.1 Cyber Incident Response PlanningОбязательно для типа архитектуры A1 A2 A3 A4 BОбласть требования: Юридическая структура
Похожие требования
CIS Critical Security Controls v8 (The 18 CIS CSC):
17.4
17.4 Establish and Maintain an Incident Response Process
Establish and maintain an incident response process that addresses roles and responsibilities, compliance requirements, and a communication plan. Review annually, or when significant enterprise changes occur that could impact this Safeguard.
Establish and maintain an incident response process that addresses roles and responsibilities, compliance requirements, and a communication plan. Review annually, or when significant enterprise changes occur that could impact this Safeguard.
ГОСТ Р № 57580.3-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Управление риском реализации информационных угроз и обеспечение операционной надежности. Общие положения.":
ОПР.5.1
ОПР.5.1 В целях обеспечения ИБ:
- разработка и (или) пересмотр внутренних документов в области обеспечения операционной надежности и защиты информации;
- планирование, реализация (в том числе установление требований) и контроль процессов обеспечения операционной надежности и защиты информации;
- разработка предложений по совершенствованию процессов обеспечения операционной надежности и защиты информации (по результатам анализа необходимости совершенствования систем управления, определяемых в рамках семейств стандартов ОН и ЗИ);
- выявление и фиксация инцидентов, в том числе обнаружение реализации компьютерных атак и выявление фактов (индикаторов) компрометации объектов информатизации;
- формирование отчетности по вопросам обеспечения операционной надежности и защиты информации, направляемой на рассмотрение коллегиальному исполнительному органу, должностному лицу, ответственному за функционирование системы управления риском реализации информационных угроз, а также иным должностным лицам, в случае наличия соответствующих требований во внутренних документах финансовой организации или требований нормативных актов Банка России;
- осуществление других функций, связанных с реализаций процессов обеспечения операционной надежности и защиты информации, предусмотренных внутренними документами финансовой организации
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 6. п.п. 3
6.3. Кредитные организации должны обеспечивать выполнение следующих требований к выявлению, регистрации инцидентов операционной надежности и реагированию на них, а также восстановлению выполнения технологических процессов и функционирования объектов информационной инфраструктуры после реализации таких инцидентов:
- выявление и регистрация инцидентов операционной надежности;
- реагирование на инциденты операционной надежности в отношении критичной архитектуры;
- восстановление функционирования технологических процессов и объектов информационной инфраструктуры после реализации инцидентов операционной надежности;
- проведение анализа причин и последствий реализации инцидентов операционной надежности;
- организация взаимодействия между подразделениями кредитной организации, а также между кредитной организацией и Банком России, иными участниками технологического процесса в рамках реагирования на инциденты операционной надежности и восстановления выполнения технологических процессов и функционирования объектов информационной инфраструктуры после реализации инцидентов операционной надежности.
NIST Cybersecurity Framework (RU):
PR.IP-9
PR.IP-9: Созданы и управляются планы реагирования (реагирование на инциденты и непрерывность бизнеса) и планы восстановления (восстановление после инцидентов и аварийное восстановление)
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ИНЦ.3
ИНЦ.3 Своевременное информирование лиц, ответственных за выявление инцидентов и реагирование на них, о возникновении инцидентов в информационной системе пользователями и администраторами
ИНЦ.6
ИНЦ.6 Планирование и принятие мер по предотвращению повторного возникновения инцидентов
ИНЦ.4
ИНЦ.4 Анализ инцидентов, в том числе определение источников и причин возникновения инцидентов, а также оценка их последствий
ИНЦ.5
ИНЦ.5 Принятие мер по устранению последствий инцидентов
ИНЦ.1
ИНЦ.1 Определение лиц, ответственных за выявление инцидентов и реагирование на них
ИНЦ.2
ИНЦ.2 Обнаружение, идентификация и регистрация инцидентов
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
ВПУ.2
ВПУ.2 Разработка и применение процедур реагирования в случае реализации информационных угроз, в том числе компьютерных атак со стороны поставщиков услуг, а также в случае идентификации риска распространения вредоносного кода на вычислительные сети финансовой организации*.
ВРВ.16.1
ВРВ.16.1 Оперативное устранение или ограничение воздействия источников и причин реализации инцидентов;
ВРВ.7.2
ВРВ.7.2 Методологии проведения предварительной оценки потенциала влияния (критичности) инцидента, включая его классификацию согласно типовому перечню и классификационным признакам;
ВРВ.27
ВРВ.27 Организация и выполнение деятельности в рамках восстановления функционирования бизнес- и технологических процессов и объектов информатизации после реализации инцидентов согласно утвержденным*** правилам и процедурам (playbooks).
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
17.4
17.4 Реализован и поддерживается процесс ответа на сообщения об инцидентах
Процесс включает роли и обязанности, показатели работы и план коммуникации по поводу инцидента.
Процесс включает роли и обязанности, показатели работы и план коммуникации по поводу инцидента.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 10.4.3
10.4.3
Defined Approach Requirements:
Exceptions and anomalies identified during the review process are addressed.
Customized Approach Objective:
Suspicious or anomalous activities are addressed.
Defined Approach Testing Procedures:
Defined Approach Requirements:
Exceptions and anomalies identified during the review process are addressed.
Customized Approach Objective:
Suspicious or anomalous activities are addressed.
Defined Approach Testing Procedures:
- 10.4.3.a Examine security policies and procedures to verify that processes are defined for addressing exceptions and anomalies identified during the review process.
- 10.4.3.b Observe processes and interview personnel to verify that, when exceptions and anomalies are identified, they are addressed.
Purpose:
If exceptions and anomalies identified during the log-review process are not investigated, the entity may be unaware of unauthorized and potentially malicious activities occurring within their network.
Good Practice:
Entities should consider how to address the following when developing their processes for defining and managing exceptions and anomalies:
If exceptions and anomalies identified during the log-review process are not investigated, the entity may be unaware of unauthorized and potentially malicious activities occurring within their network.
Good Practice:
Entities should consider how to address the following when developing their processes for defining and managing exceptions and anomalies:
- How log review activities are recorded, • How to rank and prioritize exceptions and anomalies,
- What procedures should be in place to report and escalate exceptions and anomalies, and
- Who is responsible for investigating and for any remediation tasks.
Requirement 10.7.2
10.7.2
Defined Approach Requirements:
Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems:
Defined Approach Requirements:
Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems:
- Network security controls.
- IDS/IPS.
- Change-detection mechanisms.
- Anti-malware solutions.
- Physical access controls.
- Logical access controls.
- Audit logging mechanisms.
- Segmentation controls (if used).
- Audit log review mechanisms.
- Automated security testing tools (if used).
Customized Approach Objective:
Failures in critical security control systems are promptly identified and addressed.
Applicability Notes:
This requirement applies to all entities, including service providers, and will supersede Requirement 10.7.1 as of 31 March 2025. It includes two additional critical security control systems not in Requirement 10.7.1.
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:
Failures in critical security control systems are promptly identified and addressed.
Applicability Notes:
This requirement applies to all entities, including service providers, and will supersede Requirement 10.7.1 as of 31 March 2025. It includes two additional critical security control systems not in Requirement 10.7.1.
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:
- 10.7.2.a Examine documentation to verify that processes are defined for the prompt detection and addressing of failures of critical security control systems, including but not limited to failure of all elements specified in this requirement.
- 10.7.2.b Observe detection and alerting processes and interview personnel to verify that failures of critical security control systems are detected and reported, and that failure of a critical security control results in the generation of an alert.
Purpose:
Without formal processes to detect and alert when critical security controls fail, failures may go undetected for extended periods and provide attackers ample time to compromise system components and steal account data from the CDE.
Good Practice:
The specific types of failures may vary, depending on the function of the device system component and technology in use. However, typical failures include a system no longer performing its security function or not functioning in its intended manner—for example, a firewall erasing its rules or going offline.
Without formal processes to detect and alert when critical security controls fail, failures may go undetected for extended periods and provide attackers ample time to compromise system components and steal account data from the CDE.
Good Practice:
The specific types of failures may vary, depending on the function of the device system component and technology in use. However, typical failures include a system no longer performing its security function or not functioning in its intended manner—for example, a firewall erasing its rules or going offline.
Requirement 12.10.6
12.10.6
Defined Approach Requirements:
The security incident response plan is modified and evolved according to lessons learned and to incorporate industry developments.
Customized Approach Objective:
The effectiveness and accuracy of the incident response plan is reviewed and updated after each invocation.
Defined Approach Testing Procedures:
Defined Approach Requirements:
The security incident response plan is modified and evolved according to lessons learned and to incorporate industry developments.
Customized Approach Objective:
The effectiveness and accuracy of the incident response plan is reviewed and updated after each invocation.
Defined Approach Testing Procedures:
- 12.10.6.a Examine policies and procedures to verify that processes are defined to modify and evolve the security incident response plan according to lessons learned and to incorporate industry developments.
- 12.10.6.b Examine the security incident response plan and interview responsible personnel to verify that the incident response plan is modified and evolved according to lessons learned and to incorporate industry developments.
Purpose:
Incorporating lessons learned into the incident response plan after an incident occurs and in-step with industry developments, helps keep the plan current and able to react to emerging threats and security trends.
Good Practice:
The lessons-learned exercise should include all levels of personnel. Although it is often included as part of the review of the entire incident, it should focus on how the entity’s response to the incident could be improved.
It is important to not just consider elements of the response that did not have the planned outcomes but also to understand what worked well and whether lessons from those elements that worked well can be applied areas of the plan that didn’t.
Another way to optimize an entity’s incident response plan is to understand the attacks made against other organizations and use that information to fine-tune the entity’s detection, containment, mitigation, or recovery procedures.
Incorporating lessons learned into the incident response plan after an incident occurs and in-step with industry developments, helps keep the plan current and able to react to emerging threats and security trends.
Good Practice:
The lessons-learned exercise should include all levels of personnel. Although it is often included as part of the review of the entire incident, it should focus on how the entity’s response to the incident could be improved.
It is important to not just consider elements of the response that did not have the planned outcomes but also to understand what worked well and whether lessons from those elements that worked well can be applied areas of the plan that didn’t.
Another way to optimize an entity’s incident response plan is to understand the attacks made against other organizations and use that information to fine-tune the entity’s detection, containment, mitigation, or recovery procedures.
Requirement 12.10.2
12.10.2
Defined Approach Requirements:
At least once every 12 months, the security incident response plan is:
Defined Approach Requirements:
At least once every 12 months, the security incident response plan is:
- Reviewed and the content is updated as needed.
- Tested, including all elements listed in Requirement 12.10.1.
Customized Approach Objective:
The incident response plan is kept current and tested periodically.
Defined Approach Testing Procedures:
The incident response plan is kept current and tested periodically.
Defined Approach Testing Procedures:
- 12.10.2 Interview personnel and review documentation to verify that, at least once every 12 months, the security incident response plan is:
- Reviewed and updated as needed.
- Tested, including all elements listed in Requirement 12.10.1.
Purpose:
Proper testing of the security incident response plan can identify broken business processes and ensure key steps are not missed, which could result in increased exposure during an incident. Periodic testing of the plan ensures that the processes remain viable, as well as ensuring that all relevant personnel in the organization are familiar with the plan.
Good Practice:
The test of the incident response plan can include simulated incidents and the corresponding responses in the form of a “table-top exercise”, that include participation by relevant personnel. A review of the incident and the quality of the response can provide entities with the assurance that all required elements are included in the plan.
Proper testing of the security incident response plan can identify broken business processes and ensure key steps are not missed, which could result in increased exposure during an incident. Periodic testing of the plan ensures that the processes remain viable, as well as ensuring that all relevant personnel in the organization are familiar with the plan.
Good Practice:
The test of the incident response plan can include simulated incidents and the corresponding responses in the form of a “table-top exercise”, that include participation by relevant personnel. A review of the incident and the quality of the response can provide entities with the assurance that all required elements are included in the plan.
Requirement 12.10.1
12.10.1
Defined Approach Requirements:
An incident response plan exists and is ready to be activated in the event of a suspected or confirmed security incident. The plan includes, but is not limited to:
Defined Approach Requirements:
An incident response plan exists and is ready to be activated in the event of a suspected or confirmed security incident. The plan includes, but is not limited to:
- Roles, responsibilities, and communication and contact strategies in the event of a suspected or confirmed security incident, including notification of payment brands and acquirers, at a minimum.
- Incident response procedures with specific containment and mitigation activities for different types of incidents.
- Business recovery and continuity procedures.
- Data backup processes.
- Analysis of legal requirements for reporting compromises.
- Coverage and responses of all critical system components.
- Reference or inclusion of incident response procedures from the payment brands.
Customized Approach Objective:
A comprehensive incident response plan that meets card brand expectations is maintained.
Defined Approach Testing Procedures:
A comprehensive incident response plan that meets card brand expectations is maintained.
Defined Approach Testing Procedures:
- 12.10.1.a Examine the incident response plan to verify that the plan exists and includes at least the elements specified in this requirement.
- 12.10.1.b Interview personnel and examine documentation from previously reported incidents or alerts to verify that the documented incident response plan and procedures were followed.
Purpose:
Without a comprehensive incident response plan that is properly disseminated, read, and understood by the parties responsible, confusion and lack of a unified response could create further downtime for the business, unnecessary public media exposure, as well as risk of financial and/or reputational loss and legal liabilities.
Good Practice:
The incident response plan should be thorough and contain all the key elements for stakeholders (for example, legal, communications) to allow the entity to respond effectively in the event of a breach that could impact account data. It is important to keep the plan up to date with current contact information of all individuals designated as having a role in incident response. Other relevant parties for notifications may include customers, financial institutions (acquirers and issuers), and business partners.
Entities should consider how to address all compromises of data within the CDE in their incident response plans, including to account data, wireless encryption keys, encryption keys used for transmission and storage or account data or cardholder data, etc.
Examples:
Legal requirements for reporting compromises include those in most US states, the EU General Data Protection Regulation (GDPR), and the Personal Data Protection Act (Singapore).
Further Information:
For more information, refer to the NIST SP 800- 61 Rev. 2, Computer Security Incident Handling Guide.
Without a comprehensive incident response plan that is properly disseminated, read, and understood by the parties responsible, confusion and lack of a unified response could create further downtime for the business, unnecessary public media exposure, as well as risk of financial and/or reputational loss and legal liabilities.
Good Practice:
The incident response plan should be thorough and contain all the key elements for stakeholders (for example, legal, communications) to allow the entity to respond effectively in the event of a breach that could impact account data. It is important to keep the plan up to date with current contact information of all individuals designated as having a role in incident response. Other relevant parties for notifications may include customers, financial institutions (acquirers and issuers), and business partners.
Entities should consider how to address all compromises of data within the CDE in their incident response plans, including to account data, wireless encryption keys, encryption keys used for transmission and storage or account data or cardholder data, etc.
Examples:
Legal requirements for reporting compromises include those in most US states, the EU General Data Protection Regulation (GDPR), and the Personal Data Protection Act (Singapore).
Further Information:
For more information, refer to the NIST SP 800- 61 Rev. 2, Computer Security Incident Handling Guide.
Guideline for a healthy information system v.2.0 (EN):
40 STANDARD
/STANDARD
Noticing unusual behaviour from a workstation or a server (impossible connection, significant activity, unusual activity, unauthorised open services, files created, modified or deleted without authorisation, multiple anti-virus warnings, etc.) may be a warning of a possible intrusion.
A bad reaction in the event of a security incident can make the situation worse and prevent the problem from being dealt properly. The right reaction is to disconnect the device from the network, to stop the attack. However, you must keep it powered and not restart it, so as to not lose useful information for analysing the attack. You must then alert the management, as well as the information system security point of contact.
He or she may get in contact with the security incident response service providers (PRIS) in order to carry out the necessary technical operations (physically copying the disk, analysing the memory, logs and possible malware, etc.) and determine if other elements of the information system have been compromised. This will also concern coming up with a response to provide, in order to remove possible malware and the access that the hacker may have and to change compromised passwords. Any incident must be recorded in a centralised register. Charges may also be pressed with the competent legal service.
Noticing unusual behaviour from a workstation or a server (impossible connection, significant activity, unusual activity, unauthorised open services, files created, modified or deleted without authorisation, multiple anti-virus warnings, etc.) may be a warning of a possible intrusion.
A bad reaction in the event of a security incident can make the situation worse and prevent the problem from being dealt properly. The right reaction is to disconnect the device from the network, to stop the attack. However, you must keep it powered and not restart it, so as to not lose useful information for analysing the attack. You must then alert the management, as well as the information system security point of contact.
He or she may get in contact with the security incident response service providers (PRIS) in order to carry out the necessary technical operations (physically copying the disk, analysing the memory, logs and possible malware, etc.) and determine if other elements of the information system have been compromised. This will also concern coming up with a response to provide, in order to remove possible malware and the access that the hacker may have and to change compromised passwords. Any incident must be recorded in a centralised register. Charges may also be pressed with the competent legal service.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.16.1.1
A.16.1.1 Обязанности и процедуры
Мера обеспечения информационной безопасности: Должны быть установлены обязанности и процедуры менеджмента для обеспечения уверенности в быстром, эффективном и надлежащем реагировании на инциденты информационной безопасности
Мера обеспечения информационной безопасности: Должны быть установлены обязанности и процедуры менеджмента для обеспечения уверенности в быстром, эффективном и надлежащем реагировании на инциденты информационной безопасности
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 19.1
CSC 19.1 Document Incident Response Procedures
Ensure that there are written incident response plans that define roles of personnel as well as phases of incident handling/management.
Ensure that there are written incident response plans that define roles of personnel as well as phases of incident handling/management.
Положение Банка России № 802-П от 25.07.2022 "О требованиях к защите информации в платежной системе Банка России":
П. 16.3
16.3. ОПКЦ СБП должен осуществлять:
- выявление операций, соответствующих признакам осуществления переводов денежных средств без согласия клиента, на основании моделей оценки риска операций по переводу денежных средств (далее - модели оценки риска операций Банка России), установленных в соответствии с договором о взаимодействии, заключаемым между Банком России и оператором внешней платежной системы в соответствии с частью 37 статьи 15 Федерального закона от 27 июня 2011 года N 161-ФЗ (далее - договор о взаимодействии между Банком России и ОПКЦ СБП), индикаторов уровня риска операции при осуществлении переводов денежных средств с использованием сервиса быстрых платежей, полученных от участников СБП;
- приостановление процедуры приема к исполнению, в том числе последующих процедур приема к исполнению и исполнения распоряжений в рамках выявленной операции, соответствующей признакам осуществления переводов денежных средств без согласия клиента, в соответствии с договором об оказании услуг между участником СБП и ОПКЦ СБП;
- незамедлительное уведомление участников СБП о выявлении операций, соответствующих признакам осуществления переводов денежных средств без согласия клиента, в соответствии с договором об оказании услуг между участником СБП и ОПКЦ СБП;
- уведомление Банка России о выявлении операций, соответствующих признакам осуществления переводов денежных средств без согласия клиента, в соответствии с договором о взаимодействии между Банком России и ОПКЦ СБП;
- формирование индикатора уровня риска операции на основе моделей оценки риска операций Банка России и направление участнику СБП - банку плательщика сформированных ОПКЦ СБП и участником СБП - банком получателя индикаторов уровня риска операций в электронном сообщении в случае невыявления признаков осуществления перевода денежных средств без согласия клиента.
Процедура принятия решения о наличии признаков осуществления перевода денежных средств без согласия клиента участником СБП на основании индикатора уровня риска операции, поступившего в электронном сообщении от участника СБП, ОПКЦ СБП при осуществлении операции по переводу денежных средств с использованием сервиса быстрых платежей, устанавливается участником СБП в рамках реализуемой им системы управления рисками в соответствии с частью 5.1 статьи 8 Федерального закона от 27 июня 2011 года N 161-ФЗ.
П. 16.4
16.4. В рамках реализации мер по выявлению и устранению причин и последствий компьютерных атак, направленных на объекты информационной инфраструктуры участника СБП и (или) его клиентов, ОПКЦ СБП, и дальнейшему предотвращению случаев и (или) попыток осуществления переводов денежных средств без согласия клиента участник СБП, ОПКЦ СБП должны обеспечить выполнение следующих требований:
- участник СБП - банк плательщика при выявлении информации о компьютерных атаках, проводимых с использованием идентификаторов клиентов участника СБП, направленных на получение информации о клиентах участника СБП или клиентах косвенного участника, имеющего доступ к трансграничному переводу денежных средств с использованием СБП в соответствии с абзацем восьмым пункта 3.3 Положения Банка России N 732-П (далее - косвенный участник с доступом к ТПСБП), из формирующихся распоряжений клиента участника СБП о переводе денежных средств (далее - переборы идентификаторов), при осуществлении переводов денежных средств с использованием сервиса быстрых платежей осуществляет блокировку идентификатора клиента участника СБП, используемого для осуществления переборов идентификаторов, и незамедлительно уведомляет Банк России и ОПКЦ СБП о его блокировке;
- участник СБП принимает решение о разблокировке идентификатора клиента участника СБП по результатам проведенной проверки и доводит принятое им решение до ОПКЦ СБП в соответствии с договором об оказании услуг между участником СБП и ОПКЦ СБП;
- ОПКЦ СБП осуществляет выявление переборов идентификаторов клиентов участника СБП, клиентов косвенного участника с доступом к ТПСБП, блокировку идентификатора клиента участника СБП, клиента косвенного участника с доступом к ТПСБП, используемого для осуществления переборов идентификаторов, при каждом выявлении перебора идентификаторов, в том числе при отсутствии уведомления участника СБП или косвенного участника с доступом к ТПСБП о блокировке, на срок, установленный договором об оказании услуг между участником СБП и ОПКЦ СБП, и направление уведомлений участнику СБП и Банку России о блокировке идентификатора;
- при получении участником СБП - банком плательщика уведомления о блокировке идентификатора от ОПКЦ СБП участник СБП обязан осуществлять проверку полученной информации в соответствии с договором между клиентом участника СБП и участником СБП, о результатах которой Банк России уведомляется в соответствии с абзацем девятым пункта 5.1 Положения Банка России N 719-П;
- участник СБП направляет уведомление о блокировке идентификатора клиента косвенного участника с доступом к ТПСБП косвенному участнику с доступом к ТПСБП и доводит до ОПКЦ СБП информацию о результатах проведенной проверки косвенным участником с доступом к ТПСБП в соответствии с договором об оказании услуг между участником СБП и ОПКЦ СБП;
- ОПКЦ СБП осуществляет разблокировку идентификатора клиента участника СБП, клиента косвенного участника с доступом к ТПСБП в соответствии с договором об оказании услуг между участником СБП и ОПКЦ СБП.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 10.4.3
10.4.3
Определенные Требования к Подходу:
Исключения и аномалии, выявленные в ходе процесса проверки, устраняются.
Цель Индивидуального подхода:
Рассматриваются подозрительные или аномальные действия.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Исключения и аномалии, выявленные в ходе процесса проверки, устраняются.
Цель Индивидуального подхода:
Рассматриваются подозрительные или аномальные действия.
Определенные Процедуры Тестирования Подхода:
- 10.4.3.a Изучите политики и процедуры безопасности, чтобы убедиться, что определены процессы для устранения исключений и аномалий, выявленных в процессе проверки.
- 10.4.3.b Наблюдайте за процессами и проводите собеседования с персоналом, чтобы убедиться, что при выявлении исключений и аномалий они устраняются.
Цель:
Если исключения и аномалии, выявленные в процессе просмотра журнала, не исследуются, организация может не знать о несанкционированных и потенциально вредоносных действиях, происходящих в ее сети.
Надлежащая практика:
Организациям следует рассмотреть вопрос о том, как учитывать следующее при разработке своих процессов определения и управления исключениями и аномалиями:
Если исключения и аномалии, выявленные в процессе просмотра журнала, не исследуются, организация может не знать о несанкционированных и потенциально вредоносных действиях, происходящих в ее сети.
Надлежащая практика:
Организациям следует рассмотреть вопрос о том, как учитывать следующее при разработке своих процессов определения и управления исключениями и аномалиями:
- Как записываются действия по проверке журнала, • Как ранжировать и расставлять приоритеты исключений и аномалий,
- Какие процедуры должны быть предусмотрены для сообщения об исключениях и аномалиях и их эскалации, а также
- Кто отвечает за расследование и за любые задачи по исправлению положения.
Requirement 10.7.2
10.7.2
Определенные Требования к Подходу:
Сбои критических систем контроля безопасности обнаруживаются, предупреждаются и оперативно устраняются, включая, но не ограничиваясь, отказ следующих критических систем контроля безопасности:
Определенные Требования к Подходу:
Сбои критических систем контроля безопасности обнаруживаются, предупреждаются и оперативно устраняются, включая, но не ограничиваясь, отказ следующих критических систем контроля безопасности:
- Средства управления сетевой безопасностью.
- IDS/IPS.
- Механизмы обнаружения изменений.
- Решения для защиты от вредоносных программ.
- Контроль физического доступа.
- Логический контроль доступа.
- Механизмы ведения журнала аудита.
- Элементы управления сегментацией (если они используются).
- Механизмы проверки журналов аудита.
- Автоматизированные средства тестирования безопасности (если они используются).
Цель Индивидуального подхода:
Сбои в критически важных системах контроля безопасности оперативно выявляются и устраняются.
Примечания по применению:
Это требование распространяется на все организации, включая поставщиков услуг, и заменит требование 10.7.1 с 31 марта 2025 года. Он включает в себя две дополнительные критически важные системы контроля безопасности, не указанные в требовании 10.7.1.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
Сбои в критически важных системах контроля безопасности оперативно выявляются и устраняются.
Примечания по применению:
Это требование распространяется на все организации, включая поставщиков услуг, и заменит требование 10.7.1 с 31 марта 2025 года. Он включает в себя две дополнительные критически важные системы контроля безопасности, не указанные в требовании 10.7.1.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
- 10.7.2.a Изучите документацию, чтобы убедиться, что определены процессы для оперативного обнаружения и устранения сбоев критических систем управления безопасностью, включая, но не ограничиваясь отказом всех элементов, указанных в этом требовании.
- 10.7.2.b Наблюдайте за процессами обнаружения и оповещения и опрашивайте персонал, чтобы убедиться, что сбои критических систем контроля безопасности обнаружены и сообщены, и что сбой критического контроля безопасности приводит к генерации предупреждения.
Цель:
Без формальных процессов обнаружения и оповещения о сбое критических средств защиты сбои могут оставаться незамеченными в течение длительного времени и предоставлять злоумышленникам достаточно времени для компрометации системных компонентов и кражи данных учетной записи из CDE.
Надлежащая практика:
Конкретные типы отказов могут варьироваться в зависимости от функции системного компонента устройства и используемой технологии. Однако типичные сбои включают в себя то, что система больше не выполняет свою функцию безопасности или не функционирует должным образом — например, брандмауэр стирает свои правила или переходит в автономный режим.
Без формальных процессов обнаружения и оповещения о сбое критических средств защиты сбои могут оставаться незамеченными в течение длительного времени и предоставлять злоумышленникам достаточно времени для компрометации системных компонентов и кражи данных учетной записи из CDE.
Надлежащая практика:
Конкретные типы отказов могут варьироваться в зависимости от функции системного компонента устройства и используемой технологии. Однако типичные сбои включают в себя то, что система больше не выполняет свою функцию безопасности или не функционирует должным образом — например, брандмауэр стирает свои правила или переходит в автономный режим.
Requirement 12.10.1
12.10.1
Определенные Требования к Подходу:
План реагирования на инциденты существует и готов к активации в случае предполагаемого или подтвержденного инцидента безопасности. План включает в себя, но не ограничивается:
Определенные Требования к Подходу:
План реагирования на инциденты существует и готов к активации в случае предполагаемого или подтвержденного инцидента безопасности. План включает в себя, но не ограничивается:
- Роли, обязанности, а также стратегии общения и контактов в случае предполагаемого или подтвержденного инцидента с безопасностью, включая, как минимум, уведомление платежных брендов и покупателей.
- Процедуры реагирования на инциденты с конкретными мероприятиями по локализации и смягчению последствий для различных типов инцидентов.
- Процедуры восстановления и обеспечения непрерывности бизнеса.
- Процессы резервного копирования данных.
- Анализ законодательных требований для сообщения о компромиссах.
- Охват и реагирование всех критически важных компонентов системы.
- Ссылка или включение процедур реагирования на инциденты от платежных брендов.
Цель Индивидуального подхода:
Поддерживается комплексный план реагирования на инциденты, соответствующий ожиданиям бренда card.
Определенные Процедуры Тестирования Подхода:
Поддерживается комплексный план реагирования на инциденты, соответствующий ожиданиям бренда card.
Определенные Процедуры Тестирования Подхода:
- 12.10.1.a Изучите план реагирования на инциденты, чтобы убедиться, что план существует и включает, по крайней мере, элементы, указанные в этом требовании.
- 12.10.1.b Опросите персонал и изучите документацию по ранее зарегистрированным инцидентам или предупреждениям, чтобы убедиться, что документированный план реагирования на инциденты и процедуры были соблюдены.
Цель:
Без всеобъемлющего плана реагирования на инциденты, который должным образом распространен, прочитан и понят ответственными сторонами, путаница и отсутствие единого ответа могут привести к дальнейшему простою бизнеса, ненужному освещению в средствах массовой информации, а также риску финансовых и/или репутационных потерь и юридической ответственности.
Надлежащая практика:
План реагирования на инциденты должен быть тщательным и содержать все ключевые элементы для заинтересованных сторон (например, юридические, коммуникационные), чтобы организация могла эффективно реагировать в случае нарушения, которое может повлиять на данные учетной записи. Важно поддерживать план в актуальном состоянии с учетом текущей контактной информации всех лиц, назначенных для участия в реагировании на инциденты. Другими соответствующими сторонами для уведомлений могут быть клиенты, финансовые учреждения (покупатели и эмитенты) и деловые партнеры.
Организациям следует рассмотреть вопрос о том, как устранить все нарушения данных в рамках CDE в своих планах реагирования на инциденты, включая данные учетной записи, беспроводные ключи шифрования, ключи шифрования, используемые для передачи и хранения, или данные учетной записи или данные о держателях карт и т.д.
Примеры:
Юридические требования к сообщению о компрометации включают требования большинства штатов США, Общего регламента ЕС по защите данных (GDPR) и Закона о защите персональных данных (Сингапур).
Дополнительная информация:
Для получения дополнительной информации обратитесь к Руководству по обработке инцидентов компьютерной безопасности NIST SP 800- 61 Rev. 2.
Без всеобъемлющего плана реагирования на инциденты, который должным образом распространен, прочитан и понят ответственными сторонами, путаница и отсутствие единого ответа могут привести к дальнейшему простою бизнеса, ненужному освещению в средствах массовой информации, а также риску финансовых и/или репутационных потерь и юридической ответственности.
Надлежащая практика:
План реагирования на инциденты должен быть тщательным и содержать все ключевые элементы для заинтересованных сторон (например, юридические, коммуникационные), чтобы организация могла эффективно реагировать в случае нарушения, которое может повлиять на данные учетной записи. Важно поддерживать план в актуальном состоянии с учетом текущей контактной информации всех лиц, назначенных для участия в реагировании на инциденты. Другими соответствующими сторонами для уведомлений могут быть клиенты, финансовые учреждения (покупатели и эмитенты) и деловые партнеры.
Организациям следует рассмотреть вопрос о том, как устранить все нарушения данных в рамках CDE в своих планах реагирования на инциденты, включая данные учетной записи, беспроводные ключи шифрования, ключи шифрования, используемые для передачи и хранения, или данные учетной записи или данные о держателях карт и т.д.
Примеры:
Юридические требования к сообщению о компрометации включают требования большинства штатов США, Общего регламента ЕС по защите данных (GDPR) и Закона о защите персональных данных (Сингапур).
Дополнительная информация:
Для получения дополнительной информации обратитесь к Руководству по обработке инцидентов компьютерной безопасности NIST SP 800- 61 Rev. 2.
Requirement 12.10.6
12.10.6
Определенные Требования к Подходу:
План реагирования на инциденты безопасности модифицируется и развивается в соответствии с извлеченными уроками и с учетом отраслевых разработок.
Цель Индивидуального подхода:
Эффективность и точность плана реагирования на инциденты пересматриваются и обновляются после каждого вызова.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
План реагирования на инциденты безопасности модифицируется и развивается в соответствии с извлеченными уроками и с учетом отраслевых разработок.
Цель Индивидуального подхода:
Эффективность и точность плана реагирования на инциденты пересматриваются и обновляются после каждого вызова.
Определенные Процедуры Тестирования Подхода:
- 12.10.6.a Изучить политики и процедуры для проверки того, что определены процессы для изменения и совершенствования плана реагирования на инциденты безопасности в соответствии с извлеченными уроками и с учетом отраслевых разработок.
- 12.10.6.b Изучите план реагирования на инциденты безопасности и опросите ответственный персонал, чтобы убедиться, что план реагирования на инциденты изменен и доработан в соответствии с извлеченными уроками и с учетом отраслевых разработок.
Цель:
Включение извлеченных уроков в план реагирования на инциденты после инцидента и в соответствии с развитием отрасли помогает поддерживать план в актуальном состоянии и реагировать на возникающие угрозы и тенденции в области безопасности.
Надлежащая практика:
Работа по извлечению уроков должна охватывать персонал всех уровней. Хотя он часто включается как часть анализа всего инцидента, он должен быть сосредоточен на том, как можно улучшить реакцию организации на инцидент.
Важно не просто рассмотреть элементы реагирования, которые не привели к запланированным результатам, но и понять, что сработало хорошо, и могут ли уроки из тех элементов, которые сработали хорошо, быть применены в тех областях плана, которые не сработали.
Другим способом оптимизации плана реагирования на инциденты организации является понимание атак, совершенных против других организаций, и использование этой информации для точной настройки процедур обнаружения, локализации, смягчения последствий или восстановления организации.
Включение извлеченных уроков в план реагирования на инциденты после инцидента и в соответствии с развитием отрасли помогает поддерживать план в актуальном состоянии и реагировать на возникающие угрозы и тенденции в области безопасности.
Надлежащая практика:
Работа по извлечению уроков должна охватывать персонал всех уровней. Хотя он часто включается как часть анализа всего инцидента, он должен быть сосредоточен на том, как можно улучшить реакцию организации на инцидент.
Важно не просто рассмотреть элементы реагирования, которые не привели к запланированным результатам, но и понять, что сработало хорошо, и могут ли уроки из тех элементов, которые сработали хорошо, быть применены в тех областях плана, которые не сработали.
Другим способом оптимизации плана реагирования на инциденты организации является понимание атак, совершенных против других организаций, и использование этой информации для точной настройки процедур обнаружения, локализации, смягчения последствий или восстановления организации.
Requirement 12.10.2
12.10.2
Определенные Требования к Подходу:
Не реже одного раза в 12 месяцев план реагирования на инциденты безопасности:
Определенные Требования к Подходу:
Не реже одного раза в 12 месяцев план реагирования на инциденты безопасности:
- Проверяется, и содержание обновляется по мере необходимости.
- Испытан, включая все элементы, перечисленные в требовании 12.10.1.
Цель Индивидуального подхода:
План реагирования на инциденты поддерживается в актуальном состоянии и периодически проверяется.
Определенные Процедуры Тестирования Подхода:
План реагирования на инциденты поддерживается в актуальном состоянии и периодически проверяется.
Определенные Процедуры Тестирования Подхода:
- 12.10.2 Опрашивайте персонал и просматривайте документацию, чтобы убедиться, что по крайней мере раз в 12 месяцев план реагирования на инциденты безопасности:
- Пересматривается и обновляется по мере необходимости.
- Испытано, включая все элементы, перечисленные в требовании 12.10.1.
Цель:
Надлежащее тестирование плана реагирования на инциденты безопасности может выявить нарушенные бизнес-процессы и гарантировать, что ключевые шаги не будут пропущены, что может привести к увеличению риска во время инцидента. Периодическое тестирование плана гарантирует, что процессы остаются жизнеспособными, а также гарантирует, что весь соответствующий персонал в организации знаком с планом.
Надлежащая практика:
Проверка плана реагирования на инциденты может включать имитацию инцидентов и соответствующие меры реагирования в форме “настольных упражнений”, которые включают участие соответствующего персонала. Анализ инцидента и качества реагирования может дать организациям уверенность в том, что все необходимые элементы включены в план.
Надлежащее тестирование плана реагирования на инциденты безопасности может выявить нарушенные бизнес-процессы и гарантировать, что ключевые шаги не будут пропущены, что может привести к увеличению риска во время инцидента. Периодическое тестирование плана гарантирует, что процессы остаются жизнеспособными, а также гарантирует, что весь соответствующий персонал в организации знаком с планом.
Надлежащая практика:
Проверка плана реагирования на инциденты может включать имитацию инцидентов и соответствующие меры реагирования в форме “настольных упражнений”, которые включают участие соответствующего персонала. Анализ инцидента и качества реагирования может дать организациям уверенность в том, что все необходимые элементы включены в план.
Strategies to Mitigate Cyber Security Incidents (EN):
3.2.
Host-based intrusion detection/prevention system to identify anomalous behaviour during program execution (e.g. process injection, keystroke logging, driver loading and persistence).
Relative Security Effectiveness: Very Good | Potential User Resistance: Low | Upfront Cost: Medium | Ongoing Maintenance Cost: Medium
Relative Security Effectiveness: Very Good | Potential User Resistance: Low | Upfront Cost: Medium | Ongoing Maintenance Cost: Medium
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.24
А.5.24 Планирование и подготовка в отношении инцидентов ИБ
Организация должна организовать процесс управления инцидентами ИБ путем определения, установления и коммуникации процессов управления инцидентами ИБ, ролей и обязанностей.
Организация должна организовать процесс управления инцидентами ИБ путем определения, установления и коммуникации процессов управления инцидентами ИБ, ролей и обязанностей.
Положение Банка России № 719-П от 04.06.2020 "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств":
Глава 5 п. 2
5.2. Оператор платежной системы в целях снижения риска информационной безопасности в платежной системе должен реализовывать механизмы совершенствования требований, указанных в пункте 5.4 настоящего Положения, предусматривающие в том числе накопление и учет опыта реагирования на инциденты защиты информации и восстановления функционирования платежной системы после их реализации.
Глава 5 п. 4
5.4. Оператор платежной системы должен обеспечить учет и доступность для операторов по переводу денежных средств, являющихся участниками платежной системы, и операторов услуг платежной инфраструктуры информации:
- о выявленных в платежной системе инцидентах защиты информации;
- о методиках анализа и реагирования на инциденты защиты информации.
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ИНЦ.1
ИНЦ.1 Выявление компьютерных инцидентов
ИНЦ.0
ИНЦ.0 Разработка политики реагирования на компьютерные инциденты
ИНЦ.3
ИНЦ.3 Анализ компьютерных инцидентов
ИНЦ.4
ИНЦ.4 Устранение последствий компьютерных инцидентов
ИНЦ.2
ИНЦ.2 Информирование о компьютерных инцидентах
ИНЦ.5
ИНЦ.5 Принятие мер по предотвращению повторного возникновения компьютерных инцидентов
Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":
п. 1.6.
1.6. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны обеспечивать в отношении выявления, регистрации событий операционного риска, связанных с нарушением операционной надежности, и реагирования на них, а также восстановления выполнения технологических процессов, указанных в приложении к настоящему Положению, и функционирования своих объектов информационной инфраструктуры после реализации указанных событий выполнение следующих требований:
- выявление и регистрацию событий операционного риска, связанных с нарушением операционной надежности;
- реагирование на события операционного риска, связанные с нарушением операционной надежности, в отношении критичной архитектуры;
- восстановление выполнения технологических процессов, указанных в приложении к настоящему Положению, и функционирования своих объектов информационной инфраструктуры после реализации событий операционного риска, связанных с нарушением операционной надежности;
- проведение анализа причин и последствий реализации событий операционного риска, связанных с нарушением операционной надежности;
- организацию взаимодействия между подразделениями (работниками) некредитной финансовой организации, ответственными за разработку технологических процессов, указанных в приложении к настоящему Положению, поддержание их выполнения, их реализацию, между собой и Банком России, иными участниками технологического процесса в рамках реагирования на события операционного риска, связанные с нарушением операционной надежности, и восстановления выполнения технологических процессов, указанных в приложении к настоящему Положению, а также функционирования своих объектов информационной инфраструктуры после реализации событий операционного риска, связанных с нарушением операционной надежности.
NIST Cybersecurity Framework (EN):
PR.IP-9
PR.IP-9: Response plans (Incident Response and Business Continuity) and recovery plans (Incident Recovery and Disaster Recovery) are in place and managed
Стандарт Банка России № РС БР ИББС-2.5-2014 от 01.06.2014 "Менеджмент инцидентов информационной безопасности":
Р. 6 п. 1 п.п. 1
6.1.1. Политика менеджмента инцидентов ИБ организации БС РФ является внутренним документом организации БС РФ, устанавливающим принципы и основные положения, регламентирующие деятельность по менеджменту инцидентов ИБ организации БС РФ.
Политика менеджмента инцидентов ИБ организации БС РФ разрабатывается службой ИБ организации БС РФ совместно и (или) по согласованию с подразделением информатизации организации БС РФ, юридической службой организации БС РФ, подразделениями организации БС РФ, в зоне компетенции которых находятся вопросы обеспечения непрерывности выполнения банковских технологических процессов организации БС РФ, службой персонала (кадров) организации БС РФ и утверждается руководством организации БС РФ.
Р. 6 п. 1 п.п. 2 п.п.п. 1
1. Цель и задачи менеджмента инцидентов ИБ. Основные цели менеджмента инцидентов ИБ, устанавливаемые политикой менеджмента инцидентов ИБ организации БС РФ, должны определять:
- создание условий для осуществления своевременного обнаружения и оперативного реагирования на инциденты ИБ, в том числе их закрытия;
- предотвращение и (или) снижение негативного влияния инцидентов ИБ на выполнение банковских технологических процессов организации БС РФ и (или) ее клиентов;
- оперативное совершенствование СОИБ организации БС РФ.
Основные задачи, устанавливаемые политикой менеджмента инцидентов ИБ организации БС РФ и решаемые в рамках менеджмента инцидентов ИБ, должны обеспечивать достижение установленных целей менеджмента инцидентов ИБ путем:
- своевременного обнаружения инцидентов ИБ;
- оперативного реагирования на инциденты ИБ в соответствии с требованиями законодательства РФ, нормативных актов Банка России и регламентами, установленными внутренними документами организации БС РФ;
- координации деятельности работников структурных подразделений организации БС РФ в рамках процессов реагирования на инциденты ИБ, в том числе их закрытия;
- ведения базы данных зарегистрированных событий ИБ и обнаруженных инцидентов ИБ;
- накопления и повторного использования знаний по обнаружению инцидентов ИБ и реагированию на них;
- анализа, оценки эффективности и совершенствования процессов менеджмента инцидентов ИБ организации БС РФ;
- предоставления руководству организации БС РФ информации и отчетов по результатам выполнения процессов менеджмента инцидентов ИБ, в том числе информации о фактах обнаружения инцидентов ИБ и результатах реагирования на них.
Р. 8 п. 8
8.8. В организации БС РФ рекомендуется установить процедуры информирования руководства организации БС РФ о результатах анализа процессов менеджмента инцидентов ИБ, а также о значимых инцидентах ИБ, оказывающих существенное негативное влияние на выполнение бизнес-процессов организации БС РФ.
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ИНЦ.1
ИНЦ.1 Выявление компьютерных инцидентов
ИНЦ.0
ИНЦ.0 Регламентация правил и процедур реагирования на компьютерные инциденты
ИНЦ.3
ИНЦ.3 Анализ компьютерных инцидентов
ИНЦ.2
ИНЦ.2 Информирование о компьютерных инцидентах
ИНЦ.5
ИНЦ.5 Принятие мер по предотвращению повторного возникновения компьютерных инцидентов
ИНЦ.4
ИНЦ.4 Устранение последствий компьютерных инцидентов
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.5.24
А.5.24 Information security incident management planning and preparation
The organization shall plan and prepare for managing information security incidents by defining, establishing and communicating information security incident management processes, roles and responsibilities.
The organization shall plan and prepare for managing information security incidents by defining, establishing and communicating information security incident management processes, roles and responsibilities.
Положение Банка России № 716-П от 08.04.2022 "О требованиях к системе управления операционным риском в кредитной организации и банковской группе":
Глава 7. Пункт 3.
7.3. Инциденты, приведшие к фактической реализации риска информационной безопасности, в том числе киберриска, обусловленные источниками риска информационной безопасности, в том числе инциденты, связанные с нарушениями требований к обеспечению защиты информации при осуществлении переводов денежных средств, установленных в соответствии с Положением Банка России от 4 июня 2020 года N 719-П "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств", зарегистрированным Министерством юстиции Российской Федерации 23 сентября 2020 года N 59991 (далее - Положение Банка России N 719-П), и Положением Банка России от 17 апреля 2019 года N 683-П "Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента", зарегистрированным Министерством юстиции Российской Федерации 16 мая 2019 года N 54637 (далее - Положение Банка России N 683-П) (далее - инциденты защиты информации), вследствие которых возникли прямые и (или) непрямые потери кредитной организации (головной кредитной организации банковской группы) (далее - событие риска информационной безопасности), фиксируются кредитной организацией (головной кредитной организацией банковской группы) в базе событий с присвоением вида операционного риска в соответствии с абзацем семнадцатым пункта 6.6 настоящего Положения.
(Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
Негативное влияние риска информационной безопасности должно определяться в виде потерь, приведенных в пункте 3.11 настоящего Положения и пункте 4 приложения 5 к настоящему Положению.
Связанные защитные меры
| Название | Дата | Влияние | ||
|---|---|---|---|---|
|
Community
1
8 / 91
|
Проведение киберучений в игровой форме
Вручную
Организационная
Удерживающая
01.03.2023
|
01.03.2023 | 1 8 / 91 | |
|
Community
13 / 138
|
Проведение штабных киберучений
Вручную
Организационная
08.05.2022
|
08.05.2022 | 13 / 138 |
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.