Перейти к основному содержимому

7 записей с тегом "komrad"

Посмотреть все теги

Что ещё ожидать от 4.5

· 2 мин. чтения
Антон Трофимов
Менеджер проекта

eBPF

eBPF коллектор создает события KOMRAD, используя технологию eBPF - технологию, позволяющую запускать сторонний код в пространстве ядра (если говорить поверхностно). В сфере информационной безопасности и, в частности, продукта KOMRAD, это значит, что благодаря eBPF можно получать информацию о событиях ядра, сетевом взаимодействии и многое другое.

eBPF коллектор основан на open-source продукте Tracee, позволяющем регистрировать и фильтровать множество событий (системные вызовы, передача пакетов и пр.).

Функция задокументирована

Конвертор Sigma в правило

Всем известны правила сигма, нас часто просили добавить конвертацию этих правил в KOMRAD. И мы это сделали, теперь можно вставить готовое правило в плагин и при срабатывании плагин запишет значение в поле. По этому полю можно строить корреляцию.

Функция задокументирована

Веб-скрейпинг или опрос по HTTP

Ранее HTTP-коллектор был пассивным агентом и ждал, пока другая система направит к нему события, но теперь появился плагин http-scraping, который может сам опрашивать сервисы, собирать коды ответов, запоминать их и создавать события, если код изменился, поможет уследить за сроком годности сертификатов и измерит скорость ответов других сервисов.

Функция задокументирована

Справочник MITRE ATT&CK и БДУ ФСТЭК

Уже сейчас можно вписать справочные данные принадлежности атаки в KOMRAD, но куда проще это сделать с готовым справочником, где подходящие техники и тактики можно будет просто накликать.

Возможность использовать двухфакторную аутентификацию

Из внутренней безопасности есть журналы, уведомления, сертификаты, белые списки, а теперь добавится и второй фактор c использованием решения Multifactor.

История продукта KOMRAD Enterprise SIEM

· 3 мин. чтения
Антон Трофимов
Менеджер проекта

Попробуем разобраться с хронологией создания KOMRAD Enterprise SIEM. Не так давно мы выложили историю, здесь приводить не будем, поскольку это объемная таблица.

Визуализация нацелена показать общий вектор развития продукта. Но сразу возникает вопрос, почему представлена только версия 4? Ответ прост, версия 4, является полным перезапуском продукта. Почему его пришлось перезапускать? Комрад 3 с самого начала опирался на форк опенсорса и его доработка являлась, адаптацией для Российского рынка + он имел сертификат, но когда начались серьёзные проекты, разработка зашла в тупик и не могла менять архитектуру решения, не могла довести новые функции до стабильности.

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

На этапе построения архитектуры было много вариантов, в тот момент времени законодателем мод был Elastic, он регулярно попадал в Квадрант Gartner. В первую очередь необходимо было выбрать базу данных. Мы отказались от ElasticSearch, потому что он забирает на себя много ресурсов, а мы хотели сделать систему, которую можно запустить даже на слабом ноутбуке. В качестве базы для внутренних нужд сервисов было принято решение использовать Postgresql, это популярный и качественный инструмент, но при больших нагрузках он тоже начинает отнимать большое количество ресурсов, для того, чтобы этого не происходило, мы использовали Timescaledb, главным образом решающего задачу времени вставки, в качестве эксперимента мы добавляли поддержку CockroachDB, но в последующем отказались, ввиду того, что никто ей не пользовался, а поддержка отнимала. И тут уже на горизонте стал появляться ClickHouse, мы долго сомневались, поскольку изначально он был сырой, но процесс сертификации расставил всё на свои места, мы не могли гарантировать безопасную сборку Timescaledb, а это обязательное требование и мы всё же решились перейти на ClickHouse.

Наравне с базой нам нужна была мощная шина данных, способная справиться с потоком данных с коллекторов и гарантировать безопасность общения сервисов. RabbitMQ или Kafka были написаны на сторонних для нашего проекта языках, и накладывали бы на нас обязательства по их поддержке, как заимствованных компонентов, поэтому решено было использовать NATS, который был модифицирован для наших целей. Для управления активами был заимствован nmap из состава компонентов Сканер-ВС

Остальные компоненты системы создавались уже с нуля. В первую очередь коллекторы и управляющий сервер, затем модуль фильтрации, за который отвечает сервис komrad-processor, одним из самых важных и сложных компонентов является диспетчер корреляции. Если сильно упростить исходную логику, то события фильтровались, а после на отфильтрованные события накладывался фильтр корреляции. Модель корреляции тестировалась месяцами и в процессе для удобства решили сделать конструктор правил корреляции. Впоследствии стало понятно, что кодом при наличие конструктора уже мало кто будет пользоваться. Нам удалось добиться гарантии срабатывания правил корреляции. После корреляции мы добавили модуль управления инцидентами и реакциями. Добавили уведомления в Госсопка, syslog и smtp, этого было достаточно для минимальной версии продукта. Она вышла и получила сертификат.

После была версия 4.3.58 - это большая работа над ошибками, в ней мало новых функций, но много исправлений. Про новое в версии 4.3.58 можно почитать здесь.

Сейчас идёт разработка версии 4.5.Х, а что в ней нового мы писали в другом посте.

Новый пакет экспертиз под источник С-Терра

· 1 мин. чтения
Антон Трофимов
Менеджер проекта

Центр кибербезопасности провёл новое R&D исследование в отношении источника S-Terra IDS.

Источник подключается при наличии лицензии на syslog-коллектор. Описан процесс настройки отправки событий на источнике. Для обработки поступающих событий понадобится включить плагин Suricata IDS/NSM Eve JSON. В рамках расширенной технической поддержки доступны экспертные фильтры (19 шт.) и директивы корреляции (18 шт.).

Релиз 4.5

· 7 мин. чтения
Антон Трофимов
Менеджер проекта

Попробуем разобраться что нового в KOMRAD Enterprise SIEM 4.5, чем он лучше.

Не так давно мы выложили план релиза в открытый доступ, продублируем здесь

3

Визуализация нацелена показать общее количество и направление изменений, здесь же мы попробуем обратить внимание на детали. Начнём с нового

Пакет экспертиз в UI

По мере развития продукта, мы столкнулись с накоплением экспертного контента и потребностью в его обмене как с нашими экспертами, так и с пользователями. Ранее мы использовали неудобный способ вставки подготовленных правил напрямую в базу данных. Однако было очевидно, что такой подход не удовлетворяет потребностям наших экспертов и пользователей. В связи с этим, мы разработали возможность экспорта и импорта директив, фильтров, плагинов и полей событий через графический интерфейс.

При импорте мы также проводим проверки на наличие конфликтов в правилах. Например, если пытаемся добавить директиву с уже существующим именем в системе. В таких случаях предоставляется выбор - автоматически разрешить конфликт или не импортировать правило.

Эта задача тесно связана с иерархическим построением системы, таким как центральный KOMRAD и его филиалы, что обеспечивает простой обмен контентом между ними.

Функция задокументирована

Иерархия

В некоторых проектах, где SOC-центры используют KOMRAD Enterprise SIEM, важно иметь связь между родительским и подчиненным центрами. В связи с этим, мы добавили новую функциональность, которая позволяет не только отправлять события от одного KOMRAD Enterprise SIEM к другому, но также отправлять инциденты, которые наследуют изменения статуса. Если статус инцидента изменяется, происходит синхронизация между системами. В рамках этой задачи мы также добавили возможность отправки данных по защищенному каналу с использованием TLS.

Иерархическая структура позволяет реализовать не только связь между родительским и подчиненным центрами, но и поддерживать несколько родительских и подчиненных систем. Настройка иерархии в настоящее время выполняется через конфигурационные файлы.

Функция задокументирована

Хранение

Мы часто получали запросы от наших пользователей, связанные с необходимостью разделения событий на горячие и холодные данные. Разделение данных на те, к которым требуется быстрый доступ, и на те, которые нужно хранить в соответствии с требованиями регулятора (например, хранить в течение 6 месяцев), является действительно важным.

Мы реализовали данный механизм с использованием ClickHouse. Для этого мы используем одну таблицу, в которой данные хранятся на разных дисках с помощью механизма TTL (Time to Live). Настройка этой функциональности уже встроена в наш установщик, хотя требуется предварительная подготовка дискового пространства для удобного выбора раздела. Возможна и простая настройка после установки.

Функция задокументирована

Агрегация

Функция агрегации является важной составляющей процесса корреляции, и мы продолжаем улучшать ее функциональность. Новая агрегация предоставляет дополнительные настройки, включая агрегацию по ключам. Теперь инциденты группируются не только по временному окну и числу событий на фильтре, но также имеют более гибкие возможности группировки. Например, можно работать с массивом данных, которые часто встречаются в полях, связанных с IP-адресами. Для использования этой агрегации применяется простой язык написания правил.

Функция задокументирована

Но процесс агрегации может быть ещё сложнее, и по запросам клиентов мы добавили преагрегацию и постагрегацию.

Преагрегация включена в коррелятор и работает следующим образом: когда количество инцидентов в секунду превышает определенный порог, все инциденты сверх этого порога объединяются в один, и затем регистрируется только этот объединенный инцидент.

Постагрегация инцидентов происходит во время регистрации инцидентов. Для активации постагрегации необходимо включить опцию "Агрегировать инциденты" при создании директивы и указать временное окно, а также опционально указать максимальное количество инцидентов в одном агрегированном событии.

При пре- и постагрегации агрегирующий инцидент будет содержать все ключи событий и активов, составляющих инциденты. Дата начала будет равна минимальной дате начала из составляющих инцидентов, а дата выявления инцидента - максимальной дате выявления инцидента.

Функция задокументирована

Дашборды

Визуализация в SIEM является одной из важнейших функций, которая значительно улучшена в новой версии KOMRAD 4.5. Ранее доступными были только преднастоенные виджеты и один дашборд, что зачастую требовало от наших клиентов использования сторонних инструментов визуализации, таких как Grafana.

Однако, с добавлением новой версии, пользователи теперь могут редактировать существующие виджеты, добавлять новые и создавать свои собственные дашборды. Сами виджеты претерпели значительные изменения, включая добавление новых метрик, основанных на методиках jira.

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

Функция задокументирована

Уведомления

Мы получали много запросов от пользователей о добавлении возможности отправки уведомлений в Telegram. Для реализации этой функциональности нам потребовалось добавить новый транспорт webhook. И теперь у нас есть возможность отправлять уведомления в любую систему, включая Telegram, используя этот webhook.

Настройка данной функции производится в конфигурационном файле komrad-server. Теперь пользователи могут легко настроить уведомления и получать их в Telegram или в любой другой системе, подключенной через webhook. Это предоставляет гибкость и удобство в использовании уведомлений в нашей системе.

Функция задокументирована

Кроме того, у нас появился новый транспорт Kafka, который позволяет синхронизировать инциденты.

Функция задокументирована

Имитация эластика

ELK (Elasticsearch, Logstash, Kibana) долгое время оставался стандартом в области мониторинга и пользуется большой популярностью. Многие системы SIEM до сих пор включают в свою архитектуру компоненты этого открытого исходного кода. На самом деле, если у вас уже настроены инструменты, такие как Vector или Winlogbeat, то зачем вам заморачиваться настройкой дополнительных инструментов от поставщика SIEM.

Теперь вы можете отправлять события напрямую из Vector, Winlogbeat, Heartbeat, Fluentd, Logstash, Filebeat, Metricbeat, обеспечивая прямую интеграцию с нашей системой SIEM. Но это еще не все, вы также можете подключить любой другой источник данных, который ожидает связи с базой данных Elasticsearch.

Это дает вам возможность использовать уже существующую инфраструктуру и инструменты, сокращая время и затраты на настройку новых инструментов. Вы получаете гибкость и расширенные возможности для сбора и анализа данных в нашей системе SIEM.

Функция задокументирована

Оффлайн коллекторы

Для заказчиков с автономными сегментами сети закрыта потребность в оффлайн сборе. Теперь вы можете запустить коллектор без связи с транспортной шиной, события будет писаться в файл, который потом можно будет загрузить на центральный узел KOMRAD. Оснащены оффлайн сбором WMI и Syslog коллекторы.

Функция задокументирована

SQL-коллектор

В SQL-коллектор добавилась возможность импорта шаблонов подключений, пока это возможно делать через базу, но новые шаблоны будут также предоставляться в рамках технической поддержки. Добавление такой функции обусловлено тем, что шаблоны быстро устаревают и в них нет версионирования. Также мы обновили часть шаблонов сбора.

Функция задокументирована

Файловый коллектор

Файловый коллектор получил более 20 новых настроек для сбора, но главная добавленная функция - это сбор с директорий и папок, коллектор стал стабильнее и надёжнее, каким и должен был быть изначально.

Функция задокументирована

Плагины

Плагин IF предоставляет возможность создания логических цепочек или деревьев решений для нормализации последовательности событий. Вы можете определить, как именно события должны быть нормализованы, а также указать, что они должны подпадать под несколько плагинов по условию. В новых плагинах доступен метод cel-go для задания правил нормализации, но также можно использовать регулярные выражения.

Функция задокументирована

Схема событий 2.0

Введение термина "индексация" стало новым для многих наших пользователей. Ранее, при использовании фильтров, события, соответствующие этим фильтрам, сохранялись отдельно, и для обновления данных по фильтру требовалась предварительная индексация. Однако этот процесс индексации вызывал ряд проблем, таких как утечки ресурсов и перегрузка базы данных.

В новой версии KOMRAD 4.5 индексация больше не требуется благодаря новой схеме обработки событий. Подробности о технических особенностях будут доступны позже, но это значительное событие в развитии нашего продукта.

Это важный шаг, который помогает улучшить производительность и эффективность системы, а также снизить нагрузку на ресурсы и базу данных. Мы продолжаем стремиться к развитию и усовершенствованию нашего продукта, чтобы обеспечить нашим клиентам наилучший опыт использования и более эффективную обработку данных.

Обновление документации

· 3 мин. чтения
Антон Трофимов
Менеджер проекта

На днях состоялось обновление документации для продукта KOMRAD. Спешим раскрыть все секреты касательно того, как это произошло.

Немного истории

3 года назад мы готовили сертификационную документацию по требованию ФСТЭК и задумались над тем, что сложно поддерживать её в актуальном состоянии. Дело в том что сертификационная документация очень долго обновляется и вообще это сложный процесс для всех:

  • для заказчика (он постоянно должен у спрашивать саппорта "а может ли продукт то, что не описано в руководстве, и как это сделать?"
  • для разработчика (согласовать новую версию руководства с ФСТЭК, а у нас оно лежит на диске, пересчитать КС и отправить всем)
  • для ФСТЭКа ничего кроме руководства не меняется, но документация все равно проходит все формальные процессы в ведомстве, и это может быть очень долго
  • для саппорта (у саппорта должна быть либо своя база знаний, либо мини-инструкции на любой случай)

Antora

Поэтому мы задумались о том, чтобы иметь электронную документацию, которая потенциально решила бы все наши проблемы. В первый раз мы не выбирали долго, форкнули готовый проект на Antora и переделали её под себя настроили CI/CD, начали документировать. Антора немного специфична, например, формат разметки текста в ней asciidoc. Поскольку это была наша первая электронная документация, мы хотели быстро её сделать и быстро выложить. С первым мы справились действительно быстро, сделали простое деление на руководство администратора и оператора, остальные статьи были отсылками к другим документам, но, в итоге, мы посчитали, что более структурировано будет выглядеть архитектура с продуктовой логикой, вдохновлялись документацией.

Стоит отметить, что у таких проектов, как Антора есть своя философия, там есть своя структура папок, есть рекомендации по CI, но мы, в большей степени, её игнорировали с самого начала. И не стоит забывать, что мы переделывали форк под себя, мы пытались оградить UI и бэкенд специалистов от работы, связанной с документацией, но повышать зависимости надо и документация начала ломаться. Большой проблемой стал поиск, когда локальный поиск сломался, мы попробовали его переписать, но безуспешно, UI жаловался на легаси код и отклонял наши хотелки, например, возможность зумить изображения. Вершиной всего стало то, что из-за неверной настройки нам пришлось бы потратить много времени на добавление новых версий, хотя, в репозитории документации уже были готовые ветки, из которых просто нужно было собрать версии.

Муки выбора

Есть достаточное количество проектов для электронной документации. В большей степени, они используют Markdown, очевидно, он проще и популярнее, поэтому для нас это было не ограничением, но препятствием. Мы рассматривали такие проекты:

По набору функций нас впечатлили Docusaurus и Gitbook, но у Docusaurus больше запас на развитие документации, поэтому мы сделали выбор в его пользу. Развитие - это фичи, которые можно опционально подключить, в docusaurus - это плагины, сейчас их не так много, по причине обновления docusaurus до версии 3, на 2-й версии их было огромное количество, но не все ещё добавили поддержку 3-й версии.

Docusaurus

Новые фичи:

  • локальный поиск
  • зум изображений
  • работа с формами
  • тёмная тема
  • версионирование
  • новое индексирование

Мы перенесли все документы в их исходном виде и добавили ещё одну версию 4.5.Х, сейчас она в стадии Beta и выдаётся по запросу, но уже сейчас есть доступ к её актуальной документации. Новые функции и новая логика элементов и страниц будет правиться только для версии 4.5.

Перевыпуск сертификатов

· 2 мин. чтения
Антон Трофимов
Менеджер проекта

На форме поддержки вышла статья про перевыпуск сертификатов. Тема важная, поэтому продублируем здесь.

Часто поступают запросы, связанные с падением сервисов или коллекторов через несколько месяцев после установки. В большинстве случаев это связано с сертификатами. Давайте разберёмся в чём дело.

Какие у нас есть сертификаты?

Мы составляем цепочку сертификатов, чтобы в случае компрометации одного из цепочки не была скомпрометирована вся система. В общем случае, подразумевается наличие сертификатов:

  • Корневой (CA)
  • Серверный (Server)
  • Клиентский(Client)
  • Браузерный(Browser)

Где лежат сертификаты?

Сертификаты, расположенные в /var/lib/echelon/komrad/certs/, являются одним из гарантов безопасности Вашей системы. На папку есть специальные разрешения, доступ к ней должен быть у группы root и пользователя komrad.

Какой срок годности у сертификатов?

При установке в автоматическом режиме установщик сам выставит сроки их годности.

  • Корневой (CA) 12 месяцев
  • Серверный (Server) 3 месяца
  • Клиентский(Client) 3 месяца
  • Браузерный(Browser) 3 месяца

Как определить что проблема с сертификатом?

В лога Вы увидите ошибку:

x509 expired certificate

Как проверить срок годности сертификатов?

Выполните команду:

openssl x509 -in /var/lib/echelon/komrad/certs/ca.pem -text -noout | grep "Not After" && openssl x509 -in /var/lib/echelon/komrad/certs/server.pem -text -noout | grep "Not After" && openssl x509 -in /var/lib/echelon/komrad/certs/client.pem -text -noout | grep "Not After"

После выполнения команды будет выведен результат. Если напротив сертификата будет стоять параметр Not Afterраньше текущей даты значит сертификат сертификат просрочен, необходимо выпустить сертификаты. Выпустить серверный сертификат

sudo komrad-cli certificates create server --organization “Echelon” localhost 127.0.0.1 $(hostname -I) $(hostname) --ca /var/lib/echelon/komrad/certs/ca.pem --ca-key /var/lib/echelon/komrad/certs/ca-key.pem

Выпуск клиентского сертификата

sudo komrad-cli certificates create client --ca /var/lib/echelon/komrad/certs/ca.pem --ca-key /var/lib/echelon/komrad/certs/ca-key.pem

Браузерный сертификат

sudo cp ./client-browser.p12 client.pem client-key.pem server-key.pem server.pem /var/lib/echelon/komrad/certs

Не забудьте указать необходимые сроки годности флагом expire например так:

sudo komrad-cli certificates create ca --expire 24m

Если сертификаты по какой-то причине не воспринимаются сервисом, например они лежат в не стандартной папке, дайте разрешение на их использование пользователю komrad выполнив команды :

sudo chown -R komrad:komrad /var/lib/echelon/komrad/certs
sudo chmod -R 755 /var/lib/echelon/komrad/certs
sudo chmod 0640 /var/lib/echelon/komrad/certs/server-key.pem
sudo chown root:komrad /var/lib/echelon/komrad/certs/server-key.pem
sudo usermod -a -G komrad postgres
sudo chmod 755 client-browser.p12

Не забудьте перезапустить сервисы!