- •Задание на курсовую работу
- •Содержание
- •Теоретическое введение
- •Формулировка определений и их свойств
- •1. Анализ сетевых уязвимостей и механизмов реализации деструктивных информационных воздействий
- •2. Методология моделирования угроз на основе классификации фстэк России
- •3. Математический аппарат Марковских процессов в задачах оценки надежности сетевых элементов
- •Решение поставленной задачи Сетевая конфигурация
- •4. Метрики количественного анализа уязвимостей и расчет уровня критичности
- •5. Теоретические принципы сигнатурного и хронологического анализа сетевого трафика
- •Формирование угроз
- •Граф состояний
- •Расчет уровня критичности уязвимости
- •Анализ трасс атаки
- •Трасса №1: Дистанционное зондирование и сканирование сетевых портов (tcp Port Scanning)
- •Трасса №2: Реализация деструктивного воздействия типа «отказ в обслуживании» (syn-Flood / DoS)
- •Заключение
- •Список использованных источников
Формирование угроз
На основе нового раздела угроз сайта ФСТЭК была составлена модель угроз, которые составляют опасность составленной конфигурации при условии, что злоумышленник проводит исключительно DOS-подобную атаку.
Рисунок 2. Перечень возможных угроз
Перечень возможных угроз безопасности информации:
УБИ.5 Угроза удаления информационных ресурсов. Возможен выход из строя оборудования и удаления данных, находящихся в оперативной памяти вычислительных устройств
УБИ.6 Угроза отказа в обслуживании. Суть DOS атаки
УБИ.7 Угроза нецелевого использования. Вероятнее всего данная угроза подходит, поскольку ЭВМ не используется по назначению, пока подвержена атаке
УБИ.8 Угроза нарушения работоспособности. Суть DOS-подобной атаки
Ниже представлены несколько из предложенных ФСТЭК мер защиты от угроз безопасности:
"ЗТС.2.1 Обеспечение контролируемой зоны, в пределах которой постоянно размещаются стационарные технические средства, обрабатывающие информацию, и средства защиты информации, а также средства обеспечения функционирования;
ОПС.1.4 Настройка параметров запуска компонентов программного обеспечения от имени учетной записи администратора безопасности таким образом, чтобы текущий пользователь средства вычислительной техники не мог получить через данные компоненты доступ к объектам доступа, на доступ к которым у него нет прав;
ИНЦ.3.1 Назначение должностного лица (группы расследования), имеющего навыки проведения подобных расследований;
УКФ.3.1 Разработка перечня программного обеспечения и (или) его компонентов, разрешенных оператором к установке («белый список»), и (или) перечнем программного обеспечения и (или) его компонентов, запрещенных оператором к установке («черный список»);
АВЗ.4.3 Контроль целостности обновлений базы данных признаков вредоносных компьютерных программ (вирусов);
ЗИС.35.1 Фильтрация сетевого трафика, в том числе между внешними сетями и внутренними, в том числе при организации сетевого обмена с сетями связи общего пользования;
УПД.13.3 Предоставление удаленного доступа только тем пользователям, которым он необходим для выполнения установленных должностных обязанностей (функций);
ЗНИ.2.1 Определение должностных лиц, имеющих физический доступ к машинным носителям информации;
УПД.3.3 Контроль целостности программного обеспечения и аппаратных компонентов средств вычислительной техники
Граф состояний
Далее был составлен граф состояний при помощи ПО MATLAB. За шаблон были взяты предложенные файлы-скрипты для MATLAB. Были изменены исходные значения в соответствии с вероятностями событий.
Рисунок 3. Результат main2.m
Рисунок 4. Результат LotVolCoefSource.m
Так же был изображен граф состояний с лямбда переходами
Рисунок 5. Марковский граф состояний при DOS атаке
Расчет уровня критичности уязвимости
Для выполнения расчета по актуальной методологии ФСТЭК России необходимо воспользоваться методическими указаниями от 30 июня 2025 года «МЕТОДИКА ОЦЕНКИ УРОВНЯ КРИТИЧНОСТИ УЯЗВИМОСТЕЙ ПРОГРАММНЫХ, ПРОГРАММНО-АППАРАТНЫХ СРЕДСТВ».
Идентификатор
УБИ.6 (или аналогичные УБИ) в нормативной
базе ФСТЭК относится к Банку данных
угроз. Согласно требованиям, расчет
уровня критичности
производится не для абстрактной угрозы,
а для конкретной уязвимости программного
обеспечения.
Для предложенной ранее схемы (атака SYN-Flood на Web-сервер) следует выбрать классическую уязвимость веб-сервера (например, Nginx или Apache), которая приводит именно к отказу в обслуживании (DoS/DDoS)
Расчет уровня критичности уязвимости в информационной системе вычисляется по следующей многофакторной формуле:
Где каждый из показателей детально характеризует свойства самой уязвимости, архитектурные особенности защищаемой сетевой конфигурации, а также текущую оперативную обстановку.
Этап
1. Определение базового показателя
опасности (
)
Согласно
пункту 13 документа, в качестве базового
дескриптора
принимается оценка, рассчитанная по
метрикам Common Vulnerability Scoring System (CVSS) версии
3.1, содержащаяся в Банке данных ФСТЭК
России. Для симуляции атаки типа «отказ
в обслуживании» на Web-сервер выбрана
уязвимость сетевого стека веб-службы,
имеющая высокий базовый балл. Ключевые
метрики CVSS для таких уязвимостей обычно
характеризуются сетевым вектором атаки
(AV: N), низкой сложностью реализации (AC:
L) и отсутствием требований к правам
доступа (PR:N). Фиксация значения: для
проведения расчетов примем стандартное
для критических DoS-уязвимостей значение
базовой оценки:
Этап
2. Расчет показателя влияния на
инфраструктуру (
)
Показатель
отражает внутреннюю архитектуру сети
организации. Он рассчитывается как
взвешенная сумма трех коэффициентов,
определяющих тип атакуемого узла, их
долю в системе и доступность из внешних
сетей:
.
На основе инвентаризации построенной
сетевой конфигурации и Таблицы 1 Методики,
можно определить переменные:
Тип компонента (K): Объектом атаки является Web-сервер компании. Согласно Таблице 1 (пункт 1), для серверов, выполняющих роль центральных вычислительных узлов, установлено значение
при весовом коэффициенте
.
Количество уязвимых компонентов (L): поскольку инфраструктура спроектирована по минималистичному принципу, уязвимый Web-сервер является единственным в данном сегменте, что составляет менее 10% от общего числа аппаратных компонентов информационной системы организации. По Таблице 1 (пункт 2) данному условию соответствует значение
при весовом коэффициенте
.
Влияние на защиту периметра (P): Так как Web-сервер предназначен для публикации сайта в глобальной сети, он напрямую доступен из сети «Интернет». Согласно Таблице 1 (пункт 3), для открытых внешних компонентов устанавливается максимальное значение
при весовом коэффициенте
.
Итоговое значение инфраструктурного показателя:
Этап 3. Определение показателя возможности
эксплуатации (
)
Показатель характеризует степень доступности и частоту применения эксплойтов для данной уязвимости в мировом пространстве на момент проведения оценки:
Для
большинства классических уязвимостей,
приводящих к SYN-Flood или иным DoS-состояниям,
в открытом доступе присутствуют готовые
утилиты для проведения атак (стресс-тесты,
скрипты автоматизации). На основе Таблицы
1 (пункт 4) можно заметить, что «имеются
сведения о наличии средств эксплуатации
(эксплойта) уязвимости». Этому описанию
соответствует значение
при весовом коэффициенте
.
Этап
4. Определение показателя последствий
эксплуатации (
)
Показатель детерминирует тяжесть последствий для информационной системы, наступающих в результате успешных действий нарушителя:
Исходя
из специфики выбранного деструктивного
воздействия (атака, направленная на
отказ в обслуживании), ключевым
последствием является нарушение
доступности легитимного сервиса. В
соответствии с Таблицей 1 (пункт 5),
значению «Отказ в обслуживании (DoS)»
присваивается величина
при весовом коэффициенте
.
Этап 5. Финальный расчет и интерпретация результатов ( )
Объединив все верифицированные и рассчитанные компоненты в генеральную формулу, получается точное числовое значение уровня критичности исследуемой уязвимости:
Для
интерпретации полученного результата
следует обратиться к нормативной Таблице
2 «Значения итоговой оценки уровня
критичности уязвимости». Полученный
балл
строго попадает в диапазон:
Таким образом, рассматриваемой уязвимости Web-сервера, приводящей к отказу в обслуживании при заданных параметрах сетевой топологии, присваивается Средний уровень критичности. Согласно пункту 21 раздела III представленного Методического документа ФСТЭК России, в отношении уязвимостей со средним уровнем критичности оператору информационной системы рекомендуется принять меры по их устранению или внедрить компенсирующие технические меры защиты (такие как резервирование каналов связи или подключение модулей фильтрации трафика) в течение нескольких недель (до 4 недель) с момента проведения оценки.
