Курсовая по информационной безопасности в МФТИ: модель угроз, стенд и проверка защиты без выдуманной программы

Запрос «курсовая по информационной безопасности в МФТИ» требует аккуратности с названием программы. В перечне базового приёма МФТИ на 2026 год отдельные направления группы 10.xx не указаны. При этом Высшая школа программной инженерии МФТИ ведёт образовательную траекторию по кибербезопасности, где изучаются программирование, системы, реверс-инжиниринг и безопасность.

Официальные страницы:
https://pk.mipt.ru/bachelor/2026_rules/
https://hsse.mipt.ru/bachelor/cybersecurity

Поэтому в курсовой нужно указывать реальное название своей программы и дисциплины, а слово «информационная безопасность» использовать как предметную область.

Начните не с атаки, а с актива

Что защищается?

• dataset;
• аккаунт;
• API;
• сервер;
• исходный код;
• лабораторная система;
• модель;
• сеть.

Без актива список угроз становится бессмысленным.

Security properties

Определите, что важнее:

• confidentiality;
• integrity;
• availability.

Для research dataset и системы управления приоритеты могут отличаться.

Граница доверия

Нарисуйте архитектуру.

Например:

internet -> reverse proxy -> API -> DB.

Отметьте места перехода trust boundary.

Именно там возникают многие угрозы.

Модель нарушителя

Укажите:

• внешний;
• внутренний;
• авторизованный пользователь;
• уровень знаний;
• доступ;
• цель.

Не используйте абстрактного всемогущего злоумышленника.

Threat modeling

Можно использовать STRIDE, attack tree или иной метод.

Главное - применять его к конкретной системе.

Не вставляйте список SQL injection, XSS и DDoS без связи с архитектурой.

Risk

Для каждой угрозы:

• вероятность;
• ущерб;
• мера;
• остаточный риск.

Если используется шкала 1-5, объясните критерии.

Не подгоняйте оценки.

Учебный стенд

Все проверки проводите только на своей системе, CTF или явно разрешённом стенде.

Курсовая не требует атаковать чужие ресурсы.

Аутентификация

Проверьте:

• хранение пароля;
• login;
• session;
• reset.

Не храните пароль plaintext.

Используйте password hashing.

Password hashing

Специализированные алгоритмы специально замедлены.

Покажите salt и cost.

Обычный SHA-256 не является полноценной схемой хранения паролей.

MFA

Если риск оправдывает, добавьте второй фактор.

Но MFA не исправляет broken authorization.

Каждая мера решает свой класс угроз.

Авторизация

Создайте тест:

user A запрашивает объект user B.

Ожидаемо:

403 или отсутствие доступа.

IDOR часто проще и опаснее сложной криптографии.

RBAC

Матрица ролей:

• read;
• write;
• approve;
• admin.

Права должны проверяться сервером.

Least privilege

Приложение не должно подключаться к БД root-пользователем.

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

Это хороший демонстрационный пример.

Secret management

Не коммитьте token, private key и password.

Проверьте историю Git.

Удаление строки в последнем commit не убирает секрет из истории.

TLS

TLS защищает трафик.

Но если сервер отдаёт данные не тому пользователю, TLS не поможет.

Не подменяйте security одним HTTPS.

Шифрование данных

Если оно нужно, определите алгоритм, ключ, rotation и backup.

Ключ рядом с зашифрованным файлом даёт слабую защиту.

SQL injection

На собственном стенде сравните уязвимый вариант строковой сборки SQL и исправленный parameterized query.

Покажите тест до и после.

Не публикуйте действия против реальной сторонней системы.

XSS

Если тема web, разделяйте reflected, stored и DOM.

Покажите контекст.

Экранирование зависит от места вставки.

CSRF

Для cookie-based auth проверьте state-changing request.

Меры:

• token;
• SameSite;
• origin check.

Архитектура определяет нужный вариант.

Dependency security

Запустите scanner.

Но не копируйте весь список CVE.

Для каждой важной укажите версию, достижимость, patch и риск.

SAST и DAST

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

Динамический тест показывает поведение запущенной системы.

Сравните их на нескольких реальных находках.

Fuzzing

Для parser или protocol можно генерировать неожиданный input.

Измерьте crashes, hangs и unique errors.

Работайте в контролируемой среде.

Логирование

Security events:

• failed login;
• privilege change;
• sensitive action.

Но не логируйте пароль.

Лог тоже является активом.

Audit trail

Для критичной операции сохраняйте actor, object, action, time и result.

Это позволяет расследовать изменение.

Rate limiting

Для login/API можно ограничить частоту.

Но лимит должен учитывать реальную нагрузку.

Не блокируйте легитимных пользователей случайным маленьким числом.

DoS

Полный DDoS-эксперимент не нужен.

Можно локально исследовать expensive endpoint, queue, memory и limit.

Покажите, как защита меняет поведение.

Сетевая сегментация

Для инфраструктурной темы покажите зоны:

user -> app -> DB -> admin.

Разрешите только необходимые потоки.

Не оставляйте any-any.

Backup

Для ransomware-сценария важны отдельное хранение, версии и restore test.

Backup, который не восстанавливался, не проверен.

Incident response

Можно описать небольшой сценарий:

1. alert;
2. triage;
3. isolate;
4. recover;
5. analyze.

Не пишите огромный план, если курсовая техническая.

Остаточный риск

После всех мер риск не становится нулевым.

Укажите, что остаётся.

Это признак зрелой работы.

Практическая глава

Схема:

1. реальный образовательный контекст;
2. архитектура;
3. assets;
4. attacker;
5. threats;
6. risk;
7. measures;
8. test stand;
9. repeated tests;
10. residual risk.

Контекст МФТИ

Кибербезопасность в МФТИ реально представлена в ВШПИ, но текущий базовый перечень 2026 года не нужно искажать, придумывая отдельное направление 10.xx.

Проверяйте название своей программы.

Защита

Будьте готовы показать модель угроз, один exploit на своём стенде, исправление, повторный тест и остаточный риск.

Сильная курсовая по информационной безопасности в МФТИ доказывает защиту экспериментом, а не количеством перечисленных средств.