Чем отличается угроза от риска и уязвимости — разбор на реальном тикете из SOC

На третьей неделе в SOC (Security Operations Center — центр мониторинга безопасности) я завёл тикет с пометкой «критическая угроза»: сканер показал CVE с оценкой CVSS 9.8 на продуктивном сервере. Старший аналитик глянул карточку, молча переставил приоритет на «средний» и задал два вопроса: «Эксплойт в дикой природе есть? Сервер из интернета доступен?». Сервер стоял за тремя файрволами без прямого входящего трафика. Уязвимость — критическая (CVSS 9.8 = Critical по шкале NVD). Угроза — низкая (нет экспозиции, нет известных эксплойтов). Риск — средний (изоляция сервера снижает вероятность реализации). Три слова, три разных оценки — а я тогда валил их в одну кучу. Ниже — разбор, после которого терминология кибербезопасности для начинающих перестала быть абстракцией и стала рабочим инструментом.

Уязвимость, угроза, риск — определение через один инцидент

Русскоязычные стандарты (ГОСТ Р 50922-2006, ГОСТ Р ИСО/МЭК 27005-2010) дают минимум шесть разных определений риска и несколько формулировок угрозы. Чтобы не тонуть в нормативном языке, разберём понятия на одном примере.

На сервере компании работает веб-приложение с устаревшей библиотекой, в которой обнаружена SQL-инъекция (A03:2021 — Injection по классификации OWASP Top 10, каталогу критичных рисков веб-приложений). Раскладываем ситуацию на три компонента.

Уязвимость — слабое место, которое можно эксплуатировать

Уязвимость — конкретная слабость в системе, процессе или конфигурации. В нашем примере это баг в коде, позволяющий выполнить произвольный SQL-запрос к базе данных.

Уязвимости регистрируются как CVE (Common Vulnerabilities and Exposures — единый реестр известных уязвимостей) и получают оценку CVSS (Common Vulnerability Scoring System — числовая шкала от 0 до 10, где 10 — максимальная опасность). Сама по себе уязвимость ущерба не наносит. Дверь с незапертым замком — уязвимость. Пока никто не пришёл её открыть, ничего плохого не случилось.

По данным Mandiant M-Trends 2025, эксплуатация уязвимостей (exploits) — самый распространённый вектор первичного доступа: 38% расследованных инцидентов начинались именно с неё, обгоняя фишинг и повторное использование скомпрометированных учёток.

Примеры уязвимостей за пределами кода:

• слабый пароль администратора (A07:2021 — Identification and Authentication Failures по OWASP);
• неправильно настроенные права доступа в облаке (A05:2021 — Security Misconfiguration);
• устаревшая версия библиотеки без патча (A06:2021 — Vulnerable and Outdated Components);
• сотрудник, не прошедший обучение по распознаванию фишинга.

Угроза — кто или что способно ударить по слабому месту

Угроза — потенциальный источник негативного воздействия, который может воспользоваться уязвимостью. В нашем примере угроза — злоумышленник, который знает о SQL-инъекции и намерен через неё выкачать базу клиентов.

По источнику угрозы делятся на три группы:

• Внешние — хакерские группировки, операторы шифровальщиков (ransomware), государственные APT-группы (Advanced Persistent Threat — группы, действующие в интересах государств и способные вести длительные скрытные кампании). По данным CrowdStrike Global Threat Report 2025, 86% атак имели финансовую мотивацию: выкупы, продажа данных, мошенничество.
• Внутренние — сотрудник с избыточными правами, подрядчик с доступом к продуктивной среде.
• Естественные — пожар в серверной, отключение электропитания, затопление.

Для систематизации угроз существует MITRE ATT&CK — открытая база тактик и техник атак. Каждая техника получает идентификатор (T-код). Вот несколько, которые стоит запомнить сразу:

• T1190 (Exploit Public-Facing Application, тактика Initial Access) — эксплуатация уязвимости в приложении, доступном из интернета. Ровно наша ситуация с SQL-инъекцией.
• T1566.001 (Spearphishing Attachment, тактика Initial Access) — целевой фишинг с вредоносным вложением в письме.
• T1078 (Valid Accounts, тактики Initial Access / Persistence / Privilege Escalation) — использование легитимных учётных записей для входа и закрепления в системе.

Угроза без уязвимости бессильна. Вор (угроза) не войдёт, если дверь заперта, стены без щелей и охранник на месте (нет эксплуатируемой уязвимости).

Риск — вероятность умноженная на последствия

Риск — не синоним угрозы. Риск показывает, насколько вероятно, что конкретная угроза реализуется через конкретную уязвимость, и каков будет ущерб. Мнемоническая формула для запоминания компонентов:

Риск = Угроза + Уязвимость + Актив

Это не формальное определение из стандартов, а упрощённая иллюстрация: риск возникает там, где есть все три элемента.

В операционном виде, который удобнее при работе в SOC:

Риск = Вероятность реализации угрозы × Потенциальный ущерб

Вернёмся к SQL-инъекции:

• Вариант А: сервер доступен из интернета, содержит персональные данные 500 000 клиентов. Вероятность высокая (T1190 — публичное приложение). Ущерб катастрофический: утечка ПДн, штрафы по ФЗ-152, репутационные потери. Риск — критический.
• Вариант Б: сервер во внутренней сети за VPN и файрволами, содержит справочник товаров. Вероятность низкая (нужен предварительный доступ к сети). Ущерб минимальный. Риск — низкий.

Одна уязвимость — разный риск, потому что отличаются доступность для угрозы и ценность актива. Именно это различие я не понимал в первый месяц.

По данным Verizon Data Breach Investigations Report 2025, медианный выкуп при ransomware-атаке составил $46 000, а максимальный — $75 млн в единичном инциденте. Вот почему оценка риска в кибербезопасности — не бюрократическое упражнение, а вопрос выживания бизнеса.

Триада CIA — конфиденциальность, целостность, доступность

При разборе инцидентов мало понять, чем отличается угроза от риска и уязвимости. Нужно ещё определить, что именно нарушено. Для этого используют триаду CIA (Confidentiality, Integrity, Availability) — три базовых свойства информации:

• Конфиденциальность (Confidentiality) — информация доступна только тем, кому положено. Нарушение: утечка базы данных. В январе 2024 года данные более 15 млн пользователей Trello — email-адреса, имена, логины — были собраны через скрапинг публичного API и выставлены на продажу на хакерском форуме.
• Целостность (Integrity) — данные не изменены без разрешения. Нарушение: подмена записей в бухгалтерской системе, внедрение бэкдора в обновление ПО (A08:2021 — Software and Data Integrity Failures по OWASP).
• Доступность (Availability) — сервис работает когда нужен. Нарушение: DDoS-атака, шифровальщик (техника T1486 — Data Encrypted for Impact по MITRE ATT&CK: злоумышленник шифрует данные жертвы и требует выкуп). По данным Verizon DBIR 2025, рост ransomware-инцидентов в сегменте малого и среднего бизнеса составил 18% за 2024 год.

Когда приходит алерт в SIEM (Security Information and Event Management — система сбора и корреляции событий безопасности), первое, что фиксируется в карточке инцидента: какой элемент CIA затронут. От этого зависит playbook (сценарий реагирования) и приоритет.

Как анализировать инцидент ИБ пошагово — методика разбора

Соберём всё вместе. Ниже — методика разбора инцидентов информационной безопасности в пяти шагах. Она работает для любого алерта: от подозрительного входа в учётную запись до обнаружения шифровальщика.

Шаг 1: зафиксировать событие и определить затронутый актив

Зачем: без фактов дальнейший анализ — гадание. Карточка должна быть заполнена до начала интерпретации.

Чек-лист:

• Когда — дата и время события (UTC).
• Что — тип события: неудачная аутентификация, сетевая аномалия, срабатывание антивируса.
• Где — IP-адрес, hostname, сервис.
• Актив — что затронуто: сервер, рабочая станция, облачный сервис, учётная запись.
• Ценность актива — содержит ли персональные данные (ПДн по ФЗ-152), коммерческую тайну, критичен ли для бизнес-процесса.

Ожидаемый результат: заполненная карточка с фактами. Любой коллега, открыв её, понимает контекст без дополнительных вопросов.

NIST CSF 2.0 (фреймворк кибербезопасности Национального института стандартов и технологий США) формализует этот этап: подкатегория ID.AM-01 требует вести реестр аппаратных активов, а DE.AE-01 — поддерживать базовый профиль нормального сетевого трафика для обнаружения аномалий.

Шаг 2: определить какая уязвимость задействована

Зачем: понять точку входа. Без этого брешь не закрыть.

Варианты:

• Известная CVE — проверяем в NVD (National Vulnerability Database, база уязвимостей NIST).
• Ошибка конфигурации — открытый порт, пароль по умолчанию, отсутствие MFA (многофакторной аутентификации).
• Человеческий фактор — сотрудник кликнул по фишинговой ссылке.
• Zero-day — уязвимость, о которой разработчик ещё не знает и для которой нет патча.

Если уязвимость — конкретная CVE, фиксируем:

• Идентификатор (CVE-YYYY-NNNNN).
• CVSS-оценку и вектор. Вектор описывает условия эксплуатации: AV:N — атака возможна по сети удалённо, PR:N — привилегии не нужны, UI:N — действия пользователя не требуются. Чем больше параметров равно «N» — тем проще эксплуатация.
• Наличие публичного эксплойта.
• Включение в каталог CISA KEV (Known Exploited Vulnerabilities — список уязвимостей, которые уже эксплуатируются в реальных атаках; включение в KEV — сигнал о доказанной эксплуатации. Большинство SOC используют его как основание для повышения приоритета патчинга, а в госсекторе США это обязательное требование BOD 22-01).

Ожидаемый результат: в карточке указана конкретная уязвимость или честное «не установлено — требует расследования L2/L3».

Шаг 3: идентифицировать угрозу

Зачем: выбрать правильный playbook реагирования. Фишинговая атака и инсайдер требуют разных действий.

Источники информации:

• Логи SIEM — IP-адреса источника, user-agent, паттерны поведения (время, частота, геолокация).
• Threat Intelligence фиды — сопоставление индикаторов компрометации (IoC — хеши файлов, IP-адреса, домены) с известными кампаниями.
• Контекст MITRE ATT&CK — определение техники. Допустим, в логах видно запуск PowerShell-скрипта, который подтягивает payload с внешнего сервера. Это T1059.001 (PowerShell, тактика Execution) в связке с T1105 (Ingress Tool Transfer, тактика Command and Control).

По данным IBM X-Force Threat Intelligence Index 2025, самый распространённый тип вредоносного ПО в 2024 году — инфостилеры (infostealers, программы для кражи учётных данных и сессий): 32% всех обнаруженных образцов, впереди ransomware. Если алерт связан с утечкой учёток, инфостилер — первая гипотеза для проверки.

Ожидаемый результат: в карточке зафиксирован тип угрозы (внешняя/внутренняя), предполагаемая техника по ATT&CK, уровень достоверности: «подтверждено IoC» или «гипотеза».

Шаг 4: оценить риск по матрице

Зачем: определить приоритет. От него зависит SLA (время на реагирование) и порядок эскалации.

Простейшая матрица 3×3, которой хватает для уровня L1-L2:

Определение вероятности:

• Есть публичный эксплойт + актив доступен из интернета — высокая.
• CVE известна, эксплойт не опубликован — средняя.
• Теоретическая возможность без подтверждённых случаев — низкая.

Определение ущерба:

• Затронуты ПДн, финансовые данные, критичный бизнес-процесс — высокий.
• Затронут внутренний сервис без конфиденциальных данных — средний.
• Затронут тестовый стенд без чувствительной информации — низкий.

Ожидаемый результат: инциденту присвоен приоритет (P1–P4 или аналог из внутренней классификации).

Это качественная оценка. Для зрелых процессов применяют количественные методики: ISO 27005 (международный стандарт управления рисками ИБ), FAIR (Factor Analysis of Information Risk — количественная модель с оценкой ущерба в деньгах), отечественные ГОСТ Р ИСО/МЭК 27005-2010. На уровне SOC-аналитика L1-L2 качественная матрица — рабочий инструмент, а не упрощение.

Шаг 5: задокументировать и передать

Зачем: карточка инцидента — юридический документ. Через месяц по ней восстановят хронологию и обоснуют принятые решения.

Варианты решений:

• Эскалация — передать аналитику L2/L3 при сложности выше текущей компетенции.
• Блокировка — изолировать хост, заблокировать учётную запись, добавить IP в чёрный список файрвола.
• Закрытие — false positive (ложное срабатывание) с обоснованием, почему событие признано безопасным.

NIST CSF 2.0 описывает этот этап через функции RESPOND (RS.AN-01 — расследование уведомлений от систем обнаружения) и RECOVER (RC.CO-01 — управление коммуникациями при восстановлении после инцидента).

Модель угроз информационной безопасности — зачем строить до инцидента

Разбирать инциденты без модели угроз — как тушить пожар, не зная планировки здания. Модель угроз информационной безопасности — структурированный документ, который отвечает на четыре вопроса:

1. Что защищаем — перечень активов с указанием ценности и владельца.
2. От чего защищаем — перечень актуальных угроз для конкретной инфраструктуры.
3. Где слабые места — перечень уязвимостей: технических, организационных, физических.
4. Каков риск — оценка каждой пары «угроза + уязвимость» по матрице.

Российская регуляторика (методика оценки угроз ФСТЭК от 05.02.2021) требует строить модель для государственных информационных систем, ИСПДн (информационных систем персональных данных по ФЗ-152), значимых объектов КИИ и АСУ ТП. На практике модель полезна любой компании — она превращает хаотичную реакцию на алерты в системную работу.

MITRE ATT&CK помогает заполнить раздел «от чего защищаем» конкретикой вместо абстракций. Сравните: «несанкционированный доступ» (бесполезно) и «T1078 — использование скомпрометированных учётных записей для первичного доступа и закрепления» (можно сразу написать правило детекции). Ещё пара техник для полноты картины: T1003.001 (LSASS Memory, тактика Credential Access) — извлечение паролей из памяти процесса Windows, T1070.001 (Clear Windows Event Logs, тактика Defense Evasion) — очистка журналов для сокрытия следов. Каждая техника — строка в модели угроз с конкретной мерой противодействия.

NCSC UK (Национальный центр кибербезопасности Великобритании) формулирует принцип, который я бы повесил на стену в каждом SOC: соответствие стандартам (compliance) не равно безопасности. Формальное выполнение требований может сосуществовать с дырявой защитой. Модель угроз — не галочка для аудитора, а рабочий документ, который обновляется при каждом изменении инфраструктуры.

Оценка риска в кибербезопасности — встроить в ежедневную работу

Когда модель угроз построена и методика разбора инцидентов отработана, остаётся главное — сделать оценку рисков частью повседневной рутины, а не разовым мероприятием.

При каждом новом алерте:

1. Сверить актив с реестром: есть ли он в модели угроз, какая у него категория ценности.
2. Проверить уязвимость: известна ли она, доступен ли патч, есть ли запись в CISA KEV.
3. Определить угрозу: внешняя или внутренняя, целевая или массовая.
4. Выставить приоритет по матрице из шага 4.

При ежемесячном пересмотре:

• Обновить список активов — новые серверы, выведенные из эксплуатации сервисы.
• Проверить, появились ли публичные эксплойты для уязвимостей в инфраструктуре.
• Скорректировать оценки: то, что было средним риском вчера, может стать критическим завтра после публикации эксплойта.

ISO 27005 описывает этот цикл: определение контекста — идентификация рисков — анализ — оценка — обработка — мониторинг. На практике цикл работает только когда аналитик не смешивает три базовых понятия в карточке инцидента.

Обработка рисков сводится к четырём стратегиям:

Как отмечает NCSC UK: риск нельзя устранить полностью, его можно только распознать и управлять им. Цель — не абсолютная безопасность (она недостижима), а осознанные решения на основе анализа, а не интуиции.

Большинство материалов по основам информационной безопасности с нуля подают уязвимость, угрозу и риск как три определения для заучивания. Я прошёл этот путь и скажу прямо: определения без привязки к реальному тикету бесполезны. Пока не получил от старшего аналитика вопрос «а сервер-то из интернета доступен?» — три термина оставались абстракцией из методички. Проблема обучения специалиста по информационной безопасности в том, что стандарты (ГОСТ, ISO) написаны языком, который не приземляется на конкретный алерт. Реальная работа в SOC — не знание определений, а навык декомпозиции: разложить событие на «что сломано» (уязвимость), «кто ломает» (угроза), «насколько это критично» (риск) и «что нарушено» (CIA). На третьем-четвёртом разборе публичного инцидента — хоть утечки Trello на 15 млн записей — руки начинают делать это автоматически. А на десятом настоящем алерте в SIEM слова «угроза» и «уязвимость» перестают быть взаимозаменяемыми навсегда. Если хочется не просто прочитать, а отработать этот навык системно — IB Basics в Codeby ведёт от первого тикета до самостоятельного разбора инцидентов.