INDRA — автономный полигон состязательного анализа киберустойчивости и синтеза инвариантной защиты

INDRA (Invariant-guided Neural Discovery, Reconnaissance & Attack-synthesis) — суверенный программный комплекс состязательного анализа киберустойчивости веб-приложений и программных интерфейсов (API) с замкнутым контуром автоматического синтеза защитных контрактов в концепции «ИБ 3.0».

В отличие от пассивных сканеров уязвимостей и облачных систем автономного пентестинга, оставляющих специалисту лишь текстовый отчёт после возможного повреждения тестовой базы, INDRA объединяет безопасное доказательство уязвимости на минимальном формальном свидетеле (Formal Witness) и мгновенную компиляцию защитного инварианта для перехватчика mcp-sentinel и правил периметра.


1. Назначение и решаемое противоречие (ТРИЗ)

Для кого создана платформа

  • Субъекты критической информационной инфраструктуры (КИИ) и операторы государственных информационных систем — проведение безопасных заводских и приёмочных испытаний защищённости веб-контуров и API в изолированной среде на собственном оборудовании без передачи телеметрии во внешние облака.
  • Службы информационной безопасности банков, финтеха и корпоративных платформ — непрерывная проверка внутренних микросервисов и шлюзов с автоматическим выпуском компенсирующих правил защиты до эксплуатации уязвимости злоумышленником.
  • Команды разработки (DevSecOps) и испытательные лаборатории — детерминированная проверка 7 классов уязвимостей без ложных срабатываний в конвейере непрерывной интеграции и формирование протоколов испытаний по ГОСТ Р 56939-2024.

Архитектурное противоречие и его разрешение

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

В платформе INDRA это противоречие разрешено на уровне архитектуры сетевого транспорта:

  1. Песочница нулевого ущерба (Zero-Damage Sandbox) стоит в пути трафика (in-path). Каждый исходящий зонд до отправки в сокет проходит детерминированный разбор. Запросы, содержащие разрушительные конструкции (DROP, TRUNCATE, DELETE без безопасного условия, rm -rf, mkfs, shutdown, переполнение буфера и рекурсивные бомбы), блокируются аппаратно до сетевого вызова.
  2. Контроль границ полигона (ScopeGuard и ScopedRedirectHandler). Платформа проверяет целевой узел на каждом шаге, включая цепочки HTTP-перенаправлений (301/302/307/308). Попытка перенаправить зонд со стенда на внешний адрес за пределами белого списка немедленно прерывается исключением ScopeViolationError.
  3. Замкнутая иммунная петля (Closed Immune Loop). Подтверждённый безопасный свидетель уязвимости (ExploitWitness) автоматически подаётся в компилятор ImmuneCompiler, который за доли секунды (< 0.05 с) синтезирует проверенный по синтаксическому дереву Python AST защитный контракт для шлюза mcp-sentinel и директиву сетевого экрана.

2. Измеренные показатели стенда (Ворота A–E, замер 24–25.10.2026)

Показатели точности и полноты платформы INDRA не задаются константами в исходном коде — они рассчитываются динамически при прогоне размеченного полигона ground_truth.json (verify_gate_b.py), верифицируются статическим анализатором синтаксического дерева (verify_gate_c.py и verify_gate_d.py) и подтверждены контрольным смотром из чистой установки (Ворота A–E: 12 из 12 критериев по прибору kit-acceptance.py, 25.10.2026).

  • Дата и время контрольного прогона: 2026-10-25T06:23:34.061199+00:00 (источник: stand_metrics.json, indra_audit_passport.json).
  • Объём размеченной выборки (ground_truth.json): N = 28 сценариев (14 уязвимых конечных точек и 14 защищённых контрольных ручек-обманок с идентичной структурой параметров по 7 классам активного автосканера).
  • Матрица классификации (Confusion Matrix): TP = 14, FP = 0, TN = 14, FN = 0.
  • Измеренный уровень ложных срабатываний (FPR): 0.0% (FP / (FP + TN) = 0 / 14).
  • Измеренный уровень пропусков уязвимостей (FNR): 0.0% (FN / (TP + FN) = 0 / 14).
  • Точность (Precision) / Полнота (Recall) / F1-мера: 100.0% / 100.0% / 100.0%.
  • Блокировка разрушительных воздействий (Zero-Damage Sandbox): 7 из 7 (100.0%) в цикле Ворот B и 26 из 26 (100.0%) в полном наборе разрушительных мутаций test_sandbox_integrity.py.
  • Криптографический журнал испытаний (iss-ledger-117): 105 записей в связной хеш-цепочке по ГОСТ Р 34.11-2012 («Стрибог-256»), целостность цепи подтверждена (PASS_VERIFIED).
  • Скорость иммунной компиляции и фильтрации: синтез защитного контракта из свидетеля уязвимости — < 0.05 с (среднее время полного цикла разведки, зондирования и компиляции патча на один сценарий стенда — 103.303 мс, суммарно 2892.48 мс на 28 сценариев); проверка вызова контрактом mcp-sentinel — ~0.016 мс в памяти процесса (1,08 мс медиана и 1,24 мс p95 по предкомпилированной матрице из 8 контрактов на 25.10.2026; 12,72 мс при полном холодном цикле Z3) и ~22.5 мс со сквозной записью в журнал аудита на диск.

2.1. Матрица 7 классов активного безопасного зондирования (AUTO_SCAN_VULN_TYPES)

КодКласс (vuln_type)Наименование и нормативный ориентирВыборка (N)TP / FP / TN / FNFPR / FNRИммунный инвариант
INJ-SQLsql_injectionВнедрение кода в команды СУБД (ГОСТ Р 56939-2024 §6.4.2; Приказ ФСТЭК России № 117 п. 4)42 / 0 / 2 / 00.0% / 0.0%IMMUNE-SQL-85DE2412
INJ-CMDcommand_injectionВнедрение команд ОС (ГОСТ Р 56939-2024 §6.4.3; Приказ ФСТЭК России № 117 п. 4)42 / 0 / 2 / 00.0% / 0.0%IMMUNE-CMD-E22A4527
DIR-TRVpath_traversalНарушение изоляции файловой системы (ГОСТ Р 56939-2024 §6.4.4; Приказ ФСТЭК России № 117 п. 4)42 / 0 / 2 / 00.0% / 0.0%IMMUNE-FS-A17DFC4A
AUTH-BOLAidor_bolaНеправомерный доступ к объектам данных BOLA/IDOR (ГОСТ Р 56939-2024 §6.5.1; Приказ ФСТЭК России № 117 п. 4)42 / 0 / 2 / 00.0% / 0.0%IMMUNE-BOLA-E3FF9C8C
SSRF-INTssrfПодделка запросов на стороне сервера SSRF (ГОСТ Р 56939-2024 §6.4.5; Приказ ФСТЭК России № 117 п. 4)42 / 0 / 2 / 00.0% / 0.0%IMMUNE-SSRF-27590590
SEC-LEAKsecret_exposureУтечка аутентификационных токенов и секретов (ГОСТ Р 56939-2024 §6.3.2; Приказ ФСТЭК России № 117 п. 4)42 / 0 / 2 / 00.0% / 0.0%IMMUNE-SEC-2C95EAB4
HDR-SECmissing_security_headersОтсутствие защитных заголовков безопасности (ГОСТ Р 56939-2024 §6.3.4; Приказ ФСТЭК России № 117 п. 4)42 / 0 / 2 / 00.0% / 0.0%IMMUNE-HDR-82F5EB1F

2.2. Лабораторный контур под подтверждение (LAB_ONLY_VULN_TYPES)

КодКласс (vuln_type)Режим запускаНазначение и нормативный ориентирПравило песочницыИммунный инвариант
DOS-RSRCdos_resourceLAB_ONLY (отключён в активном автосканере)Истощение вычислительных ресурсов (ГОСТ Р 56939-2024 §6.6.1; Приказ ФСТЭК России № 117 п. 4)SEC-ZD-DOS-01IMMUNE-DOS-CF88675B

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


3. Пятиуровневая архитектура контура INDRA

  1. Уровень L1 — Профилирование поверхности (Recon Swarm): синтаксический разбор маршрутов, параметров и заголовков целевого API в пределах разрешённого белого списка ScopeGuard.
  2. Уровень L2 — Выдвижение гипотез (Hypotheses Engine): детерминированное построение гипотез по 7 классам активного безопасного зондирования (AUTO_SCAN_VULN_TYPES) без обращения к внешним облачным моделям.
  3. Уровень L3 — Синтез безопасных проб и перехват (Zero-Damage Sandbox): формирование минимального проверочного запроса и принудительная фильтрация в пути сетевого обмена с записью каждого шага в журнал по ГОСТ Р 34.11-2012.
  4. Уровень L4 — Доказательство уязвимости (Formal Witness): верификация ответа сервиса против контрольного эталона чистой ручки-обманки; фиксация уязвимости происходит только при математическом подтверждении неинвариантного поведения.
  5. Уровень L5 — Автоматическая ремедиация (Closed Immune Loop): генерация готового Python-контракта для перехватчика mcp-sentinel и правила фильтрации для сетевого периметра с автоматической проверкой отсутствия регрессии на легитимных запросах.

4. Установка из чистой среды и воспроизведение проверок

Пакет indra-core написан на стандартной библиотеке Python (версия 3.10 и выше), не требует внешних сетевых зависимостей и устанавливается в полностью изолированном контуре.

Шаг 1. Установка пакета в чистом окружении

python -m venv .venv
.venv/bin/pip install --no-index --find-links ./wheels indra-core

Шаг 2. Независимое воспроизведение приёмочных ворот (без доверия к разработчику)

Посторонний проверяющий воспроизводит матрицу TP/FP/TN/FN, проверку отсутствия зашитых констант и паспорт заводских испытаний четырьмя командами:

# Ворота B: прогон размеченного стенда N=28 (14 уязвимых + 14 чистых сценариев)
python verify_gate_b.py --in-memory

# Ворота C: AST-контроль отсутствия констант точности в коде и сверка генератора паспорта
python verify_gate_c.py

# Ворота D: статическая сверка равенства Заявлено == Проверено по 8 артефактам
python verify_gate_d.py

# Проверка иммунной компиляции (8/8 классов) и песочницы Zero-Damage (26/26 мутаций)
python test_immune_loop.py
python test_sandbox_integrity.py

Шаг 3. Запуск состязательного аудита и выпуск паспорта стенда

# Безопасное зондирование локального стенда с записью в ГОСТ-журнал
indra scan --url http://localhost:8890/api/v1/vuln/sqli/search --param query=laptop --with-sandbox --ledger audit.jsonl

# Выпуск внутреннего паспорта заводских испытаний стенда
indra passport

5. Модель арендатора, архитектурные границы и дорожная карта

Архитектурные и правовые границы

  • Жёсткая изоляция полигона (Ворота 0): платформа работает исключительно по явно заданному белому списку локальных или тестовых узлов арендатора (ScopeGuard). Зондирование внешних доменов третьих лиц блокируется в коде транспорта.
  • Чистая демаркация (Clean-Room): кодовая база indra-core является самостоятельной разработкой АНО «НИИ системного синтеза» под лицензией Apache 2.0, не содержит закрытых SMT-формул шлюза MITR и взаимодействует со средой исполнения по открытым протоколам.
  • Правовой статус паспорта испытаний: формируемый утилитой export_audit_passport.py документ INDRA_AUDIT_PASSPORT.md является внутренним протоколом заводских испытаний стенда разработчика (ориентиры методики: ГОСТ Р 56939-2024 и Приказ ФСТЭК России № 117 от 11.04.2025) и не заменяет государственный сертификат соответствия ФСТЭК России. Вывод о применимости в конкретном контуре КИИ (Федеральный закон № 187-ФЗ от 26.07.2017) принимает служба безопасности организации.
  • Патентование: заявка на изобретение № 2026128816 от 22.09.2026 подана в Федеральную службу по интеллектуальной собственности (Роспатент); дата подачи фиксирует приоритет способа автономного состязательного зондирования и автоматического синтеза правил защиты, однако сама заявка не является охранным документом до вынесения решения экспертизы по существу и выдачи патента.

Статус прохождения ворот приёмки (октябрь — ноябрь 2026 года)

РубежПредмет приёмки и команда проверкиСтатусДата
Ворота 0Аппаратный контроль белого списка целей (ScopeGuard, ScopedRedirectHandler) и фильтр Zero-Damage Sandbox в пути запросаВыполнено02.10.2026
Ворота AБезопасное исполнение и перехват разрушительных мутаций в связной цепи ГОСТ Р 34.11-2012 (python verify_gate_a.py)Выполнено02.10.2026
Ворота BРазмеченный полигон ground_truth.json (N = 28, TP = 14, FP = 0, TN = 14, FN = 0, python verify_gate_b.py --in-memory)Выполнено24.10.2026
Ворота CИсключение констант точности из кода (AST-контроль 31 модуля + проба на мутанте) и автогенерация паспорта (python verify_gate_c.py)Выполнено24.10.2026
Ворота DФормальное равенство Заявлено == Проверено по 7 классам AUTO_SCAN и 1 классу LAB_ONLY (python verify_gate_d.py)Выполнено24.10.2026
Ворота EКонтрольный смотр из чистой установки (kit-acceptance.py, 12 из 12 критериев PASS) и готовность к передаче в пилотные контуры партнёровВыполнено25.10.2026

Частые вопросы (FAQ)

Чем INDRA отличается от традиционных сканеров уязвимостей и облачных ИИ-пентестеров?

Традиционные сканеры опираются на статические сигнатуры и дают высокий процент ложных тревог, а зарубежные облачные ИИ-агенты требуют передачи трафика за пределы РФ и создают риск повреждения базы данных. INDRA работает локально в контуре заказчика, пропускает каждый зонд через блокирующий фильтр Zero-Damage Sandbox, подтверждает уязвимость детерминированным свидетелем (FPR = 0.0% на выборке N = 28) и сразу компилирует защитный контракт mcp-sentinel.

Почему класс истощения ресурсов (DoS) вынесен в отдельный режим LAB_ONLY?

Активная проверка на отказ в обслуживании (dos_resource) по определению создаёт нагрузку на целевой узел. Чтобы исключить деградацию проверяемой системы при штатном автоматическом обходе (AUTO_SCAN_VULN_TYPES), этот класс отключён по умолчанию и запускается только по явному указанию инженера в изолированном лабораторном контуре (LAB_ONLY), где перехватчик Zero-Damage Sandbox проверяет срабатывание правила SEC-ZD-DOS-01.

Как проверить достоверность цифр точности и целостность журнала без доверия к разработчику?

Все показатели на странице выводятся генератором export_audit_passport.py напрямую из файла stand_metrics.json, получаемого при запуске python verify_gate_b.py --in-memory. Скрипт verify_gate_c.py проверяет синтаксическое дерево кода на отсутствие зашитых констант, очищает таблицы в документации и сверяет их побайтовое восстановление, а целостность журнала ГОСТ Р 34.11-2012 проверяется однофайловым верификатором iss_verifier.py на стандартной библиотеке Python.

Как подать заявку на пилотное тестирование INDRA в контуре организации?

Запросы на предоставление дистрибутива indra-core, проведение совместных испытаний на изолированном стенде или включение в программу пилотирования принимаются через страницу контактов института.


Проверено: 25.10.2026 — действие и реквизиты нормативных актов и стандартов, названных на странице (ГОСТ Р 56939-2024, Приказ ФСТЭК России № 117 от 11.04.2025, ГОСТ Р 34.11-2012, Федеральный закон от 26.07.2017 № 187-ФЗ), по первоисточникам.

Связанные разделы: Дорожная карта ИБ 3.0 · Канон ИБ 3.0 · Шлюз допустимости действий MITR · Все разработки института · Связаться с институтом