Куда я попал?
Положение Банка России № 719-П от 04.06.2020
О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств
Глава 1 п. 1
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
1.1. Операторы по переводу денежных средств, банковские платежные агенты (субагенты), операторы услуг информационного обмена, операторы услуг платежной инфраструктуры в части требований к обеспечению защиты информации при осуществлении переводов денежных средств, применяемых в отношении автоматизированных систем, программного обеспечения, средств вычислительной техники, телекоммуникационного оборудования, эксплуатация и использование которых обеспечивается при осуществлении переводов денежных средств операторами по переводу денежных средств (далее - объекты информационной инфраструктуры), должны обеспечивать:
- реализацию установленных настоящим Положением уровней защиты информации для объектов информационной инфраструктуры, используемых для обработки, передачи, хранения информации, указанной в абзаце первом пункта 1.3 настоящего Положения, в целях осуществления переводов денежных средств, определенных национальным стандартом Российской Федерации ГОСТ Р 57580.1-2017 «Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер», утвержденным приказом Федерального агентства по техническому регулированию и метрологии от 8 августа 2017 года № 822-ст «Об утверждении национального стандарта Российской Федерации» (М., ФГУП «Стандартинформ», 2017) (далее - ГОСТ Р 57580.1-2017);
- ежегодное тестирование на проникновение и анализ уязвимостей информационной безопасности объектов информационной инфраструктуры с учетом особенностей, предусмотренных пунктами 3.8 и 3.9 настоящего Положения;
- проведение оценки соответствия уровням защиты информации, установленным настоящим Положением (далее - оценка соответствия защиты информации), в соответствии с национальным стандартом Российской Федерации ГОСТ Р 57580.2-2018 «Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Методика оценки соответствия», утвержденным приказом Федерального агентства по техническому регулированию и метрологии от 28 марта 2018 года № 156-ст «Об утверждении национального стандарта Российской Федерации» (М., ФГУП «Стандартинформ», 2018) (далее - ГОСТ Р 57580.2-2018), с учетом особенностей, предусмотренных пунктами 2.3, 2.4, 3.6 - 3.9, 4.4, 4.5, 6.7 и 6.8 настоящего Положения.
Оценка соответствия защиты информации должна осуществляться с привлечением сторонних организаций, имеющих лицензию на осуществление деятельности по технической защите конфиденциальной информации на проведение работ и услуг, предусмотренных подпунктами «б», «д» или «е» пункта 4 Положения о лицензировании деятельности по технической защите конфиденциальной информации, утвержденного постановлением Правительства Российской Федерации от 3 февраля 2012 года № 79 «О лицензировании деятельности по технической защите конфиденциальной информации» (Собрание законодательства Российской Федерации, 2012, № 7, ст. 863; 2016, № 26, ст. 4049) (далее соответственно - проверяющая организация, постановление Правительства Российской Федерации № 79).
Операторы по переводу денежных средств, банковские платежные агенты (субагенты), операторы услуг информационного обмена, операторы услуг платежной инфраструктуры должны обеспечивать хранение отчета, подготовленного проверяющей организацией по результатам оценки соответствия защиты информации, не менее пяти лет начиная с даты его выдачи проверяющей организацией.
Похожие требования
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 9. Требования к защите информации на этапах жизненного цикла автоматизированных систем и приложений":
ЖЦ.20
ЖЦ.20 Реализация проведения ежегодного контроля защищенности АС, включающего: - тестирование на проникновение; - анализ уязвимостей системы защиты информации АС и информационной инфраструктуры промышленной среды
3-Н 2-О 1-О
3-Н 2-О 1-О
ЖЦ.14
ЖЦ.14 Реализация контроля защищенности АС, включающего (по решению финансовой организации при модернизации АС проводится контроль защищенности только элементов информационной инфраструктуры, подвергнутых модернизации): - тестирование на проникновение; - анализ уязвимостей системы защиты информации АС и информационной инфраструктуры промышленной среды
3-Н 2-О 1-О
3-Н 2-О 1-О
ГОСТ Р № 57580.3-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Управление риском реализации информационных угроз и обеспечение операционной надежности. Общие положения.":
ВИО.9.2
ВИО.9.2 Оценки возможностей нарушителя безопасности информации;
ВИО.9.3
ВИО.9.3 Выявления возможных уязвимостей критичной архитектуры;
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 6. п.п. 2
6.2. Кредитные организации должны обеспечивать выполнение следующих требований к управлению изменениями критичной архитектуры:
- управление уязвимостями в критичной архитектуре, из-за которых могут реализоваться информационные угрозы и которые могут повлечь превышение значений целевых показателей операционной надежности;
- планирование и внедрение изменений в критичной архитектуре, направленных на обеспечение недопустимости неоказания или ненадлежащего оказания банковских услуг;
- управление конфигурациями (настраиваемыми параметрами) объектов информационной инфраструктуры;
- управление уязвимостями и обновлениями (исправлениями) объектов информационной инфраструктуры.
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
ЦЗИ.8
ЦЗИ.8 Контроль отсутствия и обеспечение оперативного устранения известных (описанных) уязвимостей, указанных в пунктах ЦЗИ.1-ЦЗИ.6 настоящей таблицы, путем сканирования и анализа состава, версий и параметров настроек прикладного ПО, ПО АС и системного ПО, реализующего функции обеспечения защиты информации и (или) влияющего на обеспечение защиты информации (далее в настоящем разделе - системное ПО, в том числе ПО операционных систем, ПО СУБД, ПО серверов приложений, ПО систем виртуализации), установленного на серверном и сетевом оборудовании
3-Н 2-Т 1-Т
3-Н 2-Т 1-Т
NIST Cybersecurity Framework (RU):
DE.CM-8
DE.CM-8: Выполняется сканирование уязвимостей
ID.RA-1
ID.RA-1: Идентифицированы и задокументированы уязвимости активов
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
АНЗ.1
АНЗ.1 Выявление, анализ уязвимостей информационной системы и оперативное устранение вновь выявленных уязвимостей
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
УИ.33
УИ.33 Использование в качестве источников информации об уязвимостях, а также регулярное обновление и контроль актуальности используемой информации для проведения сканирования на уязвимости:
- баз данных общеизвестных уязвимостей (например, Common Vulnerabilities and Exposures, Банк данных угроз безопасности информации);
- сведений об уязвимостях, полученных в рамках тестирования «red team»;
- иных источников.
ТОН.6.2
ТОН.6.2 Тестирования возможности финансовой организации совместно с причастными сторонами обеспечить эффективное реагирование на инциденты и восстановление после их реализации в соответствии с заданными временными периодами (ЦВВ), в том числе в отношении переданных на аутсорсинг бизнес- и технологических процессов;
ТОН.4
ТОН.4 Организация и выполнение деятельности по тестированию готовности финансовой организации противостоять реализации информационных угроз на основе сформированных сценариев, включая:
- выявление конфигураций объектов информатизации, имеющих уязвимости;
- выявление актуальных слабостей (уязвимостей) используемого программного обеспечения;
- определение актуальных компьютерных атак, которые могут быть реализованы путем эксплуатации выявленных слабостей и уязвимостей;
- определение вероятных инцидентов, связанных с реализацией информационных угроз, к которым может привести реализация актуальных компьютерных атак;
- определение потенциальных последствий от реализации инцидентов, в том числе максимально возможных финансовых потерь.
ТОН.6.1
ТОН.6.1 Тестирования возможности финансовой организации обеспечить эффективное реагирование на инциденты и восстановление после их реализации в соответствии с заданными временными периодами (ЦВВ);
ТОН.6.3
ТОН.6.3 Тестирования возможностей финансовой организации обеспечить эффективное взаимодействие с причастными сторонами при реализации инцидентов;
ТОН.6.4
ТОН.6.4 Тестирование возможности финансовой организации обеспечить своевременное информирование об инцидентах Банка России, федерального органа исполнительной власти, уполномоченного в области обеспечения функционирования государственной системы обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации, а также причастных сторон.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 11.4.2
11.4.2
Defined Approach Requirements:
Internal penetration testing is performed:
Defined Approach Requirements:
Internal penetration testing is performed:
- Per the entity’s defined methodology,
- At least once every 12 months
- After any significant infrastructure or application upgrade or change
- By a qualified internal resource or qualified external third-party
- Organizational independence of the tester exists (not required to be a QSA or ASV).
Customized Approach Objective:
Internal system defenses are verified by technical testing according to the entity’s defined methodology as frequently as needed to address evolving and new attacks and threats and ensure that significant changes do not introduce unknown vulnerabilities
Defined Approach Testing Procedures:
Internal system defenses are verified by technical testing according to the entity’s defined methodology as frequently as needed to address evolving and new attacks and threats and ensure that significant changes do not introduce unknown vulnerabilities
Defined Approach Testing Procedures:
- 11.4.2.a Examine the scope of work and results from the most recent internal penetration test to verify that penetration testing is performed in accordance with all elements specified in this requirement.
- 11.4.2.b Interview personnel to verify that the internal penetration test was performed by a qualified internal resource or qualified external third-party and that organizational independence of the tester exists (not required to be a QSA or ASV).
Purpose:
Internal penetration testing serves two purposes. Firstly, just like an external penetration test, it discovers vulnerabilities and misconfigurations that could be used by an attacker that had managed to get some degree of access to the internal network, whether that is because the attacker is an authorized user conducting unauthorized activities, or an external attacker that had managed to penetrate the entity’s perimeter.
Secondly, internal penetration testing also helps entities to discover where their change control process failed by detecting previously unknown systems. Additionally, it verifies the status of many of the controls operating within the CDE.
A penetration test is not truly a “test” because the outcome of a penetration test is not something that can be classified as a “pass” or a “fail.” The best outcome of a test is a catalog of vulnerabilities and misconfigurations that an entity did not know about and the penetration tester found them before an attacker could. A penetration test that found nothing is typically indicative of shortcomings of the penetration tester, rather than being a positive reflection of the security posture of the entity.
Good Practice:
Some considerations when choosing a qualified resource to perform penetration testing include:
Internal penetration testing serves two purposes. Firstly, just like an external penetration test, it discovers vulnerabilities and misconfigurations that could be used by an attacker that had managed to get some degree of access to the internal network, whether that is because the attacker is an authorized user conducting unauthorized activities, or an external attacker that had managed to penetrate the entity’s perimeter.
Secondly, internal penetration testing also helps entities to discover where their change control process failed by detecting previously unknown systems. Additionally, it verifies the status of many of the controls operating within the CDE.
A penetration test is not truly a “test” because the outcome of a penetration test is not something that can be classified as a “pass” or a “fail.” The best outcome of a test is a catalog of vulnerabilities and misconfigurations that an entity did not know about and the penetration tester found them before an attacker could. A penetration test that found nothing is typically indicative of shortcomings of the penetration tester, rather than being a positive reflection of the security posture of the entity.
Good Practice:
Some considerations when choosing a qualified resource to perform penetration testing include:
- Specific penetration testing certifications, which may be an indication of the tester’s skill level and competence.
- Prior experience conducting penetration testing—for example, the number of years of experience, and the type and scope of prior engagements can help confirm whether the tester’s experience is appropriate for the needs of the engagement.
Further Information:
Refer to the Information Supplement: Penetration Testing Guidance on the PCI SSC website for additional guidance.
Refer to the Information Supplement: Penetration Testing Guidance on the PCI SSC website for additional guidance.
Requirement 11.4.4
11.4.4
Defined Approach Requirements:
Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected as follows:
Defined Approach Requirements:
Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected as follows:
- In accordance with the entity’s assessment of the risk posed by the security issue as defined in Requirement 6.3.1.
- Penetration testing is repeated to verify the corrections.
Customized Approach Objective:
Vulnerabilities and security weaknesses found while verifying system defenses are mitigated.
Defined Approach Testing Procedures:
Vulnerabilities and security weaknesses found while verifying system defenses are mitigated.
Defined Approach Testing Procedures:
- 11.4.4 Examine penetration testing results to verify that noted exploitable vulnerabilities and security weaknesses were corrected in accordance with all elements specified in this requirement.
Purpose:
The results of a penetration test are usually a prioritized list of vulnerabilities discovered by the exercise. Often a tester will have chained a number of vulnerabilities together to compromise a system component. Remediating the vulnerabilities found by a penetration test significantly reduces the probability that the same vulnerabilities will be exploited by a malicious attacker.
Using the entity’s own vulnerability risk assessment process (see requirement 6.3.1) ensures that the vulnerabilities that pose the highest risk to the entity will be remediated more quickly.
Good Practice:
As part of the entity’s assessment of risk, entities should consider how likely the vulnerability is to be exploited and whether there are other controls present in the environment to reduce the risk.
Any weaknesses that point to PCI DSS requirements not being met should be addressed.
The results of a penetration test are usually a prioritized list of vulnerabilities discovered by the exercise. Often a tester will have chained a number of vulnerabilities together to compromise a system component. Remediating the vulnerabilities found by a penetration test significantly reduces the probability that the same vulnerabilities will be exploited by a malicious attacker.
Using the entity’s own vulnerability risk assessment process (see requirement 6.3.1) ensures that the vulnerabilities that pose the highest risk to the entity will be remediated more quickly.
Good Practice:
As part of the entity’s assessment of risk, entities should consider how likely the vulnerability is to be exploited and whether there are other controls present in the environment to reduce the risk.
Any weaknesses that point to PCI DSS requirements not being met should be addressed.
Requirement 11.4.3
11.4.3
Defined Approach Requirements:
External penetration testing is performed:
Defined Approach Requirements:
External penetration testing is performed:
- Per the entity’s defined methodology
- At least once every 12 months
- After any significant infrastructure or application upgrade or change
- By a qualified internal resource or qualified external third party
- Organizational independence of the tester exists (not required to be a QSA or ASV).
Customized Approach Objective:
External system defenses are verified by technical testing according to the entity’s defined methodology as frequently as needed to address evolving and new attacks and threats, and to ensure that significant changes do not introduce unknown vulnerabilities.
Defined Approach Testing Procedures:
External system defenses are verified by technical testing according to the entity’s defined methodology as frequently as needed to address evolving and new attacks and threats, and to ensure that significant changes do not introduce unknown vulnerabilities.
Defined Approach Testing Procedures:
- 11.4.3.a Examine the scope of work and results from the most recent external penetration test to verify that penetration testing is performed according to all elements specified in this requirement.
- 11.4.3.b Interview personnel to verify that the external penetration test was performed by a qualified internal resource or qualified external third-party and that organizational independence of the tester exists (not required to be a QSA or ASV).
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.12.6.1
A.12.6.1 Процесс управления техническими уязвимостями
Мера обеспечения информационной безопасности: Должна быть своевременно получена информация о технических уязвимостях используемых информационных систем, оценена подверженность организации таким уязвимостям, и должны быть приняты соответствующие меры в отношении связанного с этим риска информационной безопасности
Мера обеспечения информационной безопасности: Должна быть своевременно получена информация о технических уязвимостях используемых информационных систем, оценена подверженность организации таким уязвимостям, и должны быть приняты соответствующие меры в отношении связанного с этим риска информационной безопасности
Положение Банка России № 802-П от 25.07.2022 "О требованиях к защите информации в платежной системе Банка России":
П. 20
20. Для оценки участниками ССНП, участниками СБП, ОПКЦ СБП и ОУИО СБП выполнения ими требований к обеспечению защиты информации при осуществлении переводов денежных средств (далее - оценка соответствия) устанавливаются следующие требования:
- оценка соответствия должна проводиться в пределах выделенных сегментов (группы сегментов) вычислительных сетей, указанных в пунктах 3 - 6 настоящего Положения;
- оценка соответствия должна проводиться в соответствии с положениями раздела 6 национального стандарта Российской Федерации ГОСТ Р 57580.2-2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Методика оценки соответствия", утвержденного приказом Федерального агентства по техническому регулированию и метрологии от 28 марта 2018 года N 156-ст и введенного в действие 1 сентября 2018 года (далее - ГОСТ Р 57580.2-2018);
- оценка соответствия должна проводиться не реже одного раза в два года.
Участники ССНП, участники СБП, ОПКЦ СБП и ОУИО СБП должны обеспечивать для объектов информационной инфраструктуры, размещенных в отдельных выделенных сегментах (группах сегментов) вычислительных сетей, указанных в пунктах 3 - 6 настоящего Положения, уровень соответствия не ниже четвертого, предусмотренного подпунктом "д" пункта 6.9 раздела 6 ГОСТ Р 57580.2-2018.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 11.4.3
11.4.3
Определенные Требования к Подходу:
Выполняется внешнее тестирование на проникновение:
Определенные Требования к Подходу:
Выполняется внешнее тестирование на проникновение:
- В соответствии с определенной организацией методологией
- Не реже одного раза в 12 месяцев
- После любого значительного обновления или изменения инфраструктуры или приложения
- Квалифицированным внутренним ресурсом или квалифицированной внешней третьей стороной
- Существует организационная независимость тестировщика (не обязательно быть QSA или ASV).
Цель Индивидуального подхода:
Защита внешней системы проверяется путем технического тестирования в соответствии с определенной организацией методологией так часто, как это необходимо для устранения возникающих и новых атак и угроз, а также для обеспечения того, чтобы значительные изменения не приводили к появлению неизвестных уязвимостей.
Определенные Процедуры Тестирования Подхода:
Защита внешней системы проверяется путем технического тестирования в соответствии с определенной организацией методологией так часто, как это необходимо для устранения возникающих и новых атак и угроз, а также для обеспечения того, чтобы значительные изменения не приводили к появлению неизвестных уязвимостей.
Определенные Процедуры Тестирования Подхода:
- 11.4.3.a Изучите объем работ и результаты последнего внешнего теста на проникновение, чтобы убедиться, что тестирование на проникновение выполнено в соответствии со всеми элементами, указанными в этом требовании.
- 11.4.3.b Провести собеседование с персоналом, чтобы убедиться, что внешний тест на проникновение был выполнен квалифицированным внутренним ресурсом или квалифицированной внешней третьей стороной и что существует организационная независимость тестировщика (не обязательно быть QSA или ASV).
Requirement 11.4.4
11.4.4
Определенные Требования к Подходу:
Уязвимые места и недостатки безопасности, обнаруженные в ходе тестирования на проникновение, исправляются следующим образом:
Определенные Требования к Подходу:
Уязвимые места и недостатки безопасности, обнаруженные в ходе тестирования на проникновение, исправляются следующим образом:
- В соответствии с оценкой субъектом риска, связанного с проблемой безопасности, как определено в Требовании 6.3.1.
- Тестирование на проникновение повторяется для проверки исправлений.
Цель Индивидуального подхода:
Уязвимости и слабые места в системе безопасности, обнаруженные при проверке системной защиты, устраняются.
Определенные Процедуры Тестирования Подхода:
Уязвимости и слабые места в системе безопасности, обнаруженные при проверке системной защиты, устраняются.
Определенные Процедуры Тестирования Подхода:
- 11.4.4 Изучите результаты тестирования на проникновение, чтобы убедиться, что отмеченные уязвимые места и недостатки безопасности были исправлены в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Результаты теста на проникновение обычно представляют собой приоритетный список уязвимостей, обнаруженных в ходе проверки. Часто тестировщик связывает несколько уязвимостей вместе, чтобы скомпрометировать системный компонент. Устранение уязвимостей, обнаруженных с помощью теста на проникновение, значительно снижает вероятность того, что те же уязвимости будут использованы злоумышленником.
Использование собственного процесса оценки риска уязвимости организации (см. требование 6.3.1) гарантирует, что уязвимости, представляющие наибольший риск для организации, будут устранены быстрее.
Надлежащая практика:
В рамках оценки риска субъектом субъекты должны учитывать, насколько вероятно использование уязвимости и существуют ли в среде другие средства контроля для снижения риска.
Любые недостатки, указывающие на несоблюдение требований PCI DSS, должны быть устранены.
Результаты теста на проникновение обычно представляют собой приоритетный список уязвимостей, обнаруженных в ходе проверки. Часто тестировщик связывает несколько уязвимостей вместе, чтобы скомпрометировать системный компонент. Устранение уязвимостей, обнаруженных с помощью теста на проникновение, значительно снижает вероятность того, что те же уязвимости будут использованы злоумышленником.
Использование собственного процесса оценки риска уязвимости организации (см. требование 6.3.1) гарантирует, что уязвимости, представляющие наибольший риск для организации, будут устранены быстрее.
Надлежащая практика:
В рамках оценки риска субъектом субъекты должны учитывать, насколько вероятно использование уязвимости и существуют ли в среде другие средства контроля для снижения риска.
Любые недостатки, указывающие на несоблюдение требований PCI DSS, должны быть устранены.
Requirement 11.4.2
11.4.2
Определенные Требования к Подходу:
Выполняется внутреннее тестирование на проникновение:
Определенные Требования к Подходу:
Выполняется внутреннее тестирование на проникновение:
- В соответствии с определенной организацией методологией,
- Не реже одного раза в 12 месяцев
- После любого значительного обновления или изменения инфраструктуры или приложения
- Квалифицированным внутренним ресурсом или квалифицированной внешней третьей стороной
- Существует организационная независимость тестировщика (не обязательно быть QSA или ASV).
Цель Индивидуального подхода:
Внутренняя защита системы проверяется путем технического тестирования в соответствии с определенной организацией методологией так часто, как это необходимо для устранения возникающих и новых атак и угроз и обеспечения того, чтобы значительные изменения не приводили к появлению неизвестных уязвимостей
Определенные Процедуры Тестирования Подхода:
Внутренняя защита системы проверяется путем технического тестирования в соответствии с определенной организацией методологией так часто, как это необходимо для устранения возникающих и новых атак и угроз и обеспечения того, чтобы значительные изменения не приводили к появлению неизвестных уязвимостей
Определенные Процедуры Тестирования Подхода:
- 11.4.2.a Изучите объем работ и результаты последнего внутреннего теста на проникновение, чтобы убедиться, что тестирование на проникновение выполнено в соответствии со всеми элементами, указанными в этом требовании.
- 11.4.2.b Провести собеседование с персоналом, чтобы убедиться, что внутренний тест на проникновение был выполнен квалифицированным внутренним ресурсом или квалифицированной внешней третьей стороной и что существует организационная независимость тестировщика (не обязательно быть QSA или ASV).
Цель:
Внутреннее тестирование на проникновение служит двум целям. Во-первых, как и внешний тест на проникновение, он обнаруживает уязвимости и неправильные настройки, которые могут быть использованы злоумышленником, которому удалось получить некоторый доступ к внутренней сети, независимо от того, является ли это авторизованным пользователем, выполняющим несанкционированные действия, или внешним злоумышленником, которому удалось проникнуть в объектпериметр.
Во-вторых, внутреннее тестирование на проникновение также помогает организациям обнаружить, где их процесс управления изменениями потерпел неудачу, обнаруживая ранее неизвестные системы. Кроме того, он проверяет состояние многих элементов управления, работающих в CDE.
Тест на проникновение на самом деле не является “тестом”, потому что результат теста на проникновение - это не то, что можно классифицировать как “прошел” или “не прошел”. Лучший результат теста - это каталог уязвимостей и неправильных настроек, о которых организация не знала, а тестировщик на проникновение обнаружил их раньше, чем это смог бы сделать злоумышленник. Тест на проникновение, который ничего не обнаружил, обычно указывает на недостатки тестировщика на проникновение, а не является положительным отражением состояния безопасности организации.
Надлежащая практика:
Некоторые соображения при выборе квалифицированного ресурса для проведения тестирования на проникновение включают:
Внутреннее тестирование на проникновение служит двум целям. Во-первых, как и внешний тест на проникновение, он обнаруживает уязвимости и неправильные настройки, которые могут быть использованы злоумышленником, которому удалось получить некоторый доступ к внутренней сети, независимо от того, является ли это авторизованным пользователем, выполняющим несанкционированные действия, или внешним злоумышленником, которому удалось проникнуть в объектпериметр.
Во-вторых, внутреннее тестирование на проникновение также помогает организациям обнаружить, где их процесс управления изменениями потерпел неудачу, обнаруживая ранее неизвестные системы. Кроме того, он проверяет состояние многих элементов управления, работающих в CDE.
Тест на проникновение на самом деле не является “тестом”, потому что результат теста на проникновение - это не то, что можно классифицировать как “прошел” или “не прошел”. Лучший результат теста - это каталог уязвимостей и неправильных настроек, о которых организация не знала, а тестировщик на проникновение обнаружил их раньше, чем это смог бы сделать злоумышленник. Тест на проникновение, который ничего не обнаружил, обычно указывает на недостатки тестировщика на проникновение, а не является положительным отражением состояния безопасности организации.
Надлежащая практика:
Некоторые соображения при выборе квалифицированного ресурса для проведения тестирования на проникновение включают:
- Специальные сертификаты тестирования на проникновение, которые могут свидетельствовать об уровне квалификации и компетентности тестировщика.
- Предыдущий опыт проведения тестирования на проникновение — например, количество лет опыта, а также тип и объем предыдущих заданий могут помочь подтвердить, соответствует ли опыт тестировщика потребностям задания.
Дополнительная информация:
Дополнительные рекомендации см. в Информационном дополнении: Руководство по тестированию на проникновение на веб-сайте PCI SSC.
Дополнительные рекомендации см. в Информационном дополнении: Руководство по тестированию на проникновение на веб-сайте PCI SSC.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
АНЗ.1
АНЗ.1 Выявление, анализ уязвимостей информационной системы и оперативное устранение вновь выявленных уязвимостей
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.8
А.8.8 Управление техническими уязвимостями
Должна своевременно получаться информация о технических уязвимостях используемых информационных систем, также должно оцениваться воздействие таких уязвимостей на организацию, и должны предприниматься соответствующие меры.
Должна своевременно получаться информация о технических уязвимостях используемых информационных систем, также должно оцениваться воздействие таких уязвимостей на организацию, и должны предприниматься соответствующие меры.
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
АУД.11
АУД.11 Проведение внешних аудитов
АУД.2
АУД.2 Анализ уязвимостей и их устранение
Положение Банка России № 757-П от 20.04.2021 "Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций":
1.5.2.
1.5.2. Оценка соответствия уровня защиты информации должна осуществляться некредитными финансовыми организациями с привлечением проверяющих организаций в соответствии с требованиями национального стандарта Российской Федерации ГОСТ Р 57580.2-2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Методика оценки соответствия", утвержденного приказом Федерального агентства по техническому регулированию и метрологии от 28 марта 2018 года N 156-ст "Об утверждении национального стандарта Российской Федерации" (далее - ГОСТ Р 57580.2-2018).
1.8.
1.8. Некредитные финансовые организации, реализующие усиленный и стандартный уровни защиты информации, должны обеспечить использование для осуществления финансовых операций прикладного программного обеспечения автоматизированных систем и приложений, распространяемых некредитными финансовыми организациями своим клиентам для совершения действий в целях осуществления финансовых операций, а также программного обеспечения, обрабатывающего защищаемую информацию при приеме электронных сообщений к исполнению в автоматизированных системах и приложениях с использованием информационно-телекоммуникационной сети "Интернет" (далее - сеть "Интернет"), прошедших сертификацию в системе сертификации Федеральной службы по техническому и экспортному контролю (далее - сертификация) или оценку соответствия по требованиям к оценочному уровню доверия (далее - ОУД) не ниже, чем ОУД 4, в соответствии с требованиями национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 15408-3-2013 "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности", утвержденного приказом Федерального агентства по техническому регулированию и метрологии от 8 ноября 2013 года N 1340-ст "Об утверждении национального стандарта" (далее - ГОСТ Р ИСО/МЭК 15408-3-2013) (далее - оценка соответствия прикладного программного обеспечения автоматизированных систем и приложений).
Некредитные финансовые организации, не реализующие усиленный и стандартный уровни защиты информации, должны самостоятельно определять необходимость сертификации или оценки соответствия прикладного программного обеспечения автоматизированных систем и приложений.
В отношении программного обеспечения и приложений, не указанных в абзаце первом настоящего пункта, некредитные финансовые организации должны самостоятельно определять необходимость сертификации или оценки соответствия прикладного программного обеспечения автоматизированных систем и приложений.
По решению некредитной финансовой организации оценка соответствия прикладного программного обеспечения автоматизированных систем и приложений проводится самостоятельно или с привлечением проверяющей организации.
Некредитные финансовые организации, реализующие усиленный уровень защиты информации, в случае сертификации прикладного программного обеспечения автоматизированных систем и приложений должны обеспечить их сертификацию не ниже 4 уровня доверия в соответствии с Требованиями по безопасности информации, устанавливающими уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий, утвержденными приказом Федеральной службы по техническому и экспортному контролю от 2 июня 2020 года N 76 "Об утверждении Требований по безопасности информации, устанавливающих уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий", зарегистрированным Министерством юстиции Российской Федерации 11 сентября 2020 года N 59772 (далее - приказ ФСТЭК России N 76).
Некредитные финансовые организации, реализующие стандартный уровень защиты информации, в случае сертификации прикладного программного обеспечения автоматизированных систем и приложений должны обеспечить их сертификацию не ниже 5 уровня доверия в соответствии с Требованиями по безопасности информации, устанавливающими уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий, утвержденными приказом ФСТЭК России N 76.
Некредитные финансовые организации, не реализующие усиленный и стандартный уровни защиты информации, должны самостоятельно определять необходимость сертификации или оценки соответствия прикладного программного обеспечения автоматизированных систем и приложений.
В отношении программного обеспечения и приложений, не указанных в абзаце первом настоящего пункта, некредитные финансовые организации должны самостоятельно определять необходимость сертификации или оценки соответствия прикладного программного обеспечения автоматизированных систем и приложений.
По решению некредитной финансовой организации оценка соответствия прикладного программного обеспечения автоматизированных систем и приложений проводится самостоятельно или с привлечением проверяющей организации.
Некредитные финансовые организации, реализующие усиленный уровень защиты информации, в случае сертификации прикладного программного обеспечения автоматизированных систем и приложений должны обеспечить их сертификацию не ниже 4 уровня доверия в соответствии с Требованиями по безопасности информации, устанавливающими уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий, утвержденными приказом Федеральной службы по техническому и экспортному контролю от 2 июня 2020 года N 76 "Об утверждении Требований по безопасности информации, устанавливающих уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий", зарегистрированным Министерством юстиции Российской Федерации 11 сентября 2020 года N 59772 (далее - приказ ФСТЭК России N 76).
Некредитные финансовые организации, реализующие стандартный уровень защиты информации, в случае сертификации прикладного программного обеспечения автоматизированных систем и приложений должны обеспечить их сертификацию не ниже 5 уровня доверия в соответствии с Требованиями по безопасности информации, устанавливающими уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий, утвержденными приказом ФСТЭК России N 76.
1.5.3.
1.5.3. Оценка соответствия уровня защиты информации некредитными финансовыми организациями, реализующими усиленный уровень защиты информации, должна осуществляться не реже одного раза в год, некредитными финансовыми организациями, реализующими стандартный уровень защиты информации, - не реже одного раза в три года.
1.4.5.
1.4.5. Некредитные финансовые организации, реализующие усиленный уровень защиты информации, и некредитные финансовые организации, реализующие стандартный уровень защиты информации (далее при совместном упоминании - некредитные финансовые организации, реализующие усиленный и стандартный уровни защиты информации), должны осуществлять ежегодное тестирование объектов информационной инфраструктуры на предмет проникновений и анализ уязвимостей информационной безопасности объектов информационной инфраструктуры.
В случае выявления уязвимостей информационной безопасности объектов информационной инфраструктуры некредитные финансовые организации, реализующие усиленный и стандартный уровни защиты информации, должны устранять выявленные уязвимости в порядке и сроки, установленные в разрабатываемых такими некредитными финансовыми организациями документах, регламентирующих процедуры нейтрализации угроз безопасности информации.
В случае выявления уязвимостей информационной безопасности объектов информационной инфраструктуры некредитные финансовые организации, реализующие усиленный и стандартный уровни защиты информации, должны устранять выявленные уязвимости в порядке и сроки, установленные в разрабатываемых такими некредитными финансовыми организациями документах, регламентирующих процедуры нейтрализации угроз безопасности информации.
Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":
п. 1.5.
1.5. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны обеспечивать выполнение следующих требований в отношении управления изменениями критичной архитектуры:
- управление уязвимостями в критичной архитектуре, с использованием которых могут реализоваться информационные угрозы и которые могут повлечь отклонение от значений целевых показателей операционной надежности, указанных в пункте 1.3 настоящего Положения;
- планирование и внедрение изменений в критичной архитектуре, направленных на обеспечение непрерывного оказания финансовых услуг;
- управление конфигурациями объектов информационной инфраструктуры некредитных финансовых организаций;
- управление уязвимостями и обновлениями (исправлениями) объектов информационной инфраструктуры некредитных финансовых организаций.
Положение Банка России № 683-П от 17.04.2019 "Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента":
9.1.
9.1. Оценка соответствия защиты информации должна осуществляться в соответствии с национальным стандартом Российской Федерации ГОСТ Р 57580.2-2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Методика оценки соответствия", (далее - ГОСТ Р 57580.2-2018).
Кредитные организации должны обеспечивать хранение отчета, подготовленного проверяющей организацией по результатам оценки соответствия защиты информации, не менее пяти лет начиная с даты его выдачи проверяющей организацией.
Кредитные организации должны обеспечивать хранение отчета, подготовленного проверяющей организацией по результатам оценки соответствия защиты информации, не менее пяти лет начиная с даты его выдачи проверяющей организацией.
3.2.
3.2. Кредитные организации должны обеспечить ежегодное тестирование на проникновение и анализ уязвимостей информационной безопасности объектов информационной инфраструктуры.
NIST Cybersecurity Framework (EN):
DE.CM-8
DE.CM-8: Vulnerability scans are performed
ID.RA-1
ID.RA-1: Asset vulnerabilities are identified and documented
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
АУД.11
АУД.11 Проведение внешних аудитов
АУД.2
АУД.2 Анализ уязвимостей и их устранение
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
12.6.1
В ответ на выявление потенциальных технических уязвимостей должны быть предприняты надлежащие и своевременные действия. Необходимо придерживаться следующих указаний для создания эффективного процесса управления техническими уязвимостями:
12.6.1 Процесс управления техническими уязвимостями
Мера обеспечения ИБ
Должна быть своевременно получена информация о технических уязвимостях используемых информационных систем, оценена подверженность организации таким уязвимостям и приняты соответствующие меры в отношении связанного с этим риска ИБ.
Руководство по применению
Актуальный и полный перечень активов (раздел 8) является необходимым условием для эффективного управления техническими уязвимостями. Специальная информация, необходимая для поддержки управления техническими уязвимостями, включает в себя информацию о поставщике программного обеспечения, номерах версий, текущем состоянии развертывания (например, какое программное обеспечение установлено в каких системах) и работниках, ответственных за программное обеспечение в организации.
В ответ на выявление потенциальных технических уязвимостей должны быть предприняты надлежащие и своевременные действия. Необходимо придерживаться следующих указаний для создания эффективного процесса управления техническими уязвимостями:
- a) организация должна определить и установить роли и обязанности, связанные с управлением техническими уязвимостями, включая их мониторинг, оценку риска, исправление ошибок, отслеживание активов и любые необходимые обязанности по координации процесса;
- b) для программного обеспечения и других технологий (на основе перечня активов, см. 8.1.1) следует идентифицировать информационные ресурсы, которые будут использоваться для выявления соответствующих технических уязвимостей и поддержания осведомленности о них; эти информационные ресурсы должны обновляться в соответствии с изменениями в перечне активов или при обнаружении новых и полезных ресурсов;
- c) следует определить сроки реагирования на уведомления о потенциально значимых технических уязвимостях;
- d) после выявления потенциальной технической уязвимости организация должна определить связанные с ней риски и действия, которые необходимо предпринять; такие действия могут включать применение пакетов исправлений к уязвимым системам или применение компенсирующих мер обеспечения ИБ;
- e) в зависимости от того, насколько срочно необходимо устранить техническую уязвимость, предпринимаемые действия должны проводиться в соответствии с мерами по управлению изменениями (см. 12.1.2) или в соответствии с процедурами реагирования на инциденты ИБ (см. 16.1.5);
- f) если доступно официальное исправление, следует оценить риски, связанные с его установкой (риски, связанные с уязвимостью, следует сравнить с рисками, которые могут возникнуть вследствие установки исправления);
- g) пакеты исправлений должны быть проверены и оценены до их установки, чтобы быть уверенным в том, что они не приведут к недопустимым побочным эффектам; если исправлений не выпущено, следует рассмотреть иные меры обеспечения информационной безопасности, такие как:
- отключение сервисов и возможностей, связанных с уязвимостью;
- настройка или добавление мер контроля доступа, например межсетевые экраны на границах сети (см. 13.1);
- усиление мониторинга для выявления реальных атак;
- повышение осведомленности об уязвимостях;
- h) следует вести журнал всех предпринятых действий;
- i) процесс управления техническими уязвимостями следует регулярно контролировать и оценивать для обеспечения его эффективности и результативности;
- j) в первую очередь следует обращать внимание на системы с высоким уровнем риска;
- k) эффективный процесс управления техническими уязвимостями должен быть согласован с действиями по управлению инцидентами, что позволит передавать данные об уязвимостях группе реагирования на инциденты и дополнит процесс техническими процедурами, которые должны быть выполнены в случае инцидента;
- l) необходимо определить процедуру для решения ситуации, когда уязвимость была выявлена, но подходящих мер еще не существует. В этой ситуации организация должна оценить риски, связанные с известной уязвимостью, и определить соответствующие действия по обнаружению и корректировке.
Дополнительная информация
Управление техническими уязвимостями может рассматриваться как подфункция процесса управления изменениями и, как следствие, может использовать преимущества процессов и процедур управления изменениями (см. 12.1.2 и 14.2.2).
Производители часто испытывают на себе значительное давление, заключающееся в требовании выпускать пакеты исправлений как можно скорее. Следовательно существует вероятность того, что исправление не решает проблему должным образом и имеет отрицательные побочные эффекты. Кроме того, в некоторых случаях после применения исправления его удаление может оказаться проблематичным.
Если адекватное тестирование исправлений невозможно, например из-за затрат или нехватки ресурсов, то следует рассмотреть возможность задержки его применения и оценить связанные с этим риски, основываясь на опыте, полученном от других пользователей. Может оказаться полезным использование ИСО/МЭК 27031 [14].
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.8.8
А.8.8 Management of technical vulnerabilities
Information about technical vulnerabilities of information systems in use shall be obtained, the organization’s exposure to such vulnerabilities shall be evaluated and appropriate measures shall be taken.
Information about technical vulnerabilities of information systems in use shall be obtained, the organization’s exposure to such vulnerabilities shall be evaluated and appropriate measures shall be taken.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.