Кибервертикаль «Ковчега знаний» — регламенты данных и постановка проектного результата
Вход — история одного инцидента
Представьте, что вы — аналитик в центре мониторинга безопасности (SOC) крупной организации. В три часа ночи SIEM-система фиксирует серию подозрительных соединений с внешнего IP-адреса на внутренний веб-сервер. Автоматический алерт приходит к вам на смену. Вам нужно ответить на вопрос руководителя: «Что это? Насколько серьёзно? Что делать?»
Вы открываете консоль. Через полчаса у вас шесть вкладок: журналы SIEM, база CVE, отчёт вендора, внутренний реестр активов, две статьи на VirusTotal. Но вы всё ещё не можете ответить строго:
- связан ли этот IP с известной APT-группировкой (а не просто «похож»);
- какие ещё активы в сети могут быть затронуты через те же уязвимости;
- есть ли в прошлых инцидентах аналогичные индикаторы — и если да, какие меры тогда сработали;
- почему два источника описывают критичность этой CVE по-разному.
Проблема не в том, что «инструменты плохие». Проблема в другом: каждый инструмент возвращает свой фрагмент данных — логи, записи, текст. А вам нужно связное знание: объекты (IP, CVE, актор, актив), отношения (кто с чем связан) и контекст (когда наблюдали, откуда, с какой уверенностью), из которых можно построить проверяемый вывод.
| Ключевая идея Кибер-аналитика — это не набор отчётов. Это управляемая структура: сущности (что?), связи (как связано?) и контекст (при каких условиях?), с проверяемым происхождением каждого факта. Без этой структуры расследование зависит от памяти конкретного аналитика — а это не масштабируется, не передаётся и не проверяется. |
Именно в этой точке появляется курс МФК-5 и кибер-слой проекта «Ковчег знаний». Курс устроен не как «теория → экзамен», а как «понимание → артефакт → защита». Вы не просто слушаете лекции — вы начинаете производить фрагмент кибер-графа знаний, пригодный к использованию в реальных сценариях.
Три проблемы, которые делают разрозненные инструменты недостаточными
Проблема 1: инструменты находят данные, а не связи.
SIEM показывает события. CVE-база показывает уязвимости. CTI-фид показывает индикаторы. Но вопрос аналитика — «как связан этот IP с этой уязвимостью через этот инцидент и какой актор за этим стоит?» — живёт не в одном инструменте, а в сети связей: IP ↔ инцидент ↔ уязвимость ↔ актор ↔ тактики. Если эта сеть не представлена явно, аналитик собирает её в голове — и каждый раз заново.
Проблема 2: контекст распадается, и вместе с ним — доверие.
Даже если вы нашли нужные данные, возникают вопросы: это актуальная версия CVE или устаревшая? Когда последний раз обновляли реестр активов? На каких данных сделан вывод в CTI-отчёте? В «документоцентричном» подходе на эти вопросы отвечают вручную — опытом старшего аналитика. Но когда масштаб растёт (тысячи IOC, сотни CVE, десятки инцидентов в месяц), ручной контроль контекста перестаёт работать.
Проблема 3: ИИ даёт ответы, но без гарантии происхождения.
Большие языковые модели формулируют ответы убедительно. Но если модель выдаёт «красивый текст» о связи актора с инцидентом, вы снова упираетесь в вопрос: откуда это? Какие источники? Какая уверенность? Подход Graph-RAG связывает генерацию с извлечёнными фактами из графа, но ключевой вопрос — как устроена «внешняя память». Если это хаотичный набор фрагментов — проблема доверия не решена. Если это граф знаний с происхождением и контролем качества — мы приближаемся к доверенному контуру.
«Кибер-слой» — не диаграмма, а инженерная инфраструктура
Проект «Ковчег знаний МГУ» создаёт платформенную систему структурированных знаний. Кибер-слой — это часть этой платформы, которая связывает данные об угрозах, уязвимостях, инцидентах и контрмерах в единую модель. Не портал с отчётами. Не библиотека PDF. А инфраструктура — система правил, форматов и сервисов, которая позволяет кибер-знанию быть: собранным из разных источников, сведённым в общий смысловой каркас, проверяемым и используемым в сценариях — от мониторинга до поддержки решений.
У кибер-слоя четыре категории потребителей, и каждая задаёт свои вопросы:
| Потребитель | Роль | Вопросы, которые он задаёт |
| SOC | Центр мониторинга | Что произошло? С чем связано? Что приоритетно? |
| CSIRT / CERT | Команда реагирования | Какова цепочка событий? На чём основана атрибуция? Какая уверенность? |
| DevSecOps | Инженерные команды | Компонент → зависимость → CVE → риск → контрмера? |
| Руководство | Принятие решений | Каковы показатели? Почему приняты такие меры? Где оставшиеся риски? |
Графовый подход здесь принципиален. Таблицы великолепны для нормализованных структур. Но как только вы выходите на задачи интеграции разнородных источников, «склейки» сущностей, сложных связных запросов и трассируемости — граф становится естественной формой. Связи в графе — первоклассные объекты: они имеют тип, направление и атрибуты. Это позволяет выполнять запросы на связность, кратчайшие пути и кластеризацию — операции, критичные для расследования инцидентов.
| Важно Граф — не магия. Он не «делает всё сам». Он заставляет нас явно описывать смысловые связи и хранить происхождение каждого факта. За счёт этого система становится управляемой. |
Красные линии — почему в кибер-курсе границы важнее «интересности»
Специфика кибербезопасности как предметной области накладывает жёсткие ограничения на учебную деятельность. В отличие от многих других дисциплин, здесь «интересный эксперимент» легко становится правонарушением. Поэтому курс вводит систему абсолютных запретов — «красных линий», действующих с первого занятия.
Запрещено:
- Любая несанкционированная активность в отношении внешних систем, сетей или аккаунтов. Это уголовное законодательство, а не «правило курса».
- Использование реальных чувствительных данных — персональные данные, коммерческая тайна, продакшн-логи, секреты, токены, пароли — без специального разрешения и обезличивания.
- Перенос «боевых» данных из продакшн-сред в учебную лабораторию.
- Публикация вредоносного кода, эксплойтов или инструментов атак как «результата курса».
Разрешено и приветствуется:
- Работа на учебных, синтетических и публичных наборах данных с фиксированной лицензией.
- Моделирование и аналитика на уровне сущностей, связей и атрибутов — без воспроизведения атак.
- Воспроизводимые запросы, отчётность и документация с указанием источников.
- Работа в изолированной учебной лаборатории: отдельная подсеть, графовая СУБД, Python/Jupyter, Git.
| Правило Границы безопасности важнее «интересности» задания. Если задание требует нарушения красных линий — меняйте задание, а не правила. |
Прослеживаемость и воспроизводимость — два принципа, которые делают кибер-аналитику инженерной
В кибербезопасности всегда звучит вопрос: «Почему вы так решили?» Если ответ — «так кажется» — это ноль. Если ответ — «вот источники, вот версия данных, вот правила преобразования, вот запросы, вот воспроизведение» — это инженерный результат.
Прослеживаемость (traceability) — это устанавливаемая связь между утверждением и его обоснованием. Цепочка: факт → источник → трансформация → версия → запрос → вывод. Для каждого элемента графа должно быть восстановимо: откуда он получен, как преобразован, какая версия использовалась. Если трассировки нет — доверия нет.
Воспроизводимость (reproducibility) — это возможность повторить результат: любой член команды или проверяющий может открыть ваш Project Pack, следовать инструкциям и получить те же выводы. Для этого фиксируются: версия схемы, версия данных, набор запросов и README с пошаговой инструкцией.
| Примечание: что означает «доверие» в инженерном смысле Доверие — это не «мы верим авторам». Это четыре проверяемых свойства: (1) можно указать источник; (2) можно объяснить, как факт получен; (3) можно воспроизвести цепочку рассуждения; (4) можно обновить знание и увидеть, что изменилось. Если прослеживаемости нет — доверия нет. |
С первой недели курса мы вводим дисциплину: каждый артефакт фиксирует версию, источники и инструкцию воспроизведения. Инструмент прослеживаемости на уровне источников — Source Register: таблица, в которой для каждого источника указан тип, лицензия, ограничения, что извлекаем, риски и дата доступа.
Как устроен курс — единица результата: артефакт
Есть два режима обучения. Первый: лекции → зачёт → забыли. Второй: обучение как часть производства результата. Мы работаем во втором режиме. Каждая из десяти недель заканчивается проверяемым артефактом. Артефакты собираются в единый Project Pack и предъявляются на защите.
Артефакт — это не «текст на словах». Это пакет, который можно открыть и понять: что моделируем, на каких источниках, какая версия данных, как воспроизвести, как проверить запросами, какие ограничения и риски. Именно так устроена современная кибер-аналитика: если нет источников, версий и воспроизводимости — это не аналитика, а мнение.
| Артефакт | Неделя | Содержание |
| M5-A1 | W1 | Паспорт домена + Source Register + План работ |
| M5-A2 | W2 | Schema v1 + Traceability v0 + Quality Checklist |
| M5-A3 | W3 | Кибер-домен v1: IOC/CVE/TTP + mapping MITRE ATT&CK |
| M5-A4 | W4 | CTI ingestion pipeline + sample dataset |
| M5-A5 | W5 | Incident Graph + Query Pack (≥7 запросов) |
| M5-A6 | W6 | Graph-RAG prototype + safety checklist |
| M5-A7 | W7 | DevSecOps KB fragment + SBOM-CVE кейс |
| M5-A8 | W8 | Mini-CTF: сценарий + safety plan + отчёт |
| M5-A9 | W9 | Integration & Demo pack (v1) + предзащита |
| M5-A10 | W10 | Final Project Pack (v2) + слайды защиты |
M5-A1 — фундамент всей цепочки. Если домен выбран неудачно, границы размыты, а источники не зафиксированы — каждый последующий артефакт будет строиться на шатком основании. Именно поэтому первая неделя посвящена не «загрузке данных в граф», а постановке: что именно мы моделируем, зачем, для кого, откуда данные и какие вопросы должен уметь отвечать наш подграф.
Методика выбора фрагмента кибер-домена — пять проверок
Главная ошибка новичков — пытаться смоделировать «всю кибербезопасность». Кибердомен огромен: акторы, кампании, тактики, уязвимости, индикаторы, активы, события, контрмеры, политики, зависимости, SBOM, логи, алерты. Попытка охватить всё за десять недель гарантированно приводит к поверхностному результату.
Вместо этого мы выбираем узкий фрагмент — подграф, который имеет понятные границы, обслуживает конкретного потребителя и отвечает на конкретные проверяемые вопросы. Вы строите не энциклопедию, а инженерный подграф под вопрос.
Проверка 1 — Границы. Можно ли чётко сказать, что входит и что не входит? «Кибербезопасность вообще» — это космос. «Связь IOC с акторами и кампаниями для SOC» — это домен.
Проверка 2 — Объекты. Можете ли вы быстро назвать минимум 10 сущностей? Если нет — домен не оформлен.
Проверка 3 — Вопросы. Существуют ли 3 содержательных вопроса, на которые должен отвечать ваш граф? Если вопрос можно решить одним документом — это не вопрос для графа. Если вопрос требует связей — это кандидат.
Проверка 4 — Данные. Есть ли минимум 3 источника, которые вы имеете право использовать? Если данных нет или они требуют нарушения красных линий — меняйте фрагмент.
Проверка 5 — Безопасность. Можно ли сделать учебно и законно, без «боевой» активности? Если для демо нужна реальная атака — это не наш фрагмент.
| Правило различения Если вопрос можно решить одним документом или одним инструментом — это, скорее всего, не вопрос для графа. Если вопрос требует связей (сравнить источники, выявить зависимости, проследить цепочку, объяснить атрибуцию) — это кандидат на граф. |
Три домена-примера — образец для вашего M5-A1
Ниже — три полностью оформленных примера. Каждый содержит все элементы, требуемые критериями приёмки (DoD). Используйте их как образец для собственного паспорта домена.
Пример 1. Разведка угроз (CTI) для SOC: связь IOC с акторами и кампаниями
| Поле M5-A1 | Содержание |
| Название домена | Разведка угроз для SOC: связь индикаторов компрометации с акторами, кампаниями и тактиками атак |
| Потребитель | Аналитик SOC уровня L2–L3, руководитель смены |
| Границы: входит | IOC (IP, домен, хеш), CVE, TTP, актор, кампания, инцидент, наблюдение, CTI-отчёт |
| Границы: не входит | Физическая инфраструктура, бизнес-процессы, персональные данные, процедуры реагирования |
| Сущности (10) | Threat_Actor, Campaign, IP_Address, Domain, File_Hash, Vulnerability (CVE), TTP (ATT&CK), Incident, Observation, CTI_Report |
| Источники | AlienVault OTX (open source); NVD/NIST (public domain); MITRE ATT&CK (CC BY 4.0); синтетические логи МФК-5 |
| Риски доверия | Неполнота публичных CTI-источников; конфликт атрибуции между источниками; устаревание IOC (IP переиспользуются) |
| Гипотеза WS | WS-1 (Данные) + WS-2 (Граф) |
Вопросы, которые «плохо решаются поиском»:
- Связан ли наблюдаемый IP с известной APT-группировкой — и если да, через какую цепочку (IP → Observation → Incident → Campaign → Actor)?
- Какие CVE эксплуатировались в инциденте X — и какой CVSS у каждой?
- Какие TTP характерны для актора Y по данным нескольких источников — и где источники противоречат друг другу?
- Какие индикаторы (IP, домены) повторяются в разных инцидентах — и что это может означать?
- Какой уровень доверия к атрибуции актора, если два CTI-отчёта дают разную оценку?
Пример 2. DevSecOps: уязвимости, зависимости и контрмеры
| Поле M5-A1 | Содержание |
| Название домена | Управление уязвимостями в контуре DevSecOps: от компонента до контрмеры |
| Потребитель | Инженер DevSecOps, владелец сервиса, AppSec-команда |
| Границы: входит | Программный компонент, зависимость, SBOM, CVE, контрмера (patch/config/workaround), политика обновления, результат SAST/DAST |
| Границы: не входит | Сетевая инфраструктура, HR-данные, финансы, юридические процедуры |
| Сущности (12) | Application, Component, Dependency, SBOM_Record, Vulnerability (CVE), Exploit_Info, Countermeasure, Policy, SAST_Finding, DAST_Finding, Risk_Assessment, Release |
| Источники | NVD (public domain); SBOM-генератор (учебный); OSV.dev (open source); результаты SAST/DAST (синтетические) |
| Риски доверия | Задержка CVE-публикации (0-day не покрыты); неполный SBOM; ложные срабатывания SAST |
| Гипотеза WS | WS-2 (Граф) + WS-4 (Сценарии) |
Вопросы:
- Какие компоненты приложения X содержат зависимости с непатченными CVE критической severity?
- Какие контрмеры закрывают конкретную CVE — и какова задержка между публикацией CVE и применением патча?
- Где в SBOM есть транзитивные зависимости с известными уязвимостями?
- Какие SAST-находки подтверждаются наличием CVE в зависимостях?
Пример 3. Инцидент-аналитика: реконструкция цепочки событий
| Поле M5-A1 | Содержание |
| Название домена | Реконструкция цепочки инцидента: от алерта до атрибуции |
| Потребитель | Аналитик CSIRT/CERT, руководитель расследования |
| Границы: входит | Алерт, событие (лог), IOC, актив (хост/сервис), уязвимость, TTP, актор, наблюдение, временная ось, гипотеза расследования |
| Границы: не входит | Юридические процедуры, оценка финансового ущерба, кадровые решения, recovery-процессы |
| Сущности (12) | Alert, Log_Event, IOC (IP/domain/hash), Host, Service, Vulnerability, TTP, Threat_Actor, Observation, Investigation_Hypothesis, Timeline_Entry, Countermeasure |
| Источники | Синтетические логи МФК-5; NVD; MITRE ATT&CK; учебный кейс инцидента (внутренний) |
| Риски доверия | Неполнота логов (пробелы во времени); сложность атрибуции по учебным данным; конфликт между автоматическими алертами и ручным анализом |
| Гипотеза WS | WS-4 (Сценарии) + WS-2 (Граф) |
Вопросы:
- Какова хронологическая цепочка от первого алерта до компрометации актива?
- Какие TTP наблюдаются в инциденте — и совпадают ли они с профилем известного актора?
- Какие активы затронуты — и есть ли между ними общие уязвимости или зависимости?
- Какая гипотеза расследования лучше объясняет наблюдаемые данные — и какие наблюдения ей противоречат?
- Какие контрмеры были применены — и какие из них подтверждённо снизили воздействие?
Паспорт домена (M5-A1): структура артефакта
На первой неделе вы создаёте документ, содержащий шесть ключевых полей:
- Название и описание домена (коротко и однозначно): что моделируем, для какого сценария, кто потребитель.
- Границы (таблица 2×2: «входит / не входит» по объектам и процессам).
- Кандидат-сущности (минимум 10): ключевые объекты домена с описанием и предварительным идентификатором.
- Кандидат-связи (минимум 10): отношения в формате Сущность A —[отношение]→ Сущность B.
- Competency questions (минимум 3): проверяемые вопросы, на которые граф должен уметь отвечать. У каждого — способ проверки и ожидаемый ответ.
- Source Register v0 (минимум 3 источника): тип, ссылка, лицензия/ограничения, что извлекаем, надёжность, риски, дата доступа.
Дополнительно: план работ на 2–3 недели (≥5 задач с владельцем и сроком), гипотезы и риски качества/ИБ.
| Три ловушки «плохого домена» 1. Слишком широко. «Вся кибербезопасность» — не домен, а космос. Сужайте до конкретного сценария и потребителя. 2. Нет проверяемости. Если вы не можете назвать хотя бы типы источников и написать Source Register — доверие не построить. 3. Нет связей. Если получается только список терминов без отношений — вы выбрали словарь, а не домен. |
Source Register — инструмент прослеживаемости, а не библиография
Source Register — это не список литературы. Это инженерный инструмент: он фиксирует, откуда данные попали (или попадут) в граф и на каких условиях. Без Source Register ваш граф — «чёрный ящик»: красивый, но непроверяемый.
Для каждого источника заполняются семь полей:
| Поле | Описание | Пример |
| Source_ID | Уникальный идентификатор | SR-001 |
| Тип | CTI-фид, база данных, отчёт, справочник, учебный датасет | CTI-фид (STIX/TAXII) |
| Ссылка | URL или способ доступа | https://otx.alienvault.com |
| Лицензия | Правовой статус и ограничения распространения | Open source, TLP:WHITE |
| Что извлекаем | Сущности и поля для вашего домена | IOC (IP, домен), связи с кампаниями |
| Надёжность | Оценка с обоснованием | Высокая: крупное сообщество, перекрёстная верификация |
| Риски | Идентифицированные проблемы | Неполнота покрытия; ложные срабатывания |
Типичная ошибка — «ссылка на рандомный блог без лицензии и даты». Такой источник нельзя воспроизвести, нельзя оценить и нельзя обновить. Предпочитайте официальные базы: NVD (NIST), MITRE ATT&CK, AlienVault OTX, CIRCL, OSV.dev.
Критерии приёмки W1 (DoD)
| Чтобы неделя считалась закрытой Границы домена сформулированы конкретно: что входит / что не входит. Есть минимум 10 кандидат-сущностей с описанием (сущности, а не темы). Есть минимум 10 кандидат-связей со смыслом и направлением. Есть 3 проверяемых competency questions с указанием способа проверки. Source Register v0 заполнен (≥3 источника) с лицензиями и рисками. План работ: ≥5 задач с владельцем и сроком. Отсутствие нарушений красных линий. Документ оформлен в Project Pack с README и версией. |
Рубрика оценивания (0–10):
| Баллы | Описание |
| 0–2 | Домен размытый или непроверяемый; сущности формальные (названия без описания); CQ отсутствуют или непроверяемые; Source Register пуст. |
| 3–5 | Домен в целом понятен, но границы размыты; сущности/вопросы абстрактные; Source Register частично заполнен. |
| 6–8 | Домен ограничен; ≥10 сущностей и связей с описанием; 3 хороших CQ; Source Register (≥3) с лицензиями/рисками; план реалистичен. |
| 9–10 | M5-A1 «встраиваемый»: CQ требуют связей; риски конкретны; Source Register ≥4 источника; виден путь к Schema v1 на W2. |
Вопросы для самопроверки
- Почему разрозненные инструменты (SIEM, CVE-база, CTI-фид) не решают задачу связного знания?
- В чём различие между «данными об инциденте» и «знанием об инциденте»?
- Что означает прослеживаемость (traceability) — и какие вопросы она закрывает?
- Зачем первая неделя курса посвящена паспорту домена, а не загрузке данных?
- Сформулируйте один вопрос к вашему домену, который точно требует связей, а не справки из одного источника.
Мини-глоссарий W1
Кибер-слой — подсистема графа знаний, связывающая данные об угрозах, уязвимостях, инцидентах и контрмерах.
Граф знаний — модель данных, представляющая знания как сеть сущностей (узлов) и отношений (рёбер) с атрибутами и происхождением.
IOC (Indicator of Compromise) — индикатор компрометации: IP-адрес, домен, хеш файла или иной артефакт, указывающий на угрозу.
CVE — Common Vulnerabilities and Exposures: стандартный идентификатор уязвимости.
TTP — Tactics, Techniques, Procedures: описание методов атак; стандарт — матрица MITRE ATT&CK.
SOC — Security Operations Center: центр мониторинга и реагирования на инциденты.
CSIRT / CERT — команда реагирования на компьютерные инциденты.
CTI — Cyber Threat Intelligence: разведка киберугроз — сбор, анализ и распространение информации об угрозах.
Provenance — происхождение данных: кто создал утверждение, когда, из каких источников, какая версия актуальна.
Source Register — реестр источников данных с метаданными: тип, лицензия, ограничения, риски.
Competency Question (CQ) — проверяемый вопрос, на который граф должен уметь отвечать; содержит способ проверки.
Traceability — прослеживаемость: устанавливаемая связь факт → источник → версия → вывод.
Reproducibility — воспроизводимость: возможность повторить результат по зафиксированным данным и инструкциям.
DoD (Definition of Done) — набор критериев, определяющих завершённость артефакта.
Property Graph — модель графа, где и узлы, и рёбра могут иметь атрибуты; используется в курсе как базовая парадигма.
SBOM — Software Bill of Materials: ведомость программных компонентов и зависимостей.
Graph-RAG — генерация ответа с опорой на извлечённые из графа знаний факты; способ снижения галлюцинаций LLM.
Мост во вторую неделю W2 — от паспорта к контракту
W1 — это постановка задачи. W2 превращает постановку в инженерный контракт: ваши кандидат-сущности получают формальные ключи, типы атрибутов и ограничения кардинальностей. Ваши competency questions становятся строками матрицы прослеживаемости (Traceability v0): вопрос → элементы схемы → источники → риски. Появляется Quality Checklist — набор из 10+ проверок качества с методами и severity.
Ваш M5-A1 физически трансформируется в M5-A2. Десять сущностей расширяются до двенадцати с ключами и provenance-полями. Десять связей получают кардинальности и валидаторы. Source Register интегрируется в provenance-модель: каждое наблюдение в графе будет привязано к источнику структурно, а не «в комментарии».
| Практический совет Если вы сегодня честно сделали границы, сущности и вопросы — на следующей неделе вы превратите это в схему. Если нет — W2 начнётся с переделки M5-A1. |