Makoto Kayashima, Nobutaka Kawaguchi, Kota Ideguchi, Nobuyoshi Morita
©SHUTTERSTOCK.COM/NONGASIMO
To counter increasing threats of cyberattacks on automobiles, it is important to practice “secure by design.” For this reason, the regulations and standards that require a risk-based security design are being formulated in the automotive industry. In the concept phase described in ISO/SAE21434:2021, it is necessary to determine cybersecurity controls based on results of the threat analysis (TA) and the risk assessment (RA). On the other hand, the National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF) defines four categories of cybersecurity controls: protection, detection, response, and recovery demand to select cybersecurity controls from these categories. To be able to formulate appropriate cybersecurity control for detection, this article proposes an extension of the threat analysis and risk assessment (TARA) based on Japanese Automotive Standards Organization (JASO) TP15002:2016 to derive candidate monitoring points (MPs) to implement detection functions. We also present evaluation metrics for the MPs derived by our proposed method and discuss future research directions.
Connected cars, autonomous driving, sharing, and electrification disruptions have continued, increasing the threats of cyberattacks. In 2010, Koscher et al. conducted one of the first comprehensive experiments that demonstrate the vulnerability and weakness of modern vehicles against cyberthreats, which could result in serious accidents and injuries [1]. Since then, researchers have presented case studies about automotive security [2]. To respond to the threat of cyberattacks on automobiles, a new worldwide regulation was formulated in the United Nations Economic Commission for Europe WP.29 [3], and the international standard ISO/SAE21434 [4] supporting compliance with the regulation was published. Under the regulation of WP.29, automobile manufacturers should execute “risk-based security design” in their development processes, and appropriate security measures commensurate with the identified risks must be implemented.
To realize risk-based security design, we must identify threats that should be considered in the target system and evaluate the risks of each threat. Then we derive the cybersecurity controls according to risk values of the threats. As the NIST CSF [5] suggests, cybersecurity controls include not only protection but also detection, response, and recovery controls. These cybersecurity measures need to be appropriately selected based on the TA and the RA.
Regarding detection capabilities, Abdul et al. have proposed a detection approach to detect intrusion attacks using convolutional neural networks and attention-based gated recurrent units for communication between in-vehicle nodes [6]. Also, Abdul et al. have proposed an anomaly detection method that uses data streams to detect anomalies in in-vehicle systems [7]. In addition to these studies, various mechanisms for attack detection in in-vehicle systems have been proposed, including those based on anomaly detection [8] and those using signatures [9]. However, these articles examine mechanisms for analyzing and detecting attack methods, and do not address where such mechanisms should be implemented in in-vehicle systems in accordance with security-by-design principles, and what threats can be addressed by such mechanisms.
Therefore, we propose a risk-based security design methodology that can place mechanisms to detect intrusion attacks in the right places to appropriately respond to the various threats that occur in connected cars.
Modern in-vehicle electric/electronic (E/E) systems consist of multiple controllers called electronic control units (ECUs) that are interconnected by networks such as controller area networks (CANs). Using these ECUs, modern vehicles achieve a variety of functions, such as autonomous driving, remote maintenance, and so on. Singh and Kim show an overview of security issues regarding vehicles, which includes in-vehicle and vehicle-to-everything (V2X) models [10]. In this article, we assume a vehicle equipped with ECUs, sensors, and actuators for autonomous driving and remote maintenance functions.
To achieve defense in depth, in-vehicle systems with autonomous functions often take the following three-layer structure:
The big difference between in-vehicle and IT systems is whether or not a human–machine interface (HMI) is equipped on the component. In the case of in-vehicle systems, except for some types of ECUs, the component, such as the navigation system, does not have HMIs. Instead, most in-vehicle components have interfaces between the sensors and actuators. As a result, in the case of in-vehicle systems, we need to consider cyberattacks via the component’s sensor. Further, in cyberattacks against in-vehicle systems, we must consider the damage to the safety functions due to the malfunctioning of actuators.
Clause 9 of ISO/SAE21434 defines the process to realize a risk-based security design. The subclauses are
First, identify the item and the related operational environment. As an item description, you should specify the “item function,” “item boundary,” and “preliminary architecture.” Also, specify the operational environment, which is the context that considers the interactions in operational use.
Second, perform a TA on the item definition. The TA derives the “threat scenario” for the item. ISO/SAE 21434 defines requirements for “asset identification” and “threat scenario identification” to implement the TA but does not mention specific methods.
For each threat scenario, a risk value should be determined. If it is determined that the risk of a threat scenario is to be reduced, a “cybersecurity goal” is to be defined. Otherwise, if the risk is determined to be shared or retained, a “cybersecurity claim” is created.
Next, perform an RA to the result of the TA. ISO/SAE 21434 defines requirements for “impact rating” and “attack feasibility ration” but does not mention specific methods.
For threat scenarios that should reduce risk, cybersecurity goals shall be derived. If the risk is to be shared or retained, a cybersecurity claim shall be written describing the reasons why the risk of that threat scenario can be shared or retained. Similarly, for threat scenarios that are found to be infeasible because of TA and RA execution, a cybersecurity claim shall be written describing the reasons for the infeasibility.
Third, to achieve the formulated cybersecurity goals, cybersecurity requirements and requirements for the operational environment should be derived. ISO/SAE 21434 requires that cybersecurity requirements be assigned to components within an item, but there is no mention of a specific methodology for deriving cybersecurity requirements.
Here we describe the procedure for preparing the work products in Clause 9 of ISO/SAE 21434 as described in the previous section according to the contents of JASO Technical Paper TP15002:2016 [11].
TP15002 uses a simplified data flow diagram (DFD) to describe the flow of data among components. The simplified DFD describes both the item boundary and preliminary architecture. Figure 1 shows an example of a simplified DFD for an in-vehicle E/E system of a three-layer structure.
Figure 1 An example of a simplified DFD for the item boundary. navi: navigation; V2X: vehicle to everything; USB: Universal Serial Bus.
The item covers a whole-vehicle system, and some interfaces are described as the item boundaries. The boundaries are
The simplified DFD describes ECUs as components inside the item, and the following objects are described as components in the operational environment.
TP15002 also uses a table called a component functions list to fill in the missing information due to simplification of the DFD. It describes the functionality provided by the item and its description as well as the assets associated with the functionality provided by the item and the cybersecurity characteristics associated with those assets. TP15002 defines two types of assets: informational and functional.
In Internet of Things products such as connected cars, the security attributes of functional and informational assets are both important. One is integrity of the function, i.e., that the functionality works as intended. The other is availability of the function, i.e., that the functionality does not stop when needed.
TP15002 uses a lifecycle table, which defines the phases of a product’s lifecycle and the people involved in those phases. By using the lifecycle table, it is possible to identify when threats occur and who is involved in the product at that time. This information is used during threat extraction.
In TP15002, assets are described in the component functions list. For each asset, threat scenarios are extracted using a unique method called the 5 W method. The 5 W method uses the following five “W” perspectives to form a tree in a top-down manner to extract threat scenarios:
Six threat types joined together (STRIDE) is a well-known threat model for classifying computer security threats, and it is also used in the automotive industry. Compared to STRIDE, the 5 W method has the following advantages:
Other TA methods have been considered attack trees by the E-safety vehicle intrusion protected applications Project. Recently, Systems-Theoretic Accident Model and Processes/System-Theoretic Process Analysis (STAMP/STPA) has been expanded and used for TA [12]. However, the attack tree is based on an implicitly determined goal of an attack and extracts the subgoals that satisfy the parent attack goal. For this reason, it cannot extract the root goal of an attack, which means threat scenarios as exhaustive as the 5 W method. Also, STAMP/STPA does not extract threat scenarios or hazards themselves, but rather analyzes the factors that cause such events to occur. For this reason, it cannot be used as a substitute for the 5 W method.
For impact and attack feasibility ratings, TP15002 has prepared a risk evaluation method called a CVSS-based risk scoring system (CRSS) [note that CRSS is a Common Vulnerability Scoring System], which is based on CVSS v2 basic metrics [13]. Threat scenarios whose risk values exceed the threshold are selected for reduction.
In TP15002, attack paths are analyzed by the fault tree as a means of deriving “security objectives” in ISO/IEC15408 Part 1 [14] for threat scenarios. The threat scenarios extracted by the 5 W method are placed at the top event of a fault tree, and three types of nodes are expanded from the top event, and the nodes are detailed to a sufficient level. The three types of nodes to be expanded from the top event are as follows:
In TP15002, a node that has reached a sufficiently detailed level is called a basic event, and the countermeasures to the basic event correspond to security objectives. TP15002 creates two types of security objectives based on the ISO/IEC15408 approach. One is realized by the IT function of the item, and the other is by the function or rules on the operational environment. In ISO/SAE21434, the first type corresponds with cybersecurity goals, and the second to cybersecurity claims, respectively.
TP15002 recommends that the cybersecurity requirements realized by item functions be embodied in the security functional requirements described in ISO/IEC15408 Part 2, with countermeasures against basic events in mind.
The previous section showed how to implement ISO/SAE21434 Clause 9 using the techniques described in TP15002. Using these techniques, one could
However, the techniques do not touch on what kind of cybersecurity requirements can be generated. Therefore, it is not guaranteed that it can generate cybersecurity requirements that clarify the four types of functions (protect, detect, response, and recover) mentioned by the NIST CSF, including where they are implemented within an item.
This section examines ways to expand on the TP15002 techniques and improve the ability to generate cybersecurity requirements for the detection function. We take advantage of the concept of the “kill chain” to recognize the attack structure. An example of the application of this kill chain to information security is the “cyber kill chain,” advocated by Lockheed Martin (note that Cyber Kill Chain is a registered trademark of Lockheed Martin Corporation, United States.) This section discusses how to utilize this cyber kill chain to identify which points of the attack path should be watched.
The cyber kill chain defines seven steps of the action. We divide these steps into the following four phases:
In preparation for the action phase, the threat agent finds the victims and prepares the required equipment on the outside of the vehicle so that the activities might not be observed. Therefore, this article focuses on the remaining three phases. Applying this cyber kill chain concept to our fault tree analysis, we expand the subordinate nodes of the action branch and condition branch, considering the attack path. Figure 2 shows the result of the fault tree analysis, where the cyber kill chain is used to expand the action branch.
Figure 2 Results of the fault tree analysis.
The fault tree shown in Figure 3 extracts detailed adverse actions performed in the cyber kill chain and the conditions. This section shows that this fault tree analysis enables us to define the cybersecurity goals related to detection of the adverse actions on the attack path.
Figure 3 Attack path models for an in-vehicle system.
First, we define the elements in the attack path as follows:
Using these elements, the following three attack path models can be defined:
Figure 3 depicts these three attack path models for an in-vehicle system.
Next we describe MP types and their roles in detecting attacks on the attack path.
Here we clarify the MPs using the proposed method and discuss the results.
To make the discussion concrete, we apply the proposed method to the fictitious items defined in Figure 1. First, we clarify the ASs of the item. In this example, the defined “existing AS” is as follows:
The defined “created AS” is as follows:
Next we identify an asset and clarify the MPs to detect attacks against that asset. Table 1 lists MPs of the attacks from each AS when information in the navigation system is assumed to be an asset. Because the cyber kill chain is monitored at multiple locations by these MPs, it is not necessary to implement detection mechanisms at every MP.
Table 1 MPs for the asset on navigation.
In this section, we discuss the three metrics used to evaluate the effectiveness of the MPs derived by our proposed method. The first metric is promptness, which evaluates the ability to detect attacks as early as possible between the time an attacker accesses an AS and the time an asset is reached. The second metric is coverage, which evaluates the coverage of ASs used by an attacker. The last metric is risk-reduction effectiveness, which evaluates how well the attack is detected by the set detection points. To quantitatively evaluate the proposed method using these metrics, we employed defense layers of the castle model [15]. In this model, concentric circles are drawn with the center as the asset, and attack paths from the AS are placed radially. The MPs (MP1–MP7) for each attack path are placed in order from the outside of this concentric circle. Using the defense layers of castle model, the promptness, coverage, and risk-reduction effectiveness of different designs can be compared. Figure 4 illustrates the results of the threat to the function of the application to the navigation system. The red circles indicate the locations that could serve as MPs.
Figure 4 An evaluation based on the defense layers of a castle model.
Promptness is a measure of how quickly an attack can be detected at the MPs. The higher the promptness, the longer the time available for response. A previous study on the evaluation of intrusion detection systems [16] defines promptness as the period between detection and reporting. However, the evaluation depends on the implementation method of the function. As the evaluation of the proposed method is conducted in the security design phase, this article examines an evaluation method for promptness that is independent of the implementation.
First, we assign layer number r to each layer of the defense layers of the castle model. The layer number represents the amount of time required to undermine the cybersecurity property of the central asset. An outer layer has a larger number. In Figure 4, the concentric circles consist of six layers, the innermost layer is layer 0, and the outermost layer is layer 6. Here, MP2 and MP6, listed in Table 1, are arranged on the same concentric circles. The reason for this is that both are the last MP just before the asset. Because the attacks are detected in order of the layer number, the promptness of the monitoring timing in the attack processes can be calculated as follows: \[{Promptness} = \frac{1}{n} \mathop{\sum}\limits_{{i} = {1}}\limits^{n}{{r}_{i}} \tag{1} \] where ${r}_{i}$ is the maximum layer number of the MP, which is installed on ${AS}_{i}$, and n is the total number of ASs.
Coverage is a measure of how many different types of attacks can be detected. The higher the coverage, the better the asset can be protected from various attacks. Coverage can be evaluated by the coverage of the fan shape where the MPs are installed. Specifically, it calculates the percentage of the number of attack paths, which can be detected via the installed MPs from the total number of attack paths. If the ratio is close to 100%, the coverage is high. \[{Coverage} = \frac{{Monitored}{\_}{path}}{{Attack}{\_}{path}}\,{\times}\,{100} \tag{2} \] where Monitored_path is the number of attack paths that can be covered by an MP, and Attack_path is the total number of attack paths.
Risk-reduction effectiveness is a measure of how much risk can be prevented by the installed MPs. By selecting MPs for the attack paths of the ASs that cause threats with high risk, the overall risk-reduction effect can be increased. In defense layers of the castle model, magnitude of the risk value of the attack path from an AS is visualized as a fan-shaped angle. Specifically, a fan-shaped angle ${\theta}$, which indicates the risk-reduction effectiveness, is calculated using the following formula: \[{\theta} = \frac{{Path}{\_}{risk}{\_}{max}}{{Total}{\_}{risk}{\_}{max}}\,{\times}\,{2}{\pi} \tag{3} \] where Path_risk_max is the maximum risk value of the AS to focus on, and Total_risk_max is the sum of the maximum risk value in each AS.
We use CRSS for the calculation of the risk value, and the availability and integrity value are ranked as “major.” These preparations enable calculating the angle for each AS in the evaluation model shown in Figure 4. (See Table 2.)
Table 2 The value of zero in each attack path.
To detect attacks more promptly, the outer circle will be more effective than each MP. The effectiveness of each AS can be calculated by the product of the angle ${\theta}$ and the layer number r.
This preparation allows us to evaluate the set of MPs selected by the proposed method. Here we show that the proposed method can discover candidate MPs, and that evaluation metrics can be used to evaluate where to implement the detection mechanism. For this purpose, we assume several cases in which a set of MPs is selected from all the extracted MPs and show that the characteristics of each case can be identified. First, we consider the following cases in which the detection mechanism is selected to be implemented based on the defense layers of the castle model from the candidate MPs found by the proposed method.
Implement a detection mechanism at the outermost MP for all attack paths.
As in case 1, target the outermost MP but exclude MPs for the attack paths from ASs (here, AS3 and AS7 are excluded as examples).
Select the MPs closest to the asset.
Next, for each case, an evaluation was conducted using the metrics considered (Table 3).
Table 3 The evaluation result for each case.
A comparison of cases 1 and 3 shows that placing the outermost MP can increase promptness and risk-reduction effectiveness. A comparison of cases 1 and 2 shows that reducing the number of ASs to be monitored worsens all metrics, but the promptness and risk-reduction effectiveness of case 2 have better than those of case 3. From this, it can be determined that the following strategy should be used to select the MPs where the detection mechanism should be implemented:
This article proposed a method that derives cybersecurity requirements for detection mechanisms from risk-based security designs and discussed evaluation metrics for the MPs derived by the proposed method. ISO/SAE21434:2021 requires that TARA be performed, and that the results be used to derive cybersecurity goals. JASO TP15002:2016 contains items that help in realizing the requirements of ISO/SAE21434. However, it does not describe how to derive which activities are in an item and how they should be monitored for cybersecurity controls related to intrusion detection.
Therefore, this article proposed an extension of the existing TARA method based on TP15002 in combination with the cyber kill chain to derive candidate MPs for detecting attacks. Furthermore, this article presented a discussion comparing three different sets of MPs derived using this extended method for an example in-vehicle system with multiple ASs.
As a future work, we believe it is necessary to expand the evaluation metrics to formulate optimal MPs while considering the cost of implementing cybersecurity controls and the ease of maintenance after realization. It is also necessary to provide an easily accessible means for the extended method to be widely used in actual security designs.
Makoto Kayashima (makoto.kayashima.hh@hitachi.com) is a senior manager in the security and trust research department in the R&D group of Hitachi, Ltd., Chiyoda, Tokyo 244-0817, Japan. He received his B.S., M.S., and Ph.D. degrees from Yokohama National University. He organizes product security research areas in his organization. He is also a member of the Information Technology Promotion Agency in Japan.
Nobutaka Kawaguchi (nobutaka.kawaguchi.ue@hitachi.com) is a chief researcher in the security and trust research department in the R&D group of Hitachi, Ltd., Chiyoda, Tokyo 244-0817, Japan. He received his B.S., M.S., and Ph.D. degrees from Keio University in 2003, 2005, and 2008, respectively. His main research activities are focused on cybersecurity. He is a Member of IEEE and is a Certified Information Systems Security Professional.
Kota Ideguchi (kota.ideguchi.yf@hitachi.com) is a chief researcher in the security and trust research department in the R&D group of Hitachi, Ltd., Chiyoda, Tokyo 244-0817, Japan. He received his B.S., M.S., and Ph.D. degrees in science from the University of Tokyo. His main research activities are focused on cybersecurity for automotive systems and cryptography.
Nobuyoshi Morita (nobuyoshi.morita.gj@hitachi.com) is a senior researcher in the security and trust research department in the R&D group of Hitachi, Ltd., Chiyoda, Tokyo 244-0817, Japan. He received his B.S. and M.S. degrees from Soka University in 2007 and 2009, respectively. His main research activities are focused on product security, especially for the automotive industry.
[1] K. Koscher et al., “Experimental security analysis of a modern automobile,” in Proc. 2010 IEEE Symp. Secur. Privacy, pp. 447–462, doi: 10.1109/SP.2010.34.
[2] C. Miller et al., “Adventures in automotive networks and control units,” IOActive, Seattle, WA, USA, White Paper, 2013. [Online] . Available: https://ioactive.com/pdfs/IOActive_Adventures_in_Automotive_Networks_and_Control_Units.pdf
[3] Cyber Security and Cyber Security Management System, WP.29 UN Regulation No. 155, 2020.
[4] Road Vehicles – Cybersecurity Engineering, ISO/SAE Standard ISO/SAE 21434:2021.
[5] V. Barrett, “Framework for improving critical infrastructure cybersecurity version 1,” National Institute of Standards and Technology, Gaithersburg, MD, USA, 2018. [Online] . Available: https://www.nist.gov/publications/framework-improving-critical-infrastructure-cybersecurity-version-11
[6] A. R. Javed, S. u. Rehman, M. U. Khan, M. Alazab, and T. R. G, “CANintelliIDS: Detecting in-vehicle intrusion attacks on a controller area network using CNN and attention-based GRU,” IEEE Trans. Netw. Sci. Eng., vol. 8, no. 2, pp. 1456–1466, Apr./Jun. 2021, doi: 10.1109/TNSE.2021.3059881.
[7] A. R. Javed, M. Usman, S. U. Rehman, M. U. Khan, and M. S. Haghighi, “Anomaly detection in automated vehicles using multistage attention-based convolutional neural network,” IEEE Trans. Intell. Transp. Syst., vol. 22, no. 7, pp. 4291–4300, Jul. 2021, doi: 10.1109/TITS.2020.3025875.
[8] M. Tayyab, A. Hafeez, and H. Malik, “Clock phishing attack on clock based intrusion detection systems (CIDS) for CAN protocol,” in Proc. Embedded Secur. Cars Conf., 2018.
[9] T. D. Pyun, R. Kurachi, H. Ueda, and S. Horihata, “CAN disabler: Hardware-based prevention of unauthorized transmission in CAN and CAN-FD networks,” in Proc. Embedded Secur. Cars Conf., 2016.
[10] M. Singh and S. Kim, “Security analysis of intelligent vehicles: Challenges and scope,” in Proc. 2017 Int. SoC Des. Conf. (ISOCC), pp. 13–14, doi: 10.1109/ISOCC.2017.8368805.
[11] Guideline for Automotive Information Security Analysis, JSAE, JASO TP15002, 2016.
[12] N. Paula de Souza, C. d. A. C. César, J. d. M. Bezerra, and C. M. Hirata, “STAMP-based approach to analyze safety, security and data privacy,” in Proc. 9th Latin-Amer. Symp. Dependable Comput. (LADC), 2019, pp. 1–10, doi: 10.1109/LADC48089.2019.8995717.
[13] Cybersecurity Information Exchange, Vulnerability/State Exchange, Common Vulnerability Scoring System, ITU, ITU-T X.1521, 2011.
[14] Information Technology - Security Techniques - Evaluation Criteria for IT Security – Part 1: Introduction and General Model, ISO/IEC Standard 15408-1, 2009.
[15] A. Milenkoski, M. Vieira, S. Kounev, A. Avritzer, and B. D. Payne, “Evaluating computer intrusion detection systems: A survey of common practices,” ACM Comput. Surv., vol. 48, no. 1, pp. 1–41, 2015, doi: 10.1145/2808691.
[16] N. Boggs, S. Du, and S. J. Stolfo, “Measuring drive-by download defense in depth,” in Proc. Int. Workshop Recent Adv. Intrusion Detection, 2014, vol. 8688, pp. 172–191, doi: 10.1007/978-3-319-11379-1_9.
Digital Object Identifier 10.1109/MVT.2022.3219239