Автоматизовані звіти кіберрозвідки для військового командування

Проблема розвідки, з якою стикається військове командування у кіберпросторі, полягає не у нестачі даних. Це проблема формату. Стрічки загроз надають сирі індикатори — IP-адреси, хеші файлів, доменні імена — оптимізовані для завантаження засобами виявлення, а не для прийняття рішень командирами. Коли офіцер J6 повинен проінформувати командира про поточну картину кіберзагроз, сирий дамп IOC із SIEM — це не той продукт, що передається по ланцюжку. Хтось має його перекласти. Ця перекладацька робота — перетворення машиночитаних індикаторів на структуровану, атрибутовану, готову до командирського рівня розвідку — наразі виконується вручну аналітиками, яких менше, ніж даних, які вони обробляють.

Автоматизована генерація звітів кіберрозвідки за допомогою LLM і структурованих CTI-даних змінює економіку цього перетворення. У цій статті розглядається, як виглядають автоматизовані CTI-звіти, готові для командирського рівня, які структуровані вхідні дані потрібні для їх надійної генерації, як побудувати конвеєр LLM із засобами контролю галюцинацій, яких вимагає військовий контекст, і як поширювати вихідні дані через канали, якими фактично користується ланцюжок командування.

Прогалина: сирі стрічки IOC versus розвідка, готова для командування

Сирі стрічки IOC виконують специфічну й цінну функцію: вони наповнюють списки блокування, керують правилами кореляції SIEM і живлять системи виявлення на кінцевих точках. Для цієї мети формат правильний — машиночитаний, великий обсяг, структурований для автоматизованого завантаження. Проблема виникає, коли та сама стрічка має обслуговувати розвідувальні потреби командного рівня. Командир не може діяти на основі списку з 2 000 IP-адрес. Їм потрібно знати, яке угруповання противника, швидше за все, стоїть за активністю, яка його мета, які системи чи мережі перебувають під загрозою, який рівень достовірності атрибуції і який курс дій рекомендується.

Перетворення індикатора на оцінку вимагає кількох етапів збагачення, яких сирі стрічки IOC не виконують: атрибуція суб'єктів загрози за допомогою кластеризації інфраструктури кампаній, зіставлення на рівні технік із ATT&CK для характеристики поведінки противника, історичний контекст із відомих зразків цільових атак противника та оцінка впливу, пов'язана з конкретними критичними системами командування. Нічого з цього немає у стрічці. Все це вимагає часу аналітика для ручного виробництва.

Проблема своєчасності ускладнює проблему формату. Загроза, ідентифікована й класифікована через дванадцять годин після першої появи відповідних індикаторів, може більше не бути придатною до дії. Виконавчий брифінг, доставлений командиру о 08:00 та охоплює активність загроз за попередні 24 години, є корисним. Брифінг, доставлений о 16:00 за той самий період, — ні. Автоматизована генерація звітів вирішує обидві проблеми одночасно: вона виробляє командно-готові вихідні дані у послідовному форматі, і робить це достатньо швидко, щоб своєчасність більше не визначалась доступністю аналітика.

Типи звітів для ланцюжка командування

Не кожен тип звіту обслуговує кожну аудиторію. Проектування таксономії звітів до реалізації конвеєра є обов'язковим — LLM генерує текст у межах шаблону, і шаблон має відповідати своїй аудиторії. Чотири типи звітів охоплюють практичні потреби більшості військових командних структур.

Виконавчий брифінг із загрозами

Виконавчий брифінг із загрозами — це максимально дворівневе резюме, призначене для командира і старшого персоналу. Він містить поточну позицію загроз (підвищена, номінальна, знижена), називає угруповання противника з активними кампаніями, що стосуються зони відповідальності командування, характеризує ймовірну мету кожного угруповання одним-двома реченнями і перелічує три найкращих рекомендованих дії командного рівня. Рівні достовірності виражаються простою мовою — "оцінено з високою достовірністю на основі трьох підтверджуючих вихідних звітів" — а не у вигляді десяткових ймовірностей. TLP-класифікація відображається у заголовку. Кожне фактичне твердження є прослідковуваним до вихідного запису в базі знань CTI, але цитати вихідних записів містяться у додатку, а не в тексті, щоб зберегти читабельність на виконавчому рівні.

Технічний звіт про індикатори

Технічний звіт про індикатори обслуговує SOC і персонал J6, яким потрібно діяти на основі конкретних індикаторів, що лежать в основі виконавчого брифінгу. Він містить повну таблицю IOC (із полями контексту: пов'язане сімейство шкідливого ПЗ, ідентифікатор техніки ATT&CK, показник достовірності, часові мітки першого і останнього спостереження, TLP-класифікація на кожен індикатор), керівництво з виявлення, зіставлене зі стеком датчиків командування, та експорт пакету STIX 2.1. Цей тип звіту вимагає мінімальної участі LLM у тексті — основна частина — це структуровані дані, відтворені з бази знань CTI. LLM бере участь у вступному резюме, тексті на рівні технік для кожного кластера технік ATT&CK, присутнього у наборі індикаторів, і тексті керівництва з виявлення.

Оновлення профілю противника

Профіль противника — це постійний документ, що оновлюється, коли нова активність кампанії надає додаткові знання про відстежувану групу суб'єктів загрози. Він описує відому організаційну структуру групи, основні сектори та географії цільових атак, арсенал шкідливого ПЗ, переважні TTP, зіставлені з ATT&CK, та хронологію минулих операцій. LLM генерує дельту — що змінилося порівняно з попередньою версією профілю — шляхом порівняння набору вихідних записів попереднього профілю з поточним і генерації тексту для нових доповнень. Контроль версій документа профілю є обов'язковим; кожне оновлення несе номер версії профілю та журнал змін, що підсумовує додане або переглянуте.

Хронологія інциденту

Коли кібер-інцидент, що впливає на мережі командування, підтверджено або підозрюється, звіт про хронологію інциденту відновлює хронологічну послідовність подій із доступної телеметрії датчиків, збігів загроз із розвідкою та підтвердження OSINT. LLM синтезує текстову хронологію із записів подій, упорядкованих за часовою міткою, ідентифікує ймовірні послідовності технік ATT&CK (вказуючи, якої фази ланцюжка атаки досяг противник) та створює структуровану таблицю подій для перегляду персоналом командування. Хронологія є продуктом, найбільш безпосередньо корисним для дебрифінгу командування після інциденту та для інформування захисних заходів.

Конвеєр LLM для генерації звітів

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

Етап 1 — Структурований CTI-завантаж. Усі вихідні дані надходять до конвеєру в одному з двох форматів: пакети STIX 2.1 із підписок на стрічки та експорти подій MISP, або збагачені записи подій, вироблені конвеєром класифікації вище за потоком. Сирі записи IOC без зіставлень технік ATT&CK, показників достовірності та TLP-класифікацій затримуються під час завантаження і направляються до конвеєра збагачення перед генерацією звітів. Генератор звітів вимагає структурованих вхідних даних — спроби генерувати командно-готовий текст із незбагачених списків IOC дають вихідні дані низької якості, що не проходять перевірку галюцинацій і вимагають великої аналітичної корекції.

Етап 2 — Вибір шаблону та збірка вхідних даних. На основі запиту на звіт (ініційованого за розкладом, подією за порогом або запитом аналітика) конвеєр обирає відповідний шаблон звіту і збирає вхідний набір записів. Для виконавчого брифінгу це означає отримання всіх активних записів кампаній за поточний звітний період, згрупованих за суб'єктом загрози, ранжованих за серйозністю. Для оновлення профілю противника — отримання набору дельта-записів, тобто вихідних записів, доданих після останньої версії профілю. Збірка вхідних даних є детермінованою; той самий запит відносно того самого набору записів виробляє ті самі зібрані вхідні дані, що забезпечує відтворюваність і аудит.

Етап 3 — Генерація тексту з прив'язкою RAG. LLM генерує текст розділ за розділом відносно зібраних вхідних записів. Пошук із доповненням генерації (RAG) є обов'язковою архітектурою: модель генерує текст, прив'язаний до конкретних записів, наданих у контексті промпту, а не відносно своїх параметричних знань. Кожен промпт наказує моделі цитувати ідентифікатор вихідного запису для кожного фактичного твердження. Вихідні дані відповідають суворій JSON-схемі, що відображається на розділи шаблону звіту. Валідація схеми виконується відразу після отримання; помилки синтаксичного аналізу ініціюють автоматичне повторення з виправними інструкціями до маршрутизації на перевірку аналітиком.

Етап 4 — Виявлення галюцинацій і верифікація прив'язки до фактів. Кожен згенерований звіт проходить автоматизовану перевірку прив'язки до фактів до того, як потрапить до рецензента-людини. Перевірка підтверджує, що кожен цитований ідентифікатор вихідного запису існує у вхідному наборі і що згенероване твердження семантично узгоджується зі змістом цитованого запису. Семантична узгодженість перевіряється за допомогою другого LLM-виклику з бінарним судженням у промпті — легкий підхід, що виявляє найпоширеніші зразки галюцинацій без вичерпного зіставлення сутностей. Твердження, що не пройшли перевірку узгодженості, позначаються у чернетці звіту. Реєстр відомих хибних тверджень (спростовані атрибуції, хибнопозитивні індикатори) сканується відносно кожного звіту; будь-яке збіг блокує розповсюдження до вирішення конфлікту аналітиком.

Етап 5 — Перевірка та затвердження людиною. Жоден автоматизований CTI-звіт не розповсюджується без затвердження рецензентом-людиною. Інтерфейс рецензента показує чернетку звіту з усіма виділеними позначками прив'язки до фактів, відображає вихідні записи, що підтримують кожне позначене твердження, і вимагає явної дії затвердження до того, як звіт потрапить до черги розповсюдження. Ідентифікатор рецензента, часова мітка і всі внесені виправлення реєструються як частина запису походження звіту. Це не бюрократична формальність — у контексті військового CTI автоматизований звіт, що містить неправильну атрибуцію, яка визначає командне рішення, є загрозою оперативній безпеці, а не просто розвідувальною помилкою.

Вимоги до структурованих вхідних даних

Стеля якості для автоматизованих CTI-звітів визначається якістю структурованих вхідних даних. Жодна стратегія промпт-інжинірингу не компенсує відсутні зіставлення технік ATT&CK, відсутні показники достовірності або невирішені псевдоніми суб'єктів загрози. Наступні вимоги до вхідних даних є мінімальними для надійної генерації звітів.

Пакети STIX 2.1 мають містити розв'язані зв'язки між об'єктами. Пакет, що містить лише об'єкти Indicator без об'єктів Relationship, що з'єднують їх із об'єктами Threat Actor, Malware та Attack Pattern, не надає контексту атрибуції, необхідного генератору звітів. Об'єкти Campaign, що пов'язують Threat Actor із кількома об'єктами Indicator у часовому діапазоні, особливо цінні для генерації виконавчих брифінгів, оскільки вони надають структурні докази атрибуції активності без вимоги до LLM самостійно їх виводити.

Зіставлення технік ATT&CK мають містити показники достовірності на кожну техніку. Зіставлення техніки без показника достовірності за замовчуванням трактується як низька достовірність. Показник достовірності використовується для калібрування сили текстового твердження: зіставлення T1071 (Application Layer Protocol) із високою достовірністю визначає конкретне твердження про метод C2-комунікації противника; зіставлення із низькою достовірністю визначає обережне твердження з такими формулюваннями, як "можливо відповідає", а не "використовує". Це розрізнення має оперативне значення на командному рівні, де надмірно впевнена розвідка historically призводила до поганих рішень.

TLP-класифікації мають бути присутніми на всіх вихідних записах до генерації звітів. Конвеєр обчислює рівень TLP звіту як максимум за всіма рівнями TLP вихідних записів і застосовує його автоматично. Вихідний запис без TLP-класифікації за замовчуванням трактується як TLP:AMBER — найбільш консервативний незаблокований рівень — до явного присвоєння класифікації аналітиком. Цей підхід за замовчуванням консервативний запобігає випадковому надмірному поширенню.

Засоби контролю якості: запобігання галюцинаціям у CTI-контексті

Запобігання галюцинаціям у контексті військового CTI вимагає більшого, ніж стандартні підходи до валідації вихідних даних LLM, що використовуються у комерційних застосунках. Три конкретні засоби контролю є обов'язковими.

По-перше, твердження про атрибуцію мають бути прив'язані до фактичних доказів інфраструктури кампанії, а не до параметричних знань моделі про угруповання суб'єктів загрози. Модель, навчена на публічних CTI-звітах, знає чимало про APT-групи — їх інструментарій, зразки цільових атак, минулі операції. Ці параметричні знання не мають дозволятись визначати твердження про атрибуцію у згенерованому військовому звіті. Архітектура RAG забезпечує це: контекст промпту містить лише конкретні записи, зібрані для цього звіту, і моделі дається вказівка робити твердження про атрибуцію лише з цього контексту.

По-друге, мова достовірності має бути відкалібрована відповідно до вхідних показників достовірності, а не до мовних уподобань моделі. LLM схильні до впевнених тверджень у плавній прозі. У CTI-контексті розділ звіту, згенерований із записів із середнім показником достовірності 0,62, має використовувати обережні формулювання — "оцінено з помірною достовірністю", "відповідає, але не підтверджено як" — незалежно від того, наскільки плавним було б написати твердження рішуче. Для забезпечення цього потрібні явні правила відображення достовірності на мову у промпті та постгенераційна перевірка, що сканує вихідні дані на мову впевненого твердження у поєднанні із записами з низькою достовірністю.

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

Для більш детального розгляду того, як CTI-платформи структурують дані загроз для продуктів розвідки командного рівня, дивіться наш посібник з архітектури CTI-платформ рівня оборони.

Розповсюдження: відповідність каналу типу звіту

Автоматизовані звіти мають цінність лише тоді, коли вони досягають правильної аудиторії через правильний канал з відповідними засобами контролю доступу. Середовища військового командування мають специфічні вимоги до розповсюдження, яких комерційні CTI-платформи не передбачають.

XMPP і push у реальному часі

Для термінових виконавчих брифінгів і сповіщень про інциденти з високим ступенем серйозності XMPP push доставляє коротке попередження — позиція загрози, угруповання противника, рекомендована дія та захищене посилання для отримання — персоналу командування протягом секунд після затвердження звіту. XMPP є привабливим протоколом для тактичних командних комунікацій у багатьох оборонних середовищах через свою федеративну архітектуру та буферизацію повідомлень в режимі офлайн. Повний звіт доступний за посиланням для отримання; повідомлення XMPP є сповіщенням, а не самим звітом.

MISP push для технічного розповсюдження

Технічні звіти про індикатори безпосередньо надсилаються до екземпляру MISP командування як структуровані події з тегами галактики ATT&CK, позначками TLP і пов'язаними об'єктами STIX. Правила кореляції SIEM нижче за потоком та інструменти виявлення на кінцевих точках підписуються на потік подій MISP і автоматично завантажують нові індикатори без необхідності аналітичного втручання для кожного звіту. Засоби контролю розповсюдження MISP забезпечують обмеження TLP на рівні групи спільного доступу, гарантуючи, що індикатори, позначені TLP:AMBER, не потрапляють до несанкціонованих серверів у федерації.

PDF та DOCX для ланцюжка командування

Виконавчі брифінги та профілі противника відтворюються у PDF для офіційного розповсюдження через системи управління документами командування. Вихідні дані PDF включають метадані походження звіту — ідентифікатор звіту, часова мітка генерації, версія ATT&CK, ідентифікатор рецензента, TLP-класифікація — у стандартизованому заголовку. Вихідні дані DOCX надаються для звітів, які будуть анотовані і переслані персоналом командування. Обидва формати генеруються з одного і того ж вихідного JSON-запису, забезпечуючи синхронізацію структурованої та придатної для читання людиною версій. Шаблони форматування забезпечують послідовне оформлення для всіх типів звітів, щоб персонал командування ознайомлювався зі структурою документа, а не переорієнтовувався на інше оформлення щоразу.

Для контексту про те, як конвеєри моніторингу OSINT подають структуровані CTI-дані до продуктів розвідки командного рівня, дивіться наш посібник з архітектури моніторингу загроз OSINT рівня оборони.

Corvus.Sense: структуровані брифінги з розвідки загроз із моніторингу OSINT

Конвеєр, описаний у цій статті, вимагає безперервного джерела структурованих, збагачених CTI-даних як вхідних даних вище за потоком. Telegram-канали, відкриті платформи обміну повідомленнями та джерела OSINT є одними з найбільш інформативних вхідних даних для моніторингу активності противника у поточних конфліктних середовищах — але вони надають неструктурований контент, який вимагає автоматизованої класифікації та збагачення до того, як він зможе забезпечити генерацію звітів.

Corvus.Sense надає цей шар вище за потоком: безперервний моніторинг Telegram-каналів і джерел OSINT, автоматизована LLM-класифікація контенту загроз, зіставлення технік ATT&CK із показниками достовірності, TLP-класифікація та структуровані записи розвідки, придатні для експорту STIX. Вихідні дані є структурованим CTI-вхідним матеріалом, якого вимагає конвеєр генерації звітів — записи суб'єктів загрози, хронології технік, набори індикаторів та дані профілів противника, зібрані з відстежуваних відкритих джерел у близькому до реального часу режимі.