Опубликовано: 21.09.2026 | Источник: Xakep.ru

Анализ кибербезопасности IoT для ВКР: модель угроз на примере атаки на Intoxalock

Поддомен: Cybersecurity / ИБ подключённых устройств. Роль автора: специалист по информационной безопасности.

25 марта 2026 года стало известно об атаке на Intoxalock — одного из крупнейших в США поставщиков систем блокировки зажигания. Итог жёсткий и очень показательный: водители, у которых машина «привязана» к алкоблокиратору, просто не смогли завести двигатель. Устройство — не игрушка, оно управляет допуском к запуску автомобиля, а значит, компромисс корпоративной инфраструктуры вендора мгновенно превращается в отказ в обслуживании на уровне физического мира. Для выпускника ИТ-специальности это готовый, публично подтверждённый кейс: есть архитектура, есть точки отказа, есть что формализовать в модель угроз, диаграммы и метрики. Ниже — как превратить этот инцидент в защищаемую ВКР, а не в пересказ новости.

FAQ: что чаще всего спрашивают перед выбором темы

Нужен ли реальный стенд с CAN-шиной или хватит эмуляции?

Для бакалаврской ВКР достаточно программно-аппаратного стенда на Raspberry Pi / ESP32 плюс эмулятор CAN (например, can-utils и socketcand) и MQTT-брокер. В главе 3 вы честно описываете допущения модели: «физический уровень абстрагирован, исследуется логика аутентификации и канал телеметрии». Комиссия это принимает, если допущения зафиксированы явно, а не спрятаны.

Где брать данные об атаках, если вендор не публикует телеметрию?

Используйте три источника: (1) публичные отчёты об инциденте и уведомления регуляторов; (2) синтетические датасеты на базе открытых наборов сетевого трафика IoT (CIC-IoT, TON_IoT, N-BaIoT); (3) собственный логи стенда. Для ВКР по ИБ валиднее всего третий вариант — вы сами генерируете атаку (replay, MITM, подмена прошивки) и сами её детектируете.

Как считать эффективность системы защиты, чтобы цифры не выглядели выдуманными?

Считайте не «проценты защищённости», а измеримые величины: Precision, Recall, F1 для детектора аномалий, MTTR (среднее время реакции), долю ложных срабатываний, число успешных обходов на 100 попыток. Для надёжности — доверительные интервалы и повторяемость эксперимента (минимум 5 прогонов сценария).

Что требовать от нормоконтроля при работе с диаграммами угроз?

Схемы — по ГОСТ 19.701-90 (или UML/C4 с легендой), обозначения — по ГОСТ 34.201-89. Стрелки на DFD подписывайте «что передаётся», а не «зачем». Все аббревиатуры расшифровывайте при первом упоминании. Если не уверены, как писать ВКР по такому шаблону — сначала утвердите перечень схем с научруком, потом рисуйте.

Три темы ВКР, которые вытекают прямо из инцидента

• Тема 1. Разработка системы обнаружения аномалий в телеметрии алкоблокираторов

  Актуальность: атака на Intoxalock показала, что сбой централизованной платформы останавливает парк устройств. Значит, нужен детектор, который ловит отклонения до отказа.

  Цель: снизить время обнаружения компрометации канала телеметрии.

  Задачи: обзор OWASP IoT Top 10 и MITRE ATT&CK for ICS; построение модели нормального трафика; реализация детектора; оценка Precision/Recall и MTTR.

  Структура: Гл. 1 — анализ угроз и стандартов; Гл. 2 — архитектура детектора и стенд; Гл. 3 — эксперименты, метрики, сравнение с baseline.

• Тема 2. Проектирование отказоустойчивой архитектуры телеметрии с mTLS и офлайн-режимом допуска

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

  Цель: обеспечить запуск двигателя при недоступности центрального сервиса без потери контроля трезвости.

  Задачи: анализ сценариев отказа; проектирование локального кэша решений; взаимная аутентификация по mTLS; оценка рисков обхода проверки.

  Структура: Гл. 1 — теория отказоустойчивости и threat modeling; Гл. 2 — C4-диаграммы и спецификация протокола; Гл. 3 — нагрузочные и негативные тесты.

• Тема 3. Оценка рисков кибербезопасности подключённых транспортных средств

  Актуальность: инцидент затрагивает не только вендора, но и регулятора, и пользователя. Нужна воспроизводимая методика оценки.

  Цель: построить модель рисков и приоритизировать меры защиты.

  Задачи: выбор методики (ISO/IEC 27005, ГОСТ Р 56545); расчёт CVSS для выявленных уязвимостей; реестр рисков; план обработки.

  Структура: Гл. 1 — обзор подходов; Гл. 2 — модель активов и угроз; Гл. 3 — калькулятор рисков и сценарии «до/после».

Основная часть: как встроить кейс в главы работы

1. Раскладка инцидента по главам

Не пытайтесь описать хакерскую атаку целиком — комиссия ждёт анализа, а не хроники. Разложите так: в главе 1 инцидент идёт как обоснование актуальности и постановка проблемы (какие активы под угрозой, какие классы угроз реализации). В главе 2 вы проектируете средства защиты под выявленные точки отказа. В главе 3 проверяете их на стенде и считаете метрики. Такой сквозной сюжет сильно выигрывает по сравнению с «обзор литературы + обзор литературы».

2. Модель угроз и диаграммы

Базовый каркас — STRIDE плюс DFD уровня 0/1. Дальше — C4 (Context + Container), чтобы показать, где заканчивается доверенная зона. Пример формализованной записи угроз, который можно положить в приложение:

threat_model:
  system: "ignition_interlock_telemetry"
  assets:
    - id: A1
      name: "Решение о допуске запуска двигателя"
      criticality: high
    - id: A2
      name: "Канал телеметрии устройство-облако"
      criticality: high
  threats:
    - id: T1
      stride: Spoofing
      target: A2
      vector: "Подмена устройства в MQTT-брокере"
      cvss: 8.1
      mitigations: [mTLS, device_attestation]
    - id: T2
      stride: DenialOfService
      target: A1
      vector: "Недоступность облака => блокировка запуска"
      cvss: 7.5
      mitigations: [offline_cache, fail_safe_policy]
  trust_boundaries:
    - "device <-> edge gateway"
    - "edge gateway <-> cloud backend"

Схема верхнего уровня словами, если SVG в шаблоне не поддерживается:

[Устройство в авто] --MQTT/TLS--> [Edge-шлюз] --mTLS--> [Облачный бэкенд]
        |                             |                        |
   локальный кэш              фильтрация/IDS             реестр устройств
   допуска (fail-safe)        (аномалии трафика)         (RBAC, аудит)

3. Метрики и инструменты

Цифры — то, за что цепляется комиссия. Заведите таблицу метрик и обязательно зафиксируйте baseline (состояние «до внедрения защиты»).

4. Конфигурация и код — что реально показать в приложении

Минимальный, но убедительный артефакт — защищённый канал между устройством и брокером. Фрагмент конфигурации MQTT-брокера с обязательной взаимной аутентификацией:

listener 8883
cafile   /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/broker.crt
keyfile  /etc/mosquitto/certs/broker.key
require_certificate true
use_identity_as_username true
tls_version tlsv1.3
allow_anonymous false

Дальше — правило корреляции в SIEM: алерт, если одно устройство за 60 секунд отправило более N запросов на смену статуса допуска без успешной аутентификации. Такое правило легко защитить: оно измеримо, воспроизводимо и напрямую отвечает на сценарий из статьи.

Чему вы научитесь на такой теме

• Строить модель угроз по STRIDE и связывать её с реальным инцидентом, а не с абстрактным списком.
• Проектировать отказоустойчивые схемы, где критическая функция не зависит от доступности облака.
• Настраивать защищённые каналы устройство-сервер (mTLS, отзыв сертификатов, ротация ключей).
• Считать метрики ИБ (MTTD, MTTR, Precision/Recall) и защищать их перед комиссией.
• Оформлять диаграммы и ТЗ по ГОСТ 34/19, не теряя инженерный смысл.

Источник: Из-за атаки на Intoxalock автомобили с алкоблокираторами перестали заводиться (опубликовано 2026-03-25)