|
Use Case |
Integration |
ROI (Return on Investment) |
|
Deriving Item Definition from System Architecture |
The Item Definition, the starting point for every TARA, is consistently derived from the System Architecture (managed by system engineers). Benefit: The TARA is based on a current and correct representation of the system to be analyzed. Redundant data storage and resulting inconsistencies between architecture representation and TARA definition are avoided. |
Elimination of data redundancy and inconsistency, improving the quality and accuracy of the TARA, which avoids costly security design flaws later in the development cycle. |
|
Cybersecurity Requirements in Requirements Management |
Security goals and requirements identified from the TARA are directly fed into the Requirements Management System. Benefit: Cybersecurity requirements are treated equally to functional or safety requirements. A separate silo for security requirements is not created, ensuring interdisciplinary collaboration and adherence to process requirements (e.g., in the V-model). |
Reduced rework by integrating security early ("shift-left"), leading to lower development costs and ensuring product security meets market/regulatory requirements from the start. |
|
Harmonization with Safety Goals (Security Goals & Safety Goals) |
The security goals derived from the TARA are aligned and linked with the Safety Goals from functional safety management. Benefit: Consistent risk consideration in both safety and security. The integration ensures that cybersecurity measures do not unintentionally compromise the system's functional safety, and vice versa. |
Mitigating the high-cost risk of safety-security conflicts, preventing system-critical failures and the associated liability or product recall costs. |
