Anomaly Event Monitoring
A dedicated CAN security event monitor watches the entire bus, applies anomaly rules to traffic, logs events with timestamps, and optionally reports through a secure channel. It is the cross-cutting detective shell, the system-wide complement to per-node Local Injection Detection, and a near-mandatory shell for CRA event logging and IEC 62443 SR 6.x. CRA Annex I SR 6.2
Why Anomaly Event Monitoring Is Mandatory
The CRA expects products with digital elements to make internal activity auditable to support incident investigation and vulnerability handling. IEC 62443 SR 6.2 mandates audit logging and a clear retention/export story. Both push CAN-based systems toward a monitoring shell that is more than functional diagnostics. It is a security control with its own integrity guarantees.
What a CAN Anomaly Event Monitor Does
It receives every frame on the bus, applies expected-traffic models, flags deviations, and writes timestamped entries to a tamper-resistant, auditable event log. Where possible, it also reports critical events upstream over a separate channel (not on the CAN bus monitored) for centralized correlation.
Timing-Based Anomaly Detection
Depending on configuration, CAN traffic is periodic. The
monitor learns or is configured with the expected period of
each CAN ID and flags deviations: frames arriving too soon,
too late, or not at all. Timing anomalies catch both injection
(frames where there should be none) and DoS (legitimate frames
missing). For best coverage, ensure your base CAN
communication model is time driven and not event (change of
state) driven.
Injection Detection and Reporting
Combined with Local Injection Detection on legitimate senders, the monitor receives explicit injection reports (indicated by lost secure heartbeats)) and correlates them with bus-level evidence. Injection events should generate higher-severity log entries than routine timing variations.
Auditable Security Event Log
The log itself must be protected to fulfill the requirements to be "auditable": append-only structure, monotonic timestamps, integrity checksums or signatures over chunks. The log persists across resets and can be exported through a controlled interface for forensic review.
Dedicated Hardware vs Software Task
For higher security levels a dedicated hardware module on the bus is preferred. It has its own trust domain and cannot be silenced by compromising another control unit. For lower-risk products a hardened software task on an existing node with strong isolation can be sufficient, but the trust-domain trade-off must be documented.
Reporting Channel Security
Outbound reporting (to a manufacturer or operator cloud, asset-management system, or local maintenance interface) must be authenticated and confidentiality-protected. TLS-PSK is appropriate for constrained channels; cTLS is suitable when frame sizes matter. Diagnostic-only channels still need authentication.
IEC 62443 and CRA Mapping
This shell directly addresses SR 6.2 (Continuous monitoring) and supports SR 2.x (Use control) by providing the evidence trail. Under the EU CRA, Annex I requires products to record security-relevant events and to support vulnerability handling, which this shell delivers. SR 6.2 CRA Annex I
What This Shell Does Not Catch
Anomaly event monitoring detects but does not prevent. By the time the alarm fires, the malicious frame has reached its targets. The monitor is also itself a target. If it shares a trust domain with a compromised node, the attacker can suppress its logs. Pair this shell with Frame Security so injection cannot succeed in the first place.
Frequently Asked Questions
Is a security event log required by the EU CRA?
The CRA's Annex I expectations include logging of internal activity such as data accesses and modifications, and supporting incident investigation. For CAN-based products this translates into an anomaly event monitoring shell, not just functional diagnostics.
Can the main control unit act as the security monitor?
It can, but separation of concerns argues for a dedicated component or task. The main control unit is itself a high-value target; if it is compromised the security log goes with it. A dedicated monitor with a separate trust domain is preferred for higher security levels.
How does timing-based anomaly detection work on a CAN bus?
CAN traffic is highly periodic in most systems. The monitor learns or is configured with the expected period of each CAN ID and flags deviations: frames arriving too soon, too late, or not at all. This catches both injection (frames where there should be none) and DoS (legitimate frames missing).