What's behind Automotive Intrusion Detection?...Automotive Intrusion Detection/Prevention Attack 2. Report Consolidation of security events, event storage and reporting (e.g. hardware

V1.0 | 2019-10-23

Vector Technology Days 2019 – 2019-10-23

What's behind Automotive Intrusion Detection?Ideas, Concepts and a Software Architecture Proposal

© 2019. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V1.0 | 2019-10-23

~100M lines of code in one vehicle [2]

Boeing 787 Dreamliner: ~14M lines of code [2]

Increased potential for safety-relevant attacks

History with summary of exploited interfaces

Automotive Megatrends

Attack Surface and Attack History

Motivation

Connectivity

~470M connected vehicles by 2025(E.U., U.S. and China) [1]

Autonomous Driving

~80M vehicles with high or full automation by 2030(E.U., U.S. and China) [1]

2010-

2014

2015

2016-

2018

Physical access to in-vehicle network, diagnostic port, multimedia interfaces, cellular network

„Jeep Hack“ via cellular network: Recall of 1.4M vehicles

Diagnostic port, multimedia interfaces, cellular network

[1] pwc, and strategy&. 2017. “The 2017 Strategy& Digital Auto Report: Fast and furious: Why making money in the "roboconomy" is getting harder.” https://www.strategyand.pwc.com/media/file/2017-Strategyand-Digital-Auto-Report.pdf.”

[2] “McCandless, David, Pearl Doughty-White, and Miriam Quick. 2015. “Codebases: Millions of lines of code.” https://informationisbeautiful.net/visualizations/million-lines-of-code/.”

2/14


Five Steps to Compromise an ECU

Attack Example

ADASDomain Controller

InfotainmentDomain Controller

Telematic Control UnitPowertrain

Domain Cont.

ChassisDomain Controller Body

DomainController

Intrusion Detection/Prevention System (IDPS)

Diagnostic port

1.Remote access

2.Access to

in-vehicle network

3.Bridge domain

boundaries

4.Access to

target ECU

5.Manipulate ECU orvehicle behavior

Defense barriers

3/14


The Big Picture

Automotive Intrusion Detection/Prevention

Attack

2. Report

Consolidation of security events, event storage and reporting

(e.g. hardware security module, secure communication, signed uploads)

3. Analyze

Threat monitoring and threat triage for single vehicles and the whole fleet

(e.g. impact analysis, root cause analysis)

4. Develop

Threat response (e.g. identification, implementation

and test of countermeasures)

5. Deploy

Secure download of software updates(e.g. secure communication, signed updates)

Security Operations Center (SOC)

1. Prevent and Detect

Intrusion prevention and detection sensors(e.g. firewalls, gateway, diagnostics,

watchdog, operating system)

4/14


Static electric/electronic (E/E) architecture

Definition of in-vehicle communication and to some extend also ECU internals in a semi-formalized way

[DBC, FIBEX, LDF]

AUTOSAR XML (ARXML)

Network-based (in-vehicle communication)

Ethernet

Controller Area Network (CAN)/CAN FD

FlexRay (FR)

Local Interconnect Network (LIN)

Host-based (ECU internals)

Control flow

CPU runtime

Memory consumption

ECU-internal communication

Automotive Intrusion Detection Principles


Detection of IDS events

Signature-based (detection of known attacks)

Anomaly-based (detection of deviations from normal behavior)

5/14


Distributed Automotive IDS on System Level





Domain Cont.


DomainController

Diagnostic port

IDS Manager (IdsM)

Abstracts reaction on IDS events

Consolidation of IDS events (ECU-local)Host-based IDS sensors

Network-based IDS sensors

6/14


Proposed Software Architecture

Realization of IDS sensors in existing basic software modules and SW-Cs

Lots of “sensors” are already implemented but no standardized reporting/action is defined> Examples

> TcpIp: Packets with invalid destination IP address are dropped

> SecOC: Secured PDU is dropped when MAC authentication fails

> Dcm: Security Access request denied due to wrong credentials

Minor changes to enable existing modules to report detected misbehavior as IDS events

New IDS Manager basic software module

1. Unified interface for IDS event reporting> Also useable from application level (SW-Cs)

2. Consolidation of reported IDS events> Avoid IDS event “flooding” by debouncing/aggregation

3. Different reactions on reported IDS events> Set fault memory entry

> Store information in NvM

> Send communication message

> Inform application

4. No active countermeasure

Automotive IDS in Classic AUTOSAR


RTE

IDS ManagerComm. Stacks (CAN,

LIN, FR, ETH) Diag.

SW-C

OS

System Services

Mem.

7/14



Realization of IDS sensors in the operating system, Adaptive AUTOSAR functional clusters and Adaptive Applications (user)

Lots of “sensors” are already implemented but no standardized reporting/action is defined(same as for Classic AUTOSAR)> Examples

> Identity and Access Management

> Platform Health Management

Minor changes to enable existing modules to report detected misbehavior as IDS events

Special handling/adaptions for OS functionality (like network stacks) necessary> Instrumentation of OS or/and realization of sensors

as Adaptive Application

IDS Manager as Adaptive Application

Same tasks as in Classic AUTOSAR

Automotive IDS in Adaptive AUTOSAR


IDS Manager

Adaptive

Application

Adaptive

Pla

tform

OS

Crypto …

Network Monitor

Network Stack

EM IAM

PHM

SOMEIPd

Appl.

8/14


Standardization ongoing

AUTOSAR concept 671

Specification of IDS sensors and IdsM

Classic and Adaptive AUTOSAR

Planned release: 20/11

IdsR out of scope(see next slides)

You are welcome to join the concept group!

IDS Standardization in AUTOSAR


9/14


Reporting Use Cases

2. Report

3. Analyze

4. Develop

5. Deploy



Send regular (e.g. hourly/daily) vehicle health status

2. Report

Send an immediate notification of a critical security incident

Get a detailed ECU security log

Get a detailed vehicle security log

10/14


IDS Event Reporting on System Level

2. Report




Domain Cont.


DomainController

Diagnostic port

IDS Manager (IdsM)

Protected forwarding of IDS events to IDS Reporter via automotive protocol

IDS Reporter (IdsR)

Reporting of IDS events to Security Operations Center (SOC) / backend

Consolidation of IDS events (vehicle-local)

SecurityOperations

Center (SOC)

11/14



IDS Reporter is instantiated only once and in an Adaptive AUTOSAR-based ECU

Realization of IDS Reporter as an Adaptive Application

Secure forwarding of IDS events to SOC/backend (wireless)> Usage of different communication

protocols possible, e.g. MQTT, SOME/IP, DDS

Different buffering and reporting strategies possible

IDS Managers of the same and of other ECUs to forward IDS events to the IDS Reporter> Standardized IDS event format

beneficial/necessary

IDS Event Reporting in Adaptive AUTOSAR


IDS Manager

Adaptive

Application

Adaptive

Pla

tform

OS

Crypto …

Network Monitor

Network Stack

EM

PHM

SOMEIPd

Appl.

IDS Reporter

SecurityOperations

Center (SOC)

IAM

IdsM IdsM

12/14


Summary and Outlook

What's behind Automotive Intrusion Detection?

2. Report

Different reporting strategies

Connection to SOC/backend implemented once> Different communication protocols

Vehicle-local consolidation of IDS events in the IDS Reporter (IdsR)> Realization as new Adaptive Application

4. Develop

5. Deploy


3. Analyze


Host- and network-based IDS sensors> Realization in existing BSW modules/

functional clusters, OS and application

ECU-local consolidation of IDS events in the IDS Manager (IdsM)> Realization as new BSW module/

Adaptive Application

Standardization in AUTOSAR ongoing> Invitation to join the concept group

13/14


Authors:Dr. Eduard Metzker; Dr. Marc WeberVector Germany

Your questions are welcome!

http://www.vector.com/

Documents

What's behind Automotive Intrusion Detection?...Automotive Intrusion Detection/Prevention Attack 2. Report Consolidation of security events, event storage and reporting (e.g. hardware