WIP - Initial MITRE v19 Support

[eric-forte-elastic]

Pull Request

Issue link(s):

Resolves #6366

Related to #6035

Summary - What I changed

Adds a dev command to generate a first pass at v19 mappings, and adds general support for v19 mappings in rule toml files. Also allows one to specify which framework version to use for outputting rules. Adds scaffolding to support other mapping frameworks in the future.

For much more context see issue: #6366

How To Test

Step 1: write the v19 block into the rule TOML

dev attack convert-threat-mappings reads the rule's existing v18 threat field, remaps it
through attack_v18_to_v19.yaml, and writes a [[rule.threat_mappings]] block (version = "19")
back into the TOML. Any IDs not present in the config are dropped and reported.

# single rule by ID
python -m detection_rules dev attack convert-threat-mappings \
  -t 19 \
  -id <rule-uuid>

# single rule by file
python -m detection_rules dev attack convert-threat-mappings \
  -t 19 \
  -f rules/linux/command_and_control_cat_network_activity.toml

# preview without writing
python -m detection_rules dev attack convert-threat-mappings \
  -t 19 \
  -f rules/linux/command_and_control_cat_network_activity.toml \
  --dry-run

Step 2: export with v19 as the output threat

export-rules-from-repo has no --threat-version flag. Version selection is controlled by the
DR_THREAT_MAPPING_VERSION environment variable (or threat_mapping_version in _config.yaml).
Pass it inline to select v19 for a single export:

# export a single rule with v19 threat mapping (by ID)
DR_THREAT_MAPPING_VERSION=19 python -m detection_rules export-rules-from-repo \
  -id <rule-uuid> \
  -o rule_v19.ndjson

# export by file
DR_THREAT_MAPPING_VERSION=19 python -m detection_rules export-rules-from-repo \
  -f rules/linux/command_and_control_cat_network_activity.toml \
  -o rule_v19.ndjson

The build selects the v19 threat_mappings block and emits it as threat; threat_mappings is
always stripped from the exported artifact. Rules that have no v19 block fall back to their v18
threat with a warning logged.

Setting v19 as the persistent default

To avoid passing the env var on every command, set it in
detection_rules/etc/_config.yaml:

threat_mapping_version: "19"

All commands (including export-rules-from-repo) will use v19 until the value is reverted.
The env var DR_THREAT_MAPPING_VERSION takes precedence over the config file if both are set.

Should be able to select which mapping to use which would result in rendering like this (left v18 right v19):

Checklist

• Added a label for the type of pr: bug, enhancement, schema, maintenance, Rule: New, Rule: Deprecation, Rule: Tuning, Hunt: New, or Hunt: Tuning so guidelines can be generated
• Added the meta:rapid-merge label if planning to merge within 24 hours
• Secret and sensitive material has been managed correctly
• Automated testing was updated or added to match the most common scenarios
• Documentation and comments were added for features that require explanation

Contributor checklist

• Have you signed the contributor license agreement?
• Have you followed the contributor guidelines?

[github-actions]

Enhancement - Guidelines

These guidelines serve as a reminder set of considerations when addressing adding a feature to the code.

Documentation and Context

• Describe the feature enhancement in detail (alternative solutions, description of the solution, etc.) if not already documented in an issue.
• Include additional context or screenshots.
• Ensure the enhancement includes necessary updates to the documentation and versioning.

Code Standards and Practices

• Code follows established design patterns within the repo and avoids duplication.
• Ensure that the code is modular and reusable where applicable.

Testing

• New unit tests have been added to cover the enhancement.
• Existing unit tests have been updated to reflect the changes.
• Provide evidence of testing and validating the enhancement (e.g., test logs, screenshots).
• Validate that any rules affected by the enhancement are correctly updated.
• Ensure that performance is not negatively impacted by the changes.
• Verify that any release artifacts are properly generated and tested.
• Conducted system testing, including fleet, import, and create APIs (e.g., run make test-cli, make test-remote-cli, make test-hunting-cli)

Additional Checks

• Verify that the enhancement works across all relevant environments (e.g., different OS versions).
• Confirm that the proper version label is applied to the PR patch, minor, major.