EQL против ES|QL: когда использовать каждый язык в расследованиях безопасности

Что решает EQL

EQL особенно подходит для временных последовательностей. Rule может искать Process start, а затем Network event от того же process.entity_id. Можно связывать Events по общему полю с помощью by, определять Timestamp, Event category и Tiebreaker, и даже искать Missing events в определенных сценариях.

Преимущество в том, что логика отражает историю: шаг А произошел до шага Б. Вместо того чтобы суммировать два типа Events в одном окне и предполагать, что они связаны, EQL проверяет порядок и Key связи. Поэтому он полезен для Process chains, Authentication sequences, File, а затем Process, или Event, который ожидается, но не приходит.

sequence by process.entity_id
  [process where event.type == "start" and process.name == "lab-tool.exe"]
  [network where event.type == "connection" and network.direction == "egress"]

Пример использует вымышленное имя и лабораторные данные. Он ищет Process, а затем Network connection от того же Process. Он не доказывает вредоносность; необходимо проверить Destination, Signer, Parent, User и Host context.

Что решает ES|QL

ES|QL работает с таблицами и поддерживает Pipeline-обработку. Начинаем с FROM, фильтруем по WHERE, создаем поля в EVAL, суммируем с помощью STATS ... BY, сортируем и отображаем Columns. Detection типа ES|QL превращает каждую строку Result в Alert.

Он подходит, когда вопрос количественный или требует Transformation: сколько Hosts запустили определенный инструмент, какие Users создали аномальный объем, каково соотношение Success к Failure, или какое вычисляемое поле превышает Threshold. Это не естественный выбор, когда порядок Event A, а затем B является главным; Elastic рекомендует использовать EQL для упорядоченных последовательностей.

FROM logs-endpoint.events.*
| WHERE event.category == "process" AND event.type == "start"
| WHERE process.name == "lab-tool.exe"
| STATS executions = COUNT(*), hosts = COUNT_DISTINCT(host.id) BY user.name
| WHERE executions >= 5

Этот Query суммирует запуски по пользователю и фильтрует Users с пятью и более запусками. Он отвечает на вопрос, отличающийся от EQL: «Кто запустил инструмент сколько раз и на скольких Hosts?», а не «Создал ли определенный Process Connection после себя?»

Sequence против Pipeline

Тот же сценарий в двух подходах

Предположим, общий сценарий — это лабораторный инструмент под названием lab-tool.exe, который может работать в аномальном контексте. Сначала определим точный вопрос:

• Вопрос EQL: Был ли запущен определенный Instance инструмента, а затем установлено Network connection?
• Вопрос ES|QL: Какие пользователи или Hosts запускали инструмент с аномальной частотой?
• Вопрос Custom query: Был ли инструмент вообще запущен с неожиданным Parent?

Три вопроса могут поддерживать один и тот же Use Case, но не являются эквивалентными. EQL обеспечивает хронологическую связь. ES|QL предоставляет Baseline или Aggregation. Custom query обеспечивает прямое соответствие. Хорошая Detection architecture может использовать несколько Rules, но следует избегать дублирования и определять, что добавляет каждая Rule.

Требования к данным

EQL требует надежный Timestamp и Event category. Последовательности выигрывают от Tiebreaker, когда Events имеют одно и то же время. Поле связи должно быть стабильным: process.entity_id обычно предпочтительнее process.name, поскольку несколько Processes могут иметь одно и то же имя. Если entity_id отсутствует или изменяется между Sources, Sequence не будет работать, как ожидалось.

ES|QL требует, чтобы Indices были доступны, а поля соответствовали командам. Aggregation по полю типа text вместо keyword, значения Null или несогласованная Schema могут изменить Results. В Detection Rule необходимо учитывать Deduplication Alerts, Schedule и Lookback. Возможности и некоторые требования к Metadata меняются между версиями Elastic, поэтому необходимо проверять документацию к версии.

Преимущества и ограничения

Преимущества EQL

• Выражает порядок Event читабельным способом.
• Связывает шаги по общему Entity.
• Подходит для Process lineage и поведенческих последовательностей.
• Может выражать отсутствие ожидаемого Event в поддерживаемых сценариях.

Ограничения EQL

• Не является естественным инструментом для сложной Aggregation и Statistics.
• Сильно зависит от Timestamp, event.category и стабильного Key.
• Слишком широкая Sequence может быть дорогостоящей или шумной.

Преимущества ES|QL

• Четкий Pipeline для фильтрации, вычисления и Aggregation.
• Создание производных полей с помощью EVAL.
• STATS ... BY позволяет Detection по агрегированным значениям.
• Подходит для Hunting и табличных отчетов.

Ограничения ES|QL

• Не заменяет EQL, когда порядок Events является основным требованием.
• Каждая Row превращается в Alert, поэтому Grain результата должен быть спланирован.
• Aggregation может потерять Raw event context, если Investigation Guide не предоставляет Drill-down.

Матрица выбора

Лабораторное упражнение

1. Создайте пять вымышленных Process events и два Network events с process.entity_id.
2. Напишите EQL, который возвращает Sequence только тогда, когда Network происходит после Process для той же сущности.
3. Напишите ES|QL, который суммирует количество запусков по user.name и host.id.
4. Измените Timestamp одного Event и проверьте, что происходит с последовательностью.
5. Удалите process.entity_id из события и проверьте, как качество данных влияет.
6. Напишите для каждого Query предложение: что он доказывает, что не доказывает и какой Drill-down требуется.

Частые ошибки

• Использование ES|QL для имитации сложной Sequence, когда EQL подходит лучше.
• Использование EQL для вопроса, который является простым Count.
• Связывание по process.name вместо стабильного Entity.
• Игнорирование Time zone, Ingestion delay и Tiebreaker.
• Превращение Aggregation в строку Alert без полей, позволяющих проводить расследование.
• Копирование Query из другой версии без проверки Syntax и требований к Metadata.

Резюме и CTA

Прежде чем писать Query, напишите вопрос на листе бумаги: Ищу ли я Event, Sequence, Count, Transformation, IOC или Anomaly? Выбор языка почти всегда следует из ответа. В упражнениях HPI рекомендуется использовать одну и ту же Telemetry и запускать на ней EQL и ES|QL, чтобы увидеть, как модель вопроса меняет результат расследования.

Вопросы и ответы