Сегодня Центры мониторинга киберугроз или Security Operation Center (SOC) стали еще более востребованными. Помимо угроз со стороны злоумышленников необходимо также отслеживать техническое состояние контролируемых устройств, выявлять и исправлять неполадки, обнаруживать сбои и своевременно на них реагировать.
Информационные системы, за которыми осуществляется контроль, обладают сегодня большим масштабом (десятки или сотни тысяч устройств). Сама структура этих систем, а также количество устройств, динамически изменяется и работают они часто «в нескольких средах» (облака и ЦОД).
На практике это означает, что данные поступают из множества точек, и отслеживание всех возможных векторов атак, а также выявление важных событий, связанных с безопасностью, — комплексная задача, решать которую становится сложнее с каждым днем. Очевидно, что такое количество источников данных невозможно обрабатывать вручную. Каждую секунду центр мониторинга получает десятки тысяч событий — все эти горы данных необходимо сортировать и анализировать на предмет аномалий — представьте, сколько времени и ресурсов это может занять.
АВТОМАТИЧЕСКИЙ КОНТРОЛЬ
С другой стороны, за последние годы машинное обучение неоднократно применялось в индустрии кибербезопасности для решения различных задач, например, анализа и классификации пользовательской активности, либо сетевого трафика, обнаружения компьютерных атак. Мы стараемся применять накопленный опыт и для анализа логов SOC, но в настоящей статье хотим поделиться базовой мерой контроля, целью которой является мониторинг потока файлов логов с каждого устройства исключительно по их количеству.
В случае сбоя, технической неполадки, либо инцидента информационной безопасности, количество логов, поступающих с устройства, изменяется. А из-за большого количества устройств адекватной возможности контроля каждого устройства ресурсами аналитиков нет, выявить источник, который нарушает паттерн отправки событий вручную, невозможно, и, к сожалению, бывают случаи, когда отсутствие событий от источников обнаруживается не сразу. Таким образом, автоматический контроль наличия потока необходимого количества логов для своевременного обнаружения и предотвращения инцидентов является эффективной мерой, способной снизить финансовые, репутационные и иные риски.
МОНИТОРИНГ КОЛИЧЕСТВА ЛОГОВ
Для решения данной задачи было проведено исследование и разработан программный модуль, предназначенный для мониторинга количества логов, поступающих с контролируемых устройств. Если описывать задачу более формально, то здесь мы имеем дело с набором показателей, регулярно измеряемых через равные промежутки времени: количество логов на конкретном устройстве в единицу времени, например, один час. Такой показатель принято называть временным рядом, а задача в терминах машинного обучения представляет собой обнаружение аномалий во временных рядах (рис. 1).
Рисунок 1. Пример временного ряда для конкретного источника
Возникает закономерный вопрос: почему нельзя просто выставить определённые пороговые значения, выход за рамки которых свидетельствовал бы о критической ситуации и о необходимости создания нового инцидента. Это простое решение, имеющее право на жизнь. Но для его использования необходимо подбирать пороговые значения. Это можно попробовать сделать, ориентируясь на средние значения или другие характеристики ряда, но в действительности со временем поведение рядов часто может меняется. Более того, в разное время суток, день недели или еще по какой-то закономерности может быть разное пороговое значение. Так, для персонального компьютера, отсутствие активности ночью, может быть нормальным событие, в то время как в рабочий день вероятность такого мала. И конечно же всё это осложняется количеством устройств и большим объёмом информации, с которым приходится работать. И тут на помощь приходят технологии машинного обучения.
С УЧИТЕЛЕМ И БЕЗ
Для решения задачи средствами машинного обучения нам необходимо вначале обучить модель. Обучение может быть двух видов: с учителем и без. Разница в том, что при обучении с учителем у нас уже есть разметка (то есть множество ответов на тренировочных данных, которые учится прогнозировать модель), а при обучении без учителя разметки нет. Наш случай как раз второй, поскольку достаточного количества данных, соответствующих схожим инцидентам, которые мы хотели бы отлавливать, у нас нет. Даже при наличии достаточного числа задокументированных событий тем не менее сохранялась бы опасность наличия большего числа незадокументированных инцидентов, которые потенциальная модель училась бы “считать” нормальными. Кроме того, рядов много, их поведение со временем меняется, поэтому делать разметку и периодически её обновлять было бы очень ресурсозатратно.
ТРИ ПОДХОДА
Для обнаружения аномалий во временных рядах с учетом отсутствия разметки тоже используются разные методы машинного обучения, которые в свою очередь можно разделить на следующие большие группы:
Первый подход хоть и не требует разметки для обучения, но требует ее для тестирования результатов — иначе понять, успешно или нет получается решать задачу, невозможно. Второй подход помогает эффективно искать аномалии в многомерных временных рядах, где важна взаимосвязь показателей. Например, в кластере датчиков, в котором отклонение одного значения без знания других показателей не является критичным. Минусом такого подхода является концентрация на локальном промежутке времени, что ограничивает взаимосвязи, которые можно было бы уловить из данных.
Поэтому мы выбрали подход по прогнозированию временных рядов, как наиболее подходящий в данной ситуации.
ТРИ ШАГА
Общий принцип работы этих методов можно разделить на несколько шагов.
При выборе такого подхода у нас появляется косвенная мера, позволяющая оценить, хорошо ли у нас получится решить целевую задачу — найти ошибку прогнозирования. И возникает вопрос — как мы могли бы измерить ее для 1000 рядов и понять, что у нас все получается. Самые распространенные подходы — измерять модуль или квадрат разности фактического значения и прогнозируемого, чему соответствуют такие меры как MAE (mean absolute error) и MSE (mean squared error).
Тем не менее, для одного временного ряда может оказаться, что в момент загрузки он вполне может продуцировать до 1000 событий в час, и отклонение в 10 событий выглядит совершенно несущественным. Но логично, что присутствуют источники, для которых 20 событий это потолок, и, если количество падает в два раза, это о чем-то да говорит. Можно было бы нормировать (делить) на фактическое значение, чтобы ошибку считать в относительных единицах — это позволило бы сравнивать ошибки для разных источников и хотя бы посчитать среднее значение ошибки на всех рядах для того или иного подхода, чтобы выбрать наиболее оптимальный.
Такая мера обозначается как MAPE или mean absolute percentage error. Но и тут кроется проблема: если текущее фактическое значение равно 0, что вполне нормально для персональных компьютеров, выключенных на ночь, то делить мы также будет на 0, а заниматься этим без разрешения взрослых мы не могли. Существует мера исправляющая этот подход: SMAPE или symmetric mean absolute percentage error, в котором нормировка происходит не только на фактическое значение, а на среднее между фактическим и прогнозируемым значением в этот момент времени. На эту метрику качества мы и ориентировались в своей работе. Существуют и другие распространенные подходы оценить качество прогноза — измерение R2. Но специфика этой метрики такова, что по факту она сравнивает ошибку прогнозирования текущей модели с ошибкой прогнозирования единственным значением, иначе константой. Поскольку в данной задаче мы были нацелены на прогнозирование значительно более качественное, чем константное, эта мера нам также не подходила.
ТРЕНД И СЕЗОННОСТЬ
После того как мы определились, как же нам оценивать результаты прогноза, возникает следующая нетривиальная задача: выбор подхода, алгоритма машинного обучения, который бы универсально подходил для всех временных рядов. Какие же ингредиенты требуются для успешного прогнозирования? На самом деле самые базовые подходы, которых может оказаться достаточно для решения некоторых задач, основаны на скользящем среднем и его вариациях. Т. е. в таком случае следующее значение временного ряда, в данном случае число логов, которое мы ожидаем в следующий час, определяем как среднее число логов за последние n часов. Вполне валидный подход, но для наших целей совершенно не подходящий, поскольку при возникновении инцидента, приводящего к прекращению поступления логов, через эти самые n часов для нашей системы это отсутствие логов станет совершенно нормальным. Противоположной альтернативой является представление временного ряда на всем промежутке времени в виде двух составляющих: тренд и сезонность.
Тренд представляет собой постепенное изменение временного ряда. Например, при запуске сервиса нагрузка на него может быть 100 запросов в час, но впоследствии его востребованность растет.
Сезонность же представляет собой периодические закономерные изменения временного ряда. Например, увеличение числа событий днем и затухание ночью. Проблема такого подхода в том, что не все временные ряды настолько закономерны. Кроме того, подход предполагает оценку тренда и сезонности единожды при обучении, никак не опираясь на текущие показатели временного ряда.
КОМПЛЕКСНЫЙ ПОДХОД
Оптимальным же, как всегда, является подход комплексный, включающий как моделирование сезонных составляющих, так и учитывающий текущие наблюдения временного ряда. В качестве алгоритма реализующего такой подход возможно выбирать любую модель машинного обучения, подходящую для решения задачи регрессии — т. е. определения непрерывного показателя на выходе (в противоположность классификации-определению заранее определенных категорий). Здесь также есть два больших кластера подходов: нейросетевые и классические. Нами были опробованы оба и принято решение использовать модель на основе градиентного бустинга.
В качестве основных признаков, использовавшихся для прогноза значений временного ряда за следующий час, можно выделить следующие:
Примеры работы разработанного модуля приведены на рис. 2.
Рисунок 2. Примеры работы модуля. Жёлтым цветом показаны фактические значения ряда, зелёным прогноз, красным выделены аномальные значения
На рисунке 3 также приведён график с результатом работы модуля, а внутри графика ещё один, на котором изображён временной ряд, использованный для обучения прогнозной модели.
Рисунок 3. Результат работы модуля и временной ряд, на котором обучалась модель
ОГРАНИЧЕНИЯ
На протяжении работы мы также столкнулись с определёнными ограничениями данного подхода. Особенно хочется отметить необходимость оценивать в целом прогнозируемость временных рядов. Описанный подход довольно успешно можно применять в тех случаях, когда ряды прогнозируемы, но на практике бывают случаи, когда ряды сами по себе плохо прогнозируемы и больше напоминают шум. Поскольку каждый ряд описывает количество логов с конечного устройства, а бывает и такое, что устройства постоянно меняют своё поведение (изменяется режим работы, сменяются пользователи этого устройства и т. д.). Необходимо отлавливать такие случаи и обрабатывать их отдельно.
Подводя итог, можно сделать вывод о том, что автоматический контроль количества логов с каждого устройства является дополнительным средством обнаружения инцидентов информационной безопасности. Таким образом, команды SOC могут использовать машинное обучение для выявления новых инцидентов, а значит, более оперативно устранять возникающие угрозы.
Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных
Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных