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.

ℹ️ 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

Grabacion.2024-06-11.123352.mp4

Update 08/07

Grabacion.2024-06-11.123352.mp4

[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: