Add monitoringAndDetection[] for MDR / detection engineering use cases

[JohnASRG]

Motivation

methodology/UseCases.md lists UC_006 (MDR/log ingestion), UC_007 (detection engineering), and UC_008 (behavioral analytics) as V1.0 use cases, but no schema objects connect a threat scenario to the telemetry, detection logic, and operational status that the SOC actually consumes. R155 also expects post-production monitoring evidence. Without this, RDX cannot drive a detection-engineering pipeline from TARA output.

Proposed change

Add a top-level monitoringAndDetection[]:

{
  "id": "DET-001",
  "title": "Detect repeated failed remote command authentication",
  "relatedThreatScenarioIds": ["TS-REMOTE-COMMAND"],
  "relatedAttackPathIds": ["AP-001"],
  "requiredTelemetry": ["auth.failure.count", "source.ip", "vehicle.id"],
  "detectionLogicRef": "sigma:...",
  "detectionLogicFormat": "sigma" | "yara" | "ocsf-query" | "splunk-spl" | "kql" | "custom",
  "platforms": ["vehicle-soc", "cloud-soc", "ecu-local"],
  "status": "proposed" | "deployed" | "tuning" | "retired",
  "lastValidatedAt": "...",
  "owner": "..."
}

Add relationship types detects (DET → threatScenario/attackPath) and mitigatedBy for the AFR/risk re-evaluation loop. Update methodology to describe how an MDR consumer ingests RDX → detection ruleset.

References

• methodology/UseCases.md UC_006/UC_007/UC_008
• AI peer review, section "Recommended backlog → monitoringAndDetection[]"
• Sigma: https://github.com/SigmaHQ/sigma ; OCSF: https://github.com/ocsf

Acceptance criteria

• monitoringAndDetection[] added to JSON Schema + XSD
• Example examples/rdx-detection-engineering-example.json validates and links a Sigma rule to a threat scenario
• relationships enum extended with detects
• methodology/UseCases.md updated with the ingestion flow

---

Surfaced by external AI peer review; see chat transcript for full review text.