Тестирование обновлений безопасности по методике ФСТЭК от 28.10.2022

1. Почему нельзя просто нажать «Обновить»

Методика ФСТЭК от 28 октября 2022 года — это практический инструмент защиты от атак на цепочку поставок (Supply Chain Attacks). Цель методики (пункт 2.1) — своевременное выявление в обновлениях потенциально опасных функциональных возможностей и недекларированных разработчиком возможностей (НДВ).

  graph TB
    subgraph "Атаки на цепочку поставок"
        A1["Компрометация репозитория<br/>разработчика<br/>(SolarWinds, 2020)"]
        A2["Подмена обновления<br/>на этапе скачивания<br/>(MITM-атака)"]
        A3["Внедрение вредоносного<br/>кода в open-source<br/>библиотеки"]
        A4["Политические баннеры<br/>и НДВ в зарубежном ПО"]
    end
    
    subgraph "Методика ФСТЭК от 28.10.2022"
        M1["6 обязательных тестов<br/>Т001–Т006"]
        M2["Среда тестирования:<br/>стенд / песочница"]
        M3["Принятие решения:<br/>🟢 Зелёный / 🟡 Жёлтый / 🔴 Красный"]
        M4["Отчётность:<br/>форма ФСТЭК + НКЦКИ"]
    end
    
    A1 --> M1
    A2 --> M1
    A3 --> M1
    A4 --> M1
    
    style A1 fill:#c62828,color:#fff
    style A2 fill:#c62828,color:#fff
    style A3 fill:#c62828,color:#fff
    style A4 fill:#c62828,color:#fff

Комментарий эксперта

Игорь Краев: «Методика применяется в первую очередь к обновлениям безопасности — тем, которые закрывают уязвимости. Но по решению оператора можно тестировать и любые другие. Особый контроль — за критическими обновлениями: если патч закрывает уязвимость уровня RCE, он должен пройти все шесть тестов. Игнорировать эту методику нельзя: Приказ № 117 (пункт 39) прямо запрещает бесконтрольную установку обновлений».


2. Среда тестирования и инструменты

  graph TB
    subgraph "Среда тестирования (п. 2.6)"
        ENV1["Исследовательский стенд<br/>Отдельный «железный»<br/>или виртуальный стенд"]
        ENV2["Тестовая зона<br/>Изолированный сегмент<br/>инфраструктуры"]
        ENV3["Продуктивная среда<br/>⚠️ Только в крайнем случае"]
    end
    
    subgraph "Инструменты (п. 2.7)"
        T1["Антивирусы<br/>Не менее 2 разных<br/>вендоров"]
        T2["Сканеры уязвимостей<br/>Сигнатурный поиск"]
        T3["Снифферы<br/>Wireshark, tcpdump"]
        T4["Песочницы<br/>Cuckoo Sandbox, CAPE"]
    end
    
    ENV1 --> T1
    ENV1 --> T2
    ENV1 --> T3
    ENV1 --> T4
    
    style ENV1 fill:#2e7d32,color:#fff
    style ENV2 fill:#f57f17,color:#fff
    style ENV3 fill:#c62828,color:#fff

Требования к инструментам:

  • Российские или Open Source (без ограничений на территории РФ).
  • Антивирусы — не менее двух разных вендоров.
  • Все инструменты должны быть установлены и настроены до начала тестирования.

Комментарий эксперта

Игорь Краев: «Создайте эталонный снапшот виртуальной машины до установки обновления. Это позволит легко откатиться и сравнить состояние системы “до” и “после”. Тестирование в продуктивной среде — исключение; оно допустимо, только если нет технической возможности развернуть стенд. Но в отчёте это должно быть обосновано».


3. Шесть обязательных тестов (Т001–Т006)

  graph LR
    T001["<b>Т001</b><br/>Сверка<br/>идентичности"]
    T002["<b>Т002</b><br/>Проверка<br/>подлинности"]
    T003["<b>Т003</b><br/>Антивирусный<br/>контроль"]
    T004["<b>Т004</b><br/>Поиск опасных<br/>конструкций"]
    T005["<b>Т005</b><br/>Мониторинг<br/>активности"]
    T006["<b>Т006</b><br/>Ручной<br/>анализ"]
    
    T001 --> T002 --> T003 --> T004 --> T005
    T005 -->|"При аномалиях"| T006
    T003 -->|"Обнаружены угрозы"| T006
    T004 -->|"Обнаружены конструкции"| T006
    
    style T001 fill:#1a237e,color:#fff
    style T006 fill:#c62828,color:#fff

3.1. Т001 — Сверка идентичности (п. 3.2)

Цель: Защита от подмены обновления на этапе скачивания.

  graph LR
    subgraph "Тест Т001"
        S1["Скачать обновление<br/>с российского IP"]
        S2["Скачать обновление<br/>из международного<br/>сегмента (через VPN)"]
        S3["Рассчитать<br/>контрольные суммы<br/>(MD5, SHA-256, ГОСТ 34.11)"]
        S4["Сравнить хеши"]
    end
    
    S1 --> S3
    S2 --> S3
    S3 --> S4
    
    S4 -->|"Хеши совпадают"| PASS["✅ Т001 пройден"]
    S4 -->|"Хеши различаются"| FAIL["🔴 Т001 не пройден<br/>→ Т006 ручной анализ"]
    
    style PASS fill:#2e7d32,color:#fff
    style FAIL fill:#c62828,color:#fff

Пример вывода в отчёте:

«Проведена сверка контрольных сумм обновления, полученного с сайта разработчика (RU IP) и с зеркала в Европе. Хеши SHA-256 идентичны: a1b2c3d4e5f6.... Тест Т001 пройден успешно».


3.2. Т002 — Проверка подлинности (п. 3.3)

Цель: Подтверждение, что обновление действительно выпущено заявленным разработчиком.

  graph LR
    subgraph "Тест Т002"
        P1["Распаковать/расшифровать<br/>файлы обновления"]
        P2["Проверить ЭЦП<br/>или контрольные суммы<br/>от разработчика"]
        P3["Сравнить с данными<br/>на официальном сайте"]
    end
    
    P1 --> P2 --> P3
    
    P3 -->|"Подпись подтверждена"| PASS2["✅ Т002 пройден"]
    P3 -->|"Подпись не проверена"| WARN["🟡 Потенциально опасно<br/>→ Т006 ручной анализ"]
    
    style PASS2 fill:#2e7d32,color:#fff
    style WARN fill:#f57f17,color:#fff

Комментарий эксперта

Игорь Краев: «Если разработчик не предоставил средств проверки подлинности — тест автоматически получает “жёлтый” уровень. В отчёте это нужно отразить как “подлинность не проверена”. Типичная ситуация: вендор выкладывает патч, но без файла контрольных сумм. Это сразу понижает уровень доверия и требует ручного анализа Т006».


3.3. Т003 — Антивирусный контроль (п. 3.4)

  graph TB
    subgraph "Тест Т003"
        AV1["Проверить файлы обновления<br/>не менее чем 2 антивирусами<br/>разных разработчиков"]
        AV2["Установить обновление<br/>на стенд"]
        AV3["Выполнить полное сканирование<br/>ОЗУ, файловой системы,<br/>загрузочных секторов"]
    end
    
    AV1 --> AV2 --> AV3
    
    AV3 -->|"Угроз не обнаружено"| PASS3["✅ Т003 пройден"]
    AV3 -->|"Обнаружены угрозы"| FAIL3["🔴 Т003 не пройден<br/>→ Т006 ручной анализ"]
    
    style PASS3 fill:#2e7d32,color:#fff
    style FAIL3 fill:#c62828,color:#fff

Пример вывода в отчёте:

«Файлы обновления проверены антивирусными средствами Kaspersky и Dr.Web: угроз не обнаружено. После установки патча проведено полное сканирование системы: вредоносная активность не выявлена. Тест Т003 пройден успешно».


3.4. Т004 — Поиск опасных конструкций (п. 3.5)

  graph LR
    subgraph "Тест Т004"
        Y1["Поиск индикаторов<br/>компрометации (IOC)<br/>по базам Threat Intelligence"]
        Y2["Проверка YARA-правилами<br/>на известные вредоносные<br/>паттерны"]
        Y3["Контекстный поиск:<br/>политические лозунги,<br/>баннеры, призывы"]
    end
    
    Y1 --> Y2 --> Y3
    
    Y3 -->|"Ничего не найдено"| PASS4["✅ Т004 пройден"]
    Y3 -->|"Найдены конструкции"| FAIL4["🔴 Т004 не пройден<br/>→ Т006 ручной анализ"]
    
    style PASS4 fill:#2e7d32,color:#fff
    style FAIL4 fill:#c62828,color:#fff

Комментарий эксперта

Игорь Краев: «Методика явно упоминает поиск политических баннеров и лозунгов. Это ответ на инциденты с “закладками” в зарубежном ПО, которые активируются по команде. Даже если код не вирусный, но содержит скрытый баннер или призыв — это уже НДВ. Рекомендую использовать автоматизированные YARA-сканеры и регулярно обновлять базы Threat Intelligence».


3.5. Т005 — Мониторинг активности (п. 3.6)

Самый показательный тест. Даже если антивирус молчит, поведение программы может выдать закладку.

  graph TB
    subgraph "Тест Т005: План мониторинга"
        M1["Анализ системных вызовов<br/>exec(), fopen(), socket()"]
        M2["Анализ сетевого трафика<br/>Не стучится ли в «левые» IP<br/>(особенно зарубежные)"]
        M3["Сравнение файловой системы<br/>«до» и «после» установки"]
        M4["Сигнатурный поиск уязвимостей<br/>Закрыл ли патч заявленную<br/>уязвимость? Не открыл ли новые?"]
    end
    
    M1 --> M2 --> M3 --> M4
    
    M4 -->|"Аномалий нет"| PASS5["✅ Т005 пройден"]
    M4 -->|"Обнаружены аномалии"| FAIL5["🔴 Т005 не пройден<br/>→ Т006 ручной анализ"]
    
    style PASS5 fill:#2e7d32,color:#fff
    style FAIL5 fill:#c62828,color:#fff

Пример вывода (негативный):

«В ходе мониторинга сетевой активности обновлённого ПО выявлено обращение к недокументированному IP-адресу 203.0.113.55. Признак потенциально опасной активности. Тест Т005 требует ручного анализа Т006».


3.6. Т006 — Ручной анализ (п. 3.7)

Ручной анализ обязателен в следующих случаях:

СитуацияДействие
Различия в хешах из разных источниковТ001 не пройден
Не пройдена проверка подлинностиТ002 — жёлтый/красный
Обнаружены признаки вредоносной активностиТ003 — красный
Обнаружены опасные конструкцииТ004 — красный
Выявлены аномалии сетевой/файловой активностиТ005 — красный
Тестируется ПО с открытым кодомОбязателен всегда

Методы ручного анализа:

  • Дизассемблирование и декомпиляция бинарного кода.
  • Отладка и трассировка в изолированной среде.
  • Статический и динамический анализ исходного кода (для open source).
  • Поиск ключевой информации (паролей, токенов) в обновлении.

Комментарий эксперта

Игорь Краев: «Критически важно: если ручной анализ провести невозможно — нет специалистов, нет инструментов — исследователь обязан сделать вывод о наличии признаков НДВ. То есть логика такая: “не знаю, что внутри, но ставить нельзя”. Для значимых объектов КИИ это означает, что обновление не будет установлено до получения квалифицированного заключения».


4. Оформление результатов и принятие решения

4.1. Форма отчёта о тестировании (п. 4.2)

Наименование тестаРезультатОписание
Т001УспешноХеши из 2 источников совпали
Т002УспешноЭЦП разработчика подтверждена
Т003УспешноKaspersky + Dr.Web угроз не нашли
Т004УспешноYARA-правила не сработали
Т005УспешноАномалий сетевой активности нет
Т006—Не требовался
ВердиктОбновление безопасно. Установка возможна.

4.2. Правила принятия решения («Светофор»)

  graph TB
    subgraph "Приложение №1 к Методике"
        G["🟢 ЗЕЛЁНЫЙ<br/><b>Обновление безопасно</b><br/>Все тесты пройдены,<br/>опасных конструкций нет"]
        Y["🟡 ЖЁЛТЫЙ<br/><b>Потенциально опасно</b><br/>Можно установить<br/>при определённых<br/>ограничениях"]
        R["🔴 КРАСНЫЙ<br/><b>Установка не рекомендуется</b><br/>Выявлены НДВ, вирусы,<br/>закладки"]
    end
    
    G --> ACTION_G["Установка<br/>разрешена"]
    Y --> ACTION_Y["Установка с<br/>компенсирующими мерами<br/>(ACL, сегментирование)"]
    R --> ACTION_R["Сообщить в НКЦКИ<br/>(п. 3.7.5)<br/>Установка запрещена"]
    
    style G fill:#2e7d32,color:#fff
    style Y fill:#f57f17,color:#fff
    style R fill:#c62828,color:#fff

Пример решения для «Жёлтого» уровня:

«Обновление может быть установлено только на серверы, не имеющие выхода в сеть Интернет, и после дополнительной настройки ACL на межсетевом экране».


5. Отправка отчёта

Отчёты о тестировании можно направлять в ФСТЭК на адрес webmaster@bdu.fstec.ru (пункт 4.4 Методики). Это не обязательное требование для каждого обновления, но рекомендуется для критических патчей.


Как «Стратегия Ра» помогает с тестированием обновлений

Мы выполняем полный цикл работ:

  • Развёртывание среды тестирования. Настраиваем изолированный стенд или тестовую зону в вашей инфраструктуре.
  • Проведение тестов Т001–Т006. Выполняем все 6 тестов, включая ручной анализ (Т006) с применением дизассемблеров и отладчиков.
  • Оформление отчёта по форме ФСТЭК. Готовим полный комплект документов с выводами по каждому тесту и итоговым вердиктом.
  • Разработка Регламента управления обновлениями. Внедряем процесс тестирования обновлений как часть системы управления ИБ.

Приглашаем к диалогу

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


Материал подготовлен на основе лекций и практических кейсов Игоря Краева, генерального директора ООО «Стратегия Ра», апрель 2026 г.