Опубликовано: 01.10.2026 | Источник: CNews (новости)

Перед вёрсткой — семантика, чтобы вы понимали, из чего собран текст: **Основной запрос:** выявление инвестиционного мошенничества в ВКР / антифрод-система для диплома. **LSI:** социальная инженерия, антифрод, машинное обучение, графовые модели, потоковая обработка, Kafka, Elasticsearch, OpenTelemetry, Prometheus, метрики качества классификации, ISO/IEC 25010, ГОСТ 34.602-89. **Вопросы студентов:** где брать датасет мошеннических сайтов; обязательно ли обучать нейросеть; как считать precision/recall в дипломе; нужен ли реальный код; как оформить ТЗ и схемы. **Сущности:** ГОСТ 34.602-89, ГОСТ 19.701-90, ISO/IEC 25010, Kubernetes, CI/CD-пайплайн, Neo4j, XGBoost, Grafana. ```html

Выявление инвестиционного мошенничества в ВКР: аналитическая глава, архитектура и метрики качества

Центр аналитики социальной инженерии и искусственного интеллекта в кибермошенничестве (ЦАСИ) опубликовал цифру, которая плохо ложится в новостной формат, зато отлично ложится в план диплома: почти 40% мошеннических схем в IV квартале 2025 года — это ложные инвестиционные предложения. Не «развод на доставке», не «мама, я попал в ДТП», а аккуратно свёрстанные лендинги с графиками доходности, личным кабинетом и «аналитиком», который ведёт клиента за руку к первому депозиту.

Почему это важно для выпускника ИТ-направления? Потому что защита от таких схем — это уже не про «написать правила модерации». Это про классификацию, графовые связи, потоковую обработку и измеримые метрики. Тема вашей работы перестаёт быть абстрактной, если в обосновании актуальности стоит конкретный отраслевой показатель, а в третьей главе — таблица с precision и recall вашей модели.

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

1. Система выявления фишинговых инвестиционных платформ на основе машинного обучения

• Актуальность. Доля инвестиционных схем растёт, а чёрные списки доменов устаревают быстрее, чем обновляются: средний срок жизни мошеннического лендинга — дни, иногда часы.
• Цель. Снизить число пропущенных мошеннических ресурсов при доле ложных срабатываний не выше 1%.
• Задачи: разобрать признаки (возраст домена, WHOIS-данные, цепочка сертификатов, ключевые слова и эмбеддинги текста), собрать и разметить датасет, обучить и сравнить модели, обернуть в REST-сервис, оценить метрики на отложенной выборке.
• Структура. Глава 1 — анализ методов и обзор источников; глава 2 — архитектура сервиса, схема данных, выбор стека; глава 3 — эксперименты, метрики, расчёт эффекта от внедрения.

2. Графовый анализ сетей мошеннических кампаний

• Актуальность. Мошенники работают кластерами: один владелец, один шаблон движка, общие счётчики аналитики. Статистика ЦАСИ как раз про массовость — а массовость удобно ловить графом, а не одиночной проверкой.
• Цель. Автоматически выделять связанные группы ресурсов, чтобы блокировка одного домена закрывала всю кампанию.
• Задачи: построить модель графа (домен — сертификат — IP — трекер — платёжный реквизит), реализовать алгоритм поиска сообществ, визуализировать кластеры, оценить качество разбиения.
• Структура. Глава 1 — теория графов в кибербезопасности; глава 2 — ETL-пайплайн и хранилище; глава 3 — оценка кластеризации и сценарии применения.

3. Платформа потокового мониторинга подозрительных лендингов

• Актуальность. Раз схема живёт часы, решение должно срабатывать минуты, а не на следующий день после выгрузки логов.
• Цель. Обнаружение нового подозрительного ресурса в пределах заданного времени реакции.
• Задачи: спроектировать потоковый конвейер, реализовать обогащение событий, совместить правила и модель, собрать дашборд, провести нагрузочное тестирование.
• Структура. Глава 1 — сравнительный анализ потоковых платформ; глава 2 — проектирование и развёртывание; глава 3 — нагрузка, отказоустойчивость, эксплуатационные метрики.

Аналитическая глава: чем обосновывать выбор решения

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

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

Проектная часть: что рисовать и что писать в ТЗ

Техническое задание по ГОСТ 34.602-89 — это не бюрократия, а каркас второй главы. Там уже есть пункты «требования к системе», «требования к видам обеспечения», «стадии разработки» — вам останется наполнить их своим содержимым. Схемы — по ГОСТ 19.701-90, иначе нормоконтроль вернёт работу с формулировкой, которую вы запомните надолго.

Минимальный набор диаграмм: контекстная схема (кто и как общается с системой), диаграмма компонентов, схема последовательности для сценария «новый домен → вердикт», модель данных. Если используете контейнеризацию — отдельная схема развёртывания в Kubernetes с указанием сервисов, хранилищ и очередей.

POST /api/v1/check
{
  "url": "https://example-invest.example",
  "features": {
    "domain_age_days": 4,
    "tls_issuer": "Let's Encrypt",
    "has_payment_form": true,
    "promised_yield_percent": 42
  }
}

200 OK
{
  "verdict": "suspicious",
  "score": 0.87,
  "reasons": ["young_domain", "yield_promise", "shared_tracker_id"]
}

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

Тестирование и метрики: где защищаются слабые места

Третья глава чаще всего проваливается не из-за кода, а из-за отсутствия цифр. Заранее зафиксируйте набор метрик и способ их получения.

Мониторинг описывайте через OpenTelemetry: трассировка запроса, метрики сервиса, логи. Дальше данные уезжают в Prometheus и визуализируются в Grafana. Пример запроса, который уместно вставить в приложение:

histogram_quantile(0.95,
  sum(rate(antifraud_request_duration_seconds_bucket[5m])) by (le)
)

Нагрузочное тестирование проводите минимум на двух профилях: пиковый поток регистраций доменов и массовая проверка батчем. Это даст материал для раздела «оценка эффективности» и заодно обоснование требований к железу.

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

• Обосновывать стек не вкусовщиной, а требованиями стандарта и профилем нагрузки.
• Строить пайплайн «данные → признаки → модель → сервис → мониторинг» целиком, а не фрагментом.
• Считать метрики качества так, чтобы они отвечали на вопрос заказчика, а не только на вопрос научрука.
• Оформлять ТЗ, схемы и приложения по ГОСТ без переделок в последнюю неделю.
• Разделять продуктовые и эксплуатационные риски: дрейф модели, деградация задержек, отказ хранилища.

Типичные ошибки студентов

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

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

Зависит от требований кафедры, но работоспособный прототип почти всегда усиливает защиту. Достаточно минимального сервиса с одной моделью и одним эндпоинтом — важно, чтобы его можно было запустить и показать метрики.

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

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

Насколько сложна такая тема для студента?

Средний уровень. Ключевая сложность не в модели, а в инфраструктуре: сбор данных, воспроизводимость экспериментов, оформление. Если сократить объём до одной модели и одного сценария, работа спокойно укладывается в стандартный срок.

Как оформить UML и схемы архитектуры?

Диаграммы компонентов и последовательностей — в нотации UML, схемы процессов и данных — по ГОСТ 19.701-90. Подписи к рисункам обязательны, а каждая схема должна упоминаться в тексте до того, как она появилась.

Что проверить перед сдачей

Источник: Почти 40% мошеннических схем в IV квартале 2025 года составили ложные инвестиционные предложения (опубликовано 2026-03-26)

```