WIXLIB

Model-Based Engineering for Cybersecurity:Preparing for UN ECE Regulation and ISO/SAE-21434July 1st 2020 EUROPE 2020 The MathWorks, Inc.1

In the News 5 years ago Source: high-speed-steering-acceleration-hacks/2

In the News 5 years ago Source: high-speed-steering-acceleration-hacks/3

In the News 5 years ago Source: high-speed-steering-acceleration-hacks/4

Cybersecurity – Emerging Topic On-Board & V2X CommunicationVehicle-to-InfrastructureWifi HotspotWireless KeyGrowing communication of on-boardsystems, sensors and external sites Car becomes another node of IoT Security can compromise vehicle safety„FCA recalls 1.4 Million cars after Jeep hack“Remote StartInternet ConnectionTire Pressure MonitorVehicle-to-VehicleeCallBluetooth media/2013/02/2014-jeep-cherokee-1.jpg5

6

Current milestones around regulations, guidelines and standards11/2019ENISA publishes“GOODPRACTICES FORSECURITY OFSMART CARS”06/2020TODAY02/2020ISO/SAE 21434 DISis published06/2020UN ECE WP.29discussing adoption12/2020ISO/SAE 21434FDIS to bepublished7

Why is this important? UN ECE/TRANS/WP.29/2020/79 regulation proposal onCybersecurity– Uniform provisions concerning the approval of vehicles with regardto cyber security and of their cybersecurity management systems(CSMS)– Relevant for homologation– Automotive supply-chain to implement the UN Regulation ISO/SAE 21434 – “Road vehicles – Cybersecurityengineering”– Widely seen as reference implementation of a CSMS for E/ESystems– Development processes need to be adapted to deal withCybersecurity Threats and Risks8

ISO/SAE 21434 is aligned with the V model and ISO 26262Risk management(e.g. TARA/HARA)SystemRequirementsSecurity concept /High level design ofcountermeasuresSystem ReleaseSystemIntegration andTestSystem DesignSecurity specification /Detailed design ofcountermeasuresImplementationSW DesignSW TestSWImplementationContinuousSystem CareSecurity relatedSystem integration test andverificationSecurity related SWintegration test andverificationSecurity related SW componenttest and verification9

10

Embedded Systems Threats and Vulnerabilities Network Incorrect order of network connectionoperationsTainted data TOCTOU (race condition)Vulnerable path manipulationUse of non-secure temporary fileExecution of a binary/Loadof library from a relativepath can be controlled by anexternal actorTainted Data Tainted DataFile SystemHSM3rd partysoftwareUser Input Deterministic random output fromconstant seed Vulnerable pseudo-randomnumber generator Sensitive heap memory notcleared before releaseHSM: Hardware Security Module Tainted DataSensors11

Databases collecting security vulnerabilities and exploits CVE – Common Vulnerabilities & Exposures (cve.mitre.org)OSVDB – Open Source Vulnerability Database (osvdb.org)SANS Institute - SysAdmin, Audit, Network, Security (www.sans.org)OWASP - Open Web Application Security Project (www.owasp.org)13

CERT and other organizations share secure coding practicessource: https://www.securecoding.cert.orgValidate inputsHeed compiler warnings and use static and dynamic analysis toolsArchitect/Design Software for security policies14

15

Jeep Hack: Deterministic Random Number GeneratorVulnerability of the in-car impossibletime() integer2,147,483,647 possibilities (232-1)Source: http://illmatics.com/Remote%20Car%20Hacking.pdf16

Model-Based Design - examples of potential Cert C issues * 2FLP30-C– Do not use floating-point variables as loop counters 41FLP34-C– Ensure that floating-point conversions are within range of the new type 72INT30-C– Ensure that unsigned integer operations do not wrap 343INT31-C– Ensure that integer conversions do not result in lost or misinterpreted data*) all user made; found in C code generated from 50 industry models17

Model-Based Design - examples of potential Cert C issues *The models have not been designed to comply with Cert C(violations are specifically relevant if taint data is involved) 2FLP30-C– Do not use floating-point variables as loop counters 41FLP34-C– Ensure that floating-point conversions are within range of the new type 72INT30-C– Ensure that unsigned integer operations do not wrap 343INT31-C– Ensure that integer conversions do not result in lost or misinterpreted data*) all user made; found in C code generated from 50 industry models18

Early security considerations at model level Identify .– Discouraged blocks– Non-determinism– Basic design flaws Covers:– Most frequent issues(according the inhouse study)– CERT C, CWE and other checks Result:– Analyzable model– Removed basic flawsDesign flaw!20

Quantifying Security Compliance at Code LevelCode from original example model: 50% fewer Cert-C violations!Code from improved example model:Design improvements reduce late findings in C code and design iterations!21

Documenting formal cybersecurity requirements Outcome of ThreatAnalysis and RiskAssessment (TARA) needsto be documented andlinked to a system or acomponent Each threat can bemitigated by one or morerequirements22

Author and manage functional/cybersecurity requirementsCreate, organize and view requirementsdirectly in your modelsTrack implementation and verification status23

Cybersecurity testing in simulation using attack libraries Run attacks in simulation– Attacks can be implemented in Simulink– Usable for every system model and toattack almost every signal– Helps improve effectiveness of intrusiondetection systems (IDS) Adaptable– Increase variety of cyberattacks and usemasked parameters for flexibility– MATLAB Function blocks for morecomplex logic– Testing in SIL, PIL, HILSource: ber-physical-autonomy-1550746639241.html24

Model-Based Engineering use cases for ISO/SAE 21434Risk management(e.g. TARA/HARA)SystemRequirementsThreatSecurity concept /modeling &High level design ofanalysisSystem ReleaseSystemIntegration andTestSystem DesigncountermeasuresContinuousSystem ectionSystempreventionintegration test andverificationSecureSecurity specification /modelingDetailed design of& designSW DesignSW Testcountermeasures MISRA CSecure code CERT CgenerationImplementation CWESWImplementationReactionSmart related SWSecurityfuzz testingintegrationtest andverificationCode levelSecurityrelated SW componentsecuritytest and verificationverification25

26

In 2018 41% of the automotive suppliers did nothave an established cybersecurity program or teamSource: Ponemon Study of Automotive Industry Cybersecurity Practices (2018)27

Please contact us with questionsAre you planning to implement Cybersecurityrequirements in the near future?YES, we’re already working on itYES, this will be relevant for usin the next 1-2 yearsNO, this is not relevant for ussdavid@MathWorks.com

Model-Based Engineering use cases for ISO/SAE 21434 System Release System Integration and Test SW Test SW Implementation SW Design System Design System Requirements Continuous System Care Risk management (e.g. TARA/HARA) Security concept / High level design of countermeasures Security specification / Detailed design of countermeasures .