Раздел Requirement 10.4.3 PCI DSS 4.0 (En) - Контроль соответствия

CIS Critical Security Controls v8 (The 18 CIS CSC):

17.4

17.4 Establish and Maintain an Incident Response Process
Establish and maintain an incident response process that addresses roles and responsibilities, compliance requirements, and a communication plan. Review annually, or when significant enterprise changes occur that could impact this Safeguard.

17.9

17.9 Establish and Maintain Security Incident Thresholds
Establish and maintain security incident thresholds, including, at a minimum, differentiating between an incident and an event. Examples can include: abnormal activity, security vulnerability, security weakness, data breach, privacy incident, etc. Review annually, or when significant enterprise changes occur that could impact this Safeguard.

Стандарт № GMP Annex 11: Computerised Systems (EN) от 30.11.2011 "Good Manufacturing Practice. Annex 11: Computerised Systems":

Р. 4 п. 13 п.п. 1

All incidents, not only system failures and data errors, should be reported and assessed. The root cause of a critical incident should be identified and should form the basis of corrective and preventive actions.

NIST Cybersecurity Framework (RU):

RS.CO-2

RS.CO-2: События сообщаются в соответствии с установленными критериями

DE.AE-5

DE.AE-5: Установлены пороги оповещения об инциденте

Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":

РСБ.4 РСБ.4 Реагирование на сбои при регистрации событий безопасности, в том числе аппаратные и программные ошибки, сбои в механизмах сбора информации и достижение предела или переполнения объема (емкости) памяти

РСБ.5 РСБ.5 Мониторинг (просмотр, анализ) результатов регистрации событий безопасности и реагирование на них

Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):

17.4

17.4 Реализован и поддерживается процесс ответа на сообщения об инцидентах
Процесс включает роли и обязанности, показатели работы и план коммуникации по поводу инцидента.

17.9

17.9 Определены и поддерживаются пороговые значения для инцидентов безопасности
Сценарий реагирования разработан для разных событий безопасности: подозрительной активности, обнаруженной уязвимости, утечки информации и так далее.

Стандарт № 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 10.4.3

10.4.3
Определенные Требования к Подходу:
Исключения и аномалии, выявленные в ходе процесса проверки, устраняются.

Цель Индивидуального подхода:
Рассматриваются подозрительные или аномальные действия.

Определенные Процедуры Тестирования Подхода:

10.4.3.a Изучите политики и процедуры безопасности, чтобы убедиться, что определены процессы для устранения исключений и аномалий, выявленных в процессе проверки.
10.4.3.b Наблюдайте за процессами и проводите собеседования с персоналом, чтобы убедиться, что при выявлении исключений и аномалий они устраняются.

Цель:
Если исключения и аномалии, выявленные в процессе просмотра журнала, не исследуются, организация может не знать о несанкционированных и потенциально вредоносных действиях, происходящих в ее сети.

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

Как записываются действия по проверке журнала, • Как ранжировать и расставлять приоритеты исключений и аномалий,
Какие процедуры должны быть предусмотрены для сообщения об исключениях и аномалиях и их эскалации, а также
Кто отвечает за расследование и за любые задачи по исправлению положения.

Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":

РСБ.4 РСБ.4 Реагирование на сбои при регистрации событий безопасности, в том числе аппаратные и программные ошибки, сбои в механизмах сбора информации и достижение предела или переполнения объема (емкости) памяти

РСБ.5 РСБ.5 Мониторинг (просмотр, анализ) результатов регистрации событий безопасности и реагирование на них

SWIFT Customer Security Controls Framework v2022:

7 - 7.1 Cyber Incident Response Planning

7.1 Cyber Incident Response Planning

Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":

АУД.8 АУД.8 Реагирование на сбои при регистрации событий безопасности

АУД.2 АУД.2 Анализ уязвимостей и их устранение

Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":

п. 1.6.

1.6. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны обеспечивать в отношении выявления, регистрации событий операционного риска, связанных с нарушением операционной надежности, и реагирования на них, а также восстановления выполнения технологических процессов, указанных в приложении к настоящему Положению, и функционирования своих объектов информационной инфраструктуры после реализации указанных событий выполнение следующих требований:

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

NIST Cybersecurity Framework (EN):

RS.CO-2 RS.CO-2: Incidents are reported consistent with established criteria

DE.AE-5 DE.AE-5: Incident alert thresholds are established

Стандарт Банка России № РС БР ИББС-2.5-2014 от 01.06.2014 "Менеджмент инцидентов информационной безопасности":

Р. 7 п. 3 п.п. 1

7.3.1. Рекомендуется организовать деятельность по обнаружению и реагированию на инциденты ИБ в соответствии со следующим общим алгоритмом:

обнаружение событий ИБ, выполняемое работниками организации БС РФ и (или) техническими средствами. Работник организации БС РФ осуществляет первичное документирование информации об обнаруженном событии ИБ и оповещение оператора-диспетчера ГРИИБ в соответствии с установленным регламентом. Для обнаружения событий ИБ работники организации БС РФ используют доведенный до них перечень событий ИБ. Технические средства эксплуатируются в соответствии с документацией, согласованной со службой ИБ организации БС РФ. Информацию о событиях ИБ, выявляемых клиентами и партнерами организации БС РФ, рекомендуется также доводить до оператора-диспетчера ГРИИБ;
регистрация информации о событиях ИБ, включая сбор информации, связанной с событием ИБ, первичную оценку собранной информации, выполняемые оператором-диспетчером ГРИИБ. Основная задача при первичной оценке — определение, является ли событие ИБ инцидентом ИБ, в частности, произошло ли нарушение ИБ или требований к обеспечению ИБ, установленных для организации БС РФ. Рекомендуется использование технических средств мониторинга ИБ, осуществляющих автоматическое обнаружение инцидентов ИБ из потока информации о событиях ИБ в соответствии с установленными правилами корреляции событий ИБ;
оповещение членов и (или) руководителя ГРИИБ об инциденте ИБ, выполняемое оператором-диспетчером ГРИИБ. В зависимости от характера инцидента ИБ на основе критериев, установленных в регламенте работы оператора-диспетчера ГРИИБ, оповещается определенный аналитик ГРИИБ, руководитель определенной функциональной группы ГРИИБ и (или) руководитель ГРИИБ;
вторичная оценка инцидента ИБ, выполняемая аналитиком ГРИИБ с целью подтвердить или опровергнуть то, что обнаруженное событие ИБ является инцидентом ИБ;
в случае подтверждения того, что обнаруженное событие ИБ является инцидентом ИБ, принятие конкретных мер по закрытию инцидента ИБ, в том числе принятие решения об эскалации инцидента ИБ, устранение нарушения в СОИБ организации БС РФ, прекращение воздействия реализовавшейся угрозы (угроз) ИБ, восстановление выполнения банковских технологических процессов организации БС РФ;
эскалация инцидента ИБ и привлечение дополнительной компетенции для его обработки. Необходимость эскалации определяет руководитель ГРИИБ и в случае необходимости обращается к куратору ГРИИБ. Эскалация может быть иерархической — если полномочий руководителя ГРИИБ недостаточно для выполнения действий в рамках реагирования на инциденты ИБ, которые, по его мнению, необходимо осуществить (например, прекратить выполнение определенных банковских технологических процессов), а также функциональной — если требуется привлечение специалистов, не входящих в состав ГРИИБ. К иерархической эскалации относится также обращение в ГРИИБ центрального уровня в случае невозможности закрытия инцидента ИБ силами ГРИИБ филиала организации БС РФ или при других обстоятельствах, например в случае невозможности закрытия инцидента ИБ силами ГРИИБ филиала организации БС РФ в установленный срок;
в случае если инцидент ИБ может привести к судебному разбирательству против лица или организации, а также для проведения дисциплинарных процедур в организации БС РФ вся информация, относящаяся к данному инциденту ИБ, должна быть собрана, сохранена и представлена с целью проведения дальнейшего анализа и возможного принятия судом в качестве доказательства. В зависимости от характера инцидента ИБ желательно максимально полное дублирование журналов о событиях ИБ и об инцидентах ИБ с учетом возможности сохранения необходимости указанных действий и после закрытия инцидента ИБ;
принятие решения о закрытии инцидента, утверждаемое руководителем ГРИИБ, осуществляемое только после полного восстановления нарушений в СОИБ организации БС РФ, выполнения банковских технологических процессов организации БС РФ, последствий реализации угрозы ИБ, выяснения причин всех проявлений нештатного выполнения бизнес-процессов организации БС РФ и нетипичного поведения работников организации БС РФ.

Р. 6 п. 1 п.п. 2 п.п.п. 1

1. Цель и задачи менеджмента инцидентов ИБ. Основные цели менеджмента инцидентов ИБ, устанавливаемые политикой менеджмента инцидентов ИБ организации БС РФ, должны определять:

создание условий для осуществления своевременного обнаружения и оперативного реагирования на инциденты ИБ, в том числе их закрытия;
предотвращение и (или) снижение негативного влияния инцидентов ИБ на выполнение банковских технологических процессов организации БС РФ и (или) ее клиентов;
оперативное совершенствование СОИБ организации БС РФ.

Основные задачи, устанавливаемые политикой менеджмента инцидентов ИБ организации БС РФ и решаемые в рамках менеджмента инцидентов ИБ, должны обеспечивать достижение установленных целей менеджмента инцидентов ИБ путем:

своевременного обнаружения инцидентов ИБ;
оперативного реагирования на инциденты ИБ в соответствии с требованиями законодательства РФ, нормативных актов Банка России и регламентами, установленными внутренними документами организации БС РФ;
координации деятельности работников структурных подразделений организации БС РФ в рамках процессов реагирования на инциденты ИБ, в том числе их закрытия;
ведения базы данных зарегистрированных событий ИБ и обнаруженных инцидентов ИБ;
накопления и повторного использования знаний по обнаружению инцидентов ИБ и реагированию на них;
анализа, оценки эффективности и совершенствования процессов менеджмента инцидентов ИБ организации БС РФ;
предоставления руководству организации БС РФ информации и отчетов по результатам выполнения процессов менеджмента инцидентов ИБ, в том числе информации о фактах обнаружения инцидентов ИБ и результатах реагирования на них.

Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":

АУД.2 АУД.2 Анализ уязвимостей и их устранение

АУД.8 АУД.8 Реагирование на сбои при регистрации событий безопасности

Framework № PCI DSS 4.0 от 01.03.2022

Payment Card Industry Data Security Standard

Requirement 10.4.3

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

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

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