Куда я попал?
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022
Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А
A.12.7.1
Для проведения оценки соответствия по документу войдите в систему.
Похожие требования
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 9. Требования к защите информации на этапах жизненного цикла автоматизированных систем и приложений":
ЖЦ.14
ЖЦ.14 Реализация контроля защищенности АС, включающего (по решению финансовой организации при модернизации АС проводится контроль защищенности только элементов информационной инфраструктуры, подвергнутых модернизации): - тестирование на проникновение; - анализ уязвимостей системы защиты информации АС и информационной инфраструктуры промышленной среды
3-Н 2-О 1-О
3-Н 2-О 1-О
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 8. Требования к организации и управлению защитой информации":
СЗИ.1
СЗИ.1 Проведение и фиксация результатов (свидетельств) анализа необходимости совершенствования процесса системы защиты информации в случаях:
- обнаружения инцидентов защиты информации;
- обнаружения недостатков в рамках контроля системы защиты информации
3-О 2-О 1-О
Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 8 п. 12 п.п. 4
8.12.4. Процедуры мониторинга ИБ и контроля защитных мер должны подвергаться регулярным, регистрируемым пересмотрам в связи с изменениями в составе и способах использования защитных мер, выявлением новых угроз и уязвимостей ИБ, а также на основе данных об инцидентах ИБ.
Стандарт Банка России № СТО БР ИББС-1.3-2016 от 01.01.2017 "Сбор и анализ технических данных при реагировании на инциденты информационной безопасности при осуществлении переводов денежных средств":
Р. 6 п. 3
6.3. Рекомендации к предварительному планированию сбора технических данных. В плане (регламенте) сбора технических данных рекомендуется определить для каждого потенциального инцидента ИБ из числа указанных в подпункте 6.1 настоящего раздела следующие положения:
- состав собираемых технических данных;
- приоритеты (последовательность) сбора технических данных;
- инструкции по использованию технических средств инструментов, описание процедур и сервисных команд, необходимых для сбора технических данных;
- описание процедур и сервисных команд, в том числе технических, проверки (контроля) целостности собранных данных;
- правила описания и протоколирования выполненных процедур и сервисных команд, описания места сбора технических данных;
- правила создания копий собираемых технических данных и требования к их количеству;
- правила маркирования, безопасной упаковки и хранения носителей собранных технических данных;
- правила регистрации и хранения описаний и протоколов, связанных со сбором технических данных.
В плане (регламенте) сбора технических данных рекомендуется также определить необходимость и условия подготовки обращения в МВД России, его территориальное подразделения и (или) FinCert Банка России.
При планировании сбора технических данных возможно рассмотрение следующих типовых сценариев, определяющих степень оперативности предпринимаемых действий:
При планировании сбора технических данных возможно рассмотрение следующих типовых сценариев, определяющих степень оперативности предпринимаемых действий:
- сбор данных в реальном масштабе времени в случае, когда система ДБО, АБС, система фронт-офиса, система бэк-офиса (далее при совместном упоминании – целевые системы) непосредственно не подвержена компьютерной атаке, а компьютерная атака выявлена на периметре информационной инфраструктуры;
- сбор данных непосредственно после реализации инцидента ИБ (например, в течение 24 часов);
- сбор данных по прошествии значительного времени после инцидента ИБ.
Рекомендуется реализовать сбор следующих технических данных:
Р. 6 п. 2
6.2. Организацию сбора технических данных рекомендуется проводить в следующем порядке:
- предварительное планирование и создание условий для сбора технических данных:
- разработка и утверждение плана (регламента) сбора технических данных, реализуемого в случае выявления инцидентов ИБ;
- включение ответственных за выполнение ролей в рамках процессов обработки технических данных в группу реагирования на инциденты ИБ, создаваемую в соответствии с РС БР ИББС-2.5;
- обеспечение необходимых технических средств и инструментов для сбора и обработки технических данных;
- сбор технических данных при выявлении инцидента ИБ:
- оперативное определение перечня компонентов информационной инфраструктуры, задействованной в реализации инцидента ИБ;
- оперативное ограничение доступа к компонентам информационной инфраструктуры, задействованной в реализации инцидента ИБ, а также техническим данным для цели обеспечения их сохранности до выполнения сбора;
- сбор и документирование сведений об официально назначенном эксплуатационном персонале (администраторах) информационной инфраструктуры, задействованной в реализации инцидента ИБ, получение документально оформленных подтверждений лиц из состава эксплуатационного персонала о предоставлении/непредоставлении их аутентификационных данных третьим лицам и о внесении изменений/невнесении изменений в протоколы (журналы) регистрации, формируемые компонентами информационной инфраструктуры;
- непосредственный сбор технических данных, в том числе проверка и обеспечение целостности (неизменности) собранных данных, маркирование носителей собранных данных;
- обеспечение сохранности машинных носителей информации и защиту от воздействий, которые могут повредить их информационное содержимое, путем безопасной упаковки, опечатывания, исключающего возможность несанкционированного использования (подключения) носителя данных без нарушения целостности упаковки (печати), а также безопасного хранения и транспортировки носителей собранных данных.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 10.7.2
10.7.2
Defined Approach Requirements:
Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems:
Defined Approach Requirements:
Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems:
- Network security controls.
- IDS/IPS.
- Change-detection mechanisms.
- Anti-malware solutions.
- Physical access controls.
- Logical access controls.
- Audit logging mechanisms.
- Segmentation controls (if used).
- Audit log review mechanisms.
- Automated security testing tools (if used).
Customized Approach Objective:
Failures in critical security control systems are promptly identified and addressed.
Applicability Notes:
This requirement applies to all entities, including service providers, and will supersede Requirement 10.7.1 as of 31 March 2025. It includes two additional critical security control systems not in Requirement 10.7.1.
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:
Failures in critical security control systems are promptly identified and addressed.
Applicability Notes:
This requirement applies to all entities, including service providers, and will supersede Requirement 10.7.1 as of 31 March 2025. It includes two additional critical security control systems not in Requirement 10.7.1.
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:
- 10.7.2.a Examine documentation to verify that processes are defined for the prompt detection and addressing of failures of critical security control systems, including but not limited to failure of all elements specified in this requirement.
- 10.7.2.b Observe detection and alerting processes and interview personnel to verify that failures of critical security control systems are detected and reported, and that failure of a critical security control results in the generation of an alert.
Purpose:
Without formal processes to detect and alert when critical security controls fail, failures may go undetected for extended periods and provide attackers ample time to compromise system components and steal account data from the CDE.
Good Practice:
The specific types of failures may vary, depending on the function of the device system component and technology in use. However, typical failures include a system no longer performing its security function or not functioning in its intended manner—for example, a firewall erasing its rules or going offline.
Without formal processes to detect and alert when critical security controls fail, failures may go undetected for extended periods and provide attackers ample time to compromise system components and steal account data from the CDE.
Good Practice:
The specific types of failures may vary, depending on the function of the device system component and technology in use. However, typical failures include a system no longer performing its security function or not functioning in its intended manner—for example, a firewall erasing its rules or going offline.
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.
Постановление Правительства РФ № 584 от 13.06.2012 "Положение о защите информации в платежной системе":
п. 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 10.2.1
10.2.1
Определенные Требования к Подходу:
Журналы аудита включены и активны для всех компонентов системы и данных о держателях карт.
Цель Индивидуального подхода:
Фиксируются записи всех действий, влияющих на компоненты системы, и данные о держателях карт.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Журналы аудита включены и активны для всех компонентов системы и данных о держателях карт.
Цель Индивидуального подхода:
Фиксируются записи всех действий, влияющих на компоненты системы, и данные о держателях карт.
Определенные Процедуры Тестирования Подхода:
- 10.2.1 Опросите системного администратора и изучите системные конфигурации, чтобы убедиться, что журналы аудита включены и активны для всех компонентов системы.
Цель:
Журналы аудита должны существовать для всех компонентов системы. Журналы аудита отправляют предупреждения системному администратору, предоставляют данные другим механизмам мониторинга, таким как системы обнаружения вторжений (IDS) и средства защиты информации и систем мониторинга событий (SIEM), а также обеспечивают отслеживание истории для расследования после инцидента.
Ведение журнала и анализ событий, связанных с безопасностью, позволяют организации выявлять и отслеживать потенциально вредоносные действия.
Надлежащая практика:
Когда организация решает, какую информацию записывать в свои журналы, важно помнить, что информация, хранящаяся в журналах аудита, является конфиденциальной и должна быть защищена в соответствии с требованиями настоящего стандарта. Следует позаботиться о том, чтобы в журналах аудита сохранялась только важная информация, чтобы свести к минимуму риск.
Журналы аудита должны существовать для всех компонентов системы. Журналы аудита отправляют предупреждения системному администратору, предоставляют данные другим механизмам мониторинга, таким как системы обнаружения вторжений (IDS) и средства защиты информации и систем мониторинга событий (SIEM), а также обеспечивают отслеживание истории для расследования после инцидента.
Ведение журнала и анализ событий, связанных с безопасностью, позволяют организации выявлять и отслеживать потенциально вредоносные действия.
Надлежащая практика:
Когда организация решает, какую информацию записывать в свои журналы, важно помнить, что информация, хранящаяся в журналах аудита, является конфиденциальной и должна быть защищена в соответствии с требованиями настоящего стандарта. Следует позаботиться о том, чтобы в журналах аудита сохранялась только важная информация, чтобы свести к минимуму риск.
Requirement 10.7.2
10.7.2
Определенные Требования к Подходу:
Сбои критических систем контроля безопасности обнаруживаются, предупреждаются и оперативно устраняются, включая, но не ограничиваясь, отказ следующих критических систем контроля безопасности:
Определенные Требования к Подходу:
Сбои критических систем контроля безопасности обнаруживаются, предупреждаются и оперативно устраняются, включая, но не ограничиваясь, отказ следующих критических систем контроля безопасности:
- Средства управления сетевой безопасностью.
- IDS/IPS.
- Механизмы обнаружения изменений.
- Решения для защиты от вредоносных программ.
- Контроль физического доступа.
- Логический контроль доступа.
- Механизмы ведения журнала аудита.
- Элементы управления сегментацией (если они используются).
- Механизмы проверки журналов аудита.
- Автоматизированные средства тестирования безопасности (если они используются).
Цель Индивидуального подхода:
Сбои в критически важных системах контроля безопасности оперативно выявляются и устраняются.
Примечания по применению:
Это требование распространяется на все организации, включая поставщиков услуг, и заменит требование 10.7.1 с 31 марта 2025 года. Он включает в себя две дополнительные критически важные системы контроля безопасности, не указанные в требовании 10.7.1.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
Сбои в критически важных системах контроля безопасности оперативно выявляются и устраняются.
Примечания по применению:
Это требование распространяется на все организации, включая поставщиков услуг, и заменит требование 10.7.1 с 31 марта 2025 года. Он включает в себя две дополнительные критически важные системы контроля безопасности, не указанные в требовании 10.7.1.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
- 10.7.2.a Изучите документацию, чтобы убедиться, что определены процессы для оперативного обнаружения и устранения сбоев критических систем управления безопасностью, включая, но не ограничиваясь отказом всех элементов, указанных в этом требовании.
- 10.7.2.b Наблюдайте за процессами обнаружения и оповещения и опрашивайте персонал, чтобы убедиться, что сбои критических систем контроля безопасности обнаружены и сообщены, и что сбой критического контроля безопасности приводит к генерации предупреждения.
Цель:
Без формальных процессов обнаружения и оповещения о сбое критических средств защиты сбои могут оставаться незамеченными в течение длительного времени и предоставлять злоумышленникам достаточно времени для компрометации системных компонентов и кражи данных учетной записи из CDE.
Надлежащая практика:
Конкретные типы отказов могут варьироваться в зависимости от функции системного компонента устройства и используемой технологии. Однако типичные сбои включают в себя то, что система больше не выполняет свою функцию безопасности или не функционирует должным образом — например, брандмауэр стирает свои правила или переходит в автономный режим.
Без формальных процессов обнаружения и оповещения о сбое критических средств защиты сбои могут оставаться незамеченными в течение длительного времени и предоставлять злоумышленникам достаточно времени для компрометации системных компонентов и кражи данных учетной записи из CDE.
Надлежащая практика:
Конкретные типы отказов могут варьироваться в зависимости от функции системного компонента устройства и используемой технологии. Однако типичные сбои включают в себя то, что система больше не выполняет свою функцию безопасности или не функционирует должным образом — например, брандмауэр стирает свои правила или переходит в автономный режим.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.34
А.8.34 Защита информационных систем при аудиторском тестировании
Аудиторские тесты и иные действия по обеспечению уверенности, связанные с оценкой операционных систем, должны планироваться и согласовываться между тестировщиком и соответствующим руководством.
Аудиторские тесты и иные действия по обеспечению уверенности, связанные с оценкой операционных систем, должны планироваться и согласовываться между тестировщиком и соответствующим руководством.
FDA 21 CFR part 11 (RU):
Sec. 11.10 p. 1 sp. k2
(2) Процедуры управления версией и изменениями для ведения журнала аудита, документирующего упорядоченную по времени разработку и модификацию системной документации.
Стандарт Банка России № РС БР ИББС-2.5-2014 от 01.06.2014 "Менеджмент инцидентов информационной безопасности":
Р. 8 п. 3
8.3. В результате анализа рекомендуется определять наиболее проблемные с точки зрения подверженности инцидентам ИБ сегменты и компоненты информационной инфраструктуры организации БС РФ, наиболее существенные уязвимости и недостатки в обеспечении ИБ, оценивать достаточность принятых мер и выделенных ресурсов для реагирования на инциденты ИБ.
Кроме того, рекомендуется анализировать наличие тенденций, которые могут указывать на потребности в совершенствовании СОИБ организации БС РФ.
Кроме того, рекомендуется анализировать наличие тенденций, которые могут указывать на потребности в совершенствовании СОИБ организации БС РФ.
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
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.34
А.8.34 Protection of information systems during audit testing
Audit tests and other assurance activities involving assessment of operational systems shall be planned and agreed between the tester and appropriate management.
Audit tests and other assurance activities involving assessment of operational systems shall be planned and agreed between the tester and appropriate management.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.