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

Курсовая по информационной безопасности в НИЯУ МИФИ имеет особенно естественный контекст. В актуальном наборе 2026 года по направлению 10.03.01 представлены программы по безопасности компьютерных систем, критической информационной инфраструктуре и информационно-аналитическим системам финансового мониторинга.

Официальная страница:
https://admission.mephi.ru/admission/baccalaureate-and-specialty/education/programs/all/view/136

Начните с того, что защищается

Актив:

• data;
• account;
• system;
• model;
• control network;
• key;
• service.

Не начинайте с перечня атак.

Угроза имеет смысл только относительно актива.

CIA

Для каждого актива определите:

• confidentiality;
• integrity;
• availability.

У критической инфраструктуры availability может быть важнее, чем у обычного web-сервиса.

Граница системы

Нарисуйте:

user -> frontend -> API -> DB
                -> external service.

Отметьте trust boundaries.

Это места, где особенно важны проверки.

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

Опишите:

• external/internal;
• access;
• knowledge;
• resources;
• goal.

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

Иначе невозможно оценить меру.

Threat modeling

Можно использовать:

• STRIDE;
• attack tree;
• data-flow based analysis.

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

Не вставляйте список терминов из OWASP.

Risk

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

• likelihood;
• impact;
• existing control;
• residual risk.

Если используются баллы, объясните шкалу.

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

Все технические проверки выполняйте только на собственной системе или явно разрешённой лабораторной среде.

Не тестируйте сторонние сервисы без разрешения.

Это принципиальное правило.

Authentication

Проверьте:

• password storage;
• login;
• session;
• recovery.

Пароль не хранится plaintext.

Используйте специализированный password hash.

Password hashing

Нужны:

• salt;
• cost;
• proper algorithm.

Быстрый general-purpose hash сам по себе недостаточен.

MFA

Второй фактор полезен для high-risk account.

Но он не закрывает broken authorization.

Разделяйте меры по угрозам.

Authorization

Проверяйте право на объект в backend.

Negative test:

user A запрашивает record user B.

Ожидаемо:

access denied.

Least privilege

DB account приложения должен иметь только нужные права.

Сервис чтения не должен иметь DROP.

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

Secrets

Не коммитьте:

• private key;
• API token;
• database password.

Проверьте Git history.

Удаление из последнего commit недостаточно.

TLS

TLS защищает channel.

Он не исправляет ошибку access control.

Не пишите «система защищена HTTPS».

Encryption at rest

Если данные действительно чувствительные, продумайте:

• algorithm;
• key storage;
• rotation;
• backup.

Ключ рядом с encrypted data обесценивает часть защиты.

Input validation

Проверяйте:

• length;
• type;
• format;
• range.

Но security не сводится к regex.

Используйте безопасные API и parameterized queries.

SQL injection

На своём стенде можно показать:

уязвимый query -> безопасный query -> повторный test.

Не переносите эксперимент на чужой ресурс.

XSS

Для web-проекта учитывайте context:

• HTML;
• attribute;
• JS.

Механизм escaping зависит от места вывода.

Dependency vulnerabilities

Scanner даёт список CVE.

Для каждой важной находки разберите:

• affected version;
• reachable code;
• patch;
• severity.

Не вставляйте сотни строк отчёта.

SAST

Статический инструмент помогает искать unsafe patterns.

Выберите несколько находок.

Проверьте false positive.

Инструмент не заменяет анализ.

DAST

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

Он может найти другой класс проблем.

Сравните SAST и DAST.

Fuzzing

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

Метрика:

• crash;
• hang;
• unique failure.

Работайте локально.

Критическая информационная инфраструктура

Если тема относится к КИИ, особенно важно разделять:

• IT;
• OT;
• safety;
• availability.

Обычная офисная security-модель не всегда подходит к технологической системе.

Сегментация

Покажите зоны:

user
application
database
admin
OT.

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

Не делайте any-any.

Firewall rules

Таблица source/destination/port/action должна соответствовать архитектуре.

Не копируйте случайный набор правил.

Monitoring

Security monitoring может включать:

• failed login;
• privilege change;
• unusual event;
• integrity alert.

Но alert должен иметь action.

Audit

Для критичной операции храните:

• actor;
• time;
• object;
• result.

Audit log должен быть защищён от обычного пользователя.

Backup

Для ransomware resilience важно:

• separate copy;
• versioning;
• restore test.

Backup считается проверенным только после восстановления.

Availability

Проверьте:

• service restart;
• DB failure;
• network loss.

Для critical context downtime сам является security impact.

Rate limiting

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

Покажите threshold и влияние на normal users.

Не выбирайте число без workload.

DoS lab

В курсовой достаточно безопасного локального load test.

Например:

expensive endpoint до и после rate limiting.

Не нужен реальный DDoS.

Финансовый мониторинг

Если тема связана с информационно-аналитическими системами, разделяйте:

• anomaly;
• suspicious event;
• confirmed violation.

Алгоритм не должен автоматически объявлять человека виновным.

False positive

В security analytics это критичная метрика.

Слишком чувствительное правило создаёт поток ложных alerts.

Сравнивайте recall и precision.

Incident response

Опишите один сценарий:

detect -> triage -> contain -> recover -> learn.

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

Residual risk

После мер риск остаётся.

Перечислите 2-3 ключевых остаточных риска.

Это делает вывод реалистичным.

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

Схема:

1. architecture;
2. assets;
3. attacker;
4. threats;
5. risk;
6. controls;
7. lab;
8. tests;
9. monitoring;
10. residual risk.

Контекст НИЯУ МИФИ

В актуальном наборе информационная безопасность связана и с компьютерными системами, и с критической инфраструктурой.

Поэтому работа особенно выигрывает от чёткой архитектуры и безопасного воспроизводимого эксперимента.

Защита

Будьте готовы показать threat model, конкретную меру, test до исправления, test после, log и residual risk.

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