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

Положение Банка России № 719-П от 04.06.2020

О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств

Глава 5 п. 1

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

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

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

Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 8 п. 7 п.п. 2
8.7.2. Все планы внедрения СОИБ, в частности планы реализации требований разделов 7 и 8 настоящего стандарта, планы обработки рисков нарушения ИБ и внедрения защитных мер, должны быть утверждены руководством. Указанные планы должны определять: 
  • последовательность выполнения мероприятий в рамках указанных планов; 
  • сроки начала и окончания запланированных мероприятий; 
  • должностных лиц (подразделения), ответственных за выполнение каждого указанного мероприятия. 
Р. 8 п. 11 п.п. 4
8.11.4. Разработка планов обеспечения непрерывности бизнеса и его восстановления после прерывания должна основываться на результатах оценки рисков нарушения ИБ организации БС РФ применительно к информационным активам, существенным для обеспечения непрерывности бизнеса и его восстановления после прерывания. 
Р. 8 п. 5 п.п. 4
8.5.4. В организации БС РФ должны быть определены роли по разработке планов обработки рисков нарушения ИБ и назначены ответственные за выполнение указанных ролей. 
Р. 8 п. 4 п.п. 6
8.4.6. В организации БС РФ должны быть определены роли, связанные с деятельностью по определению/коррекции методики оценки рисков нарушения ИБ/подхода к оценке рисков нарушения ИБ и назначены ответственные за выполнение указанных ролей. 
Р. 8 п. 7 п.п. 1
8.7.1. Решения о реализации и эксплуатации СОИБ должны утверждаться руководством организации БС РФ. В частности, в организации БС РФ требуется зафиксировать решения руководства:
  • об анализе и принятии остаточных рисков нарушения ИБ;
  • о планировании этапов внедрения СОИБ, в частности требований по обеспечению ИБ, изложенных в разделах 7 и 8 настоящего стандарта;
  • о распределении ролей в области обеспечения ИБ организации БС РФ;
  • о принятии со стороны руководства планов внедрения защитных мер, направленных на реализацию требований разделов 7 и 8 настоящего стандарта и снижение рисков ИБ;
  • о выделении ресурсов, необходимых для реализации и эксплуатации СОИБ. 
Р. 8 п. 4 п.п. 1
8.4.1. В организации БС РФ должна быть принята/корректироваться методика оценки рисков нарушения ИБ/подход к оценке рисков нарушения ИБ. 
Р. 8 п. 4 п.п. 2
8.4.2. В организации БС РФ должны быть определены критерии принятия рисков нарушения ИБ и уровень допустимого риска нарушения ИБ. 
Р. 8 п. 8 п.п. 3
8.8.3. В организации БС РФ должны быть определены роли, связанные с реализацией планов обработки рисков нарушения ИБ и с реализацией требуемых защитных мер, и назначены ответственные за выполнение указанных ролей. 
Р. 8 п. 4 п.п. 3
8.4.3. Методика оценки рисков нарушения ИБ/подход к оценке рисков нарушения ИБ организации БС РФ должна определять способ и порядок качественного или количественного оценивания риска нарушения ИБ на основании оценивания:
  • степени возможности реализации угроз ИБ выявленными и (или) предполагаемыми источниками угроз ИБ, зафиксированными в моделях угроз и нарушителя, в результате их воздействия на объекты среды информационных активов организации БС РФ (типов информационных активов);
  • степени тяжести последствий от потери свойств ИБ, в частности свойств доступности, целостности и конфиденциальности, для рассматриваемых информационных активов (типов информационных активов). Порядок оценки рисков нарушения ИБ должен определять необходимые процедуры оценки рисков нарушения ИБ, а также последовательность их выполнения. 
Р. 8 п. 10 п.п. 1
8.10.1. Должны быть определены, выполняться, регистрироваться и контролироваться процедуры обработки инцидентов, включающие:
  • процедуры обнаружения инцидентов ИБ;
  • процедуры информирования об инцидентах, в том числе информирования службы ИБ;
  • процедуры классификации инцидентов и оценки ущерба, нанесенного инцидентом ИБ;
  •  — процедуры реагирования на инцидент;
  •  — процедуры анализа причин инцидентов ИБ и оценки результатов реагирования на инциденты ИБ (при необходимости с участием внешних экспертов в области ИБ). 
Р. 8 п. 10 п.п. 6
8.10.6. В организации БС РФ должны быть определены роли по обнаружению, классификации, реагированию, анализу и расследованию инцидентов ИБ и назначены ответственные за выполнение указанных ролей. 
ГОСТ Р № 57580.3-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Управление риском реализации информационных угроз и обеспечение операционной надежности. Общие положения.":
ОПР.1.2
ОПР.1.2 Описание структуры и подходов к интеграции процессов управления риском реализации информационных угроз в систему управления операционным риском финансовой организации; 
ОПР.1.5
ОПР.1.5 Порядок утверждения и условия пересмотра структуры и организации систем управления риском реализации информационных угроз, операционной надежности и защиты информации.
ОПР.1.1
ОПР.1.1 Определение и описание состава процессов управления риском реализации информационных угроз, обеспечения операционной надежности и защиты информации; 
ОПР.1.3
ОПР.1.3 Определение организационной структуры финансовой организации, задействованной в выполнении процессов управления риском реализации информационных угроз, обеспечения операционной надежности и защиты информации, в том числе установление функций подразделений финансовой организации (включая принятие решений с учетом исключения конфликта интересов) и контроль за выполнением процессов в рамках порядка организации и осуществления финансовой организацией внутреннего контроля; 
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 6
6. Кредитные организации должны разработать во внутренних документах и выполнять требования к операционной надежности, которые включают в себя:
  • требования к порядку определения значений целевых показателей операционной надежности и обеспечению контроля за их соблюдением;
  • требования к идентификации состава элементов, указанных в подпункте 6.1 настоящего пункта;
  • требования к управлению изменениями элементов, указанных в подпункте 6.1 настоящего пункта;
  • требования к выявлению, регистрации инцидентов операционной надежности и реагированию на них, а также восстановлению выполнения технологических процессов и функционирования объектов информационной инфраструктуры после реализации указанных инцидентов с учетом установленных главой 7 Положения Банка России N 716-П требований к выявлению событий риска информационной безопасности, порядку реагирования на выявленные события риска информационной безопасности и восстановлению деятельности кредитной организации в случае реализации таких событий;
  • требования к взаимодействию с третьими лицами (внешними подрядчиками, контрагентами, участниками банковской группы), оказывающими услуги в сфере информационных технологий, связанные с выполнением технологических процессов (далее - поставщики услуг в сфере информационных технологий), с учетом установленных главами 7 и 8 Положения Банка России N 716-П требований к управлению риском информационной безопасности и риском информационных систем при передаче поставщикам услуг в сфере информационных технологий выполнения отдельных функций кредитной организации и (или) использовании внешних информационных систем, а также требований к аутсорсингу обслуживания и функционирования информационных систем;
  • требования к тестированию операционной надежности технологических процессов;
  • требования к нейтрализации информационных угроз со стороны несанкционированного доступа работников кредитной организации или работников поставщиков услуг в сфере информационных технологий, обладающих полномочиями доступа к объектам информационной инфраструктуры (далее - внутренний нарушитель), к объектам информационной инфраструктуры;
  • требования к обеспечению осведомленности кредитной организации об актуальных информационных угрозах, которые могут привести к инцидентам операционной надежности.
п. 3
3. Кредитные организации с учетом требований главы 5 Положения Банка России N 716-П должны определить во внутренних документах для каждого технологического процесса и соблюдать значения следующих контрольных показателей уровня операционного риска для целей обеспечения операционной надежности (далее - целевые показатели операционной надежности):

  • допустимого отношения общего количества банковских операций и иных операций, осуществляемых в рамках технологического процесса, совершенных во время нарушений технологических процессов, приводящих к неоказанию или ненадлежащему оказанию банковских услуг (далее - деградация технологического процесса (технологических процессов), в рамках события операционного риска или серии связанных событий операционного риска, вызванных информационными угрозами и (или) сбоями объектов информационной инфраструктуры, которые привели к неоказанию или ненадлежащему оказанию банковских услуг (далее - инцидент операционной надежности), к ожидаемому количеству банковских операций и иных операций, осуществляемых в рамках технологических процессов, за тот же период в случае непрерывного оказания банковских услуг, установленного кредитной организацией (далее - допустимая доля деградации технологического процесса);
  • допустимого времени простоя и (или) деградации технологических процессов кредитных организаций в рамках инцидента операционной надежности (в случае превышения допустимой доли деградации технологического процесса). Значение данного целевого показателя устанавливается кредитной организацией не выше значений, предусмотренных приложением к настоящему Положению;
  • допустимого суммарного времени простоя и (или) деградации технологического процесса кредитной организации (в случае превышения допустимой доли деградации технологического процесса) в течение очередного календарного года;
  • показателя соблюдения режима работы (функционирования) технологического процесса (времени начала, времени окончания, продолжительности и последовательности процедур в рамках технологического процесса).
Значение допустимой доли деградации технологических процессов должно рассчитываться кредитной организацией на основании статистических данных за период не менее двенадцати календарных месяцев, предшествующих дате определения значения целевого показателя операционной надежности, за исключением случая, предусмотренного абзацем седьмым настоящего пункта, и (или) иных данных, обосновывающих их определение (по выбору кредитной организации).

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

ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
РИ.6
РИ.6 Установление и применение единых правил реагирования на инциденты защиты информации
3-О 2-О 1-О
NIST Cybersecurity Framework (RU):
ID.RM-3
ID.RM-3: Определение отношения (степени принятия риска) к риску организации основывается на ее роли в  критической инфраструктуре и анализе рисков для конкретных секторов 
ID.RM-2
ID.RM-2: Определен и четко выражен критерий принятия риска в организации 
PR.IP-9
PR.IP-9:  Созданы и управляются планы реагирования (реагирование на инциденты и непрерывность бизнеса) и планы восстановления (восстановление после инцидентов и аварийное  восстановление) 
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ИНЦ.2 ИНЦ.2 Обнаружение, идентификация и регистрация инцидентов
ИНЦ.5 ИНЦ.5 Принятие мер по устранению последствий инцидентов
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Тело стандарта":
6.1.2 Оценка рисков информационной безопасности
6.1.2 Оценка рисков информационной безопасности
Организация должна определить и применять процесс оценки рисков информационной безопасности, который
  • а) устанавливает и поддерживает критерии рисков информационной безопасности, которые включают в себя:
    • 1) критерии приемлемости рисков; а также
    • 2) критерии выполнения оценок рисков информационной безопасности;
  • b) обеспечивает выработку повторяющимися оценками рисков информационной безопасности цельных, достоверных и сравнимых результатов;
  • c) выявляет риски информационной безопасности:
    • 1) применение процесса оценки рисков информационной безопасности с целью выявления рисков, связанных с потерей конфиденциальности, целостности и доступности информации в пределах области действия системы менеджмента информационной безопасности; а также
    • 2) выявление владельцев рисков;
  • d) анализирует риски информационной безопасности:
    • 1) оценка возможных последствий, которые могут произойти в результате реализации рисков, выявленных в п.6.1.2 с)1);
    • 2) оценка реалистичной вероятности реализации рисков, выявленных в п.6.1.2 с)1); а также
    • 3) определение уровней рисков;
  • e) оценивает риски информационной безопасности:
    • 1) сравнение результатов анализа рисков с критериями, установленными в п.6.1.2 а); а также
    • 2) расставляет приоритеты обработки проанализированных рисков.
Организация должна сохранять документированную информацию о процессе оценки рисков информационной безопасности.
8.2 Оценка рисков информационной безопасности
8.2 Оценка рисков информационной безопасности
Организация должна выполнять оценки рисков информационной безопасности в запланированные интервалы времени или при наступлении или предполагаемом наступлении значительных изменений, при этом учитываются критерии, установленные в п.6.1.2 а).
Организация должна сохранять документированную информацию по результатам оценок рисков информационной безопасности.
8.3 Обработка рисков информационной безопасности
8.3 Обработка рисков информационной безопасности
Организация должна внедрить план обработки рисков информационной безопасности.
Организация должна сохранять документированную информацию по результатам обработки рисков информационной безопасности.
6.1.3 Обработка рисков информационной безопасности
6.1.3 Обработка рисков информационной безопасности
Организация должна определить и применять процесс обработки рисков в целях:
  • a) выбора применимых вариантов обработки рисков информационной безопасности, учитывающих результаты оценки рисков;
  • b) определения всех средств управления информационной безопасностью, необходимых для внедрения выбранного варианта (-ов) обработки рисков информационной безопасности; 
ПРИМЕЧАНИЕ 1 Организация может разработать средства управления информационной безопасностью, по мере необходимости, или определить их из иного источника.

  • c) сравнения средств управления информационной безопасностью, вышеопределенных в п.6.1.3 b) и содержащихся в Приложении А, а также подтверждения того, что ни одно необходимое средство управления информационной безопасностью не пропущено;
ПРИМЕЧЕНИЕ 2 Приложение А содержит перечень средств управления информационной безопасностью. Пользователи настоящего документа отсылаются к Приложению А для обеспечения того, что ни одно необходимое средство управления информационной безопасностью не будет пропущено.
ПРИМЕЧАНИЕ 3 Перечисленные в Приложении А средства управления информационной безопасностью не являются исчерпывающими и, по необходимости, могут быть применены потребоваться дополнительные средства управления информационной безопасностью.

  • d) выработки Положения о Применимости, которое содержит:
    • необходимые средства управления информационной безопасностью (см. п.6.1.3 b) и с));
    • обоснование их применения;
    • сведения от том, реализованы они или нет, а также
    • обоснование исключения из применения приведенных в Приложении А средств управления информационной безопасностью.
  • e) разработки плана обработки рисков; а также
  • f) получения одобрения плана обработки рисков информационной безопасности и остаточных рисков информационной безопасности со стороны владельцев рисков.
Организация должна сохранять документированную информацию о процессе обработки рисков информационной безопасности.
ПРИМЕЧАНИЕ 4 Процесс оценки и обработки рисков информационной безопасности в настоящем документе соответствует принципам и общим указаниям, изложенным в ИСО 31000.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования":
8.3
 8.3 Обработка рисков информационной безопасности 
Организация должна реализовать план обработки рисков информационной безопасности. Организация должна хранить документированную информацию о результатах обработки рисков информационной безопасности. 
8.2
 8.2 Оценка рисков информационной безопасности 
Организация должна проводить оценку рисков информационной безопасности через запланированные интервалы времени или в случае предполагаемых или произошедших существенных изменений, учитывая критерии рисков информационной безопасности, установленные в соответствии с 6.1.2 а). 
Организация должна хранить документированную информацию о результатах проведенных оценок рисков информационной безопасности. 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 12.10.7
12.10.7
Defined Approach Requirements: 
 Incident response procedures are in place, to be initiated upon the detection of stored PAN anywhere it is not expected, and include:
  • Determining what to do if PAN is discovered outside the CDE, including its retrieval, secure deletion, and/or migration into the currently defined CDE, as applicable.
  • Identifying whether sensitive authentication data is stored with PAN.
  • Determining where the account data came from and how it ended up where it was not expected.
  • Remediating data leaks or process gaps that resulted in the account data being where it was not expected. 
Customized Approach Objective:
Processes are in place to quickly respond, analyze, and address situations in the event that cleartext PAN is detected where it is not expected. 

Applicability Notes:
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:
  • 12.10.7.a Examine documented incident response procedures to verify that procedures for responding to the detection of stored PAN anywhere it is not expected to exist, ready to be initiated, and include all elements specified in this requirement. 
  • 12.10.7.b Interview personnel and examine records of response actions to verify that incident response procedures are performed upon detection of stored PAN anywhere it is not expected. 
Purpose:
Having documented incident response procedures that are followed in the event that stored PAN is found anywhere it is not expected to be, helps to identify the necessary remediation actions and prevent future leaks. 

Good Practice:
If PAN was found outside the CDE, analysis should be performed to 1) determine whether it was saved independently of other data or with sensitive authentication data, 2) identify the source of the data, and 3) identify the control gaps that resulted in the data being outside the CDE. 
Entities should consider whether there are contributory factors, such as business processes, user behavior, improper system configurations, etc. that caused the PAN to be stored in an unexpected location. If such contributory factors are present, they should be addressed per this Requirement to prevent recurrence. 
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. 
Requirement 12.10.5
12.10.5
Defined Approach Requirements: 
The security incident response plan includes monitoring and responding to alerts from security monitoring systems, including but not limited to:
  • Intrusion-detection and intrusion-prevention systems.
  • Network security controls.
  • Change-detection mechanisms for critical files.
  • The change-and tamper-detection mechanism for payment pages. This bullet is a best practice until its effective date; refer to Applicability Notes below for details.
  • Detection of unauthorized wireless access points. 
Customized Approach Objective:
Alerts generated by monitoring and detection technologies are responded to in a structured, repeatable manner. 

Applicability Notes:
The bullet above (for monitoring and responding to alerts from a change- and tamper-detection mechanism for payment pages) is a best practice until 31 March 2025, after which it will be required as part of Requirement 12.10.5 and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:
  • 12.10.5 Examine documentation and observe incident response processes to verify that monitoring and responding to alerts from security monitoring systems are covered in the security incident response plan, including but not limited to the systems specified in this requirement. 
Purpose:
Responding to alerts generated by security monitoring systems that are explicitly designed to focus on potential risk to data is critical to prevent a breach and therefore, this must be included in the incident-response processes. 
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.2
12.10.2
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:
  • 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. 
Приказ ФСБ России № 282 от 19.06.2019 "Порядок информирования ФСБ России о компьютерных инцидентах, реагирования на них, принятия мер по ликвидации последствий компьютерных атак, проведенных в отношении значимых объектов критической информационной инфраструктуры Российской Федерации":
п. 6
6. Для подготовки к реагированию на компьютерные инциденты и принятию мер по ликвидации последствий компьютерных атак субъектом критической информационной инфраструктуры, которому на праве собственности, аренды или ином законном основании принадлежит значимый объект критической информационной инфраструктуры, в срок до 90 календарных дней со дня включения данного объекта в реестр значимых объектов критической информационной инфраструктуры Российской Федерации (см 1) разрабатывается план реагирования на компьютерные инциденты и принятия мер по ликвидации последствий компьютерных атак (далее - План), содержащий:
  • технические характеристики и состав значимых объектов критической информационной инфраструктуры;
  • события (условия), при наступлении которых начинается реализация предусмотренных Планом мероприятий;
  • мероприятия, проводимые в ходе реагирования на компьютерные инциденты и принятия мер по ликвидации последствий компьютерных атак, а также время, отводимое на их реализацию;
  • описание состава подразделений и должностных лиц субъекта критической информационной инфраструктуры, ответственных за проведение мероприятий по реагированию на компьютерные инциденты и принятие мер по ликвидации последствий компьютерных атак.
(1) Порядок ведения реестра значимых объектов критической информационной инфраструктуры Российской Федерации, утвержденный приказом ФСТЭК России от 6 декабря 2017 г. N 227 "Об утверждении Порядка ведения реестра значимых объектов критической информационной инфраструктуры Российской Федерации" (зарегистрирован Минюстом России 8 февраля 2018 г., регистрационный N 49966).
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.16.1.5
A.16.1.5 Реагирование на инциденты информационной безопасности 
Мера обеспечения информационной безопасности: Реагирование на инциденты информационной безопасности должно осуществляться в соответствии с документально оформленными процедурами 
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Body":
8.2 Information security risk assessment
8.2 Information security risk assessment
The organization shall perform information security risk assessments at planned intervals or when significant changes are proposed or occur, taking account of the criteria established in 6.1.2 a).
The organization shall retain documented information of the results of the information security risk assessments.
6.1.2 Information security risk assessment
6.1.2 Information security risk assessment
The organization shall define and apply an information security risk assessment process that:
  • a) establishes and maintains information security risk criteria that include:
    • 1) the risk acceptance criteria; and
    • 2) criteria for performing information security risk assessments;
  • b) ensures that repeated information security risk assessments produce consistent, valid and comparable results;
  • c) identifies the information security risks:
    • 1) apply the information security risk assessment process to identify risks associated with the loss of confidentiality, integrity and availability for information within the scope of the information security management system; and
    • 2) identify the risk owners;
  • d) analyses the information security risks:
    • 1) assess the potential consequences that would result if the risks identified in 6.1.2 c) 1) were to materialize;
    • 2) assess the realistic likelihood of the occurrence of the risks identified in 6.1.2 c) 1); and
    • 3) determine the levels of risk;
  • e) evaluates the information security risks:
    • 1) compare the results of risk analysis with the risk criteria established in 6.1.2 a); and
    • 2) prioritize the analysed risks for risk treatment.
The organization shall retain documented information about the information security risk assessment process.
8.3 Information security risk treatment
8.3 Information security risk treatment
The organization shall implement the information security risk treatment plan.
The organization shall retain documented information of the results of the information security risk treatment.
6.1.3 Information security risk treatment
6.1.3 Information security risk treatment
The organization shall define and apply an information security risk treatment process to:
  • a) select appropriate information security risk treatment options, taking account of the risk assessment results;
  • b) determine all controls that are necessary to implement the information security risk treatment option(s) chosen;
NOTE 1 Organizations can design controls as required, or identify them from any source.

  • c) compare the controls determined in 6.1.3 b)  above with those in Annex A and verify that no necessary controls have been omitted;
NOTE 2 Annex A contains a list of possible information security controls. Users of this document are directed to Annex A to ensure that no necessary information security controls are overlooked.
NOTE 3 The information security controls listed in Annex A are not exhaustive and additional information security controls can be included if needed.

  • d) produce a Statement of Applicability that contains:·  the necessary controls (see 6.1.3 b) and c));· justification for their inclusion;· whether the necessary controls are implemented or not; and· the justification for excluding any of the Annex A controls.;
  • e) formulate an information security risk treatment plan; and
  • f) obtain risk owners’ approval of the information security risk treatment plan and acceptance of the residual information security risks.
The organization shall retain documented information about the information security risk treatment process.
NOTE 4 The information security risk assessment and treatment process in this document aligns with the principles and generic guidelines provided in ISO 31000.
Положение Банка России № 802-П от 25.07.2022 "О требованиях к защите информации в платежной системе Банка России":
П. 16.2
16.2. Участник СБП - банк получателя должен осуществлять формирование индикатора уровня риска операции в рамках реализуемой им системы управления рисками, применяемой для выявления операций, соответствующих признакам осуществления переводов денежных средств без согласия клиента, и его направление в электронном сообщении в ОПКЦ СБП в формате и порядке, установленных договором об оказании услуг между участником СБП и ОПКЦ СБП.
П. 16.1
16.1. Участник СБП - банк плательщика должен осуществлять:
  • выявление операций, соответствующих признакам осуществления переводов денежных средств без согласия клиента, установленным Банком России в соответствии с частью 5.1 статьи 8 Федерального закона от 27 июня 2011 года N 161-ФЗ (далее - признаки осуществления переводов денежных средств без согласия клиента), в рамках реализуемой им системы управления рисками при осуществлении переводов денежных средств с использованием сервиса быстрых платежей;
  • приостановление в соответствии с частью 5.1 статьи 8 Федерального закона от 27 июня 2011 года N 161-ФЗ исполнения распоряжения в рамках выявленной операции, соответствующей признакам осуществления переводов денежных средств без согласия клиента, с учетом информации об уровне риска операции без согласия клиента (далее - индикатор уровня риска операции), включенной в электронное сообщение, полученной от ОПКЦ СБП в формате и порядке, установленных договором об оказании услуг между участником СБП и ОПКЦ СБП, содержащей в том числе информацию об индикаторе уровня риска операции, сформированном участником СБП - банком получателя;
  • формирование индикатора уровня риска операции на основе оценки рисков операций в рамках реализуемой участником СБП - банком плательщика системы управления рисками и его направление в электронном сообщении в ОПКЦ СБП в формате и порядке, установленных договором об оказании услуг между участником СБП и ОПКЦ СБП, - в случае невыявления признаков осуществления перевода денежных средств без согласия клиента.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 12.10.7
12.10.7
Определенные Требования к Подходу:
Существуют процедуры реагирования на инциденты, которые должны быть инициированы при обнаружении сохраненной информации в любом месте, где она не ожидается, и включают:
  • Определение того, что делать, если PAN обнаружен за пределами CDE, включая его извлечение, безопасное удаление и/или перенос в текущий определенный CDE, в зависимости от обстоятельств.
  • Определение того, хранятся ли конфиденциальные данные аутентификации с помощью PAN.
  • Определение того, откуда взялись данные учетной записи и как они оказались там, где их не ожидали.
  • Устранение утечек данных или пробелов в процессах, которые привели к тому, что данные учетной записи оказались там, где их не ожидали.
Цель Индивидуального подхода:
Существуют процессы для быстрого реагирования, анализа и устранения ситуаций в случае обнаружения открытого текстового сообщения там, где этого не ожидается.

Примечания по применению:
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

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

Надлежащая практика:
Если PAN был обнаружен за пределами CDE, следует выполнить анализ, чтобы 1) определить, был ли он сохранен независимо от других данных или с конфиденциальными данными аутентификации, 2) определить источник данных и 3) выявить пробелы в контроле, которые привели к тому, что данные оказались за пределами CDE.
Организации должны рассмотреть, существуют ли способствующие факторы, такие как бизнес-процессы, поведение пользователей, неправильные конфигурации системы и т.д., Которые привели к хранению PAN в неожиданном месте. Если такие способствующие факторы присутствуют, они должны быть устранены в соответствии с этим Требованием, чтобы предотвратить повторение.
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.5
12.10.5
Определенные Требования к Подходу:
План реагирования на инциденты безопасности включает мониторинг и реагирование на предупреждения от систем мониторинга безопасности, включая, но не ограничиваясь этим:
  • Системы обнаружения вторжений и предотвращения вторжений.
  • Средства контроля сетевой безопасности.
  • Механизмы обнаружения изменений для критически важных файлов.
  • Механизм обнаружения изменений и несанкционированного доступа к платежным страницам. Этот бюллетень является наилучшей практикой до даты его вступления в силу; подробности см. в Примечаниях к применению ниже.
  • Обнаружение несанкционированных точек беспроводного доступа.
Цель Индивидуального подхода:
На предупреждения, генерируемые технологиями мониторинга и обнаружения, реагируют структурированным, повторяющимся образом.

Примечания по применению:
Приведенный выше пункт (для мониторинга и реагирования на предупреждения от механизма обнаружения изменений и несанкционированного доступа к платежным страницам) является наилучшей практикой до 31 марта 2025 года, после чего он потребуется как часть требования 12.10.5 и должен быть полностью рассмотрен во время оценки PCI DSS.

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

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

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

Надлежащая практика:
Работа по извлечению уроков должна охватывать персонал всех уровней. Хотя он часто включается как часть анализа всего инцидента, он должен быть сосредоточен на том, как можно улучшить реакцию организации на инцидент.
Важно не просто рассмотреть элементы реагирования, которые не привели к запланированным результатам, но и понять, что сработало хорошо, и могут ли уроки из тех элементов, которые сработали хорошо, быть применены в тех областях плана, которые не сработали.
Другим способом оптимизации плана реагирования на инциденты организации является понимание атак, совершенных против других организаций, и использование этой информации для точной настройки процедур обнаружения, локализации, смягчения последствий или восстановления организации.
Requirement 12.10.2
12.10.2
Определенные Требования к Подходу:
Не реже одного раза в 12 месяцев план реагирования на инциденты безопасности:
  • Проверяется, и содержание обновляется по мере необходимости.
  • Испытан, включая все элементы, перечисленные в требовании 12.10.1.
Цель Индивидуального подхода:
План реагирования на инциденты поддерживается в актуальном состоянии и периодически проверяется.

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

Надлежащая практика:
Проверка плана реагирования на инциденты может включать имитацию инцидентов и соответствующие меры реагирования в форме “настольных упражнений”, которые включают участие соответствующего персонала. Анализ инцидента и качества реагирования может дать организациям уверенность в том, что все необходимые элементы включены в план.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.26
А.5.26 Реагирование на инциденты ИБ
Реагирование на инциденты ИБ должно осуществляться в соответствии с документированными процедурами.
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ИНЦ.0 ИНЦ.0 Разработка политики реагирования на компьютерные инциденты
ИНЦ.5 ИНЦ.5 Принятие мер по предотвращению повторного возникновения компьютерных инцидентов
ИНЦ.4 ИНЦ.4 Устранение последствий компьютерных инцидентов
ИНЦ.3 ИНЦ.3 Анализ компьютерных инцидентов
ИНЦ.1 ИНЦ.1 Выявление компьютерных инцидентов
NIST Cybersecurity Framework (EN):
ID.RM-3 ID.RM-3: The organization’s determination of risk tolerance is informed by its role in critical infrastructure and sector specific risk analysis
ID.RM-2 ID.RM-2: Organizational risk tolerance is determined and clearly expressed
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
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ИНЦ.0 ИНЦ.0 Регламентация правил и процедур реагирования на компьютерные инциденты
ИНЦ.3 ИНЦ.3 Анализ компьютерных инцидентов
ИНЦ.5 ИНЦ.5 Принятие мер по предотвращению повторного возникновения компьютерных инцидентов
ИНЦ.1 ИНЦ.1 Выявление компьютерных инцидентов
ИНЦ.4 ИНЦ.4 Устранение последствий компьютерных инцидентов
Стандарт № 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.

Связанные защитные меры

Ничего не найдено