Тестирование на проникновение с учетом Методических рекомендаций Банка России №2-МР

Пентест по 2-МР: зачем он нужен финансовым организациям

Методические рекомендации Банка России № 2-МР разработаны для формирования единого подхода к проведению тестирования на проникновение и анализа уязвимостей информационной безопасности объектов информационной инфраструктуры организаций финансового рынка.

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

Для таких организаций тестирование на проникновение — это не просто техническая проверка внешнего периметра. Это управляемый процесс оценки защищенности объектов информационной инфраструктуры, который должен быть связан с технологическими участками, моделью угроз, критичными бизнес-процессами, защищаемой информацией и требованиями нормативных актов Банка России.

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

Для кого актуальна услуга

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

К таким организациям относятся:

• банки и кредитные организации;
• некредитные финансовые организации;
• страховые компании;
• микрофинансовые организации;
• профессиональные участники рынка ценных бумаг;
• операторы платежной инфраструктуры;
• субъекты национальной платежной системы;
• бюро кредитных историй;
• организации, оказывающие профессиональные услуги на финансовом рынке;
• компании, эксплуатирующие дистанционные каналы обслуживания клиентов;
• организации, использующие личные кабинеты, мобильные приложения, API и интеграционные системы.

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

Какие объекты включаются в границы тестирования

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

На практике в периметр работ могут входить:

• веб-приложения дистанционного банковского обслуживания физических лиц;
• веб-приложения дистанционного банковского обслуживания юридических лиц;
• веб-приложения личных кабинетов клиентов некредитных финансовых организаций;
• мобильные приложения ДБО физических лиц;
• мобильные приложения ДБО юридических лиц;
• мобильные приложения личных кабинетов клиентов финансовых организаций;
• специализированные клиентские приложения ДБО;
• специализированные клиентские приложения личных кабинетов;
• автоматизированные системы, участвующие во взаимодействии с ДБО;
• интеграционные системы;
• API;
• серверы приложений;
• серверы систем управления базами данных;
• телекоммуникационное оборудование;
• средства вычислительной техники;
• компоненты инфраструктуры, относящиеся к критичной архитектуре.

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

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

Цели проведения тестирования

Основными целями тестирования на проникновение и анализа уязвимостей являются:

• оценка уровня защищенности объектов информационной инфраструктуры;
• подтверждение доверия к объектам информационной инфраструктуры;
• выявление уязвимостей и способов их эксплуатации;
• выявление нарушений функций безопасности;
• определение рисков информационной безопасности;
• оценка возможного влияния уязвимостей на защищаемую информацию и операционную надежность;
• подготовка предложений по устранению выявленных уязвимостей;
• формирование решений по минимизации риска.

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

Что входит в тестирование по 2-МР

Внешнее тестирование на проникновение

Внешнее тестирование проводится с позиции внешнего нарушителя, который не имеет доступа во внутреннюю инфраструктуру организации. Цель — оценить возможность первичного проникновения через ресурсы, доступные из сети Интернет.

В рамках внешнего пентеста проверяются:

• публичные IP-адреса и домены;
• веб-приложения и клиентские порталы;
• интерфейсы ДБО;
• API и интеграционные шлюзы;
• VPN и сервисы удаленного доступа;
• почтовые и вспомогательные сервисы;
• административные интерфейсы;
• сетевые службы, доступные из Интернета;
• ошибки конфигурации TLS/SSL;
• возможность эксплуатации известных уязвимостей;
• риски получения несанкционированного доступа к внутренним ресурсам.

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

Внутреннее тестирование на проникновение

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

В рамках внутреннего пентеста проверяются:

• сегментация сети;
• разграничение доступа;
• безопасность Active Directory;
• возможность повышения привилегий;
• доступность критичных систем из внутренних сегментов;
• хранение учетных данных;
• ошибки конфигурации серверов и рабочих станций;
• доступ к базам данных;
• возможность горизонтального перемещения по инфраструктуре;
• возможность достижения критичных систем;
• устойчивость инфраструктуры к действиям внутреннего нарушителя.

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

Анализ уязвимостей

2-МР рассматривает тестирование на проникновение вместе с анализом уязвимостей информационной безопасности. Это означает, что в рамках работ необходимо не только моделировать действия нарушителя, но и выявлять, оценивать и описывать уязвимости объектов информационной инфраструктуры.

Анализ уязвимостей может включать:

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

При проведении анализа уязвимостей учитываются российские и международные источники сведений об угрозах и уязвимостях, включая БДУ ФСТЭК России, CAPEC, MITRE ATT&CK, OWASP, STIX, WASC, CWE, CVE и иные базы знаний.

При выявлении уязвимостей рекомендуется использовать средства анализа защищенности, прошедшие сертификацию не ниже 4 уровня доверия в соответствии с приказом ФСТЭК России № 76. При анализе исходного кода также рекомендуется применять сертифицированные средства анализа исходного кода не ниже 4 уровня доверия.

Оценка критичности уязвимостей может проводиться с учетом методического документа ФСТЭК России по оценке уровня критичности уязвимостей программных и программно-аппаратных средств. При организации дальнейшей работы с выявленными недостатками также может учитываться руководство ФСТЭК России по организации процесса управления уязвимостями.

Методы проведения тестирования

2-МР предусматривает три метода проведения тестирования на проникновение.

Метод черного ящика

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

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

Преимущество метода — реалистичность. Недостаток — часть времени проекта уходит на разведку и сбор информации. структуре организации через опубликованные сервисы.

Метод серого ящика

Метод серого ящика применяется, когда исполнитель владеет частичной информацией об объектах информационной инфраструктуры.

Например, заказчик может предоставить тестовые учетные записи, описание ролей, перечень адресов, архитектурную схему, описание бизнес-процессов или иную ограниченную информацию.

Этот подход часто наиболее эффективен для финансовых организаций, потому что позволяет глубже проверить ДБО, личные кабинеты, API, мобильные приложения и системы с авторизованным доступом.

Метод серого ящика помогает выявить не только технические уязвимости, но и ошибки бизнес-логики, разграничения прав, доступа к объектам данных и выполнения операций в обход установленных ограничений.

Метод белого ящика

Метод белого ящика применяется, когда исполнитель владеет полной информацией об объекте тестирования.

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

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

Такой подход может применяться при проверке критичной архитектуры, новых систем перед вводом в эксплуатацию, значимых изменений инфраструктуры, приложений, API и интеграционных компонентов.

Документы перед началом работ

Перед проведением тестирования на проникновение и анализа уязвимостей организациям финансового рынка рекомендуется разработать или актуализировать комплект организационных и технических документов.

В рамках проекта могут подготавливаться:

• техническое задание на проведение тестирования;
• соглашение об ответственности сторон;
• соглашение о разрешении тестирования адресов и подсетей;
• соглашение о неразглашении конфиденциальной информации;
• модель угроз информационной безопасности объектов информационной инфраструктуры;
• планы восстановления операционной надежности на случай нештатных ситуаций;
• перечень средств защиты информации и регламенты их работы;
• правила выделения учетных записей для специалистов;
• парольные политики;
• инструкции пользователей;
• инструкции администраторов;
• график работы работников организации финансового рынка;
• порядок оперативного взаимодействия сторон.

Наличие таких документов позволяет провести тестирование контролируемо, снизить риск влияния на промышленную эксплуатацию и подтвердить корректность процедуры при внутреннем аудите или проверке.

Техническое задание по 2-МР

Техническое задание является одним из ключевых документов проекта. В нем фиксируются цели, объем, границы, методы, этапы, ожидаемые результаты и требования к отчетности.

В ТЗ рекомендуется отражать:

• наименование планируемых работ;
• количество этапов проведения работ;
• срок проведения работ;
• цели проведения работ;
• перечень нормативных актов Банка России, во исполнение которых проводятся работы;
• перечень объектов информационной инфраструктуры, подлежащих тестированию;
• технологические участки;
• перечень объектов, входящих в границы тестирования, но исключенных из фактической проверки;
• причины исключения отдельных объектов;
• метод проведения тестирования;
• возможные классы атак, поверхности атаки, техники и тактики атак;
• возможные классы уязвимостей;
• методы и инструменты тестирования;
• базы данных угроз и уязвимостей;
• среды проведения тестирования;
• схемы сетевых подключений;
• адреса и подсети, подлежащие проверке;
• факторы риска, реализуемые в рамках тестирования;
• события, при наступлении которых тестирование должно быть незамедлительно прекращено;
• ожидаемые результаты;
• требования к разработке рекомендаций по устранению уязвимостей;
• формы отчетных документов;
• сроки и условия повторного тестирования и анализа уязвимостей.

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

Как проходит проект

1. Определение целей и периметра

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

Результатом этапа является согласованный периметр работ и понимание того, какие объекты необходимо включить в тестирование.

2. Подготовка Т З и организационных документов

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

На этом этапе также определяются ограничения: какие действия допустимы, какие действия запрещены, в какие временные окна можно проводить активные проверки и при каких событиях работы должны быть остановлены.

3. Сбор информации и построение модели атаки

Специалисты анализируют доступную информацию об объектах тестирования, формируют карту поверхности атаки, определяют потенциальные точки входа и сопоставляют сценарии проверки с моделью угроз.

При проведении работ учитывается потенциал нарушителя, указанный в модели угроз информационной безопасности.

4. Выявление уязвимостей

Проводится анализ уязвимостей объектов информационной инфраструктуры. Используются автоматизированные средства и ручные методы проверки.

На этом этапе выявляются:

• известные уязвимости;
• ошибки конфигурации;
• небезопасные сервисы;
• недостатки разграничения доступа;
• ошибки аутентификации и авторизации;
• уязвимости веб-приложений;
• уязвимости API;
• уязвимости мобильных приложений;
• ошибки сетевой архитектуры;
• недостатки защиты серверов и баз данных.

Автоматизированные средства используются как вспомогательный инструмент. Ключевое значение имеет ручная проверка, валидация результатов и оценка реальной возможности эксплуатации.

5. Эксплуатация уязвимостей

Выявленные уязвимости проверяются на возможность эксплуатации в согласованных границах. Цель этапа — подтвердить реальный риск, а не просто зафиксировать потенциальную проблему.

В рамках эксплуатации могут проверяться:

• возможность несанкционированного доступа;
• обход аутентификации;
• повышение привилегий;
• доступ к защищаемой информации;
• выполнение неразрешенных операций;
• доступ к чужим данным;
• перемещение по инфраструктуре;
• достижение критичных систем;
• реализация негативных последствий или недопустимых событий.

Все действия выполняются контролируемо и документируются. При возникновении непредвиденных ситуаций фактические результаты фиксируются, а причины таких ситуаций анализируются.

6. Оценка критичности и последствий

Для каждой уязвимости определяется уров
ень критичности, условия эксплуатации, потенциальные последствия и приоритет устранения.

Особое внимание уделяется не только технической стороне, но и влиянию на бизнес-процессы: возможность незаконной финансовой операции, нарушения конфиденциальности данных клиентов, компрометации учетных записей, нарушения доступности сервиса или воздействия на критичную архитектуру.

7. Подготовка отчета

По итогам работ формируется отчет по результатам тестирования на проникновение и анализа уязвимостей информационной безопасности объектов информационной инфраструктуры.

Отчет может включать:

• описание объекта оценки;
• общее описание проведенных работ;
• технологические участки;
• краткое описание результатов;
• период проведения тестирования;
• реквизиты сторон;
• сведения об исполнителях;
• сведения об учетных записях и их ролях;
• дополнительную информацию, предоставленную для тестирования;
• описание потенциала нарушителя;
• определение негативных последствий и недопустимых событий;
• перечень объектов доступа, в отношении которых возможен несанкционированный доступ;
• виды тестирования с указанием тестируемых объектов;
• описание области исключений или сведения об отсутствии исключений;
• методологию проведения тестирования;
• описание стадий тестирования в соответствии с ГОСТ Р 58 143−2018;
• условия и обобщенные результаты проведения работ;
• перечень выявленных уязвимостей;
• описание уязвимостей в соответствии с ГОСТ Р 56 545−2015;
• использованный инструментарий;
• IP-адреса, DNS-имена и иную информацию для идентификации объектов;
• описание эксплуатации уязвимостей;
• дату и время использования шаблонов атак;
• описание возможных негативных последствий;
• рекомендации по устранению уязвимостей;
• критичность уязвимостей.

Отчет рекомендуется оформлять в электронном виде в формате, не допускающем редактирования, и подписывать усиленной квалифицированной электронной подписью руководителя сторонней организации.

При оформлении отчета на бумажном носителе рекомендуется использовать сквозную нумерацию страниц, прошивку, печать организации и заверительную надпись с указанием количества листов. Отчету рекомендуется присваивать регистрационный номер. Рекомендуемый срок хранения отчета — не менее 5 лет.

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

8. Повторное тестирование

После устранения выявленных уязвимостей рекомендуется проводить повторное тестирование на проникновение и анализ уязвимостей.

Повторная проверка позволяет подтвердить, что уязвимости действительно устранены, а внесенные изменения не создали новых рисков.

Повторное тестирование может не проводиться для тех объектов информационной инфраструктуры, в которых уязвимости не были выявлены.

Инциденты при проведении тестирования

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

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

При информировании Банка России рекомендуется отражать связанность выявленных инцидентов с проведением тестирования на проникновение и анализа уязвимостей.

Самостоятельное проведение работ или привлечение сторонней организации

2-МР допускает самостоятельное проведение тестирования на проникновение и анализа уязвимостей либо привлечение сторонней организации на договорной основе.

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

При этом не рекомендуется возлагать такие функции на работников, которые отвечают за обеспечение информационной безопасности тестируемых объектов, а также привлекать заинтересованных работников: разработчиков, владельцев, администраторов и администраторов информационной безопасности соответствующих объектов.

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

На практике для финансовых организаций часто эффективнее привлекать независимого внешнего исполнителя. Это снижает риск конфликта интересов, повышает объективность оценки и позволяет подтвердить результаты перед руководством, внутренним аудитом и регулятором.

Требования к сторонней организации

При привлечении сторонней организации 2-МР рекомендует учитывать следующие критерии:

• наличие действующей лицензии на деятельность по технической защите конфиденциальной информации для оказания услуг, предусмотренных подпунктом «б» пункта 4 Положения о лицензировании деятельности по технической защите конфиденциальной информации;
• наличие опыта проведения тестирования на проникновение объектов информационной инфраструктуры не менее 3 лет в организациях финансового рынка;
• подтверждение такого опыта не менее чем тремя завершенными договорами, контрактами или соглашениями;
• наличие у привлекаемых специалистов подтвержденного опыта проведения тестирования на проникновение объектов информационной инфраструктуры не менее 3 лет.

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

Также рекомендуется обеспечить нахождение специалистов сторонней организации и автоматизированных средств, используемых для проведения тестирования, на территории Российской Федерации.

Для обеспечения независимости оценки к работам рекомендуется допускать специалистов, которые не принимали участия на стадиях формирования требований к системе защиты, проектирования, внедрения и оценки соответствия системы защиты объектов информационной инфраструктуры, подлежащих тестированию.

Какие работы выполняет Инфо-Трейдинг

Мы проводим тестирование на проникновение и анализ уязвимостей с учетом Методических рекомендаций Банка России № 2-МР и специфики организаций финансового рынка.

В рамках услуги выполняем:

• внешнее тестирование на проникновение;
• внутреннее тестирование на проникновение;
• тестирование веб-приложений ДБО;
• тестирование личных кабинетов клиентов;
• тестирование API и интеграционных систем;
• тестирование мобильных приложений;
• анализ защищенности серверов приложений;
• анализ защищенности серверов баз данных;
• проверку сетевой инфраструктуры;
• проверку удаленного доступа;
• проверку безопасности Active Directory;
• анализ уязвимостей информационной инфраструктуры;
• подготовку технического задания на проведение работ;
• подготовку организационных документов перед началом тестирования;
• подготовку отчета с учетом рекомендуемой формы 2-МР;
• повторное тестирование после устранения уязвимостей.

Работы проводятся в согласованных границах, с учетом критичности объектов, требований к непрерывности финансовых сервисов и необходимости минимизировать влияние на промышленную эксплуатацию.

Что получает заказчик

По результатам работ заказчик получает:

• формализованное техническое задание;
• согласованный периметр тестирования;
• описание методов и условий проведения работ;
• подтверждение проведенных проверок;
• отчет по структуре, учитывающей рекомендации 2-МР;
• перечень выявленных уязвимостей;
• описание сценариев эксплуатации;
• оценку критичности;
• описание возможных негативных последствий;
• рекомендации по устранению;
• приоритизацию мероприятий;
• материалы для внутреннего аудита и подтверждения выполнения требований Банка России;
• возможность проведения повторного тестирования после устранения замечаний.

Главная ценность таких работ — не просто обнаружить уязвимости, а подтвердить управляемость процесса: организация понимает свои риски, фиксирует результаты, устраняет недостатки и может подтвердить выполнение требований по защите информации.

Почему компании обращаются к нам

Учитываем специфику финансового сектора

Финансовая организация не может проводить пентест как обычную техническую проверку. Необходимо учитывать нормативные акты Банка России, технологические участки, защищаемую информацию, критичную архитектуру, ДБО, API, мобильные приложения и возможные негативные последствия для клиентов и бизнес-процессов.

Готовим документы, а не только технический отчет

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

Проверяем реальные сценарии атаки

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

Проверяем реальные сценарии атаки

Даем практические рекомендации

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

Сопровождаем после завершения работ

После выдачи отчета мы можем провести разбор результатов с ИТ- и ИБ-командами, помочь сформировать план устранения уязвимостей и выполнить повторное тестирование.

Получите консультацию специалиста

Оставьте заявку — и мы поможем определить:

• какой вид пентеста подходит под ваши задачи;
• какие системы и инфраструктуру включить в проверку;
• сроки и стоимость тестирования в вашем случае.