Три кита РБПО. Кит №3. Архитектурный анализ

Три кита РБПО. Кит №3. Архитектурный анализ

В этом блоке, завершающем серию «Три кита РБПО», речь пойдёт о методологиях и инструментах анализа, объединённых в категорию «архитектурный анализ», или «комплексный архитектурный анализ» (КАО) в терминах, принятых в Методике выявления уязвимостей и недекларированных возможностей ПО ФСТЭК России [1].

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

Попробуем понять, что именно приходит в голову сотруднику испытательной лаборатории в системе сертификации ФСТЭК России с многолетним стажем, когда он слышит словосочетание «архитектурный анализ». В предыдущих статьях цикла я уже упоминал о неформальной терминологии — РБПО «вширь» и «вглубь» [2]. «Вширь» — подразумевает комплексный анализ наличия в компании процессов РБПО, определяемых ГОСТ 56939-2024 [3] (далее — ГОСТ РБПО), а также минимально необходимого набора артефактов, подтверждающих реализацию процессов с требуемыми характеристиками. «Вглубь» — больше про реализацию конкретных практик РБПО применительно к конкретной кодовой базе конкретных средств защиты информации (или иного программного обеспечения) в соответствии с Методикой выявления уязвимостей и недекларированных возможностей ФСТЭК России (далее — Методика ВУ и НДВ). Перечисленные в Методике ВУ и НДВ требования и рекомендации в первую и основную очередь относятся к разработчикам и испытательным лабораториям, зачастую совместными усилиями готовящим продукты к сертификационным испытаниям и данные испытания проходящим (проводящим). Однако они могут использоваться в качестве коллекции отечественных лучших практик и критериев успешности их выполнения при анализе любых продуктов, не ограничиваясь средствами защиты информации.

Архитектурный анализ и ГОСТ РБПО

Какие процессы, описанные в ГОСТ РБПО, можно отнести к архитектурному анализу? Разумеется, в первую очередь это процессы №6 «Разработка, уточнение и анализ архитектуры ПО» и №7 «Моделирование угроз и разработка описания поверхности атаки». Нет смысла комментировать далее — названия процессов говорят сами за себя, без участия роли «архитектор» (а в ряде крупных компаний с высокой гранулярностью ролей — роли «архитектор ИБ») выполнение данных процессов не представляется возможным. Вопрос отнесения остальных процессов к категории «архитектурный анализ» — дискуссионный. Как это часто случается, не договорившись об аксиоматике и типовых моделях (ролей, процессов) в производственных командах, сложно и, скорее всего, контрпродуктивно утверждать о наличии единого (или, того хуже, единственно верного) подхода к категорированию. Например, относить ли к «архитектурной» категории действия, осуществляемые в рамках процесса №3 «5.3 Формирование и предъявление требований безопасности к ПО»? Разумеется, хорошо проработанный глоссарий типовых требований, включающий в себя требования различных типов (к функционалу, к анализу), вероятно, будет формироваться и поддерживаться с привлечением архитектора команды (компании в целом). Однако, во-первых, в небольших компаниях это может быть реализовано и на уровне роли руководителя проекта либо ведущего разработчика, а во-вторых, роль архитектора не обязательно будет главной (определяющей) при реализации данного процесса. Вполне могут найтись аргументы, обосновывающие тезис: «Требования от бизнеса, реализация от разработчиков, инфраструктура трекера и тестов от девопсов — не стоит пихать везде несчастного архитектора». Или процесс №16 «Использование инструментов композиционного анализа» — процесс, во многом также зависящий от формирования контролируемого репозитория [4] и внедрения инструментов автоматизации данного процесса. Кто-то скажет, что формирование политик наполнения контролируемого репозитория сторонними компонентами невозможно без архитектурного комитета, а кто-то сочтёт, что данный функционал вполне по силам специалисту ИБ или РБПО. Таким образом, с позиции ГОСТ РБПО к процессам архитектурного анализа стоит относить в первую очередь именно те процессы, при реализации которых в выбранной организации специалисты, обладающие ролью «архитектор», принимают непосредственное и даже руководящее участие.

Архитектурный анализ и Методика ВУ и НДВ

Если ГОСТ РБПО говорит об организации процессов в целом, то Методика ВУ и НДВ в первую и основную очередь посвящена тому, что именно и в каком объёме необходимо делать исследователям безопасности — неважно, сотрудник ли это команды разработки продукта или сотрудник испытательной лаборатории, осуществляющей сертификационные испытания. Там, где ГОСТ, на примере горячо любимого мною фаззинга, говорит примерно следующее: «Нужно фаззить то, что нужно, при этом регулярно и желательно с привлечением разных дополнительных инструментов, повышающих эффективность анализа», Методика ВУ и НДВ конкретизирует: «Необходимо взять X сэмплов, Y датчиков срабатывания ошибок и выполнять фаззинг-тестирование без роста покрытия в течение Z часов с использованием инструментов, удовлетворяющих комплекту функциональных требований T». Соответственно, и раздел КАО в Методике ВУ и НДВ — это в первую очередь описание конкретных практик анализа (порой с точностью до описания инструментов), а также описание критериев достаточности их применения в ходе конкретных исследований, с учётом глубины исследований (уровень контроля) и некоторых конкретных особенностей испытываемого продукта.

При этом необходимо подсветить важный «исторический» нюанс. Методика ВУ и НДВ, как и парадигма ФСТЭК-РБПО в целом, уделяет достаточно существенное внимание «тяжёлым» практикам анализа, предполагающим непосредственно работу с исходным или исполняемым (в том числе специально модифицированным) кодом. Данные «тяжёлые» практики описаны в разделах САО (статический анализ исходного кода) и ДАО (в Методике ВУ и НДВ выделяется три вида динамического анализа: модульное, фаззинг- и системное тестирование) — им посвящены прошлые номера рубрики «Три кита» [4, 5]. Наличие акцента на указанных практиках, с одной стороны, позволяет существенно повысить доверие к исследуемому программному обеспечению за счёт необходимости глубокого контроля над создаваемым кодом, что практически невозможно без системно отстроенных процессов анализа и наличия профильных специалистов РБПО. С другой же стороны, «тяжёлые» практики, как правило, весьма ограниченно применяются в легковесном, «коммерческом» РБПО, состоящем из большего числа лучше автоматизируемых практик, к числу которых относятся: композиционный анализ, анализ избыточных привилегий процессов и ресурсов, поиск захардкоженных приватных параметров (пароли, ключи, токены), различные варианты DAST [2] и автоматизированного пентеста и т. д.

В силу принятой парадигмы при создании ФСТЭК России первой версии Методики ВУ и НДВ в 2018 г. разделы САО и ДАО были посвящены вполне конкретным видам анализа — «тяжёлым», требующим наличия исходного кода и контроля над созданием из него кода исполняемого, с проработанными критериями выполнения и высоким профессиональным уровнем специалистов. Но видов анализа, полезных при проведении испытаний, существенно больше, тем более что новые виды/подвиды появляются достаточно динамично. Плодить для каждого собственный раздел — высокоуровневую структуру в составе Методики ВУ и НДВ — решение спорное и вряд ли оптимальное. Именно поэтому множество различных видов и конкретных частных практик анализа кода, конфигурации и архитектуры, весьма разношёрстных и разномасштабных, было решено «свалить» в раздел КАО, где они и пребывают по настоящее время. Исключение составляют методологии определения поверхности атаки и ручного направленного анализа, в силу своей значимости и специфичности также вынесенные в отдельные разделы — ПОД.1 и ЭКО соответственно.

Виды архитектурного анализа при проведении сертификационных испытаний

Разобравшись с историей возникновения категории «архитектурный анализ» (кстати, ей посвящена одна из трёх программ образовательных курсов ФСТЭК России, организуемых на базе ИСП РАН [6]), уделим немного внимания текущему и перспективному [7] наполнению данного раздела Методики ВУ и НДВ в формате тезисов:

• многочисленные виды архитектурного анализа можно делить на подкатегории различными способами, в том числе на статические и динамические;
• исторически к видам архитектурного анализа относятся: проверка наличия и эксплуатируемости известных уязвимостей в сторонних компонентах с открытым исходным кодом (подмножество задач композиционного анализа); поиск захардкоженных приватных параметров, а также поиск компрометирующих конструкций и комментариев в коде ПО; поиск ошибок конфигурирования сервисов в составе ПО; динамический анализ исследуемого ПО в формате «песочницы» — в попытке выявить нештатные/недекларированные взаимодействия и ряд иных практик;
• в раздел КАО включены задачи тестирования на проникновение, выполняемого в ходе сертификационных испытаний;
• в связи с выходом информационного письма ФСТЭК России об уточнении порядка исследований СЗИ в контейнерном исполнении [8] в разрабатываемую сейчас версию Методики ВУ и НДВ будет добавлен раздел, аналогичный требованиям информационного письма;
• важность задачи минимизации привилегий различных видов, в разрабатываемую сейчас версию Методики ВУ и НДВ будет добавлен раздел, посвящённый необходимости выявления повышенных привилегий и их последующей минимизации либо обоснования безальтернативности данного решения;
• вопросы харденинга сборок с использованием возможностей компиляторов (в том числе, например, с использованием безопасного компилятора SafeC [9]), также относятся к ведению раздела «Архитектурный анализ».

Методика ВУ и НДВ не ограничивает исследователя перечисленными методами анализа. Раздел КАО является одним из наиболее «методичных» и наименее «требовательных», подсказывая исследователю возможные векторы и аспекты рассмотрения защищённости анализируемого продукта. Яркий пример — рекомендация по анализу безопасности конфигураций компонентов, относящаяся не только к продукту в целом, но и к конкретным компонентам с открытым исходным кодом, ключевым в составе продукта. Из многолетнего опыта работы известно, что в типовых СЗИ за формирование непосредственной поверхности атаки и реализацию основного функционала почти всегда отвечает подмножество из менее чем 100 компонентов с открытым исходным кодом (существенная часть которых уже исследуется в рамках деятельности Центра исследований безопасности системного ПО [10]). Для многих из этих компонентов — зачастую популярнейших, используемых во множестве продуктов по всему миру — созданы открытые или платные инструменты оценки безопасности их конфигурирования. По уровню своей технологичности они не всегда заслуживают даже отнесения к «линтерам» («Линтер» представляет собой классический пример термина, вроде бы понятного всем. Однако порой попытка чёткой классификации инструментов на «линтеры»/«не линтеры» может привести к небольшой ссоре между вами и вашим визави. Лучший из известных мне подходов к классификации содержится в разделе 3 [11]). Даже их полноценный учёт (а уж тем более какая-то «сертификация» в качестве «типового» инструмента анализа) является задачей нетривиальной и, скорее всего, малополезной практически. Однако рекомендация поиска и применения актуальных «прямо сейчас» средств анализа конфигураций, вне зависимости от их «технологичности» и «регалий», приносит ощутимую практическую пользу. В данном типе инструментов мощность «движка», как правило, не принципиальна — на первый план выходит полнота и актуальность набора экспертных правил, определяющих эксплуатационные «мисконфиги» компонентов.

Ещё один пример — возможность применения инструментов, подобных Luntry [12], для комплексного исследования защищённости контейнерных решений, предназначенных для выполнения под управлением оркестратора k8s. Несмотря на то что основным предназначением инструмента является обеспечение безопасности функционирующих в проде кластеров, он вполне и с успехом может применяться и для выявления различных «избыточностей» в соответствии с информационным письмом [9].

Более подробные описания ряда методологий и инструментов архитектурного анализа представлены уважаемыми участниками в следующих статьях рубрики. Обсуждению вопросов архитектурного анализа посвящён чат @sdl_arch в семействе чатов РБПО-сообщества ФСТЭК России и ИСП РАН [13]. В качестве заключения стоит отметить, что архитектурный анализ при проведении сертификационных испытаний ограничивается именно исследованиями в области безопасности кода, конфигурации и архитектуры ПО. Анализ и критика эффективности выбранного архитектурного подхода (например, монолит или микросервисы), если только он не несёт угроз безопасности, не входит в область задач эксперта испытательной лаборатории.

Источники

[1] Новость об утверждении Методики ВУ и НДВ

[2] Пономарев Д. Многоликий динамический анализ // BIS Journal.  — 2025.  — № 3 (58)

[3] ГОСТ 56939–2024

[4] Проект ГОСТ «Композиционный анализ программного обеспечения» на сайте ФСТЭК, раздел «Термины и определения»

[5] Пономарев Д. Испытания статических анализаторов // BIS Journal.  — 2025.  — № 2 (57) 

[6] Курсы ФСТЭК России на базе ИСП РАН

[7] Запись трансляции «Актуальные вопросы защиты информации» 

[8] Информационное сообщение ФСТЭК России «О повышении безопасности средств защиты информации, в состав которых разработчики включают средства контейнеризации или образы контейнеров»

[9] Безопасный компилятор Си/Си++ 

[10] Центр исследований безопасности системного программного обеспечения 

[11] Статья «Статический анализатор Svace как коллекция анализаторов разных уровней сложности»

[12] Евдокимов Д. Всё для SOC в контейнерных средах и Kubernetes // BIS Journal.  — 2025.  — № 3 (58)

[13] Информационные ресурсы РБПО-сообщества ФСТЭК России и ИСП РАН