INDRA (Invariant-guided Neural Discovery, Reconnaissance & Attack-synthesis) — суверенный программный комплекс состязательного анализа киберустойчивости веб-приложений и программных интерфейсов (API) с замкнутым контуром автоматического синтеза защитных контрактов в концепции «ИБ 3.0».
В отличие от пассивных сканеров уязвимостей и облачных систем автономного пентестинга, оставляющих специалисту лишь текстовый отчёт после возможного повреждения тестовой базы, INDRA объединяет безопасное доказательство уязвимости на минимальном формальном свидетеле (Formal Witness) и мгновенную компиляцию защитного инварианта для перехватчика mcp-sentinel и правил периметра.
1. Назначение и решаемое противоречие (ТРИЗ)
Для кого создана платформа
- Субъекты критической информационной инфраструктуры (КИИ) и операторы государственных информационных систем — проведение безопасных заводских и приёмочных испытаний защищённости веб-контуров и API в изолированной среде на собственном оборудовании без передачи телеметрии во внешние облака.
- Службы информационной безопасности банков, финтеха и корпоративных платформ — непрерывная проверка внутренних микросервисов и шлюзов с автоматическим выпуском компенсирующих правил защиты до эксплуатации уязвимости злоумышленником.
- Команды разработки (DevSecOps) и испытательные лаборатории — детерминированная проверка 7 классов уязвимостей без ложных срабатываний в конвейере непрерывной интеграции и формирование протоколов испытаний по ГОСТ Р 56939-2024.
Архитектурное противоречие и его разрешение
Классический состязательный анализ требует полной свободы фаззинга и генерации атакующих запросов для выявления нетривиальных брешей, однако неконтролируемые мутации запросов на рабочем контуре приводят к удалению таблиц, порче данных или отказу в обслуживании.
В платформе INDRA это противоречие разрешено на уровне архитектуры сетевого транспорта:
- Песочница нулевого ущерба (
Zero-Damage Sandbox) стоит в пути трафика (in-path). Каждый исходящий зонд до отправки в сокет проходит детерминированный разбор. Запросы, содержащие разрушительные конструкции (DROP,TRUNCATE,DELETEбез безопасного условия,rm -rf,mkfs,shutdown, переполнение буфера и рекурсивные бомбы), блокируются аппаратно до сетевого вызова. - Контроль границ полигона (
ScopeGuardиScopedRedirectHandler). Платформа проверяет целевой узел на каждом шаге, включая цепочки HTTP-перенаправлений (301/302/307/308). Попытка перенаправить зонд со стенда на внешний адрес за пределами белого списка немедленно прерывается исключениемScopeViolationError. - Замкнутая иммунная петля (
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 / FN | FPR / FNR | Иммунный инвариант |
|---|---|---|---|---|---|---|
INJ-SQL | sql_injection | Внедрение кода в команды СУБД (ГОСТ Р 56939-2024 §6.4.2; Приказ ФСТЭК России № 117 п. 4) | 4 | 2 / 0 / 2 / 0 | 0.0% / 0.0% | IMMUNE-SQL-85DE2412 |
INJ-CMD | command_injection | Внедрение команд ОС (ГОСТ Р 56939-2024 §6.4.3; Приказ ФСТЭК России № 117 п. 4) | 4 | 2 / 0 / 2 / 0 | 0.0% / 0.0% | IMMUNE-CMD-E22A4527 |
DIR-TRV | path_traversal | Нарушение изоляции файловой системы (ГОСТ Р 56939-2024 §6.4.4; Приказ ФСТЭК России № 117 п. 4) | 4 | 2 / 0 / 2 / 0 | 0.0% / 0.0% | IMMUNE-FS-A17DFC4A |
AUTH-BOLA | idor_bola | Неправомерный доступ к объектам данных BOLA/IDOR (ГОСТ Р 56939-2024 §6.5.1; Приказ ФСТЭК России № 117 п. 4) | 4 | 2 / 0 / 2 / 0 | 0.0% / 0.0% | IMMUNE-BOLA-E3FF9C8C |
SSRF-INT | ssrf | Подделка запросов на стороне сервера SSRF (ГОСТ Р 56939-2024 §6.4.5; Приказ ФСТЭК России № 117 п. 4) | 4 | 2 / 0 / 2 / 0 | 0.0% / 0.0% | IMMUNE-SSRF-27590590 |
SEC-LEAK | secret_exposure | Утечка аутентификационных токенов и секретов (ГОСТ Р 56939-2024 §6.3.2; Приказ ФСТЭК России № 117 п. 4) | 4 | 2 / 0 / 2 / 0 | 0.0% / 0.0% | IMMUNE-SEC-2C95EAB4 |
HDR-SEC | missing_security_headers | Отсутствие защитных заголовков безопасности (ГОСТ Р 56939-2024 §6.3.4; Приказ ФСТЭК России № 117 п. 4) | 4 | 2 / 0 / 2 / 0 | 0.0% / 0.0% | IMMUNE-HDR-82F5EB1F |
2.2. Лабораторный контур под подтверждение (LAB_ONLY_VULN_TYPES)
| Код | Класс (vuln_type) | Режим запуска | Назначение и нормативный ориентир | Правило песочницы | Иммунный инвариант |
|---|---|---|---|---|---|
DOS-RSRC | dos_resource | LAB_ONLY (отключён в активном автосканере) | Истощение вычислительных ресурсов (ГОСТ Р 56939-2024 §6.6.1; Приказ ФСТЭК России № 117 п. 4) | SEC-ZD-DOS-01 | IMMUNE-DOS-CF88675B |
Выделение класса dos_resource в отдельный режим LAB_ONLY исключает генерацию нагрузочных проб при штатном обходе сервиса и гарантирует сохранность проверяемого контура.
3. Пятиуровневая архитектура контура INDRA
- Уровень L1 — Профилирование поверхности (
Recon Swarm): синтаксический разбор маршрутов, параметров и заголовков целевого API в пределах разрешённого белого спискаScopeGuard. - Уровень L2 — Выдвижение гипотез (
Hypotheses Engine): детерминированное построение гипотез по 7 классам активного безопасного зондирования (AUTO_SCAN_VULN_TYPES) без обращения к внешним облачным моделям. - Уровень L3 — Синтез безопасных проб и перехват (
Zero-Damage Sandbox): формирование минимального проверочного запроса и принудительная фильтрация в пути сетевого обмена с записью каждого шага в журнал по ГОСТ Р 34.11-2012. - Уровень L4 — Доказательство уязвимости (
Formal Witness): верификация ответа сервиса против контрольного эталона чистой ручки-обманки; фиксация уязвимости происходит только при математическом подтверждении неинвариантного поведения. - Уровень 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 · Все разработки института · Связаться с институтом