Webinar: Automotive Cybersecurity · Ask your questions at "All Panelists". Questions are answered online during and after the presentation. Slides & Presentation Within 1-2 days

V1.0 | 2018-03-08

Dr. Christof Ebert, Vector Consulting Services@ChristofEbert, @VectorVCS

Webinar: Automotive Cybersecurity

© 2018. Vector Consulting Services GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V1.0 | 2018-03-08

Welcome

Challenge Cybersecurity

Risk-Oriented Security

Systematic Security Engineering

Case Study

Summary and Discussion

Agenda

2/50


Webinar Automotive Cybersecurity

Welcome

Technical Notes

AudioThere should be music to hear. If the audio transmission over the Internet is not working, ask for the participation in a conference call. Contact the "host" in the "chat" window.

Screen Disable your screen saver.

Feedback & communication Open and review the "chat" window to get all organizational messages of the "hosts". Use the "chat" window to the "host" to contact all organizational WebEx and transfer requests or disturbances. Use the "Q & A" window instead of the "chat" window for substantive questions about the webinar. Ask your questions at "All Panelists". Questions are answered online during and after the presentation.

Slides & Presentation Within 1-2 days after the webinar, you will receive a link to the slides and additional information. After the webinar a link will guide you to a feedback form. We are looking forward to receiving your feedback to continuously improve our services.

Automotive Cybersecurity –Challenges and Practical GuidanceSpeaker: Dr. Christof Ebert

3/50


Welcome

Vector Consulting Services

Your experts for product development,technology strategy, IT, and managing changes

Interim support, such as virtual security/safety officer project management, line leadership

Global presence

Training on Agile, Requirements, Security, Safety, CMMI/SPICE etc.

Part of Vector Group with over 2000 employees

www.vector.com/consulting

www.vector.com/consulting-career Railway

IT & Finance

Automotive

Aerospace

DigitalTransformation

Medical

4/50


Vector Offers the most Complete Portfolio for Security/Safety

Welcome

Vector Cybersecurity and Safety Solutions

Security and Safety Consulting

AUTOSAR Basic Software

Tools (PLM with

PREEvision, Architecture, Test,

Diagnosis etc.)

Engineering Services for Safety and Security

HW based Security

5/50


Welcome




Case Study


Agenda

6/50


Challenges – Vector Client Survey


Safety and security paired with efficient engineering are major challenge.

Magic TriangleM

id-t

erm

chal

lenges

Short-term challenges

Vector Client Survey. Details: www.vector.com/trends. Horizontal axis shows short-term challenges; vertical axis shows mid-term challenges. Sum > 100% due to 3 answers per question. Strong validity with >4% response rate of 1500 recipients from different industries worldwide.

Innovative Products

Others

Connectivity

Distributed Development

Efficiencyand Cost

Digital Transformation

Governance and Compliance

ComplexityManagement

Securityand Safety

0%

10%

20%

30%

40%

50%

60%

70%

0% 10% 20% 30% 40% 50% 60% 70%

7/50


Different Threats Demand Holistic Systems Engineering


Liability Risk management Holistic systems engineering

Safety

Goal: Protect health(i.e., inside and outside)

Risk: Accident

Governance: ISO 26262, liability, etc.

Methods:

HARA, FTA, FMEA, …

Fail operational, …

Redundancy, …

Security

Goal: Protect assets(e.g., safety impact)

Risk: Attack, exploits

Governance: ISO 27001, policies, etc.

Methods:

TARA, …

Cryptography, IDIP, …

Key management, …

Privacy

Goal: Protect personal data

Risk: Data breach

Governance: Privacy laws, culture impacts

Methods:

TARA,…

Cryptography,…

Explicit consent, …

8/50


Who Doesn’t Learn from History Is Doomed to Repeat It


1980s: IT Systems were Complex Distributed Software Intensive Perceived as secure

Then came the Morris worm

A 100% security solution is not possible.Advanced risk assessment and mitigation is the order of the day.

2017: Automotive Systems are Complex Distributed Software Intensive Perceived as secure

Then…

9/50



Vulnerabilities Increase with Complexity and Connectivity

Devices

1980 2000 2020

Demand: Harden systems against cybersecurity threats

InfrastructureSystems

10/50


ACES (Autonomy, Connectivity, etc.)


Security will be the major liability risk in the future. Average security breach is detected in of 70% cases by third party – after 8 months.

4G LTE

OBD DSRC

SuppliersOEM

Public Clouds

Service Provider

ITS Operator

Cyberattacks

Password attacks

Application vulnerabilities

Rogue clients,

malware

Man in the middle attacks

Eavesdropping, Data leakage

Command injection,

data corruption, back doors

Physical attacks,Sensor

confusion

Trojans,Ransomware

11/50


Welcome




Case Study


Agenda

12/50


Security and Safety Standards Evolve in Parallel


Functional Safety (IEC 61508, ISO 26262, ISO 21448)

Hazard and risk analysis Functions and risk mitigation Safety engineering

ISO 26262 ed.2 will not fully address security, but has shared methods, such as TARA and demands infrastructure.

architecture methods data formats & functionality

+ Security (ISO 27001, ISO 15408, ISO 21434, SAE J3061)

Security and Safety are interactingand demand holistic systems engineering

Threat and risk analysis Abuse, misuse, confuse cases Security engineering

Safety Goals and

Requirements

Functional and

Technical Safety-Concept

Op. Scenarios,

Hazard, Risk Assessment

Safety Implemen-

tation

Safety Validation

Safety Case, Certification,

Approval

Safety Verification

Assets, Threats and

Risk Assessment

Security Goals and

Requirements

Technical Security Concept

Security Implemen-

tation

Security Validation

Security Case, Audit, Compliance

Security Verification

Safety Management

after SOP

Security Management

in POS

For (re) liable and efficient ramp-up connect security to safety13/50


Standards in Automotive Cybersecurity


ISO21434

14/50


Safety and Security must be addressed in parallel


Innovative functionality...

Autonomous driving and energy efficiency

Distributed systems

External interfaces (V2X; vehicle as IP node)

Complex feature interaction

Need to efficiently and effectively implement quality requirements

Connec-tivity

Things, Devices

Services

... Drives new challenges

New 3-tier automotive architecture

Functional development

Fail-safe and fail-operational behaviors

Safety-critical functions must be secured against external and internal attacks

Cost-effective development, evolution and support over the entire life-cycle

15/50


Tool Support: Vector SecurityCheck


Apply tools Consistent risk assessment and management Enable traceability to development Governance by continuously updated documentation

16/50


Tool Support: Vector SecurityCheck


Use tools and checklists for informed analysis – specifically for the unknown

17/50


Welcome




Case Study


Agenda

18/50


Assets, Threats and Risk

Assessment

Security Goals and

Requirements


Security Implementation

Security Validation

Security Case, Assessment, Compliance


Security Mgmt in Production,

Operation, Service

Security Engineering


Threat & Risk Analysis:1) Identify assets of value and threats caused by potential attackers.2) Rate impact and likelihood of successful attacks against assets to definetheir security level.

19/50


TARA - Identify and Agree on Assets


Consider specific automotive assets derived from CIAAG (Confidentiality, Integrity, Authenticity, Availability, Governance)

scheme

Which information, algorithm or intellectual property shall remain confidential?

Which data (e.g. configuration parameters) shall remain unchanged?

Which functions or procedures shall be only applied by e.g. OEM?

Which functions or data shall be always available?

Which company guidelines or legal requirements on data or procedures must be fulfilled?

Specific automotive asset categories

Privacy,Legislation,Governance

e.g. private data

Operational Performance

e.g. Drivingexperience

Finance

e.g. Liability, brand image

Safety

e.g. Vehicle functions

Checklist to identify assets

20/50


Threat Examples


Asset Threat Definition Example

Confidentiality InformationDisclosure

Exposing information to someone not authorized to see it

Allow reengineering of SW IP. Publish payment data on the web.

Integrity Tampering Modifying data or code

Modifying a software code executed in an ECU, or a frame transmission as it traverses the bus system.

Authenticity Spoofing Impersonating something or someone else.

Pretending to be an ADAS ECU, which sends an emergency brake signal.

Authenticity Repudiation Claiming to have not performed an action.

“I did not use the motorway so I do not have to pay a fee”, “I did not modify the mileage counter”

Availability Denial of Service

Deny or degrade service to users

Switch car into limp home mode. Delay emergency brake signal.Crash navigation system.Deny access to OEM cloud services.

Policy Enforcement

Elevation of Privilege

Gain capabilities without proper authorization

Allow a remote internet user to send signals on the vehicle bus.Allow vehicle owner to activate features without paying for them.

Policy Enforcement

Backdoor Gaining access to the software by malicious code

Software developer builds in a secret backdoor to later make changes to data.

21/50



Assessment

Security Goals and

Requirements



Security Validation




Operation, Service



SecurityCheck & Requirements:1) Derivation of Security Goals from threats2) Refinement of Security Goals to Functional Security Requirements (FSR)

22/50


Apply a Systematic Threat and Risk Assessment


Asset Attack Vectors

Threat, Risk Analysis

Security Goal

Threat Level

Impact Level

Security Level

Security work productsArchitecture Requirements

TARA

Security Concept


RefinedArchitecture

Security Goals

SecurityRequirements

SecurityMechanisms

Preliminary Architecture

23/50


Determine Necessary Security Level with TARA Results


No

.

Ass

et I

D Asset / Vehicle Function

CIAAP Attack vector

Th

reat

ID Threat

Exp

ertis

e

Win

dow

of

Opp

ortu

nity

Equ

ipm

ent

/ E

ffor

t

Th

reat

lev

el

(hig

h=

4; l

ow

=1)

Saf

ety

Fin

anci

al

Ope

ratio

nal

Pri

vacy

Imp

act

Lev

el Security level

1 Ast 2 Business model Auth Expoiting a vulnerability of ECU

Tht-1 Unpaid functional upgrades Expert Medium Tailored 2 Mod. Injuries

Medium Low No effect

3 Medium

24/50


Security Requirements Engineering


OEM Supplier

Market Requirements

Security Goals (SG)

Functional Security Requirements (FSR)

Why?

What?

How?

SG

FSR

TSR

Technical Security Requirements (TSR)

Establish a solid OEM-supplier interface, similar to DIA: OEM: system security concept, key managementTier 1: security concept, assumptions to OEM

“Security out of context” will not work25/50


Security Requirements and Traceability


TestArchitectureRequirements

Functional security requirements

TARA,Security Goals

Technical security requirements

Penetration Test, Robustness Tests

Functional Tests, Security Testing

Unit Test, Static Code Analysis

Seed/Key

Transmit

Abstract memoryoperation

Indications

Diagnostics

Seed/Key

IndicationsTransmit

TaskAbstract memoryoperation

IndicationsVerification Data Processing

Abstract memoryoperationStream Output Memory I/O

Memory Handling Library

Verification Data ProcessingAbstract memoryoperationStream Output Memory I/O

Memory blockoperation

Abstract memoryoperation

Task

Indications

Memory I/O

Multiple Memory I/O Manager

Memory I/O

Memory I/O

Decompression

Decompression

Memory blockoperation

Delta Download Library

Stream OutputMemory blockoperation

Decryption Decompression

Data Processing

Decryption Decompression

Data Processing

Memory Driv ers

Memory I/O

Indications

Communication Stack

IndicationsTransmitTask

Timer

Timer

Com Task Diag TaskTrigger Mem TaskTimer

Task Handling

Com Task Diag TaskTrigger Mem TaskTimer

Interprocessor Communication

Stack

Abstractmemoryoperation Memory I/O

Watchdog

Trigger

Security Module

Seed/Key Verification Decryption

System

Functional

SW/HW

26/50



Assessment

Security Goals and

Requirements



Security Validation




Operation, Service



SecurityCheck:

1. Derivation of Security Goals from threats

2. Refinement of Security Goals to Functional Security Requirements (FSR)

Technical Security Concept:

1. Refinement of system architecture to technical component level (SW/HW components)

2. Technical Security Requirements (TSeR) are refined out of the Security Concept

27/50


Layered Security Concept


Secure External Communication

Secure Gateways

Secure In-Vehicle

Communication

Secure Platform

Secure communication to services outside the vehicle

Intrusion detection mechanisms

Firewalls

Key Infrastructure / Vehicle PKI

Synchronized secure time Authenticity of messages

Integrity and freshness of messages

Confidentiality of messages

Key storage

Secure boot and secure update

Crypto library

HW trust anchor (HTA)

Associated Security Concepts

28/50


Firewall

Key Infrastructure

Secure On Board Com.

Secure Off Board Com.

Intrusion Detection / Prevention

Monitoring / Logging

Hypervisor

Crypto Library Download Manager

Connectivity

Gateway

TCU

Instrument

Cluster

DSRC

4G LTE

Laptop

Tablet

Smart-phone

Central Gateway

ADAS DC

Smart Chargin

g

Powertrain DC

Chassis DC

Body DC

Secure Boot & Secure update

Security Mechanisms allocated in Example Architecture


Head Unit

Secure SynchronizedTime Manager

Diagnostic Interface

29/50





Assessment

Security Goals and

Requirements



Security Validation




Operation, Service

30/50


Goal Avoid design and code errors which

can lead to security exploits

Approach Use a hardened OS with secure partitioning

Avoid embedded Linux due to its complexity and rapid change and thus many security gaps, (e.g. NULL function pointer dereferences, which allow hackers to inject executable code).

Deploy secure boot strategyStarting with first-stage ROM loader with a pre-burned cryptographic key, the next levels are verified before executing to ensure authenticity of each component of the boot

Apply rigorous static code analysisTools like Coverity, Klocwork or Bauhaus allow security checks, such as NULL pointer dereferences, memory access beyond allocated area, reads of uninitialized objects, buffer and array underflows, resource leaks etc.

Use modified condition/decision coverage (MC/DC)Detect backdoors

Security by Design: Secure Coding


31/50


Goal: Separate security privileged functions from the applications of the ECU by hardware

Approach: Secure Hardware Extension

On-chip extension to microcontroller

Secure Boot directly triggered by hardware upon start

Pre-shared cryptographic key Memory for secure storage of

(cryptographic) data Hardware extension for

cryptographic primitives

Security by Design: Hardware-Based Security


Controller

CPU

Peripherals (CAN, UART, ...)

SHE – Secure Hardware Extension

Control Logic

AES

RAM + Flash + ROM

Secure Zone

32/50


Safety and Security by Design: MICROSAR 4.3ff and FBL


Microcontroller

1 Extensions for AUTOSAR

FBL Application

HIS Security Module

Runtime Protection

Sec. Bootmanager (HSM)

Secure Update Manager

Update Authorization

RTE

SYS

CAN

COM

LIN FR ETH V2G1

AVB1

IO LIBS

ComplexDriver

MCAL

OS DIAG MEM

AMD

CSM

TLS

XML Sec

CAL (CPL)

EXT

SECOC

ETHFW1

FWM1

CANFW1

IDSM1

ETHIDS1CANIDS1

KSM1

POLM1

SCANTSYN1 SETHTSYN1

SLOG1

CRYDRV (HW)

CRYIF

CRYDRV(SW)

Application KeyM1

Hardware Trust Anchor (HTA )

Secure On-Board

Communication

Key management,

crypto handling

Firewall, IntrusionDetection

ASIL A-D hardened

33/50





Assessment

Security Goals and

Requirements



Security Validation




Operation, Service

34/50


V&V Methods and Tools Static / dynamic code analyzer Encryption cracker Vulnerability scanner Network traffic analyzer / stress tester Hardware debugger Interface scanner Exploit tester Layered fuzzing tester

Live Hacking Penetration testing Attack schemes Governance and social engineering attacks

Verification and Validation


Test for the known – and for the unknown.Ensure automatic regression tests are running with each delivery.

35/50


Ensure that each deployment satisfies security requirements Governance: Safety/security documentation is updated and validated Data encryption: Protection of intellectual property by encryption Authorization: Protection against unauthorized ECU access Validation: Safeguarding of data integrity in the flash memory Authentication: Verification of authenticity through signature methods

Deploy Security for Service and Operations: OTA


OEM Side Update Process

36/50


Welcome




Case Study


Agenda

37/50


ADAS Basic Functions (simplified use cases)

Warn driver when vehicle is getting too close to preceding vehicle

Warn driver if vehicle is leaving the driving lane

Perform action such as counter-steering or braking to mitigate risk of accident

Advanced Driver Assistance System – Overview

Case Study

Case Study

Scenario System Architecture

ADAS function is defined

Function level (implementation-independent, function-focused)

Probably, other risk assessment stages before or after this step

Level of Analysis

38/50


Step 1: Agree assets to be protected

A1: Network messages received or send by ADAS

A2: ADAS Software, including safety mechanisms

A3: Security keys

A4: Driving history and recorded data

ADAS – Step 1: Assets

Case Study

Asset Attack Threat

Attack Potential Security Goal

is performed

against is reduced by

requirescauses

has value for

Threat Agent(e.g. hacker)

Stakeholders(e.g., driver, OEM)

has


is achieved by

Case Study

39/50


Assessment Assess attack potential (Vector SecurityCheck, STRIDE, etc.)

consider expertise required, window of opportunity, equipment required Use external (!) expert judgment Identify attacks without taking into account potential security mechanisms

Attacks A1-AT1: Messages for braking are blocked. A1-AT2: Messages are replayed. A2-AT1: Safety mechanism, no lane keeping during manual take-over,

compromised and not working.

Threats A1-AT1-T1: Vehicle does not brake although the driver presses the braking

pedal. (Possible injuries in case failure of braking leads to an accident.) A1-AT2-T1: Display of warning messages with high frequency and without

reason. (Replay of warning messages at critical situations can lead to erroneous behavior and massive driver distraction.)

A2-AT1-T1: Lane is kept during manual take-over. (Heavy injuries because of failed take-over.)

ADAS – Step 2: Threat and Risk Analysis (TARA)

Case Study

Case Study

A … Asset

AT … Asset Attack

T … Threat

40/50


ADAS – Step 3: Security Goals

Case Study

Case Study

Asset/Function Attack Threat Threat Level

Impact Level

Risk

Messages received (e.g. steering angle, lane information) or send by the ADAS-System (warning message, counter steering request)

Confidentiality:Attacker overhearsmessages including risky overtaking maneuvers.

Information about driver’s behavior is forwarded to insurance agency that increases insurance fees for the driver.

Medium Very High

High

Messages received (e.g. steering angle, lane information) or send by the ADAS-System (warning message, counter steering request)

Authenticity: Messages are replayed.

Display of warning messages with high frequency and without reason.

Medium Medium Medium

Software of the ADAS-System (including safety mechanisms)

Availability: Safety mechanism, no lane keeping during manual take-over, compromised and not working.

Vehicle stays on opposite lane during manual take-overalthough driver wants to return to his lane.

Medium Very High

High

41/50


ADAS – Step 3: Security Requirements

Case Study

Security Goals

Functional Security Requirements

Technical Security Requirements

A1-AT1-T1-SG1: The system shall prevent manipulation of the messages send by the driver assistance system

The integrity of communication between driver assistance and sensors shall be ensured

The MAC shall be calculated by a SHE-compliant hardware trust anchor using the algorithm RSA2048

The MAC shall be truncated after x byte

Security goals are high level security requirements

Case Study

42/50


Case Study

ADAS – Step 4: Security Mechanisms (1/3)

Plausibility Checks, e.g. Vehicle Speed,

Engine_Status

OR

Braking while driving with speed > 10 km/h

Manipulation of Radar Object on CAN Bus

Overtake Brake ECU

Write message to CAN

Create correct message on CAN

AND

Systematic / Random HW Fault

Deliberate Manipulation

OR

Case Study

43/50


Case Study


Secure Communication

Secure Download

Secure

Diagnostics

AND

AND

AND

Write message to CAN

Create correct message on CAN

Overtake ECU on same CAN Bus

Create authenticated CAN message

Connection to ECU

Know-How Firmware

Enter programming Session (0x27)

Flash Firmware on ECU

Access to Flash

Know-How CAN message

Case Study

44/50


Case Study


Secure Internal Communication

Secure Download

Secure Diagnostics

• Efficient encryption and message authentication (e.g., H-MAC)

• Rationality Checks (e.g., Vehicle speed < 10 km/h)

• PKI with RSA-2048

• Closing Programming Interface

• No Keys on Diagnostic Tool

• Secure Access with organizational access management and guidelines

Reduce likelihood of attack

Secure Implementation

(e.g. Standard Architecture, Design Rules, Coding Guidelines, Process Rules, etc)

Case Study

45/50


Welcome




Case Study


Agenda

46/50


Safety and Security Must Cover the Entire Life-Cycle


Needs for safety and security along the life-cycle: Systems and service engineering methods for embedded and IT Scalable techniques for design, upgrades, regressions, services Multiple modes of operation (normal, attack, emergency, etc.)

Safety hazards

and security threats

Safety / Security by design

Development

Secured supply chain

Production

Monitoring and upgrades

Operations

Secure provisioningand governance

Services

47/50


Value - Supporting you in choosing the right technique


Security Techniques Cost Benefit

Quick Wins

Vector SafetyCheck and Vector SecurityCheck for risk assessment and implementation guidance

Low Medium

Virtual Security Manager for fast ramp-up and consistency Medium High

Safety and Security Training and compliance audits Low High

Technology

IDS/IPS, Firewall with adjusted policies Medium Medium

Secure boot, encrypted communication, storage High High

Secure run-time (e.g. CFI, DFI, MACs) High High

Process and Governance

Development for safety and security Medium High

Defensive and robust design, static analysis Medium High

Test strategy, e.g. Fuzz Testing, Penetration Testing etc. Medium High

Secure Key Management High Medium

Security task force and response team (internal or virtual) Medium High

48/50


Trainings

Open training: 24. April in Stuttgartwww.vector.com/consulting-training

In-house trainings tailored to your needs available worldwide

Automotive Cybersecurity: www.vector.com/training-security

Functional Safety: www.vector.com/training-safety

Grow Your Competences in Risk-Oriented Development


Webinars and Podcasts

Further webinars and recordingswww.vector.com/webinar-securitywww.vector.com/webinar-safety

Free white papers etc.

www.vector.com/media-consulting

49/50


Thank you for your attention.Contact us – We are glad to support you.

Passion. Partner. Value.

Vector Consulting Services

@VectorVCS

www.vector.com/[email protected]: +49-711-80670-0

Documents

Webinar: Automotive Cybersecurity · Ask your questions at "All Panelists". Questions are answered online during and after the presentation. Slides & Presentation Within 1-2 days