КАО.1 — Анализ архитектуры ОО статическими методами

Раздел методики: 4.1.2
Применимость для уровня доверия 4 (уровень контроля 4): базовое исследование + усиления 1, 2, 3
Кто проводит: испытательная лаборатория (самостоятельно и/или с использованием результатов разработчика)

Задача исследования

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

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

• руководством по безопасной установке и настройке ОО
• руководствами администратора и пользователя из эксплуатационной документации

Ключевое правило: ОО и его составным частям назначаются только минимально необходимые полномочия. Выявленные избыточные полномочия рассматриваются как недостатки безопасности ОО.

Исходные данные

От разработчика ОО (п. 2.3 Методики):

• а) Документация на ОО: руководство пользователя, руководство администратора, формуляр, руководство по безопасной установке и настройке
• б) Исходный код ОО
• в) Сборочная среда и система сборки ОО, включая их документацию
• г) Дистрибутив ОО
• д) Результаты выполнения процессов разработки ОО по ГОСТ Р 56939-2024: анализ безопасности архитектуры и определение поверхности атаки, композиционный анализ (перечни компонентов, известные уязвимости заимствованных компонентов), анализ безопасности конфигураций, результаты тестирования на проникновение, результаты Bug Bounty (если проводились)
• е) Перечень программных компонентов и образов контейнеров ОО в формате CycloneDX 1.6/1.7 (JSON, RFC 8259)
• з) При внесении изменений в сертифицированный ОО: план поддержки безопасности заимствованных компонентов
• и) Для контейнерного исполнения: перечни разрешённых действий (правила) взаимодействия компонентов ОО между собой, с компонентами среды функционирования и внешними по отношению к ОО компонентами (из эксплуатационной документации)
• к) Методики анализа поверхности атаки open-source компонентов с портала portal.linuxtesting.ru

Из предыдущих этапов:

• Сведения из ПОД.1: методика проведения исследований, описание поверхности атаки, перечень анализируемых модулей с перечнем критичных участков кода
• Испытательный стенд и тестовые сборки ОО по результатам ПОД.2

Требования к проведению исследования

Сбор данных из открытых источников

Испытательная лаборатория самостоятельно собирает и анализирует материалы из открытых источников об ОО и аналогичном по архитектуре ПО:

Источники информации:

• Банк данных угроз безопасности информации ФСТЭК России (bdu.fstec.ru) и иные отечественные базы уязвимостей
• Зарубежные базы данных: CVE/Common Vulnerabilities and Exposures, CWE/Common Weakness Enumeration, CAPEC/Common Attack Pattern Enumeration and Classification
• Публикации и форумы с отзывами пользователей
• Результаты исследований сторонних исследователей (по ОО и аналогичным продуктам)

Оценка результатов разработчика

Оцениваются исходные данные по п. 3.1 и п. 2.3 Методики:

а) Композиционный анализ (перечни компонентов):

• Перечни программных компонентов (SBOM) и результаты поиска известных уязвимостей заимствованных компонентов (включая образы контейнеров) в публично доступных базах уязвимостей.

б) Анализ конфигурации:

• Результаты автоматизированного анализа конфигурации ОО и отдельных модулей на предмет уязвимостей конфигурации; применение инструментальных средств анализа конфигураций.

в) Учёт требований безопасности:

• Результаты учёта в архитектуре ОО требований безопасности, результатов композиционного анализа и анализа конфигураций.

Если результаты разработчика соответствуют требованиям

Испытательная лаборатория проводит выборочную проверку результатов анализаторов разработчика:

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

Если результаты разработчика не соответствуют требованиям

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

Анализ комментариев в исходном коде

В целях выявления НДВ, компрометирующих конструкций и недостатков — выполняется анализ комментариев в исходном коде ОО.

Самостоятельный анализ испытательной лабораторией

Испытательная лаборатория самостоятельно анализирует:

1. Исходный код ОО на предмет открыто присутствующей чувствительной информации и «секретов» (пароли, приватные ключи, другие данные).

2. Веб-интерфейсы из состава поверхности атаки (статическими методами) — на предмет наличия уязвимостей из раздела «Типовые уязвимости веб-приложений» банка данных угроз ФСТЭК России.

3. Конфигурации запуска контейнеров и групп контейнеров (для ОО в контейнерном исполнении) — на соответствие публично доступным рекомендациям по безопасности и минимизации полномочий (рекомендации ФСТЭК России, CIS, Kubernetes Security Best Practices и др.):

4. контейнеры запускаются с минимально необходимыми полномочиями на уровне процессов хостовой ОС
5. для ОО под управлением оркестратора: управление доступом между компонентами ОО соответствует правилам, заданным разработчиком (п. 2.3 Методики)

Избыточные полномочия компонентов и избыточные разрешающие правила доступа расцениваются как недостатки безопасности ОО.

Дополнительные требования (усиления) для уровня контроля 4

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

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

Усиление 2 — Код, выполняющийся в контексте браузера

Проверяется наличие в составе ОО кода (либо генераторов такого кода), выполняющегося в контексте браузера (JavaScript, ActiveX, WebAssembly и др.):

• такой код должен быть учтён в перечне программных компонентов
• в отношении него должен быть выполнен композиционный анализ разработчиком

Критичные выявления:

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

Усиление 3 — Опции компиляции и компоновки

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

Справочник опций: ГОСТ Р 71206-2024 «Разработка безопасного программного обеспечения. Безопасный компилятор языков C/C++», а также методические рекомендации ФСТЭК России по повышению безопасности программных компонентов.

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

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

• Если результаты разработчика соответствуют требованиям п. 3.1 и п. 2.3 Методики — испытательная лаборатория допускается повторно использовать их при оформлении материалов исследований.
• Результаты фиксируются в материалах исследований в объёме, соответствующем п. 5.2 Методики.

Проверка артефактов результата

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

Чек-лист проверки результатов перед отправкой

Формат: каждый пункт проверяется как выполнено / не выполнено / неприменимо.

Блок 1: Анализ полномочий ОО

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

Блок 2: Сбор данных из открытых источников

• Проверены базы ФСТЭК BDU и отечественные базы уязвимостей.
• Проверены CVE, CWE, CAPEC.
• Проверены публикации, форумы, результаты сторонних исследователей по ОО и аналогичным продуктам.
• Результаты сбора задокументированы.

Блок 3: Оценка результатов разработчика

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

Блок 4: Анализ исходного кода

• Выполнен анализ комментариев в исходном коде на предмет НДВ и компрометирующих конструкций.
• Исходный код проверен на наличие чувствительной информации и «секретов» (пароли, ключи, токены).
• Результаты задокументированы.

Блок 5: Веб-интерфейсы

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

Блок 6: Контейнерное исполнение (при применимости)

• Проверены конфигурации запуска контейнеров на соответствие рекомендациям ФСТЭК, CIS, Kubernetes Security Best Practices.
• Подтверждено, что контейнеры запускаются с минимально необходимыми полномочиями.
• Для ОО под управлением оркестратора: правила доступа между компонентами соответствуют заданным разработчиком.
• Избыточные полномочия и разрешающие правила доступа зафиксированы как недостатки безопасности.

Блок 7: Опции компиляции (усиление 3)

• Проверены конфигурации систем сборки на наличие опций безопасной компиляции и компоновки.
• Учтены требования ГОСТ Р 71206-2024 и рекомендации ФСТЭК по безопасному компилятору C/C++.
• Отсутствие необходимых опций зафиксировано как недостаток безопасности.

Блок 8: Браузерный код (усиление 2)

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

Блок 9: Компоненты среды функционирования (усиление 1)

• Выполнен анализ известных уязвимостей компонентов среды функционирования ОО (кроме компонентов системы сборки).
• Результаты зафиксированы в материалах исследований.

Блок 10: Оформление результатов

• Результаты исследований зафиксированы в материалах исследований в соответствии с п. 5.2 Методики.
• Все выявленные недостатки безопасности задокументированы по форме таблицы 6 Методики.

Задачи СИ по данному разделу

Рабочий перечень задач для Redmine: Перечень_задач_СИ_М3.md