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

Социальная инженерия через «Госуслуги» в ВКР: модель угроз и защитные сценарии

Поддомен: Cybersecurity  |  Роль эксперта: Специалист по информационной безопасности

Введение: почему кейс из Владивостока — это готовая тема ВКР

В марте 2026 года произошёл случай, который должен быть в учебниках по ИБ: жительница Москвы прилетела во Владивосток, чтобы по указанию «сотрудника ФСБ» вскрыть чужой сейф. Итог — уголовное дело и семья, потерявшая 15 миллионов рублей. Схема развода опиралась на «Госуслуги» — легитимный сервис, вызывающий у граждан доверие. Именно это доверие и стало уязвимостью.

Для выпускника направления «Информационная безопасность» здесь спрятана не одна, а три-четыре защищаемые темы. Социальная инженерия перестала быть «про разговоры по телефону» — это многоэтапная атака с использованием легитимных цифровых сервисов, ролевого давления и логистики. И если вы хотите заказать диплом, где будет не «вода» про актуальность, а живая модель угроз — этот кейс отличный стартовый материал.

FAQ: что чаще всего спрашивают студенты по этой теме

Мне обязательно проводить реальные эксперименты с людьми, чтобы доказать эффективность защиты?

Нет. Достаточно имитационного моделирования в изолированной среде: сценарии MITRE ATT&CK маппятся на тестовый стенд (например, Keycloak + mock-портал), а метрики (TTD, FPR) снимаются с SIEM. Эксперимент с реальными пользователями требует одобрения этического комитета — в ВКР это избыточно.

Где брать статистику по социальной инженерии для главы 1?

Источники: отчёты ЦБ РФ по кибермошенничеству, статистика МВД, отчёт Verizon DBIR, база MITRE ATT&CK. Дополнительно — открытые данные SecurityLab, Positive Technologies, BI.ZONE. Обязательно указывайте дату выгрузки — данные устаревают каждый квартал.

Какой стек выбрать для реализации?

Зависит от темы: для UEBA — Python + Elastic Stack; для оценки защищённости — GoPhish + кастомный парсер; для архитектурной модели — C4-диаграммы + PlantUML. Не гонитесь за модой: если обоснуете выбор по ISO/IEC 25010, комиссия оценит это выше, чем «мы взяли Kubernetes, потому что модно».

Как считать эффективность защиты без реальных атак?

Через пары метрик: FPR/FNR детектора, Time-to-Detect и Time-to-Respond на синтетическом потоке событий, доля заблокированных сценариев из заранее выбранного подмножества MITRE ATT&CK. Всё это воспроизводимо и проверяемо — в отличие от «мы поговорили с экспертами».

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

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

Глава 1. Аналитическая: превращаем новость в формализованный кейс

Не пересказывайте статью — декомпозируйте её. Схема «жертва → лжесотрудник ФСБ → инструкции → поездка → вскрытие сейфа» отлично раскладывается на цепочку MITRE ATT&CK: Reconnaissance (OSINT по жертве) → Initial Access (телефонный контакт) → Execution (убеждение выполнить действия) → Impact (доступ к активам).

Что построить:

• UML Sequence Diagram — пошаговое взаимодействие злоумышленника, жертвы и легитимного сервиса.
• Диаграмму «kill chain» по Lockheed Martin — покажет, где можно «разорвать» атаку.
• Таблицу соответствия «этап атаки → техника MITRE ATT&CK → возможная контрмера».

Обязательно сосласться на ГОСТ 34.601-90 — он задаёт стадийность анализа требований к системе защиты, и комиссия это любит. А для оценки качества будущей системы — ISO/IEC 25010 (функциональная пригодность, защищённость, удобство использования).

Глава 2. Проектирование и реализация: что показать комиссии

Здесь важно не «нарисовать красиво», а доказать воспроизводимость. Пример — фрагмент правила корреляции для SIEM (Sigma), которое ловит сценарий «всплеск чувствительных операций после смены пароля», типичный для этого кейса:

title: Suspicious post-password-change activity on Government Portal
id: 7c3e-...-a91b
status: experimental
logsource:
  product: gosuslugi_portal
  service: audit
detection:
  change:
    event: "password_changed"
  suspicious:
    event:
      - "document_download"
      - "profile_export"
      - "session_from_new_geo"
  timeframe: 30m
  condition: change | followed by suspicious by user_id
level: high
tags:
  - attack.t1078
  - attack.t1530
falsepositives:
  - "Legitimate user re-login after password reset"

Что ещё приложить к главе: C4-диаграмму контекста и контейнеров, схему потоков данных (DFD) с границами доверия, BPMN-схему процесса верификации входящего обращения «из ведомства». И — конфиг OpenTelemetry для сбора событий входа:

receivers:
  otlp:
    protocols: { grpc: {}, http: {} }
processors:
  attributes/portal:
    actions:
      - key: service.name
        value: gosuslugi-portal
        action: upsert
exporters:
  elasticsearch:
    endpoints: ["https://siem.local:9200"]
service:
  pipelines:
    logs:
      receivers: [otlp]
      processors: [attributes/portal]
      exporters: [elasticsearch]

Глава 3. Оценка эффективности: метрики вместо «мы сделали»

Вводите как минимум две группы метрик:

• Детектор: Precision, Recall, FPR, FNR — на размеченном датасете синтетических событий.
• Процесс: TTD (Time-to-Detect), TTR (Time-to-Respond), доля покрытых техник из подмножества MITRE ATT&CK.

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

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

• Строить модель угроз и валидировать её по MITRE ATT&CK и OWASP.
• Проектировать детектирующие правила и настраивать конвейер логов (OpenTelemetry → SIEM).
• Оформлять архитектурные диаграммы (C4, UML, DFD) и согласовывать их с ГОСТ 34.
• Считать метрики эффективности и защищать цифры на защите.
• Различать «человеческий фактор» и «технические контрмеры» — и обосновывать баланс между ними.

Чек-лист «Что проверить перед сдачей»

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

Источник: Москвичка прилетела во Владивосток, чтобы вскрыть чужой сейф по приказу «ФСБ». Теперь ей грозит срок (опубликовано 2026-03-24)