Add reusable Attacker Capability Library (ACL) for TAF to standardize capability factors

[github-actions]

Motivation

TAF and AFR assessments rely on consistent attacker capability descriptions (resources, skills, time, equipment) to be comparable across assessments and between organizations. RDX currently supports tafAssessments but lacks a canonical, reusable attacker capability catalog. A shared Attacker Capability Library (ACL) enables: consistent TAF scoring, sharing of attacker capability definitions between OEMs and suppliers, and small-footprint references in tafAssessments rather than repeating freeform attacker descriptions.

Proposed change

1. Schema additions

• Add optional attackerCapabilities[] at riskSet level. Each capability entry SHOULD include:

  • id (string)
  • title (string)
  • description (string)
  • resourceProfile (object): { "timeHours": { "min": number, "median": number, "max": number }, "budgetUSD": { "min": number, "median": number, "max": number } } (optional)
  • skillSet[] (array of strings or enumerated values, e.g., ["exploitDev","socialEngineering","hardwareReverse"])
  • equipment[] (array strings, e.g., ["JTAG","Oscilloscope","customFirmwareTooling"])
  • accessModes[] (enum): subset of ["remote","adjacent","physical","insider"]
  • detectionRisk (enum): ["low","medium","high"] — ease of evading detection
  • confidence (string|number) — optional confidence metadata
  • references[] — external taxonomy links (e.g., ATT&CK PATTERN ids)

• Add attackerCapabilityRefs[] (array of capability ids) to tafAssessments and attackFeasibilityRatings. Allow each reference to include weight (0..1) to support blended capability profiles.

2. Library provisioning & reuse

• Provide a suggested baseline ACL in spec/attacker-capabilities/standard-acl.json with a small curated set (e.g., "opportunist", "skilled-criminal", "nation-state"), each with example numeric resource profiles to seed tooling.

3. Examples

• Add examples/rdx-taf-acl-example.json showing tafAssessments referencing attackerCapability ids and how factorRatings map to capability properties.

4. Backwards compatibility

• If no attackerCapabilities present, tafAssessments continue to support existing freeform targetContext.attackerProfile strings; the ACL is additive and optional.

5. New requirement ID: RDX-117 (new requirement): "Provide an optional attackerCapabilities library for standardized TAF capability descriptions and referencing from tafAssessments and AFRs." Update REQUIREMENTS.md.

References

• ISO/SAE PAS 8475 (TAF guidance) — informational listing. https://www.iso.org/standard/83187.html
• Supplier perspective on attacker capabilities and how AFR uses capability matrices (example academic/supplier analysis). [example paper] https://d-nb.info/1271425033/34
• ENISA automotive cyber guidance (for attacker taxonomy inspirations). https://www.enisa.europa.eu/

Acceptance criteria

• Schema: spec/json/rdx.schema.json and spec/xml/rdx.xsd accept attackerCapabilities[] and attackerCapabilityRefs[] and validate the new example.
• Example: examples/rdx-taf-acl-example.json demonstrates referencing standard ACL entries from tafAssessments and includes at least three capability examples (opportunist, organized-criminal, nation-state) with numeric resource profiles.
• Documentation: methodology/CAL-TAF-Integration.md updated explaining how to use ACL entries, weightings, and how to map capability properties to tafAssessments factorRatings.
• REQUIREMENTS.md: add RDX-117 and map to RDX-021 (Attack Feasibility Ratings) and RDX-024 (Impact Ratings) in the rationale.
• CI: validation of example passes in ./tools/validate.sh.

---

Generated by tools/ai_idea_scout.py via the AI Idea Scout workflow.
Review the proposal, refine the title/body/labels, and close if not desired.