Статья 'Алгоритм локализации участка корпоративной информационно-телекоммуникационной сети предприятий с аномальным поведением' - журнал 'Вопросы безопасности' - NotaBene.ru
по
Journal Menu
> Issues > Rubrics > About journal > Authors > About the Journal > Requirements for publication > Editorial collegium > Peer-review process > Policy of publication. Aims & Scope. > Article retraction > Ethics > Online First Pre-Publication > Copyright & Licensing Policy > Digital archiving policy > Open Access Policy > Article Processing Charge > Article Identification Policy > Plagiarism check policy
Journals in science databases
About the Journal

MAIN PAGE > Back to contents
Security Issues
Reference:

Algorithm of localization of a corporate information and telecommunication network’s area with abnormal behavior

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
Putintsev Grigorii

Engineer at Vladimir State University

600000, Russia, Vladimir, ul. Gor'kogo, 87, aud. 427a

putigr@mail.ru
Mazurok Dmitrii

Engineer at Vladimir State University

600000, Russia, Vladimir, ul. Gor'kogo, 87, aud. 408

cherpak-diman@mail.ru
Porfirev Artem

Engineer at Vladimir State University

600000, Russia, Vladimir, ul. Gor'kogo, 87, aud. 427b

vlsu_web_2015@bk.ru

DOI:

10.7256/2409-7543.2017.2.21868

Received:

01-02-2017


Published:

20-05-2017


Abstract: The research object is an information and telecommunication network. The research subject is the algorithms of detection and identification of information safety incidents of information and telecommunication networks of modern companies. The purpose of the study is to develop algorithms of detection of information safety incidents in corporate information and telecommunication networks. The authors describe the method based on the comparison of the reference configurations of information and telecommunication networks with the factual ones. Unauthorized change of configurations and external interference in the work of a corporate information and telecommunication network cause the instability of work of its elements, and threaten information safety. The authors use the theory of graphs and the methods of discrete mathematics and mathematical statistics. The article contains the algorithm of identification of a corporate and telecommunication network’s area with abnormal behavior, and the example of its program realization, and raises the problem of importance of timely and reasoned localization of a corporate information and telecommunication network’s area with probable information safety incidents. The scientific novelty of the study consists in the development of the model of an information safety incident and the algorithm of localization of a corporate information and telecommunication network’s area with abnormal behavior. The authors formulate the algorithm of localization, which helps reduce the time of an information safety incident detection by approximately 15% and identification – from 5 to 10%. 


Keywords:

information safety, corporate Information-Telecommunications Network, IS incidents, abnormal behaviour, detection algorithm, experimental facility, localization of a network's segment, graph model, reference values, equipment CITN

This article written in Russian. You can find original text of the article here .
Введение

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

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

Основная часть

Проанализировав научные труды на тему типовой сетевой активности пользователей можно выделить основные критерии для определения аномальной сетевой активности [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.

.jpg

Рисунок 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.

.png_01

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

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

.png_02

Рисунок 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:

.png_07

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

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

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

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

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

.png_03

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

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

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

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

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

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

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

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

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

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

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

.png_04

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

.png_05

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

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

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

.png_06

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

Вывод

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

References
1.
2.
3.
4.
5.
Link to this article

You can simply select and copy link from below text field.


Other our sites:
Official Website of NOTA BENE / Aurora Group s.r.o.