
# Інтеграція реального часу розвідки про загрози з ШІ для автоматизованих відповідей на питання безпеки  

Опитувальники безпеки – один із найчасозатратніших артефактів у процесі управління ризиками постачальників SaaS. Вони потребують актуальних доказів щодо захисту даних, реагування на інциденти, управління вразливостями і, усе частіше, щодо **поточної ситуації з загрозами**, яка може вплинути на постачальника. Традиційно команди безпеки копіюють‑вставляють статичні політики та вручну оновлюють формулювання ризиків щоразу, коли виявляється нова вразливість. Такий підхід схильний до помилок і занадто повільний для сучасних циклів закупівлі, які часто завершуються за кілька днів.

**Procurize** вже автоматизує збір, організацію та створення чернеток відповідей на опитувальники за допомогою ШІ. Наступний крок – **вбудовування живої розвідки про загрози** у процес генерації, щоб кожна відповідь відображала найновіший контекст ризику. У цій статті ми:

* Пояснимо, чому статичні відповіді є ризиком у 2025 році.  
* Описатимемо архітектуру, що поєднує потоки розвідки про загрози, граф знань і підказки великих мовних моделей (LLM).  
* Показуватимемо, як створювати **правила валідації відповідей**, які тримають вихід ШІ у відповідності зі стандартами комплаєнсу.  
* Надатимемо покроковий посібник з впровадження для команд, що використовують Procurize.  
* Розглянемо вимірювані вигоди та потенційні підводні камені.  

---

## 1. Проблема зі застарілими відповідями на опитувальники  

| Проблема | Вплив на управління ризиками постачальника |
|----------|---------------------------------------------|
| **Регуляторне відхилення** – Політики, створені до появи нових нормативів, можуть не задовольняти оновлення [GDPR](https://gdpr.eu/) або [CCPA](https://oag.ca.gov/privacy/ccpa). | Зростає ймовірність знаходження порушень під час аудиту. |
| **Нове уразливості** – Критичний CVE, виявлений після останнього перегляду політики, робить відповідь неточною. | Клієнти можуть відхилити пропозицію. |
| **Зміна тактик та процедур (TTP) акторів** – Техніки атак розвиваються швидше, ніж квартальні перегляди політик. | Підриває довіру до стану безпеки постачальника. |
| **Ручна повторна робота** – Командам безпеки доводиться шукати кожен застарілий рядок. | Втрачаються години інженерного часу та уповільнюються продажі. |

Статичні відповіді таким чином стають прихованим ризиком. Мета – зробити кожну відповідь **динамічною**, **підкріпленою доказами**, і **безперервно перевіреною** проти актуальних даних про загрози.

---

## 2. Архітектурна схема  

Нижче – високорівневий Mermaid‑діаграм, що ілюструє потік даних від зовнішньої розвідки про загрози до ШІ‑згенерованої відповіді, готової до експорту з Procurize.

```mermaid
graph TD
    A["Live Threat Intel Feeds"]:::source --> B["Normalization & Enrichment"]:::process
    B --> C["Threat Knowledge Graph"]:::store
    D["Policy & Control Repository"]:::store --> E["Context Builder"]:::process
    C --> E
    E --> F["LLM Prompt Engine"]:::engine
    G["Questionnaire Metadata"]:::source --> F
    F --> H["AI‑Generated Draft"]:::output
    H --> I["Answer Validation Rules"]:::process
    I --> J["Approved Response"]:::output
    J --> K["Procurize Dashboard"]:::ui

    classDef source fill:#f9f,stroke:#333,stroke-width:2px;
    classDef process fill:#bbf,stroke:#333,stroke-width:2px;
    classDef store fill:#bfb,stroke:#333,stroke-width:2px;
    classDef engine fill:#ffb,stroke:#333,stroke-width:2px;
    classDef output fill:#fbf,stroke:#333,stroke-width:2px;
    classDef ui fill:#f66,stroke:#333,stroke-width:2px;
```

**Ключові компоненти**

1. **Live Threat Intel Feeds** – API від сервісів типу AbuseIPDB, OpenCTI або комерційних постачальників.  
2. **Normalization & Enrichment** – Нормалізує формати даних, збагачує IP‑адреси геолокацією, прив’язує CVE до оцінок CVSS і позначає техніки ATT&CK.  
3. **Threat Knowledge Graph** – Сховище Neo4j або JanusGraph, яке зв’язує вразливості, акторів загроз, експлуатовані активи та контрольні заходи.  
4. **Policy & Control Repository** – Існуючі політики (наприклад, [SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2), [ISO 27001](https://www.iso.org/standard/27001), внутрішні) зберігаються у сховищі документів Procurize.  
5. **Context Builder** – Об’єднує граф знань із відповідними вузлами політик, формуючи *payload* контексту для кожного розділу опитувальника.  
6. **LLM Prompt Engine** – Надсилає структурований підказка (system + user) до налаштованої LLM (наприклад, GPT‑4o, Claude‑3.5), що включає найновіший контекст загрози.  
7. **Answer Validation Rules** – Правил‑двигун (Drools, OpenPolicyAgent), який перевіряє чернетку на відповідність критеріям комплаєнсу (наприклад, “повинна посилатися на CVE‑2024‑12345, якщо він присутній”).  
8. **Procurize Dashboard** – Показує живий прев’ю, журнал аудиту та дозволяє рецензентам затвердити або редагувати фінальну відповідь.

---

## 3. Промпт‑інжиніринг для контекстно‑обізнаних відповідей  

Якісний підказка – ключ до точної генерації. Нижче – шаблон, який використовують клієнти Procurize, поєднуючи статичні уривки політик із динамічними даними про загрози.

```
System: You are a security compliance assistant for a SaaS provider. Your responses must be concise, factual, and cite the most recent evidence available.

User: Provide an answer for the questionnaire item "Describe how you handle newly disclosed critical vulnerabilities in third‑party libraries."

Context:
- Policy excerpt: "All third‑party dependencies are scanned weekly with Snyk. Critical findings must be remediated within 7 days."
- Recent intel: 
  * CVE‑2024‑5678 (Snyk severity: 9.8) discovered on 2025‑03‑18 affecting lodash v4.17.21.
  * ATT&CK technique T1190 "Exploit Public‑Facing Application" linked to recent supply‑chain attacks.
- Current remediation status: Patch applied on 2025‑03‑20, monitoring in place.

Constraints:
- Must reference the CVE identifier.
- Must include remediation timeline.
- Must not exceed 150 words.
```

LLM поверне чернетку, яка вже **згадує останній CVE** і відповідає внутрішній політиці щодо ремедіації. Далі движок валідації перевіряє, чи існує CVE у графі знань і чи відповідає тайм‑лайн правилам 7‑денної політики.

---

## 4. Створення правил валідації відповідей  

Навіть найкраща LLM може «галюцинувати». Правил‑на‑основі захисний бар’єр усуває хибні твердження.

| ID правила | Опис | Приклад логіки |
|------------|------|----------------|
| V‑001 | **Наявність CVE** – Кожна відповідь, що посилається на вразливість, має містити дійсний CVE‑ID, який присутній у графі знань. | `if answer.contains("CVE-") then graph.containsNode(answer.extractCVE())` |
| V‑002 | **Тайм‑бонд ремедіації** – Твердження про виправлення мають відповідати максимальній кількості днів, зазначеній у політиці. | `if answer.matches(".*within (\d+) days.*") then extractedDays <= policy.maxDays` |
| V‑003 | **Атрибуція джерела** – Усі фактичні твердження мають посилатися на джерело (назва фіду, ID звіту). | `if claim.isFact() then claim.source != null` |
| V‑004 | **Відповідність ATT&CK** – Якщо згадується техніка, вона має бути пов’язана з контрольним заходом, що її пом’якшує. | `if answer.contains("ATT&CK") then graph.edgeExists(technique, control)` |

Ці правила кодуються в **OpenPolicyAgent (OPA)** у вигляді політик Rego і автоматично виконуються після етапу LLM. Будь‑яке порушення позначає чернетку для ручного перегляду.

---

## 5. Покроковий посібник з впровадження  

1. **Обрати постачальників розвідки про загрози** – Зареєструватися хоча б у двох фідах (один відкритий, один комерційний) для забезпечення покриття.  
2. **Розгорнути сервіс нормалізації** – Використати функцію AWS Lambda, яка отримує JSON з фідів, мапить поля до уніфікованої схеми й відправляє в Kafka‑топік.  
3. **Налаштувати граф знань** – Встановити Neo4j, визначити типи вузлів (`CVE`, `ThreatActor`, `Control`, `Asset`) та зв’язки (`EXPLOITS`, `MITIGATES`). Заповнити його історичними даними та налаштувати щоденний імпорт з Kafka.  
4. **Інтегрувати з Procurize** – Увімкнути модуль *External Data Connectors*, налаштувати запити до графу через Cypher для кожного розділу опитувальника.  
5. **Створити шаблони підказок** – У бібліотеці *AI Prompt Library* Procurize додати шаблон, показаний вище, використовуючи змінні‑заповнювачі (`{{policy_excerpt}}`, `{{intel}}`, `{{status}}`).  
6. **Налаштувати движун валідації** – Розгорнути OPA як sidecar у тому ж pod Kubernetes, завантажити політики Rego і надати REST‑endpoint `/validate`.  
7. **Запустити пілот** – Обрати низькоризиковий опитувальник (наприклад, внутрішній аудит) і дозволити системі генерувати відповіді. Перевірити позначені правила і удосконалити формулювання підказки та суворість правил.  
8. **Виміряти KPI** – Відстежувати середній час генерації відповіді, кількість порушень валідації та скорочення годин ручної роботи. Поставити мету **70 % скорочення** часу до доставки вже через перший місяць.  
9. **Впровадити у продакшн** – Увімкнути робочий процес для всіх вихідних опитувальників постачальників. Налаштувати оповіщення про будь‑яке порушення правил валідації, що перевищує поріг (наприклад, >5 % відповідей).  

---

## 6. Кількісні вигоди  

| Показник | До інтеграції | Після інтеграції (через 3 міс) |
|----------|----------------|--------------------------------|
| Середній час генерації відповіді | 3,5 год (ручний) | 12 хв (ШІ + розвідка) |
| Обсяг ручної редакції | 6 год на опитувальник | 1 год (лише ревізія) |
| Інциденти регуляторного зсуву | 4 за квартал | 0,5 за квартал |
| Оцінка задоволеності клієнтів (NPS) | 42 | 58 |
| Кількість знахідок під час аудиту | 2,3 % | 0,4 % |

Ці дані отримані від перших впроваджувачів **Threat‑Intel‑Enhanced Procurize** (наприклад, фінтех SaaS, що обробляє 30 опитувальників на місяць).

---

## 7. Типові підводні камені та їх уникнення  

| Підводний камінь | Симптоми | Заходи профілактики |
|-------------------|----------|----------------------|
| **Залежність від одного фіду** | Пропущені CVE, застарілі ATT&CK‑мапи | Поєднати кілька фідів; резервний відкритий фід типу NVD. |
| **Галюцинації ШІ щодо неіснуючих CVE** | Відповіді посилаються на “CVE‑2025‑0001”, якого немає | Жорстке правило V‑001; логувати кожен витягнутий ідентифікатор для аудиту. |
| **Вузька пропускна здатність запитів до графу** | Затримка >5 сек на відповідь | Кешувати часто‑використовувані результати; використовувати індекси Neo4j Graph‑Algo. |
| **Несумісність політики та розвідки** | Політика вимагає ремедіацію за 7 днів, а розвідка вказує 14‑дневний шлюз через затримки постачальника | Додати процес **policy‑exception**, де лідер безпеки може затвердити тимчасове відхилення. |
| **Регуляторні зміни, що випереджають оновлення фідів** | Новий EU регламент не відображений у жодному фіді | Підтримувати ручний “список регуляторних виключень”, який підказка інжекціює у контекст. |

---

## 8. Перспективні вдосконалення  

1. **Прогностичне моделювання загроз** – Використовувати LLM для прогнозування майбутніх CVE на основі історичних патернів, дозволяючи проактивно оновлювати політики.  
2. **Оцінки нуль‑довіри** – Поєднувати результати валідації у реальний час з ризиковим балом, який відображається на довірчій сторінці постачальника.  
3. **Само‑навчання підказок** – Періодично перенавчати шаблони підказок за допомогою підкріплювального навчання на основі зворотного зв’язку рецензентів.  
4. **Федеративний обмін знаннями** – Створити федеративний граф, у якому кілька SaaS‑постачальників анонімно діляться мапінгами розвідки‑політик, підвищуючи колективний рівень безпеки.  

---

## 9. Висновок  

Вбудовування **розвідки про загрози в реальному часі** у ШІ‑драйвану автоматизацію опитувальників Procurize відкриває три ключові переваги:

* **Точність** – Відповіді завжди підтверджені найсвіжішими даними про вразливості.  
* **Швидкість** – Час генерації скорочується з годин до хвилин, підтримуючи конкурентоспроможність у продажах.  
* **Довіра до комплаєнсу** – Правил‑двигун гарантує, що кожне твердження відповідає внутрішнім політикам та зовнішнім вимогам (наприклад, [SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2), [ISO 27001](https://www.iso.org/standard/27001), [GDPR](https://gdpr.eu/), [CCPA](https://oag.ca.gov/privacy/ccpa)).

Для команд безпеки, що стикаються з ростом кількості опитувальників, описана інтеграція пропонує практичний шлях перетворення ручної «вузької пляшки» у стратегічну перевагу.

---

## Дивіться також  

- [NIST SP 800‑53 Revision 5 – Security and Privacy Controls for Federal Information Systems](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final)  
- [OpenCTI – Open-source Cyber Threat Intelligence Platform](https://www.opencti.io/)