Куда я попал?
Положение Банка России № 802-П от 25.07.2022
О требованиях к защите информации в платежной системе Банка России
П. 16.1
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 7 п. 8 п.п. 6
7.8.6. Комплекс защитных мер банковского платежного технологического процесса должен предусматривать, в том числе:
- защиту платежной информации от искажения, фальсификации, переадресации, несанкционированного уничтожения, ложной авторизации электронных платежных сообщений;
- доступ работника организации БС РФ только к тем ресурсам банковского платежного технологического процесса, которые необходимы ему для исполнения должностных обязанностей или реализации прав, предусмотренных технологией обработки платежной информации;
- контроль (мониторинг) исполнения установленной технологии подготовки, обработки, передачи и хранения платежной информации;
- аутентификацию входящих электронных платежных сообщений;
- двустороннюю аутентификацию автоматизированных рабочих мест (рабочих станций и серверов), участников обмена электронными платежными сообщениями;
- возможность ввода платежной информации в АБС только для авторизованных пользователей;
- контроль, направленный на исключение возможности совершения злоумышленных действий, в частности двойной ввод, сверка, установление ограничений в зависимости от суммы совершаемых операций;
- восстановление платежной информации в случае ее умышленного (случайного) разрушения (искажения) или выхода из строя средств вычислительной техники;
- сверку выходных электронных платежных сообщений с соответствующими входными и обработанными электронными платежными сообщениями при осуществлении межбанковских расчетов;
- возможность блокирования приема к исполнению распоряжений клиентов;
- доставку электронных платежных сообщений участникам обмена.
Кроме того, в организации БС РФ рекомендуется организовать авторизованный ввод платежной информации в АБС двумя работниками с последующей программной сверкой результатов ввода на совпадение (принцип "двойного управления").
Р. 8 п. 4 п.п. 5
8.4.5. Полученные в результате оценивания рисков нарушения ИБ величины рисков должны быть соотнесены с уровнем допустимого риска, принятого в организации БС РФ. Результатом выполнения указанной процедуры является зафиксированный перечень недопустимых рисков нарушения ИБ.
Р. 8 п. 4 п.п. 4
8.4.4. Оценка рисков нарушения ИБ проводится для свойств ИБ всех информационных активов (типов информационных активов) области действия СОИБ.
Р. 5 п. 5.15
5.15. Риски нарушения ИБ должны быть согласованы и иерархически связаны с рисками основной (бизнес) деятельности организации БС РФ через возможный ущерб.
Допускается оценка рисков информационной безопасности в составе операционных рисков с целью создания единой карты рисков и оценки стоимости ущерба по организации в целом.
Риски нарушения ИБ выражаются в возможности потери состояния защищенности интересов (целей) организации БС РФ в информационной сфере и возникновения ущерба бизнесу организации БС РФ или убытков.
Потеря состояния защищенности интересов (целей) организации БС РФ в информационной сфере заключается в утрате свойств доступности, целостности или конфиденциальности информационных активов, утрате заданных целями бизнеса параметров или доступности сервисов инфраструктуры организации БС РФ.
Допускается оценка рисков информационной безопасности в составе операционных рисков с целью создания единой карты рисков и оценки стоимости ущерба по организации в целом.
Риски нарушения ИБ выражаются в возможности потери состояния защищенности интересов (целей) организации БС РФ в информационной сфере и возникновения ущерба бизнесу организации БС РФ или убытков.
Потеря состояния защищенности интересов (целей) организации БС РФ в информационной сфере заключается в утрате свойств доступности, целостности или конфиденциальности информационных активов, утрате заданных целями бизнеса параметров или доступности сервисов инфраструктуры организации БС РФ.
CIS Critical Security Controls v8 (The 18 CIS CSC):
7.2
7.2 Establish and Maintain a Remediation Process
Establish and maintain a risk-based remediation strategy documented in a remediation process, with monthly, or more frequent, reviews.
Establish and maintain a risk-based remediation strategy documented in a remediation process, with monthly, or more frequent, reviews.
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
МАС.5
МАС.5 Организация мониторинга данных регистрации о событиях защиты информации, формируемых АС и приложениями
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
МАС.3
МАС.3 Организация мониторинга данных регистрации о событиях защиты информации, формируемых сетевыми приложениями и сервисами
3-Н 2-Т 1-Т
3-Н 2-Т 1-Т
РИ.1
РИ.1 Регистрация информации о событиях защиты информации, потенциально связанных с инцидентами защиты информации, в том числе НСД, выявленными в рамках мониторинга и анализа событий защиты информации
3-О 2-Т 1-Т
3-О 2-Т 1-Т
NIST Cybersecurity Framework (RU):
PR.PT-1
PR.PT-1: В соответствии с политикой определяются, документируются, внедряются и проверяются записи аудита / журналов событий
ID.RM-3
ID.RM-3: Определение отношения (степени принятия риска) к риску организации основывается на ее роли в критической инфраструктуре и анализе рисков для конкретных секторов
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
РСБ.5
РСБ.5 Мониторинг (просмотр, анализ) результатов регистрации событий безопасности и реагирование на них
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
ВРВ.17.3
ВРВ.17.3 Реализация механизмов приостановления осуществления финансовых (банковских) операций, в том числе операций по переводу денежных средств, в соответствии с нормативными актами Банка России.
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
7.2
7.2 Реализован и поддерживается процесс управления обнаруженными проблемами безопасности
Документ с описанием процесса пересматривается раз в месяц или чаще.
Документ с описанием процесса пересматривается раз в месяц или чаще.
Стандарт № ИСО/МЭК 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 а).
Организация должна сохранять документированную информацию по результатам оценок рисков информационной безопасности.
Организация должна выполнять оценки рисков информационной безопасности в запланированные интервалы времени или при наступлении или предполагаемом наступлении значительных изменений, при этом учитываются критерии, установленные в п.6.1.2 а).
Организация должна сохранять документированную информацию по результатам оценок рисков информационной безопасности.
8.3 Обработка рисков информационной безопасности
8.3 Обработка рисков информационной безопасности
Организация должна внедрить план обработки рисков информационной безопасности.
Организация должна сохранять документированную информацию по результатам обработки рисков информационной безопасности.
Организация должна внедрить план обработки рисков информационной безопасности.
Организация должна сохранять документированную информацию по результатам обработки рисков информационной безопасности.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования":
6.1.2
6.1.2 Оценка рисков информационной безопасности
Организация должна определить и внедрить процесс оценки рисков информационной безопасности, который позволяет:
а) устанавливать и поддерживать критерии рисков информационной безопасности, включая:
1) критерии принятия рисков информационной безопасности;
2) критерии для проведения оценки рисков информационной безопасности;
b) обеспечивать уверенность в том, что повторные оценки рисков информационной безопасности дают непротиворечивые, достоверные и сопоставимые результаты;
с) идентифицировать риски информационной безопасности, т. е.:
1) применять процесс оценки рисков информационной безопасности для идентификации рисков, связанных с нарушением конфиденциальности, целостности и доступности информации в рамках области действия системы менеджмента информационной безопасности;
2) идентифицировать владельцев рисков информационной безопасности;
d) проводить анализ рисков информационной безопасности, т. е.:
1) оценивать потенциальные последствия, которые могут произойти в результате реализации рисков информационной безопасности, идентифицированных в соответствии с 6.1.2 с) 1);
2) оценивать реальную вероятность реализации рисков информационной безопасности, идентифицированных в соответствии с 6.1.2 с) 1);
3) определять уровни рисков информационной безопасности;
е) оценивать риски информационной безопасности, т. е.:
1) сравнивать результаты анализа рисков информационной безопасности с критериями рисков, установленными в соответствии с 6.1.2 а);
2) определять приоритетность обработки проанализированных рисков информационной безопасности.
Организация должна хранить документированную информацию о процессе оценки рисков информационной безопасности.
Организация должна определить и внедрить процесс оценки рисков информационной безопасности, который позволяет:
а) устанавливать и поддерживать критерии рисков информационной безопасности, включая:
1) критерии принятия рисков информационной безопасности;
2) критерии для проведения оценки рисков информационной безопасности;
b) обеспечивать уверенность в том, что повторные оценки рисков информационной безопасности дают непротиворечивые, достоверные и сопоставимые результаты;
с) идентифицировать риски информационной безопасности, т. е.:
1) применять процесс оценки рисков информационной безопасности для идентификации рисков, связанных с нарушением конфиденциальности, целостности и доступности информации в рамках области действия системы менеджмента информационной безопасности;
2) идентифицировать владельцев рисков информационной безопасности;
d) проводить анализ рисков информационной безопасности, т. е.:
1) оценивать потенциальные последствия, которые могут произойти в результате реализации рисков информационной безопасности, идентифицированных в соответствии с 6.1.2 с) 1);
2) оценивать реальную вероятность реализации рисков информационной безопасности, идентифицированных в соответствии с 6.1.2 с) 1);
3) определять уровни рисков информационной безопасности;
е) оценивать риски информационной безопасности, т. е.:
1) сравнивать результаты анализа рисков информационной безопасности с критериями рисков, установленными в соответствии с 6.1.2 а);
2) определять приоритетность обработки проанализированных рисков информационной безопасности.
Организация должна хранить документированную информацию о процессе оценки рисков информационной безопасности.
8.2
8.2 Оценка рисков информационной безопасности
Организация должна проводить оценку рисков информационной безопасности через запланированные интервалы времени или в случае предполагаемых или произошедших существенных изменений, учитывая критерии рисков информационной безопасности, установленные в соответствии с 6.1.2 а).
Организация должна хранить документированную информацию о результатах проведенных оценок рисков информационной безопасности.
Организация должна проводить оценку рисков информационной безопасности через запланированные интервалы времени или в случае предполагаемых или произошедших существенных изменений, учитывая критерии рисков информационной безопасности, установленные в соответствии с 6.1.2 а).
Организация должна хранить документированную информацию о результатах проведенных оценок рисков информационной безопасности.
8.3
8.3 Обработка рисков информационной безопасности
Организация должна реализовать план обработки рисков информационной безопасности. Организация должна хранить документированную информацию о результатах обработки рисков информационной безопасности.
Организация должна реализовать план обработки рисков информационной безопасности. Организация должна хранить документированную информацию о результатах обработки рисков информационной безопасности.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 10.2.1
10.2.1
Defined Approach Requirements:
Audit logs are enabled and active for all system components and cardholder data.
Customized Approach Objective:
Records of all activities affecting system components and cardholder data are captured.
Defined Approach Testing Procedures:
Defined Approach Requirements:
Audit logs are enabled and active for all system components and cardholder data.
Customized Approach Objective:
Records of all activities affecting system components and cardholder data are captured.
Defined Approach Testing Procedures:
- 10.2.1 Interview the system administrator and examine system configurations to verify that audit logs are enabled and active for all system components.
Purpose:
Audit logs must exist for all system components. Audit logs send alerts the system administrator, provides data to other monitoring mechanisms, such as intrusion-detection systems (IDS) and security information and event monitoring systems (SIEM) tools, and provide a history trail for post-incident investigation.
Logging and analyzing security-relevant events enable an organization to identify and trace potentially malicious activities.
Good Practice:
When an entity considers which information to record in their logs, it is important to remember that information stored in audit logs is sensitive and should be protected per requirements in this standard. Care should be taken to only store essential information in the audit logs to minimize risk.
Audit logs must exist for all system components. Audit logs send alerts the system administrator, provides data to other monitoring mechanisms, such as intrusion-detection systems (IDS) and security information and event monitoring systems (SIEM) tools, and provide a history trail for post-incident investigation.
Logging and analyzing security-relevant events enable an organization to identify and trace potentially malicious activities.
Good Practice:
When an entity considers which information to record in their logs, it is important to remember that information stored in audit logs is sensitive and should be protected per requirements in this standard. Care should be taken to only store essential information in the audit logs to minimize risk.
Requirement 12.3.1
12.3.1
Defined Approach Requirements:
Each PCI DSS requirement that provides flexibility for how frequently it is performed (for example, requirements to be performed periodically) is supported by a targeted risk analysis that is documented and includes:
Defined Approach Requirements:
Each PCI DSS requirement that provides flexibility for how frequently it is performed (for example, requirements to be performed periodically) is supported by a targeted risk analysis that is documented and includes:
- Identification of the assets being protected.
- Identification of the threat(s) that the requirement is protecting against.
- Identification of factors that contribute to the likelihood and/or impact of a threat being realized.
- Resulting analysis that determines, and includes justification for, how frequently the requirement must be performed to minimize the likelihood of the threat being realized.
- Review of each targeted risk analysis at least once every 12 months to determine whether the results are still valid or if an updated risk analysis is needed.
- Performance of updated risk analyses when needed, as determined by the annual review.
Customized Approach Objective:
Up to date knowledge and assessment of risks to the CDE are maintained.
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:
Up to date knowledge and assessment of risks to the CDE are maintained.
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.3.1 Examine documented policies and procedures to verify a process is defined for performing targeted risk analyses for each PCI DSS requirement that provides flexibility for how frequently the requirement is performed, and that the process includes all elements specified in this requirement.
Purpose:
Some PCI DSS requirements allow an entity to define how frequently an activity is performed based on the risk to environment. Performing this risk analysis according to a methodology ensures validity and consistency with policies and procedures.
This targeted risk analysis (as opposed to a traditional enterprise-wide risk assessment) focuses on those PCI DSS requirements that allow an entity flexibility about how frequently an entity performs a given control. For this risk analysis, the entity carefully evaluates each PCI DSS requirement that provides this flexibility and determines the frequency that supports adequate security for the entity, and the level of risk the entity is willing to accept.
The risk analysis identifies the specific assets, such as the system components and data—for example, log files, or credentials—that the requirement is intended to protect, as well as the threat(s) or outcomes that the requirement is protecting the assets from—for example, malware, an undetected intruder, or misuse of credentials. Examples of factors that could contribute to likelihood or impact include any that could increase the vulnerability of an asset to a threat—for example, exposure to untrusted networks, complexity of environment, or high staff turnover—as well as the criticality of the system components, or volume and sensitivity of the data, being protected.
Reviewing the results of these targeted risk analyses at least once every 12 months and upon changes that could impact the risk to the environment allows the organization to ensure the risk analysis results remain current with organizational changes and evolving threats, trends, and technologies, and that the selected frequencies still adequately address the entity’s risk.
Good Practice:
An enterprise-wide risk assessment, which is a point-in-time activity that enables entities to identify threats and associated vulnerabilities, is recommended, but is not required, for entities to determine and understand broader and emerging threats with the potential to negatively impact its business. This enterprise-wide risk assessment could be established as part of an overarching risk management program that is used as an input to the annual review of an organization's overall information security policy (see Requirement 12.1.1).
Examples of risk-assessment methodologies for enterprise-wide risk assessments include, but are not limited to, ISO 27005 and NIST SP 800-30.
Some PCI DSS requirements allow an entity to define how frequently an activity is performed based on the risk to environment. Performing this risk analysis according to a methodology ensures validity and consistency with policies and procedures.
This targeted risk analysis (as opposed to a traditional enterprise-wide risk assessment) focuses on those PCI DSS requirements that allow an entity flexibility about how frequently an entity performs a given control. For this risk analysis, the entity carefully evaluates each PCI DSS requirement that provides this flexibility and determines the frequency that supports adequate security for the entity, and the level of risk the entity is willing to accept.
The risk analysis identifies the specific assets, such as the system components and data—for example, log files, or credentials—that the requirement is intended to protect, as well as the threat(s) or outcomes that the requirement is protecting the assets from—for example, malware, an undetected intruder, or misuse of credentials. Examples of factors that could contribute to likelihood or impact include any that could increase the vulnerability of an asset to a threat—for example, exposure to untrusted networks, complexity of environment, or high staff turnover—as well as the criticality of the system components, or volume and sensitivity of the data, being protected.
Reviewing the results of these targeted risk analyses at least once every 12 months and upon changes that could impact the risk to the environment allows the organization to ensure the risk analysis results remain current with organizational changes and evolving threats, trends, and technologies, and that the selected frequencies still adequately address the entity’s risk.
Good Practice:
An enterprise-wide risk assessment, which is a point-in-time activity that enables entities to identify threats and associated vulnerabilities, is recommended, but is not required, for entities to determine and understand broader and emerging threats with the potential to negatively impact its business. This enterprise-wide risk assessment could be established as part of an overarching risk management program that is used as an input to the annual review of an organization's overall information security policy (see Requirement 12.1.1).
Examples of risk-assessment methodologies for enterprise-wide risk assessments include, but are not limited to, ISO 27005 and NIST SP 800-30.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.12.4.1
A.12.4.1 Регистрация событий
Мера обеспечения информационной безопасности: Требуется обеспечивать формирование, ведение и регулярный анализ регистрационных журналов, фиксирующих действия пользователей, нештатные ситуации, ошибки и события информационной безопасности
Мера обеспечения информационной безопасности: Требуется обеспечивать формирование, ведение и регулярный анализ регистрационных журналов, фиксирующих действия пользователей, нештатные ситуации, ошибки и события информационной безопасности
A.12.7.1
A.12.7.1 Меры обеспечения информационной безопасности в отношении аудита информационных систем
Мера обеспечения информационной безопасности: Требования к процессу регистрации событий (аудиту) и деятельности, связанной с контролем находящихся в эксплуатации систем, должны быть тщательно спланированы и согласованы для минимизации сбоев в бизнес-процессах
Мера обеспечения информационной безопасности: Требования к процессу регистрации событий (аудиту) и деятельности, связанной с контролем находящихся в эксплуатации систем, должны быть тщательно спланированы и согласованы для минимизации сбоев в бизнес-процессах
Стандарт № 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.
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:
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:
- 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.
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.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 10.2.1
10.2.1
Определенные Требования к Подходу:
Журналы аудита включены и активны для всех компонентов системы и данных о держателях карт.
Цель Индивидуального подхода:
Фиксируются записи всех действий, влияющих на компоненты системы, и данные о держателях карт.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Журналы аудита включены и активны для всех компонентов системы и данных о держателях карт.
Цель Индивидуального подхода:
Фиксируются записи всех действий, влияющих на компоненты системы, и данные о держателях карт.
Определенные Процедуры Тестирования Подхода:
- 10.2.1 Опросите системного администратора и изучите системные конфигурации, чтобы убедиться, что журналы аудита включены и активны для всех компонентов системы.
Цель:
Журналы аудита должны существовать для всех компонентов системы. Журналы аудита отправляют предупреждения системному администратору, предоставляют данные другим механизмам мониторинга, таким как системы обнаружения вторжений (IDS) и средства защиты информации и систем мониторинга событий (SIEM), а также обеспечивают отслеживание истории для расследования после инцидента.
Ведение журнала и анализ событий, связанных с безопасностью, позволяют организации выявлять и отслеживать потенциально вредоносные действия.
Надлежащая практика:
Когда организация решает, какую информацию записывать в свои журналы, важно помнить, что информация, хранящаяся в журналах аудита, является конфиденциальной и должна быть защищена в соответствии с требованиями настоящего стандарта. Следует позаботиться о том, чтобы в журналах аудита сохранялась только важная информация, чтобы свести к минимуму риск.
Журналы аудита должны существовать для всех компонентов системы. Журналы аудита отправляют предупреждения системному администратору, предоставляют данные другим механизмам мониторинга, таким как системы обнаружения вторжений (IDS) и средства защиты информации и систем мониторинга событий (SIEM), а также обеспечивают отслеживание истории для расследования после инцидента.
Ведение журнала и анализ событий, связанных с безопасностью, позволяют организации выявлять и отслеживать потенциально вредоносные действия.
Надлежащая практика:
Когда организация решает, какую информацию записывать в свои журналы, важно помнить, что информация, хранящаяся в журналах аудита, является конфиденциальной и должна быть защищена в соответствии с требованиями настоящего стандарта. Следует позаботиться о том, чтобы в журналах аудита сохранялась только важная информация, чтобы свести к минимуму риск.
Requirement 12.3.1
12.3.1
Определенные Требования к Подходу:
Каждое требование PCI DSS, обеспечивающее гибкость в отношении частоты его выполнения (например, требования, которые должны выполняться периодически), подкрепляется целевым анализом рисков, который документируется и включает:
Определенные Требования к Подходу:
Каждое требование PCI DSS, обеспечивающее гибкость в отношении частоты его выполнения (например, требования, которые должны выполняться периодически), подкрепляется целевым анализом рисков, который документируется и включает:
- Идентификация защищаемых активов.
- Идентификация угрозы (угроз), от которой защищает требование.
- Выявление факторов, которые способствуют вероятности и/или воздействию реализуемой угрозы.
- Итоговый анализ, который определяет и включает обоснование того, как часто должно выполняться требование, чтобы свести к минимуму вероятность реализации угрозы.
- Просматривайте каждый целевой анализ рисков не реже одного раза в 12 месяцев, чтобы определить, остаются ли результаты в силе или необходим обновленный анализ рисков.
- Проведение обновленного анализа рисков, когда это необходимо, в соответствии с ежегодным обзором.
Цель Индивидуального подхода:
Поддерживаются актуальные знания и оценка рисков для CDE.
Примечания по применению:
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
Поддерживаются актуальные знания и оценка рисков для CDE.
Примечания по применению:
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
- 12.3.1 Изучите документированные политики и процедуры, чтобы убедиться, что определен процесс для выполнения целевого анализа рисков для каждого требования PCI DSS, который обеспечивает гибкость в отношении того, как часто выполняется требование, и что процесс включает все элементы, указанные в этом требовании.
Цель:
Некоторые требования PCI DSS позволяют организации определять, как часто выполняется та или иная деятельность, исходя из риска для окружающей среды. Выполнение этого анализа рисков в соответствии с методологией обеспечивает обоснованность и согласованность с политиками и процедурами.
Этот целевой анализ рисков (в отличие от традиционной общеорганизационной оценки рисков) фокусируется на тех требованиях PCI DSS, которые позволяют организации гибко выбирать, как часто организация выполняет тот или иной контроль. Для этого анализа рисков организация тщательно оценивает каждое требование PCI DSS, обеспечивающее такую гибкость, и определяет частоту, обеспечивающую надлежащую безопасность для организации, а также уровень риска, который организация готова принять.
Анализ рисков определяет конкретные активы, такие как системные компоненты и данные — например, файлы журналов или учетные данные, — для защиты которых предназначено требование, а также угрозы или последствия, от которых требование защищает активы — например, вредоносное ПО, необнаруженный злоумышленник, или неправильное использование учетных данных. Примеры факторов, которые могут способствовать вероятности или воздействию, включают любые, которые могут повысить уязвимость актива к угрозе, например, подверженность ненадежным сетям, сложность среды или высокая текучесть кадров, а также критичность компонентов системы или объем и критичность данных, поскольку защищенный.
Анализ результатов этих целевых анализов рисков не реже одного раза в 12 месяцев и при изменениях, которые могут повлиять на риск для окружающей среды, позволяет организации убедиться, что результаты анализа рисков остаются актуальными с учетом организационных изменений и развивающихся угроз, тенденций и технологий, а также что выбранные частоты по-прежнему адекватно учитывают риск организации..
Надлежащая практика:
Оценка рисков в масштабах всей организации, которая представляет собой оперативную деятельность, позволяющую организациям выявлять угрозы и связанные с ними уязвимости, рекомендуется, но не требуется, для определения и понимания более широких и возникающих угроз, которые могут негативно повлиять на их бизнес. Эта общеорганизационная оценка рисков может быть создана как часть всеобъемлющей программы управления рисками, которая используется в качестве вклада в ежегодный обзор общей политики информационной безопасности организации (см. Требование 12.1.1).
Примеры методологий оценки рисков для оценки рисков в масштабах предприятия включают, но не ограничиваются ими, ISO 27005 и NIST SP 800-30.
Некоторые требования PCI DSS позволяют организации определять, как часто выполняется та или иная деятельность, исходя из риска для окружающей среды. Выполнение этого анализа рисков в соответствии с методологией обеспечивает обоснованность и согласованность с политиками и процедурами.
Этот целевой анализ рисков (в отличие от традиционной общеорганизационной оценки рисков) фокусируется на тех требованиях PCI DSS, которые позволяют организации гибко выбирать, как часто организация выполняет тот или иной контроль. Для этого анализа рисков организация тщательно оценивает каждое требование PCI DSS, обеспечивающее такую гибкость, и определяет частоту, обеспечивающую надлежащую безопасность для организации, а также уровень риска, который организация готова принять.
Анализ рисков определяет конкретные активы, такие как системные компоненты и данные — например, файлы журналов или учетные данные, — для защиты которых предназначено требование, а также угрозы или последствия, от которых требование защищает активы — например, вредоносное ПО, необнаруженный злоумышленник, или неправильное использование учетных данных. Примеры факторов, которые могут способствовать вероятности или воздействию, включают любые, которые могут повысить уязвимость актива к угрозе, например, подверженность ненадежным сетям, сложность среды или высокая текучесть кадров, а также критичность компонентов системы или объем и критичность данных, поскольку защищенный.
Анализ результатов этих целевых анализов рисков не реже одного раза в 12 месяцев и при изменениях, которые могут повлиять на риск для окружающей среды, позволяет организации убедиться, что результаты анализа рисков остаются актуальными с учетом организационных изменений и развивающихся угроз, тенденций и технологий, а также что выбранные частоты по-прежнему адекватно учитывают риск организации..
Надлежащая практика:
Оценка рисков в масштабах всей организации, которая представляет собой оперативную деятельность, позволяющую организациям выявлять угрозы и связанные с ними уязвимости, рекомендуется, но не требуется, для определения и понимания более широких и возникающих угроз, которые могут негативно повлиять на их бизнес. Эта общеорганизационная оценка рисков может быть создана как часть всеобъемлющей программы управления рисками, которая используется в качестве вклада в ежегодный обзор общей политики информационной безопасности организации (см. Требование 12.1.1).
Примеры методологий оценки рисков для оценки рисков в масштабах предприятия включают, но не ограничиваются ими, ISO 27005 и NIST SP 800-30.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
РСБ.5
РСБ.5 Мониторинг (просмотр, анализ) результатов регистрации событий безопасности и реагирование на них
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.15
А.8.15 Логирование
Должны создаваться, храниться, защищаться и анализироваться журналы, в которых фиксируются деятельность, исключения, сбои и другие релевантные события.
Должны создаваться, храниться, защищаться и анализироваться журналы, в которых фиксируются деятельность, исключения, сбои и другие релевантные события.
Положение Банка России № 719-П от 04.06.2020 "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств":
Глава 5 п. 1
5.1. Оператор платежной системы в целях реализации пункта 11 части 3 статьи 28 Федерального закона № 161-ФЗ (Собрание законодательства Российской Федерации, 2011, № 27, ст. 3872) в рамках системы управления рисками в платежной системе определяет в правилах платежной системы и иных документах порядок обеспечения защиты информации в платежной системе для операторов по переводу денежных средств, являющихся участниками платежной системы, операторов услуг платежной инфраструктуры с учетом требований к обеспечению защиты информации при осуществлении переводов денежных средств (далее - требования к обеспечению защиты информации в платежной системе).
Оператор платежной системы должен определить требования к обеспечению защиты информации в платежной системе в отношении следующих мероприятий:
- управление риском информационной безопасности в платежной системе как одним из видов операционного риска в платежной системе, источниками реализации которого являются: недостатки процессов обеспечения защиты информации, в том числе недостатки применяемых технологических мер защиты информации, недостатки прикладного программного обеспечения автоматизированных систем и приложений, а также несоблюдение требований к указанным процессам деятельности операторами по переводу денежных средств, являющимися участниками платежной системы, операторами услуг платежной инфраструктуры (далее - риск информационной безопасности в платежной системе);
- установление состава показателей уровня риска информационной безопасности в платежной системе;
- реализация операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры механизмов, направленных на соблюдение требований к обеспечению защиты информации при осуществлении переводов денежных средств, и контроль их соблюдения операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры;
- реализация операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры процессов выявления и идентификации риска информационной безопасности в платежной системе в отношении объектов информационной инфраструктуры участников платежной системы, операторов услуг платежной инфраструктуры;
- выявление и анализ операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры риска информационной безопасности в платежной системе;
- реализация операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры процессов реагирования на инциденты защиты информации и восстановления штатного функционирования объектов информационной инфраструктуры в случае реализации инцидентов защиты информации;
- реализация операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры взаимодействия при обмене информацией об инцидентах защиты информации;
- реализация операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры мероприятий по противодействию осуществлению переводов денежных средств без согласия клиента, определенных пунктами 2.2 и 2.4 Указания Банка России от 8 октября 2018 года № 4926-У «О форме и порядке направления операторами по переводу денежных средств, операторами платежных систем, операторами услуг платежной инфраструктуры в Банк России информации обо всех случаях и (или) попытках осуществления переводов денежных средств без согласия клиента и получения ими от Банка России информации, содержащейся в базе данных о случаях и попытках осуществления переводов денежных средств без согласия клиента, а также о порядке реализации операторами по переводу денежных средств, операторами платежных систем, операторами услуг платежной инфраструктуры мероприятий по противодействию осуществлению переводов денежных средств без согласия клиента», зарегистрированного Министерством юстиции Российской Федерации 12 декабря 2018 года № 52988;
- реализация операторами платежных систем процессов применения в отношении операторов по переводу денежных средств, являющихся участниками платежной системы, и операторов услуг платежной инфраструктуры ограничений по параметрам операций по осуществлению переводов денежных средств в случае выявления факта превышения значений показателей уровня риска информационной безопасности в платежной системе, в том числе условий снятия таких ограничений.
SWIFT Customer Security Controls Framework v2022:
6 - 6.4 Logging and Monitoring
6.4 Logging and Monitoring
7 - 7.4A Scenario Risk Assessment
7.4A Scenario Risk Assessment
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
АУД.4
АУД.4 Регистрация событий безопасности
NIST Cybersecurity Framework (EN):
PR.PT-1
PR.PT-1: Audit/log records are determined, documented, implemented, and reviewed in accordance with policy
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
Стандарт Банка России № РС БР ИББС-2.5-2014 от 01.06.2014 "Менеджмент инцидентов информационной безопасности":
Р. 6 п. 5 п.п. 2
6.5.2. Средства мониторинга ИБ и контроля защитных мер должны выполнять следующие основные функции:
- отслеживание и регистрацию событий ИБ в целях обнаружения инцидентов ИБ;
- агрегирование полученной информации о событиях ИБ, корреляцию информации о событиях ИБ, обнаружение инцидентов ИБ на основе установленных в организации БС РФ критериев и правил;
- текущий контроль функционирования применяемых средств защиты информации и обнаружение отклонений в их работе от штатного режима;
- текущий контроль действий пользователей и эксплуатирующего персонала и обнаружение нарушений в эксплуатации технических средств.
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
АУД.4
АУД.4 Регистрация событий безопасности
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
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).
12.7.1
12.7.1 Меры обеспечения информационной безопасности в отношении аудита информационных систем
Мера обеспечения ИБ
Требования к процессу регистрации событий [аудиту] и деятельности, связанной с контролем находящихся в эксплуатации систем, должны быть тщательно спланированы и согласованы для минимизации сбоев в бизнес-процессах.
Руководство по применению
Необходимо придерживаться следующих рекомендаций:
- a) требования доступа к системам и данным для проведения аудита должны быть согласованы с соответствующим руководством;
- b) область действия технического аудита должна быть согласована и проконтролирована;
- c) аудиторские тесты должны быть ограничены доступом уровня "только на чтение" в отношении программного обеспечения и данных;
- d) доступ, отличный от режима "только на чтение", должен быть разрешен только для изолированных копий системных файлов, которые должны быть уничтожены по завершении аудита или обеспечены соответствующей защитой, если существует необходимость сохранять такие файлы в соответствии с требованиями документации по аудиту;
- e) требования к специальной и дополнительной обработке должны быть идентифицированы и согласованы;
- f) аудиторские тесты, которые могут повлиять на доступность системы, следует проводить в нерабочее время;
- g) любой доступ должен контролироваться и регистрироваться для создания прослеживаемости.
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.8.15
А.8.15 Logging
Logs that record activities, exceptions, faults and other relevant events shall be produced, stored, protected and analysed.
Logs that record activities, exceptions, faults and other relevant events shall be produced, stored, protected and analysed.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.