Файл: Пояснительная записка на 92 страницах. Графическая часть на 4 листах. Допускается к защите Протокол заседания кафедры ат от 2020 г.pdf

37
Рисунок 3.1 – Общая архитектура приложения
Если при проектировании самой программы применяется модульный подход к программированию, что позволяет довольно легко модернизировать
SIEM-систему, просто заменяя один модуль другим при необходимости. То при проектировании самих модулей уже применяется объектно-ориентированный подход к программированию, это позволяет легко масштабировать каждый из модулей, добавляя новые сущности – классы, при необходимости.
Более подробная информация о ходе разработки каждого из модулей представлена ниже. Также ниже представлены алгоритмы работы модулей кор- реляции и прогнозирования.
3.2. Разработка модуля агрегации
Агрегация – это процесс объединения элементов в единую систему. При- менительно к разрабатываемой SIEM, этот термин означает интеграцию ин- формации с различных источников в единый формат, удобный для анализа мо- дулем корреляции [22]. В настоящем проекте в качестве единого формата вы- ступает набор JSON-файлов, конструируемый из log-файлов от различных ис- точников информации. Формат JSON был выбран не случайно, данный формат представления данных является одним из самых популярных, наряду с XML.
Также JSON формат крайне удобен для программного представления данных и легко читается человеком при просмотре исходного содержимого JSON файла.

38
Модуль агрегации состоит из совокупности классов унаследованных от одного общего класса. Этот общий класс является реализацией интерфейса все- го модуля. UML-диаграмма модуля агрегации представлена на рисунке 3.2.
Рисунок 3.2 – UML-диаграмма классов модуля агрегации
Многоточием обозначается пропуск некоторого количества классов, в угоду наглядности. Классов унаследованных от основного класса реализации может быть неограниченное количество, это позволяет добавлять сколь угодное число источников агрегации информации для новых признаков. Также на диа- грамме представлен класс пользовательских агрегаций. Спроектированный класс пользовательских агрегаций позволяет добавлять дополнительные источ- ники для сбора информации, не создавая дополнительных классов в коде. Этот класс является пользовательским инструментов внедрения дополнительных правил агрегации. Например, если на предприятии будет установлен СКУД, ко- торый хранить информации о ходе своей работы в log-файлах, то в SIEM- систему можно будет добавить правило, по которому она будет собирать ин- формацию из log-файлов системы контроля и управления доступом.

39
Теперь более подробно рассмотрим источники информации для агрегиро- вания, как уже было сказано выше, данными источниками выступают различ- ные log-файлы. По умолчанию используются log-файлы, которые являются стандартными для операционных систем семейства unix и log-файлы самых распространенных программных продуктов систем этого семейства.
Вот полный перечень используемых SIEM системой файлов логов [23]:
1.
/var/log/syslog(/var/log/messages) - содержит глобальный системный журнал, в котором пишутся сообщения с момента запуска системы, от ядра
Linux, различных служб, обнаруженных устройствах, сетевых интерфейсов и много другого ;
2.
/var/log/auth.log(/var/log/secure) — информация об авторизации пользователей, включая удачные и неудачные попытки входа в систему, а также задействованные механизмы аутентификации;
3.
/var/log/dmesg — драйвера устройств;
4.
/var/log/cron — Отчет службы crond об исполняемых командах и сообщения от самих команд;
5.
/var/log/faillog — Неудачные попытки входа в систему;
6.
var/log/kern.log — Журнал содержит сообщения от ядра и предупреждения, которые могут быть полезны при устранении ошибок пользовательских модулей встроенных в ядро;
7.
/var/log/lastlog — Последняя сессия пользователей;
8.
/var/log/httpd/(/var/log/apache2/) — Лог веб сервера Apache, журнал доступа находится в access_log, а ошибки — в error_log.
Как уже было сказано выше, в модуль агрегации встроена возможность добавления своих файлов логов для сбора информации из них. В отличие от стандартного расширения функционала, данная возможность предусматривает добавление дополнительных лог файлов без написания кода и является инстру- ментов пользователя разработанной системы мониторинга и управления собы- тиями информационной безопасности. Для этого предусмотрен специальный

40 конфигурационный файл aggr.json, в котором при помощи несложного синтак- сиса можно указать log-файл для сбора информации, и саму информацию, ко- торую нужно агрегировать при помощи регулярных выражений. В результате будет создан JSON-файл для модуля корреляции.
Примерный синтаксис конфигурационного файла:
{
―one-config‖:{
―result-json‖:‖apache2.json‖,
―parent-node‖:‖requests‖,
―key-regexp‖:‖
\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}‖,
―type-node‖:‖object‖,
―inner-cell‖:{
―type-node‖: ―string‖,
―key-value‖:‖time‖,
―parameter-regexp‖:‖
\d{4}:\d{2}:\d{2}:\d{2}‖,
―and-cell‖:{
―type-node‖:‖string‖,
―key-value‖:‖path‖,
―parameter-regexp‖:‖
(?:\s)\/.*(?:\sH)‖,
―and-cell‖:{
―type-node‖:‖string‖,
―key-value‖:‖response code‖,
―parameter-regexp‖:‖
(?:\"\s)\d{3}(?:\s)‖
}
}
}
}
}

41
При вводе выше описанных команд в конфигурационный файл aggr.json можно извлечь ip-адрес, дату поступления запроса, время поступления запроса, путь обращения и код ответа из файла access.log со следующим содержанием:
213.87.240.167 - - [20/May/2020:00:43:00 +0500] "GET / HTTP/1.1" 200 302 "-"
"Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0"
213.87.240.167 - - [20/May/2020:00:43:00 +0500] "GET /favicon.ico HTTP/1.1" 404 487 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0"
213.87.240.167 - - [20/May/2020:00:51:00 +0500] "GET /phpinfo.php HTTP/1.1"
404 487 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Fire- fox/68.0"
213.87.240.167 - - [20/May/2020:00:51:00 +0500] "GET /backup HTTP/1.1" 404 487 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0"
213.87.240.167 - - [20/May/2020:00:52:00 +0500] "GET /admin HTTP/1.1" 404 487
"-" "Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0"
213.87.240.167 - - [20/May/2020:00:52:00 +0500] "GET /cvs HTTP/1.1" 404 487 "-"
"Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0"
213.87.240.167 - - [20/May/2020:00:53:00 +0500] "GET /error_log HTTP/1.1" 404 487 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0"
213.87.240.167 - - [20/May/2020:00:54:00 +0500] "GET /htpasswd HTTP/1.1" 404 487 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0"
213.87.240.167 - - [20/May/2020:00:57:00 +0500] "GET /robots.txt HTTP/1.1" 404 487 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0"
Ниже приведен фрагмент созданного в результате работы модуля агрега- ции файла apache2.json:
{
―requests‖:{
―213.87.240.167‖:{
―time‖:‖00:51:00‖,
―path‖:‖favicon.ico‖,
―response-code‖:‖404‖

42
}
}
}
Содержимое файла apache2.json в дальнейшем будет использовано моду- лем корреляции для поиска инцидентов и событий ИБ.
После рассмотрения устройства и принципов работы модуля агрегации следует привести общую схему спроектированного модуля, представленную на рисунке 3.3.
Рисунок 3.3 – Структурная схема модуля агрегации
Как можно заметить по схеме, представленной выше, модуль агрегации также использует модуль для работы с JSON файлами. JSON модуль также яв- ляется разработанным вручную, о нем и о других модулях, напрямую не отно- сящихся к SIEM речь пойдет в конце раздела.

43
Корреляция применительно к SIEM-системам, это сопоставление различ- ных признаков некоторому симптому, который является событием информаци- онной безопасности.
Существуют сигнатурные (rule based) и бессигнатурные методы корреля- ции. Сигнатурные — те, в которые человек должен добавить некие правила определения инцидентов. Бессигнатурные — черный ящик, который сам отли- чает хорошее от плохого.
На практике применяются следующие [24]:

Statistical — сложный бессигнатурный метод корреляции событий, основанный на измерении двух или более переменных и вычислении степе- ни статистической связи между ними;

RBR Rule-based (pattern based) (HP ECS, IMPACT, RuleCore) — ме- тод, в котором взаимосвязи между событиями определяются аналитиками в заранее заданных специфических правилах;

CBR Codebook (case) based (SMARTS). Корреляция производится по подходящим векторам из предварительно заданной матрицы событий;

MBR model based reasoning (слишком большой MTTR) — метод ос- нован на абстракции объектов и наблюдения за ними в рамках модели;

Bayesian (BDR) — это, надо полагать, всем известный метод, не требующий особых разъяснений. На практике — неэффективен.

NMBR — Normalized model based reasoning. Схож с MBR, известен как baseline;

Graph based. Корреляция заключается в поиске зависимостей между системными компонентами (network devices, hosts, services) и построении графа на их основе;

Neural network based — идеологический метод. Нейронная сеть обучается для обнаружения аномалий в потоке событий.
В разрабатываемой SIEM-системе применяется Graph based подход [25].
Особенностью разрабатываемого модуля корреляции является сопостав- ление событий информационной безопасности симптомам векторов атак APT-

44 группировок. Таким образом, можно проследить конкретный тип атаки на ин- формационную систему.
В общем случае работа модуля корреляции сводится к тому, чтобы со- брать информацию с подготовленных JSON-файлов логов и принять решение о наличии зависимости между событиями информационной безопасности, если такая зависимость есть, то уведомить администратора информационной без- опасности о наличии инцидента ИБ.
Структура модуля корреляции похожа на структуру модуля агрегации.
Модуль корреляции также состоит из совокупности классов, унаследованных от общего класса, реализующего интерфейс корреляции. В данном модуле это также сделано для возможности масштабировать весь проект путем добавления корреляции по новым признакам или дополнением правил корреляции по уже существующим.
Ниже, на рисунке 3.4, представлена UML-диаграмма классов модуля кор- реляции:
Рисунок 3.4 – UML-диаграмма классов модуля корреляции

45
На диаграмме видно, что над модулем корреляции спроектирован мо- дуль-обертка, который принимает классы обнаруженных признаков и на их ос- нове строит структуру данных, известную, как граф.
Более подробно работа модуля корреляции выглядит так:
1.
Получение информации из JSON-файлов логов – на данном этапе происходит загрузка содержимого JSON-логов в оперативную память для дальнейшего использования в алгоритме поиска зависимостей;
2.
Проверка наличия симптомов событий информационной безопасности в содержимом загруженных JSON-логов;
3.
При обнаружении события информационной безопасности, информация о найденном событии ИБ помещается в специальный контейнер, который представляет из себя вершину будущего графа найденных симптомов;
4.
После обнаружения всех симптомов, осуществляется поиск зависимостей между найденными симптомами на основании схожести найденной информации и приоритете отдельных записей о событии информационной безопасности;
5.
При обнаружении зависимостей между несколькими симптомами модуль корреляции формирует уведомление об обнаружении инцидента ИБ и сохраняет найденную информацию в файле результата работы.
Рассмотрим действие модуля корреляции на упрощенном примере.
Пусть имеется три лог-файла:
1. Лог-файл с записями веб-сервера apache:
{
―requests‖:{
―213.87.240.167‖:{
―time‖:‖23:15:18‖,

46
―path‖:‖favicon.ico‖,
―response-code‖:‖404‖
},
}
}
2. Лог-файл с подключением по ssh:
{
―connections‖:{
―Alex‖:{
―time‖:‖23:25:12‖,
―destination-ip‖:‖213.87.240.167‖
},
…
―Nikita‖:{
―time‖:‖10:02:13‖,
―destination-ip‖:‖182.11.90.22‖
}
}
}
3. Лог-файл с перечнем запущенных программ пользователями в системе:
{
―users‖:{
―Alex‖:{
―run‖:{
―time‖:‖ 23:31:12‖
―program‖:‖tar‖,
―arg‖:‖-czcf /etc/‖
}
},

47
―Nikita‖:{
―run‖:{
―time‖:‖10:02:52‖
―program‖:‖ls‖,
―arg‖:‖.‖
}
…
}
}
Схематично можно представить информацию из log-файлов выше в виде следующей схемы (полагая, что количество запросов в с ip 213.97.240.167 к веб-серверу apache превышало некий допустимый лимит). Такая схема пред- ставлена на рисунке 3.5.
Рисунок 3.5 - Схематичное изображение событий ИБ

48
На представленном выше изображении видно, что последовательность действий пользователя Nikita похожа на действия легитимного пользователя, который удаленно подключается к своему рабочему аккаунту.
В то время как по цепочке действий человека, вошедшего под учетной записью Alex можно предположить, что был осуществлен взлом учетной запи- си пользователя Alex, затем содержимое папки /etc/ было заархивировано. Та- ким образом, после корреляции событий и обнаружении инцидента информа- ционной безопасности, формируется уведомлению о соответствующем инци- денте.
Помимо заранее заданных правил корреляции на основе векторов кибе- ратак, разработанный модуль корреляции, также как и модуль корреляции, позволяет добавлять свои правила нахождения событий информационной без- опасности в потоке log-файлов.
Для того, чтобы добавить обнаружение своего события, необходимо вне- сти изменения в конфигурационный файл corr.json.
Например, при вводе следующих изменений в конфигурационный файл, в файле с JSON-логами модуль корреляции попытается найти запись о пользова- теле Denis, совершившем вход в систему позднее 20:00.
Содержимое конфигурационного файла для поиска вышеперечисленных параметров:
{
"config":{
"config-path":"auth.json",
"type-config":"found",
"type-node":"object",
"key-value":"Denis|1",
"inner-condition":{
"type-node":"string",
"key-value":"action|0",
"parameter-value":"login|0",