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

49
"and-condition":{
"type-node":"string",
"key-value":"time|0",
"parameter-value":">|20:00:00|0"
}
}
}
}
В синтаксисе конфигурационного файла имеются следующие соглаше- ния:

сonfig-path – указывает путь до файла с JSON-логами;

type-config – указывает на тип конфигурационной записи.
Found обозначает поиск вхождения при соблюдении условий. Amount – поиск количества вхождений, при соблюдении прописанных условий;

type-node – указывает тип JSON-объекта, который нужно искать;

key-value - указывает значение ключа, по которому осуществляется поиск;

parameter-value
– указывает значение параметра, соответствующего ключу;

inner-condition - ключевое слово, позволяющее добавить дополнительное условие поиска, внутри JSON-объекта;

and-condition – ключевое слово, позволяющее добавить дополнительное условие поиска в том же JSON-объекте;

символ вертикальной черты ‗|‘ служит для добавления приоритета к ключу или параметру. Добавленный приоритет используется модулем корреляции для поиска зависимостей и оценки необходимости формирования уведомления о возможно инциденте информационной безопасности, если приоритет равен нулю, то информация, к которой добавлен такой приоритет не будет учитываться

50 при поиске зависимостей между симптомами, а симптом с таким приоритетом будет оказывать минимальное влияние на оценку необходимости формирования уведомления о развитии целевой атаки.
Помимо добавления приоритета, при помощи символа ‗|‘ можно указать условие сравнения значения внутри parameter-value или key-value.
Возможность добавления пользовательских условий корреляции позволя- ет внедрить в SIEM-систему поиск абсолютно любых симптомов и возмож- ность их корреляции, как со стандартными симптомами целевых атак кибер- группировок, так и с другими пользовательскими симптомами.
Общая схема модуля корреляции представлена на рисунке 3.6.
Рисунок 3.6 – Структурная схема модуля корреляции
По структурной схеме, представленной выше можно заметить, что для полноценной работы основной части модуля корреляции необходимо обра-

51 щаться к модулю JSON, а также формировать граф событий ИБ. Сам граф и со- вокупность составляющих его подграфов, представляют собой отдельные клас- сы, в которые инкапсулированы алгоритмы поиска взаимосвязей между обна- руженными событиями информационной безопасности.
Сам алгоритм поиска взаимосвязей между признаками реализовано в классе RecognitionCategory, представленном на UML-диаграмме.
3.4. Разработка модуля прогнозирования
Возможность предсказать дальнейшие действия злоумышленника, может помочь принять эффективные контрмеры для того, чтобы смягчить последствия атаки или полностью ее предотвратить. Для этого в разрабатываемую SIEM- систему был добавлен модуль прогнозирования.
Созданный модуль работает на основе собранной о симптомах информа- ции и базы данных MITRE | ATT&CK. После того, как модуль корреляции за- вершит построение графа симптомов и сформирует уведомление о соответ- ствующем инциденте информационной безопасности, модуль прогнозирования начнет проверку найденных признаков из вектора атаки, построенного на осно- ве графа симптомов. Каждому найденному событию информационной безопас- ности присваивается категория симптома из базы данных MITRE, далее идет проверка на совпадение со всеми занесенными в базу данных MITRE |
ATT&CK векторами атак. После проверки формируется предупреждение о наиболее вероятном типе целевой атаки. Если найденные симптомы относятся к нескольким атакам, то формируется сообщение о каждой из них. Так как все симптомы каждой из атак уже исследованы и занесены в базу данных MITRE, то нетрудно выяснить дальнейшее развитие атаки по уже обнаруженным при- знакам.
Схематичное представление обнаруженных симптомов и прогнозирова- ния дальнейшего развития целевой атаки APT1 представлено на рисунке 3.7.

52
Рисунок 3.7 – Схематичное представление атак APT1 и APT3
Как можно заметить по изображению выше, прогнозирование дальней- ших действий не связано с какой-то одной атакой, оно, при прочих равных, от- носится и к другим целевым атакам, большинство признаков которых было об- наружено в ходе корреляции.
Структурно, модуль прогнозирования представляет собой один класс, ко- торый принимает на вход подграф обнаруженных симптомов и сверяет их с информацией из файла, в котором содержаться признаки APT-атак, и на выходе возвращает вектор, состоящий из типов атак и соответствующих им вариантов развития атаки. UML-диаграмма модуля прогнозирования представлена на ри- сунке 3.8.

53
Рисунок 3.8 – UML-диаграмма классов модуля прогнозирования
Общая схема модуля прогнозирования представлена на рисунке 3.9.
Рисунок 3.9 – Структурная схема модуля корреляции
На схеме выше видно, что модуль прогнозирования, также как и осталь- ные модули SIEM-системы включается в основной модуль программы, куда и возвращает результат своей работы.
3.5. Разработка вспомогательных модулей
Как можно было заметить по схемам, приведенным выше, в SIEM- систему помимо основных модулей также встроены и вспомогательные моду- ли, выполняющие утилитарные для работы остальных модулей функции. Таки-

54 ми модулями являются JSON-модуль и модуль для работы с представлением времени.
3.5.1. Разработка модуля для работы с JSON файлами
Так как основные части разработанной системы мониторинга и управления событиями информационной безопасности работают, извлекая и записывая информацию в JSON формате, было принято решение разработать модуль, предоставляющий удобный интерфейс для работе с JSON файлами.
UML-диаграмма классов модуля представлена на рисунке 3.10.
Рисунок 3.10 – UML-диаграмма классов JSON-модуля
Набольший интерес из представленных на диаграмме объектов представляет структура JsonContainer. Эта структура инкапсулирует в себе всю информацию о JSON объектах, таких как узлы, массивы и строки. Эта структура данных представляет собой дерево, вершинами которого являются объекты JSON, а ребрами – отношения между узлами.
Схематично это показано рисунке 3.11.

55
Рисунок 3.11 – Структурная схема класса JsonContainer
На представленной выше структурной схеме, видно, что такой подход позволяет конструировать JSON объекты любой степени вложенности.
3.5.2. Разработка модуля для работы с представлением времени
Большинство записей в log-файлах дополняются временными метками, которые позволяют определить точно время произошедшего события информа- ционной безопасности. Для удобства представления этого времени, как объекта и предоставления интерфейса для взаимодействия с ним, был также разработан модуль для работы со временем.
UML-диаграмма представлена на рисунке 3.12.
Рисунок 3.12 – UML-диаграмма классов и объектов Date-модуля

56
Разработанный модуль необходим для решения задач по конвертации строкового значения времени в объект, арифметических операций со време- ним, в том числе сравнение двух объектов типа Time, что может быть удобно при поиске взаимосвязи между событиями информационной безопасности по времени.
На рисунке 3.13 представлена подробная структурная схема разработан- ной SIEM-системы.
Рисунок 3.13 – Структурная схема системы мониторинга и управления инци- дентами информационной безопасности
На схеме демонстрируется взаимосвязь как основных, так и вспомога- тельных модулей между собой. Для упрощения и наглядности были опущены элементы схемы, которые отвечают только за считывание данных из файла и запись данных в файл.

57
3.6. Выводы по разделу
Во время разработки SIEM-системы основной был сделан упор на удо- влетворении требований, сформированных в предыдущем разделе. Это позво- ляет сконцентрировать усилия при поиске событий информационной безопас- ности именно на обнаружении целевой атаки. Помимо этого, система монито- ринга способна прогнозировать дальнейшее развитие APT-атаки, что суще- ственно помогает администратору информационной безопасности в попытках предпринять своевременные меры как по устранению последствий от уже про- изошедших этапов компрометации информационной системы, так и принятию мер по блокированию дальнейшего развития атаки.
Такой подход к проектированию системы мониторинга безопасности поз- воляет сократить время на анализе вектора атаки, что приводит к повышению скорости ответа на несанкционированные действия.
В следующем разделе будет дано объяснение относительно нюансов ра- боты каждого из модулей.

58
4. Алгоритм работы программы
После описания работы всех модулей, следует рассмотреть их работу в комплексе, а также описать некоторые аспекты работы каждого из модулей от- дельно.
Условно алгоритм работы всей SIEM системы можно разделить на сле- дующие несколько этапов:

Обход и сбор информации со стандартных системных log-файлов, формирование результатов сбора информации в соответствующие JSON- файлы;

Обход и сбор информации с log-файлов, по прописанным в конфигурационном файле правил агрегации информации;

Поиск событий информационной безопасности в сформированных log-файлах;

Построение графа симптомов на основе найденных событий информационной безопасности;

Поиск взаимосвязи между симптомами;

Формирование уведомления о возможном инциденте информационной безопасности;

Прогнозирование дальнейших возможных действий злоумышленника и уведомление о типе атаки/атак.
Схема алгоритма представлена в Приложении Б.
4.1. Алгоритм корреляция событий ИБ
В модуле корреляции разработанной SIEM-системы используется graph- based метод корреляции. На практике это означает, что во время работы модуля корреляции будет формироваться граф из обнаруженных событий информаци- онной безопасности. В сформированном графе сами симптомы будут являться вершинами, а взаимосвязи между ними – ребрами.

59
Подход с графами удобен тем, что можно быстро, относительно полного перебора, найти взаимосвязь между двумя симптомами. Для этого используется такой алгоритм поиска в графах, как поиск в глубину.
Поиск в глубину — один из методов обхода графа. Стратегия поиска в глубину, как и следует из названия, состоит в том, чтобы идти «вглубь» графа, насколько это возможно. Алгоритм поиска описывается рекурсивно: перебира- ем все исходящие из рассматриваемой вершины рѐбра. Если ребро ведѐт в вер- шину, которая не была рассмотрена ранее, то запускаем алгоритм от этой не- рассмотренной вершины, а после возвращаемся и продолжаем перебирать рѐб- ра. Возврат происходит в том случае, если в рассматриваемой вершине не оста- лось рѐбер, которые ведут в нерассмотренную вершину [26].
Скорость работы алгоритма поиска в глубину в среднем равна O(E + V), где E – количество вершин графа, а V – количество ребер между всеми верши- нами[26].
Для сравнения полный перебор для нахождения взаимосвязи одной вер- шины с другой занял бы O(n * m), если представить совокупность вершин в ви- де матрицы со сторонами n и m. Для поиска взаимосвязи для каждой вершины, полный перебор уже будет занимать в среднем O(n^2 * (n*m)) = O(m * n^5), в то время как для выявления взаимосвязей между симптомами, применяя алго- ритм поиска в глубину, в среднем будет потрачено O(n^3 + m * n^2).
4.2. Алгоритм прогнозирования событий ИБ
После формирования уведомления о возможном инциденте, модуль кор- реляции формирует вектор взаимосвязанных симптомов и передает его модулю прогнозирования. Модуль прогнозирования, в свою очередь, получает данный вектор, извлекает из него симптомы и сопоставляет их с симптомами из матри- цы признаков атак группировок APT. Сопоставляю симптомы, модуль прогно- зирования пытается выяснить наиболее вероятный тип атаки. Расчет вероятно- сти происходит достаточно тривиальным способом, а именно расчетом отно- шения числа обнаруженных симптомов к числу симптомов конкретной атаки.
После вычисления наиболее вероятного типа атаки, из базы данных признаков

60 собираются оставшиеся, еще не обнаруженные симптомы и информация о них выводится в соответствующем уведомлении пользователю.

61 5. Имитационное моделирование
После стадии разработки необходимо проверить работоспособность спроектированной SIEM-системы, а именно возможности обнаружения целевой атаки, способности указать тип атаки и оценить возможные дальнейшие дей- ствия злоумышленника.
Для имитационного моделирования, была выбрана имитация атаки
APT41.
APT41 – это спонсируемая Китаем группировка, занимающаяся шпиона- жем и атаками на отрасли в сфере здравоохранения, телекоммуникаций, техно- логий и видеоигр в 14 странах [27].
5.1. Признаки APT41 и их описание
Признаки атаки APT41 представлены во всех группах симптомов, начи- ная от группы «начального доступа»(initial access) и заканчивая группой «кон- троль»(command and control). Для моделирования атаки APT41 следует кратко разобраться с ее симптомами:
1. External Remote Services – данный симптом иллюстрирует подключение злоумышленника через удаленный внешний сервис с возможностью закрепления внутри системы. Такими сервисами могут быть ssh или vpn;
2. Spearphishing Attachment – это вариация фишинговой атаки, которая заключается в отправке вредоносного программного обеспечения, прикрепленного к почте. Это могут быть зараженные MS office документы, исполняемые PDF файлы или архивированные файлы;
3. Valid Accounts – данный симптом представляет собой авторизацию нарушителя безопасности при помощи учетных данных легитимных пользователей;
4. Command-Line Interface – это использование злоумышленником интерфейса командной строки для взаимодействия с операционной системой;