И снова про SIEM
Решение класса SIEM уже давно стали неотъемлемой частью любой серьезной системы информационной безопасности. В этой статье мы поговорим о том, что такое SIEM, для чего они предназначены и как можно использовать решения с открытым исходным кодом.
Итак, SIEM (Security information and event management) — это система управления событиями безопасности. Технология SIEM обеспечивает анализ в реальном времени событий безопасности, исходящих от сетевых устройств и приложений, и позволяет реагировать на них до наступления существенного ущерба. Основными задачами систем данного класса являются сбор, обработка и анализ событий безопасности, поступающих в систему из множества источников, также обнаружение в режиме реального времени атак и нарушений критериев и политик безопасности. На основе получаемых событий ИБ осуществляется оперативная оценка защищенности информационных, телекоммуникационных и других критически важных ресурсов, анализ и управление рисками безопасности. Во многие современные SIEM системы встроены механизмы принятия решений и инструменты расследования инцидентов. Также неотъемлемой частью SIEM является наличие средств для формирования отчетных документов. Но, давайте для начала посмотрим, для чего вообще нужны SIEM системы.
О журналировании и его проблемах
Любое сколько-нибудь серьезное приложение или ОС ведет логи. То есть, в том или ином виде в системе ведется журнал, в котором фиксируются наиболее важные события. Такими событиями может быть успешный и не очень вход в систему, переход в привилегированный режим, изменение прав на какой-либо файл или объект и многое другое.
Однако, если все эти логи хранятся только на локальном узле, то их полезность несколько снижается. Представим себе ситуацию, когда злоумышленник атакует сервер или сетевое устройство. Скорее всего его действия не сразу увенчаются успехом и возможно в логах будут события о попытках подбора паролей, сканирования портов или выполнения определенных команд. В ОС Windows события сохраняются в журнале Event Log, при этом каждое событие имеет свой номер и описание.
В случае с ОС Linux события журналируются в каталог /var/log/. В нем имеется множество различных *.log файлов содержащих события от различных источников в текстовом виде.
В зависимости от установленных в системе приложений, в каталоге /var/log могут находиться различные файлы журналов.
Однако, когда хакеру удастся захватить административные права в данной системе, он сможет почистить логи, скрыв следу своего присутствия. В случае с Linux, он может просто удалить файлы журналов, или очистить их.
В случае с Windows при очистке логов генерируется событие 1102 Очистка журналов событий.
Однако, злоумышленник может легко избавиться от этого события. Имея необходимые права (будем считать, что взломщик уже получил административные права в системе) можно в свойствах журнала событий легко настроить параметры ротации таким образом, чтобы событие очистки логов было быстро удалено.
Далее, злоумышленник заполнит журнал различными мусорными событиями в таком объеме, чтобы событие очистки просто было удалено. И таким образом, хакер сможет скрыть следы своего присутствия.
В случае с сетевым оборудованием ситуация будет аналогичной. Пока злоумышленник реализует тот же ARP poisoning, коммутатор будет фиксировать манипуляции с ARP записями, однако никуда дальше он их передавать не будет, и атака так и останется незамеченной.
Таким образом, совершенно очевидно, что хранить логи локально это плохая практика. Они недоступны для централизованного анализа. Чтобы прочитать локальные журналы событий необходимо подключаться непосредственно к машине. И в случае физического отказа жесткого диска мы также лишаемся информации обо всех событиях.
В качестве альтернативы локальному хранению логов можно предложить централизованный сбор событий на одном узле. В Linux это делается с помощью службы Syslog, в Windows события могут передаваться с помощью механизма Windows Event Forwarding. В результате мы можем собрать события с нескольких узлов на одной машине. При этом, можно с помощью самописных скриптов анализировать приходящие события на предмет подозрительных активностей и отправлять уведомления об инцидентах в случае их появления. Удобно, но только если у вас не более десятка таких узлов источников и среднее количество событий с каждого из них также немногим больше десяти. В случае если у вас узлов источников или событий больше, начнется потеря событий, так как сервер получатель начнет захлебываться и будет терять события.
И вот здесь у нас возникает необходимость в решения класса SIEM.
Как устроены SIEM
Система управления событиями безопасности, как уже говорилось ранее осуществляет сбор, сохранение, обработку и анализ событий безопасности, поступающих в систему из множества источников, и обнаружение подозрительной активности. Из чего состоит SIEM и какие компоненты реализуют этот функционал на практике?
В классической реализации SIEM состоит из сборщика, событий, ядра, в котором осуществляется корреляция и хранение событий и веб консоли управления.
За получение событий с источников отвечает компонент сбора событий. У разных вендоров этот элемент может называться по-разному: агент, коннектор, коллектор. Суть одна: он должен получить событие от источника. Сбор событий может осуществляться в активном режиме — сборщик событий сам подключается к источнику по различным протоколам (RPC, SMB и т.д.) и собирает у него события. Или же источник сам присылает события посредством протокола Syslog или SNMP.
Компонент сбора событий осуществляет агрегацию, нормализацию, фильтрацию сырых событий, полученных от источника, и затем пересылает эти события в нормализованном виде ядру системы. Агрегация представляет собой объединение нескольких одинаковых событий в одно, тем самым позволяя сэкономить пропускную способность канала. Нормализация событий обеспечивает приведение их к общему стандарту и подготовке к дальнейшей обработке. Например, из сырого события извлекаются значения различных полей SIEM.
На рисунке ниже из представленных событий неудачного входа в систему можно извлечь время создания события, службу (sshd/ss2), имя пользователя (root), адрес источника (192.168.101.46), порт источника 21379.
Набор готовых правил нормализации для наиболее распространенных источников идет вместе с SIEM. В случае, если у нас имеется нестандартный источник, в современных SIEM системах имеется визуальный конструктор для разработки собственных правил нормализации.
Фильтрация — это выборка из общего потока только интересующих событий. Строго говоря, не совсем правильно, если логируются лишние события, лучше просто отключить их создание в настройках системы. Но в некоторых случаях события необходимы различным системам, не только SIEM, и в таких случаях они записываются в журналы.
В результате выполнения всех этих действий нормализованное событие передается ядру, однако сырое событие, пришедшее от источника, также передается ядру для хранения. В случае расследования инцидента может потребоваться оригинальное событие без нормализации.
Подозрительные корреляции
В ядре каждое событие проверяется правилами корреляции. В случае соответствия одному или нескольким правилам создается инцидент. Например, несколько попыток неудачного входа в систему это возможная попытка подбора пароля. Проверка события от системы СКУД о том, что пользователь входил в здание, при входе в домен AD это тоже пример правила. Также, отсутствие обновлений антивирусных баз — это тоже инцидент, требующий расследования.
Правила корреляции, как и в случае с нормализацией имеются в поставке, но при необходимости в состав SIEM также входят инструменты для создания собственных правил.
Созданные инциденты, вместе с событиями также сохраняются БД.
Управление
Большинство современных SIEM систем используют в своей работе веб-интерфейс, так что в качестве клиентского приложения используется браузер.
На основной странице SIEM как правило присутствуют дашборды, отображающие основные параметры работы системы, статистику по событиям, инцидентам, количество подключенных источников и другие параметры.
При желании можно настроить собственные дашборды с красивыми графиками и диаграммами, по аналогии с тем, что представлен ниже.
Открытый код
После ухода с российского рынка иностранных вендоров SIEM, отечественные решения стали активно занимать их нишу. Однако в этой статье я не буду касаться коммерческих решений SIEM, а рассмотрю некоторые из SIEM с открытым исходным кодом.
Начнем с AlientVault OSSIM. Это унифицированная платформа, предоставляющая базовые средства безопасности. OSSIM представляет собой фреймворк, состоящий из нескольких проектов с открытым исходным кодом, включая cетевую систему обнаружения вторжений Snort, систему мониторинга сетей и узлов Nagios, хостовую систему обнаружения вторжений OSSEC и сканер уязвимостей OpenVAS.
Также рассмотрим еще одно решение с открытым кодом Wazuh Security Information and Event Management. Данная система представляет собой централизованную платформу для сбора и анализа событий в режиме реального времени для обнаружения угроз и обеспечения соответствия требованиям. Wazuh собирает данные о событиях из различных источников, таких как конечные точки, сетевые устройства, облачные рабочие нагрузки и приложения, для обеспечения высокого уровня безопасности.
Конечно, использование решений с открытый кодом несет в себе некоторые риски. Так, на рынке труда не так много специалистов, знающих эти системы, кроме того, в случае проблем возможны сложности с поддержкой. Однако для начала погружения в мир SIEM решения с открытым кодом будет вполне достаточно, а дальше многое будет зависеть от уровня сложности тех задач, которые придется решать.
Заключение
В этой статье мы рассмотрели, что из себя представляет SIEM и зачем он нужен, из каких основных компонентов состоит данная система. Также рассмотрели наиболее распространенные решения с открытым кодом. Также хочу пригласить вас на бесплатный вебинар, где вы узнаете, что такое правила корреляции. Мы рассмотрим примеры и разберем использование правил корреляции для автоматизации выявления инцидентов и реагирования на них. Зарегистрироваться на вебинар.
