elastic / cloudbeat

Analyzing Cloud Security Posture
Other
15 stars 43 forks source link

[POC] Using ES|QL as a general rule engine #1540

Closed oren-zohar closed 3 months ago

oren-zohar commented 1 year ago

Summary

Initially, we decided to separate the cloud resources collection and the rule engine for CSP. We planned to use Cloudbeat to collect the cloud resources and then send them to ES/Kibana. After that, we would use EQL as the rule engine to assess these resources and generate findings. However, we encountered some limitations while using EQL, which made us switch to using OPA on the agent side as the rule engine. With the recent introduction of ES|QL in version 8.11, we are hoping it will provide a suitable solution for a rule engine in Kibana.

As we have already implemented all the relevant cloud provider benchmarks in OPA, this POC is not about testing the feasibility of migrating them to ES|QL. Instead, we aim to determine if ES|QL rules platform could be utilized as a Custom Rules Platform for CSPM/KSPM.

To verify if ES|QL can provide this functionality, we plan to implement one of our already existing CIS benchmarks with it.

Definition of done

Out of scope

Resources

kfirpeled commented 1 year ago

From what I remember, we've decided not to use the current DE rules because a rule creates an alert. Which isn't a finding. It completely behaves differently.

In case we wish to a create a findings out of DE, the query language is less relevant. A findings is always being created, so that when the rule evaluates, and result of the finding is Failed and when it passes, it evaluates Passed.

Currently, there's no such logic in the DE for such rules. I'm not sure how ES|QL is relevant to this POC

oren-zohar commented 1 year ago

From what I remember, we've decided not to use the current DE rules because a rule creates an alert. Which isn't a finding. It completely behaves differently.

In case we wish to a create a findings out of DE, the query language is less relevant. A findings is always being created, so that when the rule evaluates, and result of the finding is Failed and when it passes, it evaluates Passed.

Currently, there's no such logic in the DE for such rules. I'm not sure how ES|QL is relevant to this POC

I think the new ENRICH command might be useful here:

The ES|QL ENRICH processing command combines, at query-time, data from one or more source indexes with field-value combinations found in Elasticsearch enrich indexes.

kfirpeled commented 9 months ago

This could be helpful to make queries on non-mapped json fields https://github.com/elastic/elasticsearch/issues/104934