Единая платформа безопасности
Helxis HEDE собирает все модули безопасности на одной платформе: от защиты до запуска файла и обнаружения-реагирования на конечной точке до сбора событий всей инфраструктуры, корреляции, расширенного обнаружения и защиты данных. Одна модель данных, одна консоль, один поток инцидентов — увиденное на конечной точке связывается здесь с увиденным в контуре.
Защита конечных точек, EDR, XDR, DLP и SIEM — это не пять продуктов, конкурирующих за один бюджет. Каждое название говорит о том, где стоит защита и на какой вопрос она отвечает. Читать их как альтернативы — кратчайший способ дважды заплатить за одну возможность и оставить другую незакрытой.
Защита конечных точек — это пара, которая живёт на самой машине. EPP решает, разрешено ли файлу запускаться: вердикт выносится ДО старта процесса, поэтому остановленная здесь атака не оставляет ущерба, который пришлось бы расследовать. EDR исходит из того, что что-то уже запустилось, и хранит запись, способную ответить, что именно оно сделало: какой процесс запустил какой, что записал, куда подключился.
| Дисциплина | За чем наблюдает | На какой вопрос отвечает |
|---|---|---|
| EPP — защита конечной точки | За файлом, до его запуска | Можно ли разрешить этому файлу запуститься? |
| EDR — обнаружение и реагирование | За процессами, памятью и соединениями на машине | Что произошло на этом хосте и кто это начал? |
| SIEM — управление событиями | За журналами всех источников инфраструктуры | Что видел весь контур? |
| XDR — расширенное обнаружение | За сигналами конечных точек, учётных записей и сети вместе | Это одна атака или отдельные события? |
| DLP — предотвращение утечек данных | За перемещением конфиденциальных данных | Куда уходят эти данные и должны ли уходить? |
HEDE — это Helxis Endpoint Defense Engine. Все пять модулей — части одной платформы: одна модель данных, один поток инцидентов, одна консоль, поэтому процесс на конечной точке и аутентификация в контуре сходятся на одном экране. Модули включаются в зависимости от инсталляции: заказчик начинает с нужного и добавляет остальное в ту же консоль — без новой системы и без второй панели.
Каждое средство защиты видит только своё событие: антивирус — про файл, firewall — про соединение, WAF — про запрос. Ни одно не знает, что увидело другое. А атака проходит ровно между ними.
Платформа не заменяет их — она строит над ними единый слой наблюдения, обнаружения и учёта. Один запрос работает по всем источникам, потому что события приведены к одной модели: поле с одним и тем же именем означает одно и то же независимо от вендора.
Поэтому поиск, правила корреляции, дашборды и отчёты не привязаны к типу источника. При появлении нового вендора правила не переписываются.
| Этап | Что выполняется |
|---|---|
| Приём | Проверка источника, буферизация на диск, контроль дубликатов и потерь |
| Обработка | Разбор, нормализация в единую модель, категоризация, обогащение контекстом |
| Детектирование | Корреляция, поведенческие профили, формирование оповещений |
| Предъявление | Инциденты, дашборды, отчёты и пересылка во внешние системы |
Событие перемещается между уровнями по возрасту, объёму уровня или доле занятого места. Сроки задаются отдельно для каждого класса источников; для событий, вошедших в инциденты, действует своя политика.
| Профиль | Hot | Warm | Cold-archive |
|---|---|---|---|
| Краткий · 30 суток | 7 суток | 23 суток | — |
| Базовый · 90 суток | 14 суток | 76 суток | по требованию политики |
| Расширенный · 180 суток | 30 суток | 150 суток | до 365 суток |
| Годовой · 365 суток | 30 суток | 180 суток | 185 суток |
| Длительный · 1825 суток | 30 суток | 180 суток | 1615 суток |
Профили приведены как примеры конфигурации. Типовой коэффициент сжатия на текстовых журналах — 6–12×.
Во всех четырёх вариантах функциональность одинакова — различаются способ поставки образов и механизм масштабирования.
| Вариант | Поставка | Масштабирование |
|---|---|---|
| Физическая среда | Пакеты RPM / DEB, ISO-образ | Добавление узлов и дисковых полок |
| Виртуализация | Образы OVA / QCOW2 / VHDX | Изменение ресурсов ВМ, клонирование |
| Частное и публичное облако | Образы ВМ, шаблоны IaC | Группы масштабирования, объектное хранилище |
| Контейнеры и гибрид | OCI-образы, Helm-чарты | Изменение числа реплик, StatefulSet |
Для инфраструктуры с несколькими площадками применяется схема «центральный узел — удалённые площадки»: на площадке Helix Collector принимает события локально, буферизует 1–72 ч и передаёт в центр по TLS 1.2/1.3.
Нет. EDR глубоко показывает, что произошло на одной машине, но видит только её. SIEM видит весь контур, но знает лишь то, что прислали источники. Атака обычно оставляет след в обоих: на конечной точке — процесс, в контуре — аутентификацию и соединение. Поэтому они и стоят в одной консоли рядом.
Антивирус в основном ищет сигнатуру файла, уже признанного вредоносным. Предзапусковый сканер HEDE читает структуру файла: какие сочетания вызовов запрашивает таблица импорта, энтропию секций, действительность подписи и набор правил YARA — и оставляет доказательство по каждому начисленному баллу. Поэтому он способен оценить образец, которого никто раньше не видел, и показать, почему оценил именно так.
Нет — и это сделано намеренно. Модуль конечной точки сам оценивает файл до запуска; остальные модули собирают события уже имеющихся у вас средств в одно место, связывают их и формируют инцидент. Средства продолжают делать свою работу, а платформа закрывает промежуток между ними.
В базовой поставке есть готовые правила разбора для 600+ типов источников. Для источника вне списка декодер описывается конфигурацией — код продукта не меняется и компоненты не пересобираются.
Нет. Агент применяется на конечных точках там, где он нужен; сетевое оборудование, средства защиты и облачные сервисы собираются безагентно — через Syslog, REST API, WMI, SNMP или API провайдера.
Исходная запись хранится без изменений, для каждой записи считается контрольная сумма, включаемая в цепочку хешей блока. Нарушение или удаление выявляется плановой фоновой проверкой; за период готовится отчёт о целостности.
Это зависит от объёма потока и срока хранения. Типовой коэффициент сжатия на текстовых журналах — 6–12×, а хранение разделено на три уровня: самый дорогой NVMe нужен только под hot. Точный расчёт даётся после замера вашего потока.
Определим, какие источники, какой объём и какой срок хранения нужны, — после этого дадим точное предложение по составу компонентов и объёму хранилища.
