[Vulnerabilities dashboard] Research about vulnerabilities dashboard context/scope

[Machi3mfl]

Description

Make a research about the vulnerability module domain and define the scope. Register the scope and the related domain about the new dashboard.

• Add all the necessary documentation to understand the vulnerability module and dashboard

Related to epic #5763

[Machi3mfl]

Current vulnerabilities module behavior

Right now, all the data retrieve to show in the vuls module become from wazuh api endpoints like:

• endpoint /vulnerability

The current behavior only supports the data from an agent, don't have the way to get global information and make general metrics.

Vulnerabilities Inventory

UI Components used

The inventory view use the following UI elements to show the module data:

Severity chart:

• Data from: /vulnerability/000/summary/severity endpoint
• Component: VisualizationBasicWidget donut chart

Details card:

• Data from: /vulnerability/000/summary/severity,/vulnerability/000/last_scan endpoints

• Component: Custom card

  Summary chart:

• Data from: /vulnerability/000/summary/ (can be filtered by vul property like "name", "cve", etc)

• Component: VisualizationBasicWidgetSelector

Vuls table:

• Data from: /vulnerability/000 endpoint
• Component: TableWzAPI

Note All the api calls are being requested by de wz-request file and apiReq method and is rendered by the VisualizationBasicWidget from /common/charts/visualizations/ implementation , customs cards and TableWzAPI component from wazuh-kibana-app/plugins/main/public/components/agents/vuls/inventory.tsx

wz-request

apiRequest method

This methods calls to the /api/request endpoint generated in the plugin server-side and works like a layer between the wazuh plugin and the wazuh api. The server side layer is implemented on /server/controllers/wazuh-api.ts

Workflow

sequenceDiagram;

Note left of UI (client-side): UI Component needs data to render!
UI (client-side)->>Plugin API (server-side): make a call to fetching data
Note left of Plugin API (server-side): the plugin server-side works like a middleware(layer) between plugin a wazuh api
Plugin API (server-side)->>Wazuh Server API: authorize call and make a request to the wazuh API
Wazuh Server API->>Plugin API (server-side): response with the data requested
Plugin API (server-side)--> UI (client-side): retrieve the information requtested

Disadvantages

• Strong coupling between UI and plugin server-side: If in the future we decide to change the data source. For instance: Change the source between wazuh api to a index. In the current solution we need to refactor all the implementation.
• Interfaces not defined: The non-definition of interfaces makes switching implementations more expensive. We cannot change the implementation without spending a lot of time in develop it

[Machi3mfl]

Next vulnerabilities dashboard scope

UI components

• Search bar and Filters
  • Data source: new vulnerabilities index
• Visualizations/Charts
  • OSD visualizations (OSD vis plugin)
  • Custom visualizations (by code)
• Metrics (statistics)
• Data table