8 800 201-20-70
Контакты it_law_security Поиск
RTM Group » Информационная безопасность » Анализ уязвимостей программного обеспечения по ОУД4 и ГОСТ 15408-3
Бесплатный вебинар «Новые требования ФСТЭК: ГИС, КИИ и ПДн» — 10 сентября в 12:00 МСК

Анализ уязвимостей программного обеспечения по ОУД4 и ГОСТ 15408-3

Мы предлагаем:

  • Выбор прикладного ПО, подлежащего проверке
  • Анализ уязвимостей прикладного ПО банка
  • Помощь в разработке документов заявителя

Почему мы:

  • Сертифицированные эксперты с опытом работы в сфере информационной безопасности более 10 лет.
  • Работаем с крупнейшими банками РФ и предприятиями с активами более 1 млрд рублей.
  • Одна из первых профильных компаний на рынке РФ.

Важно:

Анализ необходимо проводить при каждой смене версии ПО. Поможем грамотного организовать данные работы на основе нашего огромного опыта.

Анализ уязвимостей программного обеспечения по ОУД4 и ГОСТ 15408-3 - услуги RTM Group
Анализ уязвимостей программного обеспечения по ОУД4 и ГОСТ 15408-3 - от RTM Group
Узнать стоимость?
Перейти

Эксперты по анализу уязвимостей программного обеспечения по ОУД4 и ГОСТ 15408-3

Эксперт по анализу уязвимостей программного обеспечения по ОУД4 и ГОСТ 15408-3 Музалевский Федор Александрович

Музалевский Федор Александрович

Ведущий эксперт компьютерно-технического направления

Опыт: Экспертная работа с 2010 года. Педагогический стаж с 2012 года. Кандидат физико-математических наук. Доцент кафедры ВМ и ИТ ФГБОУ ВО «ВГУИТ»

Профиль >>

Задать вопрос эксперту: Музалевский Федор Александрович Все эксперты

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

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

Где содержалось требование проводить анализ уязвимостей ПО?

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

Требования проводить анализ уязвимостей ПО содержались в следующих положениях Банка России:

  • Положение Банка России от 30.01.2025 г. N 851-П «Об установлении обязательных для кредитных организаций, иностранных банков, осуществляющих деятельность на территории Российской Федерации через свои филиалы, требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента».

Подробнее Приведение в соответствие и оценка по 851-П для банка

Документами Банка России предусмотрено 2 варианта оценки уязвимостей:

  • Сертификация программного продукта в системе сертификации ФСТЭК России
  • Проведение анализа уязвимостей по требованиям к оценочному уровню доверия 4 (ОУД 4), пункт 7.6 ГОСТ Р ИСО/МЭК 15408-3-2013.

Важно

Анализ необходимо проводить при каждой смене версии ПО.

Нужна консультация?

Какое ПО нужно было оценивать на уязвимости по 851-П?

851-П указывает на необходимость анализа уязвимостей в отношении:

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

851-П

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

В случае с банками к таким системам относятся:

  • АБС
  • Интернет-банк
  • Мобильный банк

и пр.

Что сказано в ГОСТ 15408-3 про анализ уязвимостей ПО?

ГОСТ Р ИСО/МЭК 15408-3-2013. Данный стандарт определяет меры доверия, которые ранее применялись при сертификации средств защиты информации, при этом в настоящий момент он используется как лучшие практики, в том числе и для выявления уязвимостей программных продуктов. В состав мер доверия по ОУД4 входит компонент доверия AVA_VAN.3, именно по данному компоненту и работает эксперт проводящий анализ уязвимостей в соответствии с 851-П.

Оценщик (термин «оценщик» применяется в ГОСТ вместо привычного нам термина «эксперт») проводит тестирование проникновения с целью удостовериться в том, что потенциальные уязвимости не могут быть использованы в среде функционирования объекта оценки. Тестирование проникновения проводится оценщиком, исходя из потенциала нападения — усиленный базовый.

В соответствии 15.2.5 ГОСТ Р 15408-3 работы по компоненту доверия AVA_VAN.3 проходят по следующей схеме:

Элементы действий разработчика AVA_VAN.3.1D Разработчик должен представить объект оценки для тестирования
Элементы содержания и представления свидетельств AVA_VAN.3.1C Объект оценки должен быть пригоден для тестирования.
Элементы действий оценщика AVA_VAN.3.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
AVA_VAN.3.2E Оценщик должен выполнить поиск информации в общедоступных источниках, чтобы идентифицировать потенциальные уязвимости в объекте оценки.
AVA_VAN.3.3E Оценщик должен провести независимый анализ уязвимостей ОО с использованием документации руководств, функциональной спецификации, проекта, описания архитектуры безопасности и представления реализации, чтобы идентифицировать потенциальные уязвимости в объекте оценки.
AVA_VAN.3.4E Оценщик должен провести тестирование проникновения, основанное на идентифицированных уязвимостях, чтобы сделать заключение, что объект оценки является стойким к нападениям, выполняемым нарушителем, обладающим Усиленным базовым потенциалом нападения.

Как сделать анализ уязвимостей программного обеспечения по ОУД4 и ГОСТ 15408-3?

Как сделать анализ уязвимостей программного обеспечения по ОУД4 и ГОСТ 15408-3?

Более подробно работы по анализу уязвимостей регламентированы в ГОСТ Р 58143-2018. Данный стандарт описывает порядок действий оценщика при оценке компонента доверия AVA_VAN.3, а именно:

1) Разработать тесты для проверки наличия потенциальных уязвимостей с учетом соответствующего (AVA_VAN.3.4.E) потенциала нападения

2) Разработать тестовую документацию для тестов на проникновение для обеспечения воспроизводимости

3) Использовать шаги оценивания AVA_VAN.1-5 и AVA_VAN.1-6 в качестве основы для выполнения тестов

4) Зафиксировать результат тестирования

5) Привести в техническом отчете об оценке информацию, об усилиях оценщика по тестированию проникновения

6) Исследовать результаты тестирования и сделать отрицательное заключение по действию оценщика AVA_VAN.1.3.E, если результаты показали, что ПО не является стойким к нарушителю, обладающему базовым потенциалом нападения

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

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

Важно! Приемлемым результатом работы оценщика является как обнаружение (выявление) уязвимостей, так и отсутствие выявленных уязвимостей

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

Отчет по анализу уязвимостей ПО

Результатом работы оценщика, таким образом, является:

  • Документация по тестированию программного обеспечения
  • Технический отчет об оценке (анализе) уязвимостей

Именно заключение, сделанное в данном отчете, дает право считать ПО соответствующим требованию положения 851-П. В дальнейшем отчет используется для устранения уязвимостей, которые были выявлены в ходе аудита. По содержанию, в отчете от RTM Group в обязательном порядке содержится:

  1. Описание, предоставленного на исследование, программного обеспечения
  2. Описание хода исследования (процесса) выявления уязвимостей
  3. Методики и методы выявления уязвимостей
  4. Продукты и решения по анализу кода и анализу уязвимостей ПО, которые использовались при проведении исследования
  5. Список выявленных уязвимостей и дефектов программного продукта
  6. Описание выявленных уязвимостей и оценка их критичности
  7. Действия, которые необходимо предпринять для устранения выявленных уязвимостей
  8. Рекомендации по дальнейшим действиям

Дополнительные услуги по анализу уязвимостей

Внешние организации, являющиеся лицензиатами ФСТЭК России могут проводить следующие работы:

Почему RTM Group?

  • Профиль деятельности RTM Group – проведение экспертиз по направлению ИТ и кибербезопасности
  • Мы специализируемся на технических экспертизах, аудитах информационной безопасности. Являемся постоянными Исполнителями работ по 821-П, 757-П, 851-П для российских банков, некредитных финансовых организаций, а также платежных систем.
  • Поддерживаем самую обширную линейку услуг в тематике тестирования на проникновение и анализа уязвимостей
  • Сроки проведения анализа уязвимостей программного продукта соответствия от 2 недель до 6 месяцев (в зависимости от сложности ПО)
  • Мы обладаем лицензиями:
    • Лицензия ФСТЭК России на деятельность по технической защите конфиденциальной информации
    • Лицензия ФСТЭК России на деятельность по разработке и производству средств защиты конфиденциальной информации
    • Лицензия ФСБ России на работу со средствами криптозащиты

Лицензии RTM Group

Заказать услуги по анализу уязвимостей программного обеспечения по ОУД4 и ГОСТ 15408-3

Для уточнения стоимости и сроков звоните или пишите нам:

Тел: 8 800 201-20-70 (Звонок по России бесплатный)
email:




Оглавление:

1 Где содержится требование проводить оценку (анализ) уязвимостей ПО?2 Какое ПО нужно оценивать на уязвимости по 683-П?3 Что сказано в ГОСТ 15408-3 про анализ уязвимостей ПО?4 Как сделать анализ уязвимостей программного обеспечения по ОУД4 и ГОСТ 15408-3?5 Отчет по анализу уязвимостей ПО6 Дополнительные услуги по анализу уязвимостей7 Почему RTM Group?8 Заказать работы по анализу уязвимостей программного обеспечения


Видео по анализу уязвимостей программного обеспечения по ОУД4 и ГОСТ 15408-3

Почему RTM Group

RTM Group экспертная организация №1 по версии Федерального каталога экспертных организаций

В списке SWIFT Directory of CSP assessment providers

В реестре надежных партнеров торгово-промышленной палаты Российской Федерации

Полноправный член «Ассоциации пользователей стандартов по информационной безопасности» (АБИСС)

Входим в рейтинг «Pravo.ru-300» в отрасли Цифровая экономика

Сайт RTM Group входит в тройку лучших юридических сайтов России

В составе ТК №122

Цены на услуги по анализу уязвимостей программного обеспечения по ОУД4 и ГОСТ 15408-3

Обратите внимание!
Компания работает с юридическими лицами, ИП и бюджетными организациями по безналичному расчету.
Работа с физическими лицами временно не осуществляется.

Наименование услуги Стоимость

Консультация

Бесплатно

Разработка документов заявителя для проведения анализа уязвимостей по ОУД4 в соответствии с ГОСТ 15408-3-2013

Срок — от 10 недель

от 992 000 руб.

Анализ уязвимостей программного обеспечения по ОУД4 в соответствии с ГОСТ 15408-3-2013

Срок — от 8 недель

от 512 000 руб.

Тестирование на проникновение (пентест) и анализ уязвимостей

Срок — от 2 недель

Подробное описание
 

от 150 000 руб.

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

Наши преимущества

3 лицензии

ФСТЭК России и ФСБ России

Каждый 4-й российский банк - наш клиент

Мы работаем с банками по направлениям аудитов ИБ, экспертизам, а также оказываем юридическую поддержку

821-П, 851-П (683-П), 757-П, 802-П, Пентест, ОУД4 и пр.

Специализируемся на всех вариантах аудитов ИБ финансовых организаций по требованиям Центрального банка

2800+ аудитов и экспертиз

Эксперты обладают одновременно опытом ИТ-аудитов и судебных компьютерных экспертиз

Нами проведено более 800 аудитов

Сотрудники компании провели более 700 аудитов по различным критериям

Наши отзывы по анализу уязвимостей программного обеспечения по ОУД4 и ГОСТ 15408-3

Благодарность от АО «НВКбанк»
26.08.2019
Отдел по обеспечению информационной безопасности АО «НВКбанк» выражает благодарность руководству и специалистам ООО «РТМ ТЕХНОЛОГИИ» за эффективно проведенные работы по проведение оценки соответствия по требованиям Положения Банка России от 9 июня 2012 г. № 382-П. По результатам проекта специалистами ООО «РТМ ТЕХНОЛОГИИ» было предоставлено заключение о результатах оценки соответствия и подготовлены рекомендации по устранению всех выявленных несоответствий и совершенствованию применяемых мер по защите информации при осуществлении переводов денежных средств. С завершением работ мы хотим поблагодарить команду ООО «РТМ ТЕХНОЛОГИИ» за профессионализм, надежность и качественное исполнение проекта. Рекомендуем компанию как ответственного и высокопрофессионального исполнителя, а также надеемся в дальнейшем продолжить сотрудничество между нашими организациями в будущих проектах по информационной безопасности. С уважением, Советник Председателя Правления по информационной безопасности Бобров Б.Б.
Благодарность от КБ «ОБР» (ООО)
26.08.2019
По результатам внешней независимой оценки выполнения КБ «ОБР» (ООО) установленных Положением 382-П требований к обеспечению защиты информации при осуществлении переводов денежных средств, специалисты компании ООО «РТМ ТЕХНОЛОГИИ» предоставили заключение о выполнении Банком необходимых требований, подготовили подробный отчет по результатам оценки соответствия платежной системы требованиям 382-П и предоставили рекомендации по совершенствованию системы защиты информации. КБ «ОБР» (ООО) благодарит ООО «РТМ ТЕХНОЛОГИИ» за оказанное содействие в совершенствовании систем защиты информации Банка и оперативность исполнения проекта, а так же рекомендует компанию как надежного партнера, с которым мы хотели бы продолжить сотрудничество и в будущем. С уважением, Начальник отдела СИБ КБ «ОБР» (ООО) Иванов Н.И.
Благодарность от ООО «Цифровой Платеж»
05.10.2020
Для улучшения состояния информационной безопасности корпоративной инфраструктуры и в целях проверки обеспечения соответствия требованиям регулятора, Общество с ограниченной ответственностью «Цифровой Платеж», ИНН 7714909651, (далее - ООО «Цифровой Платеж») обратилось к компании ООО «РТМ ТЕХНОЛОГИИ», владеющей необходимыми компетенциями, для проведения работ по анализу уязвимостей по требованиям к оценочному уровню доверию ОУД4 в соответствии с ГОСТ 15408-3-2013. ООО «Цифровой Платеж» - оператор Платежной системы Sendy. Sendy — национально значимая Платежная система для совершения операций с помощью мобильного устройства, в основе которой лежит технология оплаты через QR-код. Банк России зарегистрировал оператора Платежной системы Sendy 30 сентября 2014 года под номером 0035. В рамках проведенных работ были оказаны услуги:
  • Анализ уязвимостей по ОУД4 в соответствии с ГОСТ 15408-3-2013;
  • Разработка документов заявителя для проведения анализа уязвимостей по ОУД4 в соответствии с ГОСТ 15408-3-2013.
Консультанты ООО «РТМ ТЕХНОЛОГИИ» подготовили подробный отчет о результатах анализа уязвимостей по требованиям к оценочному уровню доверию ОУД4 в соответствии с ГОСТ 15408-3-2013. ООО «Цифровой Платеж» благодарит ООО «РТМ ТЕХНОЛОГИИ» за качественное выполнение работ и рекомендует компанию как надежного и ответственного поставщика услуг в области защиты информации. Генеральный директор О.В. Ярыгина Исполнитель И.М. Чернышов
Благодарность АО ИФК "Солид"
06.09.2021
Акционерное общество Инвестиционно-финансовая компания «Солид» выражает благодарность компании ООО "РТМ ТЕХНОЛОГИИ" (RTM Group) за профессионально выполненные работы по анализу уязвимостей по требованиям к оценочному уровню доверию ОУД4 в соответствии с ГОСТ 15408-3-2013. Благодаря работе команды экспертов ООО «РТМ ТЕХНОЛОГИИ» (RTM Group) мы получили развернутый отчет в запланированные сроки. Отдельно выражаем благодарность за компетентную и оперативную работу Чайковскому Андрею и Музалевскому Федору. Надеемся на дальнейшее плодотворное и взаимовыгодное сотрудничество! Начальник Отдела информационной безопасности Петкевич Е.О.
Благодарность от КБ "ЛОКО-Банк" (АО)
19.05.2022
КБ «ЛОКО-Банк» выражает искреннюю благодарность RTM Group за компетентность и ответственность, проявленных при проведении анализа уязвимостей программного продукта «ДБО» по ОУД4 в соответствии с ГОСТ 15408-3-2013. По окончанию работы специалистов компании RTM Group был предоставлен технический отчет в соответствии с требованиями национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 15408-3-2013, состоящий из 101 страницы и включающий описание, состав исследований, вывод о соответствии. Отдельно хочется отметить работу сотрудников Фёдора Музалевского, Андрея Чайковского и Фёдора Мартынова за проявленный профессионализм, отзывчивость и оперативность. За период нашей работы RTM Group зарекомендовала себя как профессиональная аудиторская компания. Надеемся на долгосрочное сотрудничество в области обеспечения информационной безопасности в будущем и желаем успехов Вашей компании. Директор по информационным технологиям Савоськин А.А.
Благодарность от ООО «Леруа Мерлен Восток»
08.06.2022
ООО «Леруа Мерлен Восток» выражает благодарность специалистам компании ООО «РТМ ТЕХНОЛОГИИ» за профессионально выполненные работы по анализу уязвимостей по требованиям к оценочному уровню доверия ОУД4 в соответствии с ГОСТ 15408-3-2013 для программного комплекса «Платформеко». По итогам работ мы получили развёрнутый отчёт в запланированные сроки. Сотрудничество с вашей компанией произвело самое благоприятное впечатление. Отдельно хотелось отметить работу Мартынова Фёдора, Чайковского Андрея, Курихина Андрея, Музалевского Федора и высокий уровень предоставленных услуг. Рекомендуем компанию ООО «РТМ ТЕХНОЛОГИИ», как ответственного, компетентного и надёжного партнера, отдельно благодарим всех сотрудников за высокий профессионализм, отзывчивость и компетентность. Желаем процветания вашей организации и надеемся на дальнейшее плодотворное сотрудничество. 08.06.2022 Директор ЛМ Тех Юсупов А.И.  

Услуги для вас

Услуга Оценка соответствия по ОУД4 в соответствии с ГОСТ 15408-3-2013

Оценка соответствия по ОУД4 в соответствии с ГОСТ 15408-3-2013

— Кому необходимо проводить оценку соответствия
— Различия между оценкой соответствия и анализом уязвимостей
— Что делать тем, кто уже провёл анализ уязвимостей
— Профиль защиты
— Кто может проводить оценку соответствия
— Стоимость работ по оценке соответствия программного обеспечения
— Заказать работы по оценке соответствия программного обеспечения
Услуга Пентест — услуги тестирования на проникновение и анализа уязвимостей

Пентест — услуги тестирования на проникновение и анализа уязвимостей

- Что следует учесть при выполнении требования Банка России по проведению пентеста на ежегодной основе?
- Пример технического задания на проведение пентеста по 851-П, 821-П, 757-П
- Почему RTM Group?
- Цена проведения пентеста
Услуга Анализ защищенности программного обеспечения

Анализ защищенности программного обеспечения

— Как правильно анализ кода, аудит ПО или тестирование?
— Аудит методом «белого ящика»
— Анализ методом «серого ящика»
— Анализ методом «черного ящика»
— Что входит в аудит?
— Где заказать аудит кода?

Продукты и решения для вас

Anti-DDoS и WAF

Anti-DDoS и WAF

Anti-DDoS — это набор инструментов и технологий, предназначенных для защиты серверов, сетей и веб-приложений от DDoS-атак. Их задача — отличить легитимный трафик от вредоносного, блокируя последний и обеспечивая стабильную работу ресурса. WAF — это программное или аппаратное решение, которое анализирует входящий и исходящий трафик веб-приложения. Его задача — выявлять и блокировать подозрительные запросы, предотвращая попытки атак, таких как SQL-инъекции, XSS (межсайтовый скриптинг), атаки на сеансы и другие.

Security Awareness

Security Awareness

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

ЕСИА

ЕСИА

ЕСИА — решения и услуги для подключения, настройки и интеграции с Единой системой идентификации и аутентификации.

Менеджер паролей

Менеджер паролей

Программное обеспечение класса PMS (Password Management System) или корпоративный менеджер паролей. Программы предназначены для централизованного хранения и организации доступа к паролям для систем и сервисов, используемых компанией или организацией.

Многофакторная аутентификация

Многофакторная аутентификация

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

МФУ и печатная техника

МФУ и печатная техника

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

Офисный пакет

Офисный пакет

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

ПК (АРМ)

ПК (АРМ)

ПК (АРМ) предназначен для оснащения рабочих мест сотрудников. Может быть исполнен в различных форм-факторах: моноблок, Compact, Desktop, Tower.

Сервер

Сервер

Сервер — это устройство, которое хранит данные и даёт доступ к ним большому числу клиентов.

Система инвентаризации

Система инвентаризации

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

Системы защиты информации

Системы защиты информации

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

СХД

СХД

Система хранения данных (СХД) — специализированная инфраструктура для централизованного хранения и управления информацией в компьютерных сетях.

Удаленный доступ и управление конфигурациями устройств

Удаленный доступ и управление конфигурациями устройств

UEM (Unified Endpoint Management) – это системы, которые позволяют компаниям предоставлять для своих сотрудников доступ к работе с любого устройства и удаленно управлять этими устройствами.

DLP

DLP

DLP (Data Loss Prevention) — это система или набор технологий и политик, разработанных для предотвращения утраты, утечки или несанкционированного распространения конфиденциальных данных. Она используется для защиты информации, которая может быть ценной, конфиденциальной или чувствительной для организации.

SIEM

SIEM

SIEM (Security Information and Event Management) — это комплексная система, объединяющая функции сбора, анализа и управления информацией о безопасности в компьютерных сетях и информационных системах.

Межсетевые экраны

Межсетевые экраны

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

Управление уязвимостями

Управление уязвимостями

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

Антивирусы

Антивирусы

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

Цифровая криминалистика

Цифровая криминалистика

Операционные системы

Операционные системы

Операционная система (ОС) — это программное обеспечение, которое управляет и контролирует работу компьютера или другого устройства.

Информационная безопасность

Информационная безопасность

Нам доверяют

Полезные статьи

Статья Что такое пентест (pentest) и кто такой пентестер?

Что такое пентест (pentest) и кто такой пентестер?

- Что входит в тестирование на проникновение?
- Примеры пентестинга
- Что является результатом пентеста?
- Заключение
Статья Изменения в 382-П вступившие в силу с 01.01.2020

Изменения в 382-П вступившие в силу с 01.01.2020

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

Положение банка России № 757-П

Положение 757-П вышло на замену 684-П и устанавливает новые обязательные для Некредитных Финансовых Организаций требования по защите информации.
Статья Обзор Стандарта Банка России от 01.03.2023 № ОД-335 «СТО БР БФБО-1.7-2023»

Обзор Стандарта Банка России от 01.03.2023 № ОД-335 «СТО БР БФБО-1.7-2023»

Стандарт принят и введен в действие приказом Банка России от 01.03.2023 № ОД-335 «СТО БР БФБО-1.7-2023», который устанавливает рекомендации по контролю «цифровых отпечатков устройств».
Статья ГОСТ Р ИСО/МЭК 15408: Эволюция и современное состояние стандарта безопасности ИТ

ГОСТ Р ИСО/МЭК 15408: Эволюция и современное состояние стандарта безопасности ИТ

Применение стандарта ГОСТ Р ИСО/МЭК 15408, известного как «Общие критерии», для оценки безопасности информационных технологий, в разных сферах, таких как государственные сервисы, финансы и медицина.
Статья Обзор Положения Банка России № 851-П и сравнение с № 683-П

Обзор Положения Банка России № 851-П и сравнение с № 683-П

Обзор Положения Банка России № 851-П, которое заменяет действующее Положение № 683-П и вносит ряд значительных изменений в сферу информационной безопасности.
Статья Оценка уязвимостей информационной инфраструктуры (VA)

Оценка уязвимостей информационной инфраструктуры (VA)

Оценка – важный этап процесса управления уязвимостями. Именно по ее результатам принимается решение об их критичности, способах и сроках устранения, либо же о принятии риска эксплуатации уязвимости.

FAQ: Часто задаваемые вопросы

Здравствуйте!
Подскажите, что решено на данный момент с профилем защиты прикладного программного обеспечения автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций?

Здравствуйте!
Проект методического документа «Профиль защиты прикладного программного обеспечения автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций» официально утвержден техническим комитетом № 122 «Стандарты финансовых операций», однако до настоящего момента не опубликован.

Добрый день. Какие документы должны предоставляться оценщику, либо компании, которая будет выполнять работы по анализу уязвимостей ПО, чтобы можно было сделать заключение о соответствии проверяемого ПО не ниже ОУД4?
Спасибо

Добрый день.

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

Задание по безопасности:

  • Функциональные требования безопасности
  • Требования доверия к безопасности

Функциональная спецификация:

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

Проект объекта оценки:

  • Перечень подсистем
  • Перечень модулей
  • Описание модулей

Описание архитектуры безопасности:

  • Перечень функций безопасности (идентификация, аутентификация и пр.)
  • Перечень механизмов собственной защиты от вмешательства.
  • Описание защищённости процесса инициации функций безопасности
  • Описание невозможности обхода функциональных возможностей, осуществляющих выполнение функциональных требований безопасности

Представление реализации:

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

Руководство пользователя по эксплуатации:

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

Руководство по подготовительным процедурам:

  • Шаги для безопасной установки
  • Шаги для безопасной подготовки среды функционирования
  • Шаги для безопасной приёмки поставленного объекта оценки

Инструментальные средства и методы (описание):

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

 

Разумеется, эксперты РТМ готовы помочь в подготовке данной документации.

Здравствуйте! Возможно ли проведение оценки по ОУД4 собственными силами?

В нормативных документах Центрального Банка 382-П, 683-П указано, что для проведения анализа прикладного программного обеспечения по ОУД4 организации должны привлекать лицензиата ФСТЭК, имеющего лицензию на деятельность по технической защите конфиденциальной информации с указанным в ней видом работ и услуг предусмотренных подпунктами «б», «д» или «е» пункта 4 Положения о лицензировании деятельности по технической защите конфиденциальной информации, утвержденного постановлением Правительства Российской Федерации от 3 февраля 2012 года N 79 «О лицензировании деятельности по технической защите конфиденциальной информации», а именно: «контроль защищенности конфиденциальной информации в информационных системах», «работы и услуги по проектированию в защищенном исполнении», а также «услуги по установке, монтажу, наладке, испытаниям, ремонту средств защиты информации» (https://rtmtech.ru/licenses/). То есть банку необходимо привлекать сторонние организации имеющие соответствующие лицензии ФСТЭК.

Однако, для некредитной финансовой организации актуальны требования 684-П, такая Организация принимает решение: самостоятельно ли проводить ей оценку по ОУД4 или с привлечением проверяющей организации.

Здравствуйте!
По какой методике должен проводиться аудит программного обеспечения?

Требования к проведению аудита прикладного программного обеспечения по ОУД4 содержатся в методических документах, выпускаемых ФСТЭК и предусмотренных ГОСТ 57580.2. В данных документах указаны цели и методика.

В ГОСТ 15408 указаны методы и средства обеспечения безопасности, критерии оценки безопасности информационных технологий, необходимый компонент доверия AVA_VAN.3 и метод анализа уязвимостей программного обеспечения, а именно — сосредоточенный анализ уязвимостей.

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

Добрый день!

Какое программное обеспечение должно подвергаться анализу по ОУД4 в банке?

И нужно ли оценивать АБС или ДБО?

Добрый день.

В 683-П и 382-П указано, что Организация обязана использовать программное обеспечение (далее — ПО), предоставляемое клиентам, которое используется для осуществления банковских операций (ДБО) и ПО, используемое для осуществления переводов денежных средств, а также в котором происходит процесс обработки защищаемой информации на участках, используемых для приема электронных сообщений (отдельные компоненты АБС), сертифицированное по ОУД4.

Исходя из вышеуказанных требований можно сделать вывод, что анализу по ОУД.4 должно подвергаться ПО в функции которого входит совершение банковских операций (предоставляемое клиентам), а также ПО используемое для операции по переводу денежных средств и обработки защищаемой информации на участках, используемых для приема электронных сообщений.

Следовательно, ответ на Ваш вопрос – да, системы ДБО и отдельные компоненты АБС, используемые для приема электронных сообщений с использованием сети интернет, должны подвергаться анализу по ОУД4 в банке.

Что включает в себя данный пункт в рамках предлагаемых услуг «Разработка документов заявителя для проведения анализа уязвимостей по ОУД4 в соответствии с ГОСТ 15408-3-2013»?
Требуется ли разрабатывать задание по безопасности в рамках данных работ?

Для проведения работ по ОУД4, требуется предоставление Разработчиком Оценщику ряда документов. Точный перечень не установлен ГОСТ или иным документом, и варьируется в зависимости от объекта оценки (анализируемой системы). Обычно это:
— Задание по безопасности
— Функциональный, модульный проекты
— Представление реализации
— Инструкция по безопасной установке
Документы могут быть заменены аналогами. В любом случае, решающее значение имеет не перечень документов, а их содержание. Содержание документов должно раскрывать требования к безопасности приложения и подтверждение полноты реализации этих требований.

Как связаны между собой эти процедуры: пентест, анализ уязвимостей информационной безопасности объектов КИИ, анализ уязвимостей ПО?

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

Исследование ПО на уязвимости по уровню ОУД4 — это отдельное требование 382-П и 683-П/684-П. Оно включает в себя анализ документации на программное обеспечение с расчетом потенциала злоумышленника, способного взломать приложение, и пентест самого приложения. То есть отличается от пентеста или анализа уязвимостей инфраструктуры составом работ и областью тестирования.

В Положении 719-П.

Какие есть требования и нормативные акты со стороны Банка России?

Основные положения, которые действуют для финансовых организации по анализу уязвимости — это положения 382-П, 683-П и 684-П. По соответствию на ОУД4 — это положение 719-П.

На кого распространяются требования по ОУД4? На какие системы?

По положениям 382-П и 719-П распространяется на всё прикладное ПО банка (ППО АСП).

По положениям 683-П и 684-П — распространяется на системы взаимодействия с клиентами (ДБО).

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

Действующие Положения 382-П и 683-П предусматривают либо сертификацию на НДВ, либо анализ уязвимости. Для анализа уязвимости в рамках 683-П требуется привлекать стороннюю организацию-лицензиата ФСТЭК, который в соответствии с ГОСТ 15408 проведет действия по AVA_VAN.3 и зависимостям и в результате получит отчет по оценке.

Т.е. сам себе банк не может проводить анализ уязвимости.

Здравствуйте, то есть если разработчик ДБО предоставляет сертификат соответствия ФСТЭК на продукт, то никаких анализов больше не требуется?

При наличии сертификата на НДВ или по 131 приказу анализ уязвимостей не требуется. Сертификат ФСТЭК — это альтернатива анализу уязвимости.

Добрый день!

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

Кто должен проходить ОУД4? Чья это зона ответственности?

Банк должен предоставить ЦБ сертификат/отчет о прохождении анализа уязвимости используемого ПО. Кто разрабатывал ПО значение не имеет.

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

Да, может. А разработчик может отказать.

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

В любом случае ответственность на банке.

Вправе. Но банк вправе перейти на другого вендора. Рыночные отношения.

Если банк лицензиат ФСТЭК, может ли банк сам проводить оценку соответствия по ОУД4?

В п. 4.2. Положения 683-П сказано, что для анализа уязвимости в рамках 683-П требуется привлекать стороннюю организацию — лицензиата ФСТЭК. Таким образом сам себе банк не может проводить анализ уязвимости.

Есть ли какое-то послабление для некредитных финансовых организаций в части оценки по ОУД4?

В положении 684-П п. 9 сказано «…По решению некредитной финансовой организации анализ уязвимостей в прикладном программном обеспечении автоматизированных систем и приложений проводится самостоятельно или с привлечением проверяющей организации.»

Таким образом НФО могут самостоятельно проводить анализ уязвимостей по ОУД4.

В каком документе можно прочитать — что такое функционал безопасности?

Функционал безопасности описан в ГОСТ 15408-1-2012

Много ли проверяется функций безопасности обычно?

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

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

Какая средняя продолжительность проведения анализа уязвимости по ОУД4?

Продолжительность проведения анализа уязвимости — занимает в среднем около полугода.

Что делать при обновлении версий?

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

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

Повторное проведение работ в разы быстрее и дешевле. Вплоть до 6 кратного снижения трудозатрат.

Какой самый маленький срок проведения повторного анализа по ОУД4?

Самый маленький срок проведения повторного анализа — в пределах месяца.

Требований по ОУД4 в Положении 672-П нет.
Хотя, если вдаваться в подробности, то АРМ КБР является той же системой ДБО со стороны ЦБ и по хорошему он должен проходить ОУД4 по тому же 684-П.

Гарантировать уровень может только разработчик. Оценщик может его установить и подтвердить.

Добрый день!

Обязательна-ли сертификация АБС банка согласно пункту 4.1 Положения 683-П, т.к. напрямую АБС не использует информационно-телекоммуникационную сеть «Интернет»?
И мы не распространяем никакие составляющие АБС своим клиентам.

Добрый день.
Прямых указаний именно для АБС нет. Существуют архитектуры АБС, принимающие сообщения от клиентов. Поэтому Банк России и рекомендует рассматривать каждый случай отдельно.
По существу вопроса — если АБС не обрабатывает полученные от клиента платежные поручения, то и сертифицировать (проводить анализ уязвимостей) не надо.
Следует отметить, что согласно требованиям 683-П «В отношении прикладного программного обеспечения автоматизированных систем и приложений, не указанных в абзаце первом настоящего подпункта, кредитные организации должны самостоятельно определять необходимость сертификации или анализа уязвимостей и контроля отсутствия недекларированных возможностей.». То есть Банк может самостоятельно принять решение и сертифицировать или провести анализ уязвимостей в отношении АБС, даже если это не обязательно.

Известны меры наказаний от ЦБ за несоответствие ПО ОУД4?

Меры наказаний строго не регламентированы, но известно, что недавно ЦБ оштрафовал 17 банков за несоответствие требованиям ИБ. Какие банки, за что оштрафовали и на какие суммы — неизвестно. Среди наших клиентов таких не было. Здесь ЦБ занимает лояльную позицию и не выписывает штрафы сразу, а дает время на устранение. Отдельно отметим, что провести анализ уязвимостей за 30 дней стоит гораздо дороже, чем провести нормальный аудит за 3-4 месяца. В этом аспекте существенную роль играет не сумма штрафа, а последствия, сопутствующие наказанию. Сумма штрафа может быть и 30 000 рублей, а аудит с 1 500 000 рублей вырастет в цене до 5 000 000 рублей.

Добрый день!
Что будет являться конечным документом по оценке соответствия по ОУД4, для предъявления проверяющим из ЦБ?

Конечным документом будет являться отчет об оценке. Документ так и называется «Отчет об оценке» в соответствии с ГОСТом 15408. Отчет об оценке дается и при оценке соответствия, и при проведении анализа уязвимостей.

По ОУД4 нужно ДБО или еще и АБС?

Если мы говорим про 683-П, то там ДБО предусмотрено однозначно, а АБС предусмотрен в том случае, если он обрабатывает клиентские платежи. По 382-П и по 719-П предусмотрены требования и к АБС, и к ДБО. Исходя из комментариев ЦБ нужно смотреть на архитектуру каждого банка. Таким образом по анализу уязвимостей ОУД4 — ДБО точно, АБС возможно, в зависимости от архитектуры.

п.2.5 719-П «Операторы по переводу денежных средств, не указанные в абзаце первом настоящего пункта, должны обеспечить сертификацию прикладного программного обеспечения автоматизированных систем и приложений не ниже 5 уровня доверия в соответствии с приказом ФСТЭК России N 131.» однозначно оуд не появляется. считается ли, что Банки теперь ОУД не смогут делать, а только сертификацию?

В пункте 2.5 написано, что операторы по переводу денежных средств — только сертификация, но в первом разделе 719-П сказано, что оператор по переводу денежных средств обеспечивает использование ПО, в отношении которого проведена оценка соответствия ОУД4. Таким образом, если рассматривать 2.5 как конкретизацию требований, то ОУД4 банки делать не смогут, только сертификацию. Если речь идет о технической ошибке либо опечатке, то сертификация является альтернативой оценке соответствия по ОУД4 (что вполне логично и ожидаемо). Комментариев Банка России по этому поводу на данный момент нет.

Т.е. это проблема разработчика приложения (ОУД 4), если ОУД 4 нет, не покупаем приложение?

Наличие ОУД4 — это проблема банка, потому что проверять его придет ЦБ. И если нет ОУД4 вы либо приложение не покупаете, либо вы принимаете риск того, что ЦБ накажет за это банк.

Добрый день, а если мобильное приложение собственной разработки?

Какие дополнительные требования нужно выполнять?

На данный момент необходимо проводить анализ уязвимостей по ОУД4.

Банком приобретается новое мобильное приложение, когда надо проводить пентест?

Пентест надо проводить (согласно 382-П, 683-П) ежегодно. Если мы смотрим ГОСТ 57580 там есть отдельные пункты жизненного цикла, и пентест также требуется проводить ежегодно либо при смене инфраструктуры. Но если Вами приобретается новое мобильное приложение, то оно должно пройти (на данный момент) анализ уязвимостей по ОУД4, это не пентест, но другое требование. С точки зрения Банка России, анализ уязвимостей должен быть проведен до того, как Вы запускаете приложение в эксплуатацию.

Для работ по ОУД4 требуется привлечение внешних организаций с лицензией на ТЗКИ?

Да, требуется привлечение внешнего лицензиата.

В чём заключается отличие анализа уязвимостей по ОУД4 от оценки соответствия по ОУД4?

Отличие анализа уязвимостей по ОУД4 от оценки соответствия по ОУД4 заключается в том, что при анализе уязвимостей оценивается лишь часть классов доверия (семейства и компоненты доверия, соответственно, тоже).

На приведённом изображении указаны компоненты доверия, необходимые к оценке по ГОСТ 15408-3-2013. Зелёным цветом выделены работы по анализу уязвимостей по ОУД4 (главным критерием является AVA_VAN.3, а остальные необходимо оценивать в соответствии с зависимостью семейства AVA_VAN), а красным пунктиром выделены работы по оценке соответствия по ОУД4.

Исходя из вышесказанного становится понятно, что работы по анализу уязвимостей по ОУД4 – примерно треть работ по оценке соответствия по ОУД4.

Как проходить ОУД 4, если изменения в исходный код вносятся каждый день? Вы сказали «если затрагивают функции безопасности»? Банк сам определяет, что затрагивает функции безопасности?

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

Для несистемно значимых и незначимых банков нужно проводить ОУД4 тоже или нужно проходить теперь ОУД5?

В пункте требований, о котором вопрос, упомянуты несколько вариантов сертификации: ОУД по соответствующему ГОСТ и оценка уровня доверия по 76 приказу ФСТЭК. ОУД все еще по 4 уровню.

Повторное проведение ОУД-4 необходимо только в случае, если изменения исходного кода затрагивают функции безопасности?

Только при изменении функций безопасности.

В случае, если ЕБС используется для осуществления переводов ДС, оно относится к ОУД-4 или к какому ОУД будет относиться?

«Программное обеспечение, эксплуатируемое на участках, используемых для приема электронных сообщений к исполнению в автоматизированных системах и приложениях с использованием информационно-телекоммуникационной сети «Интернет».» Имеется ввиду, что под формулировку может подпадать любое ПО, а не только комплексные решения по типу АБС. В случае, если ЕБС для осуществления переводов ДС через Интернет, то ОУД4 необходим АБС.

Нужно ли проводить в банке оценку ОУД4 для ПО, в отношении которого разработчик уже провел соответствующую оценку?

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