Разработка системы мониторинга безопасности предприятия ООО «Неоматика» на основе модели векторов кибератак. Пояснительная записка на 92 страницах. Графическая часть на 4 листах. Допускается к защите Протокол заседания кафедры ат от 2020 г
 Скачать 2.26 Mb.
|
|
3.3. Разработка модуля корреляции Корреляция – это один из основных терминов теории вероятности, пока- зывающий меру зависимости между двумя и более случайными величинами. 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", 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. Сопоставляю симптомы, модуль прогно- зирования пытается выяснить наиболее вероятный тип атаки. Расчет вероятно- сти происходит достаточно тривиальным способом, а именно расчетом отно- шения числа обнаруженных симптомов к числу симптомов конкретной атаки. После вычисления наиболее вероятного типа атаки, из базы данных признаков |