Статья опубликована в №14 (октябрь) 2014
Разделы: Информационные технологии
Размещена 24.10.2014. Последняя правка: 24.10.2014.
Просмотров - 5065

Разработка типовой архитектуры подсистемы мониторинга и аудита ОС на базе Linux

Стеценко Дмитрий Андреевич

Волгоградский государственный университет

студент

Научный руководитель: Умницын Михаил Юрьевич, ассистент кафедры Информационной безопасности Волгоградского государственного университета

УДК 004.273

ВВЕДЕНИЕ

На сегодняшний день известно, что госаппарат РФ в большей степени оснащен программными продуктами компании Microsoft, которая ограничивает доступ к исходным кодам своих разработок. Не секрет, что использование такого ПО несет целый ряд угроз национальной безопасности. Например, никто не может гарантировать, что в архитектуру этих продуктов на этапе разработки не были заложены программные закладки, действующие уже или готовые активизироваться при необходимости в будущем. Распоряжением правительства РФ от 17 декабря 2010 г.  № 2299-р государственным структурам было предписано осуществить до 2015 года переход с дорогостоящего лицензионного ПО на более дешёвые аналоги OpenSource-разработок на базе GNU Linux. Исполнения данного приказа до последнего времени оставалось под большим вопросом, однако в связи со сложившейся геополитической ситуацией вопрос снова встал ребром.

ИС, функционирующая под управлением какой-либо ОС с открытыми исходными кодами и оснащенная средствами мониторинга и аудита, позволяет квалифицированному специалисту провести своевременный анализ событий, повлекших нарушение безопасности, выработать решение и внедрить его в рабочую систему, тем самым раз и навсегда перекрыв возможность злоумышленнику реализовать подобную атаку снова. При этом вопросы государственной безопасности перестают быть зависимы от частоты и тщательности обновлений выпускаемых «враждебной стороной».

АКТУАЛЬНОСТЬ

Ежегодная статистика по утечкам конфиденциальной информации, приводимая Аналитическим Центром InfoWatch, лишь подчеркивает актуальность вопроса проработки подходов к информационной защите государственного сектора. В 2013 году наблюдался «бум» утечек из государственного сектора, в 2014 - крупные множественные утечки добавились в образовательных и муниципальных учреждениях, и в высокотехнологичной отрасли.

Из всего сказанного выше можно сделать вывод, что вопрос защиты данных конфиденциального характера, обрабатываемых в ГИС, приобретают все большую актуальность, о чем косвенно свидетельствует один из последних приказов ФСТЭК России от 11 февраля
2013 г. № 17.

ИССЛЕДОВАНИЕ

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

Таким образом, актуальной представляется задача разработки открытой архитектуры, методики построения и рабочего прототипа универсального инструмента мониторинга и аудита вычислительных ресурсов для всего семейства ОС GNU Linux, не ограниченного конкретной версией дистрибутива.

В ходе данного исследования необходимо решить следующие задачи:

1)      разработать тетьоретико-множественную модель типового профиля системного окружения операционных систем семейства Linux;

2)      выделить подсистемы системы мониторинга и аудита, на основе которых разработать архитектура программного комплекса мониторинга и аудита;

3)      разработать алгоритм мониторинга и аудита объектов системного окружения ОС семейства Linux.

Следует отметить, что для проведения большинства атак на ОС семейства Linux, злоумышленнику необходимо получить доступ к конфигурационным файлам системы с целью их подмены или частичной замены некоторых параметров, влияющих на уровень безопасности ИС (большинство из этих файлов содержится в каталогах: /etc; /bin; /etc/init.d; /etc/rc.d). Поэтому для обеспечения должного уровня защищенности, средства мониторинга и аудита следует оснастить, помимо базовых функций, возможностью контроля целостности как минимум тех файлов, изменение которых способно повлиять на общий уровень безопасности всей системы в целом.

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

Описанная "гибкость" системы мониторинга и аудита можно реаизовать путем применения модульной архитектуры, проектируемого средства защиты. Применение метода функциональной декомпозиции позволяет выделить в Таблицу 1 составные части (модули), характерные для описанной выше системы мониторинга. Одной из особенностей данной архитектуры является концепция  агентного  мониторинга  –  это  так  называемые  пассивные  проверки  (Passive Checks),  при  которых  инициатива  проверки  принадлежит  не  ядру  мониторинга,  а  самой  подконтрольной  системе,  отсылающей  на  сервер  мониторинга  только  результаты  проверки тогда,  когда это необходимо.

Таблица 1. Составные части разрабатываемой системы мониторинга

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

Соответсвующую данному описанию архитектуру схематично можно изобразить следующим образом:

Рисунок 1 – Архитектура системы мониторинга и аудита

Таблица 2. Отображение составных частей разрабатываемой системы мониторинга в ее архитектуре

Агенты сбора данных	БД	Рассылка	Обработка данных	Отображение	Принятие решений
1,2	10,11,12	7,8,9	4,5	13	6

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

По отношению к множеству компонентов системного окружения (СО) уязвимостьпроявляется как свойство компонентов СО, использование которых нарушителем может привести к реализации угрозы. Угроза в свою очередь проявляется как деструктивное воздействие на компоненты СО, связанное с изменением его свойств. Т.о. в основе аудита информационной безопасности лежит метод выявления аномалий основанный на составлении и последующем сравнении текущего профиля системы с эталонным.

Пускай существует такое множество, элементы которого описывают состояния СО. Назовем его профилем системного окружения и обозначим как П_со. При этом выделяют два режима составления профиля:

1. составление эталонного профиля (П_э): данный профиль формируется при тестовом проведении мониторинга и характеризует состояние КС, которое изначально считается безопасным.
2. составление текущего профиля (П_т): данный профиль создается каждый раз при проведении мониторинга состояния КС.

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

П_ис = {FS, SP, HS, SU}, где

• FS = {path, hash, size} – множество информационных единиц, полученных при анализе состояний файловой системы, где

path – множество путей к системным файлам,

hash – множество контрольных сумм системных файлов,

size – множество размеров, занимаемого дискового пространства, системными файлами;

• SP = {packet, prog, autorun, execp} – множество информационных единиц, полученных при анализе процесса функционирования служб системы, в том числе служб безопасности, где

packet – множество установленных в системе пакетов,

prog – множество установленных в системе программ,

autorun – множество программ автозапуска,

execp – множество программ, неподлежащих мониторингу;

• HS = {peref{usb, sata}, sys{CPU,IO,RAM}} – множество информационных единиц, описывающее состояние оборудования, обеспечивающего функционирование информационной системы, где

peref{usb, sata, com} – множество информационных единиц о периферийных устройствах подключенных к компьютеру через порты USB, SATA и COM,

sys{CPU,IO,RAM} – множество информационных единиц о состоянии устройств процессора (CPU), ввода\вывода (IO) и оперативной памяти (RAM);

• SU {all, current} – множество пользователей находящихся в системе, где

all – множество информационных единиц о всех пользователях системы,

current – множество информационных единиц о пользователях подключенных к системе в данные момент времени.

Формально аудит информационной безопасности системного окружения можно описать  процессом составления и сравнения профилей (эталонного и текущего). По результатам сравнения делается вывод о наличие в СО аномалий, которые могут свидетельствовать о нарушениях безопасности. Ниже представлен алгоритм, реализующий  процессы составления и сравнения профилей. Этот процесс легко представить в виде блок-схемы.

                                                             Блок-схема 1 - Алгоритм аудита.

Алгоритм аудита ИБ в системном окружении, включает следующие шаги:

1)  На первом шаге, после запуска системы мониторинга и аудита ИБ, проверяется, существует ли эталонный профиль.

2)  Если профиль существует, он загружается в систему.

3)  В случае если контрольного профиля нет, система мониторинга и аудита получает от подсистемы сбора данных нужные параметры мониторинга.

4)  На шаге 4 формируется эталонный профиль системы.

5)  Далее, проверяется состояние объектов мониторинга.

6)  На этом шаге стартует цикл опроса состояний объектов мониторинга.

7)  На основе полученных данных формируется текущий профиль СО.

8)  На 8 шаге сравниваются два профиля - эталонный и текущий.

9)  В случае проявления отклонений, производится реакция на нарушение.

10)           Итерация цикла закончена, переход к шагу 5.

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

Блок-схема 2 ‒ Алгоритм взаимодействия подсистем системы мониторинга и аудита

Блок-схема 2 описывает алгоритм взаимодействия подсистем системы мониторинга и аудита, включающий следующие шаги:

1)      На первом шаге после запуска мониторинга и аудита происходит обработка события подсистемой сбора данных.

2)      На шаге 2 формируется текущий профиль системного окружения на основе данных, полученных от подсистемы сбора данных.

3)      На этом шаге из подсистемы хранения считывается эталонный профиль системы.

4)      Происходит сравнение сформированного текущего профиля с эталонным профилем системы.

5)      На этом шаге происходит анализ выявленных отклонений при сравнении профилей.

6)      В случае нахождения нарушений, информация о событии записывается подсистемой хранения данных.

7)      Подсистема оповещения формирует сообщение о событии, обнаруженном на шаге 6.

8)      Подсистема отображения выводит пользователю сообщение об отклонениях в текущем профиле.

ВЫВОД

Разработанная модульная архитектура:

• позволяет вносить изменения и дополнения функциональных возможностей разрабатываемого по предложенной архитектуре программного средства за счет доработки существующих и создния новых плагинов;
• ориентирована на оперативный мониторинг, направленный на оценку текущей работоспособности и эффективности работы исследуемых объектов и немедленную реакцию на разнообразные внештатные ситуации, связанные с безопасностью функционирования системного окружения ОС Linux.
• должна эксплуатироваться в подразделениях защиты информации, пользователями программного комплекса должны являться сотрудники подразделений по защите информации.

1. ГОСТ Р 51275-2006 // Защита информации. Объект информатизации. Факторы, воздействующие на информацию. Общие положения Режим доступа: http://protect.gost.ru/document.aspx?control=7&id=129071
2. Дмитриенко П. В. Методика оценки эффективности систем мониторинга вычислительных ресурсов // Компьютерные исследования и моделирование 2012 Т. 4 № 3 С. 661–668 Режим доступа: http://crm.ics.org.ru/uploads/crmissues/crm_2012_3/661-668.pdf
3. Кореньков В. В., Дмитриенко П. В. Архитектура и пути реализации системы локального мониторинга ресурсного центра // Электронный журнал «Системный анализ в науке и образовании», №3, 2011. – Дубна, 2011. Режим доступа: http://www.sanse.ru/download/96
4. Мирошник И. В. Теория автоматического управления. Линейные системы: Учебное пособие для вузов. – С.-Пб.: Питер, 2005. – 336 с.
5. Распоряжение правительства РФ от 17 декабря 2010 г. № 2299-р Режим доступа: http://government.consultant.ru/page.aspx?1536480
6. ПРИКАЗ ФСТЭК России N 17 от 11 февраля 2013 г. Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах. Режим доступа: http://fstec.ru/rss-lenta/110-deyatelnost/tekushchaya/tekhnicheskaya-zashchita-informatsii/normativnye-pravovye-akty/prikazy/703-prikaz-fstek-rossii-ot-11-fevralya-2013-g-n-17
7. Кореньков В.В. Методология развития научного информационно – вычислительного комплекса в составе глобальной грид-инфраструктуры // Автореферат диссертации на соискание учёной степени кандидата технических наук, Дубна, 2012 год

Рецензии:

24.10.2014, 20:49 Клинков Георгий Тодоров
Рецензия: Статья рекондуется опубликованию.Основания: 1.Актуальность проблематики... 2.Стиль контекстного изложения... 3.Объем и способ динамизаций етапных частей... 4.Логическая связь между основного повествовательного конструкта текста и архитектоника блок-схем. 5.Мониторинг на основе Linux дает нужную оперативную информацию в режимах информационной защиты.

31.10.2014, 21:46 Назарова Ольга Петровна
Рецензия: Статья рекомендуется к печати



Комментарии пользователей:

Оставить комментарий