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

ГОСТ Р № 57580.1-2017 от 01.01.2018

Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации

РИ.1

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

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

Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 6. п.п. 3
6.3. Кредитные организации должны обеспечивать выполнение следующих требований к выявлению, регистрации инцидентов операционной надежности и реагированию на них, а также восстановлению выполнения технологических процессов и функционирования объектов информационной инфраструктуры после реализации таких инцидентов:
  • выявление и регистрация инцидентов операционной надежности;
  • реагирование на инциденты операционной надежности в отношении критичной архитектуры;
  • восстановление функционирования технологических процессов и объектов информационной инфраструктуры после реализации инцидентов операционной надежности;
  • проведение анализа причин и последствий реализации инцидентов операционной надежности;
  • организация взаимодействия между подразделениями кредитной организации, а также между кредитной организацией и Банком России, иными участниками технологического процесса в рамках реагирования на инциденты операционной надежности и восстановления выполнения технологических процессов и функционирования объектов информационной инфраструктуры после реализации инцидентов операционной надежности.
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
РСБ.3 РСБ.3 Сбор, запись и хранение информации о событиях безопасности в течение установленного времени хранения
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 10.2.1.4
10.2.1.4
Defined Approach Requirements: 
Audit logs capture all invalid logical access attempts. 

Customized Approach Objective:
Records of all invalid access attempts are captured 

Defined Approach Testing Procedures:
  • 10.2.1.4 Examine audit log configurations and log data to verify that invalid logical access attempts are captured. 
Purpose:
Malicious individuals will often perform multiple access attempts on targeted systems. Multiple invalid login attempts may be an indication of an unauthorized user’s attempts to “brute force” or guess a password. 
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. 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.12.4.1
A.12.4.1 Регистрация событий 
Мера обеспечения информационной безопасности: Требуется обеспечивать формирование, ведение и регулярный анализ регистрационных журналов, фиксирующих действия пользователей, нештатные ситуации, ошибки и события информационной безопасности 
A.16.1.2
A.16.1.2 Сообщения о событиях информационной безопасности 
Мера обеспечения информационной безопасности: Требуется как можно скорее сообщать о событиях информационной безопасности по соответствующим каналам управления 
A.16.1.4
A.16.1.4 Оценка и принятие решений в отношении событий информационной безопасности 
Мера обеспечения информационной безопасности: Должна быть проведена оценка событий информационной безопасности, и должно быть принято решение, следует ли их классифицировать как инциденты информационной безопасности 
Положение Банка России № 802-П от 25.07.2022 "О требованиях к защите информации в платежной системе Банка России":
П. 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 10.2.1.4
10.2.1.4
Определенные Требования к Подходу:
Журналы аудита фиксируют все недопустимые попытки логического доступа.

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

Определенные Процедуры Тестирования Подхода:
  • 10.2.1.4 Проверьте конфигурации журнала аудита и данные журнала, чтобы убедиться, что зафиксированы недопустимые попытки логического доступа.
Цель:
Злоумышленники часто совершают многократные попытки доступа к целевым системам. Множественные неудачные попытки входа в систему могут указывать на попытки неавторизованного пользователя “перебрать” или угадать пароль.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
РСБ.3 РСБ.3 Сбор, запись и хранение информации о событиях безопасности в течении установленного времени хранения
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.6.8
А.6.8 Сообщения о событиях ИБ
Организация должна предоставить персоналу механизм для своевременного сообщения о наблюдаемых или предполагаемых событиях ИБ по соответствующим каналам.
А.8.16
А.8.16 Деятельность по мониторингу
Сети, системы и приложения должны быть объектом мониторинга на предмет выявления аномального поведения и выполнения соответствующих действий по оценке возможных инцидентов ИБ.
А.5.25
А.5.25 Оценка и принятие решений в отношении событий ИБ
Организация должна оценивать события ИБ и решать, следует ли их относить к инцидентам ИБ.
А.8.15
А.8.15 Логирование
Должны создаваться, храниться, защищаться и анализироваться журналы, в которых фиксируются деятельность, исключения, сбои и другие релевантные события.
Методика экспресс-оценки уровня кибербезопасности организации РезБез:
3.2.2.
Определена область мониторинга  событий ИБ (перечень источников событий ИБ, перечень собираемых событий и параметров регистрации) с учетом результатов анализа рисков, связанных с КБ
SWIFT Customer Security Controls Framework v2022:
6 - 6.4 Logging and Monitoring
6.4 Logging and Monitoring
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
АУД.4 АУД.4 Регистрация событий безопасности
АУД.7 АУД.7 Мониторинг безопасности
Положение Банка России № 757-П от 20.04.2021 "Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций":
1.14.2.
1.14.2. По каждому инциденту защиты информации некредитные финансовые организации, реализующие усиленный, стандартный и минимальный уровни защиты информации, должны осуществлять регистрацию:
  • защищаемой информации на технологических участках, на которых произошел несанкционированный доступ к защищаемой информации;
  • результата реагирования на инцидент защиты информации, в том числе совершенных действий по возврату денежных средств, ценных бумаг или иного имущества клиента некредитной финансовой организации.
Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":
п. 1.6.
1.6. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны обеспечивать в отношении выявления, регистрации событий операционного риска, связанных с нарушением операционной надежности, и реагирования на них, а также восстановления выполнения технологических процессов, указанных в приложении к настоящему Положению, и функционирования своих объектов информационной инфраструктуры после реализации указанных событий выполнение следующих требований:
  • выявление и регистрацию событий операционного риска, связанных с нарушением операционной надежности;
  • реагирование на события операционного риска, связанные с нарушением операционной надежности, в отношении критичной архитектуры;
  • восстановление выполнения технологических процессов, указанных в приложении к настоящему Положению, и функционирования своих объектов информационной инфраструктуры после реализации событий операционного риска, связанных с нарушением операционной надежности;
  • проведение анализа причин и последствий реализации событий операционного риска, связанных с нарушением операционной надежности;
  • организацию взаимодействия между подразделениями (работниками) некредитной финансовой организации, ответственными за разработку технологических процессов, указанных в приложении к настоящему Положению, поддержание их выполнения, их реализацию, между собой и Банком России, иными участниками технологического процесса в рамках реагирования на события операционного риска, связанные с нарушением операционной надежности, и восстановления выполнения технологических процессов, указанных в приложении к настоящему Положению, а также функционирования своих объектов информационной инфраструктуры после реализации событий операционного риска, связанных с нарушением операционной надежности.
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
АУД.7 АУД.7 Мониторинг безопасности
АУД.4 АУД.4 Регистрация событий безопасности
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
16.1.2
16.1.2 Сообщения о событиях информационной безопасности

Мера обеспечения ИБ
Требуется незамедлительно сообщать о событиях информационной безопасности по соответствующим каналам управления.

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

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

Дополнительная информация
Сбои или иное ненормальное поведение системы могут быть индикаторами атак на систему защиты или фактического нарушения защиты, и следовательно о них всегда необходимо сообщать как о событиях ИБ.
16.1.4
16.1.4 Оценка и принятие решений в отношении событий информационной безопасности

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

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

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

Руководство по применению
Журналы событий, где это применимо, должны включать в себя:
  • a) пользовательские идентификаторы;
  • b) действия в системе;
  • c) дату, время и детали ключевых событий, например вход и выход из системы;
  • d) идентификатор устройства или местоположения, если возможно, и системный идентификатор;
  • e) записи об успешных и отклоненных попытках доступа к системе;
  • f) записи об успешных или отклоненных попытках доступа к данным и иным ресурсам;
  • g) изменения конфигурации системы;
  • h) использование привилегий;
  • i) использование системных служебных программ и приложений;
  • j) файлы, к которым был запрошен доступ, а также вид доступа;
  • k) сетевые адреса и протоколы;
  • l) сигналы тревоги от системы контроля управления доступом;
  • m) события активации и деактивации систем защиты, таких как антивирусные средства и системы обнаружения вторжений;
  • n) записи транзакций, выполненных пользователями в приложениях.
Ведение журнала событий служит основой для автоматизированных систем мониторинга, которые способны генерировать консолидированные отчеты и оповещения о безопасности системы.

Дополнительная информация
Журналы событий могут содержать информацию ограниченного доступа. Для обеспечения конфиденциальности должны быть приняты соответствующие меры защиты (см. 18.1.4).
Там, где это возможно, системные администраторы не должны иметь прав на удаление или деактивацию журналирования собственных действий (см. 12.4.3).
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.8.16
А.8.16 Monitoring activities
Networks, systems and applications shall be monitored for anomalous behaviour and appropriate actions taken to evaluate potential information security incidents.
А.6.8
А.6.8 Information security event reporting
The organization shall provide a mechanism for personnel to report observed or suspected information security events through appropriate channels in a timely manner.
А.8.15
А.8.15 Logging
Logs that record activities, exceptions, faults and other relevant events shall be produced, stored, protected and analysed.
А.5.25
А.5.25 Assessment and decision on information security events
The organization shall assess information security events and decide if they are to be categorized as information security incidents.

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

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

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