POC engine UX - security policy management

[asteriscos]

Description

We have to create a new proof of concept plugin that allows the user to manage the new engine.

The engine has the following object types:

• policies (a list of integrations)
• decoders
• rules
• outputs
• filters
• integrations ( a set of decoders, rules, filters, and outputs)
• kvdbs

Related to the security policy management the engine defines:

• routes
• endpoint to test events against a policy

These concepts are defined in the engine user manual

Based on this, we need to propose a UI to manage these concepts.

We need to provide an intuitive interface for the engine configuration changes, allowing users to easily adjust settings. It should list the engine configuration and provide a form to edit each setting, ideally using different controls for different configuration data types, validanting the user input.

Also, we need to provide a way to manage KVDBs which is the replacement of the current CDBs. The main difference is that KVDBs are dynamic and can be updated while the policy is running. KVDBs will not be stored in the indexer, so these operations should assume it will be accessed using the API.

References

• Create plugin: https://opensearch.org/blog/dashboards-plugins-intro/
• Index mocked data: https://www.elastic.co/guide/en/elasticsearch/reference/7.10/docs-index_.html
• Vega examples: https://vega.github.io/vega/examples/
• Vega docs: https://opensearch.org/docs/latest/dashboards/visualize/vega/
• Vega (Kibana 7.10): https://www.elastic.co/guide/en/kibana/7.10/vega-reference.html

Plan

• [ ] Create a new plugin with a basic layout to have a draft of how it would look with simple interactions
• [ ] Create mocked data in indexes with basic fields
• [ ] The mocked data should be WCS (Wazuh Common Schema) compliant
• [ ] Analyse the possibility of using a Vega visualisation to display rules relationships
• [ ] Mock API endpoints to be able to have a minimum interaction with the UI

[Desvelao]

Plugin

A plugin with ID wazuhEngine was created in the plugins/wazuh-engine.

This plugin defines and exposes the UI components to manage the Engine.

The plugin does not register any application as we would want, because this would need some services that are defined on the main plugin, so the render of the view of Engine application is rendered by the main plugin to simplify the POC. But this should be done as desirable in the final implementation.

So, a new app is registered on the side menu called Engine:

Accessing to the Engine app displays a layout based on the side menu and body. The side menu has access to the different entities of the engine: decoders, rules, filters, outputs, integrations, policies and KVDBs.

Clicking on the menu items changing the view to manage that entity of the engine with the CRUD actions: TODO

[Desvelao]

Reserved

[Desvelao]

Research - Rule relationship visualization

I was exploring the idea to represent the rule relationships through a Vega visualization.

I don't know what is the final document schema of a rule definition, but I defined a simple schema to test the representation of rule relationship storing in the rules data:

• id: rule ID
• parent: parent ID

Reviewing the chart types, I decided to test with the Tree layout.

:information_source: From my tests, the Tree layout chart needs only one root of the data to build the tree. It could not get to work with multiple tree roots. So this could mean one restriction depending on the use case.

Following this approach I store some data on an index on Wazuh indexer

I created an index where I store some mocked documents related to rules. ``` PUT /wazuh-rules { "settings": { "number_of_shards": 1, "number_of_replicas": 0 }, "mappings": { "properties": { "id": { "type": "keyword" }, "parent": { "type": "keyword" } } } } ``` Then I indexed some documents: ``` POST /wazuh-rules/_doc { "id": "1" } POST /wazuh-rules/_doc { "id": "2", "parent": "1" } POST /wazuh-rules/_doc { "id": "3", "parent": "1" } POST /wazuh-rules/_doc { "id": "4" } ```

With the data rule on the Wazuh indexer, I created a visualization of Vega type.

Notes:

• The visualization has hard-coded the values of the index to search and the id or parent document to get.
• The data is retrieved using a query and use the hits. It is possible to use aggregations, but it could not make sense for the use case.
• The visualization has defined some controls to modify the behavior and representation. These were inherited from the example visualization of Tree Layout example. We could remove them.
• The visualization only displays a node and its children on the first level. Using a less-restricted query could display more depth, but depending on the data could cause the tree has multiples nodes and this gives an error.

Vega visualization definition

``` { $schema: https://vega.github.io/schema/vega/v5.json description: An example of Cartesian layouts for a node-link diagram of hierarchical data. padding: 5 signals: [ { name: labels value: true bind: { input: checkbox } } { name: layout value: tidy bind: { input: radio options: [ tidy cluster ] } } { name: links value: diagonal bind: { input: select options: [ line curve diagonal orthogonal ] } } { name: separation value: false bind: { input: checkbox } } ] data: [ { name: tree url: { /* An object instead of a string for the "url" param is treated as an OpenSearch query. Anything inside this object is not part of the Vega language, but only understood by OpenSearch Dashboards and OpenSearch server. This query counts the number of documents per time interval, assuming you have a @timestamp field in your data. OpenSearch Dashboards has a special handling for the fields surrounded by "%". They are processed before the the query is sent to OpenSearch. This way the query becomes context aware, and can use the time range and the dashboard filters. */ // Apply dashboard context filters when set // %context%: true // Filter the time picker (upper right corner) with this field // %timefield%: @timestamp /* See .search() documentation for : https://opensearch.org/docs/latest/clients/javascript/ */ // Which index to search index: wazuh-rules // If "data_source.enabled: true", optionally set the data source name to query from (omit field if querying from local cluster) // data_source_name: Example US Cluster // Aggregate data by the time field into time buckets, counting the number of documents in each bucket. body: { query: { bool: { should: [ { match_phrase: { id: 1 } } { match_phrase: { parent: 1 } } ] minimum_should_match: 1 } } /* query: { match_all: { } } */ size: 1000 } } /* } For our graph, we only need the list of bucket values. Use the format.property to discard everything else. */ format: { property: hits.hits } transform: [ { type: stratify key: _source.id parentKey: _source.parent } { type: tree method: { signal: layout } size: [ { signal: height } { signal: width - 100 } ] separation: { signal: separation } as: [ y x depth children ] } ] } { name: links source: tree transform: [ { type: treelinks } { type: linkpath orient: horizontal shape: { signal: links } } ] } ] scales: [ { name: color type: linear range: { scheme: magma } domain: { data: tree field: depth } zero: true } ] marks: [ { type: path from: { data: links } encode: { update: { path: { field: path } stroke: { value: "#ccc" } } } } { type: symbol from: { data: tree } encode: { enter: { size: { value: 100 } stroke: { value: "#fff" } } update: { x: { field: x } y: { field: y } fill: { scale: color field: depth } } } } { type: text from: { data: tree } encode: { enter: { text: { field: _source.id } fontSize: { value: 15 } baseline: { value: middle } } update: { x: { field: x } y: { field: y } dx: { signal: datum.children ? -7 : 7 } align: { signal: datum.children ? 'right' : 'left' } opacity: { signal: labels ? 1 : 0 } } } } ] } ```

Then, I got the visualization definition and used the same mechanism to render a dashboard used on the main plugin, and I got the visualization:

[JuanGarriuz]

Mocked API response and flyout added

https://github.com/wazuh/wazuh-dashboard/assets/124377319/f1d1352d-5df2-4d30-a9cc-a483c98ae471

Update 08/07

https://github.com/wazuh/wazuh-dashboard/assets/124377319/dcc9786b-9743-4d12-8c5a-165224198637

[Desvelao]

POC - Rules

This section has the following capabilities:

• List rules

• Bulk actions

• Rule details:

Cotain information about the rules (table and JSON), its relation with other rules and related events.

• Table
  • JSON
  • File
  • Relationship with other rules
  • Events

• Create rule

It allows the creation of a rule using a visual editor or (through a form) or a file editor. All views allow importing from file.

• Import from file

updates

- 2024/07/24 - add ability to remove field form arrayOf form field - Create component to select the configuration method - Replace the creator with configuration method switch - Create paths for editors or rules and outputs - Enhance spec of rule and outputs - Enhance render of arrayOf form fields on form editor - 2024/08/09 - update screenshots

[JuanGarriuz]

Update KVDB 10/07

• Added a new custom button to render flyout.

• Added custom action buttons and functionality with API

• Added Routing with react

Work on

• Implement logic of creating a new KVDB list and its respective keys

ToDo

• [ ] Refactor flyout
• [ ] Add table buttons funcionality

[JuanGarriuz]

Update 15/07

ToDo

• [ ] Upgrade flyout styles
• [ ] Add a sample data script
• [ ] Add functional actions buttons

[JuanGarriuz]

Update 02/08

Decoders

Forms

[JuanGarriuz]

Update 07/08

Policies

Decoders

[Desvelao]

POC - Outputs

• List

• Bulk actions

• Details

  • Table

  • JSON

• File

• Relationship TODO

• Events

• Create Form: TBD File: