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

На сегодняшний день известно, что госаппарат РФ в большей степени оснащен программными продуктами компании 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 и рисунок 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 — множество информационных единиц о пользователях подключенных к системе в данные момент времени.

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

алгоритм программный мониторинг linux.

Блок-схема 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. ГОСТ Р 51 275−2006 // Защита информации. Объект информатизации. Факторы, воздействующие на информацию. Общие положения Режим доступа: http://protect.gost.ru/document.aspx?control=7&id=129 071
• 2. Дмитриенко П. В. Методика оценки эффективности систем мониторинга вычислительных ресурсов // Компьютерные исследования и моделирование 2012 Т. 4 № 3 С. 661−668 Режим доступа: http://crm.ics.org.ru/uploads/crmissues/crm_2012₃/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?1 536 480
• 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 год