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

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

Сильная работа связывает актив, угрозу, уязвимость, риск и конкретную меру.

Определите объект

Это может быть:

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

Не анализируйте информационную безопасность предприятия целиком без границ.

Активы

Сначала составьте список того, что имеет ценность.

Например:

• персональные данные;
• коммерческая информация;
• учётные записи;
• конфигурация;
• ключи;
• доступность сервиса;
• журнал операций.

Не ограничивайтесь файлами.

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

Свойства безопасности

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

• конфиденциальность;
• целостность;
• доступность.

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

Для открытой публикации конфиденциальность может вообще не быть целью.

Не применяйте триаду механически.

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

Нарисуйте архитектуру и отметьте, где данные переходят между зонами.

Например:

• браузер;
• сервер;
• БД;
• внешний API;
• административный интерфейс.

Переход через границу доверия является удобной точкой для анализа.

Субъекты угроз

Не нужно фантазировать о конкретных преступниках.

Достаточно категорий:

• внешний нарушитель;
• обычный пользователь;
• привилегированный сотрудник;
• подрядчик;
• ошибающийся пользователь.

Внутренняя ошибка и целевая атака требуют разных мер.

Сценарий угрозы

Пишите конкретно.

Не «утечка данных», а:

«Пользователь получает доступ к записи другого пользователя из-за отсутствия проверки права на объект».

Так сразу видно, где должна быть защита.

Уязвимость и угроза

Это не одно и то же.

Уязвимость - слабость.

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

Риск появляется, когда сценарий имеет вероятность и последствия.

Не смешивайте понятия в одной таблице.

Оценка риска

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

Например:

• вероятность;
• ущерб;
• итоговый уровень.

Но заранее задайте значения шкалы.

Не ставьте всем угрозам высокий риск.

Тогда приоритизация теряет смысл.

Модель доступа

Если система многопользовательская, создайте матрицу ролей.

Покажите, кто может:

• читать;
• создавать;
• изменять;
• удалять;
• администрировать.

Принцип наименьших привилегий означает, что пользователю не дают права на всякий случай.

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

Продумайте:

• хранение пароля;
• восстановление;
• сессии;
• блокировку;
• многофакторность, если она оправдана.

Не храните пароли в открытом виде или обратимо зашифрованном виде.

В курсовой достаточно описать безопасный принцип без публикации секретов.

Авторизация

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

Скрытая кнопка в интерфейсе не запрещает прямой запрос к API.

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

Секреты

API-ключ, пароль БД и токен не должны попадать:

• в репозиторий;
• в лог;
• в скриншот;
• в отчёт.

Используйте тестовые или обезличенные значения.

Ввод пользователя

Не доверяйте данным только потому, что они пришли из вашей формы.

Проверяйте тип, длину, формат и допустимое значение.

Для запросов к БД используйте безопасные механизмы параметризации.

Не собирайте в отчёте рабочие примеры вредоносных строк, если для объяснения достаточно безопасного тестового случая.

Логи

Журнал должен помогать расследовать событие.

Полезно фиксировать:

• время;
• пользователя;
• действие;
• объект;
• результат.

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

Резервное копирование

Наличие backup-файла ещё не гарантирует восстановление.

Покажите:

• что копируется;
• как часто;
• где хранится;
• кто имеет доступ;
• как проверяется восстановление.

Тест восстановления важнее красивого расписания резервного копирования.

Доступность

Если сервис критичен, оцените:

• одиночные точки отказа;
• резерв;
• мониторинг;
• план восстановления.

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

Он решает другую задачу.

Обновления

Уязвимое ПО нужно обновлять, но обновление тоже создаёт риск совместимости.

В курсовой можно описать процесс:

1. тест;
2. резервная копия;
3. обновление;
4. проверка;
5. откат при необходимости.

Это сильнее фразы регулярно обновлять программы.

Сегментация

Разделение сети ограничивает распространение инцидента.

Но VLAN сама по себе не является достаточной защитой.

Нужны правила обмена между сегментами.

Покажите, какие соединения разрешены и зачем.

Шифрование

Определите, от чего оно защищает.

Данные могут шифроваться при передаче и при хранении.

Шифрование не защищает от пользователя, которому система уже дала доступ к расшифрованным данным.

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

Мониторинг

Нужно определить события, которые имеют смысл:

• множество неудачных входов;
• изменение прав;
• массовая выгрузка;
• отказ службы.

Не создавайте сигнализацию на каждое обычное действие.

Избыточные ложные события снижают внимание.

Проверка мер

Каждую защиту лучше связать с тестом.

Например:

• пользователь другой роли получает отказ;
• после удаления сессии старый токен не работает;
• backup восстанавливается;
• запрещённое соединение блокируется.

Не тестируйте защиту только наличием настройки в интерфейсе.

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

Даже после мер риск не исчезает полностью.

Покажите, что остаётся и почему это приемлемо или требует следующего шага.

Фраза «система полностью защищена» для реального проекта почти всегда слишком сильная.

Документирование

Полезно сохранить:

• схему;
• модель угроз;
• матрицу доступа;
• перечень мер;
• сценарии тестов.

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

В центре должны быть логика и проверяемость.

Защита

Покажите одну сквозную угрозу:

1. актив;
2. сценарий;
3. уязвимость;
4. риск;
5. мера;
6. тест;
7. остаточный риск.

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