ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ
УДК 004.056.53
Принцип создания правил реагирования для OSSEC
Гузарев А.С.
Аннотация. Постановка задачи: рассматривается создание правил реагирования для многоагентной системы обнаружения вторжений OSSEC, применяемой для защиты автоматизированных комплексов связи от несанкционированного доступа. Целью работы является описание принципа создания правил для систем обнаружения вторжений, обрабатывающих регистрируемые события в соответствии с классом защищенности автоматизированных систем 1Б. Используемые методы: теоретический и практический заделы в области обеспечения безопасности информации с использованием объектно-ориентированного принципа при формировании групп правил. Новизна состоит в применении нового принципа создания правил декодирования и реагирования на регистрируемые события различных типов и форматов, обеспечивающего возможность внесения изменений в отдельные группы правил без необходимости изменения остальных. Применение такого принципа позволяет сократить время обработки или необходимые вычислительные ресурсы. Апробация предложенного принципа была проведена в рамках работ по созданию Многофункционального интегрированного комплекса связи. Результат заключается в наборе правил для программного средства OSSEC, обеспечивающих реагирования на все события в соответствии с требованиями руководящего документа ФСТЭК на автоматизированные системы в части защиты от несанкционированного доступа к информации. Практическая значимость: предложенный принцип создания правил применим для ряда многоагентных систем обнаружения вторжений, включая OSSEC, Wazuh и OSSIM. Создаваемые правила могут обеспечить обработку различных форматов журналов регистрации событий.
Ключевые слова: система обнаружения вторжений, система защиты, информационная безопасность, несанкционированный доступ.
Введение
Предприятие в процессе разработки автоматизированных комплексов связи (АКС) подводных лодок [1], надводных кораблей и различных проектов [2], наземных и корабельных средств авиационной связи провело разработку подсистемы обеспечения безопасности информации (ОБИ). Подсистема была испытана в 2017-2018 гг. в составе многофункционального интегрированного комплекса корабельной связи (МИКС).
Разработка комплекса проводилась в инициативном порядке и позволила подвести промежуточные итоги [3] по направлению создания автоматизированного рабочего места (АРМ) администратора ОБИ. АКС является автоматизированной системой (АС), подлежащей защите от несанкционированного доступа (НСД) к информации по классу защищенности 1Б [4]. В перечне регистрируемых действий присутствуют аутентификации пользователей, печати документов, запуска и завершения программных средств, операции доступа к защищаемым файлам и узлам сети, нарушения целостности, изменения полномочий субъектов доступа. Все попытки нарушения защиты должны сигнализироваться на АРМ ОБИ. Реализация данного требования была выполнена путем централизованного сбора и анализа журналов протоколирования (журналов аудита) операционных систем (ОС), служб и специального программного обеспечения (СПО).
Технические решения подобного рода принято называть многоагентыми системами обнаружения вторжений (МСОВ) [5]. Была организована трехуровневая архитектура МСОВ, содержащая агенты регистрации, систему сбора и реагирования, интерфейс администратора ОБИ. Проблеме выбора программной реализации МСОВ посвящена работа [6]. По
совокупности показателей, для решения задачи по защите АКС от НСД, был выбран OSSEC, позволяющий анализировать журналы, проверять целостность, обнаруживать и активно реагировать на попытки нарушения НСД. В функциональность заложена возможность анализа журналов, как уровня ОС, так и отдельных приложений.
МСОВ OSSEC входит в набор модулей ОС специального назначения Astra Linux® Special Edition, применяемой на серверных устройствах МИКС. Программное средство состоит из трех компонентов, соответствующих трехуровневой архитектуре. МСОВ была развернута в сети АКС. Поскольку базовые правила OSSEC не удовлетворяли нормативным требованиям класса 1Б, были ориентированы на небольшой набор параметров и ограниченное количество событий, а также трудно изменяемы, то было принято решение о создании собственного набора правил, разрабатываемых по новому принципу.
В статье приведено формализованное описание алгоритма работы МСОВ, изложены примененный принцип и логика создания правил реагирования на НСД.
Формализация работы МСОВ
От агентов в систему сбора и реагирования поступают сообщения о произошедших событиях с различными форматами и родом информации. Образуемое множество сообщений E будем считать бесконечным:
E = {E>, E2,...Et). (1)
Информация в сообщениях E , как правило, передается в виде единой текстовой строки без дополнительных параметров. Дальнейшая работа с подобными сообщениями требует проведения синтаксического анализа.
В качестве примера сообщения E будем использовать сообщение, возникающее в
результате удаленного подключения к устройству по протоколу ssh, определенному в RFC 4252.
Jul 4 08:40:57 arml sshd[5990]: Accepted passwordfor userl9 from 192.168.254.112 port 55525 ssh2
Сообщение автоматически регистрируется средствами операционной системы и имеет формат syslog. В приведенном примере подключение было выполнено к устройству arm1 с устройства, имеющего zp-адрес 192.168.254.112, для авторизации была использована учетная запись user19.
Первичная обработка сообщений строится по следующему принципу: поступающее сообщение декодируется, нормализуется, затем применяются правила реагирования и исключения. Данные правила применяются последовательно, если сообщение не соответствует ни одному правилу, то оно отбрасывается.
Процесс декодирования заключается в разделении исходной строки на статические St и переменные VI части в строгом порядке, соответствующем правилу декодирования Rd :
Rd} = {StY ,Vll, St2 ,Vl2 „...St; ,Vlk,...}. (2)
Правила декодирования Rd применяются по порядку до первого полного совпадения статических частей строки. Если совпадений не найдено, то сообщение будет пропущено. Множеству переменных частей {Vl } ставится в соответствие множество параметров, такое,
что Prk ^ Vlk. Образованный кортеж ({Prk},{Vlk} является декодированным сообщением. Функцию декодирования Fd^ode сообщения можно записать в следующем формализованном виде:
Fdecode(E, ,{Rdj}) = ({Prk },{Vlk }). (3)
Результат декодирования Fd^ode представленного ранее сообщение E будет выглядеть
следующим образом:
**Phase 1: Completedpre-decoding.
full event: 'Jul 4 08:40:57 arm1 sshd[5990]: Accepted password for user19 from 192.168.254.112port 55525 ssh2' hostname: 'arm1' program_name: 'sshd'
log: 'Acceptedpassword for user19 from 192.168.254.112 port 55525 ssh2'
**Phase 2: Completed decoding.
decoder: 'D_authentification_success'
dstuser: 'user19'
srcip: '192.168.254.112'
srcport: '55525'
proto: 'ssh2'
Как видно из листинга работы OSSEC, декодирование имеет две фазы: предварительное декодирование (pre-decoding) и декодирование по правилу «Dauthentificationsuccess».
Предварительное декодирование позволяет определить пары {Prk},{Vlk}, общие для формата syslog, включая наименование устройства, зарегистрировавшего событие и программное средство. Правила предварительного декодирования находятся в коде программы и применяются всегда. Правила декодирования разрабатываются в зависимости от требований проекта.
Декодирование по правилу позволяет определить пары {Prk },{Vlk}, специфичные для программного средства, действия которого были зарегистрированы. Для sshd декодированы следующие параметры:
используемая учетная запись (user 19);
zp-адрес устройства с которого было выполнено подключение (192.168.254.112); порт удаленного устройства, используемый для подключения (55525); протокол, использованный для удаленного подключения (ssh2).
После успешного декодирования сообщения выполняется поиск правила реагирования. Правила реагирования Rr содержат пары параметр PrRr и его значение VlRr. Соответствием правилу Rri сообщения Ei , имеющего параметры {Ргк} и значения {Vlк}, является выполнение следующего условия:
{{PrRr },{VlRr} £ ({Ргк },{Vlk })• (4)
Результат работы OSSEC по правилу реагирования Rr на сообщение E , будет
выглядеть следующим образом:
**Phase 3: Completed filtering (rules). Rule id: '5501' Level: '2'
Description: 'Аутентификация пользователя' **Alert to be generated.
Реакцией МСОВ на сообщение Ei является генерация сообщения об успешной аутентификации пользователя с уровнем критичности. Кроме генерации сообщения правило может содержать автоматические действия по блокировке zp-адресов или портов. Сообщение МСОВ включает в себя:
сообщение Ej в изначальном виде;
пары {Prk },{Vlk } полученные в результате декодирования;
номер сработавшего правила Rrt;
уровень критичности (Level);
текст описания события (Description).
Таким образом, функция МСОВ Rri заключается в преобразовании событий Ei в виде строки в набор формализованных параметров ({Ргк },{Мк}), который может быть использован для дальнейшей обработки, анализа или визуализации.
Flds (E ) = {{Prlds},{Vllds}). (5)
Сообщения МСОВ сохраняются в журнале работы OSSEC, в зависимости от настройки, могут дополнительно отправляться в базу данных или удаленный сервер.
Принцип разработки правил декодирования и реагирования
Работа МСОВ OSSEC с базовыми правилами представляет собой последовательный перебор правил декодирования (декодеров), потом правил реагирования, что соответствует линейной алгоритмической сложности O(n).
Сокращение времени операций поиска правил декодирования Rd и реагирования Rr , предлагается объединением правил в группы, подгруппы и цепочки штатными возможностями OSSEC. При этом, декодеры предлагается разделять на родительские и дочерние, а правила реагирования - на группы примитивов и группы событий. Соответствующий порядок обработки сообщений приведен на рис. 1. Пример следования сообщения по правилам обозначен пунктирными линиями.
Сообщение 1 Сообщение 2 ки
Сообщение i
Родительские декодеры
Декодер
Декод
ер
Декодер
Дочерние декодеры
Декодер
Декодер
X
У
Группы примитивов
-у/
Примитив
Примитив
Примитив
Групп ы событий
Событие
Событи
Событие
Событие
Событие
Событие
Событие
Синтаксический анализ
Группирование событий
Правила реагирования
Рис. 1. Соответствующий порядок обработки сообщений
Время декодирования напрямую зависит от длинны строки, количества статических и переменных V частей и количества правил декодирования . Сокращение
затрачиваемого времени может быть достигнуто путем перераспределения порядка правил и разделением на родительские и дочерние декодеры.
Порядок включения декодеров должен содержать наиболее часто срабатываемые правила вначале, и наименее востребованные в конце. По возможности, декодеры должны быть составлены так, чтобы строго советовать форматам сообщений.
Каждое программное средство или их группа, если они разработаны по одинаковому принципу, при создании сообщений придерживаются общего формата подставляя контекст в зависимости от ситуации. Родительские декодеры Rd parent должны определять программное
средство и основной тип сообщений. Дочерние декодеры Rdchild должны непосредственно
содержать статические St и переменные Vl части для декодирования. Первым шагом будет найден родительский декодер, вторым шагом будет найден дочерний декодер из ограниченного множества. Функцию декодирования Fd^ode сообщения можно переписать в виде композиции:
Fdecode = Rd parenP Rd child ■ (6)
Пример родительского и дочерних декодеров представлен ниже: <decoder name="D_authentification_success"> <program_name>login\sshd</program_name> <prematck>ALOGIN ON\AAccepted password for</prematch> </decoder>
<decoder name="D_authentification_success_ch1">
<parent>D_authentification_success</parent>
<program_name>login</program_name>
<prematck>ALOGIN ON</prematch>
<regex>LOGIN ON \S+ BY (\S+)</regex>
<order>dstuser</order>
</decoder>
<decoder name="D_authentification_success_ch3"> <parent>D_authentification_success</parent> <program_name >sshd</program_name > <prematch>AAccepted password for</prematch> <regex>A (\S+) from (\S+)port (\d+) (\S+)</regex> <order>dstuser,srcip, srcport,proto</order> </decoder>
В приведенном примере, родительский декодер «D authentification success» будет срабатывать только на успешные операции удаленной и локальной аутентификации пользователя. При этом, если программное средство не соответствует «login» или «sshd», алгоритм сразу перейдет к следующему родительскому декодеру без проверки соответствия регулярному выражению из тега «prematch». Дочерние декодеры «D_authentification_success_ch1» и «D authentification success ch^y определяются по тегу «parent». Поиск дочернего декодера выполняется по названию программного средства и по регулярному выражению сообщения. После того как найден первый подходящий дочерний декодер, выполняется операция декодирования F .
Такой принцип составления правил позволяет избежать ситуации полного перебора и сократить количество регулярных выражений, по которым пройдется алгоритм.
OSSEC обеспечивает возможность определения порядка поиска правил реагирования за счет групп и порядковых номеров правил. Предлагаемый принцип строится на идее формирования групп правил на основе декодеров и дальнейшей работе с правилами в пределах заданной группы в порядке следования.
Поскольку целью сбора сообщений является выявление несанкционированных действий, то группирование правил возможно по типу регистрируемого событий. В таком
случае, первая группа правил, называемая примитивами Rr , должна соответствовать одному или нескольким декодерам и определять тип события, например, «успешная авторизация», «неправильный пароль или пользователь» и другие. При этом, одни и те же декодеры могут входить в разные примитивы.
Вторая группа правил, называемая событиями Rr , служит для конкретизации зарегистрированных действий и реагирования, например, «неправильно введенный пароль при авторизации через ssh», «вход заблокированным пользователем» и др. При этом, правила группы событий могут делиться на базовые, которые должны отработать по умолчанию, и уточняющие, отрабатывающие при определенных значениях Vlг параметров Ргг. Пример групп правил примитивов и событий представлен ниже: <group name = "PMTV_auth_ok"> <rule id= "5501" level= "2">
<decoded_as>D_authentification_success</decoded_as> <description>Аутентификация nonb3oeamenH</description> </rule> </group>
<group name = "EVNT_auth_session"> <rule id= "5511" level= "2"> <if_group>PMTV_auth_session</if_group> <program_name>login</program_name>
<description> Успешный вход в систему в текстовомрeжимe</description>
</rule>
... </group >
Приведенный выше пример содержит примитив «PMTVauthok», соответствующий одному декодеру «Dauthentificationsuccess». Примитив может быть использован для генерации события «по умолчанию», если в группе событий не оказалось подходящего правила. Правила группы событий «EVNT_auth_session» должны обрабатываться только при срабатывании примитива, указанного в теге «if_group». Они выполняют зхадачу классификации события и уточнения уровня критичности. Порядок применения правил определяется идентификатором правила id. Правила могут объединяться в цепочки посредством применения тега «if sid», а также содержать исключающие правила. Таким образом, формула (5) может быть переписана в следующем виде:
F,ds = Fdecode ° RrPVTV ° RrEVNT ■ (7)
Такой подход позволяет объединять в примитивы сообщения от разных программных средств и создавать правила событий независимо от типов и форматов. Вместе с этим, обеспечивается классификация событий, позволяющая более точно определить характер действий в системе.
Выводы
1. Обеспечение требований по защите АКС от НСД по классу защищенности АС 1Б может быть выполнено за счет использования МСОВ OSSEC, входящей в состав ОС специального назначения Astra Linux® Special Edition. Недостатком данной системы является трудность расширения базы правил реагирования. Регистрируемые события имеют различные типы и форматы, что может потребовать переработку как правил декодирования, так и правил реагирования.
2. Предложенный в статье новый принцип создания правил решает две проблемы. Во-первых, за счет введения объектно-ориентированного подхода правила разбиваются на уровни, задача по изменению правил сводится к редактированию отдельных сущностей. Во-вторых, разделение правил на группы и подгруппы сокращает множество в котором ищутся
правила, что снижает алгоритмическую сложность с линейной O(n) до логарифмической O(log n), сокращает время поиска и объемы вычислительных ресурсов.
3. Алгоритм работы OSSEC и принцип создания правил были описаны в формализованном виде и могут быть использованы при работе с другими МСОВ аналогичного типа.
4. Подсистема ОБИ апробирована в рамках работ по созданию МИКС, прошедшего государственные испытания.
5. Предложенных принцип создания правил обеспечивает работу с различными типами и форматами событий, разработанная подсистема ОБИ применима не только для АКС, но и для других распределенных автоматизированных систем, включая автоматизированные системы общего назначения.
Литература
1. Николашин Ю.Л. и др. Интегрированный комплекс связи надводного корабля. Патент РФ на изобретение №2548023 от 18.03.2015.
2. Николашин Ю.Л. и др. Телекоммуникационный комплекс корабельной связи. Патент РФ на полезную модель №133376 от 10.10.2013.
3. Гузарев А.С. Применение виртуализации для безопасной разработки элементов автоматизированных систем / Труды НИИ ОСИС ВМФ, ВМА. Научно-технический сборник статей и докладов «Интеллектуальные разработки в интересах строительства и развития ВМФ». СПб. 2018. С. 447-453.
4. Руководящий документ Гостехкомиссии России «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации». М.: ГТК РФ, 1992. 20 с.
5. Волошин Б.В., Жуков В.Г. Применение многоагентных систем в задаче построения системы обнаружения инцидентов информационной безопасности // Актуальные проблемы авиации и космонавтики. 2012. №8.
6. Астаулов Р.А., Тимохович А.С. Повышение защищенности информационной системы путем реализации мер по обнаружению вторжений уровня узла // Наука и образование сегодня. 2017. №6 (17).
References
1. Nikolashin Y.L. et al. Integrirovannyj kompleks svyazi nadvodnogo korablya [Integrated communication complex of surface ship]. Patent RU №2548023. Publ.18.03.2015. (In Russian).
2. Nikolashin Y.L. et al. Telekommunikacionnyj kompleks korabel'noj svyazi [Telecommunication complex of ship communication]. Patent na poleznyju model' RF [The patent for useful model RU] No.133376. Publ. 18.03.2015. (In Russian).
3. Guzarev A.S. Primenenie virtualizacii dlya bezopasnoj razrabotki elementov avtomatizirovannyh sistem [Application virtualization for secure development of elements of automated systems]. Trudy NII OSIS VMF, VMA.Nauchno-tekhnicheskij sbornik statej i dokladov «Intellektual'nye razrabotki v interesah stroitel'stva i razvitiya VMF» [Researches NII OSIS of the Navy, military medical Academy.Scientific and technical collection of articles and reports "Intellectual development for the construction and development of the Navy."]. - Saint-Petersburg -2018. - P. 447-453. (In Russian).
4. Rukovodyashchij dokument Gostekhkomissii Rossii [Guidance document of the Russian state technical Commission] "Avtomatizirovannye sistemy. Zashchita ot nesankcionirovannogo dostupa k informacii. Klassifikaciya avtomatizirovannyh sistem i trebovaniya po zashchite informacii" [Automated systems. Protection against unauthorized access to information. Classification of automated systems and information security requirements]. - Moscow.: GTK RF [state customs Committee of the Russian Federation], 1992. - 20 P. (In Russian).
5. Voloshin B.V., Zhukov V.G. Primenenie mnogoagentnyh sistem v zadache postroeniya sistemy obnaruzheniya incidentov informacionnoj bezopasnosti [The use of multi-agent systems in the task of building an information security incident detection system]. Aktual'nye problemy aviacii i kosmonavtiki [Actual problems of aviation and cosmonautics]. 2012. No. 8. (In Russian).
6. Astaurov R.A., A.S. Povyshenie zashchishchennosti informacionnoj sistemy putem realizacii mer po obnaruzheniyu vtorzhenij urovnya uzla [Timokhovich improving the security of information systems through the implementation of measures for intrusion detection level of the node] // Nauka i obrazovanie segodnya [Science and education today]. 2017. No. 6 (17). (In Russian).
Статья поступила 19 июля 2019 г.
Информация об авторе
Гузарев Антон Сергеевич - Начальник отдела ПАО «Интелтех».
Тлф.: 8(812) 448-96-65. E-mail: a.guzarev@ntc1.inteltech.ru.
Адрес: 197342, Россия, г. Санкт-Петербург, ул. Кантемировская, дом 8
The principle of creating response rules for OSSEC
A.S. Guzarev
Annotation. Problem statement: we consider the creation of response rules for multi-agent system for detection of intrusions OSSEC, used to protect automated communication systems from unauthorized access. The aim of the work is to describe the principle of creating rules for intrusion detection systems that process recorded events in accordance with the security class of automated systems 1B. Methods used: theoretical and practical groundwork in the field of information security using the object-oriented principle in the formation of groups of rules. The novelty consists in the application of a new principle of creating rules for decoding and responding to recorded events of various types and formats, providing the ability to make changes to individual groups of rules without the need to change the rest. The application of this principle allows to reduce the processing time or necessary computing resources. Testing of the proposed principle was carried out as part of the work on the creation of the MIKS. The result is a set of rules for the OSSEC software tool that ensure response to all events in accordance with the requirements of the FSTEC Russia guidance document for automated systems in terms of protection against unauthorized access to information. Practical relevance: the proposed rule-making principle is applicable to a number of multiagent intrusion detection systems, including OSSEC, Wazuh and OSSIM. The rules that you create can handle a variety of event log formats.
Keywords: intrusion detection system, security system, OSSEC, information security, unauthorized
access.
Information about Author
Guzarev Anton Sergeevich - Department manager of PJSC «Information Telecommunication Technologies». Tel.: 8(812) 448-96-65. E-mail: a.guzarev@ntc1.inteltech.ru. Address: 197342, Russia, Saint-Petersburg, Kantemirovskaya, 8.
Для цитирования: Гузарев А.С. Принцип создания правил реагирования для OSSEC // Техника средств связи. 2019. № 3 (147). С. 77-84.
For citation: Guzarev A.S. The principle of creating response rules for OSSEC. Means of communication equipment. 2019. No 3 (147). P. 77-84. (In Russian).