feat: permission improvements, correlation alerts, and audit logging

[TerrifiedBug]

Summary

• Permission granularity: Separate manage_index_config from manage_settings for better access control
• Correlation alert improvements: Add MITRE tags extraction from linked rules, consolidate UI
• Audit logging: Add comprehensive audit trails for alert comments and ownership
• CodeQL optimization: Exclude alembic migrations to reduce false positives

Changes

Permissions

• Add manage_index_config permission for index pattern management
• Update frontend route guards and navigation menu permissions
• Restrict Health page to manage_settings, Field Mappings to manage_index_config

Correlation Alerts

• Extract MITRE ATT&CK tags from linked sigma rules' YAML content
• Add links to source sigma rules and alerts in correlation alert details
• Consolidate correlation rule link into the Correlation Alert Details box
• Hide separate "Rule" card for correlation alerts (redundant)

Audit Logging

• alert.comment_add - Track comment additions
• alert.comment_edit - Track comment edits
• alert.comment_delete - Track comment deletions
• alert.assign - Track alert ownership assignments
• alert.unassign - Track alert ownership releases

Bug Fixes

• Fix "Assigned to me" pagination returning only 25 alerts (now fetches up to 1000)
• Fix correlation alert entity_field and tags not populated (requires new alerts)

CodeQL

• Exclude backend/alembic/versions/** from analysis (reduces FP noise)

Test plan

• Verify permission separation works (index config vs settings)
• Create new correlation alert and verify tags appear
• Add/edit/delete comment on alert, check audit log
• Assign/unassign alert, check audit log
• Verify "Assigned to me" shows all assigned alerts

In general, empty except blocks should be replaced with handlers that either (1) perform some recovery/compensation, (2) re-raise or wrap the exception, or at minimum (3) log the exception with enough context to diagnose issues later. When failure should not abort the operation (as here, where tags are additive metadata), the best fix is to log the error and continue.

For this specific block, the ideal minimal-impact fix is:

• Keep the try/except structure and continue to swallow the error so alert creation is never blocked by a bad rule’s YAML.
• Replace pass with a log statement that records:
  • Which rule failed (rule_a_id / rule_b_id).
  • That tags could not be loaded from YAML.
  • The exception object.
• Use the existing logger already defined a few lines above in the if triggered_correlations: block, so no new imports or global loggers are required.
• Apply the same change consistently to both the rule_a_id and rule_b_id except blocks.

Concretely, within backend/app/api/logs.py, in the shown region:

• For the except (ValueError, yaml.YAMLError, Exception): at line 417, replace pass with a logger.warning(...) call mentioning rule_a_id and including exc_info=True so stack traces are available if needed.
• For the analogous except at line 431, replace pass with a similar logger.warning(...) mentioning rule_b_id.

No new imports or helper methods are required; the logging import and logger variable are already in scope in this part of the function.

General fix: empty except blocks should either (a) handle the error (e.g., log it, adjust control flow, or provide a fallback) or (b) be documented with a clear comment why ignoring is safe. Here, the appropriate fix is to treat YAML/DB issues as non-fatal but log them so operators can debug malformed rules.

Best minimal fix: keep the same behavior (alert creation continues even if tag parsing fails) but add logging in the except blocks for both rule_a and rule_b. The logging should include the rule ID and the exception details. We will not re‑raise; we’ll just record the problem. This matches the later pattern where WebSocket broadcast failures are logged but do not stop processing.

Concretely:

• In backend/app/api/logs.py, within the shown code region:
  • Replace the except (ValueError, yaml.YAMLError, Exception): pass for rule_a with an except Exception as e: (or keep the tuple if desired) that logs a warning or error, then continues.
  • Apply the same change to the rule_b block at line 431.
• To do this we need a logger available in this module. The snippet already shows logger.error(...) later, so a logger is presumably defined earlier in the file; we will rely on that existing definition and just call logger.warning(...) in the new code.

This adds observability without altering functional behavior: alerts are still created; tags enrichment remains best-effort, but failures are now visible.