Towards a Standardized Mapping from Automotive Security Levels to Security Mechanisms
Total Page:16
File Type:pdf, Size:1020Kb
Towards a Standardized Mapping from Automotive Security Levels to Security Mechanisms Downloaded from: https://research.chalmers.se, 2021-09-28 23:19 UTC Citation for the original published paper (version of record): Rosenstatter, T., Olovsson, T. (2018) Towards a Standardized Mapping from Automotive Security Levels to Security Mechanisms IEEE Conference on Intelligent Transportation Systems, Proceedings, ITSC: 1501-1507 http://dx.doi.org/10.1109/ITSC.2018.8569679 N.B. When citing this work, cite the original published paper. research.chalmers.se offers the possibility of retrieving research publications produced at Chalmers University of Technology. It covers all kind of research output: articles, dissertations, conference papers, reports etc. since 2004. research.chalmers.se is administrated and maintained by Chalmers Library (article starts on next page) Towards a Standardized Mapping from Automotive Security Levels to Security Mechanisms Thomas Rosenstatter Tomas Olovsson Department of Computer Science and Engineering Department of Computer Science and Engineering Chalmers University of Technology Chalmers University of Technology Email: [email protected] Email: [email protected] Abstract—Modern vehicles are becoming targets and need to requirements. Currently missing in proposed models is how be secured throughout their lifetime. There exist several risk to select required security mechanisms for each component assessment models which can be used to derive security levels and function based on the security level when following that describe to what extent components, functions and messages (signals), need to be protected. These models provide methods the risk assessment process. In this paper, we address this to gather application specific security requirements based on problem by first suggesting that the risk assessment process identified threat and item combinations that need to be coped should result in five security levels, similar to the Automotive with. However, a standardized mapping between security levels Safety Integrity Levels (ASILs) and, when needed, a set and required mandatory security mechanisms and design rules of specific security requirements for that particular function. is currently missing. We address this problem first by suggesting that the risk assessment process should result in five security Fig. 1 provides an overview and puts our work into context. levels, similar to the functional safety standard ISO 26262. We believe the proposed methodology can show the way Second, we identify suitable security mechanisms and design rules towards a possible future automotive security standard similar for automotive system design and associate them with appropriate to ISO 26262 used in automotive safety. The proposed method- security levels. Our proposed methodology is as much as possible ology is realistic to deploy in existing organizations, as it is aligned with ISO 26262 and we believe that it should therefore be realistic to deploy in existing organizations. aligned with safety design methodologies which are already in place. In addition, having distinct requirements for security I. INTRODUCTION design allows the classification of components, including third- Computer and network security became more and more party designs, and enables us to know how robust and secure important as the number of interconnected devices spread. We the design is and to what extend it can be trusted by other now face similar challenges in the ongoing transition towards components. the Internet of things, industry 4.0 and smart connected vehi- We emphasize that we are focusing on mechanisms to cles. Constraints, such as low computational power, low energy be deployed in vehicles rather than traditional information consumption and real time reaction, are major challenges that systems, which is covered by the ISO 27000 family [7]. The limit the range of applicable security mechanisms and design contributions of this paper are as follows: rules. Back in 2011, Checkoway et al. provided a detailed a We propose a set of suitable mandatory security mech- analysis of the attack surface of vehicles including attacks via anisms and design rules for the automotive domain. the Tire Pressure Monitoring System and the media player [1]. a We suggest a framework for mandatory security mecha- Furthermore, Miller and Valasek have demonstrated several nisms that should be required for specific security levels. vulnerabilities that lead to attacks against vehicles that could a We motivate the proposed method with an automotive be performed remotely in 2015 [2]. use case. There is currently no standard similar to the functional safety standard ISO 26262 [3] for security in the automotive II. BACKGROUND AND RELATED WORK domain. The ISO work item ISO/SAE AWI 21434 Road The Cybersecurity Guidebook for Cyber-Physical Vehicle Vehicles – Cybersecurity engineering is currently under de- Systems, SAE J3061 [5], provides guidance for threat iden- velopment and is planned to address threat modeling and risk tification and assessment, and guidance for security in the assessment. Proposed security models, such as Microsoft’s development process. HEAVENS [6] and EVITA [8] are two STRIDE threat model [4], SAE J3061 [5] and the HEAVENS Threat Analysis and Risk Assessment (TARA) models also model [6], describe how to identify items that need to be referred to in SAE J3061, which result in security levels secured, perform the threat analysis and result in security and methods for how to specify security requirements for levels for components and functions in a vehicle. HEAVENS identified threats. Later in this paper, we apply the HEAVENS additionally describes a method for deriving item specific model to our automotive use case, to identify security relevant Selection of security mechanisms SL 1 SL 2 SL 3 SL 4 Logical Separation ● ● ● TARA Classification Message Auth. ● ● Item Threat Knowledge ... Message Integrity ● ● ● ● Braking Spoofing Standard ... low Watchdog Braking Tampering Restricted ... medium ● ● ● Speed Spoofing Standard ... high ... ... ... ... critical Derive specific requirements Technical Security Requirements Analysis of the system according to a security model, such as HEAVENS, STRIDE, EVITA, or NIST FIPS PUB 199 for informations systems. Hardware Security Software Security Requirements Requirements Fig. 1: Overview of the steps from performing Threat Analysis and Risk Assessment (TARA) to requirement engineering. items, i.e., functions, components and messages (signals), and III. SECURITY MECHANISMS AND DESIGN RULES classify their security needs. The resulting security levels constitute of six elements representing the security attributes mitigating the STRIDE threats: integrity, authenticity, non- Security mechanisms are used to mitigate threats and to repudiation, confidentiality, availability, and authorization. minimize the risk of security attributes of an item being IEC 62443 [9], a security standard for industrial communi- violated. Table I shows the mapping between the STRIDE cation networks, performs a similar mapping between system threats and the corresponding security attributes, including requirements and security levels. IEC 62443 is not entirely an explanation from HEAVENS [6, p.6]. In Table I we applicable for the automotive domain due to the focus on the additionally associate the STRIDE threats with item types to human operation of industrial automation systems. emphasize the threats violating the security attributes related to The NIST FIPS PUB 199 [10], Standards for Security these types. For example, mechanisms that mitigate all types Categorization of Federal Information and Information Sys- of threats are necessary in order to properly protect messages tems, describes a security classification for information sys- or signals – the information flow. tems using confidentiality, integrity, and availability with each The benefits of having a direct relation between STRIDE having three levels, low, moderate and high. Additionally, the and security attributes is that any threat assessment model NIST special publication SP 800-53 [11], Security and Privacy can be used to derive required mandatory security require- Controls for Federal Information Systems and Organizations, ments provided a mapping to STRIDE exists. For example, contains security mechanisms for information systems. The a mapping of the CIA model in [10] to STRIDE is also work in the Connected Vehicles Pilot Development Phase 1 - possible, however, the desired granularity decreases due to Security Management Operating Concept – New York City [12] the aggregation of security attributes. A proposed mapping follows both, the NIST FIPS PUB 199 and NIST SP 800- between security levels and identified mechanisms is provided 53, and identifies safety and privacy requirements for specific in Table II. For some identified design rules and mechanisms, usage scenarios and further divides these requirements in it is favorable to divide them into different classes repre- information flow and device classes. As many of the NIST SP sented as numbers instead of dots in the table describing the 800-53 security controls are not appropriate for the automotive requirements in more detail. For instance, the requirement domain, the identified security requirements in this project do AU.3 Verify authenticity of firmware/functions on start has not cover the requirements for the automotive domain in depth. class 1 on demand verification of modules and a stricter class 2 The United