1、 _ SAE Technical Standards Board Rules provide that: “This report is published by SAE to advance the state of technical and engineering sciences. The use of this report is entirely voluntary, and its applicability and suitability for any particular use, including any patent infringement arising ther
2、efrom, is the sole responsibility of the user.” SAE reviews each technical report at least every five years at which time it may be revised, reaffirmed, stabilized, or cancelled. SAE invites your written comments and suggestions. Copyright 2016 SAE International All rights reserved. No part of this
3、publication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of SAE. TO PLACE A DOCUMENT ORDER: Tel: 877-606-7323 (inside USA and Canada) Tel: +1 724-776-49
4、70 (outside USA) Fax: 724-776-0790 Email: CustomerServicesae.org SAE WEB ADDRESS: http:/www.sae.org SAE values your input. To provide feedback on this Technical Report, please visit http:/www.sae.org/technical/standards/J3061_201601 SURFACE VEHICLE RECOMMENDED PRACTICE J3061 JAN2016 Issued 2016-01 C
5、ybersecurity Guidebook for Cyber-Physical Vehicle Systems RATIONALE To provide a cybersecurity process framework and guidance to help organizations identify and assess cybersecurity threats and design cybersecurity into cyber-physical vehicle systems throughout the entire development lifecycle proce
6、ss. Defines a complete lifecycle process framework that can be tailored and utilized within each organizations development processes to incorporate cybersecurity into cyber-physical vehicle systems from concept phase through production, operation, service, and decommissioning. Provides high-level gu
7、iding principles. Provides information on existing tools and methods. Provides the foundation for further standards development. TABLE OF CONTENTS 1. SCOPE . 5 1.1 Purpose 6 1.2 When to Apply a Cybersecurity Process 6 2. REFERENCES . 6 3. DEFINITIONS AND ACRONYMS 8 4. RELATIONSHIP BETWEEN SYSTEM SAF
8、ETY AND SYSTEM CYBERSECURITY 17 4.1 Analogies between System Safety and System Cybersecurity Engineering . 18 4.2 Unique Aspects of System Safety and System Cybersecurity 18 5. GUIDING PRINCIPLES ON CYBERSECURITY FOR CYBER-PHYSICAL VEHICLE SYSTEMS (CPS) . 20 5.1 Know Your Systems Cybersecurity Poten
9、tial 20 5.2 Understand Key Cybersecurity Principles 20 5.3 Consider the Vehicle Owners Use of the System . 21 5.4 Implement Cybersecurity in Concept and Design Phases . 21 5.5 Implement Cybersecurity in Development it is up to an organization to determine what is considered low risk and whether low
10、risk safety-related threats need to be addressed. To help ensure that all potential safety-related threats are considered, the Cybersecurity experts should communicate with the safety experts. Note that the basis of decision for following the process is on the identified potential risk of the identi
11、fied safety-related threats rather than on whether a corresponding potential hazard is ASIL rated (A, B, C, or D). This is because the threat risk for a safety-related threat may be low, while the corresponding hazard may be assessed a high ASIL; there is no direct correspondence between an ASIL rat
12、ing and the potential risk associated with a safety-related threat. 2. REFERENCES 1. ISO 26262 Part 8 First Edition, “Supporting Processes, Road Vehicles Functional Safety”, 11-15-2011. 2. Barbara J. Czerny. “System Security and System Safety Engineering: Differences and Similarities and a System Se
13、curity Engineering Process Based on the ISO 26262 Process Framework”, SAE Technical Paper 2013-01-1419, SAE World Congress and Exhibition, 2013. 3. B. Potter. Microsoft SDL Threat Modelling Tool. In: Network Security 2009.1 (2009), pp. 1518. ISSN: 1353-4858. DOI:http:/dx.doi.org/10.1016/S1353-4858(0
14、9)70008-X. URL: http:/ (cit. on p. 37). 4. Ivn Arce, Kathleen Clark-Fisher, Neil Daswani, Jim DelGrosso, Danny Dhillon, Christoph Kern, Tadayoshi Kohno, Carl Landwehr, Gary McGraw, Brook Schoenfield, Margo Seltzer, Diomidis Spinellis, Izar Tarandach, and Jacob West. “Avoiding the Top 10 Software Sec
15、urity Design Flaws”, IEEE Computer Society, 2014. SAE INTERNATIONAL J3061 JAN2016 Page 7 of 128 5. Global Alliance, Global Automakers, “Consumer Privacy Protection Principles for Vehicle Technologies and Services”, November 12, 2014. 6. NIST, SP 800-88, Revision 1, “Guidelines for Media Sanitization
16、”, December, 2014. 7. ISO/IEC 15408 “Information Technology Security Techniques Evaluation Criteria for IT Security”, (3 Parts). 8. NIST, Version 1, “Framework for Improving Critical Infrastructure Cybersecurity”, February 12, 2014. 9. NIST SP 800-53, Revision 4, “Security and Privacy Controls for F
17、ederal Information Systems and Organizations”, April 2014. 10. FIPS Pub 199. “Standards for Security Categorization of Federal Information and Information Systems”, February 2004. 11. ISO (International Organization for Standardization). “ISO 12207 - Systems and Software Engineering - Software LifeC
18、ycle Processes”, 2008. 12. ISO (International Organization for Standardization). “ISO/IEC 27001: - Information technology - Security techniques - Information security management systems - Requirements“. International Organization for Standardization. 27 January 2015. 13. ISO (International Organizat
19、ion for Standardization). “ISO/IEC 27002: Information Technology - Security Techniques. Code of Practice for Information Security Controls” 2008. 14. ISO (International Organization for Standardization). “ISO/IEC 29119: The International Software Testing Standard”, September 10, 2014. 15. NIST 800-6
20、1 Revision 2, “Computer Security Incident Handling Guide”, August 2012. 16. NIST Special Publication 800-30 Revision 1, “Guide for Conducting Risk Assessments”, September 2012. 17. Chrysler Corporation, Ford Motor Company, General Motors Corporation, QS 9000 Third Edition, “Quality System Requiremen
21、ts”, October 1998. 18. ISO/TS 16949:2009 “Quality Management Systems” December 2008. 19. Ruddle, Alastair, Ward, David, et al, EVITA Project Deliverable D2.3: “Security requirements for automotive on-board networks based on dark-side scenarios” Version 1.1, 30 December 2009. 20. EVITA deliverable D2
22、.1: “Specification and evaluation of e-security relevant use cases”, 2009. 21. Woody, Carol. “Applying OCTAVE: Practitioners Report.” Software Engineering Institute, May 2006. 22. Caralli, Richard, James Stevens, Lisa Young, and William Wilson. “Introducing OCTAVE Allegro: Improving the Information
23、Security Risk Assessment Process.” Software Engineering Institute, May 2007. 23. M. Islam et al., Deliverable D2 Security models. HEAVENS Project, Deliverable D2, Release 1. Dec. 2014. 24. ISO (International Organization for Standardization). Road vehicles - Functional safety ISO 26262:2011. (cit. o
24、n pp. 17, 30, 40, 42, 44). 25. BSI-Standard 100-4, Version 1.0, 2009, Federal Office for Information Security (BSI), Germany. 26. Automotive Industry Action Group (AIAG), “Potential Failure Mode and Effects Analysis (FMEA)”, 2008. 27. “Privacy Impact Assessment Guideline”, 2011, Federal Office for I
25、nformation Security (BSI), Germany. SAE INTERNATIONAL J3061 JAN2016 Page 8 of 128 28. ISO (International Organization for Standardization). Road vehicles - Functional safety - Part 3: Concept phase (ISO 26262-3:2011). ISO 26262-3:2011. 2011 (cit. on p. 18). 29. Schneier, Bruce, “Secrets and Lies Dig
26、ital Security in a Networked World”, Wiley, ISBN 978-0-471-45380-2. 30. Amer Aijaz1, Bernd Bochow2, Florian Dotzer3, Andreas Festag4, Matthias Gerlach2, Rainer Kroh5 and Tim Leinmuller5 , “Attacks on Inter Vehicle Communication Systems an Analysis”. 31. http:/www7.informatik.uni-erlangen.de/dulz/fko
27、m/06/Material/11/Security/NOW_TechReport_Attacks_on_Inter_Vehicle_Communications.pdf. 32. Avizienis A, Laprie J-C, Randell B, Lanwehr C, “Basic Concepts and taxonomy of Dependable and Secure Computing”, IEEE Transactions on independent and Secure Computing”. January-March 2004. 33. MITRE Corporation
28、, “Common Weakness Enumeration, A Community Developed Dictionary for Software Weakness Types “,2006 -2014, http:/cwe.mitre.org/. 34. MITRE Corporation, “Common Vulnerabilities and Exposures ”, 1999-2014, https:/cve.mitre.org/cve/index.html. 35. Security Focus, BugTraq, 2010, http:/ 36. NIST, Nationa
29、l Vulnerability Database, http:/nvd.nist.gov/. 37. MITRE Corporation, Common Weakness Scoring System, 2006-2014, http:/cwe.mitre.org/cwss/cwss_v1.0.1.html. 38. NIST, Common Vulnerability Scoring System, http:/nvd.nist.gov/cvss.cfm. 3. DEFINITIONS AND ACRONYMS 3.1 API Application Programming Interfac
30、e 3.2 ASF - Application Security Frame Threat categorization tool that determines threats based on system break down methodology. 3.3 ASIL - Automotive Safety Integrity Level A means of classifying hazards in ISO 26262. 3.4 ATTACK POTENTIAL The likelihood that a potential attack can be successfully
31、carried out. 3.5 ATTACK SURFACE The different points (the “attack vectors“) where an unauthorized user (the “attacker“) can try to enter data to or extract data from an environment. 3.6 ATTACK TREE ANALYSIS (ATA) An analysis method to determine the potential paths that an attacker could take through
32、 the system to lead to the top level threat. SAE INTERNATIONAL J3061 JAN2016 Page 9 of 128 3.7 BLACK BOX TESTING Testing where nothing formal is known about the system being tested. No specifications, hardware information, software code, etc. are provided during the testing. 3.8 CAN - Controller Are
33、a Network A serial communication network. The following standards provide the specifics associated with the CAN protocol and some of its automotive variants: SAE J1939, SAE J2411, ISO 11898, ISO 15765-2. 3.9 CERT C Secure coding standard for C, C+, Java and Pearl. Developed by the CERT coding initia
34、tive team. 3.10 CPU - Central Processing Unit The part of a computer system (a microcontroller) that performs the computers main functions and controls parts of the system. 3.11 COMMON VULNERABILITY ENUMERATION (CVE) CVE is designed to allow vulnerability databases and other capabilities to be linke
35、d together, and to facilitate the comparison of security tools and services. 3.12 COMMON VULNERABILITY SCORING SYSTEM (CVSS) Scoring system for vulnerabilities. 3.13 COMMON WEAKNESS ENUMERATION (CWE) The CWE is a “formal list of software weakness types” hosted by MITRE cooperation. 3.14 COMMON WEAKN
36、ESS SCORING SYSTEM (CWSS) Is a scoring system that may help stakeholders concerned with software security - to assess and where applicable - prioritize reported software weakness. 3.15 CYBER-ATTACK An assault on system Cybersecurity that derives from an intelligent act, i.e., an intelligent act that
37、 is a deliberate attempt (especially in the sense of a method or technique) to evade Cybersecurity services and violate the Cybersecurity policy of a system. 3.16 CYBER-PHYSICAL SYSTEM (CPS) A system of collaborating computational elements controlling physical entities. 3.17 CYBER-PHYSICAL VEHICLE S
38、YSTEM (CPAS) Vehicle embedded control systems where there exists a tight coupling between the computational elements and the physical elements of the system and the environment around the system. 3.18 CYBERSECURITY Measures taken to protect a cyber-physical system against unauthorized access or atta
39、ck. SAE INTERNATIONAL J3061 JAN2016 Page 10 of 128 3.19 CYBERSECURITY ASSESSMENT An assessment of the level of Cybersecurity of a feature that will be refined throughout the development process and provides appropriate arguments and evidence to support Cybersecurity claims at each stage of developme
40、nt. The Cybersecurity assessment is reviewed at each of the major milestones. 3.20 CYBERSECURITY CASE The final Cybersecurity Assessment after all milestone reviews have been completed and before the feature can be released for production. The Cybersecurity case provides the final argumentation and
41、evidence that the feature as designed and developed satisfies its Cybersecurity goals. 3.21 CYBERSECURITY CONCEPT Developed in the concept phase to describe the high-level Cybersecurity strategy for the feature. The Cybersecurity concept will be refined to a technical Cybersecurity concept during pr
42、oduct development at the system level. 3.22 CYBERSECURITY CONTROLS The management, operational, and technical controls (e.g., safeguards or countermeasures) prescribed for a feature to eliminate potential vulnerabilities or to reduce the likelihood that a vulnerability will be exploited. 3.23 CYBERS
43、ECURITY-CRITICAL A system where losses could occur in cyber-physical systems due to vulnerabilities in the system that could be exploited either directly or indirectly by an outside entity. 3.24 CYBERSECURITY GOALS The goals for achieving Cybersecurity for the feature determined from the threat anal
44、ysis and risk assessment results. These are the highest level Cybersecurity requirements that will drive the development and refinement of functional and technical Cybersecurity requirements. 3.25 CYBERSECURITY MECHANISM Technical Cybersecurity control added to the feature to eliminate potential vul
45、nerabilities or to reduce the likelihood that a vulnerability will be exploited. 3.26 CYBERSECURITY POTENTIAL The level of risk or likelihood that something may happen. 3.27 CYBERSECURITY PROGRAM PLAN Defines responsibilities for planning and overseeing the Cybersecurity activities. 3.28 CYBERSECURI
46、TY REVIEW A review, possibly conducted by a small team of technical reviewers, to assess the technical aspects of the work products during the various stages of the development process. 3.29 DIS Draft International Standard SAE INTERNATIONAL J3061 JAN2016 Page 11 of 128 3.30 DOD Department of Defens
47、e 3.31 DREAD - Damage Reproducibility Exploitability Affected users and Discoverability Threat categorization tool that determines threats based on system break down methodology. 3.32 DVD - Digital Video Disc A device with high storage capacity of information. 3.33 ECU - Electronic Control Unit A mo
48、dule that provides a function to the vehicle. 3.34 ETHERNET A serial communication network. 3.35 ETSI European Telecommunications Standards Institute 3.36 EVITA - E-safety Vehicle Intrusion protected Applications A project initiated by the European Community from 2007 through 2013. Primarily to desi
49、gn, verify and prototype Cybersecurity building blocks for vehicle on-board networks. 3.37 FEATURE System or an array of systems to implement a function at the vehicle level to which a Cybersecurity process for cyber-physical vehicle systems is applied. 3.38 FAULT TREE ANALYSIS (FTA) A deductive ana
