Журнал "Information Security/ Информационная безопасность" #4, 2026

дований в разделах ПОД, КАО, САО и ДАО). Роль же современной лаборатории можно описать примерно так: помогать разработчику развивать процессы РБПО, сделать самостоятельно ряд проверок, провести кросс-верификацию результатов выполнения РБПО-процессов разработ- чиком. В случае существенных недостат- ков в процессах разработчика и попытке доверить все проверки лаборатории в стилистике испытаний, принятой в 2010-х гг., результат, скорее всего, будет пла- чевным. См. например раздел САО: " Если доля неверно размеченных разработчиком ОО предупреждений превосходит 10%, испытательной лабораторией выполняется статический анализ кода самостоятельно в соответствии с требованиями настоящей Методики либо принимается решение о невозможности проведения дальнейших исследований ОО ". Очевидно, что полный анализ всего кода лабораторией уже на этапе испытаний либо обойдется разра- ботчику очень недешево (как в финансо- вых, так и во временных затратах), либо приведет к прекращению испытаний. При этом важно отметить – Методика не освобождает лабораторию от необхо- димости выполнять и организовывать часть проверок самостоятельно, подтвер- ждая тем самым своему заказчику-раз- работчику, что она не зря ест свой хлеб, и способна не только к оформлению ПиМ и протоколов, но и к инженерно- исследовательской работе (см. например раздел ДАО.2, стр. 30, последний абзац). Борьба с уязвимостями нулевого дня В цикле "Три кита РБПО" я описывал разницу между коммерческим и ФСТЭК- подходом к РБПО [8]. Разумеется, все практики, направленные на относительно быстрый поиск уже известных уязвимо- стей и типовых недостатков безопасности (в том числе уровня конфигураций), в Методике присутствуют и получили раз- витие. Однако, как и ранее, Методика фокусируется на необходимости зани- маться именно исследованиями исходного кода, в том числе кода всех заимствуемых компонентов, составляющих СЗИ 2 . Существенное развитие получила мето- дология определения поверхности атаки, синхронизированная в том числе с терми- нами ГОСТ Р 56939–2024. Фокус методо- логии, как и прежде, на определении поверхности атаки в коде конкретных функций, а не только на уровне интер- фейсов/модулей, как принято в более ком- мерческих подходах. При изучении доку- мента обратите особое внимание на опре- деление интерфейсов "непосредственной" поверхности атаки и усиления 3–5 раздела ПОД.1. Неформально говоря, любые "тор- чащие" (постоянно или периодически) из продукта интерфейсы, и программный код модулей, реализующий обработку посту- пающих по ним данных, – это поверхность атаки. Как правило, у типового СЗИ она состоит из тысяч функций, в том числе расположенных в транзитивных зависи- мостях, а значит, пройти испытания, поме- стив в материалы результат фаззинга 1– 3 несложных фаззинг-целей, вряд ли полу- чится. Очевидными правильными реше- ниями в этих условиях являются: l минимизация кодовой базы в составе СЗИ за счет удаления эксперименталь- ного, устаревшего, и не несущего основ- ную бизнес-ценность функционала; l дедупликация компонентов разных версий 3 ; l активное участие в деятельности Цент- ра исследований безопасности систем- ного ПО ФСТЭК России и ИСП РАН [9], которому посвящена отдельная статья данного спецпроекта. Проблема бинарного результата Итогом сертификационных испытаний является подготавливаемое лаборато- рией техническое заключение. Тради- ционно данный документ имел бинарную форму: либо "все хорошо", либо что-то нехорошо настолько, что результат испы- таний признан неуспешным. В практи- ческой работе данный подход имеет существенный минус, связанный и с человеческим фактором. Лаборатория не имеет возможности воздействовать на улучшение продукта (в том числе в отношении спорных в части безопасно- сти технических решений), кроме как выдачей отрицательного заключения 4 . В новой Методике появился очень интересный п. 5.5, позволяющий лабо- ратории фиксировать в техническом заключении в том числе рекомендации по улучшению продукта. Это нововведе- ние позволит для спорных/пограничных ситуаций, с одной стороны, все таки пройти испытания в срок, с другой – явно зафиксировать особое мнение лабора- тории в официальном документе. Накоп- ление и разбор таких особых мнений ФСТЭК России, ожидаемо, будет влиять на дальнейшее развитие регуляторики и методологии испытаний. Подводя краткий итог Подводя краткий итог и "передавая мик- рофон" коллегам, отмечу, что Методика – это актуальный, технически насыщенный и сложный документ, правоприменительная практика которого сейчас только начинает формироваться. Первые оценки и примеры разбора нетривиальных ситуаций при испы- таниях, скорее всего, будут представлены на традиционных осенних методических сборах ФСТЭК России с отраслью. Ссылки [1] https://fstec.ru/dokumenty/vse-doku- menty/informatsionnye-i-analiticheskie- materialy/informatsionnoe-soobshchenie- fstek-rossii-ot-28-maya-2026-g-n-240-24- 3693 [2] https://fstec.ru/dokumenty/vse-doku- menty/spetsialnye-normativnye-dokumen- ty/metodicheskij-dokument-ot-12-maya- 2026-g [3] https://ib-bank.ru/rpbo_pdf/3 [4] https://fstec.ru/tk-362/standarty/perechen- natsionalnykh-standartov [5] https://cs.groteck.ru/IB_3_2023/40/ [6] https://www.tbforum.ru/2026/program/infor- mation-security [7] https://www.tbforum.ru/2026/program/rbpo [8] https://ib-bank.ru/rpbo_pdf/7 стр. 42 [9] https://portal.linuxtesting.ru/ [10] https://www.isprasopen.ru/ • 65 МЕТОДИКА ВУ И НДВ www.itsec.ru Рис. Результат коллективного творчества РБПО-сообщества – украшает стену во 2-м управлении ФСТЭК России 3 Особенно актуально для СЗИ в контейнерном исполнении, в составе которых зачастую могут быть десятки схожих образов контейнеров, отличающихся минорными версиями компонентов 4 Для этого, как правило, нужно доказать эксплуатируемость (построить PoC эксплуатации) и отбиться от разработчика, который обязательно будет утверждать, что, мол, да, ошибка вроде есть, но в реальных-то условиях от этого защитит WAF/NGFW/волшебный черный ящик, поэтому нестрашно, мы потом поправим, а сертификат очень нужен прямо сейчас... пожалуйста!