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

Положение Банка России № 787-П от 12.01.2022

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

п. 6. п.п. 3

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

Список требований

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

Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 8 п. 10 п.п. 5
8.10.5. В организациях БС РФ должны приниматься, фиксироваться и выполняться решения по всем выявленным инцидентам ИБ. 
Р. 8 п. 11 п.п. 3
8.11.3. Должен быть определен план обеспечения непрерывности бизнеса и его восстановления после возможного прерывания. План должен содержать инструкции и порядок действий работников организации БС РФ по восстановлению бизнеса. В частности, в состав плана должны быть включены:
  • условия активации плана;
  • действия, которые должны быть предприняты после инцидента ИБ;
  • процедуры восстановления;
  • процедуры тестирования и проверки плана;
  • план обучения и повышения осведомленности работников организации БС РФ;
  • обязанности работников организации с указанием ответственных за выполнение каждого из положений плана. 
Р. 8 п. 10 п.п. 2
8.10.2. Должны быть определены, выполняться, регистрироваться и контролироваться процедуры хранения и распространения информации об инцидентах ИБ, практиках анализа инцидентов ИБ и результатах реагирования на инциденты ИБ. 
Р. 7 п. 4 п.п. 4
7.4.4. В организации БС РФ должны быть определены, выполняться, регистрироваться и контролироваться правила и процедуры мониторинга ИБ, анализа и хранения данных о действиях и операциях, позволяющие выявлять неправомерные или подозрительные операции и транзакции, для чего, среди прочего, следует:
  • определить действия и операции, подлежащие регистрации;
  • определить состав и содержание данных о действиях и операциях, подлежащих регистрации, сроки их хранения;
  • обеспечить резервирование необходимого объема памяти для записи данных;
  • обеспечить реагирование на сбои при регистрации действий и операций, в том числе аппаратные и программные ошибки, сбои в технических средствах сбора данных;
  • обеспечить генерацию временных меток для регистрируемых действий и операций и синхронизацию системного времени на технических средствах, используемых для целей мониторинга ИБ, анализа и хранения данных.
В организации БС РФ должно быть реализовано ведение журналов действия и операций автоматизированных рабочих мест, серверного и сетевого оборудования, межсетевых экранов и АБС с целью их использования при реагировании на инциденты ИБ.
Рекомендуется обеспечить хранение данных о действиях и операциях не менее трех лет, а для данных, полученных в результате выполнения банковского платежного технологического процесса, - не менее пяти лет, если иные сроки хранения не установлены законодательством РФ, нормативными актами Банка России.
Для проведения процедур мониторинга ИБ и анализа данных о действиях и операциях следует использовать специализированные программные и (или) технические средства.
Процедуры мониторинга ИБ и анализа данных о действиях и операциях должны использовать зафиксированные критерии выявления неправомерных или подозрительных действий и операций. Указанные процедуры мониторинга ИБ и анализа должны применяться на регулярной основе, например ежедневно, ко всем выполненным действиям и операциям (транзакциям).
Р. 8 п. 11 п.п. 6
8.11.6. План обеспечения непрерывности бизнеса и его восстановления после прерывания должен быть согласован с существующими в организации процедурами обработки инцидентов ИБ. 
ГОСТ Р № 57580.3-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Управление риском реализации информационных угроз и обеспечение операционной надежности. Общие положения.":
ОПР.5.1
ОПР.5.1 В целях обеспечения ИБ:
  • разработка и (или) пересмотр внутренних документов в области обеспечения операционной надежности и защиты информации;
  • планирование, реализация (в том числе установление требований) и контроль процессов обеспечения операционной надежности и защиты информации;
  • разработка предложений по совершенствованию процессов обеспечения операционной надежности и защиты информации (по результатам анализа необходимости совершенствования систем управления, определяемых в рамках семейств стандартов ОН и ЗИ);
  • выявление и фиксация инцидентов, в том числе обнаружение реализации компьютерных атак и выявление фактов (индикаторов) компрометации объектов информатизации;
  • формирование отчетности по вопросам обеспечения операционной надежности и защиты информации, направляемой на рассмотрение коллегиальному исполнительному органу, должностному лицу, ответственному за функционирование системы управления риском реализации информационных угроз, а также иным должностным лицам, в случае наличия соответствующих требований во внутренних документах финансовой организации или требований нормативных актов Банка России;
  • осуществление других функций, связанных с реализаций процессов обеспечения операционной надежности и защиты информации, предусмотренных внутренними документами финансовой организации
ОПР.2
ОПР.2 Реализация механизмов взаимодействия и координации деятельности* вовлеченных подразделений, формирующих «три линии защиты», а также причастных сторон (за исключением клиентов финансовой организации) в целях подготовки и реализации политики управления риском реализации информационных угроз.
ОПР.19.9
ОПР.19.9 Обеспечение реагирования финансовой организации в случае превышения сигнальных и контрольных значений КПУР.
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
MAC.18
MAC.18 Обеспечение возможности выявления и анализа событий защиты информации, потенциально связанных с инцидентами защиты информации, в том числе НСД
3-Т 2-Т 1-Т
РИ.6
РИ.6 Установление и применение единых правил реагирования на инциденты защиты информации
3-О 2-О 1-О
РИ.1
РИ.1 Регистрация информации о событиях защиты информации, потенциально связанных с инцидентами защиты информации, в том числе НСД, выявленными в рамках мониторинга и анализа событий защиты информации
3-О 2-Т 1-Т
NIST Cybersecurity Framework (RU):
RS.MI-1
RS.MI-1: Инциденты локализируются 
RS.AN-2
RS.AN-2: Понимается влияние инцидента
RS.MI-2
RS.MI-2: Смягчаются последствия от инцидента 
PR.IP-9
PR.IP-9:  Созданы и управляются планы реагирования (реагирование на инциденты и непрерывность бизнеса) и планы восстановления (восстановление после инцидентов и аварийное  восстановление) 
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ИНЦ.2 ИНЦ.2 Обнаружение, идентификация и регистрация инцидентов
ИНЦ.5 ИНЦ.5 Принятие мер по устранению последствий инцидентов
ИНЦ.4 ИНЦ.4 Анализ инцидентов, в том числе определение источников и причин возникновения инцидентов, а также оценка их последствий
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
ВРВ.34.3
ВРВ.34.3 Определение источников и выявление причин реализации инцидентов;
ВРВ.34.1
ВРВ.34.1 Определение целевых показателей анализа технических данных (свидетельств);
ВРВ.34.5
ВРВ.34.5 Оценку последствий от реализации инцидентов, влияния последствий на КПУР, предусмотренных ГОСТ Р57580.3, с учетом требований нормативных актов Банка России, в том числе оценку прямых и непрямых финансовых потерь от реализации инцидентов;
ВРВ.37
ВРВ.37 Организация и выполнение деятельности по информированию о результатах проведенного анализа причин и последствий реализации инцидентов:
  • исполнительного органа финансовой организации****;
  • должностного лица, ответственного за функционирование системы управления риском реализации информационных угроз;
  • причастных сторон (за исключением клиентов финансовой организации); - Банка России (ФинЦЕРТ)*****.
ВРВ.34.4
ВРВ.34.4 Описание сценариев реализации инцидентов;
ВРВ.34.2
ВРВ.34.2 Сбор и анализ технических данных (свидетельств)* в рамках выявления, реагирования на инциденты и восстановления после их реализации;
ВРВ.16.1
ВРВ.16.1 Оперативное устранение или ограничение воздействия источников и причин реализации инцидентов;
ВРВ.7.6
ВРВ.7.6 Перечня причастных сторон (за исключением клиентов финансовой организации), с которыми финансовая организация осуществляет взаимодействие в рамках реагирования на инциденты;
ВРВ.27
ВРВ.27 Организация и выполнение деятельности в рамках восстановления функционирования бизнес- и технологических процессов и объектов информатизации после реализации инцидентов согласно утвержденным*** правилам и процедурам (playbooks).
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
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:
  • 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. 
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:
  • 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:
  • 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. 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.16.1.5
A.16.1.5 Реагирование на инциденты информационной безопасности 
Мера обеспечения информационной безопасности: Реагирование на инциденты информационной безопасности должно осуществляться в соответствии с документально оформленными процедурами 
A.16.1.6
A.16.1.6 Анализ инцидентов информационной безопасности 
Мера обеспечения информационной безопасности: Знания, приобретенные в результате анализа и урегулирования инцидентов информационной безопасности, должны использоваться для уменьшения вероятности или влияния будущих инцидентов 
A.16.1.4
A.16.1.4 Оценка и принятие решений в отношении событий информационной безопасности 
Мера обеспечения информационной безопасности: Должна быть проведена оценка событий информационной безопасности, и должно быть принято решение, следует ли их классифицировать как инциденты информационной безопасности 
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.
Стандарт № GMP Annex 11: Computerised Systems (RU) от 30.11.2011 "Правила надлежащей производственной практики. Приложение 11: Компьютеризированные системы":
Р. 4 п. 13 п.п. 1
Все инциденты (непредвиденные случаи), включая системные сбои и ошибки данных, должны быть записаны и оценены. Следует установить основную причину критических сбоев и использовать эту информацию в качестве основы корректирующих и предупреждающих действий. 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 12.10.1
12.10.1
Определенные Требования к Подходу:
План реагирования на инциденты существует и готов к активации в случае предполагаемого или подтвержденного инцидента безопасности. План включает в себя, но не ограничивается:
  • Роли, обязанности, а также стратегии общения и контактов в случае предполагаемого или подтвержденного инцидента с безопасностью, включая, как минимум, уведомление платежных брендов и покупателей.
  • Процедуры реагирования на инциденты с конкретными мероприятиями по локализации и смягчению последствий для различных типов инцидентов.
  • Процедуры восстановления и обеспечения непрерывности бизнеса.
  • Процессы резервного копирования данных.
  • Анализ законодательных требований для сообщения о компромиссах.
  • Охват и реагирование всех критически важных компонентов системы.
  • Ссылка или включение процедур реагирования на инциденты от платежных брендов.
Цель Индивидуального подхода:
Поддерживается комплексный план реагирования на инциденты, соответствующий ожиданиям бренда card.

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

Надлежащая практика:
План реагирования на инциденты должен быть тщательным и содержать все ключевые элементы для заинтересованных сторон (например, юридические, коммуникационные), чтобы организация могла эффективно реагировать в случае нарушения, которое может повлиять на данные учетной записи. Важно поддерживать план в актуальном состоянии с учетом текущей контактной информации всех лиц, назначенных для участия в реагировании на инциденты. Другими соответствующими сторонами для уведомлений могут быть клиенты, финансовые учреждения (покупатели и эмитенты) и деловые партнеры.
Организациям следует рассмотреть вопрос о том, как устранить все нарушения данных в рамках CDE в своих планах реагирования на инциденты, включая данные учетной записи, беспроводные ключи шифрования, ключи шифрования, используемые для передачи и хранения, или данные учетной записи или данные о держателях карт и т.д.

Примеры:
Юридические требования к сообщению о компрометации включают требования большинства штатов США, Общего регламента ЕС по защите данных (GDPR) и Закона о защите персональных данных (Сингапур).

Дополнительная информация:
Для получения дополнительной информации обратитесь к Руководству по обработке инцидентов компьютерной безопасности NIST SP 800- 61 Rev. 2.
Requirement 12.10.6
12.10.6
Определенные Требования к Подходу:
План реагирования на инциденты безопасности модифицируется и развивается в соответствии с извлеченными уроками и с учетом отраслевых разработок.

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

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

Надлежащая практика:
Работа по извлечению уроков должна охватывать персонал всех уровней. Хотя он часто включается как часть анализа всего инцидента, он должен быть сосредоточен на том, как можно улучшить реакцию организации на инцидент.
Важно не просто рассмотреть элементы реагирования, которые не привели к запланированным результатам, но и понять, что сработало хорошо, и могут ли уроки из тех элементов, которые сработали хорошо, быть применены в тех областях плана, которые не сработали.
Другим способом оптимизации плана реагирования на инциденты организации является понимание атак, совершенных против других организаций, и использование этой информации для точной настройки процедур обнаружения, локализации, смягчения последствий или восстановления организации.
Strategies to Mitigate Cyber Security Incidents (EN):
3.1.
Continuous incident detection and response with automated immediate analysis of centralised time-synchronised logs of allowed and denied computer events, authentication, file access and network activity.
Relative Security Effectiveness:  Excellent | Potential User Resistance:  Low | Upfront Cost:  Very High | Ongoing Maintenance Cost: Very High 
Приказ ФСБ России № 77 от 13.02.2023 "Об утверждении порядка взаимодействия операторов с государственной системой обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации, включая информирование ФСБ России о компьютерных инцидентах,":
Пункт 2
2. Операторы, с которыми взаимодействие по получению информации организовано в соответствии с подпунктом 4.8 пункта 4 Положения о НКЦКИ, направляют информацию о компьютерных инцидентах, повлекших неправомерную передачу (предоставление, распространение, доступ) персональных данных, в соответствии с определенными НКЦКИ форматами представления информации о компьютерных инцидентах в ГосСОПКА с использованием каналов информационного взаимодействия, в том числе посредством электронной почтовой связи и технической инфраструктуры НКЦКИ, предназначенных для отправки, получения, обработки и хранения уведомлений и запросов в рамках информационного взаимодействия с субъектами критической информационной инфраструктуры, а также с иными не являющимися субъектами критической информационной инфраструктуры органами и организациями, в том числе иностранными и международными (далее - каналы информационного взаимодействия), в течение 24 часов с момента обнаружения компьютерного инцидента, повлекшего неправомерную передачу (предоставление, распространение, доступ) персональных данных.
Пункт 3
3. Операторы, не указанные в пункте 2 настоящего Порядка, направляют информацию о компьютерных инцидентах, повлекших неправомерную передачу (предоставление, распространение, доступ) персональных данных, путем заполнения уведомления о факте неправомерной передачи (предоставления, распространения, доступа) персональных данных, содержащегося на официальном сайте Роскомнадзора в информационно-телекоммуникационной сети "Интернет", в срок не позднее 24 часов с момента обнаружения компьютерного инцидента, повлекшего неправомерную передачу (предоставление, распространение, доступ) персональных данных, а также путем заполнения уведомления о результатах внутреннего расследования, содержащегося на официальном сайте Роскомнадзора в информационно-телекоммуникационной сети "Интернет", в срок не позднее 72 часов с момента обнаружения компьютерного инцидента, повлекшего неправомерную передачу (предоставление, распространение, доступ) персональных данных.
Передача указанной информации Роскомнадзором в НКЦКИ регламентируется порядком, устанавливаемым ФСБ России и Роскомнадзором в соответствии с частью 11 статьи 23 Федерального закона от 27 июля 2006 г. N 152-ФЗ "О персональных данных".
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.27
А.5.27 Извлечение уроков из инцидентов ИБ
Знания, полученные по результатам инцидентов ИБ, должны использоваться для укрепления и улучшения средств управления ИБ.
А.8.16
А.8.16 Деятельность по мониторингу
Сети, системы и приложения должны быть объектом мониторинга на предмет выявления аномального поведения и выполнения соответствующих действий по оценке возможных инцидентов ИБ.
А.5.25
А.5.25 Оценка и принятие решений в отношении событий ИБ
Организация должна оценивать события ИБ и решать, следует ли их относить к инцидентам ИБ.
А.5.26
А.5.26 Реагирование на инциденты ИБ
Реагирование на инциденты ИБ должно осуществляться в соответствии с документированными процедурами.
Положение Банка России № 719-П от 04.06.2020 "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств":
Глава 2 п. 6
2.6. Операторы по переводу денежных средств должны установить порядок их информирования привлекаемыми ими банковскими платежными агентами (субагентами), операторами услуг информационного обмена о выявленных инцидентах защиты информации. Операторы по переводу денежных средств по запросу Банка России должны направлять в Банк России сведения об инцидентах защиты информации, полученные от привлекаемых ими банковских платежных агентов (субагентов), операторов услуг информационного обмена.
Глава 1 п. 5
1.5. Операторы по переводу денежных средств, операторы услуг платежной инфраструктуры в части требований к обеспечению защиты информации при осуществлении переводов денежных средств, применяемых в отношении информирования Банка России об инцидентах (событиях), связанных с нарушением требований к обеспечению защиты информации при осуществлении переводов денежных средств, в том числе включенных в перечень типов инцидентов, согласованный с федеральным органом исполнительной власти, уполномоченным в области обеспечения функционирования государственной системы обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации, и размещаемый Банком России на официальном сайте Банка России в сети «Интернет» (далее соответственно - инциденты защиты информации, перечень типов инцидентов), должны осуществлять информирование Банка России:
  • о выявленных инцидентах защиты информации, включенных в перечень типов инцидентов;
  • о планируемых мероприятиях по раскрытию информации об инцидентах защиты информации, включая размещение информации на официальных сайтах в сети «Интернет», выпуск пресс-релизов и проведение пресс-конференций, не позднее одного рабочего дня до дня проведения мероприятия.
Информирование осуществляется посредством предоставления в Банк России сведений, указанных в абзацах втором и третьем настоящего пункта. Информация о форме и сроке предоставления указанных сведений подлежит согласованию с федеральным органом исполнительной власти, уполномоченным в области обеспечения функционирования государственной системы обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации, согласно части 6 статьи 5 Федерального закона от 26 июля 2017 года № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» (Собрание законодательства Российской Федерации, 2017, № 31, ст. 4736) (далее - Федеральный закон № 187-ФЗ) и размещается на официальном сайте Банка России в сети «Интернет».
SWIFT Customer Security Controls Framework v2022:
7 - 7.1 Cyber Incident Response Planning
7.1 Cyber Incident Response Planning
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ИНЦ.1 ИНЦ.1 Выявление компьютерных инцидентов
ИНЦ.0 ИНЦ.0 Разработка политики реагирования на компьютерные инциденты
ИНЦ.3 ИНЦ.3 Анализ компьютерных инцидентов
ИНЦ.4 ИНЦ.4 Устранение последствий компьютерных инцидентов
Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":
п. 1.6.
1.6. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны обеспечивать в отношении выявления, регистрации событий операционного риска, связанных с нарушением операционной надежности, и реагирования на них, а также восстановления выполнения технологических процессов, указанных в приложении к настоящему Положению, и функционирования своих объектов информационной инфраструктуры после реализации указанных событий выполнение следующих требований:
  • выявление и регистрацию событий операционного риска, связанных с нарушением операционной надежности;
  • реагирование на события операционного риска, связанные с нарушением операционной надежности, в отношении критичной архитектуры;
  • восстановление выполнения технологических процессов, указанных в приложении к настоящему Положению, и функционирования своих объектов информационной инфраструктуры после реализации событий операционного риска, связанных с нарушением операционной надежности;
  • проведение анализа причин и последствий реализации событий операционного риска, связанных с нарушением операционной надежности;
  • организацию взаимодействия между подразделениями (работниками) некредитной финансовой организации, ответственными за разработку технологических процессов, указанных в приложении к настоящему Положению, поддержание их выполнения, их реализацию, между собой и Банком России, иными участниками технологического процесса в рамках реагирования на события операционного риска, связанные с нарушением операционной надежности, и восстановления выполнения технологических процессов, указанных в приложении к настоящему Положению, а также функционирования своих объектов информационной инфраструктуры после реализации событий операционного риска, связанных с нарушением операционной надежности.
Стандарт Банка России № РС БР ИББС-2.5-2014 от 01.06.2014 "Менеджмент инцидентов информационной безопасности":
Р. 6 п. 1 п.п. 2 п.п.п. 1
1. Цель и задачи менеджмента инцидентов ИБ. Основные цели менеджмента инцидентов ИБ, устанавливаемые политикой менеджмента инцидентов ИБ организации БС РФ, должны определять:
  • создание условий для осуществления своевременного обнаружения и оперативного реагирования на инциденты ИБ, в том числе их закрытия;
  • предотвращение и (или) снижение негативного влияния инцидентов ИБ на выполнение банковских технологических процессов организации БС РФ и (или) ее клиентов;
  • оперативное совершенствование СОИБ организации БС РФ. 
Основные задачи, устанавливаемые политикой менеджмента инцидентов ИБ организации БС РФ и решаемые в рамках менеджмента инцидентов ИБ, должны обеспечивать достижение установленных целей менеджмента инцидентов ИБ путем:
  • своевременного обнаружения инцидентов ИБ;
  • оперативного реагирования на инциденты ИБ в соответствии с требованиями законодательства РФ, нормативных актов Банка России и регламентами, установленными внутренними документами организации БС РФ;
  • координации деятельности работников структурных подразделений организации БС РФ в рамках процессов реагирования на инциденты ИБ, в том числе их закрытия; 
  • ведения базы данных зарегистрированных событий ИБ и обнаруженных инцидентов ИБ;
  • накопления и повторного использования знаний по обнаружению инцидентов ИБ и реагированию на них; 
  • анализа, оценки эффективности и совершенствования процессов менеджмента инцидентов ИБ организации БС РФ; 
  • предоставления руководству организации БС РФ информации и отчетов по результатам выполнения процессов менеджмента инцидентов ИБ, в том числе информации о фактах обнаружения инцидентов ИБ и результатах реагирования на них. 
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ИНЦ.0 ИНЦ.0 Регламентация правил и процедур реагирования на компьютерные инциденты
ИНЦ.3 ИНЦ.3 Анализ компьютерных инцидентов
ИНЦ.1 ИНЦ.1 Выявление компьютерных инцидентов
ИНЦ.4 ИНЦ.4 Устранение последствий компьютерных инцидентов
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
16.1.4
16.1.4 Оценка и принятие решений в отношении событий информационной безопасности

Мера обеспечения ИБ
Должна быть проведена оценка событий безопасности и принято решение, следует ли их классифицировать как инциденты ИБ.

Руководство по применению
Контактные лица по вопросам обнаружения и информирования об инцидентах должны оценивать каждое событие безопасности, используя согласованную шкалу классификации событий и инцидентов безопасности, и решать, следует ли классифицировать событие как инцидент ИБ. Классификация и распределение инцидентов по приоритетам может помочь в определении влияния и масштаба инцидента.
В тех случаях, когда в организации есть группа реагирования на инциденты ИБ (ГРИИБ), оценка и принятие решения могут быть переданы ей для подтверждения или повторной оценки.
Результаты оценки и принятых решений должны быть подробно зафиксированы с целью обращения к ним в будущем и проверки.
16.1.6
16.1.6 Извлечение уроков из инцидентов информационной безопасности

Мера обеспечения ИБ
Знания, приобретенные в результате анализа и урегулирования инцидентов ИБ, должны использоваться для уменьшения вероятности или влияния будущих инцидентов.

Руководство по применению
Должны быть внедрены механизмы, позволяющие количественно определять и отслеживать типы, объемы и стоимость инцидентов ИБ. Информация, полученная в результате оценки инцидентов ИБ, должна использоваться для выявления повторяющихся или значительных инцидентов.

Дополнительная информация
Оценка инцидентов ИБ может указывать на необходимость в усилении или дополнении мер обеспечения ИБ для снижения частоты, ущерба и стоимости в будущем или может быть принята во внимание при пересмотре политики безопасности (см. 5.1.2).
При должном внимании к аспектам конфиденциальности, истории про реальные инциденты ИБ могут быть использованы при обучении персонала (см. 7.2.2) в качестве примеров того, что может случиться, как реагировать на такие инциденты и как избежать их в будущем.
16.1.5
16.1.5 Реагирование на инциденты информационной безопасности

Мера обеспечения ИБ
Реагирование на инциденты ИБ должно осуществляться в соответствии с документально оформленными процедурами.

Руководство по применению
Реагирование на инциденты ИБ должно осуществляться назначенными контактными лицами и другими соответствующими лицами из числа самой организации или сторонних организаций (см. 16.1.1).
Реагирование должно включать в себя следующее:
  • a) как можно более быстрый сбор свидетельств произошедшего;
  • b) проведение криминалистического анализа ИБ по мере необходимости (см. 16.1.7);
  • c) эскалация, если требуется;
  • d) обеспечение того, что все выполняемые действия по реагированию соответствующим образом зарегистрированы для дальнейшего анализа;
  • e) информирование о факте инцидента ИБ или любых существенных деталях о нем других лиц из числа самой организации или сторонних организаций в соответствии с принципом "необходимого знания";
  • f) устранение недостатка(ов) ИБ, которые могут стать причиной или способствовать возникновению инцидента;
  • g) после того, как инцидент успешно отработан, необходимо формально закрыть и записать его.
После инцидента должен проводиться анализ для выявления первопричины инцидента.

Дополнительная информация
Первоочередной целью реагирования на инцидент является возобновление "нормального уровня безопасности", а затем инициирование необходимого восстановления.
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.8.16
А.8.16 Monitoring activities
Networks, systems and applications shall be monitored for anomalous behaviour and appropriate actions taken to evaluate potential information security incidents.
А.5.27
А.5.27 Learning from information security incidents
Knowledge gained from information security incidents shall be used to strengthen and improve the information security controls.
А.5.25
А.5.25 Assessment and decision on information security events
The organization shall assess information security events and decide if they are to be categorized as information security incidents.
А.5.26
А.5.26 Response to information security incidents
Information security incidents shall be responded to in accordance with the documented procedures.
Приказ ФСТЭК России № 235 от 21.12.2017 "Требования к созданию систем безопасности значимых объектов критической информационной инфраструктуры Российской Федерации и обеспечению их функционирования":
IV п.25 п.п. б)
б) планы мероприятий по обеспечению безопасности значимых объектов критической информационной инфраструктуры, модели угроз безопасности информации в отношении значимых объектов критической информационной инфраструктуры, порядок реализации отдельных мер по обеспечению безопасности значимых объектов критической информационной инфраструктуры, порядок проведения испытаний или приемки средств защиты информации, порядок реагирования на компьютерные инциденты, порядок информирования и обучения работников, порядок взаимодействия подразделений (работников) субъекта критической информационной инфраструктуры при решении задач обеспечения безопасности значимых объектов критической информационной инфраструктуры, порядок взаимодействия субъекта критической информационной инфраструктуры с государственной системой обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации;
IV п.25 п.п. в)
в) правила безопасной работы работников субъекта критической информационной инфраструктуры на значимых объектах критической информационной инфраструктуры, действия работников субъекта критической информационной инфраструктуры при возникновении компьютерных инцидентов и иных нештатных ситуаций.
Положение Банка России № 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 к настоящему Положению.

Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.