1 Introduction

Information systems (IS) involve in the gathering, processing, storing, and distributing information to perform specific tasks and make decisions [14]. Autonomous vehicles (AV), a.k.a., self-driving cars, infer as the intelligent information systems (IIS) because they perceive, collect, generate and disseminate sensitive information to improve knowledge to act autonomously and provide its required services of mobility, safety, and comfort to humans. Therefore, it is necessary to secure data and information against malicious use and its resulting security risks. But the current studies focus on the automotive aspect of the AVs and do not consider the AV as an information system. This shortcoming leads stakeholders to miss vital security-related knowledge of the AV information collection, manipulation and actuation activities to make well-informed decisions regarding security investment in AV systems.

In this study, we analyse how autonomous vehicles as intelligent information systems can be protected against security risks? Specifically, we focus on vehicles that have achieved autonomy as defined in the SAE J3016 [28] standard – which is level 4 (semi-AVs that autonomously perform all driving functions under certain conditions, e.g. on a specific type of road or at certain times) and level 5 (full AVs that perform all driving functions under all conditions autonomously). We combine the domain model for IS security risk management (ISSRM) [11] with the operationally critical threat, asset and vulnerability evaluation (OCTAVE allegro) [5] to explore the security risks in AVs through the literature study and case analysis.

2 Research Method

There exist different methods aimed at security risk management, relevant for use in AVs: for example, EVITA [13], ETSI Threat, Vulnerability and implementation Risk Analysis (TVRA) standard [12], HEAVENS security model [21], Security-aware hazard and risk analysis method (SAHARA) [17]. These methods provide guidelines when considering AV security; however, they lack a consistent approach for identifying vulnerabilities, threats/attacks, risk assessment, risk estimation, and risk treatment. Consequently, we did not find a standard or method in the literature that apply to AV security, given its complex capabilities and its overlap across multiple information domains.

In this study, we combine the ISSRM domain model [11] and the OCTAVE [5] method. OCTAVE guides the assessment of information security risks; it contains templates to document risk management activities and guide data collection for probability and security risk impact estimation. But OCTAVE does not support an explicit risk analysis process. The ISSRM domain model guides elicitation of assets, attack methods, vulnerabilities, threats, risks, and solutions to mitigate risks. Initially developed for IS risk management, the ISSRM domain model is also applicable in the AV systems as these systems gather, manipulate, interpret and disseminate information for the stakeholders. A combination of OCTAVE and ISSRM strengthens the analysis (i) with the ISSRM guidance for the security risk definition and (ii) with the OCTAVE templates for security risk estimation.

3 Literature Study

Assets. Following [2], the AV system can be decomposed to perception, network and application layers, as illustrated in Fig. 1. The business assets are defined as data and information that are valuable in the system with its security needs to be estimated using the security criteria (i.e., confidentiality, integrity and availability). The perception layer includes the system components responsible for collecting video, location and travel, surrounding environment and other data [24, 27, 28]. The collected data is transmitted to the application layers using the network layer. The application layer uses the collected data to perform tasks, i.e., calculate routes. An actuation module uses these calculations to perform autonomous functions.

Fig. 1.
figure 1

(adapted from [26])

Literature study: AV system assets

Table 1. Literature study: Security risks and countermeasures

Security Risks. In the literature, we have identified security risks (see Table 1, columns 1–3). Eleven risks (R1–R9, R16) are identified at the perception layer, seven (R10–R11, R19–R23) – at the application layer, and four (R12–R15) at the network layer. R17 can be found at all layers, and R18 is identified at the network and application layers. Details of security risks could also be found in [26]. We do not consider the risks in Table 1 as exhaustive but aim to raise awareness of the AVs’ risks.

Countermeasures identified in the literature are presented in Table 1 (see columns 4 and 5). Some key countermeasures at the perception layer are noise detection, rejection, and the use of multiple input sources [24, 28]. At the network layer, countermeasures are encryption, special devices and user authentication techniques [25, 27]. At the application layer, countermeasures include anti-malware software, firewalls, access control and user authentication.

Fig. 2.
figure 2

(adapted from [26])

Case analysis: AV assets and associated security risks

4 Case Analysis

We have combined the ISSRM and OCTAVE methods to assess the Lexus RX450h AV system in the laboratory environmentFootnote 1. The car’s architecture is presented in Fig. 2; it is adapted from our literature study (see Fig. 1). The figure also illustrates how risks are associated. Table 2 shows an example of one risk – R6. Here, an attacker with some expertise and tools sends malicious optical inputs targeting the AV cameras(system assets) because the cameras are vulnerable to blinding attacks. If the event happens, it negates the integrity of video and picture data leading to unreliable data sensed by the cameras that could provoke wrong decisions when the car is driving/steering. In [26], all considered security risks are explicitly defined using the ISSRM domain model.

Countermeasures are suggested at all three AV layers – perception, network, and application – to mitigate the security risks. We also elicit the relative countermeasure costs. For example, to reduce risk R6, two controls are suggested: (i) multiple sensors for redundancy check estimated with a low cost and (ii) filter to remove harmful light with a high cost. The complete risk management documentation of the Lexus RX450h AV system can be accessed in [26].Footnote 2\(^{,}\)Footnote 3

Limitations of Case Analysis. The case study AV is still in the early development phase (i.e., laboratory settings), so we could not consider the system and business assets throughout its life-cycle management; thus, the risk estimations could change. Additionally, we apply security risks found in the literature in our case study. Although we have discovered added risks, our security risk analysis and estimation is limited by those we identified in the literature.

Table 2. Risk estimation using OCTAVE (R6: Blinding cameras)

5 Concluding Remarks

AVs, as IIS, provide a unique perspective on how security risks should be handled while considering the autonomy of data gathering, manipulating, disseminating and actuating functions. In this section, we conclude the paper with the lessons learnt and an overview of the related studies.

5.1 Lessons Learnt

Asset-Related Concepts. We have identified the business assets in the perception, network, and application layers. The study results in the systematic examination of the security risks and helps identify countermeasures. For example, the inclusion of multiple sensors could monitor and analyse data from robust and redundant data sources in AVs, which help develop protection strategies that could identify anomalous inputs and behaviour produced by cyber attacks. However, stakeholders must ensure the presence and trust boundary of the sensors as data sources.

Risk-Related Concepts. The assets, alongside attack methods and threat agents, are dynamic. Thus, our estimated scores in the case analysis would change over periods. The dynamic nature of assets, threat likelihood due to evolving attack tools/ methods, and an evolving environment indicate that security risk management must be an iterative activity involving dynamic and real-time risk impact estimations as proposed in [16].

We discovered other attacks on the AV not discussed in the literature. One example is carrying out the blinding attack using mirrors to reflect sunlight which could make the likelihood of R7 (see Footnote 3), high. Another is spoofing the LiDARR9 (see Footnote 3) with smoke, which increases the likelihood of a spoofing event as it is a low effort attack. Lastly, capability to tamper with the AV code functions used by the ECU in the code repository. Efforts must be made to continually improve sensors (i.e. auto-exposure settings for R7), algorithms (i.e., improving obstacle detection algorithms for R9) and integrity checks for all code used by the ECU.

Risk Treatment-Related Concepts. Outlining risk estimations enables treatment prioritisation and return on security on investment analysis in AVs. Using OCTAVE, we can deduce the risk scores based on the relative scores of the impact on the affected assets and threat likelihood while providing a documented risk overview.

Table 3. Comparing related work

Thus, the combination of the ISSRM and OCTAVE methods has filled in the gaps posed by either method’s single-use. The ISSRM method refined the security risk management concepts applied in OCTAVE. At the same time, OCTAVE helped provide formal documentation and risk estimation through risk scores based on the relative scores of the affected assets’ impact and threat likelihood. The combination provided a useful output to support the AV stakeholders. In [3], Bailey combines the NIST risk assessment process [1] with a probabilistic method and applies the optimisation techniques to recommend the best solutions. Similarly, we have used the countermeasure cost estimation, but we transform the estimates to the qualitative values. This approach allows us to reduce the amount of collected data, but it still supports countermeasure selection decisions.

5.2 Related Work

Related studies analyse security risks in some parts or the whole AV. However, these studies do not consider AVs as information systems. In Table 3, we present a comparison illustrating the focus on AV security risk management. It indicates that Dominic et al. [10], and Parkinson et al. [22] cover the security risk estimation and management in AVs; however, they provide little details on AV system assessment’s impact. Other related studies [6,7,8,9, 15, 18] address security risk management, some [4, 7] focus on safety and security engineering in AVs. But these studies do not discuss estimations needed for AV stakeholder security investment decisions. In [4], Boudguiga et al. TVRA and EVITA methods are combined, but they did not include the cost of countermeasures to assess the severity of the security risks in supporting business decisions. Our study provides a security-focused risk estimation and management analysis on the AV information system, covering the security assets, threats, resulting risks, proposed countermeasures and risk impact estimations based on the mentioned security metrics. We have documented these concepts within the AV case analysis, providing the rationale for making business decisions on securing AVs.