INTRUSION DETECTION AS A DISTRIBUTED SYSTEM

To start with, it must be clarified which safety-critical and mission-critical systems need to be secured and what protection is required for networks and connectivity units. How vulnerable they are depends on their connectivity via wireless or hardware-based interfaces. Resources available for IDS implementation are not measured solely by the RAM, ROM, or CPU load of the respective E/E architecture or possible restrictions of the data traffic. Professionals with specific automotive domain expertise are needed here, too; after all, high-quality configuration and regular updates can reduce the number of false positives. During vehicle operation, engine updates, event-driven updates, and regular configuration updates ensure a high level of protection, as lessons learned from the field are immediately incorporated into the dIDS to optimize its ability to detect anomalies.

Host-based or network-based IDS sensors
The first and most significant instance within a dIDS are the IDS sensors in the vehicle. These monitor ECUs and network communications and record any security events (SEv) that indicate cyberattacks or unauthorized access. This work is shared between host-based IDS (HIDS) sensors and network IDS (NIDS) sensors. HIDS sensors are located on individual ECUs and are specialized for monitoring their “host”; however, their focus is limited to the individual device. NIDS sensors are a different story: they monitor data traffic for specific network segments and stay alert for any suspicious activity in network, transport, and application protocols. However, they usually recognize attacks and manipulation only once the systems have already been compromised.

In the dIDS, security information from the specialized HIDS and the broader NIDS is combined to form a picture of the security situation that also includes the heterogeneous communication standards and systems in the vehicle. Which IDS sensors are used at which point is determined by the specific security requirements: sensors defined in the AUTOSAR stack often meet only the minimum standards, whereas smart sensors can review complex issues and independently pre-filter security events.



Distributed system for intrusion detection in the vehicle – from the (smart) IDS sensor, to the IDS manager, to the IDS reporter.

Rules-based approach
The IDS sensors register deviations from normal operation as security events (SEv). For example, a NIDS sensor recognizes a non-defined CAN ID or a non-defined Ethernet MAC address as a potential IT SEv, whereas a HIDS sensor registers unauthorized attempts at authentication for a diagnostic session at “its” ECU. Even if access fails, the logged SEv may be relevant for the subsequent forensics and evaluation of the risk situation.

Because vehicles are complex but still largely static systems, rules-based intrusion detection is practical. This approach is particularly well suited to mapping an OEM’s fixed specifications in terms of components, functions, resource consumption, protocols, and traffic in the vehicle. However, these specifications must be complete and error-free, and additional signal content or physical laws must be included in the IDS implementation for extended rules. If this is the case, the rules-based IDS can then even be used to test the specifications during development.

IDS managers: Qualify security events, reduce data volume
The next step is effective aggregation, qualification, and evaluation of the security events, carried out by the IDS managers (IdsM). As software-based switching points within the dIDS, they collect the detected SEv, filter out irrelevant logs, and forward only qualified security events (QSEv) to the vehicle’s IDS reporter (IdsR), which in turn feeds them to the backend for further analysis. It is there, in the vehicle security operations center (VSOC), that all QSEv for the entire fleet ultimately converge.



Filtering and processing of security events in an IDS manager. (© AUTOSAR)

The IDS manager’s specifications – e.g. its central data format for the SEv or even the setting of its filter functions – set a certain framework for intrusion detection that must be taken into account throughout the OEM’s supply chain. To this end, basic IdsM specifications have been integrated into every AUTOSAR Classic and Adaptive release since R20-11. However, the standard laid down in the AUTOSAR stack covers only the lowest common denominator. Depending on the reporting strategy and the available computing power within the E/E architecture, the range of functions can and should be extended to include more complex SEv aggregation and deeper filtering functions. Because AUTOSAR has also lacked an IdsR specification up to now, the OEM requires an overall concept for the in-vehicle dIDS.

In the future, the in-vehicle distributed intrusion detection system will become the cornerstone of lasting and effective cyber resilience, which can be scaled across entire fleets via a connected VSOC and software update management system (SUMS).

www.escrypt.com