Опубликовано: 21.09.2026 | Источник: The Verge – Tech Section

Анализ безопасности потребительских IoT-роутеров для ВКР: от цепочки поставок до Zero Trust

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

Частые вопросы студентов по теме

Три темы ВКР, которые можно собрать из кейса FCC

• «Методика оценки рисков цепочки поставок сетевого оборудования».
  Актуальность: регуляторные ограничения на foreign-made устройства меняют модель угроз закупок.
  Цель: разработать процедуру оценки риска поставщика и прошивки.
  Задачи: 1) обзор угроз по OWASP IoT Top 10; 2) построение модели угроз STRIDE для трёх классов устройств; 3) SBOM-инвентаризация; 4) расчёт интегрального риска.
  Структура: Гл. 1 — теория угроз и стандарты (ISO/IEC 27001, 25010); Гл. 2 — проектирование матрицы рисков и скриптов сбора данных; Гл. 3 — эксперимент на стенде и оценка эффективности.
• «Zero Trust в сегменте домашней/малой офисной сети».
  Актуальность: доверие к периметру падает — это прямое следствие сюжета со «сторонними» роутерами.
  Цель: спроектировать сегментацию и политики доступа без доверия к устройству по умолчанию.
  Задачи: 1) анализ моделей доверия; 2) проектирование микросегментации (VLAN, ACL, 802.1X); 3) конфигурации и тесты; 4) метрики покрытия политиками.
  Структура: Гл. 1 — Zero Trust и сетевой доступ; Гл. 2 — архитектура (C4 + UML deployment); Гл. 3 — проверка на стенде, MTTR и число нарушений политик.
• «Непрерывный мониторинг уязвимостей прошивок IoT».
  Актуальность: обновления прошивок — узкое место, а регуляторные реестры лишь фиксируют проблему.
  Цель: построить конвейер сопоставления инвентаря с NVD и оповещения.
  Задачи: 1) обзор источников данных; 2) реализация сборщика (Python + API); 3) хранение и дедупликация CVE; 4) метрики MTTP и покрытия.
  Структура: Гл. 1 — управление уязвимостями, CVSS; Гл. 2 — архитектура сервиса и схема БД; Гл. 3 — нагрузочные тесты и оценка полноты обнаружения.

Как встроить материал статьи в главы работы

Глава 1: анализ и постановка задачи

Сюжет о покрытом списке FCC — это не «пример из новостей», а обоснование проблемы: технические решения перестают быть чисто техническими, когда появляются регуляторные ограничения и вопросы доверия к поставщику. В первой главе уместно дать обзор стандартов и практик: ISO/IEC 27001 (управление рисками ИБ), ISO/IEC 25010 (характеристики качества), OWASP IoT Top 10. Здесь же строится модель угроз. Простой DFD-набросок:

Внешние угрозы
    |
    v
[Интернет] --(WAN)--> [Роутер] --(LAN/Wi-Fi)--> [Клиенты IoT]
                          |
                          +--(Прошивка вендора, обновления)
                          +--(Цепочка поставок, прошивка OEM)
                          +--(Облачный сервис управления)

Для модели угроз используйте STRIDE: спуфинг, подмена данных, отказ в обслуживании, повышение привилегий. Каждую угрозу свяжите с конкретным компонентом и контролем — это снимет половину вопросов на защите.

Глава 2: проектирование и реализация

Здесь появляются артефакты: диаграмма развёртывания (UML deployment), схема сети по ГОСТ, конфигурации и скрипты. Простейший инвентаризатор прошивок, который сопоставляет версии с NVD и формирует отчёт, выглядит так:

# firmware_audit.py — сопоставление прошивок с NVD по CPE
import json, requests
from datetime import datetime

NVD = "https://services.nvd.nist.gov/rest/json/cves/2.0"

def lookup(cpe: str, version: str) -> list:
    r = requests.get(NVD, params={
        "cpeName": f"{cpe}:{version}",
        "resultsPerPage": 50
    }, timeout=20)
    r.raise_for_status()
    out = []
    for item in r.json().get("vulnerabilities", []):
        cve = item["cve"]
        metrics = cve.get("metrics", {})
        cvss = next(iter(metrics.values()), [{}])[0].get(
            "cvssData", {}).get("baseScore", "n/a")
        out.append({"id": cve["id"], "cvss": cvss,
                    "published": cve["published"][:10]})
    return out

if __name__ == "__main__":
    report = {"generated": datetime.utcnow().isoformat(),
              "devices": []}
    with open("inventory.json", encoding="utf-8") as f:
        for dev in json.load(f):
            report["devices"].append({
                "model": dev["model"],
                "firmware": dev["firmware"],
                "cves": lookup(dev["cpe"], dev["firmware"])
            })
    print(json.dumps(report, ensure_ascii=False, indent=2))

Дополнительно приложите SBOM в формате CycloneDX или SPDX — это подтверждает, что вы умеете работать с составом программного обеспечения, а не только «сканировать порты». Конфигурацию самого роутера удобно описывать чек-листом в YAML:

# router_hardening.yml
wifi:
  security: WPA3-Personal
  wps: disabled
  guest_network: isolated
admin:
  default_credentials_changed: true
  remote_management: disabled
  firmware_auto_update: true
services:
  upnp: disabled
  telnet: disabled
  ssh:
    enabled: true
    password_auth: false
logging:
  syslog_forward: "192.168.10.20:514"

Глава 3: тестирование и оценка эффективности

Минимальный набор метрик, который комиссия примет без споров:

Для сбора первичных данных подойдёт связка nmap и jq — этого достаточно для дипломного эксперимента:

nmap -sV -Pn -p- 192.168.10.0/24 -oX scan.xml
xmlstarlet sel -t -m "//port[state/@state='open']" \
  -v "concat(../address/@addr, ':', @portid, '/', @protocol)" -n scan.xml

Чему вы научитесь в процессе

• Строить модель угроз (STRIDE) и связывать её с конкретными контролями по ISO/IEC 27001.
• Работать с NVD, CVSS и SBOM как с инженерными артефактами, а не «теорией из лекций».
• Проектировать сегментацию и политики Zero Trust для сети с недоверенными устройствами.
• Оформлять схемы (C4, UML deployment, DFD) и ТЗ с учётом ГОСТ 34.601.
• Считать метрики эффективности так, чтобы цифры были воспроизводимы и защищаемы.

Источник: The United States router ban, explained (опубликовано 2026-03-25)