Skip to main content

​
How do I configure system elements for my TARA project?

System elements represent the components being analyzed for cybersecurity threats. Each systemElement work item has an elementType field with a 5-level hierarchy: system, subsystem, assembly, subassembly, and component. Start by creating a top-level system element, then decompose it into subsystems and components that map to your actual architecture. Components are typically the leaf nodes linked to cybersecurity goals and TARA records. See Create System Elements for the full setup procedure.

​
What are the Stakeholder and Threat Scenario catalogs?

The TARA Risksheet uses two shared catalogs stored as Polarion documents:
  • Risks/StakeholderCatalog — Contains pre-defined stakeholder work items (e.g., Vehicle Owner, Backend Server, Road Authority) that can be reused across multiple TARA modules.
  • Risks/ThreatScenarioCatalog — Contains pre-defined threat scenario work items that provide consistent threat naming and can be linked to multiple TARA records.
When you click a Stakeholder or Threat Scenario cell in the Risksheet, a picker appears showing only items from the corresponding catalog. This catalog-driven approach ensures consistency and reuse across analyses. See Use Shared Threat Scenario and Stakeholder Catalogs for more details.

​
What formulas are configured in the Risksheet?

The TARA Risksheet includes three JavaScript formulas:
  1. feasibilityFormula — Sums five attack factor scores (attackTime, attackExpertise, attackKnowledge, attackWoo, attackEquipment) and maps the total to a feasibility level (high, medium, low, veryLow).
  2. verdictFormula — Computes a risk verdict integer (1—5) from a 4x4 matrix of taraImpact and taraFeasibility values.
  3. description formula — Auto-generates a structured summary for each TARA record in the format: STAKEHOLDER: [title] / DAMAGE: [scenario] / THREAT: [scenario] / PATH: [path].
All formula-driven fields (taraFeasibility, taraVerdict, description) are read-only to prevent manual override. See Risksheet Formulas Reference for the complete formula documentation.

​
How do query factories control the item pickers?

The Risksheet uses three queryFactories to restrict what appears in link picker dialogs:
  • stakeholderQuery — Filters to type:stakeholder items from the StakeholderCatalog document
  • threatScenarioQuery — Filters to type:threatScenario items from the ThreatScenarioCatalog document
  • cybersecurityGoalQuery — Filters to type:cybersecurityGoal items (not restricted to a specific document)
These factories prevent users from accidentally linking the wrong work item type to a TARA record. Cybersecurity goals, unlike stakeholders and threat scenarios, can be sourced from any module in the project.
Query factories are a critical data integrity mechanism. If you customize the Risksheet configuration, always verify that queryFactory definitions match the intended work item types and source documents.

​
Can I edit the CAL value directly in the Risksheet?

Yes. The goalCal column uses a cross-item binding (cybersecurityGoal.cal) that reads and writes the CAL field on the linked cybersecurityGoal work item. The calDecorator validates whether the CAL meets the minimum required by the verdict score (verdict 5 requires CAL 4, verdict 4 requires CAL 3, verdict 3 requires CAL 2, verdicts 1—2 require CAL 1). A red warning badge displays “min CAL N” when the assigned CAL is too low. See Cybersecurity Assurance Levels (CAL) for definitions.

​
What are the Risksheet cell decorators?

Cell decorators provide visual feedback through color-coding and validation warnings:
  • feasibilityDecorator — Colors feasibility cells green (veryLow/low), amber (medium), or red (high)
  • impactDecorator — Colors impact cells from light green (negligible) through light red (severe)
  • verdictDecorator — Applies a 5-point color gradient from green (verdict 1) to red (verdict 5)
  • rowHeaderVerdict — Colors the row header based on verdict, providing row-level risk indication even when the Verdict column is hidden
  • goalHighlight — Shows “Goal required” warning when treatment is reducing/avoiding but no goal is linked
  • claimHighlight — Shows “Claim required” warning when treatment is retaining/sharing but no claim text exists
  • calDecorator — Color-codes CAL 1—4 and shows a mismatch warning when CAL is below the verdict-required minimum
See Risksheet Configuration Reference for the full decorator specification.

​
How do I create custom Risksheet views?

The TARA solution ships with seven pre-configured views (five workflow views, Overview, and Full View). Each view is defined in the risksheet configuration YAML by listing which columns to display. The Full View uses the @all wildcard to show every column, which is useful for export or complete audit review. To customize views, modify the sheet configuration YAML in .polarion/nextedy/sheet-configurations/. See Configure Risksheet Views for TARA for guidance on adding or modifying views.
All Risksheet configuration lives in the .polarion/nextedy/sheet-configurations/ directory of your Polarion project. Changes to this YAML file affect column definitions, views, formulas, and decorators. Always test changes in a sandbox project before applying to production TARA analyses.