Четверг, 14:40. В NVD появляется пачка из 87 новых CVE за сутки, CISO требует триаж до конца рабочего дня: что из этого затрагивает наш стек, что требует экстренного патча. Аналитик копирует описание первого бюллетеня в Claude - и получает блок от DLP: в запросе внутренние имена хостов и версии ПО из SBOM. Знакомо? Именно после такого случая мы подняли локальный инференс на Ollama с моделью Llama 3 8B на RTX 4090 и за шесть часов прогнали весь массив бюллетеней - без единого байта, покинувшего периметр. Ниже - конкретные цифры по VRAM, сравнение моделей на security-задачах и detection-чеклист для SOC, который мониторит собственную LLM-инфраструктуру.
Зачем SOC-команде локальная LLM для кибербезопасности
Облачные LLM решают задачи анализа угроз быстро и качественно. Проблема не в качестве - проблема в данных, которые туда уходят. Аналитик SOC отправляет в GPT-4 запрос с сырым логом firewall, а в запросе - внутренние IP, имена хостов, иногда учётные данные, случайно попавшие в лог. Этот сценарий описывают коллеги из NeetroX в практическом гайде по автоматизации SOC: «zero leakage - модель работает на машине, которую вы контролируете, данные не пересекают периметр». Подробнее - в нашем обзоре безопасность llm атаки.Противники и сами активно используют ИИ для разведки. В MITRE ATT&CK техника Artificial Intelligence (T1588.007, Resource Development) описывает подготовку ресурсов атаки с помощью ИИ, а Query Public AI Services (T1682, Reconnaissance) - прямой сбор информации через публичные модели. SOC-команде нужен адекватный ответ: автоматизация триажа CVE, парсинг OSINT-фидов, корреляция IOC - и всё это без отправки данных наружу.
Три практических мотива поднять свою LLM:
Приватность и регулятивный контекст. 152-ФЗ с оборотными штрафами за утечку персональных данных, отраслевые стандарты ЦБ для финсектора, GDPR для международных операций - все требуют контроля над тем, кто обрабатывает данные. Отправка логов с ПДн в облачный API - это дополнительная поверхность для атрибуции утечки. Локальная LLM убирает из уравнения внешнего процессора.
Предсказуемость затрат. По данным NeetroX, SOC-команда, которая перевела триаж алертов с облачного API на локальную модель на одной GPU-станции, снизила расходы с непредсказуемого per-token billing до фиксированной стоимости электричества. При масштабировании автоматизации облачные расходы растут линейно; локальные - нет.
Доступность при инцидентах. Когда штормит тысячи алертов, облачный API может ответить rate limit'ом. Локальная модель работает с постоянной скоростью - без очередей и round-trip задержек. Для incident response это критично: playbook триажа не должен зависеть от чужого API.
Какой GPU для LLM выбрать: VRAM как главный ограничитель
Главный фактор при выборе видеокарты для нейросети LLM - объём VRAM. Не тактовая частота, не количество CUDA-ядер, а именно видеопамять. Модель должна полностью поместиться в VRAM вместе с KV-cache для контекстного окна - иначе инференс переключается на offload в системную RAM и замедляется в 5-10 раз. Проверено на собственной боли.Расчёт VRAM для моделей разного размера
Формула: Количество параметров × байт на параметр + KV-cache.- FP16 (без квантования): ~2 байта на параметр. Модель 7B ≈ 14 ГБ, 13B ≈ 26 ГБ.
- Q4_K_M (4-битное квантование GGUF): ~0.55 байта на параметр. Модель 7B ≈ 4.5 ГБ, 13B ≈ 8 ГБ.
- KV-cache на контекст 8k для 7B модели: +1-2 ГБ. На 32k - уже +4-8 ГБ.
| GPU | VRAM | Макс. модель (Q4) | Контекст 8k | Контекст 32k | Сценарий для SOC |
|---|---|---|---|---|---|
| RTX 3060 12GB | 12 ГБ | 7B | Да | Нет | Триаж алертов, парсинг IOC |
| RTX 3090 / 4090 | 24 ГБ | 13-20B | Да | Частично | Анализ CVE, суммаризация отчётов |
| A6000 | 48 ГБ | 34-40B | Да | Да | Киберразведка с RAG |
| 2× RTX 4090 | 48 ГБ | 34-40B (требуется vLLM/ExLlamaV2, нет NVLink) | Да | Частично | Глубокий анализ, замена GPT-4 для TI |
| A100 80GB | 80 ГБ | 70B (Q8_0) или 34-40B (FP16), несколько 13B параллельно | Да | Да | Enterprise SOC, параллельный триаж |
Для типовой SOC-задачи - автоматический триаж CVE-фида и первичная классификация OSINT - достаточно RTX 4090 с моделью 13B в квантовании Q4_K_M. На Reddit пользователь с RTX 5070 (12 ГБ VRAM) и 32 ГБ DDR5 успешно запускает модели для анализа кода, но упирается в потолок при работе с моделями крупнее 13B. Если бюджет позволяет один GPU - берите RTX 4090 (24 ГБ). Для production-grade инференса с параллельной обработкой сотен CVE - NVIDIA рекомендует 8× H100 в своём Blueprint для анализа уязвимостей контейнеров, но это уже enterprise-уровень с соответствующим ценником.
Ограничение: NVIDIA vs AMD. CUDA-стек (PyTorch, llama.cpp, vLLM) значительно более зрелый, чем ROCm для AMD. Помимо удобства, есть и security-аспект: уязвимость LeftoverLocals (CVE-2023-4969) затрагивает GPU от AMD, Apple и Qualcomm, но не NVIDIA (подробнее - в разделе про безопасность инференса).
Модели LLM для анализа CVE и OSINT-задач
Не каждая LLM одинаково полезна для security-задач. Исследование LASIGE (Университет Лиссабона, arXiv; точные цифры рекомендуется проверить в первоисточнике) протестировало несколько чатбот-моделей на OSINT - бинарной классификации CTI-твитов и извлечении именованных сущностей (NER):- GPT-4 (облачная): по данным авторов, F1 ≈ 0.94 для бинарной классификации.
- GPT4All (open-source, локальный инференс): по данным авторов, F1 ≈ 0.90 - приемлемо для замены облака.
- Vicuna, Falcon, Dolly, Alpaca-LoRA: по данным авторов, значительно слабее.
- NER (извлечение IOC): все чатбот-модели уступают специализированным моделям. LLM пока не заменяют обученные NER для точного извлечения IP, хешей и доменов из текста.
| Модель | Параметры | VRAM (Q4) | Сильные стороны для security | Ограничения |
|---|---|---|---|---|
| Llama 3 8B | 8B | ~5 ГБ | Быстрый триаж, классификация алертов | Контекст 8k, слаб на длинных отчётах |
| Llama 3.1 70B | 70B | ~40 ГБ | Глубокий анализ CVE, RAG-pipeline | Требует 2× GPU или A100 |
| Mistral 7B | 7B | ~4.5 ГБ | Быстрая суммаризация, приемлемый русский | Менее точен на NER |
| Mixtral 8x7B | 47B (12B акт.) | ~26 ГБ | MoE: хороший trade-off скорости и качества | Нестабилен на длинных контекстах |
| Qwen 2.5 14B | 14B | ~9 ГБ | Сильный multilingual, длинный контекст | Меньше community-файнтюнов для security |
NVIDIA в Blueprint для анализа уязвимостей контейнеров использует Llama 3.1 70B Instruct в связке с RAG (FAISS как векторная БД). Архитектура: Plan-and-Execute pipeline - LLM-планировщик генерирует чеклист проверок для каждого CVE, LLM-агент с RAG последовательно выполняет задачи: от анализа SBOM до генерации VEX-документа.
Квантование модели LLM: баланс между качеством и ресурсами
Квантование - сжатие весов модели из FP16 (2 байта) в INT4/INT8 (0.5-1 байт). Для security-задач выбор метода влияет на точность триажа:- Q4_K_M - оптимальный баланс для задач классификации. Потеря качества ~3-5% относительно FP16, модель занимает в 3.5 раза меньше VRAM.
- Q5_K_M - чуть лучше качество, чуть больше потребление. Рекомендую для анализа CVE, где от модели требуется точно передать severity и affected products.
- Q8_0 - близко к FP16, вдвое меньше по памяти. Если VRAM позволяет - лучший выбор для аналитических задач.
- GPTQ - альтернативный формат, оптимизирован под GPU через ExLlamaV2. Быстрее GGUF на GPU, но менее гибок при offload в RAM.
Развёртывание локального инференса: от нуля до первого CVE-запроса
запускает интерактивную сессию. Для интеграции с SIEM или TIP Ollama поднимает OpenAI-совместимый API на
localhost:11434 - вызов через curl http://localhost:11434/v1/chat/completions с JSON-телом запроса.Для изолированного развёртывания в Docker с GPU-пробросом (предварительно поставьте
nvidia-container-toolkit: apt install nvidia-container-toolkit && systemctl restart docker):
YAML:
services:
ollama:
image: ollama/ollama:latest
ports: ["11434:11434"]
volumes: ["ollama_data:/root/.ollama"]
deploy:
resources:
reservations:
devices:
- {driver: nvidia, count: all, capabilities: [gpu]}docker compose up -d, затем docker exec ollama ollama pull llama3:8b (проверьте доступные теги на ollama.com/library/llama3). После этого API доступен по адресу контейнера - SOAR-платформа или скрипт триажа подключается к нему как к обычному REST-эндпоинту.Ограничение: Ollama не поддерживает аутентификацию API из коробки. Для production - reverse proxy (nginx/Caddy) с mTLS или API-ключом перед портом 11434. Без этого любой процесс на хосте может слать запросы к модели. Я видел, как на одном стенде коллеги оставили голый порт - и через неделю обнаружили, что кто-то из соседнего отдела гонял через него свои маркетинговые тексты. Не критично, но неприятно.
Безопасность GPU-инференса: LeftoverLocals и OWASP-риски
Локальный инференс решает проблему утечки данных наружу, но создаёт новые риски внутри инфраструктуры. Поднял модель - молодец. Теперь мониторь её.LeftoverLocals (CVE-2023-4969). Исследователи Trail of Bits обнаружили, что GPU-ядра на ряде чипов (по данным NVD - затронуты реализации OpenCL, Vulkan, Imagination DDK, AMD Instinct MI300X; в оригинальном отчёте Trail of Bits также упоминаются Apple и Qualcomm) не очищают локальную память между вызовами. Атакующий процесс может прочитать данные, оставленные другим процессом - включая промпты и ответы LLM.
Характеристики по данным NVD:
- CVSS: 6.5 (MEDIUM), вектор CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N
- CWE-401: Missing Release of Memory after Effective Lifetime
- Затронуты (по NVD): Khronos OpenCL, Khronos Vulkan, Imagination DDK, AMD Instinct MI300X (firmware и device). Trail of Bits в оригинальном отчёте также указывает Apple и Qualcomm GPU
- Не затронуты: NVIDIA GPU
Вывод для SOC: для инференса с конфиденциальными данными - NVIDIA GPU (не затронуты по NVD). Если GPU от AMD или других затронутых вендоров - только single-tenant режим, один процесс на GPU. Без вариантов.
OWASP LLM Top 10 2025 - два риска, которые бьют по локальному развёртыванию:
LLM06: Excessive Agency. Если LLM-агент для анализа CVE имеет write-доступ к инфраструктуре (автоматическое применение патчей, модификация правил файрвола) - это прямой вектор ущерба. LLM-агент для CVE-триажа должен работать в режиме read-only: классифицировать и рекомендовать, не исполнять. Модель, которая сама накатывает патчи - это не автоматизация, это русская рулетка.
LLM08: Vector and Embedding Weaknesses. При использовании RAG для анализа CVE (как в NVIDIA Blueprint) векторная БД может быть отравлена модифицированными описаниями уязвимостей, что приведёт к некорректной приоритизации. Hardening: контроль целостности индексов в FAISS/Milvus и мониторинг источников для embedding.
Detection-чеклист: мониторинг LLM-инфраструктуры в SIEM
Развернули локальный инференс - мониторьте его. Конкретные правила корреляции:- Аномальное потребление GPU. Снимите baseline нормального VRAM для вашей модели. Алерт: VRAM вырос на >30% без роста легитимных запросов - возможен запуск второго процесса или эксплуатация LeftoverLocals.
- Нетипичный источник API-запросов. Ollama на порту 11434. Корреляция: запросы с IP или процесса вне whitelist - несанкционированный доступ к инференсу.
- Аномалия объёма ввода. Baseline средней длины промпта для CVE-триажа - 2-4k токенов. Алерт: промпт >32k - попытка извлечения данных через prompt injection или загрузка конфиденциальных документов.
- Деградация скорости. Tokens/sec упало на >50% относительно baseline - возможен GPU-sharing с неавторизованным процессом.
- Целостность модельных файлов. Мониторинг хешей в каталоге моделей Ollama. Изменение хеша - подмена модели (supply chain attack).
Работающий подход - не замена аналитика моделью, а предфильтрация. LLM читает 300 бюллетеней и раскидывает их на три корзины: «вероятно затрагивает наш стек», «вероятно нет», «не могу определить». Аналитик работает только с первой и третьей - это сокращает нагрузку на 60-70% при нулевом риске пропустить критичное, потому что вся неопределённость уходит на ручной разбор.
Опаснее всего не когда модель ошибается, а когда ошибается уверенно: CVSS 9.8, affected - ваш продукт, RCE. Аналитик видит красивый structured output и не перепроверяет, а модель перепутала продукт с похожим названием. Поэтому любой pipeline с локальной LLM обязан включать human-in-the-loop для всего, что классифицировано как Critical. Без исключений.
Если у вас другой стек детекции для мониторинга LLM-инфраструктуры - на форуме codeby.net обсуждаем, как адаптировать эти правила под конкретные SIEM.
