Помните, когда-то мы раскрыли неочевидную связь между гастритом… и системой выявления инцидентов? За это время MaxPatrol SIEM обновился 17 раз (не считая хотфиксов), перешагнул отметку в 650 инсталляций, включая географически распределенные, и приобрел множество новых фич. Я, Иван Прохоров, отвечаю за развитие этой SIEM-системы. Вместе с коллегой Романом Сергеевым, который трудится над архитектурой MaxPatrol SIEM и не только, мы решили, что пора — пора писать новую главу о разработке продукта.
Как удалось создать по-настоящему экспертную SIEM-систему и сделать ее более отзывчивой для аналитиков, заместить общедоступные технологии собственными (снизив при этом hardware footprint), сколько было подходов к снаряду и что получилось воплотить вопреки обстоятельствам — рассказываем в статье.
Спойлер: все это мы делаем ради того, чтобы прийти к кульминации нашей истории — главе под названием «Результативный SIEM» 😉
Встаем на линуксовые рельсы
Технологический стек, на котором начиналась разработка компонентов MaxPatrol SIEM, отвечающих за сбор данных и работу с активами, значительно пересекался с системой контроля защищенности и соответствия стандартам MaxPatrol 8: Win32 API, C#, SQL Server. В 2015 году из-за изменения конъюнктуры рынка наша команда стала делать SIEM-систему кроссплатформенной.
Была и еще одна причина: присущие Windows ограничения не позволяли нам разрабатывать высокопроизводительную SIEM-систему в кроссплатформенном стиле, поэтому высокопроизводительные инсталляции мы сразу же ориентировали под Linux. Долго существовать с гетерогенной системой, одна половина которой написана для Linux, вторая — на Windows, мы не смогли. Дуализм усложнял обслуживание, тормозил разработку и «размывал» экспертизу. Так наша команда пришла к идее унификации и полному переезду на Linux. Одновременно с этим Microsoft стал отходить от использования Windows как серверной системы для enterprise-приложений и начал адаптировать свои технологии, в частности .NET Framework, под Linux. Переход занял порядка трех лет: мы планомерно переводили более 50 микросервисов в формат, пригодный для постановки на кроссплатформенные рельсы. Челленджем стал лишь перенос коллектора. Операция проходила долго и мучительно…
Один из типичных источников событий в MaxPatrol SIEM — Windows Log. Его реализация под Linux потребовала реверс-инжиниринга протоколов и повторения функциональности, которая под Windows предоставляется «из коробки» бесплатно. При этом параллельно наша команда продолжала выпускать новые фичи для SIEM-системы. Кроме того, мы потратили немало сил на рефакторинг и выплату накопившихся архитектурных и технических долгов. В процессе разработки мы также постепенно переходили с баз данных SQL Server и MongoDB на PostgreSQL.
Можно купить хороший костюм в магазине, но лучше сшить его на заказ
… или Почему мы перестали применять Elasticsearch и разработали свою СУБД
Для работы систем класса SIEM необходимо обрабатывать и хранить большие объемы структурированной и не очень информации. В среднем объем обрабатываемых за сутки данных — сотни миллионов записей в сотни гигабайт из разнообразных логов.
Даже с возможностями современных аппаратных платформ решение этой задачи представляет собой серьезный инженерный вызов.
Все игроки рынка SIEM делятся на две большие группы:
-
обладатели проприетарной базы данных, заточенной под специфику работы продукта;
-
пользователи решений с открытым исходным кодом.
Все лидеры мирового рынка относятся к первой группе. Мы эволюционировали из второй группы в первую, разработав свою СУБД для хранения и анализа собираемых ИТ- и ИБ-событий. Ранее мы применяли Elasticsearch, в 2017 году присматривались к ClickHouse, который используется в другом нашем продукте — системе глубокого анализа трафика технологических сетей PT Industrial Security Incident Manager (PT ISIM). Мы поняли, что нам он не подходит по скорости обработки данных. Кроме того, в SIEM-системах другие сценарии использования, чем в сервисах аналитики Яндекса, для которых создавался ClickHouse.
Наше видение MaxPatrol SIEM — это высокопроизводительная и технологичная SIEM-система для компаний из сегмента enterprise. Продукт должен работать без присмотра на ограниченном «железе», справляться с большим объемом данных и давать быстрый отклик. Для этого нам пришлось создать проприетарную технологию, которая дает преимущества в части эффективности и более высокой адаптивности к задачам SIEM-системы.
Разработка собственного хранилища LogSpace начиналась с форка одной из первых публичных версий СУБД ClickHouse, и за прошедшие годы решения очень сильно разошлись в кодовой базе и своих возможностях. Так, например, в эффективности использования всех аппаратных ресурсов (CPU, RAM, disk space) мы значительно превосходим оригинальный ClickHouse: у нас в 3,5–4 раза выше плотность хранения. Из других преимуществ:
-
автоадаптируемость — автоматическое определение наиболее эффективного кодирования в зависимости от реальных данных. Это означает, что разные блоки одного файла-колонки в одном сегменте могут быть кодированы по-разному;
-
развитая система резервного копирования — специализированная, гибкая, zero-overhead, безопасный атомарный бэкап, который поддерживает много поколений архивов, частичное архивирование, моментальное восстановление и пр.;
-
атомарный и более безопасный ALTER TABLE;
-
более эффективная реализация работы с NULL-значениями, что характерно для разреженных (sparse) схем хранения событий в SIEM-системах.
Видим инфраструктуру, разбросанную в десяти часовых поясах
С ростом количества внедрений MaxPatrol SIEM в крупных российских компаниях (сегмент enterprise и large enterprise) мы изучили их привычки и особенности. Во-первых, такие организации не хранят данные в облаках. Во-вторых, у них географически распределенная инфраструктура, порой находящаяся в десяти часовых поясах, а специалисты по ИБ, которые работают в SIEM-системе в центрах мониторинга ИБ (SOC), наоборот, сконцентрированы в одном месте. Каналы связи между филиалами, как правило, оставляют желать лучшего.
Перед нашей командой стояла трудоемкая задача выстроить архитектуру решения, которая позволит обеспечить принцип локальности сбора и обработки основных объемов данных, то есть событий ИТ и ИБ (именно обилие событий ИТ и создает основной челлендж). Параллельно с этим требовалось обеспечить простую и бесшовную работу с ними подразделения ИБ, которое находится в центральном филиале. Реализация заняла полтора года.
Пишем детекты с чистого листа. Почему?
При описании логов не применяются единые стандарты, а информация о том, как в логах различных систем (Windows, веб-серверов, баз данных) фиксируется, например, неправильный ввод пароля, всегда разная. На практике логи продумываются и пишутся программистами в последний момент. Они редко задумываются об удобстве тех, кто в дальнейшем будет их анализировать. В целом ситуация постепенно улучшается, однако основная масса интересных с точки зрения ИБ логов до сих пор оставляет желать лучшего. Таким образом, главная сложность в разборе логов, собираемых с разных источников, состоит в том, чтобы понять, в каком виде их лучше представить SIEM-системе. Помимо этого, вендорам таких систем трудно писать собственные алгоритмы детекта для каждого типа источников событий в случае, например, брутфорса: рациональнее сформировать единые описания нормализованных событий для выявления этой и других активностей злоумышленников.
С 2017 года мы регулярно выпускаем пакеты экспертизы с правилами обнаружения угроз для MaxPatrol SIEM и за это время накопили опыт и получили понимание, как лучше всего нормализовывать события ИБ, чтобы в дальнейшем нам самим, клиентам и партнерам было легче писать универсальные детекты.
Реализация новой схемы нормализации была сопряжена со значительными трудностями. Так, например, была частично потеряна обратная совместимость, что оказалось очень болезненным: у нас много всего уже было написано. Кроме того, кастомные детекты самостоятельно писали многие клиенты MaxPatrol SIEM.
«Железо» и полмиллиона EPS: в поисках баланса
Из года в год одной из задач каждого нового релиза MaxPatrol SIEM был рост производительности при максимально возможно низких аппаратных ресурсах. В еще непубличных первых версиях мы начинали с 500 EPS. Для тестирования брали последний сервер из линейки DELL. В 2020 году наша команда разработки обеспечила скорость обработки данных до 40 тыс. событий в секунду, в 2021 году — до 60 тыс. Это средние показатели, достаточные для 95% российских компаний. С фичей по горизонтальному масштабированию увеличивать производительность MaxPatrol SIEM уже не было смысла, однако наш челлендж с «железом» на тот момент все еще не был решен.
Кроме того, мы видели запрос рынка на снижение требований к мощности используемых процессоров, объему оперативной памяти, а также дисковому пространству, необходимому для хранения событий. К нам также обращалось все больше компаний с крупными территориально распределенными инфраструктурами, которые хотели передавать в SIEM-систему многократно больше событий по требуемым им протоколам. Обстоятельства подтолкнули нас подойти к этой комплексной задаче с особой тщательностью к деталям.
Она потребовала ментально и процессно перестроить практику нагрузочного тестирования: мы научились правильно измерять пропускную способность для заданных аппаратных ресурсов. Это позволило определять тот минимум оборудования, который при внедрении необходим клиентам для обработки точного количества событий в секунду. Во время перестройки процессов нагрузочного тестирования мы стали использовать полученные детальные данные в разных аналитических разрезах для фокусировки разработки и т. д.
Обновление и совершенствование MaxPatrol SIEM — это постоянная гонка между «железом» и новой экспертизой для обнаружения актуальных киберугроз. Наша SIEM-система — максимально экспертный продукт, который к тому же еще и хайлоад (основную нагрузку составляет разбор и анализ логов для выявления атак). Экспертное наполнение главным образом потребляет аппаратное обеспечение. Экспертиза обновляется в среднем два раза в месяц, сейчас в продукте более 350 поддерживаемых источников событий и свыше 1200 правил корреляции.
С версии 8.0 мы значительно снизили требования MaxPatrol SIEM к «железу». Например, теперь для развертывания системы, которая обрабатывает до 5 тыс. событий в секунду, необходимо в два раза меньше процессоров (vCPU) и вдвое меньше оперативной памяти, чем раньше. Это позволяет компаниям уменьшить расходы на покупку оборудования (не забываем, как сложно и дорого его сейчас приобрести) и облегчает внедрение SIEM-системы.
Что касается производительности, на одном ядре продукта MaxPatrol SIEM и с использованием всех экспертных правил сейчас обрабатывается более 540 тыс. событий в секунду. Этот показатель позволяет организовать мониторинг больших потоков событий без регресса качества детекта и без компромиссов при выборе пакетов экспертизы. Рост производительности позволяет обеспечить мониторинг больших геораспределенных инфраструктур, которые объединяют сотни компонентов MaxPatrol SIEM в единую точку мониторинга.
Куда же без машинного обучения
Применение статических экспертных правил детектирования — конечно, хорошо, но когда к ним добавляется и набор правильно обученных и настроенных ML-модулей, заменяющих десятки (а иногда и сотни) правил и ускоряющих обнаружение как известных, так и плохо изученных атак и аномалий, это становится мегаздорово для аналитиков ИБ. В MaxPatrol SIEM есть ML-модуль поведенческого анализа (Behavioral Anomaly Detection, BAD), который кардинально снижает трудозатраты специалистов по ИБ и повышает эффективность их работы, а также механизм вайтлистинга, уменьшающий информационный шум.
Задачи и первого, и второго — уменьшить скоуп алертов, который операторам необходимо охватить глазами, то есть разгрузить их, и акцентировать внимание на инцидентах, требующих реагирования. Без них SIEM-системы могут генерировать десятки тысяч оповещений в день, в то время как пропускная способность зрелого SOC — от 10 до 50 легких киберинцидентов в день. Эти фичи позволяют адаптировать MaxPatrol SIEM и его экспертное наполнение под конкретную инфраструктуру, а специалисты по ИБ получают возможность быстрее и точнее предотвращать развитие кибератак. В частности, BAD работает как система второго мнения. Модуль содержит порядка 50 моделей машинного обучения, разработанных на основе двадцатилетнего опыта Positive Technologies в расследовании инцидентов. BAD собирает и анализирует данные о событиях, пользователях, процессах в контексте событий и присваивает им определенный уровень оценки риска (risk score).
Облака как источники данных
Со временем все больше российских компаний, в особенности в сфере ритейла и e-commerce, энергетики, разработки цифровых продуктов и решений, стали размещать свои ресурсы или часть инфраструктуры в облаках. Следовательно, у них возникла необходимость контролировать их безопасность. В ответ на эту потребность мы добавили в MaxPatrol SIEM облака как один из источников данных о защищаемой инфраструктуре (например, мы поддерживаем Amazon, Yandex Cloud, VK Cloud). Помимо этого, наш продукт может отслеживать безопасность любых ИТ-систем, находящихся в облаке, как отдельных источников, анализировать все события ИБ в облаке, а также позволяет писать правила корреляции для событий, которые он оттуда получает.
Мы стремимся сделать нашу SIEM-систему cloud native, что упростит ее внедрение в облачных и контейнерных средах. Еще одна задумка — работать не только с классическими источниками и потоками данных, как мы можем уже сейчас, но и с данными из data lake.
Итоги
В начале нашего пути из-за time to market мы разрабатывали MaxPatrol SIEM на базе доступных и готовых технологий, которые серьезно дорабатывали под задачи продукта. Но уже тогда как технологический лидер мы осознавали, что нужно создавать результативные продукты и, развивая их, предвосхищать будущие вызовы и потребности пользователей. Все эти годы мы поступательно двигались к тому, чтобы MaxPatrol SIEM обрел необходимый нам уровень технологичности: мы замещали собственными технологиями те, которые оказались недостаточно эффективными и производительными (MongoDB, Elasticsearch, Redis и др.), внедряли то, что считали перспективным (Linux, ML, распределенный поиск событий, абсолютно гибкую корреляционную логику, в будущем — Kubernetes). В общем, делали все, чтобы обеспечить работу MaxPatrol SIEM на высоких скоростях, без тонны «железа», с быстрым откликом и главное — с гарантией качественного обнаружения потенциально опасных киберинцидентов.
Мы раскрыли еще больше секретов о разработке MaxPatrol SIEM в нашем цикле статей «Оголяемся технологически»:
ссылка на оригинал статьи https://habr.com/ru/articles/852784/
Добавить комментарий