Разработка системы мониторинга безопасности предприятия ООО «Неоматика» на основе модели векторов кибератак. Пояснительная записка на 92 страницах. Графическая часть на 4 листах. Допускается к защите Протокол заседания кафедры ат от 2020 г
 Скачать 2.26 Mb.
|
|
2.2 Анализ векторов кибератак APT группировок APT дословно переводится как устойчивая угроза, или же целе- вая/направленная кибератака. Применительно к кибергруппировкам термин 28 APT трактуется как - противник, обладающий современным уровнем специ- альных знаний и значительными ресурсами, которые позволяют ему создавать возможности для достижения целей посредством различных векторов нападе- ния (например, информационных, физических и обманных) [11]. Одной из таких группировок является группировка APT37. Группировка APT37 также известная как Reaper, Group123 и ScarCruft работает, по меньшей мере, с 2012 года. Ранее хакеры обратили на себя внимание исследователей безопасности, проведя серию кибератак, в которых эксплуатировалась уязви- мость нулевого дня в Adobe Flash Player. Цели APT37 предположительно сов- падают с военными, политическими и экономическими интересами Северной Кореи. Главным образом деятельность группировки сосредоточена на государ- ственных и частных структурах в Южной Корее, включая правительственные, оборонные, военные и медиа-организации. В 2017 году APT37 расширила гео- графию своих атак на Японию, Вьетнам и Ближний Восток. В список целей группировки входят организации в области химической, обрабатывающей, ав- томобильной и аэрокосмической промышленности, а также компании, работа- ющие в сфере здравоохранения. Одной из жертв хакеров на Ближнем Востоке стал поставщик телекоммуникационных услуг, который должен был заключить соглашение с правительством Северной Кореи. После того, как сделка сорва- лась, APT37 атаковала ближневосточную компанию, предположительно, пыта- ясь собрать информацию. APT37 эксплуатирует ряд уязвимостей в Flash Player и корейском текстовом редакторе Hangul Word Processor для доставки различ- ных типов вредоносных программ, включая вредонос RUHAPPY, инструмент для проникновения CORALDECK, загрузчики GELCAPSULE и HAPPYWORK, установщики MILKDROP и SLOWDRIFT, программу для хищения информа- ции ZUMKONG, инструмент для захвата звука SOUNDWAVE, а также множе- ство различных бэкдоров, в том числе DOGCALL, KARAE, POORAIM, WIN- ERACK и SHUTTERSPEED [12]. Такую направленную кибератаку APT-группировок называют вектором атаки. В результате реализации такого вектора атаки появляется инцидент ин- 29 формационной безопасности, отдельные же этапы реализации вектора атаки можно считать событиями информационной безопасности, исходя из определе- ний, приведенных в ГОСТ Р ИСО/МЭК ТО 18044-2007 [13]. 2.2.1. Категорирование событий информационной безопасности Сегодня существуют сервисы, которые категорируют события информа- ционной безопасности из векторов кибератак. Такие сервисы рассматривают каждую направленную атаку с точки зрения признаков или же симптомов, ко- торые подразделяются по категориям. Одним из таких сервисов является MI- TRE | ATT&CK. Данный сервис представляет собой базу данных об техниках и приемах проникновения злоумышленниками в информационные системы, базирующуюся на общемировых исследованиях. Сервис MITRE | ATT&CK(далее MITRE) подразделяет вектор атаки APT на 12 групп симпто- мов[АОК-1- 01у]: 1. initial access(начальный доступ) - Это попытки злоумышленника попасть в сеть организации. Начальный доступ состоит из методов, которые используют различные векторы входа, чтобы получить "точку опоры" в сети. Эти методы, используемые для получения "точки опоры" в сети, включают фишинг и использование программных уязвимостей на публичном веб-сервисе [14]; 2. execution(исполнение) - Это попытки злоумышленника запустить вредоносный код. Исполнение состоит из методов, которые в результате позволяют злоумышленнику запустить код на локальной или удаленной системе. Методы, которые позволяют запустить вредоносный код часто сопряжены с методами других групп, для достижения всевозможных целей, например исследование сети или кражей данных [14]; 3. persistence(удержание) - Это попытки злоумышленника удержать постоянный доступ к системе. Состоит из методов, которые позволяют злоумышленнику удерживать доступ к системе, несмотря на перезагрузки, изменение учетных данных и иные обстоятельства, которые могут свести на нет попытки получить начальный доступ. Методы, используемые для 30 удержания доступа, включают любое действие или любое изменение конфигурации, которое позволит злоумышленнику закрепиться в системе. Такими действиями могут, например, является подмена легитимного кода или добавление своего кода, запускаемого вместе с запуском системы [14]; 4. privilege escalation(повышение привилегий) - Это попытки злоумышленника получить более высокоуровневые права. Повышение привилегий состоит из методов, позволяющих нарушителю получить высокоуровневые права в системе или сети. Простые подходы в получение повышенных привилегий состоят в использовании системных слабостей, ошибок конфигурации и уязвимостях. Методы повышения привилегий часто пересекаются с методами удержания доступа, так как права высокого уровня позволяют беспрепятственно сохраняться в системе [14]; 5. defense evasion(избегание обнаружения) - Это попытки нарушителя избежать обнаружения его присутствия в системе. Методики избегания обнаружения включают в себя удаление/отключение программного обеспечения для защиты системы или сокрытие/шифрование данных, позволяющих обнаружить злоумышленника и его следы в системе [14]; 6. credential access(доступ к учетных записям) - Это попытки злоумышленника получить имена аккаунтов и пароли пользователей системы. Доступ к учетным записям состоит из методик кражи данных аккаунтов. Эти методики включают в себя получение данных учетных записей при помощи программ-кейлоггеров или дампа шифрованных данных учетных записей. Использование легитимных учетных данных может дать злоумышленнику доступ к системе, который сложнее обнаружить и применить контрмеры [14]; 7. discovery(исследование) - Это попытки нарушителя выяснить программное окружение среды, к которой он получил доступ. Исследование окружение состоит из методик, позволяющих нарушителю получить информацию о системе и внутренней сети. Эти методики зачастую включают использование обычных инструментов системы для сбора 31 информации о ней или о сети, в которой данная система находится [14]; 8. lateral movement(исследование иных узлов окружения) - Это попытка злоумышленника получить доступ к иным узлам окружения. Исследование других узлов окружения состоит из методов, позволяющих злоумышленнику получить информацию о других объектах сети. Эти методы включают в себя исследование сети на предмет наличия дополнительных узлов и получение доступа к ним. В качестве инструментов для достижения целей исследования и получения доступа к иным узлам окружения используются сканеры сети, а также использование уже полученных ранее данных учетных записей для получения доступа к другим объектам сети [14]; 9. collection(сбор данных) - Это попытка нарушителя получить интересующие его данные из объектов окружения. Часто после сбора данных происходит их выгрузка с удаленной системы. Простым источником для сбора данных являются аудио, видео файлы, данные, собираемые браузером, содержание email писем. Также методы сбора информации включают в себя сохранение скриншотов и ввода данных через клавиатуру [14]; 10.command and control(контроль) - Это попытка злоумышленника взаимодействовать с скомпрометированной системой для ее контроля. Данная группа вектора атаки подразумевает использование методик взаимодействия нарушителя и скомпрометированной системы внутри уязвимой сети. Нарушитель обычно пытается эмитировать обычный, ожидаемый трафик для того, чтобы избежать обнаружения [14]; 11.exfiltration(извлечение) - Это попытки злоумышленника украсть данные. Извлечение состоит из методик, позволяющих нарушителю извлечь данные из скомпрометированной сети. Собранные ранее данные упаковываются злоумышленником и выгружаются. Данные методики включают в себя сжатие данных, их шифрование, чтобы избежать обнаружения, и дальнейшую передачу по сети или по иному 32 скомпрометированному каналу связи [14]; 12.impact(влияние) - Это попытка нарушителя манипулировать данными в системе, прервать работоспособность или уничтожить систему. Данная группа состоит из методик, позволяющих злоумышленнику повлиять на доступность и целостность бизнес процессов. Эти методики могут быть использованы злоумышленником для достижения им конечных целей(уничтожение данных, вымогательство, отказ в обслуживании и т.д.) или для сокрытия иных вредоносных действий в системе [14]; На рисунке 2.3 приведено графическое представление симптомов, рас- пределенных по группам, описанным выше, с использованием сервиса mitre- caret. Веб-приложение mitre-caret позволяет выделить события информацион- ной безопасности из общей базы данных MITRE | ATT & CK, и сгруппировать их в соответствие с определенными признаками атак APT группировок [15]. Удобство этого инструмента, который понадобится при разработке системы мониторинга и управления событиями информационной безопасности, заклю- чается в наглядном изображении сопоставления событий информационной без- опасности симптомам той или иной кибератаки. Рисунок 2.3 – Симптомы целевой атаки, распределенные по группам 33 Большинство продуктов в области мониторинга и управления событиями ИБ на рынке обнаруживают события, сопоставляют их, некоторые продукты даже позволяют добавить возможность немедленного реагирования на инци- денты, но все они работают с событиями ИБ, как с простой атакой, не сопо- ставляя найденные события признакам APT-атак. Такой вариант реализации продуктов не подходит для проекта. Перечень возможностей систем мониторинга и управления событиями информационной безопасности, представлены в таблице 2.1. Таблица 2.1.Информация о SIEM на рынке Название продукта Источники для ана- лиза Наличие правил корреляции по умолчанию Особенности MaxPatrol SIEM Поддерживается до 300 источников ин- формации[16] Присутствуют Адаптация к измене- ниям в инфраструк- туре организации Fortinet FortiSIEM Наличие стандарт- ных источников для анализа. Возмож- ность добавления своих источников Присутствуют Использование ма- шинного обучения для дополнительной корреляции. Механизмы распре- деленной корреляции[17] СерчИнформ SIEM Синхронизация с множеством баз данных, в том числе Kaspersky, McAfee, Symantec Присутствует Легкость использо- вания. Возможность симбиоза с DLP[18] 34 Продолжение Таблицы 2.1.Информации о SIEM на рынке Название продукта Источники для ана- лиза Наличие правил корреляции по умолчанию Особенности КОМРАД Наличие стандарт- ных источников для анализа. Возмож- ность добавления своих источников Присутствуют Широкий спектр поддерживаемых отечественных СЗИ[19] Security Capsule Поддержка более 40 источников Присутствуют Наличие значитель- ного количе- ства(около 3000) правил корреля- ции[20] McAfee ESM Наличие стандарт- ных источников для анализа. Возмож- ность добавления своих источников Присутствуют Интеграция с более чем 30 решениями компаний партне- ров[21] В таблице выше приведены возможности наиболее известных продуктов на Российской рынке. 2.3. Выводы по разделу После анализа общих требований, обзора функционала, предоставляемого продуктами в области мониторинга и управления событиями информационной безопасности, можно сформировать более конкретные требования к SIEM- системе с учетом анализа векторов кибератак. Такие требования будут заклю- чаться в следующем: 1. Возможность обнаруживать события информационной безопасности, сопоставляя их с симптомами типовых атак кибергруппировок; 35 2. Возможность определять тип APT атаки по найденным симптомам; 3. Способность прогнозировать дальнейшее развитие такой атаки, а также способность определить возможный переход одного типа атаки в другой; 4. Возможность добавления своих правил корреляции с указанием того, к какому признаку будет отнесены обнаруженные по заданным правилам события информационной безопасности. Исходя из конкретных требований, можно заключить, что необходимо разработать свой вариант, специализированной системы мониторинга и управ- ления событиями информационной безопасности, так как варианты, представ- ленные на рынке, не смогут удовлетворить всем сформированным требованиям. 36 3. Разработка системы мониторинга безопасности предприятия Костяк любой системы мониторинга и управления событиями информа- ционной безопасности, это агрегатор информации и еѐ анализатор. Агрегатор собирает информацию из разных источников и упаковывает ее в необходимый для анализатора формат. Анализатор по собранным данным формирует уведомление об инциден- тах информационной безопасности и оповещает администратора информаци- онной безопасности о наличии несанкционированных действий в системе. Иными словами, для создания самой простой SIEM системы необходимо разработать модуль корреляции и модуль агрегации. Разрабатываемая SIEM система помимо модулей агрегации и корреляции будет состоять также из модуля предсказаний дальнейшего поведения зло- умышленника в системе на основании матрицы симптомов кибератак различ- ных группировок, также при разработке настоящей SIEM системы будут учи- тываться все требования, сформированные в предыдущем разделе [АОК-2-01в]. 3.1 Архитектура системы мониторинга и управления событиями ИБ С архитектурной точки зрения, разрабатываемая система мониторинга и управления событиями информационной безопасности представляет собой со- вокупность модулей, взаимодействующих между собой. Сама система разрабатывается на языке программирования C++. Выбор данного языка программирования позволяет с одной стороны позволяет вос- пользоваться преимуществами объектно-ориентированного подхода при проек- тировании программ, с другой стороны, программы написанные на этом языке программирования выполняются значительно быстрее программ, написанных на других ЯП, поддерживающих объектно-ориентированную парадигму про- граммирования. 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 речь пойдет в конце раздела. |