Разработка системы мониторинга безопасности предприятия ООО "Неоматика" на основе модели векторов кибератак

Алескандр Болгов

Разработка системы мониторинга безопасности предприятия ООО "Неоматика" на основе модели векторов кибератак

Целью проекта являлось: Разработка системы мониторинга и управления событиями информационной безопасности для предприятия ООО «Неоматика» на основе векторов атак кибергруппировок. Решаемые задачи: Проведение обзора и анализа объекта информатизации, проведение анализа векторов атаки кибергруппировок, выявление требований к разрабатываемой системе мониторинга безопасности, проектирование системы мониторинга с учетом требований. Основные результаты: по результатам анализа объекта защиты и выявле-ния требований к проектируемой системе мониторинга безопасности, была разработана система мониторинга и управления событиями безопасности на основе модели векторов кибератак для предприятия ООО «Неоматика».

Информатика

Дипломы

Вуз: Пермский национальный исследовательский политехнический университет (ПНИПУ)

ID: 5f465895cd3d3e000172ec04

UUID: 73ab7dc0-c9c7-0138-2174-0242ac180006

Язык: Русский

Опубликовано: больше 3 лет назад

Просмотры: 43

10.86

Алескандр Болгов

Комментировать 12

Рецензировать 0

Скачать - 2,3 МБ

Поделиться работой

Министерство науки и высшего образования Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего образования «Пермский национальный исследовательский политехнический университет» Электротехнический факультет Кафедра автоматики и телемеханики Направление подготовки: 10.03.01 Информационная безопасность Уровень высшего образования: Бакалавриат Направленность (профиль) образовательной программы: Комплексная защита объектов информатизации ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА дипломный проект Тема Разработка системы мониторинга безопасности предприятия ООО «Неоматика» на основе модели векторов кибератак Студент группы КЗИ-16-1Б Болгов А.О. (шифр учебной группы) (подпись) (Ф.И.О.) Состав ВКР: 1. Пояснительная записка на 92__ страницах. 2. Графическая часть на 4 листах. Допускается к защите Протокол заседания кафедры АТ № от 2020 г. Заведующий кафедрой АТ д-р техн. наук, профессор « » 2020г. Руководитель ВКР Каменских А.Н. (подпись) (Ф.И.О.) Консультант Каменских А.Н. / А.А. Южаков / (подпись) Регистрационный номер Пермь 2020 (Ф.И.О.)

Индивидуальное задание на выполнение ВКР Фонд оценочных средств защиты выпускной квалификационной работы Направление подготовки: 10.03.01 «Информационная безопасность» Направленность образовательной программы «Комплексная защита объектов информатизации» УТВЕРЖДАЮ Заведующий кафедрой АТ д-р техн. наук, профессор ______________ А.А. Южаков «___» _______________ 2020 г. Индивидуальное задание на выполнение выпускной квалификационной работы студента группы____КЗИ-16-1Б__________________ (шифр учебной группы) ___________________Болгова Александра Олеговича______________________ (Ф.И.О.) 1. Тема индивидуального задания: «Разработка системы мониторинга безопасности предприятия ООО «Неоматика» на основе модели векторов кибератак. 2. Цель выполнения ВКР состоит в демонстрации выпускником достигнутого уровня подготовленности к профессиональной деятельности. 3. Задачи ВКР:  выполнение этапов работы, определенных индивидуальным заданием, календарным планом, формой представления отчетных материалов, обеспечивающих достижение заданных в компетентностном формате результатов;  оформление отчетных материалов, раскрывающих уровни освоения заданного перечня компетенций;  подготовка и проведение защиты полученных результатов. 4. Срок представления завершенной и оформленной ВКР «18» июня 2020 г. 5. Содержание ВКР включает:  анализ и обобщение научно-технических материалов по теме работы, анализ объекта информатизации, особенностей факторов, существенных для защиты информации;  разработку (изучение) перечня сведений, отнесенных к информации ограниченного доступа, определение объектов защиты;  исследование каналов утечки информации и несанкционированного доступа, разработка модели нарушителя и оценка угроз безопасности информации;  определение и исследование требований по безопасности информации для объекта информатизации;  разработку структуры системы защиты информации распределенной информационной системы;  разработку и исследование подсистем защиты информации, моделирование процессов защиты информации на объекте информатизации; 2

 разработку технической и программной реализации системы защиты информации, ее подсистем и отдельных средств защиты информации;  оценку эффективности предлагаемых решений по обеспечению информационной безопасности, применяемых способов и средств защиты информации;  формирование выводов. 6. Задание в компетентностном формате результатов выполнения ВКР Заданные результаты освоения ОП представлены агрегированными компетенциями: АОК-1, АОК-2, АПК-1 АПК-2 (Табл.1)*. 7 Основные требования к выполнению индивидуального задания 7.1 Исходными данными для выполнения задания являются: - сведения об объекте информатизации, факторы, существенные для реализации системы защиты информации на данном объекте; - требования по безопасности информации для объекта информатизации; - содержание методик по определению и оценке угроз безопасности информации; - перечень способов и средств защиты информации, порядок и правила внедрения и эксплуатации техники защиты информации; - порядок создания автоматизированных систем в защищенном исполнении; - система защиты информации должна выполнять основные требования по обеспечению безопасности объекта информатизации от актуальных угроз безопасности информации. 7.2. Требования к структуре и оформлению выпускной квалификационной работы ВКР должна включать пояснительную записку и графические материалы, раскрывающие решения профессиональных задач избранной тематики – графическую часть. Пояснительная записка должна содержать: - титульный лист; - задание на выполнение ВКР; - аннотация ВКР; - содержание; - введение; - основная часть; - заключение; - список используемой литературы; - приложения. Основная часть должна включать 3 раздела с разбивкой на пункты и подпункты. Первый раздел должен содержать аналитический обзор состояния рассматриваемой темы. Обосновывается цель выполнения работы, формулируются вытекающие из цели задачи, решаемые в последующих разделах и их актуальность. Обосновывается практическая целесообразность выполнения работы на избранную тему. Должен быть сформулирован объект исследований (проектирования) и указаны методы, обеспечивающие решение задач. Обзор литературных источников должен демонстрировать умения выпускника рассматривать, оце- 3

нивать, систематизировать информацию. Количество источников информации должно составлять не менее 20 наименований. Второй раздел должен быть посвящен изложению теоретических аспектов решаемых задач (определению объекта защиты, разработке модели нарушителя и частной модели угроз безопасности информации, требований по безопасности информации, разработке способов решения задач защиты информации, разработке структуры (топологии) информационной системы и т.д.). Раздел должен содержать примеры моделирования, экспериментального исследования, в том числе исследований на математических моделях, расчеты характеристик подсистем и средств защиты информации, синтез алгоритмов, разработку технического или программного обеспечения. Третий раздел должен содержать техническую реализацию (описание принципиальных схем, элементов конструкций физической защиты объекта, средств защиты информации и пр.), разработанную политику (частные политики) информационной безопасности Должны быть сформулированы обобщения и оценки результатов с позиции их практической значимости и эффективности защиты информации. Заключение должно содержать обобщенные выводы, научно-технические результаты, предложения по их применению, рекомендации по развитию работ в рассматриваемой области науки и техники. Приложения должны включать вспомогательный материал, необходимый для полноты работы: таблицы исходных и вспомогательных данных; промежуточные расчеты, описания методик, приборов, инструментария; описание алгоритмов и программ, разработанных в процессе выполнения работы, разработанные документы для обеспечения защиты информации и пр. Графическая часть должна включать следующие материалы:  плакат, содержащий формулировки целей и задач работы, описание объекта информатизации, модель нарушителя и т.п.;  структурные, функциональные и др. схемы;  топологию распределенной информационной системы с отображенными решениями в области защиты информации;  алгоритмы решения общей и частных задач;  структуру программного обеспечения устройств, систем;  математические модели, теоретические и/или экспериментальные результаты (в виде графиков, таблиц и пр.);  разработанные технические решения устройств, средств и пр. Объем графической части должен содержать 4 листа формата А1. Текст пояснительной записки должен быть отпечатан на формате А4 и подшит в папку. Объем основной части пояснительной записки должен составлять около 40 страниц машинописного текста (шрифт 14 пт, Times New Roman, через 1,5 интервала). 7.3. Требования к предметам оценивания (индикаторам уровня освоения компонентов контролируемых агрегированных компетенций) В качестве индикаторов объектов контроля для оценивания уровней освоения 4

контролируемых компонентов агрегируемых компетенций должны быть приняты описания объектов компонентов компетенций или действия над этими объектами. В текст основной части пояснительной записки исполнителем должны быть включены индикаторы уровня освоения контролируемых компонентов компетенций. Индикатор представляет собой описание объекта контролируемой компетенции или действий над объектами контролируемых компетенций. Индикаторы контролируемых компетенций используются для оценивания уровня освоения контролируемых компетенций. Качество представления индикаторов в тексте пояснительной записки и в ответах на вопросы определяет оценку защиты ВКР. Индикаторы объекта компетенций должны представлять его полное и безошибочное описание (метода, модели, алгоритма и пр.), включающее: название объекта, его статические характеристики, сферы применения, особенности, сравнение с аналогичными объектами и пр. Эти индикаторы раскрывают уровень знаний об объекте. Индикаторы действия над объектом должны содержать полное и безошибочное описание механизма действий объекта (над объектом), включающее: обоснование применения объекта (метода, модели и пр.); динамические, точностные, надежностные и т.д. характеристики; возможности адаптации к условиям задачи; потребности в обеспечивающих ресурсах и пр. Индикаторы объекта компетенций должны обозначаются в тексте пояснительной записки, например, [АПК-1-01у] и перечисляются в конце работы после списка использованной литературы. 8. Календарный план выполнения ВКР 1 Наименование этапа Аналитический обзор. Выбор и пути решения проектной задачи 2 Разработка теоретических аспектов задания и выполнение проектирования технического обеспечения системы 3 Практическая реализация системы Наименование работ Анализ научно-технических материалов сведений об объекте информатизации, факторов, существенных для реализации системы защиты информации в информационной системе Определение объекта защиты, разработка требований по безопасности информации и для объекта информатизации, исследование каналов утечки информации и несанкционированного доступа, разработка модели нарушителя и оценка угроз безопасности информации. Разработка концепции защиты информации в информационной системе. Разработка структурных, функциональных и аналитических моделей способов и средств защиты информации Моделирование системы защиты информации и 5 Сроки* начало 18.05.201 окончание 23.05.2017 12.06.2017 13.06.2017 18.06.2017 22.05.2017 Результат Раздел 1 пояснительной записки. Необходимый объем графической части. Раздел 2 пояснительной записки. Необходимый объем графической части Раздел 3 пояснительной

в заданном техническом базисе. Оценка системных характеристик. Оформление пояснительной записки и графической части исследование процессов способов и средств защиты информации. Оценка эффективности способов и средств защиты информации. Формулировка выводов записки. Пояснительная записка. Необходимый объем графической части *Указаны сроки выполнения соответствующих разделов ВКР. 9. Порядок выполнения ВКР Рубежный контроль хода выполнения ВКР осуществляется согласно графику выполнения. Рекомендуемая базовая литература 1. Методика определения актуальных угроз безопасности персональных данных при их обработке в информационных системах персональных данных от 14.02.2008. 2. Методика определения угроз безопасности информации в информационных системах, проект 2015 г 3. Базовая модель угроз безопасности персональных данных при их обработке в информационных системах персональных данных от 15.02.2008. 4. ГОСТ Р ИСО/МЭК ТО 18044-2007 Информационная технология. Методы и средства обеспечения безопасности. Менеджмент инцидентов информационной безопасности от 01.07.2008. 5. ГОСТ Р 50922-2006 Защита информации. Основные термины и определения Руководитель ВКР _Доцент, Кандидат технических наук__ (должность, ученая степень) _____ 18.05.2020 Каменских А.Н._ (подпись дата) (Ф.И.О.) Задание принял (а) к исполнению «18» ______Мая_____2020 _____Болгов А.О._____ (подпись) Итоговая оценка оригинальности: _83,43%_ А.С.Шабуров Предзащита проведена «18» __Июня__ 2020 г. Оценка: 6 (Ф.И.О.)

Аннотация Выпускной квалификационной работы студента Болгова А.О. по теме: Разработка системы мониторинга безопасности предприятия ООО «Неоматика» на основе модели векторов кибератак. Объем работы: 92 страницы, на которых размещены 29 рисунков и 4 таблицы. При написании работы использовались 30 источников. Ключевые слова: системы мониторинга безопасности, SIEM, APT-атаки, корреляция событий ИБ, модель нарушителя, частная модель угроз, имитационное моделирование. Целью проекта являлось: Разработка системы мониторинга и управления событиями информационной безопасности для предприятия ООО «Неоматика» на основе векторов атак кибергруппировок. Решаемые задачи: Проведение обзора и анализа объекта информатизации, проведение анализа векторов атаки кибергруппировок, выявление требований к разрабатываемой системе мониторинга безопасности, проектирование системы мониторинга с учетом требований. Основные результаты: по результатам анализа объекта защиты и выявления требований к проектируемой системе мониторинга безопасности, была разработана система мониторинга и управления событиями безопасности на основе модели векторов кибератак для предприятия ООО «Неоматика». 7

Содержание Введение .............................................................................................................. 10 1. Информация о предприятии ........................................................................... 12 1.2. Информация об объекте защиты ............................................................... 13 1.3.1. Общие положения ................................................................................... 13 1.3.2. Описание ИС ........................................................................................... 14 1.3.3. Модель нарушителя ................................................................................ 14 1.3.4. Определение базового уровня защищенности ...................................... 18 1.3.5. Определение актуальных угроз безопасности ...................................... 19 1.4. Выводы по разделу .................................................................................... 21 2.Анализ требований по мониторингу событий безопасности ......................... 22 2.1. Этапы атаки на информационную систему и меры защиты ................... 23 2.2 Анализ векторов кибератак APT группировок ......................................... 27 2.2.1. Категорирование событий информационной безопасности................. 29 2.3. Выводы по разделу .................................................................................... 34 3. Разработка системы мониторинга безопасности предприятия ..................... 36 3.1 Архитектура системы мониторинга и управления событиями ИБ .......... 36 3.2. Разработка модуля агрегации .................................................................... 37 3.3. Разработка модуля корреляции ................................................................. 42 3.4. Разработка модуля прогнозирования........................................................ 51 3.5. Разработка вспомогательных модулей .................................................... 53 3.5.1. Разработка модуля для работы с JSON файлами .................................. 54 3.5.2. Разработка модуля для работы с представлением времени ................. 55 3.6. Выводы по разделу .................................................................................... 57 4. Алгоритм работы программы ......................................................................... 58 4.1. Алгоритм корреляция событий ИБ ........................................................... 58 4.2. Алгоритм прогнозирования событий ИБ ................................................. 59 4.3. Вывод по разделу ....................................................................................... 60 5. Имитационное моделирование ....................................................................... 61 5.1. Признаки APT41 и их описание ................................................................ 61 5.2. Формирование log-файлов и моделирование атаки ................................. 63 5.3 Оценка эффективности ............................................................................... 70 8

Заключение .......................................................................................................... 75 Список литературы ............................................................................................. 76 Перечень компетенций ....................................................................................... 79 Приложение А ..................................................................................................... 80 Приложение Б ...................................................................................................... 82 Приложение В ..................................................................................................... 85 Приложение Г ...................................................................................................... 92 9

Введение С каждым годом угрозы взлома информационных систем и компрометации данных становятся все более и более актуальными, более того вектор угроз смещается от простых методов к серьезным, продуманным и нетривиальным атакам. По итогам третьего квартала 2019 года экспертами Positive Technologies был отмечен рост числа целенаправленных атак по сравнению с 2018 годом [1][ АОК-1-01з].- рисунок 1. Рисунок 1 – Статистика роста целевых атак Такие атаки называются APT-атаками(Advanced persistent threat) и направленны они на конкретную организацию или отрасль промышленности или бизнеса. По данным ФинЦЕРТ, за 2018 год было зафиксировано 687 атак на организации кредитно-финансовой отрасли. Из них 177 являлись целевыми [2]. Только от группировок Cobalt и Silence за 2018 год ущерб составил 58 млн. рублей [2]. Одна такая атака может проводиться на протяжении несколь- 10

ких месяцев, что существенно затрудняет ее обнаружение, так как администратор безопасности может и не заметить связи между несколькими событиями на отрезке в несколько недель, а специализированные системы обнаружения вторжений зачастую работают только с одним сегментом информационной системы, будь то сеть или управление контролем доступа. Такие СОВ не видят полной картины. Для решения подобной задачи может потребоваться более комплексное программное обеспечение, способное не просто замечать признаки попыток нарушения конфиденциальности, целостности и доступности информационной системы и данных в ней, но и находить взаимосвязи между такими событиями. Для всего этого подойдет система мониторинга и управления событиями информационной безопасности, такая система способна находить корреляции между различными событиями ИБ. В проекте, решается задача по разработке SIEM-системы, с добавлением к ней возможности сопоставления обнаруженных событий информационной безопасности признакам APT-атак. Задача разработки собственной реализации системы мониторинга ставится, вследствие невозможности использовать представленные на рынке варианты SIEM-систем «из коробки». Для каждой такой системы необходима полноценная настройка, учитывающая специфику предприятия, необходимо создание дополнительных правил для обнаружения инцидентов информационной безопасности, месяцы накопления статистики и корректировка уже созданных правил обнаружения. Все это требует дополнительных расходов и привлечения группы специалистов [3]. Основное направление в проекте сделано на разработку SIEM-системы, опирающуюся на категорирование признаков APT-атак. Это позволит обнаружить целевую атаку на предприятие при минимальной настройке, что существенно сокращает время развертывания и финансовые издержки. В первом разделе будет проанализирована общая информация о предприятии, необходимая для развертывания системы мониторинга безопасности. 11

1. Информация о предприятии В настоящей проекте объектом защиты является информационная система предприятия ООО «Неоматика». «Неоматика» – Российская IT-компания, занимающаяся разработкой оборудования для ГЛОНАС/GPS мониторинга с 2012 года [4]. Основными направлениями деятельности компании являются: 1. Производство автомобильных трекеров; 2. Производство персональных трекеров; 3. Производства датчиков температуры; 4. Производство датчиков наклона; 5. Производство датчиков уровня топлива; 6. Написание программного обеспечения для объединения, произведенного компанией оборудования в единую экосистему. Главный офис компании находится по адресу г. Пермь ул. Малкова 24А, на первом этаже жилого дома, вход со стороны внутреннего двора. Местоположение предприятия представлено на рисунке 1.1 Рисунок 1.1 – Расположение предприятия 12

Окна офиса выходят на жилые дома напротив здания, где расположена компания. Под нужды организации отведены четыре помещения. Как можно заметить на изображении выше, здание окружено парковкой. Все стороны здания выходят на жилые дома. Исходя из информации выше, следует заключить, что компания ООО «Неоматика» может быть целью APT-группировок, так как она поставляет программно-техническое оборудование на рынок. Это оборудование может являться промежуточным звеном в иной, более крупной цепочке атак. 1.2. Информация об объекте защиты Основным объектом защиты на предприятии выступает его информационная система. Информационная система предприятия представляет собой как сервера с исходными кодами и «прошивками» программно-технических продуктов, так и персональные данные сотрудников организации [АОК-2-01з]. Информационная система состоит из следующих компонентов: 1. 1С: Предприятие (версия 7.7); 2. 1С: Предприятие (версия 8.2); 3. 1С: Камин расчет заработной платы (версия 3.0); 4. Oracle Database 11g 5. Visual SVN server После сбора основной информации об организации, необходимо определить перечень возможных угроз предприятия. Для этого следует разработать частную модель угроз. 1.3. Частная модель угроз предприятия 1.3.1. Общие положения Настоящая модель определяет актуальные угрозы безопасности информации при ее обработке в информационной системе предприятия ООО 13

«Неоматика». Настоящая модель была разработана на основании следующих документов [АПК-2-01в]: 1. Методика определения актуальных угроз безопасности персональных данных при их обработке в информационных системах персональных данных, Утверждена заместителем директора ФСТЭК России 14 февраля 2008 г [6]. 2. Методика определения угроз безопасности информации в информационных системах, Проект 2015 г [7]. 3. Базовая модель угроз безопасности персональных данных при их обработке в информационных системах персональных данных, Утверждена заместителем директора ФСТЭК России 15 февраля 2008 г [8]. 1.3.2. Описание ИС ИС предприятия состоит из следующих компонентов: 1. 1С: Предприятие (версия 7.7); 2. 1С: Предприятие (версия 8.2); 3. 1С: Камин расчет заработной платы (версия 3.0); 4. Oracle Database 11g 5. Visual SVN Server 1.3.3. Модель нарушителя Целью оценки возможностей нарушителей по реализации угроз безопасности информации является формирование предположения о типах, видах нарушителей, информации в которые могут информационной реализовать системе с угрозы заданными безопасности структурно- функциональными характеристиками и особенностями функционирования, а также потенциале этих нарушителей и возможных способах реализации угроз безопасности информации. С учетом наличия прав доступа и возможностей по доступу к 14

информации и (или) к компонентам информационной системы нарушители подразделяются на два типа: 1. внешние нарушители (тип I) – лица, не имеющие права доступа к информационной системе, ее отдельным компонентам и реализующие угрозы безопасности информации из-за границ информационной системы; 2. внутренние нарушители (тип II) – лица, имеющие право постоянного или разового доступа к информационной системе, ее отдельным компонентам. Виды нарушителей и их возможные цели реализации угроз безопасности информации представлены в таблице 1.1 Таблица 1.1.Виды, типы и потенциал нарушителей Виды Типы Возможные цели реализации угроз Потенциал нарушителей нарушителей безопасности информации нарушителей Причинение имущественного ущерба путем мошенничества или Преступные группы Внешний иным преступным путем. Выявление уязвимостей с целью их дальнейшей Низкий продажи и получения финансовой выгоды Идеологические или политические мотивы. Причинение имущественного ущерба путем мошенничества или иным Внешние субъекты Внешний преступным путем. Любопытство или желание самореализации. Выявление уязвимостей с целью их дальнейшей продажи и получения финансовой выгоды 15 Низкий

Продолжение Таблицы 1.1. Виды, типы и потенциал нарушителей Виды Типы Возможные цели реализации угроз Потенциал нарушителей нарушителей безопасности информации нарушителей Получение конкурентных Конкурирующие организации преимуществ. Причинение Внешний имущественного ущерба путем Средний обмана или злоупотребление доверием Внедрение дополнительных Разработчики, функциональных возможностей в производители, программное обеспечение или поставщики программно-технические средства на программных, технических и Внешний этапе разработки. Причинение имущественного ущерба путем программно- обмана или злоупотребления технических доверием. Непреднамеренные, средств неосторожные или Средний неквалифицированные действия Лица, привлекаемые для Причинение имущественного ущерба установки, путем обмана или злоупотребления наладки, монтажа Внутренний доверием. Непреднамеренные, пусконаладочных неосторожные или и иных видов неквалифицированные действия Низкий работ Лица, обеспечивающие Причинение имущественного ущерба функционирование путем обмана или злоупотребления информационной Внутренний доверием. Непреднамеренные, системы или неосторожные или обслуживающие неквалифицированные действия инфраструктуру 16 Низкий

Продолжение Таблицы 1.1.Виды, типы и потенциал нарушителей Виды Типы Возможные цели реализации угроз Потенциал нарушителей нарушителей безопасности информации нарушителей Причинение имущественного ущерба путем мошенничества или иным Пользователи информационной Внутренний системы преступным путем. Месть за ранее Низкий совершенные действия. Непреднамеренные, неосторожные или неквалифицированные действия Причинение имущественного ущерба путем мошенничества или иным Администраторы преступным путем. Любопытство или информационной системы и Внутренний администраторы желание самореализации. Месть за ранее совершенные действия. Высокий Выявление уязвимостей с целью их безопасности дальнейшей продажи и получения финансовой выгоды Причинение имущественного ущерба Бывшие работники Внешний путем мошенничества или иным Низкий преступным путем. Месть за ранее совершенные действия Угрозы безопасности информации могут быть реализованы нарушителями за счет: 1. несанкционированного доступа и (или) воздействия на объекты на аппаратном уровне (программы (микропрограммы), «прошитые» в аппаратных компонентах (чипсетах)); 2. несанкционированного доступа и (или) воздействия на объекты на общесистемном уровне (базовые системы ввода-вывода, гипервизоры, операционные системы); 3. несанкционированного доступа и (или) воздействия на объекты на прикладном уровне (системы управления базами данных, браузеры, web- 17

приложения, иные прикладные программы общего и специального назначения); 4. несанкционированного доступа и (или) воздействия на объекты на сетевом уровне (сетевое оборудование, сетевые приложения, сервисы); 5. линии, несанкционированного физического доступа и (или) воздействия на (каналы) связи, технические средства, машинные носители информации; 6. воздействия на пользователей, администраторов безопасности, администраторов информационной системы или обслуживающий персонал (социальная инженерия). 1.3.4. Определение базового уровня защищенности Исходя из того, что в ИС обрабатываются также и ПДн, то следует определить также базовый уровень защищенности ИС, как ИСПДн. Под уровнем исходной защищенности ИСПДн понимается обобщенный показатель, зависящий от технических и эксплуатационных характеристик ИСПДн. Характеристики ИСПДн приведены в таблице 1.2. Таблица 1.2.Базовый уровень защищенности ИСПДн Параметр Значение Уровень защищенности По территориальному Локальная ИСПДн, развернутая в размещению пределах одного здания Высокий ИСПДн По наличию соединения с сетями общего пользования ИСПДн физически отделенная от сети общего пользования 18 Высокий

Продолжение Таблицы 1.2.Базовый уровень защищенности ИСПДн Уровень Параметр Значение По разграничению ИСПДн, к которой имеют доступ доступа к определенный перечень лиц работников персональным организации, являющейся владельцем данным ИСПДн, либо субъектом ПДн По наличию ИСПДн, в которой используется одна соединения с ПДн база ПДн, принадлежащая организации - других ИСПДн владельцу ИСПДн защищенности Средний Высокий ИСПДн, в которой предоставляемые По уровню пользователю данные являются обезличивания ПДн Высокий обезличенными По объему ПДн, которые предоставляются сторонним пользователям ИСПДн не предоставляющая часть Пдн Средний ИСПДн без предварительной обработки Значению уровня защищенности «Высокий» соответствуют 4 характеристики. Значению уровня «Средний» - 3 характеристики, значению уровня «Низкий» - 0 характеристик. Таким образом, числовой коэффициент исходной защищенности ИСПДн Оператора соответствует значению 5 (средняя). 1.3.5. Определение актуальных угроз безопасности Актуальной считается угроза, которая может быть реализована в ИС и представляет опасность для конфиденциальной информации. Актуальность угрозы определяется следующими параметрами: 19

1. уровень исходной защищенности ИС (в нашем случае, ИСПДн тоже); 2. частота (вероятность) реализации рассматриваемой угрозы. Уровень исходной защищенности ИС и ИСПДн был представлен выше, в таблице 1.2. Под частотой (вероятностью) реализации угрозы понимается определяемый экспертным путем показатель, характеризующий, насколько вероятным является реализация конкретной угрозы безопасности КИ для данной ИС в складывающихся условиях обстановки. Вводятся четыре вербальных градации этого показателя: 1. маловероятно – отсутствуют объективные предпосылки для осуществления угрозы (например, угроза хищения носителей информации лицами, не имеющими легального доступа в помещение, где последние хранятся); 2. низкая вероятность – объективные предпосылки для реализации угрозы существуют, но принятые меры существенно затрудняют ее реализацию (например, использованы соответствующие средства защиты информации); 3. средняя вероятность - объективные предпосылки для реализации угрозы существуют, но принятые меры обеспечения безопасности конфиденциальной информации недостаточны; 4. высокая вероятность - объективные предпосылки для реализации угрозы существуют, и меры по обеспечению безопасности конфиденциальной информации н не приняты. При составлении перечня актуальных угроз безопасности ИС каждой градации вероятности возникновения угрозы ставится в соответствие числовой коэффициент, а именно: 1. 0 для маловероятной угрозы; 2. 2 для низкой вероятности угрозы; 3. 5 для средней вероятности угрозы; 20

4. 10 для высокой вероятности угрозы. Полный перечень угроз, с полным перечнем угроз безопасности информации, показателями опасности этих угроз и вероятностью их реализации, а также подсчитанными коэффициентами реализуемости угроз представлены в таблице А.1, в Приложении А [АПК-2-01з]. Следует отметить, что показатель опасности угрозы безопасности информации, так же как и перечень угроз утечки информации по техническим каналам и за счет несанкционированного доступа определяются на основании экспертной оценки 1.4. Выводы по разделу При рассмотрении перечня актуальных угроз безопасности информации, представленных в таблице А.1, можно заметить, что большая часть актуальных угроз в том или ином виде являются признаками APT-атаки, речь о которых пойдет в следующем разделе. Такими признаками являются: 1. Реализация угрозы повышения привилегий; 2. Реализация угрозы подмены программного обеспечения; 3. Реализация угрозы несанкционированного создания учетной записи пользователя; 4. Реализация угрозы внедрения кода или данных. Следовательно, будет иметь смысл внедрение средства, способного своевременно обнаружить реализацию определенных угроз. Таким средством является SIEM-система, анализ требований к реализации которой будут рассмотрены далее 21

2.Анализ требований по мониторингу событий безопасности Системы мониторинга событий безопасности позволяют проводить инвентаризацию ресурсов автоматизированными средствами, анализировать сетевые приложения, оборудование и веб-сервисы, сокращать затраты на проведение аудита, автоматизировать процесс управления уязвимостями и обеспечивать контроль соответствия политикам информационной безопасности, принятым в организации [9]. Системы мониторинга и управления событиями информационной безопасности, в общем случае, состоят из 4 компонентов: 1. Компонент сбора информации, или же агрегатор, обеспечива- ет сбор информации из различных источников, таких как программное и аппаратное обеспечение, средства защиты информации, файлы логов; 2. Компонент обработки информации, участвующий в обработке событий, собранных агрегатором, и корреляции по различным критериям, на основании которых принимается решение о наличии инцидента информационной безопасности; 3. Компонент хранения данных, который участвует в хранении данных в едином, понятном, как для остальных компонентов, так и для администратора; 4. Компонент управления системой мониторинга событий ин- формационной безопасности, который нужен для более гибкой настройки параметров. Так как любая SIEM-система, это, прежде всего, средство защиты информации, то перед тем, как сформировать требования к ней, следует разобраться в том, из чего состоит атака на информационную систему, и на какие этапы она подразделяется, а также в чем состоят меры защиты от такой атаки. Такой разбор атаки и мер защиты позволит определить на каком из этапов защиты должна работать SIEM, следовательно, требования, предъявляемые к реализации 22

системы мониторинга и управления событиями информационной безопасности, будут более осмысленными и актуальными [АОК-1-01в]. 2.1. Этапы атаки на информационную систему и меры защиты Атака на информационную систему – это совокупность преднамеренных действий злоумышленника, направленных на нарушение одного из трех свойств информации – конфиденциальность, целостность, доступность. При этом любую такую совокупность действий можно подразделить на этапы атаки на информационную систему. Исходя из действий злоумышленника, атаку на информационную систему можно разделить на 3 этапа [10]: 1. Разведка 1.1.Сканирование сетей и портов 1.2.Обнаружение уязвимостей систем 1.3.Сбор отпечатков систем 1.4.Индексация web-страниц 2. Атака 2.1.Атаки типа «Отказ в обслуживании»(DOS/DDOS) 2.2.Атаки типа «Полный перебор»(Bruteforce) 2.3.Повышение привилегий(Privilege escalation) 2.4.Мошеннические атаки 2.5.Спам 2.6.Использование уязвимостей 2.7.Социальная инженерия 3. Закрепление в системе 3.1.Сканирование внутренней сети 3.2.Взлом соседних узлов 3.3.Установка средств повторного внедрения Графически этапы атаки представлены на рисунке 2.1. 23

Рисунок 2.1 – Этапы проведения атаки на информационную систему Важно понимать, что как атака ни информационную систему, так и защита от таких атак, это циклический процесс. После закрепления в системе, злоумышленник вновь может провести разведку, саму атаку и закрепление в других узлах системы, пока не достигнет своей цели. Такое подразделение атаки на этапы не является единственно верным. Существуют сервисы, вроде Mitre ATT | CK, которые предлагают свою цепочку действий злоумышленника, подразделяется на следующие этапы: 1. Начальный доступ 2. Закрепление в системе 3. Повышение привилегий 4. Избегание средств защиты 5. Получение доступа к учетным данным 6. Изучение системы 7. Дальнейшее продвижение 8. Сбор данных 9. Подготовка к выгрузке и выгрузка данных 10. Влияние на ресурсы системы 24 которая

В отличие от этапов атаки злоумышленника, представленных на рисунке 2.1, этапы атаки злоумышленника, описанные Mitre, не являются циклическими, то есть это вектор, который направлен от «начального доступа» к окончательному «влиянию на ресурсы системы». Каждое из «звеньев цепи» атаки на информационную систему согласно сервису Mitre ATT | CK будет более подробно рассмотрено в следующем подразделе. В свою очередь, для обеспечения защиты можно разделить противодействие атакам на информационную систему, на следующие этапы, представленные также на рисунке 2.2 [10][АПК-1-01з]: 1. Превентивные 1.1Управление активами 1.2.Управление уязвимостями 2. Детективные 2.1.Сбор событий ИБ с активов 2.2.Нормализация событий 2.3.Агрегирование событий 2.4.Анализ и корреляция событий 2.5.Хранение событий 3. Корректирующие 3.1.Расследование инцидентов ИБ 3.2.Изменение политики ИБ 3.3.Изменение настроек безопасности активов Рисунок 2.2 – Этапы противодействия атакам на информационную систему 25

Этапы противодействия атакам также зациклены, это позволяет обеспечивать непрерывность процесса обеспечения безопасности информации на предприятии. Следует рассмотреть каждый этап по обеспечению защитных мер отдельно: 1)Превентивные мероприятия 1. Управление активами – прежде чем что-то защищать, необходимо понять, что защищать, для этого необходимо провести инвентаризацию: 1.1.Информационных система и их критичность для предприятия; 1.2.Сотрудников; 1.3.Определить взаимодействие между активами, как на уровне систем, так и на уровне система-сотрудник и сотрудниксотрудник; 1.4.Определить перечень текущих средств защиты; 1.5.Определить перечень разработанных политик информационной безопасности. 2. Управление уязвимостями – после понимания того, что нужно защищать, проводится оценка текущего уровня уязвимостей активов, для этого собираются данные об уязвимостях информационных систем, путем: 2.1.Сканирования их различными сетевыми сканерами; 2.2.Проведения аудита; 2.3.Ознакомления компетентности сотрудников по вопросам информационной безопасности. 2)Детективные мероприятия – все мероприятия, описанные и продемонстрированные на рисунке 2.2, по сути, сводятся к работе с файлами, в которых хранятся записи о тех или иных событиях, произошедших в информационных системах (log-файлами), а именно: 26

2.1.Определение закономерностей и шаблонов, реализующих то или иное событие ИБ; 2.2.Последовательности отдельных сообщений определенного типа, по которым также можно обнаружить событие ИБ. 3)Коррективные мероприятия – все мероприятия, проводящиеся в результате появления инцидента ИБ или нарушения политики информационной безопасности: 3.1.Заведение инцидента ИБ; 3.2.Расследование в рамках инцидента ИБ. Исходя из более подробного описания этапов противодействия атакам на информационные системы, особенно исходя их описания детективного этапа, возникают следующие требования к SIEM системе: 1. Количество источников для анализа данных, которые SIEM система может поддерживать изначально; 2. Количество и качество правил корреляции, которые SIEM система использует для идентификации события или инцидента ИБ; 3. Возможность влиять на существующие правила корреляции или добавлять свои собственные; 4. Не быть требовательной к ресурсам системы, на которой она запущена. Сформированные требования являются достаточно общими и подходят для стандартных методов взлома, но как уже упоминалось в введении, зачастую на предприятия совершаются именно целевые атаки, для детектирования подобных атак необходимо формировать особые требования к системе мониторинга и управления безопасностью событиями. Перед формированием подобных требований к разрабатываемой SIEM-системы следует проанализировать вектора целевых атак, которые также называют вектора атак APT группировок. 2.2 Анализ векторов кибератак APT группировок APT дословно переводится как устойчивая угроза, или же целевая/направленная кибератака. Применительно к кибергруппировкам термин 27

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, WINERACK и SHUTTERSPEED [12]. Такую направленную кибератаку APT-группировок называют вектором атаки. В результате реализации такого вектора атаки появляется инцидент ин- 28

формационной безопасности, отдельные же этапы реализации вектора атаки можно считать событиями информационной безопасности, исходя из определений, приведенных в ГОСТ Р ИСО/МЭК ТО 18044-2007 [13]. 2.2.1. Категорирование событий информационной безопасности Сегодня существуют сервисы, которые категорируют события информационной безопасности из векторов кибератак. Такие сервисы рассматривают каждую направленную атаку с точки зрения признаков или же симптомов, которые подразделяются по категориям. Одним из таких сервисов является MITRE | ATT&CK. Данный сервис представляет собой базу данных об техниках и приемах проникновения злоумышленниками в информационные системы, базирующуюся на общемировых исследованиях. Сервис MITRE | ATT&CK(далее MITRE) подразделяет вектор атаки APT на 12 групп симптомов[АОК-1- 01у]: 1. initial access(начальный доступ) - Это попытки злоумышленника попасть в сеть организации. Начальный доступ состоит из методов, которые используют различные векторы входа, чтобы получить "точку опоры" в сети. Эти методы, используемые для получения "точки опоры" в сети, включают фишинг и использование программных уязвимостей на публичном веб-сервисе [14]; 2. execution(исполнение) - Это попытки злоумышленника запустить вредоносный код. Исполнение состоит из методов, которые в результате позволяют злоумышленнику запустить код на локальной или удаленной системе. Методы, которые позволяют запустить вредоносный код часто сопряжены с методами других групп, для достижения всевозможных целей, например исследование сети или кражей данных [14]; 3. persistence(удержание) - Это попытки злоумышленника удержать постоянный доступ к системе. Состоит из методов, которые позволяют злоумышленнику удерживать доступ к системе, несмотря на перезагрузки, изменение учетных данных и иные обстоятельства, которые могут свести на нет попытки получить начальный доступ. Методы, используемые для 29

удержания доступа, включают любое действие или любое изменение конфигурации, которое позволит злоумышленнику закрепиться в системе. Такими действиями могут, например, является подмена легитимного кода или добавление своего кода, запускаемого вместе с запуском системы [14]; 4. privilege escalation(повышение привилегий) - Это попытки злоумышленника получить более высокоуровневые права. Повышение привилегий состоит из методов, позволяющих нарушителю получить высокоуровневые права в системе или сети. Простые подходы в получение повышенных привилегий состоят в использовании системных слабостей, ошибок конфигурации и уязвимостях. Методы повышения привилегий часто пересекаются с методами удержания доступа, так как права высокого уровня позволяют беспрепятственно сохраняться в системе [14]; 5. defense evasion(избегание обнаружения) - Это попытки нарушителя избежать обнаружения его присутствия в системе. Методики избегания обнаружения включают в себя удаление/отключение программного обеспечения для защиты системы или сокрытие/шифрование данных, позволяющих обнаружить злоумышленника и его следы в системе [14]; 6. credential access(доступ к учетных записям) - Это попытки злоумышленника получить имена аккаунтов и пароли пользователей системы. Доступ к учетным записям состоит из методик кражи данных аккаунтов. Эти методики включают в себя получение данных учетных записей при помощи программ-кейлоггеров или дампа шифрованных данных учетных записей. Использование легитимных учетных данных может дать злоумышленнику доступ к системе, который сложнее обнаружить и применить контрмеры [14]; 7. discovery(исследование) - Это попытки нарушителя выяснить программное окружение среды, к которой он получил доступ. Исследование окружение состоит из методик, позволяющих нарушителю получить информацию о системе и внутренней сети. Эти методики зачастую включают использование обычных инструментов системы для сбора 30

информации о ней или о сети, в которой данная система находится [14]; 8. lateral movement(исследование иных узлов окружения) - Это попытка злоумышленника получить доступ к иным узлам окружения. Исследование других узлов окружения состоит из методов, позволяющих злоумышленнику получить информацию о других объектах сети. Эти методы включают в себя исследование сети на предмет наличия дополнительных узлов и получение доступа к ним. В качестве инструментов для достижения целей исследования и получения доступа к иным узлам окружения используются сканеры сети, а также использование уже полученных ранее данных учетных записей для получения доступа к другим объектам сети [14]; 9. collection(сбор данных) - Это попытка нарушителя получить интересующие его данные из объектов окружения. Часто после сбора данных происходит их выгрузка с удаленной системы. Простым источником для сбора данных являются аудио, видео файлы, данные, собираемые браузером, содержание email писем. Также методы сбора информации включают в себя сохранение скриншотов и ввода данных через клавиатуру [14]; 10.command and control(контроль) - Это попытка злоумышленника взаимодействовать с скомпрометированной системой для ее контроля. Данная группа вектора атаки подразумевает использование методик взаимодействия нарушителя и скомпрометированной системы внутри уязвимой сети. Нарушитель обычно пытается эмитировать обычный, ожидаемый трафик для того, чтобы избежать обнаружения [14]; 11.exfiltration(извлечение) - Это попытки злоумышленника украсть данные. Извлечение состоит из методик, позволяющих нарушителю извлечь данные из скомпрометированной сети. Собранные ранее данные упаковываются злоумышленником и выгружаются. Данные методики включают в себя сжатие данных, их шифрование, чтобы избежать обнаружения, и дальнейшую передачу 31 по сети или по иному

скомпрометированному каналу связи [14]; 12.impact(влияние) - Это попытка нарушителя манипулировать данными в системе, прервать работоспособность или уничтожить систему. Данная группа состоит из методик, позволяющих злоумышленнику повлиять на доступность и целостность бизнес процессов. Эти методики могут быть использованы злоумышленником для достижения им конечных целей(уничтожение данных, вымогательство, отказ в обслуживании и т.д.) или для сокрытия иных вредоносных действий в системе [14]; На рисунке 2.3 приведено графическое представление симптомов, распределенных по группам, описанным выше, с использованием сервиса mitrecaret. Веб-приложение mitre-caret позволяет выделить события информационной безопасности из общей базы данных MITRE | ATT & CK, и сгруппировать их в соответствие с определенными признаками атак APT группировок [15]. Удобство этого инструмента, который понадобится при разработке системы мониторинга и управления событиями информационной безопасности, заключается в наглядном изображении сопоставления событий информационной безопасности симптомам той или иной кибератаки. Рисунок 2.3 – Симптомы целевой атаки, распределенные по группам 32

Большинство продуктов в области мониторинга и управления событиями ИБ на рынке обнаруживают события, сопоставляют их, некоторые продукты даже позволяют добавить возможность немедленного реагирования на инциденты, но все они работают с событиями ИБ, как с простой атакой, не сопоставляя найденные события признакам APT-атак. Такой вариант реализации продуктов не подходит для проекта. Перечень возможностей систем мониторинга и управления событиями информационной безопасности, представлены в таблице 2.1. Таблица 2.1.Информация о SIEM на рынке Название продукта Источники для ана- Наличие правил лиза корреляции по Особенности умолчанию MaxPatrol SIEM Fortinet FortiSIEM Поддерживается до Присутствуют Адаптация к измене- 300 источников ин- ниям в инфраструк- формации[16] туре организации Наличие стандарт- Присутствуют Использование ма- ных источников для шинного обучения анализа. Возмож- для дополнительной ность добавления корреляции. своих источников Механизмы распределенной корреляции[17] СерчИнформ SIEM Синхронизация с Присутствует Легкость использо- множеством баз вания. Возможность данных, в том числе симбиоза с DLP[18] Kaspersky, McAfee, Symantec 33

Продолжение Таблицы 2.1.Информации о SIEM на рынке Название продукта Источники для ана- Наличие правил лиза корреляции по Особенности умолчанию КОМРАД Наличие стандарт- Присутствуют Широкий спектр ных источников для поддерживаемых анализа. Возмож- отечественных ность добавления СЗИ[19] своих источников Поддержка более 40 Security Capsule Присутствуют источников Наличие значительного количества(около 3000) правил корреляции[20] Наличие стандарт- McAfee ESM Присутствуют Интеграция с более ных источников для чем 30 решениями анализа. Возмож- компаний партне- ность добавления ров[21] своих источников В таблице выше приведены возможности наиболее известных продуктов на Российской рынке. 2.3. Выводы по разделу После анализа общих требований, обзора функционала, предоставляемого продуктами в области мониторинга и управления событиями информационной безопасности, можно сформировать более конкретные требования к SIEMсистеме с учетом анализа векторов кибератак. Такие требования будут заключаться в следующем: 1. Возможность безопасности, обнаруживать сопоставляя их с кибергруппировок; 34 события симптомами информационной типовых атак

2. Возможность определять тип APT атаки по найденным симптомам; 3. Способность прогнозировать дальнейшее развитие такой атаки, а также способность определить возможный переход одного типа атаки в другой; 4. Возможность добавления своих правил корреляции с указанием того, к какому признаку будет отнесены обнаруженные по заданным правилам события информационной безопасности. Исходя из конкретных требований, можно заключить, что необходимо разработать свой вариант, специализированной системы мониторинга и управления событиями информационной безопасности, так как варианты, представленные на рынке, не смогут удовлетворить всем сформированным требованиям. 35

3. Разработка системы мониторинга безопасности предприятия Костяк любой системы мониторинга и управления событиями информационной безопасности, это агрегатор информации и еѐ анализатор. Агрегатор собирает информацию из разных источников и упаковывает ее в необходимый для анализатора формат. Анализатор по собранным данным формирует уведомление об инцидентах информационной безопасности и оповещает администратора информационной безопасности о наличии несанкционированных действий в системе. Иными словами, для создания самой простой SIEM системы необходимо разработать модуль корреляции и модуль агрегации. Разрабатываемая SIEM система помимо модулей агрегации и корреляции будет состоять также из модуля предсказаний дальнейшего поведения злоумышленника в системе на основании матрицы симптомов кибератак различных группировок, также при разработке настоящей SIEM системы будут учитываться все требования, сформированные в предыдущем разделе [АОК-2-01в]. 3.1 Архитектура системы мониторинга и управления событиями ИБ С архитектурной точки зрения, разрабатываемая система мониторинга и управления событиями информационной безопасности представляет собой совокупность модулей, взаимодействующих между собой. Сама система разрабатывается на языке программирования C++. Выбор данного языка программирования позволяет с одной стороны позволяет воспользоваться преимуществами объектно-ориентированного подхода при проектировании программ, с другой стороны, программы написанные на этом языке программирования выполняются значительно быстрее программ, написанных на других ЯП, поддерживающих объектно-ориентированную парадигму программирования. 36

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

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

Теперь более подробно рассмотрим источники информации для агрегирования, как уже было сказано выше, данными источниками выступают различные 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. Как уже было сказано выше, в модуль агрегации встроена возможность добавления своих файлов логов для сбора информации из них. В отличие от стандартного расширения функционала, данная возможность предусматривает добавление дополнительных лог файлов без написания кода и является инструментов пользователя разработанной системы мониторинга и управления событиями информационной безопасности. Для этого предусмотрен специальный 39

конфигурационный файл 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)‖ } } } } } 40

При вводе выше описанных команд в конфигурационный файл 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 Firefox/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‖ 41

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

Корреляция применительно к 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- 43

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

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

―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/‖ } }, 46

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

На представленном выше изображении видно, что последовательность действий пользователя 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", 48

"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-объекте;  приоритета символ вертикальной черты ‗|‘ служит для добавления к ключу или параметру. Добавленный приоритет используется модулем корреляции для поиска зависимостей и оценки необходимости формирования уведомления о возможно инциденте информационной безопасности, если приоритет равен нулю, то информация, к которой добавлен такой приоритет не будет учитываться 49

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

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

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

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

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

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

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

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

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

Подход с графами удобен тем, что можно быстро, относительно полного перебора, найти взаимосвязь между двумя симптомами. Для этого используется такой алгоритм поиска в графах, как поиск в глубину. Поиск в глубину — один из методов обхода графа. Стратегия поиска в глубину, как и следует из названия, состоит в том, чтобы идти «вглубь» графа, насколько это возможно. Алгоритм поиска описывается рекурсивно: перебираем все исходящие из рассматриваемой вершины рѐбра. Если ребро ведѐт в вершину, которая не была рассмотрена ранее, то запускаем алгоритм от этой нерассмотренной вершины, а после возвращаемся и продолжаем перебирать рѐбра. Возврат происходит в том случае, если в рассматриваемой вершине не осталось рѐбер, которые ведут в нерассмотренную вершину [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. Сопоставляю симптомы, модуль прогнозирования пытается выяснить наиболее вероятный тип атаки. Расчет вероятности происходит достаточно тривиальным способом, а именно расчетом отношения числа обнаруженных симптомов к числу симптомов конкретной атаки. После вычисления наиболее вероятного типа атаки, из базы данных признаков 59

собираются оставшиеся, еще не обнаруженные симптомы и информация о них выводится в соответствующем уведомлении пользователю. 4.3. Вывод по разделу Подход к алгоритмизации, описанный в этом разделе позволяет SIEMсистеме достаточно быстро исполнять свои функции. С одной стороны можно заключить, что поиск взаимосвязей при помощи простых алгоритмов на графах довольно простым, с другой, такой выбор упрощает разработку и является достаточно надежным. К примеру, можно было бы повысить степень обнаружение взаимосвязей между событиями ИБ при помощи нейронной сети, но такое решение будет намного сложнее в проектировании и внедрение и развертывание его в конкретную организацию потребует довольно большого времени, так как нейронную сеть необходимо обучать и адаптировать под конкретную организацию. Исходя из этого, можно заключить, что алгоритм поиска взаимосвязей на графах является оптимальным для поставленных в проекте задач. В следующем разделе речь пойдет об имитационном моделировании, в котором будут приведены иллюстративные доказательства вывода этого раздела. 60

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 – это использование злоумышленником интерфейса командной строки для взаимодействия с операционной системой; 61

5. Scheduled Task – данный симптом иллюстрирует использование средств операционной системы для запуска задач по определенному расписанию. Таким средством может быть демон cron в операционной системе unix; 6. Exploitation for Client Execution – это использование уязвимостей в программном обеспечении нарушителем безопасности; 7. Accessibility Features – это использование встроенных в операционную систему Windows программных функций отвечающих за авторизацию в системе. Злоумышленник может модифицировать эти программы для того, чтобы войти в систему без ввода учетных записей легитимных пользователей; 8. Create Account – данный симптом представляет собой создание злоумышленником аккаунта на целевой системе, для того, чтобы обеспечить себе беспрепятственный вход в систему без необходимости снова производить взлом; 9. Clear Command History – данный признак определяется очисткой истории команд в терминале или командной строке. В ОС семейства Unix история команд в терминале находится в файле .bash_history, соответственно его очистка или удаление, может сигнализировать о наличии данного признака; 10.Brute Force – это перебор всевозможных комбинаций учетных данных при попытке подключится к легитимной учетной записи; 11.File Deletion – данный симптом представляет собой удаление файлов злоумышленником для того, чтобы скрыть следы своих действий внутри системы; 12.Remote Desktop Protocol – данный признак характеризуется удаленным подключением злоумышленника по RDP; 13.System Network Configuration Discovery – данный симптом представляет собой попытки злоумышленника узнать информацию о сети, к которой он подключился изнутри. Это могут быть попытки узнать 62

топологию сети, выяснить, какие сетевые интерфейсы открыты в системе, к которой он подключился и т.д.; 14.Network Service Scanning – это попытка злоумышленника узнать список запущенных сервисов на хосте, и найти среди них уязвимые к удаленному эксплойту. О наличии этого симптома может свидетельствовать использование нарушителем информационной безопасности сканеров портов; 15.Network Share Discovery – данный признак представляет собой обращения злоумышленника к файлам и папкам, которые являются разделяемыми в сети; 16.System Owner/User Discovery – этот признак характеризуется использованием нарушителем информационной безопасности стандартных средств операционной системы, для определения списка пользователей, которые в данный момент авторизованы в системе; 17. System Network Connections Discovery – это исследование и получение списка входящих/исходящих подключений внутри системы, в которой авторизован нарушитель ИБ; 18.Data Compressed – это использование злоумышленником алгоритмов компрессии для того, чтобы сжать необходимые ему файлы и данные, для дальнейшей передачи через скомпрометированную сеть на свой ресурс. Сжатие необходимо, чтобы снизить нагрузку на сеть при передаче, такой подход позволяет снизить риск быть обнаруженным; 19.Connection использование Proxy – данный злоумышленником симптом различных представляет собой прокси-серверов, чтобы снизить риск обнаружения себя при помощи постоянной смены своего ipадреса при каждом подключении. 5.2. Формирование log-файлов и моделирование атаки Для проверки обнаружения атаки APT41 и прогнозирования дальнейших действий, связанных с этой атакой необходимо подготовить соответствующие 63

log-файлы, в которых помимо симптомов атаки также будут содержаться записи о действиях легитимных пользователей. Для моделирования атаки будут использованы следующие симптомы, являющиеся частью атаки APT41: 1. External Remote Services 2. Valid Accounts 3. Command-line Interface 4. Create Accounts 5. Clear Command History 6. Brute Force 7. File Deletion 8. System Network Configuration Discovery 9. Network Service Scanning 10.System Owner/User Discovery 11.System Network Connections Discovery 12.Data compressed Признаки симптома External Remote Services, Valid Accounts находятся в log-файле auth.log. Информацию о симптомах Command-line Interface, Create Accounts, File Deletion, Data Compressed, System Network Connections Discovery, System Owner/User Discovery, System Network Configuration Discovery можно найти в файлах .bash_history пользователей и файле .bash_history администратора. При отсутствии таковых файлов или установке того факта, что они были очищены, можно утверждать о наличии такого признака APT атаки, как Clear Command History. Информацию о признаке Brute Force можно найти, как в файле auth.log так и в файле secure.log. Содержимое log-файлов представлено в Приложении В. Само моделирование атаки происходило в операционной системе Debian GNU/Linux 9 (stretch), с версией ядра 4.9.0-12. 64

Цепочка действий, осуществляемая автором для моделирования атаки, представлена в Приложении Г [АПК-2-01в]. После моделирования атаки и действий легитимных пользователей операционной системы, запустим разработанную SIEM-систему для анализа logфайлов и поиска в них признаков смоделированной атаки. Рисунки 5.1 - 5.4 иллюстрируют результаты анализа log-файлов SIEM-системой. Рисунок 5.1 – Уведомление об обнаруженной атаке APT41 и прогнозирование дальнейших действий злоумышленника 65

Рисунок 5.2 - Уведомление об обнаруженной атаке APT32 и прогнозирование дальнейших действий злоумышленника Как можно заметить, результаты работы модуля прогнозирования иллюстрируют признаки APT41 и APT32, которые могут появиться при дальнейшем развитии текущей атаки. Ниже представлены скриншоты результатов построения вектора уже обнаруженных признаков развития атаки. 66

Рисунок 5.3 – Первая часть графа обнаруженных признаков атаки 67

Рисунок 5.4 – Вторая часть графа обнаруженных признаков атаки Как можно заметить по рисункам выше, SIEM-система обнаружила все смоделированные автором симптомы, и построила на их основе вектор атаки. Следует обратить внимание, что разработанная система мониторинга и управления событиями ИБ обнаруживает атаку при нахождении взаимосвязи между определенным количеством событий ИБ. Это количество зависит от приоритета для каждого из событий, например, если двух признаков выставлен высокий приоритет, то при нахождении взаимосвязи даже между ними, будет сформировано уведомление о целевой атаке. И наоборот, если у событий выставлен низший приоритет, то, потребуется найти взаимосвязь между множеством событий, чтобы сформировать уведомление о возможном инциденте информационной безопасности. 68

Далее для сравнения запустим IDS и проверим возможности простой системы обнаружения вторжений определить целевую атаку в потоке трафика, проходящем через входной узел в сеть. В настоящем моделировании была использована сетевая IDS/IPS Suricata [28]. Понятно, что NIDS, исходя из названия и принципа функционирования, работает на уровне сети, следовательно, события информационной безопасности, появляющиеся на уровне системы, остаются незамеченными для такого рода программ [29]. Поэтому для моделирования событий информационной безопасности будут проведены атаки следующих типов: 1. External Remote Services 2. Brute Force 3. Network Service Scanning Моделирование этих типов атак было осуществлено при помощи программ с открытым исходным кодом, таких как: 1. Nmap v.7.70 2. Ssh 3. Hydra v.8.5 Результаты работы IDS Suricata проиллюстрированы на рисунках 5.5 - 5.7. Рисунок 5.5 – Детектирование сканирования портов 69

Рисунок 5.6 – Детектирование атаки типа «полный перебор» Рисунок 5.7 – Детектирование авторизации по ssh На скриншотах выше можно заметить, что IDS успешно обнаружила события ИБ, появившиеся в сетевом трафике, но в отличие от SIEM, IDS не смогла связать их между собой. Для Suricata все эти события равнозначны и вся работа по поиску взаимосвязей между ними ляжет на плечи администратора информационной безопасности. 5.3 Оценка эффективности Перед подведением итогов всего проекта, следует оценить эффективность разработанной SIEM-системы, это позволит сделать более полные и построенные на фактах выводы. Как уже был сказано выше, разработанная SIEM-система обнаружила все из смоделированных симптомов, успешно сформировал уведомление о наличие атаки APT41. Также было сформированы уведомление о дальнейшем развитии этой и других атак. Программа отработала за 3.852 секунды. Графически, время работы каждого из модулей представлено на рисунке 5.8 70

Рисунок 5.8 – Диаграмма времени выполнения модулей SIEM-системы На диаграмме можно увидеть, что время работы модуля корреляции почти вдвое больше, чем время работы модуля агрегации и почти втрое больше работы модуля прогнозирования. Стоит заметить, что при увеличении размера графа обнаруженных событий информационной безопасности, разрыв по времени работы между модулем корреляции и модулями агрегации и прогнозирования будет увеличиваться, из-за алгоритма поиска взаимосвязей между событиями информационной безопасности. Для большей наглядности результатов времени работы SIEM-системы сравним ее с совместным использованием HIDS(Host-based Intrusion Detection System) и NIDS(Network-based Intrusion Detection System) [30]. Сравнение будет осуществляться с точки зрения нагрузки на информационную систему [АПК-201у]. 71

Для начала необходимо уточнить топологию размещения всех выше перечисленных приложений в сегменте сети и на хостах. Для SIEM-системы такой топологией будет являться размещение на всех хостах, подлежащих контроля демона rsyslog и размещение самой системы мониторинга и управления событиями информационной безопасности на сервере обработки данных (в нашем случае дополнительный хост). Топология размещение SIEM-системы проиллюстрирована на рисунке 5.8. Рисунок 5.8 – Топология размещения SIEM-системы в сегменте сети Стрелками на рисунке 5.8 показано направление передачи log-файлов демонами rsyslog. Для IDS систем топология представляет собой размещение на хостах сегмента сети HIDS агентов, которые сканируют конечный хост и отправляют данные на IDS-сервер. В точке входа в сеть расположена NIDS, необходимая 72

для обнаружения событий ИБ в сетевом трафике. Графически топология размещения NIDS и HIDS представлена на рисунке 5.9 [АПК-1-01в]. Рисунок 5.9 – Топология размещения HIDS и NIDS в сегменте сети Предположим, что формирование log-файлов и отправка их демоном rsyslog требует 500 тактов процессора. Понятно, что в реальности такая операция потребует значительно больше процессорных тактов, к тому же их количество будет отличаться в зависимости от архитектуры процессора, операционной системы и версии программного обеспечения. Тогда предположим, что проверка HIDS агентом одного хоста занимает 5000 тактов процессора, проверка NIDS точки входа за 3000 тактов, а работа SEIM системы требует 40000 тактов процессора. Для удобства предположим, что все эти действия совершаются за 4 секунды, такой вариант более удобен, чем предположение, что действия всех этих 73

программ и подпрограмм выполняются за 1 секунду, так как ранее было отмечено, что один цикл работы SIEM системы занимает примерно 3.8 секунды. Тогда на результаты сравнения SIEM-системы и HIDS+NIDS представлены на графике, на рисунке 5.10. Рисунок 5.10 – График зависимости количества тактов от времени работы тестовых программ На рисунке 5.10 видно, что тактов процессора для работы HIDS + NIDS несколько выше, чем для работы SIEM. С увеличением количества хостов в сегменте сети этот разрыв буте только увеличиваться, так как количество тактов для работы самой SIEM остается почти на том же уровне, что и было при текущем количестве хостов, а количество тактов для работы rsyslog невелико. В тоже время с увеличением количества узлов в сегменте сети значительно повысит общее число необходимых тактов для обработки все информации средствами HIDS и NIDS. 74

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

Список литературы 1. Advanced Persistent Threat(APT). Таргетированные или целевые кибератаки «Развитая устойчивая угроза». [Электронный ресурс]. – URL: http://www.tadviser.ru/a/272878 2. APT-атаки на кредитно-финансовую сферу в России: обзор тактик и техник. [Электронный ресурс]. – URL: https://www.ptsecurity.com/ru- ru/research/analytics/apt-attacks-finance-2019/ 3. SIEM: ответы на часто задаваемые вопросы [Электронный ресурс]. – URL: https://habr.com/ru/post/172389/ 4. Neomatica [Электронный ресурс]. – URL: https://www.neomatica.com/ 5. ГОСТ Р 50922-2006 Защита информации. Основные термины и определения 6. Методика определения актуальных угроз безопасности персональных данных при их обработке в информационных системах персональных данных от 14.02.2008. 7. Методика определения угроз безопасности информации в информационных системах, проект 2015 г 8. Базовая модель угроз безопасности персональных данных при их обработке в информационных системах персональных данных от 15.02.2008. 9. Системы мониторинга событий безопасности [Электронный ресурс]. – URL: https://www.anti-malware.ru/security/security-monitoring 10. Max Patrol SIEM. информационной Обзор системы безопасности управления [Электронный ресурс]. событиями – URL: https://habr.com/ru/company/tssolution/blog/495280/ 11. APT [Электронный ресурс]. – URL: https://ru.wikipedia.org/wiki/APT 12. Что такое APT-атака и как от нее защититься [Электронный ресурс]. – URL: http://www.spy-soft.net/apt-attack/ 13. ГОСТ Р ИСО/МЭК ТО 18044-2007 Информационная технология. Методы и средства обеспечения безопасности. 76 Менеджмент инцидентов

информационной безопасности от 01.07.2008. 14. MITRE | ATT&CK [Электронный ресурс]. – URL: https://attack.mitre.org/ 15. ATT&CK Mapping [Электронный ресурс]. – URL: https://mitre- attack.github.io/caret/#/ 16. MaxPatrol [Электронный SIEM ресурс]. – URL: https://www.ptsecurity.com/ru-ru/products/mpsiem/ [Электронный 17. FortiSIEM ресурс]. – URL: https://www.fortinet.com/ru/products/siem/fortisiem#resources 18. СерчИнформ [Электронный SIEM ресурс]. – URL: https://searchinform.ru/products/siem/ 19. КОМРАД [Электронный ресурс]. – URL: https://npo- echelon.ru/production/65/11174 20. Security [Электронный Capsule ресурс]. – URL: – URL: https://www.itb.spb.ru/products/Security_Capsule_SIEM/ 21. McAfee ESM [Электронный ресурс]. https://www.mcafee.com/enterprise/ru-ru/products/enterprise-securitymanager.html 22. Агрегация [Электронный ресурс]. – URL: https://ru.wikipedia.org/wiki/Агрегация 23. Log файлы в Linux по порядку [Электронный ресурс]. – URL: https://habr.com/ru/post/332502/ 24. Корреляция SIEM – это просто. Сигнатурные методы [Электронный ресурс]. – URL: https://www.securitylab.ru/analytics/431459.php 25. Корреляция информации в SIEM-системах на основе графа связей типов событий / Федорченко А.В., Котенко И.В. // Информационно- управляющие системы – 2018. 26. Алгоритмы справочник / Джодрж Хайнеман, Гэри Поллис, Стэнли Селков.: Orelly, 2017. – 427с 27. Double Dragon APT41, a dual espionage and cyber crime operation [Электронный ресурс]. – URL: https://content.fireeye.com/apt-41/rpt-apt41 77

28. Suricata как IPS [Электронный ресурс]. – URL: https://habr.com/ru/post/192884/ 29. Общие понятия о системах обнаружения и предотвращения вторжений [Электронный ресурс]. – URL: https://habr.com/ru/company/otus/blog/479584/ 30. HIDS(Host-based Intrusion Detection System) [Электронный ресурс]. – URL: https://ru.bmstu.wiki/HIDS_(Host-Based_Intrusion_Detection_System) 78

Перечень компетенций Компоненты контролируемых компетенций Таблица 1 Код Формулировка компонента компонента АОК-1-01з Знать тенденции развития перспективных направлений науки и техники АОК-1- 01у Уметь применять современные методы и средства поиска научнотехнической информации, использовать иностранный язык как средство делового и профессионального общения. АОК-1-01в Владеть навыками актуализации знаний, их совершенствования и применения в профессиональной и общекультурной сфере. АОК-2-01з Знать организацию, правовые и этические нормы трудовой деятельности коллектива АОК-2-01у Уметь проявлять инициативу, отстаивать свое мнение, вести дискуссию в коллективе, использовать методы и средства коммуникаций АОК-2-01в Владеть навыками практического выполнения проекта в составе коллектива АПК-1-01з Знать основные средства и способы обеспечения информационной безопасности, принципы построения систем защиты информации АПК-1-01у Уметь использовать технологии автоматизированного проектирования и системный подход при проектировании систем защиты, определять ресурсы, необходимые для обеспечения информационной безопасности объектов информатизации АПК-1-01в Владеть навыками проектирования информационных систем на базе корпоративных систем управления базами данных, методами снижения угроз безопасности информационных систем, вызванных ошибками на этапе проектирования, разработки и внедрения АПК-2-01з Знать способы и средства защиты информации от утечки по техническим каналам и контроля эффективности защиты информации АПК-2-01у АПК-2-01в Уметь разрабатывать и исследовать аналитические и компьютерные модели систем, подсистем и компонентов систем защиты информации Владеть методами и технологиями проектирования, моделирования, исследования систем и подсистем безопасности объектов информатизации 79

Приложение А Таблица актуальности угроз безопасности информации Таблица А.1.Актуальность угроз безопасности информации Угрозы утечки ин- Уровень ис- Вероятность реализации угрозы (Y2) Коэффициент Показатель опасности угро- формации по тех- ходной защи- реализуемости ническим каналам щѐнности (Y1) угрозы и за счѐт НСД Средняя Высокая роятность роятность вероятностьвероятность (0) привилегий (2) (5) актуальности (10) Возможность Низкая Средняя Высокая угрозы реализации опасностьопасностьопасность угрозы 0.35 5 2 + средняя Угроза подмены программного обеспече- Вывод об Y=(Y1+Y2)/20 Малая ве- Низкая ве- Угроза повышения зы актуальная 0.35 5 2 средняя ния 80 + актуальная

Продолжение приложения А Продолжение Таблицы А.1.Актуальность угроз безопасности информации Угрозы утечки ин- Уровень ис- Вероятность реализации угрозы (Y2) Коэффициент Показатель опасности угро- формации по тех- ходной защи- реализуемости ническим каналам щѐнности (Y1) угрозы и за счѐт НСД Средняя Высокая роятность роятность вероятностьвероятность (0) (2) (5) Угроза загрузки не5 5 Угроза несанкциониучетной записи поль- актуальности (10) Возможность Низкая Средняя Высокая угрозы реализации опасностьопасностьопасность угрозы 0.5 ной системы рованного создания Вывод об Y=(Y1+Y2)/20 Малая ве- Низкая ве- штатной операцион- зы средняя + актуальная + актуальная 0.35 5 средняя 2 зователя Угроза внедрения кода или данных Угроза преодоления физической защиты 0.25 5 2 + актуальная низкая 0.35 5 2 + средняя 81 неактуальная

Приложение Б Блок-схема алгоритма работы программы Г Начало Чтение данных из системных и пользовательских log-фалов Закончились данные для чтения? Да В Нет Обработка данных модулем агрегации Запись обработанных данных в json log-файлы Чтение данных из подготовленных json log-файлов Закончились данные для чтения? Нет А 82 Да В

Продолжение приложения Б А Нет Обнаружение событий информационной безопасности Построение графа признаков APT-атак, на основе событий ИБ Обнаружена взаимосвязь между событиями ИБ? Да Формирование уведомления о потенциальном инциденте Сопоставление обнаруженного вектора атаки векторам атак кибергруппировок Да Обнаружены совпадения? Формирование уведомления о типе атаки и вероятных вариантах ее развития Нет Б 83

Продолжение приложения Б Б Выдача уведомления пользователю Выбрана ли циклическая работа системы пользователем? Да Г Нет В Запись результатов работы программы в файл Конец 84

Приложение В Содержимое log-файлов .bash_history: ls cd config_files/ nano corr.json atom . cd .. rm corr.json cd .. clear cd .. nano co kill %1 clear ls who lsof -U | head 5 sudo -s su ifconfig ls /etc tar -cjvf /etc configs.bzip cd / find . -name "*.log" cd /usr/bin ls cd / cd /var/log iptables.log PCworkstation kernel: [ 7671.376452] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=50 ID=25852 PROTO=TCP SPT=51302 DPT=1723 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.376525] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=54 ID=16457 PROTO=TCP SPT=51302 DPT=8080 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.376552] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 85

Продолжение приложения В LEN=44 TOS=0x00 PREC=0x00 TTL=41 ID=52271 PROTO=TCP SPT=51302 DPT=199 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.376577] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=57 ID=29935 PROTO=TCP SPT=51302 DPT=111 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.376602] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=52 ID=58255 PROTO=TCP SPT=51302 DPT=21 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.376646] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=41 ID=65329 PROTO=TCP SPT=51302 DPT=256 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.376671] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=42 ID=5883 PROTO=TCP SPT=51302 DPT=993 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.376696] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=57 ID=42372 PROTO=TCP SPT=51302 DPT=113 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.376725] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=44 ID=13517 PROTO=TCP SPT=51302 DPT=53 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.376757] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=49 ID=32045 PROTO=TCP SPT=51302 DPT=5900 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.380303] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=40 ID=14615 PROTO=TCP SPT=51302 DPT=443 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.380342] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=51 ID=43253 PROTO=TCP SPT=51302 DPT=143 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.380367] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=52 ID=3483 PROTO=TCP SPT=51302 DPT=8888 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.380435] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=56 ID=30623 PROTO=TCP SPT=51302 DPT=445 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.381060] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 86

Продолжение приложения В LEN=44 TOS=0x00 PREC=0x00 TTL=53 ID=10080 PROTO=TCP SPT=51302 DPT=587 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.381187] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=53 ID=29543 PROTO=TCP SPT=51302 DPT=1720 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.381860] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=38 ID=14185 PROTO=TCP SPT=51302 DPT=554 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.381967] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=57 ID=53754 PROTO=TCP SPT=51302 DPT=139 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.382587] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=39 ID=32976 PROTO=TCP SPT=51302 DPT=22 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.382728] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=49 ID=46270 PROTO=TCP SPT=51302 DPT=25 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.383406] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=45 ID=43082 PROTO=TCP SPT=51302 DPT=3389 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.383509] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=50 ID=8343 PROTO=TCP SPT=51302 DPT=1025 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.384151] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=37 ID=2067 PROTO=TCP SPT=51302 DPT=3306 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.384177] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=53 ID=31929 PROTO=TCP SPT=51302 DPT=110 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.384205] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=41 ID=62110 PROTO=TCP SPT=51302 DPT=80 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.384234] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=46 ID=11269 PROTO=TCP SPT=51302 DPT=23 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.384359] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 87

Продолжение приложения В LEN=44 TOS=0x00 PREC=0x00 TTL=38 ID=48831 PROTO=TCP SPT=51302 DPT=995 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.385046] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=51 ID=54463 PROTO=TCP SPT=51302 DPT=135 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.385145] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=55 ID=15339 PROTO=TCP SPT=51302 DPT=1057 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.385697] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=40 ID=17559 PROTO=TCP SPT=51302 DPT=7100 WINDOW=1024 RES=0x00 SYN URGP=0 PCworkstation kernel: [ 7671.387627] Iptables: SYN packet detectedIN=enp2s0 OUT= MAC=1c:1b:0d:c1:96:59:ac:e0:10:f3:5d:47:08:00 SRC=291.235.112.122 DST=192.168.1.4 LEN=44 TOS=0x00 PREC=0x00 TTL=46 ID=61665 PROTO=TCP SPT=51302 DPT=10215 WINDOW=1024 RES=0x00 SYN URGP=0 access.log 291.235.112.122 - - [20/May/2020:00:43:00 +0500] "GET /manual/da/nokia HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 291.235.112.122 - - [20/May/2020:00:43:02 +0500] "GET /manual/da/none HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 291.235.112.122 - - [20/May/2020:00:43:03 +0500] "GET /manual/da/processform HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 291.235.112.122 - - [20/May/2020:00:43:05 +0500] "GET /manual/da/process_order HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 291.235.112.122 - - [20/May/2020:00:43:08 +0500] "GET /manual/da/procure HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 291.235.112.122 - - [20/May/2020:00:43:10 +0500] "GET /manual/da/producers HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 291.235.112.122 - - [20/May/2020:00:44:03 +0500] "GET /manual/da/prodconf HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 291.235.112.122 [20/May/2020:00:44:04 +0500] "GET /manual/da/product_compare HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 291.235.112.122 - - [20/May/2020:00:44:05 +0500] "GET /manual/da/product_info HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 291.235.112.122 [20/May/2020:00:44:09 +0500] "GET /manual/da/product_thumb HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 88

Продолжение приложения В 291.235.112.122 - - [20/May/2020:00:44:12 +0500] "GET /manual/da/products HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 291.235.112.122 - - [20/May/2020:00:44:30 +0500] "GET /manual/da/products_new HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 291.235.112.122 - - [20/May/2020:00:44:31 +0500] "GET /manual/da/product-sort HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 291.235.112.122 - - [20/May/2020:00:44:38 +0500] "GET /manual/da/prog HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 291.235.112.122 - - [20/May/2020:00:44:41 +0500] "GET /manual/da/project HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 291.235.112.122 - - [20/May/2020:00:44:42 +0500] "GET /manual/da/promos HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 291.235.112.122 - - [20/May/2020:00:44:44 +0500] "GET /manual/da/promotions HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 291.235.112.122 - - [20/May/2020:00:44:45 +0500] "GET /manual/da/properties HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 291.235.112.122 - - [20/May/2020:00:44:49 +0500] "GET /manual/da/props HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 291.235.112.122 - - [20/May/2020:00:45:01 +0500] "GET /manual/da/pad HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 291.235.112.122 - - [20/May/2020:00:45:13 +0500] "GET /manual/da/page_sample1 HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 291.235.112.122 - - [20/May/2020:00:45:16 +0500] "GET /manual/da/page1 HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 291.235.112.122 - - [20/May/2020:00:45:17 +0500] "GET /manual/da/pagenotfound HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 291.235.112.122 - - [20/May/2020:00:45:18 +0500] "GET /manual/da/Pages HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 291.235.112.122 - - [20/May/2020:00:45:25 +0500] "GET /manual/da/paiement HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 291.235.112.122 - - [20/May/2020:00:45:34 +0500] "GET /manual/da/panelc HTTP/1.1" 404 434 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" sshd.log May 12 01:02:35 PCworkstation sshd[5756]: Failed password for Denis from 291.235.112.122 port 42108 ssh2 May 12 01:03:40 PCworkstation sshd[5755]: Failed password for Denis from 291.235.112.122 port 42106 ssh2 May 12 01:03:48 PCworkstation sshd[5762]: Failed password for Denis from 291.235.112.122 port 42114 ssh2 89

Продолжение приложения В May 12 01:04:06 PCworkstation 291.235.112.122 port 42112 ssh2 May 12 01:04:22 PCworkstation 291.235.112.122 port 42104 ssh2 May 12 01:04:45 PCworkstation 291.235.112.122 port 42110 ssh2 May 12 01:05:03 PCworkstation 291.235.112.122 port 42116 ssh2 May 12 01:05:29 PCworkstation 291.235.112.122 port 42120 ssh2 May 12 01:05:31 PCworkstation 291.235.112.122 port 42118 ssh2 May 12 01:05:33 PCworkstation 291.235.112.122 port 42122 ssh2 May 12 01:05:55 PCworkstation 291.235.112.122 port 42128 ssh2 May 12 01:06:01 PCworkstation 291.235.112.122 port 42132 ssh2 May 12 01:06:02 PCworkstation 291.235.112.122 port 42134 ssh2 May 12 01:06:40 PCworkstation 291.235.112.122 port 42136 ssh2 May 12 01:06:41 PCworkstation 291.235.112.122 port 42138 ssh2 May 12 01:07:12 PCworkstation 291.235.112.122 port 42140 ssh2 May 12 01:07:58 PCworkstation 291.235.112.122 port 42108 ssh2 May 12 01:08:22 PCworkstation 291.235.112.122 port 42106 ssh2 May 12 01:08:34 PCworkstation 291.235.112.122 port 42114 ssh2 May 12 01:08:45 PCworkstation 291.235.112.122 port 42112 ssh2 May 12 01:09:16 PCworkstation 291.235.112.122 port 42104 ssh2 May 12 01:10:13 PCworkstation 291.235.112.122 port 42116 ssh2 May 12 01:10:22 PCworkstation 291.235.112.122 port 42120 ssh2 May 12 01:10:31 PCworkstation 291.235.112.122 port 42118 ssh2 sshd[5758]: Failed password for Denis from sshd[5754]: Failed password for Denis from sshd[5757]: Failed password for Denis from sshd[5766]: Failed password for Denis from sshd[5773]: Failed password for Denis from sshd[5768]: Failed password for Denis from sshd[5775]: Failed password for Denis from sshd[5776]: Failed password for Denis from sshd[5778]: Failed password for Denis from sshd[5779]: Failed password for Denis from sshd[5783]: Failed password for Denis from sshd[5784]: Failed password for Denis from sshd[5787]: Failed password for Denis from sshd[5756]: Failed password for Denis from sshd[5755]: Failed password for Denis from sshd[5762]: Failed password for Denis from sshd[5758]: Failed password for Denis from sshd[5754]: Failed password for Denis from sshd[5766]: Failed password for Denis from sshd[5773]: Failed password for Denis from sshd[5768]: Failed password for Denis from 90

Продолжение приложения В May 12 01:10:32 PCworkstation sshd[5757]: Failed password for 291.235.112.122 port 42110 ssh2 May 12 01:10:51 PCworkstation sshd[5775]: Failed password for 291.235.112.122 port 42122 ssh2 May 12 01:10:56 PCworkstation sshd[5776]: Failed password for 291.235.112.122 port 42128 ssh2 May 12 01:11:32 PCworkstation sshd[5778]: Failed password for 291.235.112.122 port 42132 ssh2 May 12 01:12:15 PCworkstation sshd[5779]: Failed password for 291.235.112.122 port 42134 ssh2 May 12 01:13:21 PCworkstation sshd[5783]: Failed password for 291.235.112.122 port 42136 ssh2 May 12 01:15:25 PCworkstation sshd[5784]: Failed password for 291.235.112.122 port 42138 ssh2 May 12 01:15:30 PCworkstation sshd[5783]: Accepted password for 291.235.112.122 port 42136 ssh2 91 Denis from Denis from Denis from Denis from Denis from Denis from Denis from Denis from

Приложение Г Изображение моделируемой атаки Сканирование портов Сканирование путей web-сервера apache Подключение по ssh Попытка установить владельца системы Проверка наличия исходящих подключений Попытка выяснить конфигурацию сетевых настроек в системе Попытка выяснить конфигурацию сетевых настроек в системе Поиск конфигурационных файлов в системе Попытка выяснить конфигурацию сетевых настроек в системе 92 Атака типа "полный перебор" на ssh Попытка выяснить количество пользователей, зарегистрированных в системе Проверка наличия исходящих подключений Архивация найденных конфигурационных файлов