Skip to main content

​
The Problem Catalogs Solve

A typical TARA project analyzes multiple system elements, each with its own TARA module. Many of the same threat scenarios and stakeholders appear across modules. Without centralization:
  • The same threat scenario would be described differently in each module
  • Renaming a stakeholder would require editing every TARA
  • Cross-module reporting would struggle to correlate identical threats
  • New analysts would create redundant, slightly different threat descriptions
The catalog pattern solves all of these by establishing a single source of truth for reusable TARA artifacts.

​
Catalog Architecture

diagram The TARA solution defines two shared catalogs:

​
Threat Scenario Catalog

  • Location: Risks/ThreatScenarioCatalog
  • Work item type: threatScenario
  • Contents: 15 named threat scenarios describing classes of attacks (e.g., remote code injection, sensor spoofing, communication eavesdropping)
  • Referenced via: The threatScenario column in the Risksheet, using the hasThreatScenario link role

​
Stakeholder Catalog

  • Location: Risks/StakeholderCatalog
  • Work item type: stakeholder
  • Contents: 4 stakeholders representing entities affected by cybersecurity threats (e.g., Vehicle Owner, Road Authority)
  • Referenced via: The stakeholder column in the Risksheet, using the hasStakeholder link role

​
How Catalogs Connect to the Risksheet

Catalog items are linked to TARA records through Risksheet itemLink columns. Each itemLink column has three key configuration properties:
PropertyStakeholder ColumnThreat Scenario Column
linkRolehasStakeholderhasThreatScenario
documentRisks/StakeholderCatalogRisks/ThreatScenarioCatalog
queryFactorystakeholderQuerythreatScenarioQuery
When an analyst clicks an itemLink cell in the Risksheet, a dropdown picker appears. The picker is populated by the queryFactory function, which runs a Lucene query (e.g., type:stakeholder) filtered to the specified catalog document. Selecting an item creates a Polarion work item link using the configured linkRole.
Threat scenarios and stakeholders are regular Polarion work items. They can have descriptions, attachments, links, comments, and follow the standard work item workflow. The catalog document simply organizes them for browsing and picker filtering.

​
Query Factories

Three query factories restrict what items appear in the picker dropdowns:
FactoryLucene QueryUsed By
stakeholderQuerytype:stakeholderStakeholder column
threatScenarioQuerytype:threatScenarioThreat Scenario column
cybersecurityGoalQuerytype:cybersecurityGoalCybersecurity Goal column
These factories act as data integrity guards, preventing analysts from accidentally linking the wrong work item type.

​
Benefits of Centralized Catalogs

Consistency — Every TARA module references the same threat scenario by linking to the same work item. The threat description, ID, and metadata are always identical. Maintainability — Updating a threat scenario title or description in the catalog immediately reflects in all TARA modules that reference it. Cross-module reporting — The TARA Summary Report and Cybersecurity Case dashboards can aggregate threat data across all modules because the underlying work item IDs are shared. Onboarding — New analysts select from a curated list of pre-approved threat scenarios and stakeholders, reducing the risk of omissions or inconsistencies.

​
Extending the Catalogs

To add a new threat scenario or stakeholder:
  1. Open the relevant catalog document (Threat Scenario Catalog or Stakeholder Catalog)
  2. Add a new work item of the appropriate type (threatScenario or stakeholder)
  3. Fill in the title and description
  4. The new item automatically appears in the Risksheet picker for all TARA modules
Deleting a stakeholder or threat scenario that is linked from TARA records will break those links. Instead, mark unused items as Obsolete using the work item workflow.

​
Cybersecurity Goals: A Different Pattern

While stakeholders and threat scenarios use the catalog-and-link pattern, Cybersecurity Goals follow a slightly different approach. The cybersecurityGoal column uses itemLink with cybersecurityGoalQuery, but it is not restricted to a specific catalog document. Goals can reside in any module because they are often created per TARA rather than shared globally. The goalCal column uses a cross-item binding (cybersecurityGoal.cal) to read and write the CAL field directly on the linked goal.

​
See Also