Опубликовано: 03.10.2026 | Источник: SecurityLab (RSS)

Ниже — семантический анализ, затем готовый HTML-фрагмент. **Семантический анализ** 1. **Primary keyword:** анализ цепочек эксплойтов iOS для ВКР 2. **LSI:** мобильная безопасность, эксплойт-кит, 0-day, sandbox escape, kernel exploit, WebKit RCE, MITRE ATT&CK, STRIDE-моделирование угроз, SAST/DAST, фаззинг, YARA-правила, CVE/NVD, ISO/IEC 25010, OpenTelemetry, CI/CD-пайплайн, ГОСТ 34.602-89 3. **Вопросы студентов:** Нужен ли реальный iPhone для стенда? Обязательно ли писать код в ВКР по ИБ? Где брать датасет уязвимостей? Как измерить «защищённость» числом? Как оформить ТЗ по ГОСТ 34? 4. **Сущности:** ГОСТ 34.602-89, ГОСТ 19.201-78, ISO/IEC 25010, MITRE ATT&CK, CVE/NVD, OpenTelemetry, CI/CD ```html

Анализ цепочек эксплойтов iOS для ВКР: от CVE-датасетов до измеримых метрик защищённости

В марте 2026 года «Лаборатория Касперского» сообщила: в коде набора Coruna найдены следы, роднящие его с печально известной «Триангуляцией». Речь о 23 эксплойтах, покрывающих iOS от 13.0 до 17.2.1 — то есть почти пять лет релизов. Для выпускника ИТ-направления это не просто новость, а готовый полигон для ВКР: перед вами длинная, документированная цепочка атак, где есть что декомпозировать, моделировать и измерять. Тема удобна тем, что не требует «изобретать» предметную область: эксплойт-кит уже структурирован по стадиям, у каждой стадии есть тактика из MITRE ATT&CK, а значит — есть что положить в аналитическую главу и чем обосновать практическую часть.

Три темы ВКР, которые вырастают из этой новости

Тема 1. Модель угроз мобильной платформы на основе разбора цепочки Coruna

Актуальность: инцидент показывает, что эксплуатация строится не на одной уязвимости, а на связке: доставка → обход песочницы → повышение привилегий в ядре. Это классический кейс для STRIDE-моделирования.

Цель: построить формализованную модель угроз для корпоративного парка iOS-устройств и оценить остаточный риск.

• задачи: собрать и нормализовать данные по CVE из диапазона 13.0–17.2.1;
• сопоставить стадии цепочки с тактиками MITRE ATT&CK Mobile;
• разработать STRIDE-модель и матрицу «актив — угроза — контроль»;
• рассчитать остаточный риск до и после внедрения контрмер.

Структура: Глава 1 — анализ мобильных угроз и обзор методов моделирования; Глава 2 — проектирование модели и выбор нотации (DFD, диаграммы атак); Глава 3 — экспериментальная проверка на выборке CVE и оценка эффективности контрмер.

Тема 2. Автоматизированный конвейер анализа эксплойт-китов (SAST + YARA + CI/CD)

Актуальность: ручной разбор 23 эксплойтов — это недели работы аналитика. Автоматизация детектирования по сигнатурам и поведенческим признакам — прямая потребность SOC.

Цель: спроектировать и реализовать конвейер, который принимает образец, прогоняет статический и динамический анализ и выдаёт отчёт с оценкой по ISO/IEC 25010.

• задачи: спроектировать архитектуру конвейера и схему хранения артефактов;
• разработать набор YARA-правил для признаков семейства;
• встроить проверки в CI/CD-пайплайн с порогом качества;
• оценить ложноположительные срабатывания на контрольной выборке.

Структура: Глава 1 — обзор инструментов анализа ВПО; Глава 2 — архитектура конвейера, схемы, форматы обмена; Глава 3 — нагрузочное тестирование, метрики точности, экономика внедрения.

Тема 3. Сравнительный анализ методов защиты iOS-парка и оценка TCO

Актуальность: если эксплойты живут годами в разных версиях ОС, встаёт вопрос: что дешевле — ускоренный цикл обновлений или изоляция и мониторинг?

Цель: сравнить MDM-решения и архитектурные подходы (изоляция, zero-trust, телеметрия) по совокупной стоимости владения.

• задачи: сформировать критерии сравнения и веса;
• провести многокритериальную оценку альтернатив;
• рассчитать TCO на горизонте 3 лет;
• обосновать рекомендацию для организации среднего размера.

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

Аналитическая глава: как превратить одну новость в обзор рынка решений

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

Отдельно обоснуйте стек. Типовая ошибка — перечислить инструменты без критериев. Заведите таблицу «критерий → вес → источник данных» и ссылайтесь на ISO/IEC 25010: функциональная полнота, производительность, безопасность, сопровождаемость. Так у вас появится формальное основание выбора, а не вкусовщина.

Проектная часть: схемы, алгоритмы и где здесь настоящая инженерия

Если вы делаете конвейер (Тема 2), начните с архитектурной схемы в нотации C4: контекст, контейнеры, компоненты. Ключевые элементы — приёмник образцов, очередь, воркеры анализа, хранилище артефактов, генератор отчётности. Затем опишите алгоритм приоритизации образцов: не всё нужно гонять через динамический анализ, часть отсекается статикой. Пример псевдокода порога качества для пайплайна:

quality_gate:
  precision_threshold: 0.92
  max_false_positive_rate: 0.08
  max_scan_time_sec: 180
  on_fail: block_merge, notify_security_team

В проектной главе обязательно покажите поток данных между модулями и точки отказа. Именно здесь пригодится ISO/IEC 25010: вы декларируете, что делаете систему не «просто работающую», а соответствующую заявленным характеристикам качества. И ссылка на инцидент с Coruna уместна как источник требований: «система должна обрабатывать выборку не менее 20 образцов за прогон» — цифра берётся из публичного описания кейса.

Тестирование и метрики: без чисел диплом не защищается

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

• Качество детектирования: precision, recall, F1, доля ложных срабатываний на чистой выборке.
• Производительность: время обработки одного образца, пропускная способность, потребление памяти, p95 и p99 задержки.
• Эксплуатация: RTO и RPO для хранилища артефактов, время восстановления после сбоя воркера, покрытие мониторингом.

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

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

• работать с публичными источниками угроз: CVE, отчёты вендоров, базы MITRE ATT&CK — и не тонуть в них;
• проектировать архитектуру по нотациям C4 и DFD, а не «на словах»;
• обосновывать выбор стека через измеримые критерии, а не через «популярность»;
• собирать телеметрию и защищать численные результаты перед комиссией;
• оформлять ТЗ и пояснительную записку в соответствии с ГОСТ 34.602-89 и ГОСТ 19.201-78.

Вопросы, которые задают чаще всего

Нужен ли реальный iPhone и настоящий образец вредоносного ПО?

Нет. Для ВКР достаточно публичных данных: описания CVE, отчёты вендоров, синтетические или обезвреженные образцы. Реальный стенд — плюс, но не обязательное условие. Юридически безопаснее работать с открытыми датасетами и документацией.

Обязательно ли писать код?

Зависит от формулировки темы. Для «аналитических» тем достаточно прототипа скриптов и конфигураций. Для «проектных» — нужен работающий модуль. Практика показывает: наличие даже небольшого, но рабочего артефакта заметно повышает защищаемость работы.

Где брать данные для расчётов?

Открытые базы CVE/NVD, публичные отчёты исследовательских команд, документация вендоров. Дополнительно — собственная разметка небольшой выборки: 50–100 записей уже дают статистику, пригодную для выводов.

Как оформить диаграммы, чтобы их приняли?

Используйте распространённые нотации: C4 для архитектуры, DFD для потоков данных, UML для классов и последовательностей. Каждая диаграмма — с легендой и ссылкой в тексте. Не забывайте про нумерацию рисунков и список обозначений.

Источник: Старые знакомые в новом iPhone. «Лаборатория Касперского» нашла ДНК «Триангуляции» в коде Coruna (опубликовано 2026-03-26)

```