Куда я попал?
Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014
Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения
Р. 8 п. 10 п.п. 1
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
ГОСТ Р № 57580.3-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Управление риском реализации информационных угроз и обеспечение операционной надежности. Общие положения.":
ОПР.19.9
ОПР.19.9 Обеспечение реагирования финансовой организации в случае превышения сигнальных и контрольных значений КПУР.
ГОСТ Р № 22301 от 01.01.2022 "Надежность в технике. Системы менеджмента непрерывности деятельности. Требования":
Р. 8 п. 4 пп. 1
8.4.1 Общие положения
Организация должна внедрить и поддерживать структуру реагирования, которая позволит своевременно предупреждать нарушение деятельности организации и проводить обмен информацией с соответствующими заинтересованными сторонами. Организация должна разработать планы и процедуры управления организацией в период нарушения ее деятельности. Планы и процедуры должны быть использованы, когда необходимо инициировать решения по обеспечению непрерывности деятельности.
Примечание — Существуют различные типы процедур, которые включают в планы обеспечения непрерывности деятельности.
Организация должна определить и документировать планы и процедуры обеспечения непрерывности деятельности на основе выбранных стратегий и решений.
Процедуры должны:
Организация должна внедрить и поддерживать структуру реагирования, которая позволит своевременно предупреждать нарушение деятельности организации и проводить обмен информацией с соответствующими заинтересованными сторонами. Организация должна разработать планы и процедуры управления организацией в период нарушения ее деятельности. Планы и процедуры должны быть использованы, когда необходимо инициировать решения по обеспечению непрерывности деятельности.
Примечание — Существуют различные типы процедур, которые включают в планы обеспечения непрерывности деятельности.
Организация должна определить и документировать планы и процедуры обеспечения непрерывности деятельности на основе выбранных стратегий и решений.
Процедуры должны:
- а) быть конкретными е отношении немедленных действий, которые должны быть выполнены в период нарушения деятельности организации;
- b) гибкими, чтобы реагировать на изменяющиеся внутренние и внешние условия в период нарушения деятельности организации;
- с) фокусироваться на воздействии инцидентов, которые потенциально могут привести к нарушению деятельности организации;
- d) результативно минимизировать воздействия путем выполнения соответствующих решений;
- е) устанавливать функции и обязанности по выполнению задач внутри процедур.
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
ВРВ.43
ВРВ.43 Организация и выполнение деятельности по информированию должностного лица, ответственного за функционирование системы управления риском реализации информационных угроз, по каждому факту реализации инцидентов:
- о масштабах влияния реализации инцидента на осуществление видов деятельности финансовой организации, влиянии на фактические значения КПУР, предусмотренные ГОСТ Р 57580.3;
- о бизнес- и технологических процессах, на непрерывность выполнения которых было оказано влияние в результате реализации инцидента;
- о сроках и условиях, при которых будет восстановлено выполнение бизнес- и технологических процессов, в том числе восстановлено функционирование задействованных объектов информатизации;
- о предпринятых и запланированных действиях в рамках реагирования на инциденты и восстановления после их реализации, а также статусе выполнения соответствующих работ;
- о сведениях, которые могут быть раскрыты и доведены до потребителей финансовых услуг.
ВРВ.19
ВРВ.19 Обеспечение возможности проведения компьютерной экспертизы в целях сбора и фиксации технических данных (свидетельств), в том числе посредством заключения контрактов (договоров) с поставщиками услуг в случае, если финансовая организация не располагает необходимыми для данной деятельности компетенциями.
ВРВ.37
ВРВ.37 Организация и выполнение деятельности по информированию о результатах проведенного анализа причин и последствий реализации инцидентов:
- исполнительного органа финансовой организации****;
- должностного лица, ответственного за функционирование системы управления риском реализации информационных угроз;
- причастных сторон (за исключением клиентов финансовой организации); - Банка России (ФинЦЕРТ)*****.
ВРВ.7.2
ВРВ.7.2 Методологии проведения предварительной оценки потенциала влияния (критичности) инцидента, включая его классификацию согласно типовому перечню и классификационным признакам;
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
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.5
A.16.1.5 Реагирование на инциденты информационной безопасности
Мера обеспечения информационной безопасности: Реагирование на инциденты информационной безопасности должно осуществляться в соответствии с документально оформленными процедурами
Мера обеспечения информационной безопасности: Реагирование на инциденты информационной безопасности должно осуществляться в соответствии с документально оформленными процедурами
Положение Банка России № 802-П от 25.07.2022 "О требованиях к защите информации в платежной системе Банка России":
П. 16.3
16.3. ОПКЦ СБП должен осуществлять:
- выявление операций, соответствующих признакам осуществления переводов денежных средств без согласия клиента, на основании моделей оценки риска операций по переводу денежных средств (далее - модели оценки риска операций Банка России), установленных в соответствии с договором о взаимодействии, заключаемым между Банком России и оператором внешней платежной системы в соответствии с частью 37 статьи 15 Федерального закона от 27 июня 2011 года N 161-ФЗ (далее - договор о взаимодействии между Банком России и ОПКЦ СБП), индикаторов уровня риска операции при осуществлении переводов денежных средств с использованием сервиса быстрых платежей, полученных от участников СБП;
- приостановление процедуры приема к исполнению, в том числе последующих процедур приема к исполнению и исполнения распоряжений в рамках выявленной операции, соответствующей признакам осуществления переводов денежных средств без согласия клиента, в соответствии с договором об оказании услуг между участником СБП и ОПКЦ СБП;
- незамедлительное уведомление участников СБП о выявлении операций, соответствующих признакам осуществления переводов денежных средств без согласия клиента, в соответствии с договором об оказании услуг между участником СБП и ОПКЦ СБП;
- уведомление Банка России о выявлении операций, соответствующих признакам осуществления переводов денежных средств без согласия клиента, в соответствии с договором о взаимодействии между Банком России и ОПКЦ СБП;
- формирование индикатора уровня риска операции на основе моделей оценки риска операций Банка России и направление участнику СБП - банку плательщика сформированных ОПКЦ СБП и участником СБП - банком получателя индикаторов уровня риска операций в электронном сообщении в случае невыявления признаков осуществления перевода денежных средств без согласия клиента.
Процедура принятия решения о наличии признаков осуществления перевода денежных средств без согласия клиента участником СБП на основании индикатора уровня риска операции, поступившего в электронном сообщении от участника СБП, ОПКЦ СБП при осуществлении операции по переводу денежных средств с использованием сервиса быстрых платежей, устанавливается участником СБП в рамках реализуемой им системы управления рисками в соответствии с частью 5.1 статьи 8 Федерального закона от 27 июня 2011 года N 161-ФЗ.
П. 18
18. Для целей анализа обеспечения в платежной системе Банка России защиты информации при осуществлении переводов денежных средств участники ССНП, участники СБП и ОПКЦ СБП должны направлять информацию в соответствии с требованиями, установленными:
- Указанием Банка России от 9 июня 2012 года N 2831-У "Об отчетности по обеспечению защиты информации при осуществлении переводов денежных средств операторов платежных систем, операторов услуг платежной инфраструктуры, операторов по переводу денежных средств";
- Указанием Банка России от 12 января 2022 года N 6060-У "О формах и методиках составления, порядке и сроках представления операторами услуг платежной инфраструктуры, операторами по переводу денежных средств отчетности по обеспечению защиты информации при осуществлении переводов денежных средств;
- Указанием Банка России от 8 октября 2018 года N 4926-У "О форме и порядке направления операторами по переводу денежных средств, операторами платежных систем, операторами услуг платежной инфраструктуры в Банк России информации обо всех случаях и (или) попытках осуществления переводов денежных средств без согласия клиента и получения ими от Банка России информации, содержащейся в базе данных о случаях и попытках осуществления переводов денежных средств без согласия клиента, а также о порядке реализации операторами по переводу денежных средств, операторами платежных систем, операторами услуг платежной инфраструктуры мероприятий по противодействию осуществлению переводов денежных средств без согласия клиента";
- ОУИО СБП обязан информировать участника СБП о нарушениях требований к обеспечению защиты информации при осуществлении переводов денежных средств, в том числе о тех, которые привели или могут привести к осуществлению переводов денежных средств без согласия клиента или к неоказанию услуг по переводу денежных средств, в соответствии с договором между участником СБП и ОУИО СБП, предусмотренным пунктом 33 статьи 3 Федерального закона от 27 июня 2011 года N 161-ФЗ.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
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.
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
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.26
А.5.26 Реагирование на инциденты ИБ
Реагирование на инциденты ИБ должно осуществляться в соответствии с документированными процедурами.
Реагирование на инциденты ИБ должно осуществляться в соответствии с документированными процедурами.
Положение Банка России № 719-П от 04.06.2020 "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств":
Глава 2 п. 6
2.6. Операторы по переводу денежных средств должны установить порядок их информирования привлекаемыми ими банковскими платежными агентами (субагентами), операторами услуг информационного обмена о выявленных инцидентах защиты информации. Операторы по переводу денежных средств по запросу Банка России должны направлять в Банк России сведения об инцидентах защиты информации, полученные от привлекаемых ими банковских платежных агентов (субагентов), операторов услуг информационного обмена.
Глава 5 п. 2
5.2. Оператор платежной системы в целях снижения риска информационной безопасности в платежной системе должен реализовывать механизмы совершенствования требований, указанных в пункте 5.4 настоящего Положения, предусматривающие в том числе накопление и учет опыта реагирования на инциденты защиты информации и восстановления функционирования платежной системы после их реализации.
Глава 5 п. 1
5.1. Оператор платежной системы в целях реализации пункта 11 части 3 статьи 28 Федерального закона № 161-ФЗ (Собрание законодательства Российской Федерации, 2011, № 27, ст. 3872) в рамках системы управления рисками в платежной системе определяет в правилах платежной системы и иных документах порядок обеспечения защиты информации в платежной системе для операторов по переводу денежных средств, являющихся участниками платежной системы, операторов услуг платежной инфраструктуры с учетом требований к обеспечению защиты информации при осуществлении переводов денежных средств (далее - требования к обеспечению защиты информации в платежной системе).
Оператор платежной системы должен определить требования к обеспечению защиты информации в платежной системе в отношении следующих мероприятий:
- управление риском информационной безопасности в платежной системе как одним из видов операционного риска в платежной системе, источниками реализации которого являются: недостатки процессов обеспечения защиты информации, в том числе недостатки применяемых технологических мер защиты информации, недостатки прикладного программного обеспечения автоматизированных систем и приложений, а также несоблюдение требований к указанным процессам деятельности операторами по переводу денежных средств, являющимися участниками платежной системы, операторами услуг платежной инфраструктуры (далее - риск информационной безопасности в платежной системе);
- установление состава показателей уровня риска информационной безопасности в платежной системе;
- реализация операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры механизмов, направленных на соблюдение требований к обеспечению защиты информации при осуществлении переводов денежных средств, и контроль их соблюдения операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры;
- реализация операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры процессов выявления и идентификации риска информационной безопасности в платежной системе в отношении объектов информационной инфраструктуры участников платежной системы, операторов услуг платежной инфраструктуры;
- выявление и анализ операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры риска информационной безопасности в платежной системе;
- реализация операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры процессов реагирования на инциденты защиты информации и восстановления штатного функционирования объектов информационной инфраструктуры в случае реализации инцидентов защиты информации;
- реализация операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры взаимодействия при обмене информацией об инцидентах защиты информации;
- реализация операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры мероприятий по противодействию осуществлению переводов денежных средств без согласия клиента, определенных пунктами 2.2 и 2.4 Указания Банка России от 8 октября 2018 года № 4926-У «О форме и порядке направления операторами по переводу денежных средств, операторами платежных систем, операторами услуг платежной инфраструктуры в Банк России информации обо всех случаях и (или) попытках осуществления переводов денежных средств без согласия клиента и получения ими от Банка России информации, содержащейся в базе данных о случаях и попытках осуществления переводов денежных средств без согласия клиента, а также о порядке реализации операторами по переводу денежных средств, операторами платежных систем, операторами услуг платежной инфраструктуры мероприятий по противодействию осуществлению переводов денежных средств без согласия клиента», зарегистрированного Министерством юстиции Российской Федерации 12 декабря 2018 года № 52988;
- реализация операторами платежных систем процессов применения в отношении операторов по переводу денежных средств, являющихся участниками платежной системы, и операторов услуг платежной инфраструктуры ограничений по параметрам операций по осуществлению переводов денежных средств в случае выявления факта превышения значений показателей уровня риска информационной безопасности в платежной системе, в том числе условий снятия таких ограничений.
Методика экспресс-оценки уровня кибербезопасности организации РезБез:
4.2.1.1.
Разработаны сценарии реагирования (плейбуки) на типовые инциденты ИБ, сценарии реагирования регулярно тестируются практическим способом в ходе киберучений
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
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":
А.5.26
А.5.26 Response to information security incidents
Information security incidents shall be responded to in accordance with the documented procedures.
Information security incidents shall be responded to in accordance with the documented procedures.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.