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

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

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

РИ.2

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

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

Приказ ФСТЭК России № 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. 
ГОСТ Р № ИСО/МЭК 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.4
16.4. В рамках реализации мер по выявлению и устранению причин и последствий компьютерных атак, направленных на объекты информационной инфраструктуры участника СБП и (или) его клиентов, ОПКЦ СБП, и дальнейшему предотвращению случаев и (или) попыток осуществления переводов денежных средств без согласия клиента участник СБП, ОПКЦ СБП должны обеспечить выполнение следующих требований:
  • участник СБП - банк плательщика при выявлении информации о компьютерных атаках, проводимых с использованием идентификаторов клиентов участника СБП, направленных на получение информации о клиентах участника СБП или клиентах косвенного участника, имеющего доступ к трансграничному переводу денежных средств с использованием СБП в соответствии с абзацем восьмым пункта 3.3 Положения Банка России N 732-П (далее - косвенный участник с доступом к ТПСБП), из формирующихся распоряжений клиента участника СБП о переводе денежных средств (далее - переборы идентификаторов), при осуществлении переводов денежных средств с использованием сервиса быстрых платежей осуществляет блокировку идентификатора клиента участника СБП, используемого для осуществления переборов идентификаторов, и незамедлительно уведомляет Банк России и ОПКЦ СБП о его блокировке;
  • участник СБП принимает решение о разблокировке идентификатора клиента участника СБП по результатам проведенной проверки и доводит принятое им решение до ОПКЦ СБП в соответствии с договором об оказании услуг между участником СБП и ОПКЦ СБП;
  • ОПКЦ СБП осуществляет выявление переборов идентификаторов клиентов участника СБП, клиентов косвенного участника с доступом к ТПСБП, блокировку идентификатора клиента участника СБП, клиента косвенного участника с доступом к ТПСБП, используемого для осуществления переборов идентификаторов, при каждом выявлении перебора идентификаторов, в том числе при отсутствии уведомления участника СБП или косвенного участника с доступом к ТПСБП о блокировке, на срок, установленный договором об оказании услуг между участником СБП и ОПКЦ СБП, и направление уведомлений участнику СБП и Банку России о блокировке идентификатора;
  • при получении участником СБП - банком плательщика уведомления о блокировке идентификатора от ОПКЦ СБП участник СБП обязан осуществлять проверку полученной информации в соответствии с договором между клиентом участника СБП и участником СБП, о результатах которой Банк России уведомляется в соответствии с абзацем девятым пункта 5.1 Положения Банка России N 719-П;
  • участник СБП направляет уведомление о блокировке идентификатора клиента косвенного участника с доступом к ТПСБП косвенному участнику с доступом к ТПСБП и доводит до ОПКЦ СБП информацию о результатах проведенной проверки косвенным участником с доступом к ТПСБП в соответствии с договором об оказании услуг между участником СБП и ОПКЦ СБП;
  • ОПКЦ СБП осуществляет разблокировку идентификатора клиента участника СБП, клиента косвенного участника с доступом к ТПСБП в соответствии с договором об оказании услуг между участником СБП и ОПКЦ СБП.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
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 Логирование
Должны создаваться, храниться, защищаться и анализироваться журналы, в которых фиксируются деятельность, исключения, сбои и другие релевантные события.
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
АУД.7 АУД.7 Мониторинг безопасности
АУД.4 АУД.4 Регистрация событий безопасности
Положение Банка России № 757-П от 20.04.2021 "Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций":
1.14.2.
1.14.2. По каждому инциденту защиты информации некредитные финансовые организации, реализующие усиленный, стандартный и минимальный уровни защиты информации, должны осуществлять регистрацию:
  • защищаемой информации на технологических участках, на которых произошел несанкционированный доступ к защищаемой информации;
  • результата реагирования на инцидент защиты информации, в том числе совершенных действий по возврату денежных средств, ценных бумаг или иного имущества клиента некредитной финансовой организации.
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
АУД.4 АУД.4 Регистрация событий безопасности
АУД.7 АУД.7 Мониторинг безопасности
ГОСТ Р № ИСО/МЭК 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.
Положение Банка России № 716-П от 08.04.2022 "О требованиях к системе управления операционным риском в кредитной организации и банковской группе":
Глава 7. Пункт 3.
7.3. Инциденты, приведшие к фактической реализации риска информационной безопасности, в том числе киберриска, обусловленные источниками риска информационной безопасности, в том числе инциденты, связанные с нарушениями требований к обеспечению защиты информации при осуществлении переводов денежных средств, установленных в соответствии с Положением Банка России от 4 июня 2020 года N 719-П "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств", зарегистрированным Министерством юстиции Российской Федерации 23 сентября 2020 года N 59991 (далее - Положение Банка России N 719-П), и Положением Банка России от 17 апреля 2019 года N 683-П "Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента", зарегистрированным Министерством юстиции Российской Федерации 16 мая 2019 года N 54637 (далее - Положение Банка России N 683-П) (далее - инциденты защиты информации), вследствие которых возникли прямые и (или) непрямые потери кредитной организации (головной кредитной организации банковской группы) (далее - событие риска информационной безопасности), фиксируются кредитной организацией (головной кредитной организацией банковской группы) в базе событий с присвоением вида операционного риска в соответствии с абзацем семнадцатым пункта 6.6 настоящего Положения.
(Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)

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

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

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

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