«КОМРАД 4.0»: кросс-платформенная отечественная SIEM-система с дружественным интерфейсом и высокой производительностью

    Рады сообщить, что мы завершили разработку четвертой версии системы управления событиями информационной безопасности «КОМРАД» и начинаем бета-тестирование продукта.

    Мы повысили производительность и стабильность работы системы, продукт стал кросс-платформенным (можно развернуть в ОС Windows и Astra Linux), сделали массу улучшений, о которых подробно расскажем в наших следующих постах.

    Основной функционал SIEM-системы «КОМРАД 4.0»:

    • централизованный сбор событий информационной безопасности с различных источников с помощью Syslog, WMI, SSH, FTP, SFTP, SNMP, sFlow, Netflow v5/v9 и SQL (MSSQL, MySQL, PostgreSQL, SQLite);
    • разбор событий при помощи настраиваемых плагинов;
    • фильтрация событий;
    • визуализация данных;
    • автоматическое выявление инцидентов по заданным директивам корреляции;
    • гибкая настройка правил фильтрации и корреляции;
    • инвентаризация информационных активов;
    • управление инцидентами;
    • агрегирование инцидентов;
    • оповещение в реальном времени операторов системы;
    • интеграция с ГосСОПКой;
    • мониторинг компонентов системы;
    • автоматическая ротация устаревших событий;
    • формирование отчетов;
    • аудит действий пользователей.

    Правила фильтрации и директивы корреляции теперь формируются с помощью скриптов, что позволяет очень тонко настроить систему и значительно снизить вероятность ложных срабатываний. Динамическая структура события позволяет создавать пользовательские поля, что расширяет возможности для отслеживания специфических данных в событиях. В ходе нагрузочного тестирования на сервере чуть выше начального уровня с процессором Хeon E5-2650 v2 2.60GHz (10 ядер) и 32 Гб ОЗУ была получена скорость обработки событий порядка 5500 EPS (запись событий и индексов). Развертывание и администрирование системы максимально упрощено, в качестве СУБД может использоваться Couchbase или PostgreSQL c Timescale DB. Долгосрочное хранение событий возможно как локальное, так и в S3-совместимом облачном хранилище. Реализован собственный нативный WMI-агент, создающий минимальную нагрузку для системы. Возможен глубокий разбор структуры WMI-события.

    Пользовательский интерфейс стал еще удобнее:


    Форма редактирования фильтра событий


    Форма настройки плагина

    Если у наших читателей есть интересные и актуальные кейсы, связанные с применением SIEM-систем, которые нужно разобрать, то просим оставить комментарий, и мы постараемся учесть эти кейсы при написании следующих статей и документации на продукт.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 10

      +4
      Если она не работает на процессорах КОМДИВ, то не нещитово.
        +1
        хочу гифку кейса:
        алерт, что на сервере не работает служба, почему не работает служба, потому что она остановилась (штатно?) когда? строчка с командой остановки, parent process id, owner
        почему остановилась?
        показать события, которые были рядом с событием остановки (фильтр по хосту, время -1 минута от события Ч), ага, там авторизовался наш 1с-ник Вася, и решил что-то перезапустить, а то что зависимая служба сама не поднимется, он не знает.
        ну как-то так.
        Первую часть алерта обычно решает заббикс, вторую часть поиска logbeats+elasticsearch+kibana
          0
          Спасибо за сценарий, будем использовать! Такое расследование с помощью «КОМРАД 4.0» пользователь провести сможет.
          0

          Судя по скриншотам для выборки событий используется скрипт на LUA.
          Довольно необычный подход (если ты конечно не разработчик игр или embedded систем ;))


          Если посмотреть конкурентов то это SQL подобные DSL (SPL у splunk, PDQL у позитива, Lucene/KQL у ELK SIEM).


          Вроде так сложнее выстрелить себе в ногу и это понятнее аналитикам ИБ?
          Чем вызван такой непривычный выбор?


          Ничего личного не имею против Lua, но в 2020 году вообще мало осталось аргументов в пользу него )


            0
            Мы выбрали Lua для фильтров из-за ряда причин, основными из которых являются его быстродействие и простота. Пользователи очень быстро его осваивают, тем более он знаком аналитикам по информационной безопасности, работающими с IDS/IPS. Lua используется в Suricata и Zeek.
              0

              Lua в Suricata и в Zeek используют для кастом логики в детектировании, сами сигнатуры в IDS пишутся декларативными языками.
              Для выборки из списка событий в той же Suricata предлагают использовать JSONquery Так что аналогия не вполне уместна)


              На мой взгляд, требовать от какого-нибудь аналитика 1-ой линии в SOC знание Lua, чтобы он мог отфильтровать и отсортировать события например за неделю, как-то чересчур. Но, как говорится, на вкус и цвет. )


              Насчёт быстродействия — да (LuaJIT один из лидеров впрочем как и PyPy), но это если сравнивать именно с другими скриптовыми языками. Разумеется SQL-like запросы компилируются, а их выдача — кэшируется. Так что сомневаюсь что Lua тут выиграет и по перформансу, но тут ответ зависит конечно от того как вы с Postgre работаете.


              А правила корреляции событий в SIEM тоже на Lua?

                0
                Язык описания правил корреляции у нас собственной разработки. Он сильно привязан к данным результатов фильтрации. Основная концепция — формирование списка утверждений, в случае выполнения которых должен генерироваться инцидент.
                Имеется возможность использования переменных, ожидания данных по определенному фильтру, задавать временные окна, проверять на отсутствие данные по фильтру и т.п. По написанию правил корреляции мы подготовим отдельную статью.
            0
            Читаю у вас в посте о новой версии, Комрад 4:
            В ходе нагрузочного тестирования на сервере чуть выше начального уровня с процессором Хeon E5-2650 v2 2.60GHz (10 ядер) и 32 Гб ОЗУ была получена скорость обработки событий порядка 5500 EPS (запись событий и индексов).


            Подождите-подождите, но ведь ещё в предыдущих версиях вашего продукта, Комрад 2 и Комрад 3 (судя по Tadviser ещё 2016 году) вы доблестно отрапортовали не о 5500 EPS, а в 2 раза больше, о целых 10 000 EPS на абсолютно такой же (сюрприз-сюрприз!) серверной конфигурации:

            Текст Комрад 2 у tadviser:

            производительность: до 20 000 EPS. 10 000 EPS на серверной платформе со следующими характеристиками: 2 CPU Intel Xeon E5 2650, ОЗУ: 32 Гб, HDD: 2 Тб.


            Те же 10 000 EPS указаны в магазине Softline, где продают Комрад 3:

            производительность: до 20 000 EPS. 10 000 EPS на серверной платформе со следующими характеристиками: 2 CPU Intel Xeon E5 2650, ОЗУ: 32 Гб, HDD: 2 Тб.;


            Какие должны напрашиваться выводы у читателя?
            У вас последние 5 лет используется один и тот же сервер для тестирования?
            Продукт стал глючнее и тормознее в последней версии? EPS разворовываются и уводятся в офшоры? ))

            Не знаю, буду рада услышать вашу точку зрения))
              0
              Проведение нагрузочных тестов у нас полностью еще не закончилось и в скором времени мы опубликуем результаты и раскроем методику тестирования. Цифры приятно удивят) Наберитесь терпения!
                0
                С нетерпением буду ждать!) Отечественная SIEM стабильная и производительная нужна всем.

            Only users with full accounts can post comments. Log in, please.