Security Analytics UI - Normalization module

[asteriscos]

Description

We need to add a new Normalization module to the Security Analytics plugins, where the user will be able to manage:

• Normalization
  • Decoders
  • KVDBs
  • Testing
    • Promotion

All new views must reuse Security analytics layouts and components as much as possible:

• Tables, filters, pagination, detail drawers.
• Breadcrumbs and navigation.

Must not disrupt existing:

• Findings.
• Alerts.
• Detectors.
  • Detection Rules.
• Correlations.
  • Correlation Rules.

Functional Requirements

1. Global UX and space handling

   1.1. Under the Security analytics main menu, the Dashboard must include:

   • A new Normalization entry.

   1.2. Normalization views must expose a consistent space selector:

   • Wazuh space.
   • Custom space.
   • Test space.

   1.3. The current space selection must:

   • Control which assets are listed.
   • Control which actions are available:
     • Wazuh space: read-only.
     • Custom space: read-only (modified only via promotion).
     • Test space: full CRUD and duplication capabilities.

   1.4. The interface must visually indicate:

   • The current space at the top of each view.
   • The space each asset belongs to (badges, labels, colors).
   • Whether an asset is vendor (Wazuh) or user-defined.

   1.5. Space selection must remain consistent:

   • Same UI component and position across views.
   • Persist user choice per section when possible.

2. Normalization – Overview

   2.1. The Normalization overview must summarize normalization assets across spaces, showing:

   • Number of integrations using normalization assets.
   • Number of decoders.
   • Number of KVDBs.

   2.2. Include a “Test vs Custom differences” widget showing:

   • New assets in Test.
   • Modified assets in Test compared to Custom.
   • Assets marked for deletion in Test.

   2.3. Provide quick navigation to:

   • Decoders (space selector pre-applied).
   • KVDBs (space selector pre-applied).
   • Log test (defaulting to Test space).
   • Promotion flow (when Test and Custom differ).
   • Reload Test space (to validate all draft and saved assets).

   2.4. Include brief explanatory text/tooltips:

   • Wazuh space: vendor-managed, immutable.
   • Custom space: user production content.
   • Test space: editable sandbox.

3. Normalization – Decoders

   3.1. Use existing Security analytics table components and list decoders for the active space using Wazuh manager content APIs.

   3.2. Table columns must include:

   • Decoder name/ID.
   • Integration.
   • Category (inherited, read-only).
   • Relationship indicator (parent/child/sibling).
   • Space (Wazuh / Custom / Test).
   • Source (vendor / user).
   • Last modified.

   3.3. Filters must include:

   • Integration.
   • Category.
   • Space.
   • Source.
   • Text search (by name/ID).

   3.4. Actions per space:

   • Wazuh space:

     • View details (read-only).
     • Duplicate to Test space, choosing:
       • Full branch (parents and siblings).
       • Only siblings.
       • Only parents/ancestor chain.

   • Custom space:

     • View details (read-only).
     • Duplicate to Test space (same branch options).

   • Test space:

     • View, create, edit, delete decoders.
     • Duplicate branches within Test space for experimentation.

   3.5. Detail view:

   • Tabs: Details, Structure/Hierarchy, YAML/JSON, References.
   • Show space, source, integration, and inherited category.
   • Include category in a metadata subsection linking to the underlying WCS index (e.g., Network → wazuh-wcs-network-).
   • Provide an “Edit in Test space” action when viewing Wazuh or Custom assets (auto-duplicates if needed).

   3.6. CRUD and duplication:

   • Operate only in Test space.
   • Use manager APIs with correct relationship semantics.
   • Preserve hierarchy order when duplicating.
   • Update UI after each operation without full reload.

4. Normalization – KVDBs

   4.1. Use the same layout and interaction model as Decoders.

   4.2. Table columns:

   • KVDB name/ID.
   • Integration.
   • Category (inherited, read-only).
   • Space.
   • Source.
   • Approximate entries/size.
   • Last modified.

   4.3. Filters:

   • Integration.
   • Category.
   • Space.
   • Source.
   • Text search.

   4.4. Actions per space:

   • Wazuh space:

     • View details (read-only).
     • Duplicate KVDB to Test space.

   • Custom space:

     • View details (read-only).
     • Duplicate KVDB to Test space.

   • Test space:

     • View, create, edit, delete KVDBs.
     • Duplicate within Test space if needed.

   4.5. KVDB detail view:

   • Structured entry browser (paged).
   • YAML/JSON editor for Test space.
   • Display linked integration and inherited category with WCS index reference.
   • “Edit in Test space” button for Wazuh/Custom assets (duplicates to Test if needed).

5. Normalization – Log test

   5.1. Expose a unified log testing form:

   • Multi-line event text input.
   • Structured agent metadata (ID, name, IP, OS, etc.).
   • Space selector (default Test space).

   5.2. Submitting:

   • Calls existing Wazuh manager log test API.
   • Displays:
     • Applied decoders.
     • Matching integration.
     • Triggered rules.
     • KVDB enrichments.
     • Integration category and mapped WCS index.

   5.3. From results:

   • Open integration in Integrations view.
   • Open decoders or KVDBs involved, in the correct space.

   5.4. Clearly show when testing under Test space and that results do not affect live detections.

6. Test space reload and validation

   6.1. Provide a “Reload Test space” action in Normalization overview (and optionally in Log test view).

   6.2. Reloading must:

   • Use existing manager APIs to rebuild Test space from all saved/draft assets.
   • Validate schema and relationships across decoders, KVDBs, integrations.
   • Leave Wazuh and Custom spaces untouched.

   6.3. After reload:

   • Show status and version/timestamp if available.
   • Display validation errors with links to edit broken assets.

7. Promotion workflow (Test → Custom)

   7.1. Provide a guided promotion workflow available when Test and Custom differ.

   7.2. Entry points:

   • “Promote changes” button in Normalization overview.
   • Inline banner in Test space views when differences exist.

   7.3. Workflow must:

   • Group changes by asset type and integration.
   • Distinguish new, modified, and deleted assets.

   7.4. User can:

   • Select assets to promote.
   • Review summary of Custom space after promotion.

   7.5. Confirmation:

   • Calls manager promotion APIs.
   • Displays success with timestamp/version.
   • Refreshes Custom space view.

   7.6. Errors:

   • Identify failing assets.
   • Provide quick links to open and correct them in Test space.