SAFETY AND CYBERSECURITY SHARE A SYSTEM: WHY HARA AND TARA NEED TO CONNECT

A brake controller rejects suspicious network traffic. The cybersecurity team sees a useful containment measure. The safety team asks what happens if legitimate braking requests are rejected at the same time. Both questions concern the same vehicle behaviour, yet separate analyses can leave the interaction invisible. Connecting HARA and TARA means making that interaction explicit before a control becomes an architectural commitment.

This article completes the conceptual bridge between our published HARA and TARA workflow articles. Read those articles for their respective analysis workflows, and AI Proposes, Platform Governs, Humans Decide for the governance background. Here, the focus is the engineering relationship between the analyses. Implementation details belong in the next article.

Start with one agreed system context

Safety and cybersecurity co-engineering starts with an agreed description of the item: its functions, boundaries, interfaces, operating modes and dependencies. The analyses may need different supporting detail. TARA needs attack surfaces and trust boundaries; HARA needs malfunctioning behaviour and operational situations. Those views should describe a consistent system baseline, with explicit extensions where their scopes differ.

Record assumptions about external services, communications, power, driver interaction and degraded operation. If one team assumes an independent braking path while another assumes all commands traverse a gateway, the disagreement is an engineering issue. Resolve it or retain it as an open assumption with an owner. Shared scope does not mean forcing every cybersecurity concern into a safety analysis.

The Cyber-Physical Systems Public Working Group report published by NIST provides a useful conceptual foundation. It considers interacting physical and digital components and discusses safety, security, reliability and resilience within trustworthiness, alongside timing concerns. We use that perspective to motivate connected analysis. It does not establish an automotive compliance method or mandate the relationship model proposed here.

Keep the two risk methods independent

HARA and TARA answer different engineering questions. A HARA considers a hazardous event in its operating situation, using severity, exposure and controllability to justify a safety classification. Exposure concerns that situation; it is not the probability of a successful attack. A TARA considers credible threats, potential impact and attack feasibility to justify cybersecurity risk decisions. Engineers must apply the assessment rules and terminology appropriate to their project.

A connection between scenarios transfers relevant context, not a numerical classification. Do not convert ASIL into a cybersecurity risk level, substitute attack feasibility for exposure, or create a combined score. A safety-related consequence can inform a cybersecurity impact assessment, but the cybersecurity team must still justify that assessment. Likewise, a threat scenario can challenge a safety assumption without automatically changing an approved HARA classification.

A hypothetical brake-control conflict

Consider a wholly hypothetical vehicle with a networked brake controller, a gateway and a separately implemented local braking path. Assume the safety concept requires an appropriate braking response within 20 milliseconds of a valid local demand. This number is invented for the example. It is neither a standard requirement nor a recommendation for a real vehicle.

The HARA considers insufficient deceleration when the driver requests braking while approaching stationary traffic. The team evaluates severity, exposure and controllability for the defined situation and documents the resulting classification. We deliberately assign no S, E, C or ASIL values here: speed, road conditions, available braking and driver response would need a defensible item-specific basis.

The TARA investigates whether a compromised gateway could inject or replay commands that interfere with brake control. The causal chain is conditional: attacker access enables command manipulation; accepted commands affect controller behaviour; that behaviour can contribute to insufficient deceleration in the relevant situation. Authentication, freshness checks, arbitration and the local path may interrupt the chain. Each claimed interruption needs evidence.

Now suppose a proposed cybersecurity control locks all command processing for 100 milliseconds after repeated authentication failures. If that lock also blocks valid local demands, it conflicts with the hypothetical 20-millisecond response requirement. If it affects only network requests and the local path remains available, the direct conflict may disappear. Shared scheduling, memory or power dependencies could still defeat that apparent separation.

Use safety constraints to shape the control

The joint engineering decision is to identify exactly what the lock affects and evaluate alternatives. The team might isolate the untrusted network ingress, bound authentication workload, prioritize local demands or limit retries without suspending essential control. These are candidate design choices, not validated solutions. Each changes attack resistance, resource consumption or degraded behaviour and therefore needs review in both domains.

Timing is only one constraint. Availability requirements determine which functions must remain usable during containment. Safe-state requirements determine acceptable behaviour for the operating situation. Switching off an actuator is not automatically safe while the vehicle is moving. Continuing operation with untrusted input is not automatically acceptable either. Specify the transition, retained capability, driver information and recovery conditions rather than relying on an unexplained safe-state label.

Verification should exercise the interaction: valid demands during hostile traffic, worst-case authentication workload, detection delays, communication loss and recovery after containment. Measure the relevant response interval against the stated requirement under defined conditions. Confirm that the local path remains independent where the argument relies on independence. A nominal timing test or an isolated penetration test cannot establish the entire cross-domain argument.

Make each relationship explainable

A useful relationship states what it means. A threat scenario may cause or contribute to a malfunction; a cybersecurity goal may support a safety goal; a control may constrain a functional or technical safety requirement. Record the direction, rationale, affected operating modes and preconditions. One threat can affect several hazardous events, and one hazardous event can have several malicious or non-malicious contributors.

Keep the supporting evidence identifiable and versioned: interface specifications, architectural allocations, timing budgets, dependency analyses and test results. Distinguish an asserted relationship from one supported by reviewed evidence. A missing relationship may reveal a gap, or it may be justified because a scenario concerns confidentiality without a credible safety consequence. Record that reasoning instead of treating link density as completeness.

Review changes across both domains

Changing the gateway, timeout, authentication mechanism or degraded mode can invalidate assumptions on either side. Joint change review should identify affected scenarios, goals, requirements and evidence, then assign specialist reviews. In the example, extending the lock duration requires renewed consideration of braking availability and cybersecurity treatment, even if the original HARA classifications remain appropriate.

Preserve the earlier decision and record why it remains valid or needs revision. Agreement on a relationship does not approve either underlying analysis. The next implementation discussion can build on this foundation: consistent scope, explicit causal reasoning, independently justified risk decisions and evidence that survives architectural change.