Алгоритм локализации участка корпоративной информационно-телекоммуникационной сети предприятий с аномальным поведением

Монахова Мария Михайловна кандидат технических наук старший преподаватель, Владимирский государственный университет им. Александра Григорьевича и Николая Григорьевича Столетовых 600026, Россия, Владимирская область, г. Владимир, ул. Белоконской, 5, ауд. 406 Monakhova Mariya PhD in Technical Science Senior Lecturer at Vladimir State University named after Alexander and Nikolay Stoletovs  600026, Russia, Vladimir, ul. Belokonskoi, 5, aud. 406 mariya.monakhova@gmail.com Путинцев Григорий Васильевич инженер, Владимирский государственный университет 600000, Россия, Владимирская область, г. Владимир, ул. Горького, 87, ауд. 427а Putintsev Grigorii Engineer at Vladimir State University 600000, Russia, Vladimir, ul. Gor'kogo, 87, aud. 427a putigr@mail.ru Мазурок Дмитрий Валерьевич инженер, Владимирский государственный университет 600000, Россия, Владимирская область, г. Владимир, ул. Горького, 87, ауд. 408 Mazurok Dmitrii Engineer at Vladimir State University 600000, Russia, Vladimir, ul. Gor'kogo, 87, aud. 408 cherpak-diman@mail.ru

Порфирьев Артем Андреевич инжеенер, Владимирский государственный университет 600000, Россия, Владимирского область, г. Владимир, ул. Горького, 87, ауд. 427б Porfirev Artem Engineer at Vladimir State University 600000, Russia, Vladimir, ul. Gor'kogo, 87, aud. 427b vlsu_web_2015@bk.ru

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

В корпоративной информационно - телекоммуникационной сети (КИТС) функционируют различные протоколы маршрутизации, от правильного конфигурирования которых зависит как обеспечение бесперебойной работы КИТС, так и её безопасность. В рамках технической политики информационной безопасности требуется создавать эталонные конфигурации КИТС, тем самым защищая свою сеть от несанкционированного изменения конфигурации КИТС. Зачастую, в процессе функционирования КИТС наблюдается различная сетевая активность, повторяющаяся со временем, так, например, работа пользователей информационной системы организации, где функционирует данная КИТС с различными сетевыми сервисами. На основе этого можно сделать вывод, что увеличение сетевой активности в определенном сегменте сети, сигнализирует о несанкционированных действиях в данном сегменте.

Проанализировав научные труды на тему типовой сетевой активности пользователей можно выделить основные критерии для определения аномальной сетевой активности ^{[4; 5]}.

В процессе функционирования КИТС можно выделить различные временные интервалы сетевой активности, каждый из которых характеризуется своими показателями.

На основе выше сказанного можно сделать вывод о том, что для определения несанкционированной сетевой активности в КИТС требуется составить технические политики информационной безопасности для каждого временного интервала. Основным контролируемым параметром выделим параметры функционирующих в КИТС протоколов динамической маршрутизации, так как они чувствительны к изменению состояния каналов связи, следовательно, при появлении аномальной сетевой активности параметры маршрутизации изменяться в соответствии с изменением состояния канала. В качестве основного параметра динамических протоколов маршрутизации КИТС будем считать метрику данного протокола. Изменение метрики будет сигнализировать о несанкционированной сетевой активности.

На основе модели сети, представленной в виде графа, была предложена реализация алгоритма определения сегмента КИТС с аномальным поведением. Данная система не оказывает влияние на производительность КИТС. Система состоит из клиент-серверного приложения. Основными компонентами системы являются: клиент, сервер, конфигурационные компоненты системы.

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

Алгоритм работы клиентского приложения:

Шаг №1. Установка соединения с серверным приложением и ожидание команды начала опроса;

Шаг №2. Клиент принимает команду от сервера содержащую тип опроса;

Шаг №3. Если принятый код равен 0, то клиенту требуется собирать данные для построения эталонной матрицы метрик;

Шаг №4. Если принятый код равен 1, то клиенту требуется собирать данные для построения текущей матрицы метрик;

Шаг №5. Клиент принимает количество раундов опроса, если код типа опроса равен 1, то количество раундов равняется 1, если код типа опроса равен 0, то количество раундов определяется конфигурацией сервера;

Шаг №6. Клиент принимает от серверного приложения время между раундами опросов в секундах, для типа опроса 1 данная переменная равняется 0;

Шаг №7. Клиент принимает от серверного приложения и сохраняет в локальной рабочей директории матрицу адресации маршрутизаторов, матричное представление графовой модели КИТС;

Шаг №7. Клиент оправляет серверному приложению номер подсети в которой находиться клиент, данное значение заложено в конфигурации каждого клиентского приложения;

Шаг №9. Клиент определяет в соответствии с матрицей адресации маршрутизаторов, к какому маршрутизатору он относиться и номера подсетей к которым маршрутизатор непосредственно подключен;

Шаг №10. Клиент отправляет серверному приложению массив подсетей от лица которых он будет производить опрос;

Шаг №11. Клиент инициирует цикл с количеством итераций равных числу раундов опроса;

Шаг №12. Клиент инициирует подключение по telnet к граничному маршрутизатору, для получения конфигурации протокола маршрутизации;

Шаг №13. Клиент запускает модуль разбора конфигурации и получает значения метрик для всех связей определенной подсети;

Шаг №14. Клиент отправляет номер раунда опроса серверному приложению;

Шаг №15. Клиент отправляет массив значений метрик опрощенной подсети для данного раунда опроса;

Шаг №16. Клиент высчитывает время таймаута относительно разницы указанного временного интервала между опросами и затраченного времени на произведение одного раунда опроса;

Шаг №17. Клиент воспроизводит шаги №12-16 определенное количество раз, равное количеству раундов опроса;

Шаг №18. Конец алгоритма.

Визуальное представление алгоритма представлено на рисунке 1.

Рисунок 1 - Блок-схема алгоритма работы клиентского приложения

При запуске сервер подгружает конфигурационные файлы, содержащие матрицу адресации маршрутизаторов, матричное представление графовой модели КИТС, а также эталонные матрицы метрик для каждого временного интервала, если данный матрицы уже были собраны.

Алгоритм работы серверного приложения:

Шаг №1. Администратор вводит режим сбора данных;

Шаг №2. Если режим сбора равен 0, производиться сбор эталонной матрицы метрик;

Шаг №3. Если режим сбора равен 1, производиться сбор текущих значений метрик;

Шаг №4. Если инициирован режим построения эталонной матрицы метрик, Администратор вводит номер временного интервала, количество раундов опроса, время между раундами в секундах;

Шаг №5. Сервер ожидает, когда подключатся все клиентские машины;

Шаг №6. Сервер отправляет каждому клиенту код режима опроса и количество раундов опроса и время между раундами опроса;

Шаг №7. Клиент производит опрос определенной подсети и отправляет серверу номер подсети и полученные метрики;

Шаг №8. Сервер анализирует ответ клиента на предмет проверки связей directly connected, в тех случаях, когда опрос производится от лица других подсетей;

Шаг №9. Сервер сохраняет полученные данные в эталонной матрице метрик;

Шаг №10. Сервер определяет какие подсети остались без опроса клиентскими приложениями и производит самостоятельный опрос данных подсетей, сохраняя полученные данные метрик в эталонной матрице метрик;

Шаг №11. Сервер, по окончанию опроса всех подсетей, начинает подсчет эталонных интервалов метрик, высчитывая математическое ожидание от значений полученных метрик и среднеквадратичное отклонение этой величины;

Шаг №12. Если инициирован сбор текущих значений метрик, сервер ожидает подключения всех клиентов;

Шаг №13. Сервер отправляет код режима опроса, количество раундов равное 1 и время между раундами равное 0 секунд;

Шаг №14. Клиенты отправляют серверу номер подсети, от лица которой они производили опрос и массив значений текущих метрик;

Шаг №15. Сервер анализирует полученные значения на предмет проверки связи directly connected, в тех случаях, когда опрос производиться от лица других подсетей;

Шаг №16. Сервер сохраняет полученные данные в матрице текущих значений метрик;

Шаг №17. Сервер определяет какие подсети остались без опроса клиентскими приложениями и производит самостоятельный опрос данных подсетей, сохраняя полученные данные метрик в матрице текущих значений метрик;

Шаг №18. Сервер по окончанию сбора текущей матрицы метрик производит сравнение текущей матрицы метрик с эталонной матрицей метрик того временного интервала в период которого была собрана матрица текущих значений метрик;

Шаг №19. Сравнение производиться на основе описанного ранее алгоритма;

Шаг №20. Сервер производит анализ построенной матрицы сравнения и производит построение упрощенного графа КИТС сетевого уровня модели OSI с указанием критичных сегментов КИТС;

Шаг №21. Конец алгоритма.

Визуализация алгоритма представлена на рисунке 2.

Рисунок 2 -Блок-схема алгоритма работы серверного приложения

Для тестирования использовалась экспериментальная установка типовой КИТС, которая состояла из 14 маршрутизаторов, 4 коммутаторов, 29 подсетей. Схема используемой КИТС представлена на Рисунке 3.

Рисунок 3 – Схема типовой КИТС

Экспериментальное исследование №1

Цель эксперимента:

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

Условия эксперимента:

Стандартная сетевая активность, отсутствие инцидентов безопасности.

Входные данные:

Лабораторная установка – эмулятор КИТС, программный продукт.

Время проведения эксперимента – 5 дней по 9 часов. В ходе анализа функционирования КИТС типового предприятия Владимирской области было выявлено пять временных периодов, характеризующихся различной сетевой активностью:

Начало рабочего дня (9.00-10.00);

Рабочее время - I (10.00-12.00);

Обеденное время (12.00-13.00);

Рабочее время – II (13.00-16.00);

Окончание рабочего дня (16.00-18.00)

Проведение эксперимента:

Шаг 1. На базе сегмента КИТС кафедры ИЗИ была собрана лабораторная установка по схеме, указанной на Рисунке 3

Шаг 2. В течение рассматриваемых временных интервалов производились периодические замеры различных параметров протокола маршрутизации КИТС. Измерения производились с периодом в 7,5 мин.

Пример dump-файла топологии маршрутизации по протоколу EIGRP:

Рисунок 4 – Пример dump-файла топологии EIGRP

Шаг 3. На сервер устанавливаются и настраиваются программные модули

Шаг 4. Запускаются клиенты на рабочих станциях. На сервер передаются dump-файлы со всех маршрутизирующих устройств

Шаг 5. Запускается программный обработчик данных. По итогам работы обработчика получается таблица характеристик КИТС, необходимых для дальнейшей обработки.

Шаг 6. Запускается программный анализатор данных. Выполняется построение эталонной матрицы метрик, которая в дальнейшем послужит эталонным диапазоном для сравнения текущих значений с целью выявления фактов инцидентов ИБ. Результаты работы формируются в файл формата *.txt для дальнейшей обработки и использования администратором безопасности (Рисунок 5)

Рисунок 5 – Фрагмент эталонной матрицы метрик

Экспериментальное исследование №2

Цель эксперимента:

Тестирование разработанного на кафедре ИЗИ программного продукта - автоматизированной системы на эмулированной тестовой сети типового предприятия, при помощи которого в условиях DDOS-атаки планируется обнаружить факт возникновения инцидента ИБ и локализовать область его возникновения.

Условия эксперимента:

Стандартная сетевая активность. DDOS-атака, запущенная на сервер S1.

Входные данные:

Лабораторная установка – эмулятор КИТС, программный продукт.

Проведение эксперимента:

Шаг 1. В процессе стандартного функционирования КИТС в режиме Рабочее время – II с атакующих компьютеров была запущена DDOS-атака

Шаг 2. По аналогии с предыдущим экспериментом запускаются программные модули автоматизированной системы, которая, подгружая ранее созданную матрицу диапазонов эталонных значений на выходе получает текущую матрицу метрик (Рисунок 6) и матрицу сравнения (Рисунок 7) и сохраняет эти результаты в *.txt файл, указывая в названии текущий временной период, для ведения логирования. Полученные данные позволяют локализовать самые критичные области в КИТС, а также области, подвергшиеся влиянию инцидента ИБ в КИТС.

Рисунок 6 – Фрагмент текущей матрицы метрик

Рисунок 7 - Фрагмент матрицы сравнения

Для более наглядного представления, пересечения критичных подсетей в КИТС были выделены на Рисунке 7. Как мы можем видеть из полученного dump-файла на пересечении сетей W1, W6, W10, W12 в матрице сравнения стоят двойки, что сигнализирует о выходе текущей метрики из доверительного интервала эталонной матрицы, как следствие, в этих подсетях возможен инцидент ИБ.

Шаг 3. На основании полученной матрицы сравнения программа выводит на экран схему сети с выделенными критичными областями для наглядного представления и дальнейшей обработки полученной информации администратором безопасности (Рисунок 8).

Рисунок 8 – Вывод схемы сети с выделенными критическими областями

По результатам тестирования программного продукта было выявлено, что использование данной методики ускоряет процесс определения участка КИТС с аномальным поведением на 18% по сравнению с поиском без использования описанноый метода. Возможность использования программного продукта без воздействия на сеть, позволит широко использовать систему на предприятиях. Относительная простота развертывания и установки системы, а так же удобство предоставления полученной информации о сети для администратора безопасности позволит сократить и предупредить угрозы возникновения инцидентов ИБ, а так же вовремя устранить их. При этом от своевременного устранения минимизируются риски для предприятия связанные с инцидентом ИБ. А, как известно, важность быстрого устранения инцидента для предприятия, без отрыва от производства, минимизирует финансовые потери как отдельных элементов, так и всей организации в целом, поэтому актуальность данной разработки достаточна высока и программный продукт вполне может быть использован для внедрения на предприятия.