Network Communication Matrix: Signal-Level Security Analysis for Connected Vehicles

Modern vehicles exchange thousands of signals per second across multiple network domains — CAN, CAN-FD, LIN, FlexRay, Automotive Ethernet, and increasingly SOME/IP and DDS service-oriented architectures. Traditional threat analysis operates at the component and interface level, identifying threats to ECUs and communication channels as broad categories. But as attack sophistication increases and regulatory requirements deepen, security teams need visibility at the signal level: understanding exactly which data is flowing, between which endpoints, with what security properties, and what happens when those properties are violated.

The ThreatZ Network Communication Matrix provides this signal-level visibility. It ingests vehicle network definitions from industry-standard formats, maps signals to standardized taxonomies, assigns cybersecurity properties, and automatically generates threats based on signal exposure and characteristics. This deep dive examines every layer of the Network Communication Matrix, from data ingestion through threat generation to multi-standard compliance assessment.

Why Signal-Level Visibility Matters

Consider a typical in-vehicle network with 3,000 to 5,000 signals distributed across 200 to 400 CAN messages. A component-level threat analysis might identify "CAN bus spoofing" as a threat to the powertrain domain. But which specific signals within that domain are safety-critical? Which carry personal data subject to GDPR? Which can be read by aftermarket dongles plugged into the OBD-II port? Without signal-level analysis, these questions remain unanswered, and risk assessments operate on assumptions rather than evidence.

Signal-level analysis enables precise risk quantification. Instead of assessing the impact of "CAN bus spoofing" in general, teams can assess the impact of spoofing the EngTorqReq signal (safety-critical, high impact) versus the AmbientTemp signal (informational, low impact). This precision drives more accurate risk scores, more targeted controls, and more efficient allocation of security engineering resources.

Key takeaway: Signal-level visibility transforms automotive threat analysis from broad categorical assessments into precise, evidence-based security engineering. Every signal has different security properties, different exposure levels, and different consequence profiles.

DBC File Import: Parsing Vehicle Network Definitions

The Network Communication Matrix begins with data ingestion. ThreatZ supports import of DBC files, the de facto industry standard for CAN database definitions. A DBC file contains the complete definition of a CAN network: all messages with their CAN IDs, cycle times, and sending nodes, and all signals within each message with their bit positions, scaling factors, value ranges, and units.

Supported Protocol Formats

Beyond standard CAN DBC files, ThreatZ parses network definitions for multiple automotive protocols:

• CAN / CAN-FD — Standard DBC format with extended support for CAN-FD 64-byte payloads and flexible data rate parameters.
• LIN — LIN Description File (LDF) import for LIN sub-networks, capturing schedule tables, signal encoding, and master/slave relationships.
• FlexRay — FIBEX format support for FlexRay time-triggered networks, including static and dynamic segment assignments, slot configurations, and cycle multiplexing.
• SAE J1939 — Full support for J1939 parameter group numbers (PGNs), suspect parameter numbers (SPNs), and the J1939 address claiming protocol used in commercial vehicles and heavy-duty equipment.

During import, ThreatZ validates the file structure, resolves cross-references between messages and signals, and creates a normalized internal representation that supports analysis across protocol boundaries. Signals from different network domains are unified into a single analysis space, enabling cross-domain threat identification.

COVESA VSS v6.0 Integration

Raw signal names from DBC files are manufacturer-specific and often cryptic. The signal Veh_Spd_Avg_Drvn in one OEM's database might be VehicleSpeed_Filt in another's, yet both represent the same logical vehicle signal. To enable standardized analysis, ThreatZ integrates with the COVESA (Connected Vehicle Systems Alliance) Vehicle Signal Specification (VSS) version 6.0.

VSS provides a hierarchical taxonomy of vehicle signals organized into branches like Vehicle.Speed, Vehicle.Chassis.Brake, and Vehicle.Body.Lights. ThreatZ maps imported signals to their corresponding VSS paths, either through automatic matching based on signal metadata or through manual mapping by the engineering team. This mapping enables several powerful capabilities.

First, standardized security properties can be inherited from the VSS taxonomy. If Vehicle.Chassis.SteeringWheel.Angle is classified as safety-critical in your VSS security profile, any manufacturer-specific signal mapped to that VSS path automatically inherits that classification. Second, cross-platform analysis becomes possible: the same VSS-based security policies can be applied across different vehicle platforms even when the underlying signal databases use completely different naming conventions.

VSS/VDM Requirement Relationships

COVESA VSS provides a standardized signal taxonomy that enables consistent cybersecurity requirement allocation across OEM and Tier-1 boundaries. Because every organization references the same canonical signal paths, security requirements authored by one party can be unambiguously consumed by another without translation tables or naming-convention guides.

The COVESA Vehicle Domain Model (VDM) maps vehicle domains — Powertrain, Chassis, ADAS, Body, Infotainment, Connectivity — to architectural subsystems. ThreatZ maps these VDM domains to program subsystems, allowing teams to allocate cybersecurity requirements at the domain level and then refine them at the signal level. VDM domains align naturally with ISO/SAE 21434 "items" and their boundaries, so the domain structure used for engineering directly supports the item definition required for compliance.

VSS-to-requirement traceability is a core capability: each VSS path (e.g., Vehicle.Speed, Vehicle.ADAS.AEB.IsActive) can be linked to cybersecurity requirements derived from TARA, creating end-to-end traceability from signal to threat to risk to requirement to control. This traceability chain satisfies ISO/SAE 21434 work-product expectations and gives auditors a clear path from any individual signal to its governing security controls.

The VSS hierarchy enables an inheritance model for security requirements. Requirements defined at a VSS branch level — for example, Vehicle.ADAS — automatically cascade to all child signals beneath that branch. This means that a safety-critical classification applied to the ADAS branch is inherited by every signal under it, from Vehicle.ADAS.AEB.IsActive to Vehicle.ADAS.LaneDepartureDetection.IsWarning, significantly reducing manual effort and ensuring consistent coverage.

For cross-OEM standardization, VSS enables Tier-1 suppliers to deliver signal security documentation in a format that any OEM can consume, regardless of their internal naming conventions. A Tier-1 can author cybersecurity requirements against VSS paths once and deliver them to multiple OEM customers without rework.

ThreatZ's VSS browser enables engineers to navigate the full COVESA VSS v6.0 tree and map signals to their project's component architecture. Teams can browse branches, inspect signal metadata (data type, unit, allowed values), and link signals to subsystems directly within the tool.

COVESA's VSS and VDM provide the common language for vehicle signal security. By mapping cybersecurity requirements to standardized signal paths, OEMs and Tier-1 suppliers achieve interoperable security documentation that survives supplier changes and platform reuse.

Signal Cybersecurity Properties

Each signal in the Network Communication Matrix can be annotated with six cybersecurity properties that describe its security requirements. These properties form the foundation of automated threat generation and compliance assessment.

These properties can be assigned manually per signal, inherited from VSS mappings, or auto-assigned based on data classification rules. For example, a policy might state that all signals classified as "Safety-Critical" automatically require integrity and availability, while signals classified as "Personal" require confidentiality.

Data Classification

ThreatZ supports five data classification levels for signals, enabling automated policy application and compliance mapping:

• Personal — Data that can identify or relate to a natural person. Examples: driver ID, location history, biometric data. Triggers GDPR compliance requirements.
• Confidential — Proprietary or sensitive data not intended for public disclosure. Examples: cryptographic keys, calibration parameters, proprietary algorithms.
• Intellectual Property — Data representing trade secrets or competitive advantages. Examples: engine control strategies, autonomous driving model parameters.
• Safety-Critical — Data whose corruption or loss could result in physical harm. Examples: brake commands, steering inputs, airbag deployment signals. Triggers ISO 26262 cross-references.
• Public — Data with no confidentiality requirements. Examples: ambient temperature, odometer reading, turn signal status.

SOME/IP and DDS Service Interface Modeling

As vehicle architectures evolve from signal-oriented to service-oriented communication, the Network Communication Matrix extends beyond traditional message/signal paradigms. ThreatZ models SOME/IP (Scalable service-Oriented MiddlewarE over IP) and DDS (Data Distribution Service) service interfaces with their specific characteristics.

SOME/IP Service Definitions

For SOME/IP, ThreatZ captures service IDs, method IDs, event groups, and the serialization format of each method's request and response payloads. The service discovery mechanism (SOME/IP-SD) is modeled explicitly, as it represents a significant attack surface: an attacker who can manipulate service discovery can redirect service calls to malicious endpoints or deny service availability by suppressing offer messages.

DDS Quality of Service Profiles

For DDS-based architectures, ThreatZ models topics, data readers, data writers, and Quality of Service (QoS) profiles. QoS policies such as reliability, durability, deadline, and liveliness are captured because they directly impact security analysis. A topic configured with "best effort" reliability has different availability threat exposure than one configured with "reliable" delivery. DDS security plugins (DDS-Security) configuration is captured to identify which topics have encryption, authentication, and access control enabled.

Data Flow Visualization

The Network Communication Matrix includes a directed graph visualization that renders the complete data flow topology of the vehicle network. Nodes represent ECUs, gateways, cloud endpoints, and VSOC (Vehicle Security Operations Center) components. Edges represent communication paths carrying specific signals or service calls.

The visualization supports multiple layers of detail. At the highest level, it shows domain-level data flows between functional clusters (powertrain, chassis, body, infotainment, ADAS). Zooming in reveals individual ECU connections with message-level flows. At the deepest level, individual signal paths are shown from source ECU through network gateways to destination ECUs.

Signal Path Tracing

Signal path tracing allows engineers to select any signal and visualize its complete journey through the vehicle network. For a signal like WheelSpeed_FL, the trace might show: ABS ECU (source) → Chassis CAN → Central Gateway → Powertrain CAN → Engine Control Module (destination). Each hop in the path represents a potential interception or manipulation point that must be addressed in the threat analysis.

Path tracing also reveals gateway forwarding rules, identifying which signals cross network domain boundaries. Signals that traverse gateways have different exposure profiles than those confined to a single network segment, and the visualization makes these cross-domain flows immediately visible.

Key takeaway: Data flow visualization transforms abstract network definitions into intuitive visual maps. Signal path tracing reveals the actual attack surface by showing every point where a signal can be intercepted, manipulated, or blocked as it traverses the vehicle network.

STRIDE-Based Auto-Threat Generation

One of the most powerful capabilities of the Network Communication Matrix is automated threat generation. ThreatZ applies nine STRIDE-based rules that analyze signal properties, data classifications, exposure levels, and network topology to automatically generate relevant threats.

The nine rules cover the following threat patterns:

1. Spoofing of signal source — Generated when a signal lacks authenticity requirements and traverses a shared bus where other ECUs could inject forged messages.
2. Tampering with signal content — Generated when a signal with integrity requirements travels across unprotected network segments or through gateways without integrity verification.
3. Repudiation of signal transmission — Generated for safety-critical or legally relevant signals that lack non-repudiation properties.
4. Information disclosure of signal data — Generated when signals classified as Personal, Confidential, or IP traverse networks without confidentiality protection, or when they are accessible through diagnostic interfaces.
5. Denial of service on signal delivery — Generated for signals with strict availability requirements that travel on bus segments susceptible to flooding or bus-off attacks.
6. Elevation of privilege via signal access — Generated when signals that control privileged operations (firmware updates, diagnostic modes, calibration access) lack proper authorization controls.
7. Cross-domain signal leakage — Generated when signals cross trust boundaries through gateways without appropriate filtering or access control policies.
8. Signal replay attack — Generated for command signals that lack freshness mechanisms (counters, timestamps) and could be captured and replayed to trigger unauthorized actions.
9. Service discovery manipulation — Generated for SOME/IP and DDS services where service discovery protocols operate without authentication, enabling man-in-the-middle or denial-of-service attacks on service-oriented communication.

Each generated threat includes the specific signals affected, the network path involved, the STRIDE category, and a preliminary severity assessment based on the signal's data classification and cybersecurity properties. The threat generation is idempotent: running it multiple times on the same network configuration produces the same results, and previously generated threats are not duplicated.

Signal Access Control Policies

The Network Communication Matrix includes a VISS-style (Vehicle Information Service Specification) access control model that defines who can access which signals and at what level.

Access Levels

Four access levels are supported for each signal-consumer pair:

• Read — The consumer can read the current signal value on demand.
• ReadWrite — The consumer can read the signal value and publish updated values.
• Subscribe — The consumer receives notifications when the signal value changes.
• None — The consumer has no access to the signal.

Signal Access Matrix

The signal access matrix presents a comprehensive view of all signals crossed with all potential consumers, with the access level specified for each combination. This matrix format makes it immediately visible which consumers have access to sensitive signals and whether that access is appropriate. For example, if an infotainment ECU has "Read" access to a brake pressure signal, the matrix highlights this potentially inappropriate cross-domain access for review.

Access policies can be defined per signal, per signal group, or inherited from VSS-based templates. The matrix supports filtering by data classification, network domain, and access level, enabling focused review of specific access patterns such as "show all consumers with ReadWrite access to Safety-Critical signals."

Multi-Standard Compliance Assessment

The Network Communication Matrix maps signal security properties and access controls against requirements from multiple standards simultaneously. ThreatZ evaluates compliance across the following frameworks:

Auto-Assessment with Idempotent Results

Compliance assessment runs automatically whenever the network configuration changes. The assessment engine processes signals in chunks to handle large network definitions efficiently (networks with 5,000+ signals). Results are idempotent: the same network configuration always produces the same compliance findings, ensuring reproducibility for audit purposes.

Each compliance finding includes the specific standard clause, the affected signals, the current state, the required state, and a remediation recommendation. Findings are categorized as compliant, partially compliant, or non-compliant, with an overall compliance score calculated per standard.

Signal Risk Pipeline

Auto-generated signal threats do not exist in isolation. The signal risk pipeline converts signal-level threats into project-level risks that integrate with the broader TARA. Each signal threat can be promoted to a project risk with a single action, automatically inheriting the threat description, affected assets (the signals and their source/destination ECUs), and preliminary impact assessment based on the signal's data classification.

Once promoted, signal risks flow through the standard ThreatZ risk assessment workflow: attack feasibility rating, impact assessment, risk level determination, and risk treatment. This integration ensures that signal-level findings are not siloed in the network analysis but contribute to the holistic project risk picture that drives security engineering decisions.

Key takeaway: The signal risk pipeline bridges the gap between detailed network analysis and project-level risk management. Signal threats automatically feed the TARA process, ensuring that network-level vulnerabilities drive appropriate security controls without manual re-entry or translation.

Tier Availability

The Network Communication Matrix is available on the Professional and Enterprise tiers as part of the TARA bundle. It is not included in the Team tier, as signal-level analysis requires the advanced threat modeling and risk assessment capabilities available in higher tiers.

Regulatory Context

The Network Communication Matrix does not exist in a vacuum. It directly addresses specific requirements across multiple automotive cybersecurity standards and regulations. Understanding the regulatory context helps teams position signal-level analysis as a mandatory compliance activity rather than an optional engineering exercise.

ISO/SAE 21434 Clause 9: Concept Phase

ISO/SAE 21434 Clause 9 requires the identification of cybersecurity-relevant communication interfaces during the concept phase. The Network Communication Matrix automates this identification by parsing network definitions and cataloging every signal, message, and service interface in the vehicle. Instead of manually listing communication interfaces in a spreadsheet, teams import their DBC files and immediately have a comprehensive, structured inventory of all cybersecurity-relevant communication channels — satisfying Clause 9's identification requirements with traceable, machine-readable evidence.

ISO/SAE 21434 Clause 15: Threat Analysis and Risk Assessment

Clause 15 requires threat analysis of communication channels as part of the TARA process. The Network Communication Matrix's automated STRIDE-based threat generation directly addresses this requirement by systematically analyzing every signal for spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege threats. This automation ensures that no communication channel is overlooked during threat analysis — a common gap when TARA is performed manually at the component level only.

ISO/SAE 21434 Clause 15 (TARA): The standard requires that threat analysis consider "the communication channels of the item or component." The Network Communication Matrix ensures that this analysis operates at signal granularity, identifying threats that component-level analysis alone would miss.

UNECE R155 Annex 5: Communication Channel Threats

UNECE R155 Annex 5 explicitly lists "threats to vehicles regarding their communication channels" as a specific threat category that must be addressed by the manufacturer's CSMS. The annex enumerates threats including spoofing of messages, unauthorized access to communication, manipulation of data transmitted across vehicle networks, and denial-of-service attacks on communication channels. The Network Communication Matrix's nine STRIDE-based threat rules map directly to these Annex 5 threat categories, providing verifiable evidence that each enumerated threat has been considered at the signal level.

ISO 26262: Functional Safety and ASIL Allocation

ISO 26262 Part 6 requires communication protocol safety analysis, including ASIL allocation for safety-critical signals. The Network Communication Matrix's data classification system identifies Safety-Critical signals and ensures their integrity and availability properties are properly defined. When a signal is classified as Safety-Critical and mapped to an ASIL level, the matrix validates that appropriate protection mechanisms (MACs, redundancy, timing monitors) are specified. This creates a traceable link between the functional safety analysis under ISO 26262 and the cybersecurity analysis under ISO/SAE 21434 — addressing the critical intersection where safety and security requirements converge.

EU Cyber Resilience Act (CRA)

The CRA requires identification of all external communication interfaces for vulnerability assessment. The Network Communication Matrix maps every signal path, including those that cross trust boundaries to external interfaces such as OBD-II ports, V2X channels, cellular connections, and cloud APIs. This comprehensive mapping satisfies the CRA's requirement to document all external-facing communication interfaces and assess their vulnerability exposure.

GB 44495: China Automotive Cybersecurity

China's GB 44495 standard requires analysis of in-vehicle network security, including protection of communication channels against unauthorized access and data manipulation. The Network Communication Matrix's multi-standard compliance assessment includes GB 44495 requirements, ensuring that vehicles targeting the Chinese market have signal-level security analysis that addresses this standard's specific communication security provisions.

AUTOSAR COM Stack Implications

For ECUs built on the AUTOSAR (AUTomotive Open System ARchitecture) platform, the COM stack defines how signals are packed into PDUs (Protocol Data Units) and transmitted across the network. The Network Communication Matrix's signal-level analysis accounts for AUTOSAR-specific security mechanisms including SecOC (Secure Onboard Communication) for message authentication, signal-level E2E (End-to-End) protection profiles, and PDU-level encryption. Understanding how signals map to AUTOSAR COM configurations ensures that the threat analysis reflects the actual implementation architecture rather than abstract communication patterns.

Key takeaway: Signal-level security analysis is not an optional enhancement — it is a specific requirement across ISO/SAE 21434, UNECE R155, ISO 26262, the EU CRA, and GB 44495. The Network Communication Matrix operationalizes these requirements by automating signal-level threat identification and compliance assessment against all applicable standards simultaneously.

OEM & Tier-1 Signal Security Operations

Signal-level security analysis serves different operational purposes for OEMs and Tier-1 suppliers. Understanding these workflow differences helps teams extract maximum value from the Network Communication Matrix across the supply chain.

OEM Network Architecture Governance

OEM central architecture teams define the vehicle's network topology, signal routing, and gateway configurations. The Network Communication Matrix provides these teams with signal-level policy enforcement capabilities: defining which signals require integrity protection, which require encryption, and which must be isolated within specific network domains. By establishing signal-level security policies at the architecture level, OEMs ensure that all Tier-1 suppliers developing ECUs for the platform adhere to consistent security requirements. This centralized governance prevents the fragmentation that occurs when each supplier independently decides on signal protection without platform-level coordination.

Tier-1 ECU Development and DBC Validation

Tier-1 ECU developers receive DBC files from the OEM that define their ECU's network interface. By importing these DBC files into ThreatZ, suppliers can validate that their ECU's signal security properties meet the OEM's requirements before delivery. The automated threat generation identifies any signals that lack required protection mechanisms, enabling the supplier to address gaps during development rather than discovering them during OEM integration testing. This pre-delivery validation reduces costly rework cycles and strengthens the supplier's cybersecurity documentation package.

Signal Access Matrices as Interface Security Contracts

The signal access matrix defines the security contract between OEMs and Tier-1 suppliers at the interface level. When an OEM specifies that a Tier-1 ECU may only read (not write) specific safety-critical signals, this access policy is captured in the matrix and validated during threat analysis. These signal access matrices complement the traditional cybersecurity requirements flow-down process by providing a concrete, testable specification of inter-ECU security boundaries. They also support TISAX (Trusted Information Security Assessment Exchange) assessments by demonstrating that information security controls extend to the signal level.

Post-Production Monitoring and Runtime Detection

R155 Article 7 requires post-production monitoring of cybersecurity threats and vulnerabilities. The Network Communication Matrix supports this requirement by linking signal threat analysis to runtime detection rules. When a signal-level threat is identified (e.g., spoofing of EngTorqReq), the corresponding detection rule can be defined to monitor for that specific threat pattern in production vehicles. This traceability from design-time threat analysis to runtime detection ensures that post-production monitoring covers the actual threat landscape identified during development — not just generic detection signatures.

Vulnerability Disclosure and CVE Traceability

When a vulnerability is disclosed that affects a specific communication protocol or ECU software component, the Network Communication Matrix enables rapid impact assessment by tracing the CVE to affected signals and ECUs across the vehicle platform. If a CVE affects the CAN message authentication mechanism used by a specific Tier-1 supplier's ECU, the matrix immediately identifies all signals sent and received by that ECU, their security properties, and their downstream consumers. This signal-level traceability accelerates vulnerability disclosure coordination between OEMs and Tier-1 suppliers, reducing the time from disclosure to remediation decision.

OTA Update Impact Assessment

When deploying software updates via OTA (Over-The-Air) under R156 SUMS requirements, the Network Communication Matrix enables assessment of signal-level changes. If an ECU software update adds new signals, modifies existing signal properties, or changes message timing, comparing the pre-update and post-update network configurations reveals the exact scope of change. This signal-level change analysis supports the R156 requirement to assess whether software updates affect the vehicle's cybersecurity posture and whether additional type approval activities are needed.

Homologation Evidence: Signal Compliance Reports

Signal compliance assessment reports generated by the Network Communication Matrix serve as type approval artifacts for R155 homologation. These reports demonstrate that the manufacturer has systematically analyzed all communication channels in the vehicle, identified relevant threats per Annex 5, and implemented appropriate mitigations. Technical Services reviewing the type approval application can verify that the signal-level analysis covers the complete vehicle network rather than a subset of components, providing confidence that the CSMS addresses communication security comprehensively.

Key takeaway: Signal-level security analysis serves distinct but complementary purposes across the OEM/Tier-1 supply chain. OEMs use it for architecture governance and platform-level policy enforcement; Tier-1 suppliers use it for pre-delivery validation and compliance documentation. Together, they create a traceable security chain from vehicle architecture through component delivery to post-production monitoring.