Архитектурный анализ. Формирование и предоставление ППК ФСТЭК России

Зачем эта лекция

Современная разработка средств защиты информации в России проходит в условиях, когда «наложенные» средства защиты (NGFW, антивирусы, SOC) необходимы, но недостаточны. Безопасность должна быть встроена в продукт с этапа проектирования.

Стратегия: технологическая независимость + доверенность

Президентом РФ поставлена задача достижения технологической независимости. Импортозамещение — лишь первый шаг. На уровне разработки СЗИ критически важны:

• Суверенизация критических разработок с одновременным усилением позиций в мировом OpenSource.
• Разработка систем в парадигме доверенности как базового принципа.

Системный подход на практике

• Secure by Design — проектирование и разработка приложений в парадигме безопасной разработки.
• Школа продуктовой безопасности — формирование инженерной и образовательной культуры.
• Центры компетенций — объединение усилий по углублённому анализу критических компонентов.

Требования ФСТЭК России

Архитектурный анализ — не «ритуал лаборатории», а обязанность разработчика. Это закреплено в трёх ключевых документах ФСТЭК.

Карта актуальной нормативной базы

10 ключевых документов, формирующих регулирование РБПО и сертификации СЗИ. Часть документов уже действует, часть в поздних стадиях разработки — но рекомендуется ознакомиться с обоими типами для понимания вектора развития требований.

Что такое архитектурный анализ

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

Где он находится в общей картине РБПО

Если разделить все практики поиска уязвимостей и НДВ на крупные классы, картина получается такая:

Поверхность атаки и приоритизация

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

85% уязвимостей — в транзитивных зависимостях

По данным CodeScoring, 85% уязвимостей находятся в транзитивных зависимостях (библиотеках, которые импортируют ваши прямые зависимости). При определении поверхности атаки критически важно отслеживать, куда именно попадает поток данных — в какие сторонние приложения и библиотеки, а не только в очевидный исполняемый файл.

Стратегия: с каких компонентов начинать

Анализ начинаем с компонентов, наиболее подверженных угрозам и доступных наиболее слабым нарушителям:

• Вспомогательные сервисы, не реализующие функции безопасности и бизнес-логику. Например: мессенджер или SIP-сервер, «для удобства» встроенный в межсетевой экран типа «А».
• Web-сервисы — каждый второй мнит себя пентестером, нарушителей много.
• Парсеры пользовательского ввода — обработчики файлов, изображений, документов. Любой код, разбирающий внешние данные.

Тактика: приоритет по языкам программирования

• C/C++ — высокий приоритет анализа (нет управляемой памяти, классические уязвимости переполнений).
• C#, Java, Python — обычно безопаснее (управляемая память), но в управляемом коде бывают вставки на нативных языках (unsafe C#, JNI в Java и т. д.).
• Движки интерпретаторов и SDK — как правило написаны в том числе на нативных языках программирования.

Советы бывалого

• Смотрите документацию — скриншоты тестирования и рекламные материалы на сайте разработчика. Там всплывает функционал, который прячут в сертификационной документации.
• Различные подменю загрузки картинок для аватарки, функции загрузки превью документов и иные «незначительные» возможности часто скрывают за собой огромные библиотеки-парсеры.
• Парсеры исходных текстов / байткода в составе интерпретатора, как правило, не являются поверхностью атаки на СЗИ — в типовых сценариях запуск доступен только администратору, а не произвольному пользователю.

Статический архитектурный анализ — 6 техник

Шесть направлений анализа, не связанных с выполнением кода. Каждое направление — отдельная техника со своими инструментами.

Динамический архитектурный анализ — 3 техники

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

Контейнеры и Kubernetes

Реализация СЗИ в контейнерном исполнении не освобождает разработчика от обязанностей по анализу компонентов. Контейнер — не «вещь в себе».

Что нельзя делать

• Скачивать пресобранные образы с недоверенных репозиториев.
• Собирать наполнение образов самостоятельно (за исключением переиспользования компонентной базы из состава сертифицированных сред исполнения).
• Не выполнять статический и динамический анализ составляющих ПА или реализующих ФБ компонентов, запущенных в контейнерах.

Оркестраторы (Kubernetes)

В оркестраторах добавляются свои парадигмы управления доступом субъектов к объектам — микросервисы, поды, ServiceAccount, RBAC, NetworkPolicy. На архитектуру и её безопасность необходимо смотреть дополнительно в парадигме выбранного оркестратора.

Автоматизация архитектурного анализа

Больше автоматизации — меньше «сертификации». Регулярность анализа заложена в Требованиях. Автоматизация позволяет встроить проверки в процесс разработки и не возвращаться к ним вручную.

Декларативный подход

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

Найди архитектурную ошибку: 6 кейсов

Шесть архитектурных решений, типичных для разработки СЗИ. В каждом — два варианта: один с дефектом, другой соответствующий требованиям РБПО. Прочитайте сценарий, выберите вариант, который кажется правильным, затем раскройте подсказку.

# config.py
DB_PASSWORD = "S3cur3P@ss2024!"  # удобно для разработки
DB_HOST = "db.internal.local"

# config.py
from vault_client import get_secret

DB_PASSWORD = get_secret("db/credentials/password")
DB_HOST = get_secret("db/connection/host")

# Установить SUID-бит — любой пользователь
# запустит утилиту с правами root
$ chmod u+s /usr/local/bin/szi-tool
$ ls -l /usr/local/bin/szi-tool
-rwsr-xr-x 1 root root 12345 ... szi-tool

# Минимально необходимые capabilities
$ setcap 'cap_net_bind_service,cap_dac_read_search=+ep' \
    /usr/local/bin/szi-tool

$ getcap /usr/local/bin/szi-tool
/usr/local/bin/szi-tool = cap_net_bind_service,cap_dac_read_search+ep

# build.yml
- run: npm install fs-extra@latest

# package.json
{
  "dependencies": {
    "fs-extra": "latest"
  }
}

# .npmrc — внутренний реестр
registry=https://registry.internal.local/npm

# package.json — фиксированная версия
{
  "dependencies": { "fs-extra": "11.2.0" }
}

# build.yml — формирование ППК
- run: cyclonedx-bom > ppk.cdx.json
- run: verify-ppk ppk.cdx.json

FROM ubuntu:latest

RUN apt-get update && apt-get install -y \
    python3 nginx postgresql redis \
    curl wget jq vim less ...

COPY . /app
CMD ["python3", "/app/main.py"]

FROM registry.internal.local/ubuntu:22.04@sha256:abc123...

COPY ppk.cdx.json /opt/szi/
RUN apt-install --from-ppk /opt/szi/ppk.cdx.json \
    --no-install-recommends

USER 10001
COPY --chown=10001:10001 . /app
CMD ["python3", "/app/main.py"]

# текстовая строка в логе
logger.info(
    f"User {user.name} logged in"
    f" from {request.ip} at {ts}"
)

# событие безопасности по 59548-2022
log_security_event(
    event_id="AUT.LOGIN.SUCCESS",
    subject_id=user.id,
    subject_type="user",
    timestamp=ts,
    source_ip=request.ip,
    severity="info",
    extra={...}
)

Композиционный анализ ПО (КАПО)

КАПО — отдельный процесс №16 в ГОСТ Р 56939-2024 («Использование инструментов композиционного анализа»). Концепция ППК как машиночитаемого перечня программных компонентов прорабатывалась в рабочей группе при ФСТЭК России с 2022 года.

Цели композиционного анализа

• Инвентаризация всех видов сторонних компонентов в продукте.
• Обогащение данных компонентов информацией из баз известных уязвимостей (CVE, БДУ ФСТЭК).
• Проверка лицензионной чистоты, репутации компонентов и иных особенностей.
• Регулярный процесс в организации — не разовая активность перед сертификацией.

ППК и SBOM

ППК — Перечень программных компонентов. По смыслу это российский эквивалент SBOM (Software Bill of Materials). Формат — CycloneDX, содержит обязательные поля для каждого компонента.

Что обязано быть в ППК

• Имя и версия компонента — точная фиксация, без диапазонов.
• Тип компонента — библиотека, контейнерный образ, исполняемый файл, fragment кода.
• Source repository / origin — откуда взят компонент.
• Хэш — для верификации целостности.
• Лицензия — для проверки совместимости и лицензионной чистоты.
• Связи между компонентами — кто зависит от кого (transitive deps).

Формат CycloneDX

CycloneDX — открытый стандарт SBOM, который российская рабочая группа выбрала за основу. Текущая версия — 1.7 (релиз марта 2026), также продолжает применяться 1.6. Расширения для ФСТЭК добавляют специфичные поля (классификатор по БДУ, уровень доверия и т. п.).

Формирование ППК

Звучит просто — «соберите список компонентов в формате CycloneDX». На практике большинство команд натыкаются на одни и те же грабли.

Типовые сценарии формирования

Инструменты формирования ППК

Предоставление ППК в ФСТЭК России

Сформированный ППК подаётся в составе сертификационных материалов. Существует выделенная инфраструктура для приёма и проверки ППК — на платформе ИСП РАН.

Инфраструктура

• Платформа SBOM-инструментов: gitlab.community.ispras.ru — gitlab-инстанс ИСП РАН, где разрабатывается tooling для работы с ППК.
• SBoM-updater / sbom-checker: инструменты для верификации формата и содержания ППК до отправки.
• Центр исследования безопасности системного ПО — подразделение ФСТЭК России. Контакт публиковался в выступлении Д. Н. Шевцова на Kaspersky CyberDay 2024.

Дискуссия и обсуждения

Активная дискуссия по инструментам и практикам генерации ППК / SBOM ведётся в открытом сообществе — в Telegram-чате t.me/sdl_fld (ветка /6495), в gitlab-issues ИСП РАН, на встречах сообщества, посвящённых особенностям внедрения.

Проблематика КАПО — три угла зрения

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

Связь с другими стандартами

ГОСТ Р 56939-2024 — не одиночный документ, а центр созвездия. Эта лекция охватывает 4 процесса (№6, №7, №16, №17), и они опираются на серию связанных стандартов и методик.