Building Secure Cars Dennis Kengo Oka
Visit to download the full and correct content document: https://ebookmass.com/product/building-secure-cars-dennis-kengo-oka/
More products digital (pdf, epub, mobi) instant download maybe you interests ...
Girls in Boys' Cars Felicity Castagna
https://ebookmass.com/product/girls-in-boys-cars-felicitycastagna/
War and Trade in Maritime East Asia Mihoko Oka
https://ebookmass.com/product/war-and-trade-in-maritime-eastasia-mihoko-oka/
Panic Attack Dennis Palumbo
https://ebookmass.com/product/panic-attack-dennis-palumbo/
Panic Attack Dennis Palumbo
https://ebookmass.com/product/panic-attack-dennis-palumbo-3/
Panic Attack Dennis Palumbo
https://ebookmass.com/product/panic-attack-dennis-palumbo-2/
Cirque Mary Ellen Dennis
https://ebookmass.com/product/cirque-mary-ellen-dennis/
Book Parts Dennis Duncan (Editor)
https://ebookmass.com/product/book-parts-dennis-duncan-editor/
The Oulipo and Modern Thought Dennis Duncan
https://ebookmass.com/product/the-oulipo-and-modern-thoughtdennis-duncan/
Encyclopedia of Virology, Fourth Edition - V1-5 Dennis Bamford
https://ebookmass.com/product/encyclopedia-of-virology-fourthedition-v1-5-dennis-bamford/
Thiseditionfirstpublished2021
©2021JohnWiley&SonsLtd
Allrightsreserved.Nopartofthispublicationmaybereproduced,storedinaretrievalsystem,or transmitted,inanyformorbyanymeans,electronic,mechanical,photocopying,recordingorotherwise, exceptaspermittedbylaw.Adviceonhowtoobtainpermissiontoreusematerialfromthistitleisavailable athttp://www.wiley.com/go/permissions.
TherightofDennisKengoOkatobeidentifiedastheauthorofthisworkhasbeenassertedinaccordance withlaw.
RegisteredOffices
JohnWiley&Sons,Inc.,111RiverStreet,Hoboken,NJ07030,USA
JohnWiley&SonsLtd,TheAtrium,SouthernGate,Chichester,WestSussex,PO198SQ,UK
EditorialOffice
TheAtrium,SouthernGate,Chichester,WestSussex,PO198SQ,UK
Fordetailsofourglobaleditorialoffices,customerservices,andmoreinformationaboutWileyproducts visitusatwww.wiley.com.
Wileyalsopublishesitsbooksinavarietyofelectronicformatsandbyprint-on-demand.Somecontentthat appearsinstandardprintversionsofthisbookmaynotbeavailableinotherformats.
LimitofLiability/DisclaimerofWarranty
Inviewofongoingresearch,equipmentmodifications,changesingovernmentalregulations,andthe constantflowofinformationrelatingtotheuseofexperimentalreagents,equipment,anddevices,the readerisurgedtoreviewandevaluatetheinformationprovidedinthepackageinsertorinstructionsfor eachchemical,pieceofequipment,reagent,ordevicefor,amongotherthings,anychangesinthe instructionsorindicationofusageandforaddedwarningsandprecautions.Whilethepublisherand authorshaveusedtheirbesteffortsinpreparingthiswork,theymakenorepresentationsorwarrantieswith respecttotheaccuracyorcompletenessofthecontentsofthisworkandspecificallydisclaimallwarranties, includingwithoutlimitationanyimpliedwarrantiesofmerchantabilityorfitnessforaparticularpurpose. Nowarrantymaybecreatedorextendedbysalesrepresentatives,writtensalesmaterialsorpromotional statementsforthiswork.Thefactthatanorganization,website,orproductisreferredtointhisworkasa citationand/orpotentialsourceoffurtherinformationdoesnotmeanthatthepublisherandauthors endorsetheinformationorservicestheorganization,website,orproductmayprovideorrecommendations itmaymake.Thisworkissoldwiththeunderstandingthatthepublisherisnotengagedinrendering professionalservices.Theadviceandstrategiescontainedhereinmaynotbesuitableforyoursituation. Youshouldconsultwithaspecialistwhereappropriate.Further,readersshouldbeawarethatwebsites listedinthisworkmayhavechangedordisappearedbetweenwhenthisworkwaswrittenandwhenitis read.Neitherthepublishernorauthorsshallbeliableforanylossofprofitoranyothercommercial damages,includingbutnotlimitedtospecial,incidental,consequential,orotherdamages.
LibraryofCongressCataloging-in-PublicationData
Name:Oka,DennisKengo,author.
Title:Buildingsecurecars:assuringtheautomotivesoftwaredevelopment lifecycle/DennisKengoOka.
Description:Firstedition.|Hoboken,NJ:JohnWiley&Sons,Inc.,2021. |Includesbibliographicalreferencesandindex.
Identifiers:LCCN2020041114(print)|LCCN2020041115(ebook)|ISBN 9781119710745(cloth)|ISBN9781119710769(adobepdf)|ISBN 9781119710776(epub)
Subjects:LCSH:Automotivetelematics–Securitymeasures.|Automotive computers–Programming.
Classification:LCCTL272.53.O422021(print)|LCCTL272.53(ebook)| DDC629.2/72–dc23
LCrecordavailableathttps://lccn.loc.gov/2020041114
LCebookrecordavailableathttps://lccn.loc.gov/2020041115
CoverDesign:Wiley
CoverImage:nadla/iStock/GettyImages
Setin9.5/12.5ptSTIXTwoTextbySPiGlobal,Chennai,India
10987654321
Contents
Preface xi
AbouttheAuthor xiii
1OverviewoftheCurrentStateofCybersecurityintheAutomotive Industry 1
1.1CybersecurityStandards,Guidelines,andActivities 3
1.2ProcessChanges,OrganizationalChanges,andNewSolutions 6
1.3ResultsfromaSurveyonCybersecurityPracticesintheAutomotiveIndustry 8
1.3.1SurveyMethods 8
1.3.2ReportResults 9
1.3.2.1OrganizationalChallenges 9
1.3.2.2TechnicalChallenges 10
1.3.2.3ProductDevelopmentandSecurityTestingChallenges 11
1.3.2.4SupplyChainandThird-PartyComponentsChallenges 11
1.3.3HowtoAddresstheChallenges 12
1.3.3.1OrganizationalTakeaways 12
1.3.3.2TechnicalTakeaways 13
1.3.3.3ProductDevelopmentandSecurityTestingTakeaways 13
1.3.3.4SupplyChainandThird-PartyComponentsTakeaways 13
1.3.3.5GettingStarted 14
1.3.3.6PracticalExamplesofOrganizationsWhoHaveStarted 15
1.4ExamplesofVulnerabilitiesintheAutomotiveIndustry 16
1.5ChapterSummary 18 References 19
2IntroductiontoSecurityintheAutomotiveSoftwareDevelopment Lifecycle 23
2.1V-ModelSoftwareDevelopmentProcess 24
2.2ChallengesinAutomotiveSoftwareDevelopment 25
2.3SecuritySolutionsateachStepintheV-Model 26
2.3.1CybersecurityRequirementsReview 27
2.3.2SecurityDesignReview 27
2.3.3ThreatAnalysisandRiskAssessment 27
2.3.4SourceCodeReview 28
2.3.5StaticCodeAnalysis 28
2.3.6SoftwareCompositionAnalysis 29
2.3.7SecurityFunctionalTesting 29
2.3.8VulnerabilityScanning 29
2.3.9FuzzTesting 30
2.3.10PenetrationTesting 30
2.3.11IncidentResponseandUpdates 31
2.3.12ContinuousCybersecurityActivities 32
2.3.13OverallCybersecurityManagement 32
2.4NewTechnicalChallenges 32
2.5ChapterSummary 34 References 35
3Automotive-GradeSecureHardware 37
3.1NeedforAutomotiveSecureHardware 39
3.2DifferentTypesofHSMs 41
3.3RootofTrust:SecurityFeaturesProvidedbyAutomotiveHSM 43
3.3.1SecureBoot 44
3.3.2SecureIn-VehicleCommunication 45
3.3.3SecureHostFlashing 46
3.3.4SecureDebugAccess 47
3.3.5SecureLogging 47
3.4ChapterSummary 48 References 48
4NeedforAutomatedSecuritySolutionsintheAutomotiveSoftware DevelopmentLifecycle 51
4.1MainChallengesintheAutomotiveIndustry 53
4.2AutomatedSecuritySolutionsDuringtheProductDevelopmentPhases 55
4.2.1StaticCodeAnalysis 55
4.2.2SoftwareCompositionAnalysis 57
4.2.3SecurityTesting 58
4.2.4AutomationandTraceabilityDuringSoftwareDevelopment 59
4.3SolutionsDuringOperationsandMaintenancePhases 59
4.3.1CybersecurityMonitoring,VulnerabilityManagement,IncidentResponse,and OTAUpdates 59
4.4ChapterSummary 61 References 61
5StaticCodeAnalysisforAutomotiveSoftware 63
5.1IntroductiontoMISRAandAUTOSARCodingGuidelines 68
5.2ProblemStatement:MISRAandAUTOSARChallenges 75
5.3Solution:WorkflowforCodeSegmentation,GuidelinePolicies,andDeviation Management 79
5.3.1Step1:SegmenttheCodebaseintoDifferentCategories/ComponentsBasedon Risk 80
5.3.2Step2:SpecifyGuidelinePolicies(SetofGuidelinestoApply)Dependingon RiskCategories 81
5.3.3Step3:PerformtheScanandPlantheApproachforPrioritizationof Findings 82
5.3.4Step4:PrioritizeFindingsBasedontheRiskCategoriesandGuidelinePolicies andDetermineHowtoHandleEachFinding,e.g.FixorLeaveasDeviation 83
5.3.5Step5:FollowaDefinedDeviationManagementProcess,IncludingApproval Steps 84
5.3.6Step6:ReportonMISRAorAUTOSARCodingGuidelinesCompliance IncludingDeviations 86
5.4ChapterSummary 87 References 88
6SoftwareCompositionAnalysisintheAutomotiveIndustry 91
6.1SoftwareCompositionAnalysis:BenefitsandUsageScenarios 95
6.2ProblemStatement:AnalysisofAutomotiveSoftwareOpen-SourceSoftware Risks 98
6.2.1AnalysisResults 98
6.2.1.1zlib 99
6.2.1.2libpng 99
6.2.1.3OpenSSL 99
6.2.1.4curl 99
6.2.1.5LinuxKernel 100
6.2.2Discussion 100
6.3Solution:CountermeasuresonProcessandTechnicalLevels 101
6.3.1FullyInventoryOpen-SourceSoftware 101
6.3.2UseAppropriateSoftwareCompositionAnalysisApproaches 102
6.3.3MapOpen-SourceSoftwaretoKnownSecurityVulnerabilities 102
6.3.4IdentifyLicense,Quality,andSecurityRisks 103
6.3.5CreateandEnforceOpen-SourceSoftwareRiskPolicies 104
6.3.6ContinuouslyMonitorforNewSecurityThreatsandVulnerabilities 104
6.3.7DefineandFollowProcessesforAddressingVulnerabilitiesinOpen-Source Software 105
6.3.8HowtoGetStarted 106
6.4ChapterSummary 107 References 108
7OverviewofAutomotiveSecurityTestingApproaches 111
7.1PracticalSecurityTesting 115
7.1.1SecurityFunctionalTesting 117
7.1.2VulnerabilityScanning 119
7.1.3FuzzTesting 121
7.1.4PenetrationTesting 122
7.2FrameworksforSecurityTesting 125
7.3FocusonFuzzTesting 129
7.3.1FuzzEngine 130
7.3.2Injector 134
7.3.3Monitor 136
7.4ChapterSummary 140 References 141
8AutomatingFuzzTestingofIn-VehicleSystemsbyIntegratingwith AutomotiveTestTools 145
8.1OverviewofHILSystems 147
8.2ProblemStatement:SUTRequiresExternalInputandMonitoring 150
8.3Solution:IntegratingFuzzTestingToolswithHILSystems 152
8.3.1White-BoxApproachforFuzzTestingUsingHILSystem 157
8.3.1.1ExampleTestSetupUsinganEngineECU 159
8.3.1.2FuzzTestingSetupfortheEngineECU 161
8.3.1.3FuzzTestingSetupConsiderations 165
8.3.2Black-BoxApproachforFuzzTestingUsingHILSystem 166
8.3.2.1ExampleTargetSystemSetupUsingEngineandBodyControlModules 168
8.3.2.2FuzzTestingSetupUsingDuplicateEngineandBodyControlModules 171
8.3.2.3FuzzTestingSetupConsiderations 175
8.4ChapterSummary 176 References 177
9ImprovingFuzzTestingCoveragebyUsingAgent Instrumentation 179
9.1IntroductiontoAgentInstrumentation 182
9.2ProblemStatement:UndetectableVulnerabilities 183
9.2.1MemoryLeaks 184
9.2.2CoreDumpsandZombieProcesses 185
9.2.3ConsiderationsforAddressingUndetectableVulnerabilities 187
9.3Solution:UsingAgentstoDetectUndetectableVulnerabilities 187
9.3.1OverviewoftheTestEnvironment 188
9.3.2ModesofOperation 189
9.3.2.1SynchronousMode 190
9.3.2.2AsynchronousMode 191
9.3.2.3HybridApproach 192
9.3.3ExamplesofAgents 193
9.3.3.1AgentCoreDump 193
9.3.3.2AgentLogTailer 194
9.3.3.3AgentProcessMonitor 194
9.3.3.4AgentPID 194
9.3.3.5AgentAddressSanitizer 195
9.3.3.6AgentValgrind 195
9.3.3.7AnExampleconfig.jsonConfigurationFile 196
9.3.4ExampleResultsfromAgentInstrumentation 197
9.3.4.1BluetoothFuzzTesting 198
9.3.4.2Wi-FiFuzzTesting 199
9.3.4.3MQTTFuzzTesting 201
9.3.4.4FileFormatFuzzTesting 203
9.3.5ApplicabilityandAutomation 206
9.4ChapterSummary 207
References 208
10AutomatingFileFuzzingoverUSBforAutomotiveSystems 211
10.1NeedforFileFormatFuzzing 213
10.2ProblemStatement:ManualProcessforFileFormatFuzzing 215
10.3Solution:EmulatedFilesystemstoAutomateFileFormatFuzzing 216
10.3.1SystemArchitectureOverview 217
10.3.2PhaseOneImplementationExample:PrepareFuzzedFiles 219
10.3.3PhaseTwoImplementationExample:AutomaticallyEmulateFilesystems 223
10.3.4AutomatingUserInput 228
10.3.5MonitorforExceptions 231
10.4ChapterSummary 236
References 237
11AutomationandTraceabilitybyIntegratingApplicationSecurity TestingToolsintoALMSystems 241
11.1IntroductiontoALMSystems 242
11.2ProblemStatement:TracingSecureSoftwareDevelopmentActivitiesand ResultstoRequirementsandAutomatingApplicationSecurityTesting 245
11.3Solution:IntegratingApplicationSecurityTestingToolswithALM Systems 248
11.3.1Concept 249
11.3.1.1StaticCodeAnalysis–Example 249
11.3.1.2SoftwareCompositionAnalysis–Example 250
11.3.1.3VulnerabilityScanning–Example 250
11.3.1.4FuzzTesting–Example 250
11.3.1.5ConceptOverview 251
11.3.2ExampleImplementation 252
11.3.2.1Defensics 252
11.3.2.2codeBeamerALM 252
11.3.2.3Jenkins 252
11.3.2.4SUT 253
11.3.2.5ImplementationOverview 253
11.3.3Considerations 258
11.4ChapterSummary 262
References 264
x Contents
12ContinuousCybersecurityMonitoring,VulnerabilityManagement, IncidentResponse,andSecureOTAUpdates 267
12.1NeedforCybersecurityMonitoringandSecureOTAUpdates 268
12.2ProblemStatement:SoftwareInventory,MonitoringVulnerabilities,and VulnerableVehicles 271
12.3Solution:ReleaseManagement,MonitoringandTracking,andSecureOTA Updates 272
12.3.1ReleaseManagement 273
12.3.2MonitoringandTracking 276
12.3.2.1SolutionsinOtherIndustries 276
12.3.2.2SolutionsintheAutomotiveIndustry 277
12.3.2.3ExampleAutomotiveSOCOverview 277
12.3.2.4ExampleAutomotiveSOCWorkflow 279
12.3.2.5NewlyDetectedVulnerabilitiesinOpen-SourceSoftware–Example 279
12.3.3SecureOTAUpdates 280
12.3.3.1IdentifyVulnerableVehiclesTargetedforOTAUpdates 281
12.3.3.2PerformSecureOTAUpdates 281
12.3.3.3TargetSystemsforOTAUpdates 282
12.3.3.4OverviewofSecureOTAUpdateProcessforECUs 283
12.3.3.5StandardizationandFrameworksforOTAUpdates 284
12.4ChapterSummary 285 References 286
13SummaryandNextSteps 289 Index 293
Preface
Inthefast-changingautomotiveindustry,withevolvingnewandadvancedtechnologies allowingforincreasedconnectivity,autonomousdriving,sharedmobilityservices,andelectrification, moresoftware isbeingdevelopedandusedintheautomotiveindustrythanever before.Assmartersoftware-enabledcarsequippedwithimprovedconnectivityincreasingly fillourroads,thesecarsalsobecomemoresusceptibletocybersecurityattacksandthus thereisastrongneedto buildsecurecars.Consequently,cybersecurityisbecomingmore importantintheautomotiveindustryoverall,especiallywiththeintroductionofnewcybersecuritystandardsandregulations.Itisthereforeimperativeforautomotiveorganizations toconsider,inparticular,automatedtechnicalsolutionstohelpfulfilltherequirements specifiedinthesestandardsandregulations.
WhileIhavebeenengagedinvarioustypesofautomotivesecurityresearchformorethan 15years,Ihavenoticedthatthereisnocomprehensivebookthatexploreshowtoincorporatesecurityactivitiesandsolutionsintheautomotivesoftwaredevelopmentlifecycle.To thisend,thisbookservestohelpautomotiveorganizationsbuildsecurecars,especiallywith afocusonassuringthesoftwaredevelopmentlifecycle.
BuildingSecureCars introducesthereadertodifferenttypesofsecuritysolutionsthat canbeappliedateachstageinthetypicalautomotivesoftwaredevelopmentlifecycle.More specifically,thebookhighlightstheneedforcybersecurityfocusingontheprincipalfactors thatleadtovulnerabilitiesinautomotivesystems,namely, coding, testing,andtheuseof open-sourcesoftware.Subsequently,thefocusisonapplyingautomatedapplicationsecuritytestingsolutionssuchasstaticcodeanalysis,softwarecompositionanalysis,andfuzz testingamongothersaspartofthedevelopmentprocess.However,applyingsuchsolutionsisnotstraightforwardandseveralcommonchallengesandpitfallsbasedonreal-life experiencesfromtheautomotiveindustryarediscussed.Thebookthenpresentsmultiple technicalpracticalsolutionsthatautomotiveorganizationscanconsiderwhenemploying asystematicandautomatedapproachtofindingvulnerabilitiesefficientlyandeffectively asearlyaspossibleinthesoftwaredevelopmentlifecycle.
Itisassumedthatthereaderhassomebasicunderstandingofcybersecurityandsoftware developmentprocesses,asthiswillhelpunderstandthecontentsbetter.Thisbookisaimed atsoftwaredevelopmentprocessowners,securitypolicyowners,softwaredevelopersand engineers,cybersecurityteams,andtheirmanagersatautomotiveorganizations.Thus, thisbookintendstoprovideguidancetoautomanufacturers,partssuppliers,andother
xii Preface organizationsinvolvedinbuildingautomotivesystemstoincorporatesecurityintotheir softwaredevelopmentlifecycle.
IwouldliketoextendmygratitudetothestaffmembersatWileywhosupportedand guidedmethroughouttheentireprocessofwritingthisbook.Iwouldalsoliketothank allmycolleaguesandresearchcollaboratorsovertheyears.Iamextremelygratefultohave hadtheopportunitytoworkwithsomanybrightandtalentedpeoplewhohaveinspired andsupportedme.Onapersonalnote,IwouldliketothankmywonderfulwifeMaifor beingextremelypatientandprovidingmewithherfullsupportwhileIwaswritingthis book,andmythreebeautifuldaughtersMia,Elina,andAlyssaformakingmesmileevery day:)IwouldalsoliketothankmyparentsSvenandEtsuko,andmybrotherAlexandsister Linda,foralwayskeepingmemotivatedandfocusedontheimportantthingsinlife.
AbouttheAuthor
Dr.DennisKengoOkaisanautomotivecybersecurityexpertwithmorethan15yearsof globalexperienceintheautomotiveindustry.HereceivedhisPh.D.inComputerScience andEngineering,withafocusonautomotivesecurity,fromChalmersUniversityof TechnologyinSweden.Inthepast,DennishasworkedwithVolvoCarCorporationin Swedenwherehebootstrappedautomotivesecurityresearchforremotediagnosticsand over-the-airupdatesonvehicles.HehasalsoworkedfortheBoschGroupinJapanserving bothJapaneseandglobalcustomers.Specifically,Dennisco-launchedtheautomotive securitypractice(ESCRYPT)inJapanandwastheHeadofEngineeringandConsultingAsia-Pacific.Dennishasalsobeeninvolvedinseveralautomotivestandardization activities,includingthedevelopmentoffuzztestingguidelinesandcybersecuritytesting frameworks.Hehasover60publicationsconsistingofconferencepapers,journalarticles, andbookchapters,andisafrequentpublicspeakeratinternationalautomotiveand cybersecurityconferencesandevents.
Sincetheintroductionofthefirstgasoline-poweredautomobilesin1885,theautomotive industryhasgonethroughanamazingjourneytocreatethetechnicalmarvelsthatare today’svehicles.Buthowdidwegethere?Aquickreviewofthehistoryofautomotivetechnologytrendsshowstheintroductionofcoreelectricalsystemsinthe1980s.Theseisolated systemsweredrivenbyinnovationandnewtechnologiessuchasairbagsandanti-lock brakingsystems(ABSs).Themainfocusofthesesystemswason safety tohelpcreatesafer vehicles.Inthe1990suntiltheearly2000s,theautomotiveindustrysawawidespreadadoptionofelectroniccontrolunits(ECUs)invehicles,mainlydrivenbyefficiencyinproduction andmaintenance,toimprovescalabilityandtimetomarket,andsupportemergingcommunicationtypes.Thus,besides safety,thesesystemsfocusedonprovidingadded capabilities. Inthelate2000sandcontinuingintothe2010s,theautomotiveindustrygraduallyintroducedthenotionofconnectedandautonomousvehicles,wherevehicleswerenolonger isolatedsystemsbutinsteadhavecapabilitiestocommunicatewithexternalentitiesand partiallycontrolvehiclefunctionality.Duringthe2010s,therewasasurgeinthedevelopmentofadvanceddriverassistancesystems(ADAS),includingemergencybrakingsystems, predictiveforwardcollisionwarningsystems,lanekeepassistsystems,parkassistsystems, andautopilotfunctionality.Thisconnectedandautonomousvehicletrendismostly drivenbytheintroductionofhighconnectivityinterfaces,improvedcamerasandsensors, advanceddataprocessingandanalytics,andbythedevelopmentofnewbusinessmodelsby providingvalue-addedsolutions,suchasautopilot,remotediagnostics,andsharedservices. Themainfocusofthesesystems,besides safety and capabilities,istheneedfor security. ForillustrativepurposestheautomotivetechnologytrendsaredepictedinFigure1.1.
Theautomotiveindustryisgoingthroughadigitaltransformationwiththerapid developmentofmoreadvancedvehiclesbuiltonmoresoftware,includingopen-source software,toprovidemorecomplexfunctionalityandautonomousdrivingcapabilities,to enablemoreconnectivity,andtooffermoreservices.Toensuresuccessfuldevelopment anddeploymentofsuchvehiclesitisimperativethatsafetyandsecurityarethoroughly consideredduringthedevelopmentlifecycle.Inparticular,high-risktechnologiessuchas
BuildingSecureCars:AssuringtheAutomotiveSoftwareDevelopmentLifecycle, FirstEdition.DennisKengoOka. ©2021JohnWiley&SonsLtd.Published2021byJohnWiley&SonsLtd.
Figure1.1 Overviewofautomotivetechnologytrends.
0
Figure1.2 Comparisonofsoftwaresizesofdifferentsystemsintermsoflinesofcode.Source: Datafrom[1].
wirelessconnectivityandautonomousdrivingfunctionalityneedtobebothdesignedand developedsecurely,aswellasproperlysecuritytested.
Amodernvehiclecancontainupto150ECUsandmorethan100millionlinesofsoftware code,whichisprojectedtoriseto300millionlinesofcodeby2030.Forreference,Figure1.2 showsacomparisonofsoftwareonvehicleswiththatofothersystemsinordertohighlight theenormousvolumeofsoftwaretheautomotiveindustryisengagedin.Ascanbeseenin thefigure,amodernvehiclecontainsmoresoftwarethanFacebookwithoutthebackend code(62millionlinesofcode).AvehiclealsohasmorethandoublethecodeofMicrosoft Office2013,morethansixtimesthecodeoftheAndroidOS,morethan15timesthecode ofaBoeing787,andmorethan20timesthecodeoftheMarsCuriosityRoverandaUS militarydrone[1].Asmoresoftwareisincludedinvehicles,thereisariskofintroducing softwarebugsandvulnerabilitiesthat,ifabusedbymaliciousattackers,couldpotentially havedisastrousconsequences,includingonsafety,privacy,andoperationofthevehicles. Forreference,thestatisticalaverageforsoftwareusedincriticalsystems(e.g.flightcontrolandairtrafficcontrol)indicates10–12errorsforevery1000linesofcode.However,this leveloferrorrateisunacceptableforNASAregardingsoftwareusedonspaceshuttles.It wasshownthatsoftwarefortheunfortunateSpaceShuttleChallengerhadalatentdefect
rateofjust0.11errorsper1000linesofcode[2].Consideringeventhisminusculeerror rateof0.11errorsper1000linesofcode,mathematicallyspeaking,amodernvehiclewould containmorethan11000defects!
Ashighlightedbythetechnologytrendsandthelargevolumeofsoftware,cybersecurityis anever-increasingimportanttopicthattheautomotiveindustrymustseriouslyconsider.To thisend,theautomotiveindustryhasbeenworkingonandhasproducedseveralcybersecurityrelatedstandards,bestpractices,andguidelines.Afewexamplesofthesearepresented inthischaptertoprovidesomebackgroundonthecurrentstateofcybersecurity.Additionally,automotiveorganizationsaregoingthroughprocesschangesandorganizational changesbasedonthesestandards,bestpractices,andguidelines,whichareexploredfurther indetail.Moreover,someresultsfromasurveyconductedonthecurrentstateofcybersecuritypracticesintheautomotiveindustryarepresentedtoprovidesomefurtherinsight. Finally,thischapterdiscussesafewexamplesofvulnerabilitiesidentifiedintheautomotive industrytobetterunderstandtheconsequencescausedbythelackofadequatecybersecurityactivitiesduringthedevelopmentlifecycle.
Themainpointsofthischapterare:
● Wepresentanoverviewofthecurrentautomotivecybersecuritylandscape,including cybersecuritystandards,guidelines,andactivities.
● Wediscussthenecessaryprocesschanges,organizationalchanges,andnewsolutions thatneedtobeadoptedbyautomotiveorganizationsbasedontheaforementionedcybersecuritystandardsandguidelines.
● Wereviewresultsfromarecentstudyonautomotivecybersecuritypracticesandhighlightexistingchallengesatautomotiveorganizations.
1.1CybersecurityStandards,Guidelines,andActivities
Theautomotiveindustryiswell-knownforfollowingarigorousdevelopmentprocess basedonstandardssuchasISO26262forfunctionalsafety[3],ISO21448forsafety oftheintendedfunctionality(SOTIF)[4]andASPICE(AutomotiveSoftwareProcess ImprovementandCapabilitydEtermination)[5],andforfollowingcodingguidelines providedbyMISRA(MotorIndustrySoftwareReliabilityAssociation)fordevelopmentof safety-relevantsoftware[6].However,besidessafety,cybersecurityhasbecomeamajor concernand,consequently,thereareseveralstandards,bestpracticesandguidelines regardingcybersecurity.Forexample,theSAEJ3061[7],releasedinJanuary2016,isthe world’sfirstcybersecuritystandardfortheautomotiveindustry.The SAEJ3061:CybersecurityGuidebookforCyber-PhysicalVehicleSystems providesguidanceandrecommendations fordesigningcybersecurityintothesystemincludingproductdesign,validation,deployment,andcommunicationtasks.Italsostatesthat,forasystemtobesafe,italsoneedsto besecure.ThisconceptisdepictedinFigure1.3,whereallsafety-criticalsystemsalsoneed tobecybersecurity-criticalsystems;highlightingthemantrathat thereisnosafetywithout security.
TheSAEJ3061hasnowbeensupersededbytheISO/SAE21434standard[8].Inpreviousyears,therewereseveralongoingactivitiesonautomotivesecurityinbothISOand
Figure1.3 Allsafety-criticalsystemsare cybersecurity-criticalsystems.
SAE,so,inNovember2016,thePartnershipStandardsDevelopmentOrganization(PSDO) wascreatedasacooperationagreementbetweenISOandSAEintwoareas:RoadVehicles andIntelligentTransportationSystems.Asaresult,SAEandISOagreedtoworktogether todevelopacybersecuritystandard,namelytheISO/SAE21434,whichisthefirststandardtobecreatedunderthisnewagreement.Thisstandardwillbejointlyreleasedby bothSAEandISO.TheDIS(draftinternationalstandard)versionofISO/SAE21434was releasedinFebruary2020,andthefinaldocumentforpublicationisexpectedtobepublishedsometimeinthefirsthalfof2021.ProposedcontentsoftheISO/SAE21434divided intodifferentclausesincludeOverallcybersecuritymanagement,Continuouscybersecurityactivities,Riskassessmentmethods,Conceptphase,Productdevelopment,Production, OperationsandMaintenance,amongothers[9].Anoverviewofhowtherelevantclauses inISO/SAE21434aremappedontotheproductlifecycleisillustratedinFigure1.4.Please
Figure1.4 ClausesinISO/SAE21434mappedontotheproductlifecycle.Source:Basedon[8].
notethatclauses1through4aregeneralclausescoveringtheScope,Normativereferences, Termsandabbreviations,andGeneralconsiderations.Clauses5through15containspecificcybersecurityrequirementsfortherespectiveactivitiesthatautomotiveorganizations needtofulfill.
Moreover,therearecurrentlyongoingactivitiesfornewUNECE(UnitedNationsEconomicCommissionforEurope)regulationsregardingcybersecurityandsoftwareupdates. TherearecurrentlytwogroupsintheWorldForumforHarmonizationofVehicleRegulationsWorkingParty(WP.29)workingontheseactivities: ProposalforanewUNRegulation onuniformprovisionsconcerningtheapprovalofvehicleswithregardstocybersecurityand cybersecuritymanagementsystem(CSMS) and ProposalforanewUNRegulationonuniform provisionsconcerningtheapprovalofvehicleswithregardstosoftwareupdateandsoftware updatesmanagementsystem(SUMS)
Thesedocumentsarestillindraftformatthetimeofwritingthisbook,howeverthe currentlyproposedcontentsinclude:Riskassessmentprocesses,Threatstovehicles,Mitigations,Measurestodetectandpreventcyberattacks,CSMSrequiredfortypeapproval, SUMSrequiredforsecuredeliveryofsoftwareupdates.
TheUNregulationswillapplytopassengercars,trucks,andbusesandwillenterinto forceinJanuary2021.Theseregulationswillrequire:
● VehiclemanufacturertoobtainacertificateofcompliancefortheirCSMS.
● VehiclemanufacturertoobtainacertificateofcompliancefortheirSUMS.
● Vehicletypeapprovalwithregardtocybersecurityandsoftwareupdatesbasedonthe CSMSandSUMScertificatesandvehicle-specificmaterial.
IntheEuropeanUnion,theregulationoncybersecuritywillbemandatoryforallnew vehicletypesfromJuly2022andforallnewvehiclesproducedfromJuly2024[10].
Therehasalsobeenregionalworktopromotecybersecurity.Forinstance,inSingapore atechnicalreferencedocumentcalledTR-68[11]wasreleasedinJanuary2019focusing ongivingguidanceoncybersecurityprinciplesandassessmentframeworkforautonomous vehicles.
Moreover,ENISA(EuropeanUnionAgencyforCybersecurity)haspublishedacoupleof reportsonthetopicsofcybersecurityandresilienceofsmartcars[12],andgoodpractices forthesecurityofsmartcars[13].Thesereportscovervarioustopicsincludingthreatsand attackscenarios,andsecuritymeasuresandgoodpracticessuchaspolicies,organizational practices,andtechnicalpractices.
Furthermore,NHTSA(NationalHighwayTrafficSafetyAuthority)releasedadocument called CybersecurityBestPracticesforModernVehicles [14]inOctober2016.Thisdocument providesbestpracticesfordevelopingarisk-basedapproachandprocessestocovercybersecurityissuesfororganizationsmanufacturinganddesigningvehiclesystemsandsoftware. Moreover,therehavebeenseveralproposalsforlegislation,e.g.in2015theUSCongress SPYCAR(SecurityandPrivacyinYourCar)Act[15]wasproposed.Thisactfocusesonthe needforautomanufacturerstohandlecybersecurityandemploypropermethodsconsideringprivacyofdatacollectedinvehicles.Thisbillwasreintroducedin2017[16]and2019 [17],focusingona cyberdashboard witheasytounderstandgraphicstoinformconsumers aboutthevehicle’sprotectionfromcybersecuritythreatsanditsabilitytoprotectpersonal information.
1OverviewoftheCurrentStateofCybersecurityintheAutomotiveIndustry
Focusingonsoftwaredevelopment,besidesstandards,regulationsandbestpractices, thereexistseveralsecurecodingguidelines.Forexample,MISRA[6]wasinitially focusedonprovidingcodingrulestoensuresafedevelopmentofsafety-relevantsystems, howevertheMISRAC:2012Amendment1releasedin2016[18]includedanumber ofsecurity-relevantrulesaswell.TheCERT(ComputerEmergencyResponseTeam) C/C++ codingstandards[19,20]areoftenusedbydeveloperstodevelopsecurecode inotherindustriesand,lately,arebecomingmoreadoptedintheautomotiveindustry. TheAUTOSAR(AUTomotiveOpenSystemARchitecture)C++ 14guidelines[21]canbe followedfordevelopingsafeandsecureAUTOSARsoftware.Althoughtechnicallynot acodingguideline,theCWE(CommonWeaknessEnumeration)[22]containsabroad categorizationofsecurityflawsthatcanbeusedbydeveloperstocheckwhethertheircode containscertainweaknesses.
Furthermore,theautomotiveindustryhasaverycomplexsupplychain,traditionally startingwithanOEM(originalequipmentmanufacturer)atthetopandthenbranching outintoseveraltiersofsuppliersprovidinganythingfromentiresystems,hardwaredevices, fullyfunctionalsoftware,individualhardwarecomponents,standalonesoftwarestacks, components,libraries,specificfirmwareetc.Toproperlymanagetherisksinthesupply chain,especiallyconsideringthefluidandfastdevelopmentofsoftwarecomponents,the NationalTelecommunicationsandInformationAdministration(NTIA)oftheUnitedStates DepartmentofCommercehasestablishedataskforcefocusingonSoftwareComponent Transparency[23].ThistaskforcefocusesonpromotingSBOM(softwarebillofmaterials) bothasaconceptandforpracticaldeployment,buildingawarenessandprovidinginformationonstrategies,usecases,organizationalrolesetc.Italsolooksatuniversalapproaches onhowtoidentifyandnamecomponents,howtoshareSBOMs,howtoautomateSBOMin productionanduse,includingwhattoolsandstandardscouldbeusedforcreatingSBOMs inthespecificformatsidentified.
1.2ProcessChanges,OrganizationalChanges,andNew Solutions
Basedonthestandards,regulations,bestpractices,andguidelinespresentedintheprevious section,theautomotiveindustryisgoingthroughatransformation.Tofollowandmeetthe standardsandregulationsrequiresseveralprocessandorganizationalchanges.Moreover, forautomotiveorganizationstorealizetheseprocesschangesrequiresimplementationof severalnewtechnicalsolutions.Thisthree-stepactivityisillustratedinFigure1.5andis describedinmoredetailinthefollowing.
Changesmayneedtobemadetothesoftwaredevelopmentlifecycle(SDLC).One exampleistobecompliantwithcertaincodingstandards(e.g.MISRAorAUTOSAR). Anotherexampleistheadditionofnewsecuritygates,e.g.addingasecuritygaterequiring fuzztestingtobeperformedaspartoftheprocessbeforethenextstepintheproduct developmentphaseisallowed.Torealizecodingstandardscompliance,solutionsbased onvariousautomatedstaticcodeanalysistoolsthatperformscansofthesourcecodeand generatereportsoftheresultscouldbeused.Thesetoolscanbebuiltintothedevelopment processtorunasanautomatedstep.Torealizefuzztestingaspartoftheprocess,itis
Standards, regulations etc.
•ISO/SAE 21434
•UNECE WP.29
•TR-68 (Singapore)
Process and organizational changes
•SDLC
•Compliance
•Security gates
•Engineering process, security team
•Cybersecurity monitoring, incident response, OTA updates
Solutions
•Static code analysis for coding guidelines
•Fuzz testing integrated with automotive test systems
•Automated test lab
•Software composition analysis to generate SBOM
•ALM/PLM integration
SDLC: software development lifecycle
OTA: over-the-air
SBOM: software bill of materials
ALM/PLM: application/product lifecycle management
Figure1.5 Three-stepactivityfromstandardsandregulationstoprocessandorganizational changestosolutions.
possibletoemployatechnicalsolutionthatconsistsofanautomatedfuzztestingtoolthat teststhetargetsystemandstorestheresultsofthetestsinalogfile.Thefuzztestingtool couldbeintegratedwithexistingautomotivetestsystemstoenableautomatedfuzztesting aspartofthetestprocess.
Someotherexamplesarechangestotheengineeringprocessbyincludingtestinginan automatedmannerandtheestablishmentofdedicatedsecurityteams.Thecorresponding technicalsolutionistocreateatestlabwhichthededicatedsecurityteamisresponsible for.Thetestlabshould,usingautomation,beusedtoperformseveraldifferenttypesoftesting,e.g.securityfunctionaltesting,sourcecode/binaryscans,vulnerabilityscanning,fuzz testing,andpenetrationtesting.Inaddition,thetestlabcouldbeusedtoallowthetarget systemtobetestedinmultipledifferentenvironments,suchasstandalone,incombination withothersystems,invariousstates,onvirtualplatformsetc.
Furthermore,theremaybenewprocessrequirementsforcybersecuritymonitoring, incidentresponse,andover-the-air(OTA)updates.Theseprocessrequirementsrequire technicalsolutionsbasedon,forexample,softwarecompositionanalysistoolstogenerate SBOMduringthereleasemanagementprocessandstoretherelevantdatainsome database.Forinstance,theSBOMgenerationcanbeintegratedwithALM/PLM(applicationlifecyclemanagement/productlifecyclemanagement)systemssothatitisclear exactlywhichcomponentorvehiclecontainswhatsoftwareandwhichversionsofthe software.Cybersecuritymonitoringservicesortoolsthatgivealertsonnewvulnerabilities canbeusedtoprovideinputtoanautomotivesecurityoperationscenter(SOC).Using theinformationstoredintheALM/PLMsystemsallowsfororganizationstoidentifythe impactofacertainnewlyidentifiedvulnerability.First,itisnecessarytoassesswhich softwareversionsareaffectedbytheidentifiedvulnerability,aswellastheexploitability andimpactofsaidvulnerability.Second,itispossibletoassesshowmanycomponentsor vehiclesareaffectedbythespecificvulnerabilitybyusingtheinformationstoredinthe ALM/PLMsystemstoknowexactlywhichcomponentsorvehiclescontainthevulnerable
8
1OverviewoftheCurrentStateofCybersecurityintheAutomotiveIndustry software.Third,basedonthenumberofaffectedcomponentsorvehiclesandtheseverity ofthevulnerability,anappropriateresponsecanbetaken,e.g.urgentlyprovidingan updatedsoftwarewhichincludesafix.TofulfilltheOTAupdateprocessrequirements,the organizationrequiresatechnicalOTAsolutionorservicetobeemployed.Asaresponse totheidentifiedvulnerability,theorganizationcanthenprovidethepatchedsoftware throughtheOTAsolutiontoreachasmanyvehiclesasfastaspossible.
Thesearejustacoupleofexamplesofwherestandards,regulations,bestpractices,and guidelinesleadtoprocessandorganizationalchangesthatfinallyrequirenewtechnical solutionstobedeployedinautomotiveorganizations.
1.3ResultsfromaSurveyonCybersecurityPracticesinthe AutomotiveIndustry
Thissectionpresentssomeresultsfromasurveyoncybersecuritypracticesintheautomotiveindustrytogetabetterunderstandingofthecommonchallengesautomotive organizationsarefacing.InFebruary2019,areportbasedonasurveyoftheautomotive industrycalled“SecuringtheModernVehicle:AStudyofAutomotiveIndustryCybersecurityPractices”[24]wasreleased.SynopsysandSAEInternationalcollaboratedto commissionthisindependentsurvey.Theobjectivewastounderstandthecurrentautomotiveindustry’scybersecuritypostureanditscapabilitytoaddresssoftwaresecurityrisks inherentinconnected,software-enabledvehiclesbasedondata.Uptothispoint,therehad beenagapthathadexistedfartoolong–thelackofdatatounderstandthecurrentstateof cybersecurityintheautomotiveindustry.ThePonemonInstitutewasselectedtoconduct thestudyandresearcherssurveyed593professionalsatautomanufacturersandpartssuppliersresponsibleforcontributingtoorassessingthesecurityofautomotivecomponents.
1.3.1SurveyMethods
ThetargetofthissurveywasITsecuritypractitionersandengineersintheautomotive industry.Toensurerelevantresponses,alltheparticipantsinthestudyarecontributing toorassessingthesecurityofautomotivecomponents.Atotalof15900participantswere selectedtoparticipateinaweb-basedsurvey.Allsurveyresponseswerecapturedduringa two-weekperiodfromJuly19,2019throughAugust3,2019.Initially,responsesfromatotal of677surveyswerereceived;however,screeningandreliabilitychecksledtotheremoval of84surveys.Thus,thefinalsampleusedforthisreportconsistedofresponsesfrom593 surveys,ora3.7%responserate.
Someadditionaldetailsabouttheparticipantsofthissurveyareprovidedwiththe followingpercentagebreakdownsasfollows.Regardingtheparticipants’currentposition withintheirorganization,thereisagoodmixofdifferentrolesandpositions,suchas SeniorExecutive/VP(3%),Director(12%),Manager(19%),Supervisor(11%),Engineer (15%),andTechnician(21%),amongothers.Itisworthnotingthatmorethanhalfof therespondentsholdengineerorhigher-rankedpositions.Exploringdeeperintothe organizationandtheprimarypersonthesurveyparticipantreportsto,shows,among others,ChiefInformationOfficer(23%),Head,ProductEngineering(21%),Head,DevOps
1.3ResultsfromaSurveyonCybersecurityPracticesintheAutomotiveIndustry
(15%),ChiefInformationSecurityOfficer(15%),andChiefTechnologyOfficer(9%). Further,theorganizationstheparticipantsbelongtoareheadquarteredinthefollowing regions:UnitesStates(60%),Europe(12%),Canada(10%),LatinAmericaincludingMexico (9%),Asia-Pacific(8%),andMiddleEastandAfrica(1%).Ascanbeseen,amajorityofthe respondentsareheadquarteredintheUnitedStates.Theorganizationsizesbasedonthe worldwideheadcountfortheparticipatingorganizationswerecapturedasfollows:fewer than5000(34%),5000–10000(31%),10001–25000(16%),25001–75000(11%),andmore than75000(8%).Thus,66%oftherespondentsbelongtoorganizationswithaworldwide headcountofmorethan5000employees.Finally,thetotalyearlyinvestmentonautomotivecomponentsecurityfortheseorganizationsintermsoftechnologies,personnel, andmanagedandoutsourcedservicesrangesfrom$1–$100000(2%),$100001–$250000 (9%),$250001–$500000(13%),$500001–$1000000(19%),$1000001–$2500000(23%), $2500001–$5000000(17%),$5000001–$10000000(9%),$10000001–$25000000(2%), $25000001–$50000000(3%),$50000001–$100000000(2%),andmorethan$100000000 (1%).Itisnoteworthythatmorethanhalfoftheparticipatingorganizationsspendmore than$1millionperyearonautomotivesecurity.
1.3.2ReportResults
Thecontentsoftheautomotiveindustrycybersecuritypracticesreportaredividedintofour sections,focusingonchallengesintherespectiveareasof organizationaltopics, technical areas, productdevelopmentandsecuritytestingpractices,andfinally supplychaintopics Examplesfromeachoftheseareasarebrieflypresentedasfollows.
1.3.2.1OrganizationalChallenges
Regardingorganizationalchallenges,52%oftherespondentssaythattheyareaware ofpotentialharmtodriversthatcouldbecausedbyinsecureautomotivetechnologies. Sixty-twopercentsaythatamaliciousorproof-of-conceptattackagainsttheautomotive technologiesorsystemsdevelopedbytheirorganizationsislikelyorverylikelyinthe next12months.However,thereisacriticaldisconnectintheorganizationssinceeven thoughthesecurityexpertswithintheseorganizationshaveconcernsaboutsecurity, only31%oftherespondentsfeelempoweredtoraisesuchconcernsuptheirchainof command.Thisbegsthequestion:Whydocybersecurityexpertsnotfeelempoweredto raisetheirconcerns?Onereasoncouldbethat30%oftheorganizationsdonothaveany establishedcybersecurityprogramorteam.So,thiscouldmeanthatevenifacybersecurity expertwantstoraiseacertainconcern,thereisnostructuredapproachonwhotoreport thisconcerntoand,evenifitisreported,thereisnodefinedprocesshowtohandlethe concern.BreakingdowntheresponsesbasedonOEMsandsuppliersshowsthatOEMsare generallybettersinceonly18%ofOEMsdonothaveanyestablishedcybersecurityprogram orteam.Incontrast,roughlytwooutoffivesuppliers(41%)donothaveanyestablished cybersecurityprogramorteam.Moreover,onereasonfororganizationsnothavingan establishedcybersecurityprogramorteamcouldbeduetothelackofnecessarycybersecurityresourcesandskills.Fifty-onepercentofrespondentssaythattheorganizationsdo notallocateenoughbudgetandhumanresourcestocybersecurity.Onaverage,thereare onlynineFTE(full-timeequivalent)perorganizationdedicatedtoproductcybersecurity
Technologiesposingthegreatestcybersecurityrisks.Source:Datafrom[24].
managementprograms.Furthermore,62%oftherespondentsbelievetheydonothavethe necessarycybersecurityskillsinproductdevelopment[24].
1.3.2.2TechnicalChallenges
Regardingthetechnicalchallenges,84%oftherespondentsstatethattheyareconcerned thatcybersecuritypracticesarenotkeepingpacewithchangingtechnologies.Inparticular,thethreemaintechnologiesthatposethegreatestcybersecurityrisk,asshownin Figure1.6,arerelatedtowirelessandautonomousdrivingtechnologies,suchasWi-Fi, Bluetooth(63%),telematics(60%),andself-driving(autonomous)vehicles(58%)[24]. Thesetechnologiesarealsodrivingthetrendsintheautomotiveindustryasexplained inChapter2.Moreover,thefamousJeephackpresentedattheBlackHatandDefcon conferencesin2015[25]focusedonexploitingvulnerabilitiesandsecurityissuesinthese technologies,namely,connectingremotelytothevehicleoverWi-Fiandtelematics(over acellularnetwork)andabusingassisteddriving(partiallyself-driving)functionality,e.g. theparkassistfunction.
Assoftwarecomplexitygrowstosupportnewtechnologies,andaswithanysoftware, itisevidentthattherewillbesoftwarebugsinautomotivesoftware.However,atechnical challengethat61%oftheorganizationsfaceisbeingabletoaddresscriticalsecurityvulnerabilitiesinatimelymannerthroughasoftwareupdatedeliverymodel.Forexample,only37% oftheparticipantsstatethattheirorganizationsprovideOTAcapabilitiestodeliversecurity patchesandupdates.Last,sinceorganizationsapplysecuritysolutionstotheirautomotive systems,andsincethesesecuritysolutionsoftenrelyoncryptographicalgorithms,thereis astrongneedformanagementofcryptographickeys,includingthegeneration,exchange, storage,useandreplacementofkeys.While56%oftherespondentsansweredthattheir organizationsusecentralkeymanagementsystems,achallengeisthat43%oftheparticipantssaythattheirorganizationsuseamanualprocess,includingspreadsheetsand paper-basedapproaches,whichlimitstheusefulnessofcryptographickeysandhampers security[24].
Figure1.7 Overviewofwhensecurityassessmentsoccurinthedevelopmentlifecycle.Source: Datafrom[24].
1.3.2.3ProductDevelopmentandSecurityTestingChallenges
Intermsofthechallengesregardingproductdevelopmentandsecuritytesting,only47%of theorganizationssaythattheyperformsecurityassessmentsoftheirproductsearlyinthe productreleaseprocess,namelyinthe“requirementsanddesign,”and“developmentand testing”phases.Thus,theresultsshowthatamajorityoftheorganizationsassessvulnerabilitiestoolateintheprocesssuchasafterrelease,afterintegration,orpostproduction release.ThisfactisillustratedinFigure1.7.
Testingforvulnerabilitieslateinthedevelopmentlifecycleisoftenalsoverycostly,as providingfixestoidentifiedcriticalissuesmayrequireredesignormajorchangestothe targetsystem.Itisimportanttonotethatanestablishedbestpracticeistousearisk-based, process-drivenapproachtocybersecuritythroughouttheentireproductdevelopmentlifecycle.Thesurveyalsoshowsthat63%oftheorganizationstestlessthanhalfoftheirhardware,software,andothertechnologiesforvulnerabilities.Evenmoresurprisingisthat25% oftheorganizationsdonotperformanycybersecuritytestingatalloftheirautomotive softwareandsystems.Onemainreasonfororganizationsnotperformingcybersecuritytestingcouldbethatasecuresoftwaredevelopmentlifecycle(SSDLC)process,whichdefines thecybersecurityactivitiesisnotfollowed.Ascanbeseenfromthesurvey,36%ofthe organizationsdonotfollowanSSDLCprocess.Investigatingfurtherthemaincausesfor vulnerabilitiesinautomotivesoftwareandsystems,thesurveyrevealsthattheprimaryfactorsthatleadtovulnerabilities,showninFigure1.8,includethepressuretomeetdeadlines (71%),lackofsecurepracticesfor coding (60%)andaccidental coding errors(55%),lackof proceduresfor testing (50%),andtheuseofinsecure open-sourcesoftware (40%).Inaddition, while60%oftherespondentssaythatalackofunderstandingortrainingonsecurecodingpracticesisaprimaryfactorthatleadstovulnerabilities,only33%oftheorganizations educatetheirdevelopersonsecurecodingmethods[24].
Thus,tosummarize,thetopthreeprimaryfactors–besidesthepressuretomeetdeadlines–arerelatedto coding, testing,and open-sourcesoftware
1.3.2.4SupplyChainandThird-PartyComponentsChallenges Regardingchallengesforsupplychainandthird-partycomponents,73%oftherespondentsansweredthattheyareveryconcernedaboutthecybersecuritypostureofautomotive
Pressure to meet product deadlines
Lack
Accidental coding errors
Lack of
Figure1.8 Primaryfactorsthatleadtovulnerabilitiesinautomotivesystems.Source:Data from[24].
technologiessuppliedbythirdparties.OEMsoftenintegrateanumberofdifferentsystems frommultiplesuppliers,whointurnintegratevariousthird-partycomponents,software, communicationstacks,andapplications,whichmayincludevulnerabilitiesthattheOEMs needtobeawareofandbereadytohandle.Thus,vulnerabilitiesinthecomplexautomotivesupplychainpresentamajorrisk.Moreover,68%oftheparticipantsareveryconcerned aboutthecybersecuritypostureoftheindustryasawhole.Inaddition,56%oftheorganizationsdonotimposecybersecurityrequirementsontheproductsprovidedbytheirsuppliers. Evenfortheorganizationsthatdoprovidecybersecurityrequirementstotheirsuppliers, 40%ofthemhavenodefinedformalprocesstoverifythatthesuppliersactuallyadhereto theprovidedsecurityrequirements.Instead,51%oftheorganizationsrelyonthesuppliers toperformself-assessmentsandsubsequentlyproviderelevantartifactsforverificationand validationthatthesuppliershavefulfilledthereceivedrequirements[24].
1.3.3HowtoAddresstheChallenges
Basedontheresultsfromthesurveyoncybersecuritypracticesintheautomotiveindustry presentedinSection1.3.2,thissectionhighlightsmajortakeawaysforautomotiveorganizationstoaddresstheidentifiedchallenges.Relevanttakeawaysforeachofthefourcategories, namelyorganizationaltopics,technicalareas,productdevelopmentandsecuritytesting practices,andsupplychaintopicsarepresented.
1.3.3.1OrganizationalTakeaways
Themaintakeawaysfromtheorganizationalchallengesare,first,foranautomotiveorganizationtoensurethatcybersecurityismadeaprioritywithintheorganization.Itisa necessitythattheorganizationhasaformalleaderwhoisdrivingtheinternalcybersecurityactivities,e.g.aCISO(ChiefInformationSecurityOfficer)orVPofCybersecurity inaleadershiprole.Thisleadersendsthemessageintheorganizationthatcybersecurity priorityistop-downandthereforeempowersthesecurityexpertsintheorganizationto
speakupiftheyrecognizeanysecurityconcerns.Second,itisimportantthatorganizations establishacybersecurityprogramorteamthatisresponsibleforestablishinginternalcybersecurityprocesses,creatingguidelines,andensuringandenforcingcompliancewithinthe organization.Third,itisimperativethattheorganizationshavethenecessarycybersecurityresourcesinplace,whichincludeshiringmorepeoplewithrelevantcybersecurityskills, offeringcybersecuritytrainingtoexistingstaff,includingsecurecodingpracticeseducation fordevelopers,andpreparingmorebudgetforcybersecurityactivitiestoallowtheorganizationstoacquirenecessarycybersecurityresources,equipment,andtools.
1.3.3.2TechnicalTakeaways
Themaintakeawaysfromthetechnicalchallengesare,first,fororganizationstoput increasedsecurityfocuson,inparticular,thehigh-risktechnologyareas,namely self-driving(autonomousandADAS)technologies,andremotewirelesscommunication interfacesincludingWi-Fi,Bluetooth,andtelematics.Second,organizationsmusthavethe understandingthatsoftwarebugsandvulnerabilitieswillbedetectedintheirautomotive systemsaftervehicleshavebeenreleasedandthatsuchvulnerabilitiesneedtobeaddressed inatimelymanner.Therefore,organizationsmustpreparetechnicalsolutionstoallow OTAsoftwareupdatesandsecuritypatchesinasecuremanner.Third,asorganizations aredeployingmoresecuritysolutionsinautomotivesystems,andconsequentlymore cryptographickeysarerequiredtokeepsuchsystemssecure,itisimperativethatautomotiveorganizationsavoidmanualprocessesforkeymanagementandinsteademploybest practicesincludingtheusageofsecurekeymanagementsystems.
1.3.3.3ProductDevelopmentandSecurityTestingTakeaways
Themaintakeawaysfromthechallengesregardingproductdevelopmentandsecuritytestingare,first,fororganizationsto shiftleft andsystematicallyassessrisksandvulnerabilities intheearlyphasesofdevelopmentincludingtherequirements,concept,design,anddevelopmentphases.Byconducting,forexample,properrequirementsreviews,designreviews, andthreatanalysisandriskassessments,anorganizationcanbuildinsecuritybyincorporatingtheappropriatesecuritycontrolsearlyintherequirementsanddesigns.Second, itisimportantthatautomotiveorganizationsemployandfollowadefinedSSDLCprocess byapplyingappropriatesecurityactivitiesateachstepinthedevelopmentlifecycle.This includes,forexample,definedprocedures,securitymeasuresandactivitiestoaddress coding, testing,andtheuseof open-sourcesoftware,whichareamongtheprimaryfactorsthat leadtovulnerabilities.Thiscouldalsoincludeasecuritygatetoensurethattheautomotive softwareistestedbeforeitisshipped.Third,toalleviatethepressuretomeetdeadlines, whichisconsideredthetopfactorleadingtovulnerabilities,itisimperativetoimproveefficiencyandautomationusingautomatedtools.Thus,itisrecommendedthatautomotive organizationsuseautomatedtoolsasmuchaspossibleaspartoftheprocess.Inparticular, suchtoolscanhelporganizationsdetectvulnerabilitiesinthesoftwareduringcoding,identifyvulnerableopen-sourcesoftware,anddetectvulnerabilitiesbyperformingautomated securitytesting.
1.3.3.4SupplyChainandThird-PartyComponentsTakeaways
Themaintakeawaysforthesupplychainandthird-partycomponentschallengesare, first,forautomotiveorganizationstostartprovidingdownstreamsecurityrequirements.
1OverviewoftheCurrentStateofCybersecurityintheAutomotiveIndustry
ItisimperativethattheOEMs,whoareatthetopofthesupplychain,createandprovide relevantsecurityrequirementstotheirsuppliers.Thereshouldbebothprocess-level requirementsandproduct-levelrequirements.Theprocess-levelrequirementsshould includerequirementsontheprocessesandproductdevelopment,e.g.requiringsuppliers tousecertaintypeofapproachesortoolstotestforvulnerabilities.Theproduct-level requirementswouldbeproduct-specificrequirements,e.g.arequirementfordevice authenticationorstorageofsecretkeysontheautomotivesystem.Thesetypesofsecurity requirements,iftheyarenotapplicableforthesupplierinquestion,shouldthenbepassed onfromthetier1suppliertothetier2supplierandsoon.Second,onceasupplierprovides aproductupstream,thereceivingorganizationshouldhaveanestablishedprocessfor enforcingandverifyingthatthesupplierhasadheredtotheprovidedsecurityrequirements.Therearevariousapproachesforconductingthistypeofassessment.Forinstance, thesuppliercanperformaself-assessmentandprovidethenecessaryartifacts,including documents,testresults,logfiles,reports,etc.,alongwiththedeliverabletoprovide assurancethattherequirementshavebeenmet.Alternatively,thereceivingorganization canperformtheassessmentbyrunningvarioustestsonthereceivedautomotivesystem orgoingonsitetothesuppliertoperformasupplieraudit.Furthermore,theassessments couldalsobeperformedbyanindependentthirdpartythatteststheproductorreviews thenecessaryprocesses,documents,andreportsfromthesupplier.Regardlessofthetype ofassessment,ultimately,thegoalistoprovideassurancethatthedeliverablefulfillsthe providedsecurityrequirements.Third,sincetheuseofvulnerableopen-sourcesoftware componentsisoneoftheprimaryfactorsleadingtovulnerabilitiesinautomotivesystems, itisimperativethatautomotiveorganizationshaveanestablishedprocessforconducting open-sourcesoftwaremanagement.Mainly,thismeansthatorganizationsshouldknow whatopen-sourcesoftwarecomponentstheyareincludingintheirautomotivesystems, whichversionsofthesoftwareareincludedandwhattheassociatedknownvulnerabilities ofthosesoftwareversionsare.Moreover,asaside-noteasthisisnotdirectlyrelatedto cybersecurity,fromalegalperspectiveconsideringopen-sourcelicensecompliance,itis importantthatorganizationsalsoknowwhattheassociatedopen-sourcesoftwarelicenses areinordertobeawareofpotentiallegalrisks[26].
1.3.3.5GettingStarted
Althoughtheabove-mentionedtakeawaysaregeneralinnaturetoaddressthemajorconcernsoutlinedintheautomotivesurvey,itisimperativethatanorganizationconsiderswhat approachesandsolutionsareappropriatefortheirorganization.Tothisend,anorganizationmayproceedwiththefollowingsimplefourstepsillustratedbyfindingatreasureona treasuremapinFigure1.9togetstarted:
(1)Understandwhereyouare;
(2)Identifywhereyouwanttogo;
(3)Mapoutthewaytogothere;
(4)Startthejourneyandtracktheprogress.
Thefirststepisfortheorganizationtounderstandwheretheyare,i.e.thecurrentstate. Thisstepincludesorganizingallinternalrelevantprocessdocuments,requirementsdocuments,organizationalcharts,rolesandresponsibilitiescharts,securitymethodologiesand