SSRN Id4711138

ed
An Adaptable Security-by-design approach for ensuring a secure

Over the Air (OTA) update in modern vehicles
iew
Victormills Iyieke1.2 , Hesamaldin Jadidbonab1 , Jeremy Bryans1 , Abdur Rakib1 , Don
Dhaliwal2 , Odysseas Kosmas 2
1,
Centre for Future Transport and Cities, Coventry University, UK
2
CONIGITAL LTD
ev
January 17, 2024
r
Abstract
The increase in Connected and Automated Vehicles (CAVs) and Intelligence Transport Sys-
er
tems (ITSs) by OEMs has increased the requirement for modern vehicle sophistication comprising
various software capabilities and functionality embedded in over 100 ECUs in a vehicle. This has
led to the need for over-the-air (OTA) updates. OTA updates can be delivered wirelessly, elimi-
nating the need to bring vehicles to the garage for updates. This is more convenient for owners,
reduces costs for OEMs, and lowers greenhouse gas emissions. Researchers, Industrial partners,
pe
and OEMs have developed several OTA technology standards, such as the Uptane framework,
Open Mobile Alliance Device Management (OMA-DM) , ISO 24089, and ISO 21434 standards.
However, the systematic implementation of security-by-design applying ISO 21434 in OTA sys-
tems is not well-known, and there remains a gap in this practice of security-by-design that the
automotive industry can adapt to ensure a systematic approach to secure OTA update technology.
OTA update security hinges on identifying vulnerability pathways for potential malicious attacks.
Therefore, identifying and mitigating potential vulnerabilities throughout the OTA update pro-
ot
cess is critical for robust security. This paper proposes a secure OTA update technique with an
adaptable security-by-design approach built and extended from our work in Iyieke et al. (2023).
The adaptable security-by-design approach is then applied to a developed prototype OTA update
system based on the Uptane framework as implemented by Toradex. Security-by-design is a well-
tn
established concept in enterprise systems, but it is still developing in the cyber-physical system of
automotive cybersecurity. Our proposed approach covers the security engineering lifecycle, logical
security layered concept, and security architecture. A threat analysis and risk assessment (TARA)
is conducted based on the international automotive cybersecurity standard ISO/SAE 21434. The
highest threats identified from the TARA are formalized, and corresponding mitigation actions
are defined according to UNECE WP29. Penetration testing is conducted to verify the approach’s
rin
capability to reinforce the security of the OTA update systems against some of the identified risks
and threats. Our proposed approach provides a systematic, adaptable security-by-design approach
for ensuring secure OTA updates in modern vehicles; OEMs and other stakeholders can use it to
develop secure OTA systems regardless of the OTA framework used.
ep
Keywords; Security-by-design, Automotive Cybersecurity, Over the Air Update (OTA),

Threat Analysis and Risk Assessments (TARA), Connected and Automated Vehicles (CAVs), Intelli-
gence Transport Systems (ITS), Security Architecture.
Pr
1 Introduction
In response to the growing demand, automotive Original Equipment Manufacturers (OEMs) are in-
creasingly focusing on automation, electrification, intelligence, and connectivity, which has led to an
1
This preprint research paper has not been peer reviewed. Electronic copy available at: https://ssrn.com/abstract=4711138
increase in the number of Electronics Control Units (ECUs) in modern vehicles. This demands a
detailed and careful design, with over 100 ECUs [26] and millions of lines of software code [27].In
ed
order to implement the CAVs and ITSs that OEMs are currently focussing on, a sophisticated de-
sign is necessary. At the core of this design implementation is system security, as well as how well
these systems can be updated and maintained in a way that is most convenient and economical for
OEMs and customers. As a result, there have been a reasonable number of research publications
that address prevalent themes in the automotive industry, including Secure OTA Software Updates in
Connected Vehicles [26], SFOTA [42], EVITA [46], UniSUF[49], and security-by-design framework for
iew
Autonomous Vehicles (AV) [2]. Thus, the need for Over Air update (OTA) technology, which refers
explicitly to wireless delivery of new software/ firmware upgrades to the onboard vehicle ECUs or
components to avoid the unnecessary, inconvenient, time-consuming update of the ECU software by
the traditional methods [4]. The OTA technology is categorised into Firmware Over-The-Air (FOTA),
which updates the microprograms in the ECUs or components and while the Software Over-The-Air
(SOTA) updates the software that runs in these ECUs or components as categorized by Kim and Park
ev
[38]. In essence, OTA updates address feature update or upgrades remotely and fixes performance
issues, enhance users’ experience, and potentially increases the efficiency of the vehicle, and most im-
portantly, it is very cost-effective [43]. Hence, for this research, the term OTA technology would be
used interchangeably to cover the firmware/software of an ECU. Any reference to the core application
or calibration file within the ECU will be mentioned. The Automotive OTA Technology is primarily
r
separated into an Off-Board system and an On-board system, as shown in Figure 1
er
pe
ot
tn
rin
ep
Figure 1: OTA systems update process.

Pr
The Off-Board is the back-end (cloud server) aspect, and the On-Board is the ECUs or components
in the vehicle; when taking the entire entities in the automotive OTA update systems, they comprised
back-end, Vehicles, Mobile phones, Tier 1 suppliers of parts, Software Distribution, Vehicles Owners,
Service Centre, Insurance Company Enforcement and Law Personnel [24]. The OTA technology is
2
divided into three distinct parts: generating the update, managing its distribution, and executing the
update within the vehicle. Each square block in the OTA system represents a function that is carried
ed
out either in the Off-Board or On-Board segment.
The following subsections discuss important components, corresponding related work, and the
research gaps.
1.1 On-Board System (Vehicle)
iew
The On-board system of OTA Update comprises the various processes and implementation of OTA
update in the vehicle. The OTA update is carried out in various ECUs, like the infotainment and
sensors domain of the vehicle, as illustrated in Figure 2. For this research, the ECUs are classified as
OTA Master, and OTA Target ECUs [9].
r ev
er
pe
ot
tn
Figure 2: OTA On-board system (Vehicle).

rin
OTA updates follow a ‘download, install, activate’ process per Open Mobile Alliance (OMA) ter-
minology [10], but OTA target ECUs are not involved in the download step. The design of the systems
shall aim to isolate the download functionality from the OTA target ECUs but consider their require-
ments for installation and activation of software updates.
ep
1.2 Off-Board System (Cloud Services)

The current trend in the automotive industry and academia leads to various investigations on cloud
platform architectures that enable continuous software delivery in vehicles [31]. Since modern vehicles
are software on the wheel and non-traditional OEMs like Google are influencing the development of
products and components used in modern vehicle software, connecting the Internet of Things (IoT)
Pr
to the embedded system that makes up a vehicle’s building block is becoming the norm [35]. Data
resources are also virtualized and built as cloud services. The cloud platform is a key factor of the
OTA Off-Board System as it enables data and information to be processed and stored beyond the
vehicles, providing connectivity via a wireless communication system and enabling OEMs to carry out
3
many more business services on the cloud, as shown in Figure 3. The backend servers, which reside
in the Off-board System of the OTA update technology, recognize the remote instance which delivers
ed
the FOTA Image to be downloaded into the Vehicle (e.g., via 3G, 4G, 5G, Wifi, etc.).
iew
r ev
er
pe
Figure 3: OTA offboard services.
1.3 Contribution.
Based on our work built and extended from [36], our contribution to this paper is a systematic, adapt-
able security-by-design approach for ensuring secure OTA updates in modern vehicles, and it is also
ot
applicable to any relevant automotive systems. It covers the security engineering lifecycle, a process
that significantly improves the ad hoc security practices often used in the automotive industry. A
novel approach known as the ”logical security layered concept” has been developed based on a mod-
ification of UNECE WP29 regulation, demonstrating a practical application in real-world scenarios.
tn
Also, our approach, which uses penetration testing in addition to threat analysis and risk assessment
(TARA), effectively mitigates real-world security threats. Furthermore, we identified gaps in the au-
tomotive industry’s security-by-design practice for relevant systems; we suggested and implemented
our methodology to address the identified weakness in an OTA update system use case; and finally,
we argue that any relevant automotive system, in this case OTA systems, can use our approach to
rin
develop secure automotive systems, regardless of the OTA framework used.
1.4 Paper Organisation

The rest of the paper is organised as follows: Section 2 discusses the state-of-art on security-by design
ep
and secure OTA update. Section 3 Design process and methodology, guided by ISO/SAE 21434 and
UNECE WP.29 (R155) for an adaptable security-by-design for OTA update security (includes life-
cycle, architecture). Section 4 describes the implementation of our approach, while Section 5 shows
various cybersecurity activities in consideration. Section 6 Threat formalization and mitigation, and
Section 7 presents the verification, in addition, discussion and result, and finally, Section 8 gives a
Pr
summary of the paper while highlighting areas of future work for expansion and improvement.
4
2 Background
In this section, we review the state of the art of security-by-design and secured OTA updates within
ed
the automotive industry.
2.1 Security-by-design
Building upon the Security-by-Design principles outlined in our work [36], this section highlights the
iew
critical role of systematic, life-cycle security integration for robust automotive OTA updates. This
necessitates a meticulous examination of security characteristics throughout the system’s design and
development [19]. Such scrutiny fosters robust and resilient systems against threats, hazards, and
disruptions [19]. Expanding on this, [45] emphasises the inherent synergy between this approach and
systematically implementing processes across the entire development life cycle, encompassing pre- and
post-development activities. This includes thorough system testing to validate implemented security
controls and identify vulnerabilities [33], [45]. Therefore, [51] argues that the effectiveness of improving
ev
security practices is maximized when considered from the very inception of the development process.
Consequently, Security-by-Design advocates for implementing proactive measures against known and
unknown threats, employing a ”secure-by-default” model in hardware design, software configuration,
and access policies. It necessitates embedding security as a core facet of system design, leveraging
both trusted hardware and rigorous software assurance processes. Taking software assurance as an
r
example, this entails comprehensive threat analysis, iterative code review, and adaptable countermea-
sures designed into the system architecture. Rigorous security testing then validates these measures,
er
solidifying security-by-design as a holistic principle and discipline within system engineering [33], [45].
This focus on life-cycle integration has led to the emergence of several Secure Development Life Cycles
(SDLs) built upon the Security-by-Design approach. OWASP [22], Open SAMM, Cisco SDL, and
Microsoft SDL are prominent examples [37]. These frameworks all incorporate threat modeling at the
development outset and ongoing security assessments throughout the process, bolstering the resilience
pe
of OTA updates against diverse threats. [36]
2.2 Secured OTA Update Discussion

The motivations and problems for upgrading firmware over the air are outlined in [47]. Nevertheless,
no solutions to the previously mentioned challenges are provided. It is worth noting that researchers
ot
Mahmud et al. [40], [40] discussed and proposed a secured architecture for solution for software updates
taking into consideration some precondition (i.e., the availability of multiple copies of updates being
sent) to ensure secure software updates. Multiple copies, on the other hand, are not feasible and
incur a number of infrastructural limitations, and this proposal does not cover automotive on-board
tn
networks, where domains are customarily subdivided. In [41], [42] proposed a lightweight protocol and
verification for secured firmware updates over the air in SFOTA. During the firmware update process
of the SFOTA protocol, many characteristics are enforced (i.e., data integrity, data confidentiality,
and data freshness). However, in order to guarantee secured software updates, their technique relies
on strongly enforced assumptions: vehicle authentication is not taken into account, keys are expected
rin
to be maintained securely, and their methods employ a single encryption key for all the ECUs in
the vehicle. Moreover, their proposed approach makes no explicit implementation platform (OTA
Master) requirements. In [41], key management for secured OTA update was discussed using the
multicast method to update the software on several ECUs. However, the methods still did not address
implementation platform (OTA Master) requirements. Bar-El [23] presented a software-based solution,
ep
which are purely low-level application security functions that are detached from the hardware itself by
focusing on a framework that consists of a logical toolbox - a set of logical modules that offer security
functionality for automotive applications and are deployed in a range of embodiments (e.g., controllers).
The logical toolbox and enablers, which are low-level and application-level security operations in [23],
support a variety of onboard automotive use cases. Nevertheless, it kept the critical link to the
Pr
external communication domain untouched, therefore exposing it to attack vectors. In contrast to

[23], Muhammad et al. [44] took a holistic view of the onboard security architecture for OTA by
combining hardware and software modules. Nevertheless, it did not cover any potential security vector
that might result from the off-board systems. The current state-of-the-art in OTA update design
flaws are less known, and there remains a lack of a security-by-design method that can be applied to
5
the automotive OTA in a holistic and systematic manner as in the case of a web-based application
where a security-by-design systematic standardise approach is lead down by OWASP [21]. A robust
ed
Adaptable Security-by-design approach for ensuring a [36] secure OTA update through the application
of ISO/SAE 21434 in modern vehicles that covers all aspects of the OTA Offboard systems and the
On-board systems (secure communication, data protection, and tamper-proof secure execution for
safety-critical component) is therefore imperative.
iew
3 Design Process and Methodology
The international automotive cybersecurity standards ISO/SAE 21434 and UNECE/TRANS/WP.
29/2020/79 (R155) serves as general guidelines for our design process, which we refer to as our method-
ology. It is described in detail below and offers an adaptable security-by-design approach to ensure a
secure OTA update in modern vehicles [36].
ev
3.1 Security Engineering Life-cycle
In line with the emphasis of our previous work on [36], our approach prioritises integrating security
activities into the early phases of the OTA development life cycle, as advocated by [29]. This initial
step forms the foundation of our methodology for tailoring a secure OTA update system for modern
r
vehicles. Integrating security entails applying ISO/SAE 21434 guidelines, encompassing aspects like
Organizational cybersecurity management, Project-dependent cybersecurity management, and contin-
uous cybersecurity activities throughout the Concept, Production development, and Post-development
er
phases [8]. This includes diverse subactivities within each primary stage, such as Product development,
Cybersecurity requirement and architectural design, and cybersecurity integration and validation [8].
To comprehensively embed cybersecurity in the OTA update design and development from the very
beginning, we leverage a well-defined and structured automotive cybersecurity engineering process.
pe
This paper specifically focuses on the Concept and Product development phases of the security engi-
neering life cycle to minimise the risk of successful cyberattacks on the modern vehicle’s OTA update
system. Our approach commences in the Concept phase, incorporating systems security engineering by
prioritizing security considerations right from the outset when defining the OTA system’s requirements
[3]. Figure 4 illustrates our simplified approach for the OTA system, adhering to the Concept and
Product development phase steps outlined in [8]. It showcases the two primary phases – Concept and
ot
Product development – around which cybersecurity considerations and the design of the OTA system
revolve. These activities are briefly summarized in Figure 4 below.
3.1.1 Checks for Cybersecurity Relevance

tn
Figure 5 highlights our initial step: assessing cybersecurity relevance as noted in [36]. This crucial
checkpoint prevents unnecessary effort by pinpointing which OTA update systems actually require
dedicated cybersecurity activities. As [8] emphasises, an initial study for cybersecurity planning is
crucial to determine if a vehicle and its connected systems warrant cybersecurity considerations. Not
every component falls under this umbrella. Only features and details within or around the vehicle,
rin
including aftersales and servicing parts, are deemed cybersecurity-relevant according to [8]. Therefore,
our relevance evaluation is built into the early stages of OTA development to ensure the proper appli-
cation of standard-mandated cybersecurity activities. While the standard lacks a prescribed method
for assessing relevance, our process, outlined as a decision tree in Figure 5, offers a clear path forward.
Once we establish cybersecurity relevance through the decision tree, our design process unfolds
ep
Once we determine that the OTA is cybersecurity relevant based on the questions in the decision
tree, our design process is applied.
3.1.2 Concept Phase of the OTA Update

Pr
Though the concept phase precedes product development for OTA updates, its insights shape all subse-
quent stages. Customer needs typically drive the initial concept, focusing on shielding against potential
threats and cyberattacks that could compromise vehicle functions or data. Although we anticipate
some potential threat scenarios, accurately predicting future attacker motivations and capabilities re-
mains elusive. Thus, to navigate this challenge, we seek answers to critical questions: where and how
6
ed
iew
r ev
er
pe
Figure 4: Our cybersecurity activities for OTA update [36]
ot
might the update be vulnerable, what damage could threats inflict, and how can we manage potential
impacts? These crucial inquiries are addressed through the cybersecurity risk assessment outlined in
Figure 4, point 3 (see also [8] ). This assessment begins by defining the subject of investigation (item
tn
and relevant assets), followed by stipulating cybersecurity goals – high-level requirements based on
identified risks, explored in detail later. To mitigate an item’s risk, we prescribe cybersecurity require-
ments for its implementation. Conversely, cybersecurity claims articulate the rationale behind these
risk-treatment measures. [36]
rin
3.1.3 Item definition

Initiating the concept phase of OTA security engineering activities, we begin with item definition.
As [35] explains, an ”item” represents a functional unit within the vehicle, like the OTA system
or infotainment, encompassing modules, components, or bundled features. This definition requires
a comprehensive technical description, detailed in Table 1. We meticulously documented this by
ep
identifying and listing all relevant information, including the OTA update technology’s constituent
subsystems (offboard and onboard systems), all interfaces, and their function within the E/E system
architecture. Importantly, [8] leaves the specific solution for item definition open, focusing instead on
defining items at the vehicle level and their interfaces [36].
Pr
3.1.4 Cybersecurity Goals and Claims

Building on the complete item definition from [36] for the OTA update, we perform a Threat Assess-
ment and Risk Analysis (TARA) to systematically identify, evaluate, and quantify potential threats
and their associated risks [40]. This critical step leverages the detailed information within the item
7
ed
iew
r ev
er
Figure 5: Decision tree for checking of cybersecurity relevance in OTA update [36]
Table 1: Item definition requirement [8], [36]

pe
Item definition section 9.2.1
[RQ-09-01] The following information on the item shall be identified:
a) Item boundary;
b) Function boundary;
c) Preliminary architecture
[RQ-09-02] Information about the operational environment of the item
ot
relevant to cybersecurity shall be described.

tn
description to inform comprehensive cybersecurity risk assessments. These assessments, in turn, guide
subsequent analytical activities, ensuring that cybersecurity design decisions for the OTA update prior-
itize the most significant threats. This risk-based approach avoids overreacting to low-impact threats,
preventing over-engineering and resource waste. While delving deeper into risk assessment methodolo-
gies like TARA lies beyond the scope of this paragraph, Section 4 will provide a detailed explanation.
For now, Figure 6 visually illustrates the interplay between our OTA update definitions, cybersecurity
rin
goals, claims, and the TARA process. [36]
Cybersecurity Goals: The cybersecurity goals produced in Figure 5 meticulously align with the
requirements outlined in Table 2. These goals serve to directly address potential damage scenarios
stemming from specific threats or attack vectors [36].
ep
SAE J3061 ([3]) highlights a key point: when set for high-risk attacks, cybersecurity goals can
sometimes directly oppose the potential threat’s desired outcome. Imagine a Denial-of-Service (DoS)
attack targeting the OTA Master in the vehicle, disrupting communication with the cloud backend
server. The cybersecurity goal for such a scenario would be to prevent or minimize the likelihood of
this DoS attack, essentially negating the attacker’s objective. The following sections will delve deeper
Pr
into this concept with specific examples [36]
Cybersecurity Claims: A cybersecurity claim acts as a statement regarding a risk, providing jus-
tification for either accepting or sharing it based on risk assessment findings. However, claims are
8
ed
iew
ev
Figure 6: Cybersecurity activities
Table 2: Cybersecurity goals[8], [36]

Cybersecurity goals Section 9.4.2
r
[RQ-09-03] An analysis based on the item definition shall be performed that involves
a) asset identification per 15.3;
c) impact rating per 15.5;

er
b) threat scenario identification by 15.4;
d) attack path analysis in accordance with 15.6;

e) attack feasibility rating under 15.7; and
pe
f) risk value determined per 15.8
[RQ-09-04] Based on the results of [RQ-09-03], risk treatment options shall be
determined for each threat scenario per 15.9
RQ-09-05] If the risk treatment decision for a threat scenario includes reducing
the risk, then one or more corresponding cybersecurity goals shall be specified.
ot
RQ-09-06] If the risk treatment decision for a threat scenario includes:

a) sharing the risk; or
b) retaining the risk due to one or more assumptions used during the analysis
of [RQ-09-03], then one or more corresponding cybersecurity claims
tn
shall be specified.
[RQ-09-07] A verification shall be performed to confirm:
a) correctness and completeness of the result of [RQ-09-03] with respect to the
item definition;
b) completeness, correctness, and consistency of the risk treatment decisions
rin
of [RQ-09-04] with to the results of [RQ-09-03];

c) completeness, correctness, and consistency of the cybersecurity goals
of [RQ-09-05] and of the cybersecurity claims of [RQ-09-06] concerning the risk
treatment decisions of [RQ-09-04]; and
d) consistency of all cybersecurity goals of [RQ-09-05] and cybersecurity claims
ep
of [RQ-09-06] of the item.
specifically mandated for risks involving controls outside the OTA system itself, demanding further
action. These situations arise when Implementing cybersecurity controls demonstrably reduces the
Pr
risk to an acceptable level. For example, OTA systems employ a robust cryptographic algorithm on
data and control flows between onboard and offboard systems. Transferring the risk based on justified
reasoning that its inherent impact or damage is deemed acceptable. Table 2, specifically requirement
number [RQ-09-06] with emphasis on part b), emphasizes the need to consider cybersecurity claims,
as outlined in [32]. These claims require ongoing monitoring, suggesting the valuable practice of main-
9
taining a dedicated list. This list may initially have minimal entries at the development outset, but
should be regularly updated and enriched with new claims generated throughout the product’s lifecycle
ed
[36].
3.1.5 Cybersecurity Concept

The crux of cybersecurity lies in establishing a comprehensive strategy for each element or component
[5]. This translates to fulfilling all security goals by addressing individual cybersecurity requirements
iew
assigned to various parts of an initial architectural design. The standard defines the cybersecurity
concept as a process that seamlessly integrates defined goals, stemming from component-specific re-
quirements, into a single entity encompassing: the complete Item definition, the Threat Analysis and
Risk Assessment (TARA), overall goals, and specific claims. This unified entity represents the nec-
essary prerequisites that must be readily available before embarking on any design or development
activities. As shown in Figure 7, our OTA cybersecurity concept outlines the specific prerequisites
demanded by the [8] guidelines. [36]
r ev
er
pe
ot
tn
rin
Figure 7: Illustration of prerequisites required in our OTA cybersecurity concept [36]
Furthermore, the culmination of this process seamlessly blends inputs from the item definition, the
TARA, and the overarching cybersecurity goals into a unified, high-level strategy for securing the OTA
system. This holistic approach is crucial because the current standard, beyond outlining the high-level
ep
cybersecurity requirement depicted in Table 3, remains agnostic regarding specific technologies or

solutions for developing a cybersecurity concept. Therefore, our process bridges this gap by leveraging
diverse inputs to craft a customized and comprehensive security roadmap for the OTA system The
following outlining our adapted approach to cybersecurity concept consideration process [5]:
• Analysis of stakeholder requirements, cybersecurity goals, and claims;

Pr
• Relevant cybersecurity controls for cybersecurity goals;

• Selecting cybersecurity controls to achieve the cybersecurity goals by adhering to cybersecurity
requirements to reduce the risk of threats and
10
Table 3: Cybersecurity concept requirement [8], [36]
ed
Cybersecurity concept Section 9.5.2
[RQ-09-08] Technical and/or operational cybersecurity controls
and their interactions to achieve the cybersecurity goals shall
be described,taking into account:
a) dependencies between the functions of the item; and/or
iew
b) cybersecurity claims.
[RQ-09-09] Cybersecurity requirements of the item and
requirements on the operational environment shall be defined for the
cybersecurity goals in accordance with the description of [RQ-09-08].
[RQ-09-10] The cybersecurity requirements shall be allocated to the
item and if applicable to one or more of its components
ev
RQ-09-06] If the risk treatment decision for a threat scenario includes:
a) sharing the risk; or
b) retaining the risk due to one or more assumptions used during the analysis
of [RQ-09-03], then one or more corresponding cybersecurity claims
shall be specified.
r
[RQ-09-11] The results of [RQ-09-08], [RQ-09-09] and [RQ-09-10] shall be
verified to confirm:
er
a) completeness, correctness, and consistency concerning cybersecurity goals; and
b) consistency concerning cybersecurity claims.
pe
• Distribution of cybersecurity requirements to elements or components of the OTA Systems, etc
[36].
3.1.6 Verification of Cybersecurity Concept

The scope of our verification process ensures that the cybersecurity requirements as outlined in our
TARA will satisfy the goals of our OTA with regard to the addition of security controls. This also
ot
includes assessing the performance of the OTA system for any issues that may arise as a result of the
implementation of security controls, which are intended to reduce the risks of the threats. [36]
3.2 Logical Security Layered Concept

tn
As extended from our works in [36], our ”logical security layered concept” forms a key security control
mechanism. It deconstructs threats, vulnerabilities, and attack methods according to ECE/TRANS/WP.29/2020/79
(R155) [11]. Based on the identified threat type, security controls are implemented in distinct system
areas, akin to layers or levels. Annex 5 of R155 categorizes threats through this layered decompo-
rin
sition, assigning specific areas of impact and corresponding controls to mitigate those threats across
different security layers. These layers encompass the vehicle itself, its external environment, IT back-
end, communication channels, interfaces, and more. Figure 8 visually depicts this concept, though
it’s important to note that R155 doesn’t dictate specific implementation methods for cybersecurity
controls. Instead, it sets requirements for mitigating identified threats, vulnerabilities, and attacks.
ep
Part A of the R155 annex establishes the baseline for these elements, while Part B prescribes threat
mitigation specific to vehicle types, and Part C focuses on mitigating threats outside the vehicle, such
as in the IT backend [UNECE79]. Figure 8 further illustrates the logical security layered concept and
the diverse security controls within each layer. These controls address threats, vulnerabilities, and
attacks targeting the system and its boundaries, showcasing a comprehensive end-to-end cybersecurity
Pr
approach.
While each of the seven cybersecurity layers tackles distinct security aspects, the nature of OTA
updates spans multiple layers’ functionalities. However, covering every single area isn’t the objective
of our adaptable security-by-design approach for secure OTA updates. The following section highlights
the relevant logical security layers crucial for deploying secured OTA updates in vehicles.
11
ed
iew
r ev
er
Figure 8: Logical security layered concept adapted from (R155) [36]
pe
3.2.1 Product Development
Figure 4 showcase the subsequent phase: product development, where the OTA system itself occupies
the product spotlight. This stage encompasses the comprehensive product architecture, complete with
defining specifications, interfaces, and subsystems. It considers all elements involved in enabling OTA
updates, including the off-board backend service, the on-board system, and its supporting subsystems.
Furthermore, this phase hosts the development process’s critical final step, formalizing its completion.
ot
As noted by [36], organizations must guarantee that during development, all crucial needs are com-
prehensively addressed, including those related to cybersecurity and those relevant to the product’s
subsequent life-cycle stages, such as manufacturing, operation, and decommissioning. Given the au-
tomotive industry’s specific nature, its tiered supplier network utilizes internal processes for product
tn
development management. Therefore, this paper focuses on two primary aspects that define the spec-
ification of cybersecurity requirements and architectural design activities applicable to any business
undertaking the product development phase. Figure 9 depicts a V-model-based workflow illustrating
the application of OTA technology development activities within this framework. The cybersecurity
requirements specification aligns with the V-model’s left side, while the architectural design occupies
rin
the right side. While alternative development strategies, such as agile software development, might
diverge from the V-model, organizations can adapt it to their specific needs. Regardless of individual
customization during the product development phase, the fundamental objective still adheres to the
standardized requirement for activities surrounding cybersecurity requirements specification, integra-
tion, and verification.
ep
Cybersecurity Requirement Specification Activities: The heart of cybersecurity planning lies

in the cybersecurity requirement specification, encompassing both cybersecurity needs and the over-
arching system architecture. This crucial document undergoes meticulous refinement through incre-
mental iterations, mirroring the left-hand side of the V-model. Similar to the staggered component
Pr
integration process, this refinement may occasionally necessitate some overlap in the workflow. As
mandated by the relevant standard, Table 4 details the high-level cybersecurity specification activities
for this ongoing refinement [36]. Regardless of the level of abstraction, three key elements guide the
formulation and continuous improvement of cybersecurity requirements [5];
12
ed
iew
r ev
er
pe
Figure 9: The V-model adapted from ISO/SAE 21434 [36]
• Cybersecurity requirements cascaded from higher levels of architectural abstraction: These in-
form the specific needs at the current level;
• Selection of applicable cybersecurity controls for implementation: The chosen controls should
ot
address the identified requirements; and

• Leveraging existing architectural design from higher levels (if applicable): Synergy with estab-
lished architecture strengthens the overall effectiveness.
tn
rin
ep
Pr
13
Table 4: Product development requirement [8], [?]
ed
Product development Section 10.4.1
[RQ-10-01] Cybersecurity specifications shall be defined based on:
a) cybersecurity specifications from higher levels of architectural abstraction;
b) cybersecurity controls selected for implementation, if applicable; and
c) existing architectural design, if applicable.
iew
RQ-10-02] The defined cybersecurity requirements shall be allocated
to architectural design components.
[RQ-10-03] Procedures to ensure cybersecurity after the development of
the component shall be specified, if applicable.
[RQ-10-04] If design, modeling, or programming notations or languages
are used for the cybersecurity specifications or their implementation,
ev
the following shall be considered when selecting such a notation or language:
a) an unambiguous and comprehensible definition in both syntax and semantics;
b) support for the achievement of modularity, abstraction, and encapsulation;
c) support for the use of structured constructs;
d) support for the use of secure design and implementation techniques;
r
e) ability to integrate already existing components; and
f) resilience of the language against vulnerabilities due to its improper use.
er
[RQ-10-05] Criteria (see [RQ-10-04]) for suitable design, modeling, or
programming languages for cybersecurity that are not addressed by the language
itself shall be covered by design, modeling, and coding guidelines or by
the development environment.
pe
RC-10-06] Established and trusted design and implementation principles should
be applied to avoid or minimize the introduction of weaknesses
RQ-10-07] The architectural design defined in [RQ-10-01] shall be
analysed to identify weaknesses.
RQ-10-08] The defined cybersecurity specifications shall be verified to ensure
ot
completeness, correctness, and consistency with the cybersecurity specifications

from higher levels of architectural abstraction.
tn
Cybersecurity Integration and Verification Activities: Driving towards a secure OTA system,
our approach focuses on progressively building and integrating components into increasingly complex
”architectural abstractions,” culminating in the complete vehicle. This mirrors the right leg of the
V-model development process. Every step demands rigorous validation to ensure compliance with
defined cybersecurity standards, design specifications, and established security objectives. Table 5
rin
outlines a high-level requirement encompassing both integration and verification activities for this cru-
cial stage. Furthermore, to guarantee the overall reliability and completeness of the OTA update, all
specification requirements and architectural design elements established during product development
must be seamlessly integrated and verified. This encompasses the entire OTA system architecture,
including subsystems, cloud services (off-board backend), and onboard OTA master. Integration, in-
ep
volving both physical and functional merging of components, is accompanied by dedicated integration
testing. Cybersecurity considerations permeate this entire process. Additionally, comprehensive verifi-
cation procedures are implemented to confirm that the design is faithfully translated into a compliant
integrated system. Verification, beyond checking correct implementation, involves developing detailed
verification specifications and outlining intended test cases and anticipated outcomes, as emphasized
Pr
by [5] noted by [36].
14
Table 5: Integration and verification requirement [8], [36]
ed
Integration and verification section 10.4.2
[RQ-10-09] Integration and verification activities shall verify that the
implementation and integration of components fulfill the defined cybersecurity
specifications.
[RQ-10-10] The integration and verification activities of [RQ-10-09] shall be
iew
specified considering:
a) the defined cybersecurity specifications;
b) configurations intended for series production, if applicable;
c) sufficient capability to support the functionality specified in the defined
cybersecurity specifications; and
e) conformity with the modeling, design, and coding guidelines of [RQ-10-05],
if applicable.
ev
[RQ-10-11] If verification by testing is adopted, test coverage shall be
evaluated using defined test coverage metrics to determine the sufficiency of the test
activities.
RQ-09-06] Testing should be performed to confirm that unidentified
r
weaknesses and vulnerabilities remaining in the component are minimized.
[RQ-10-13] If testing in accordance with [RC-10-12] is not performed,
4
then a rationale shall be provided
Implementation Of Our Approach

er
pe
Building upon our previous work in [36], implementing an adaptable Security-by-Design approach for
secure automotive OTA, this section delves deeper into the design process, outlining the crucial initial
steps. We begin by focusing on the system-level architecture, encompassing the various subsystems
and components within the operational environment of the item under consideration.
4.1 System-Level Architecture

ot
Our initial consideration delves into system-level architecture, setting the foundation for the intricate
security architecture of the OTA update. We pose the fundamental question: How do we establish the
high-level framework for our OTA update, serving as the initial input for implementing our adaptable
tn
security-by-design approach and ensuring secure automotive OTA updates?. Examining existing frame-
works [36], we observe that an illustrative systems-level architecture should encompass both logical and
physical data flows, as depicted in the operational environment of the OTA update shown in Figure 10.
To provide valuable input for subsequent cybersecurity development phases, the defined architecture
must comprehensively address control and data flows within its internal components, along with data
rin
exchanges both internally and across the system boundaries. Building upon this premise, our OTA
update’s systems-level architecture leverages the Systems Modeling Language (SYSML). This robust
modeling language offers the versatility to specify, analyze, design, and verify complex systems, mak-
ing it ideal for crafting the foundation of our adaptable security-by-design approach. It is a Unified
Modeling Language (UML) profile that adds features for modeling systems [34]. Figure 10 shows an
ep
illustrative block definition diagram of a systems-level architecture based on Torizon platform that
is based on the Uptane standards for automotive OTA updates generated from the above question.
The architecture on that Figure is illustrative of the Torizon platform relevant components based on
the Uptane framework [15],[39]. Even though the systems-level architecture diagram is illustrative,
it is sufficient for us to use in demonstrating our proposed approach as it includes physical hardware
Pr
OTA update components (Yavia carrier board embedded with Verdin iMX8M, Ethernet network with
DHCP, Host Machine laptop, keyboard, and Mouse, HMI monitor, and cables. The illustrative High-
level system architecture in the form of a block definition diagram of the Torizon OTA system, which
includes the following entities:
15
4.1.1 Operational Environment
This is the environment in which the OTA update system will be deployed. It includes the device that
ed
represents the vehicle ECU (carrier board embedded with NXP i.MX 8M Plue Computer on Module
Verdin iMX8M Plus), the network, The Host Machine, and the Torizon cloud.
4.1.2 Torizon Cloud (Off-board System)
iew
Torizon Cloud is a cloud-based Software as a Service (SaaS) solution that seamlessly integrates with
Torizon OS (formerly TorizonCore) and the development tools TorizonCore Builder and Torizon IDE
Extension, enabling a streamlined development and maintenance workflow.
r ev
er
pe
Figure 10: Illustrative High-level System Architecture
It implements a centralized update management system to ensure secure and reliable updates of
ot
the Operating System (OS), Applications, and Bootloader. It also leverages synchronous updates to
streamline the update process, handling both the OS and applications as a single component and
also automating update triggers to initiate deployments whenever new updates become available. It
incorporates a safe mechanism to roll back automatically to the last working version of the OS or
tn
application in case of an update failure, and finally, it employs update-blocking capabilities to prevent
application-initiated updates, ensuring uninterrupted operation of critical applications, among many
other capabilities not relevant to OTA update. The main components of Torizon Cloud are [14]:
• Torizon Cloud Web UI: The Torizon Cloud Web UI serves as a user-friendly interface for managing
rin
your account, software, devices, fleets, and update information. It provides a centralized platform
for overseeing your entire IoT infrastructure.
• Torizon Cloud Servers: These servers host all the critical information about your devices, software
packages, updates, and security metadata. This includes encryption signing keys for quick-
starting purposes, allowing for rapid deployment of IoT devices. You can also maintain this
ep
metadata offline for enhanced security.

• Torizon Cloud OSTree Repository: This repository stores your OS images, ensuring that the
operating systems for your IoT devices are readily accessible and easily managed.
• Torizon Cloud API: The Torizon Cloud API provides a convenient and easy-to-integrate interface
Pr
for interacting with Torizon Cloud features. It enables you to seamlessly integrate Torizon Cloud
with your own cloud solution, offering greater flexibility and a seamless end-user experience.
• Your Container Registry: Torizon builds and stores information about your packages, but you
have the flexibility to host your application images in the container registry solution that best
16
suits your needs. This allows you to customize your IoT deployment according to your specific
requirements.
ed
4.1.3 Carrier Board (On-board or Vehicle Device/ ECU)
The carrier board in the high-level system architecture is a Yavia board embedded with a NXP
i.MX 8M Plue Computer on Module Verdin iMX8M Plus(SoM). The Yavia board is designed to
iew
facilitate the application of software development; it offers a compact and user-friendly platform
for accessing the most prevalent features of the Verdin family With seamless compatibility with
both existing and forthcoming Verdin SoMs, which in our case is the Verdin iMX8M Plus.
The Yavia carrier board stands as a versatile and future-proof solution for embedded systems
development, enabling various connectivity such as USB 3.x, Gigabit Ethernet, HDMI, MIPI
CSI or PCIe, etc. For more detail see [20]. The embedded SoM (System on Module) Verdin
iMX8MP to the Yavia carrier board is powered by the NXP i.MX 8M Plus family of embedded
ev
processors. The i.MX 8M Plus family comprises three variants: i.MX 8M Plus Quad, i.MX
8M Plus QuadLite, and i.MX 8M Plus Dual. The top-of-the-line i.MX 8M Plus Quad features
four Arm® Cortex®-A53 cores as its primary processor cluster. These cores provide full 64-bit
Arm®v8-A support while maintaining seamless backward compatibility with 32-bit Arm®v7-A
software. The main cores operate at up to 1.8 GHz for commercial-grade products and 1.6 GHz
r
for industrial-temperature-range products. The Verdin iMX8M Plus caters to a diverse range of
applications, including Industrial Automation, Medical, Transportation, Smart Cities, Test and
Measurement, and many more. The module offers a comprehensive suite of interfaces, ranging
er
from basic GPIOs to industry-standard I2C, SPI, CAN-FD, and UART buses, along with PCI
Express interfaces. The Verdin iMX8M Plus module features an integrated Gigabit Ethernet
PHY with Time-Sensitive Networking (TSN) and IEEE1588 support. For further details see [1].
These both form the Hardware of the system that receives and installs the OTA updates.
pe
4.1.4 Host Machine
The Host machine is used for hosting Torizon development tools, such as TorizonCore Builder
tool that allows the easy generation of a custom image of Torizon OS with device configuration
changes, a custom device tree and overlays, pre-provisioned containers, external kernel modules,
ot
and the Torizon IDE Extension 2. This final image can then be deployed to the carrier board
using SSH, Toradex Easy Installer, or Torizon Cloud updates features. The tool is designed to
be used in production programming and on development as well. See [7] for more details. Each
element within the presented high-level system architecture, composed of software, hardware,
tn
and interface components, will be individually explored and evaluated in the next section. This
analysis aims to identify potential candidate assets within the broader architecture, serving as
foundational building blocks for constructing the upcoming security architecture.. The system is
divided into three main parts: the off-board system, the on-board system, and the host machine,
all of which enable the OTA update.
rin
4.2 Torizon OTA Update on Yavia Carrier Board Embedded with

Verdin iMX8M Plues SoM
Torizon’s Remote Updates feature allows for secure and dependable remote updates of applica-
ep
tions and operating systems on Torizon OS devices. This feature is built on the OSTree and
Aktualizr technology stack. See [16]. Torizon remote update features allows the below to be
performed;
– Safely update the operating system and applications on connected devices.
Pr
– Set devices to automatically update when new versions are available.

– Perform joint updates of the operating system and applications as a single unit.
– Automatically restore the system to the previous working version if an update fails.
– Prevent updates from being applied to critical applications that cannot be interrupted.
17
4.2.1 OTA Update Limitation
ed
Our scope in this paper is to utilise the Torison platform to update the application of our
connected device (Yavia carrier board embedded with Verdin iMX8M Plues SoM). Obviously,
the focus of our methodology is not on implementing the various types of OTA updates that
can be carried out in embedded IoT’s devices, such as the Bootloader, Operating Systems,
Applications files, Calibrations and Configuration files etc. But rather we are showing the OTA
update on the application files of our device so as to enable the implementation of our adaptable
iew
security-by-design approach for ensuring a secure OTA for modern vehicles. The device (Yavia
carrier board embedded with Verdin iMX8M Plues SoM) application that is updated via OTA
is taken to be an ECU within the on-board vehicle system; in the case of the Uptane Standard,
this is the Primary ECU, and for the OMA-DM protocol, this is the OTA master (TCU). For
this paper, we are only limited to updating the OTA master or Primary ECU.
ev
4.2.2 Prerequisites for Updating Our Device
In order to perform remote updates on our device, the following are required;
The Torizon application updates are ready to be installed.
r
– Deploy Applications to a Container Using a Torizon Pre-built Image. Torizon has suggested
two options to proceed with the application update. The first option is to use a Pre-built
er
Image to deploy the applications to a Container by pulling a Toradex container image from
the server via the device terminal. However, the modifications made to applications updates
within the container will not persist after the container is shut down. Hence, our choice of
the second option of building our application image as the pre-built application image is
pe
suitable for troubleshooting or testing purposes but not for long-term development projects.
– Deploy Application in a Container Using our Custom-built Image. For this part, we carried
out the following steps illustrated in Figure 11, and for detailed steps, see [6]
Installation of TorizonCore Builder on our host machine .

This was briefly touched upon in the above section of Host Machine, but in essence, with the
ot
TorizonCore Builder, we generated a custom image for our Yavia carrier board embedded with
our Verdin iMX8M Plus (SoM), and also flashed onto the SoM using the Toradex Easy Installer
through SSH, as well as pushing to the Torizon Cloud for deploying it remotely. See [18] for
tn
more details. We registered an account with Torizon cloud in order to activate and configure
our Yavia carrier board embedded with Verdin iMX8MP. The provisioning of our device is done
in the off-board/ backend Torizon cloud by running a command that is provided in the cloud
on our Yavia carrier board embedded with Verdin iMX8MP. Torizon remote updates are the
recommended method for Over-the-Air updates using Torizon OS, which is built with OSTree
and Aktualizr together, forming the foundation for OTA update capabilities our device. [17].
rin
The credentials.zip file is downloaded from your Torizon Plattform account section.
4.2.3 Creating the Update Packages

ep
The creation of our Torizon application update package was done with our TorizonCore Builder
as detailed above and also the pushing of the application to a docker registry, so our device can
download it, although this could be done from the web UI or an IDE with an Extension for
Horizon.
Pr
4.2.4 Initiating the Update
Following the provisioning of our device in the Torizon cloud, our device is now visible for
selection, so we choose the application packages to be updated in a single device; this can also
be done in an entire fleet. As we initiate the update, four steps are required, starting with the
18
ed
iew
r ev
er
Figure 11: Deploy Application in a Container Using Custom-built Image
pe
selection of components and available update packages (including my uploaded built package),
a summary of the selection of the update package, and finally, the fourth step, the result. Our
target device or the devices in a fleet will have a new update to process when it goes online and
reaches the Torizon Cloud.
ot
4.2.5 Deploying the Remote Update
Our provisioned Yavia carrier board embedded with Verdin iMX8M will periodically search for
tn
newly available instructions and update packages on the server, and the next time our provisioned
device for updates goes online it will download, validate, and deploy the update.
5 Determination of Security Architecture

rin
Defining the security architecture of our OTA update hinges on a crucial question: how do we
assign cybersecurity requirements to various system elements (subsystems, components, and in-
terfaces) within our overall design? To answer this, we first need to confirm the OTA update’s
cybersecurity relevance, addressed in the earlier design process (Figure 5) and detailed in our
ep
prior work [36]. A decision flowchart in the concept phase guides this determination. Only for
cyber-relevant systems do cybersecurity specifications become necessary. These specifications
must include interface details between sub-components, ensuring fulfillment of defined cyber-
security requirements (static and dynamic) through their usage. Architecture modeling tools
like Enterprise Architect [12] or dedicated relationship matrices can facilitate this requirement
Pr
allocation to the architectural model. Linking requirements to architecture aligns not only with
ISO/SAE 21434 but also represents current best practices in both systems engineering and the
automotive industry.
Furthermore, the high-level systems architecture diagram for OTA updates (Figure 10) mirrors
the illustration provided in Annex H of ISO/SAE 21434 [8]. Key points to note include:
19
– Item boundary (See Figure 10),
– Item functions- Functional overview of the item: OTA updates are a way to remotely update
ed
the software in a vehicle. This can be done over a cellular network, Wi-Fi, or other wireless
network. OTA updates allow automakers to deliver new features and bug fixes to vehicles
without requiring the owner to take the vehicle to a dealership. The functional overview of
automotive OTA updates includes:
∗ The vehicle (Device)/ backend checks for updates. The vehicle/backend will periodically
iew
(every 5 minutes) check for updates from the automaker’s server (Torizon Cloud). This
can be done when the vehicle is connected to an Ethernet, cellular network, Wi-Fi, or
other wireless network.
∗ The vehicle downloads the update. If there is an update available, the vehicle will
download it from the automaker’s server. The update is typically downloaded to a
temporary storage area in the vehicle’s memory.
∗ The vehicle installs the update. Once the update has been downloaded, the vehicle will
ev
install it. This process may take a few minutes.
∗ The vehicle activates the update by reboots. Once the update has been installed, the
vehicle will activate the updates by reboot. This is necessary to ensure that the new
software is properly loaded.
r
– Illustrative High-level System Architecture (see Figure 10).
Building on this foundational assessment, we leverage ThreatGet, an automated plugin within
er
Enterprise Architecture, to guide the development of the OTA update security architecture. De-
veloped collaboratively by the AIT Austrian Institute of Technology and Lieber Group, Threat-
Get caters specifically to the automotive sector [36]. Threatget modelling is based on two com-
ponents [50]. The first component is called the System Model; in our case, this is the Security
pe
Architecture shown in Figure 12. The system model contains an abstract representation of the
system under consideration. Looking at the depicted security architecture, two systems are
identified as item boundaries: the Torizon Cloud and the carrier board in a boundary block,
and within this, these systems contained the various elements (Web UI, Server, API, Container
registry, OSTree Repository) interface, connectors, ports and asset that form the operation en-
vironment or Operational design domain (ODD). Apart from the two blocks of systems, we have
the Host machine as well as instances (Ethernet, UART, HMI display to the device etc.) of data
ot
transfer that can be seen in the depicted security architecture of the OTA update. Finally, within
the OTA security architecture are five Assets (based on Confidentiality, Integrity and Availabil-
ity) of the cybersecurity attributes and impact categories of (Privacy, Safety, Operational and
tn
Financial) that determine the part of the system that is vital to be protected based on the form
of value to the system [36]. The Illustrative High-level System Architecture, shown in Figure 10,
has been converted using the Threatget plugin in the Enterprise Architect modelling tool. This is
then modeled into a system model (security architecture) using the ThreatGet analysis language
based on five patterns (Element, Asset, Connector, Interface or Flow), each referring to one of the
diagram components. The language is designed to be modular and extensible. This means that
rin
the language can be easily modified to add new features or to accommodate new requirements.
The language structure is inspired by the data format JSON, which is a popular and well-known
format. This makes the language easy to read and write, and it also makes it easy to integrate
with other systems that use JSON [50].Building upon the design process outlined previously
above and in [36], the security architecture depicted in Figure 12 emerges directly from the item
ep
definition stage of the concept phase, informed by our prior cybersecurity relevance assessment.
However, to effectively conduct a cybersecurity risk assessment for the OTA update system, a key
question remains: how can we develop a standardized Threat Assessment and Risk Assessment
(TARA) framework suitable for automated, efficient, and scalable deployments, supporting the
security-by-design approach for a specific system like the Uptane OTA update?
Pr
The answer to the above question is based on the analysis of using the second component in
ThreatGet called Threat Model. The threat model represents a knowledge base of known vul-
nerabilities and threat scenarios, including their exploitation techniques and methods[50]. This
threat model analysis leverages the STRIDE mnemonic, a framework devised by Microsoft for
20
ed
iew
ev
Figure 12: Security Architecture
r
identifying potential threats by categorizing them into six distinct classes. STRIDE stands for
er
Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service, and Elevation of
Privilege. These categories represent fundamental attack methods that can be applied to var-
ious systems, including the one under examination. By exploring how each STRIDE category
might translate into specific threat scenarios relevant to our context (see [32]), we can anticipate
pe
and mitigate potential security vulnerabilities. The threat model is based on a set of rules that
are specified using a Domain-Specific Language. The rule consists of a title, a description, an
assigned threat type, an impact estimation, a likelihood estimation, and, most importantly, the
so-called Pattern [50]. The principle of THREATGET is based on the automatic comparison of
system model (which is generated from the system-level architecture) and the Threat model [50].
See Figure 13 below for the risk assessment process, which shows the different aspects that need
to be taken into consideration in answering the above question.
ot
5.1 Asset Identification

tn
Pinpointing a system’s critical cybersecurity assets is the core of asset identification. Components
or parts become assets when their loss significantly impacts stakeholders, be it operationally,
financially, or in terms of safety or privacy. Each such asset, as Cyres notes, inherently possesses
at least one cybersecurity attribute like confidentiality, integrity, or availability [5]. Moreover,
[8] mandates damage scenario creation in the asset identification phase (requirement RQ-15-
rin
01), emphasising the need to identify assets whose compromised cybersecurity properties could
materialize into detrimental consequences (RQ-15-02).
5.2 Impact Assessment

ep
While analyzing damage scenarios helps us understand the negative consequences of compromised
assets, it doesn’t directly compare their relative severity. This necessitates returning to the core
objective of risk assessment, as [5] emphasises. To achieve an unbiased evaluation of harm, an
impact assessment rating system (impact rating method) becomes crucial. Unlike asset and
threat scenario identification, [8] offers a specific approach for impact assessment, outlined in
Pr
Table 6 by Iyieke et al [36].
21
ed
iew
r ev
er
pe
Figure 13: A process of risk assessment according to [8], [36]
Table 6: Impact assessment requirement [8], [36]

Impact assessment section 15.5.2
[RQ-15-04] The damage scenarios shall be assessed against potential adverse consequences
ot
for road users in the impact categories of safety, financial, operational, and privacy
(S, F, O, P), respectively.
[RQ-15-05] The impact rating of a damage scenario shall be determined for each impact
category to be one of the following:
tn
— severe;
— major;
— moderate; or
— negligible.
rin
[RQ-15-06] Safety-related impact ratings shall be derived from ISO 26262-3:2018,

6.4.3. [PM-15-07] If a damage scenario results in an impact rating and an argument
can be made that every impact of another impact category
is considered less critical, then further analysis for that other impact category
may be omitted.
ep
5.3 Attack Path Analysis

Building on [36], attack trees serve a dual purpose in automotive cybersecurity: aiding threat
analysis and risk assessment throughout a vehicle’s lifespan [8]. Unlike fault trees, which de-
Pr
pict passive issues, attack trees map intentional, malicious actions an adversary might take to
compromise the target vehicle [48]. For detailed methods and applications of attack trees, refer
to[46, 39, 25, 48, 30] and [28]. As specified in requirement RQ-15-08, attack paths should men-
tion the threat scenarios they enable. Therefore, we analyse threat scenarios to identify attack
22
paths, ensuring each path links to realisable threat scenarios [8]. Now, with established attack
vectors, the next step is to estimate the likelihood of each scenario materialising into an actual
ed
attack, informing risk assessment. To refine this estimation, attack path analysis delves deeper,
meticulously documenting the specific steps an attacker might take to execute threat scenarios.
[8] proposes two methods;
– Vulnerability-driven (Bottom-up): This approach starts with a known vulnerability and
explores potential attacker actions that could lead to successful exploits, ultimately mapping
iew
out possible threat scenarios.
– Initial weakness-based (Top-down): Taking an initial system weakness as a springboard, this
method identifies potential attacker actions and sequences that could exploit said weakness
and ultimately culminate in realized threat scenarios.
5.4 Attack Feasibility Rating
ev
Building on our work in [36], we assess component vulnerability using attack feasibility rating.
To quantify risks, we develop threat scenarios identifying potential attack methods, followed by
meticulous attack path analysis pinpointing specific exploit possibilities. analysing attack path
information plays a critical role in gauging feasibility and likelihood. As [5] points out, quantifying
r
attack probability and potentially pairing it with a quantified impact measure facilitates efficient
numerical risk assessment. Table 7 outlines this key principle’s relevant requirements in [8].
5.5 Risk Value Determination er

Effectively prioritising cybersecurity investments hinges on a key TARA step: merging the out-
pe
puts of impact and attack feasibility assessments into a unified risk level. This harmonizes
perfectly with TARA’s core objective – strategic allocation of security resources. Echoing [8]
(RQ-15-15, RQ-15-16), each threat scenario’s risk score emerges from the combined severity of
potential damage scenarios and the likelihood of corresponding attack paths. This risk score
spans 1 (minimal) to 5 (highest), as defined in [8] and further clarified in [36].
ot
5.6 Risk Treatment Decision

While prior discussions on risk assessment focused on identifying the most pressing threats for the
efficient allocation of cybersecurity resources, the crucial question of how to address those risks
tn
remains. The risk level determined earlier helps prioritise but doesn’t provide specific mitigation
strategies. Section 15.9.2 of ISO 21434 provides guidance in [RQ-15-17], as highlighted in [8].
These steps include:
– Eliminating: Remove the risk source or avoid activities that create it,
rin
– Reduction: Implement measures to minimize the likelihood or impact of the risk,

– Transfer: Share or distribute the risk through contracts or insurance,
– Acceptance: Acknowledge and manage the risk within acceptable parameters.
By drawing upon these options, we can move beyond mere risk identification and embark on
ep
effective risk management within the cybersecurity context.Additionally, it addresses the above
question on how we formulate a TARA for a given OTA update system. Leveraging ThreatGet
within Enterprise Architecture, we automate a comprehensive threat analysis using the security
architecture outlined in Figure 12. ThreatGet streamlines the various sections of Figure 13’s
risk assessment process (see Appendix A for a screenshot of the model). Our automated TARA
Pr
analysis, powered by ThreatGet, identified 151 distinct threats classified based on the STRIDE
model and drawing from diverse sources: UNECE WP29 Vehicle Threat List, European Telecom-
munications Standards Institute (ETSI), International Telecommunications Union (ITU), AIT
expertise, and academic literature. Figure 14 summarises these threats alongside their severity
levels.
23
ed
iew
r ev
er
Figure 14: OTA Update TARA and Severity Summary
pe
ThreatGet analyses potential hazards from its knowledge base, assigning each a likelihood and
impact score. Figure 14 presents these threats categorised by severity. Building on this, Figure
15 uses ThreatGet’s risk matrix (aligned with [8] and illustrated in [36]) to assign risk levels
based on individual threat impact and likelihood scores. Therefore, we leverage ThreatGet to
assess the severity of OTA update risks posed by each identified threat, assigning scores between
1 and 5 using this standardised risk matrix.
ot
tn
rin
ep
Figure 15: Security risk matrix severity from 1 to 5

Pr
24
6 Formalisation of Highest Level of Threats With a Cor-
responding Mitigation Action
ed
Following on from our works in [36], defining the highest-level threats discovered in the OTA
system and outlining corresponding mitigation actions (presented in Appendix B) is a key cyber-
security goal. Essentially, this involves linking concept-level cybersecurity requirements, based
on one or more STRIDE threat scenarios, to specific OTA update assets (vulnerable properties
iew
identified by the aforementioned model). Mitigation options, such as applying controls from
our layered security concept (Figure 8), are then mapped to these threats. By filtering our
ThreatGet-generated OTA update TARA down to the 20 most severe threats (level 3 and above
in STRIDE categories), as shown in Figure 16, we can prioritise requirement formulation. Con-
r ev
er
pe
ot
tn
Figure 16: Formalisation of threats analysis from risk level 3
sidering our Logical Security Layered Concept (3.2), we recommend referencing UNECE WP29
Annex 5 (threat-mitigation pairings, part B) [11]for these high-severity threats.
rin
ep
Pr
25
7 Verification
ed
Building upon the layered security concept outlined in Section 2.2 and Figure 8, several key
elements bolster the resilience of our OTA update systems against high-priority threats, par-
ticularly Denial-of-Service (DoS) and Tampering (as shown in Figure 10). Verification through
cybersecurity penetration testing confirmed this, focusing on DoS attacks targeting the Torizon
Cloud backend, which connects the NXP i.MX8M Plus-based Device (Yavia board) and the host
iew
machine. This testing ensures a functional OTA update system capable of receiving cloud-based
updates as specified by the campaign manager. The test specifically focused on the web UI
within the Torizon Cloud, as it serves as the interface between the Device, host machine, and
backend service. A SYN flood DoS attack simulated an attacker overwhelming the target with
malicious data packets, aiming to disrupt its functionality (source: [13]). Our TARA analysis
identified DoS as the most critical threat requiring immediate attention, excluding Tampering.
Appendix C provides a sample requirement and use case for the penetration test, adapted from
ev
UNECE WP29 (source:[11]). This adaptation strengthens the security of our OTA update sys-
tems against targeted risks and threats, based on our methodology and the TARA-identified DoS
vulnerabilities. The DoS testing covered various attack vectors across the OTA update system,
including the secure backend service (layer 1), secure vehicle communication channel (layer 2),
and secure vehicle external connectivity/connections (layer 5, as detailed in Figure 88).
r
7.1 Cybersecurity Penetration Testing
er
The requirements and use cases in Appendix C are tested against denial of service (DOS) attacks
as identified by the TARA formalization of the highest level of threats discovered in the OTA
update system in section ?? above. We utilised a laptop with Windows edition: Windows 10
Enterpise. Processor: Inter® Core(TM) i5-8265U CPU @1.60GHz. Installed memory (RAM):
pe
8.00GB. Ensuring re-conditions such as;
– Installing of Oracle VM Virtual Box, and installing of Kali-Linux (though an alternative
method is available when using a different Operating system);
– Connect the Laptop to the same network hosting the TOrizon platform and the IP address
details of the target.
ot
Furthermore, our test procedure for the SYN flooding of DOS attack utilised the ”HPING3”
command by opening the window command prompt, checked for own IP address,login to terminal
emulator of the Kali Linux virtual machine, checking for the target host IP address from the Kali
tn
terminal, starting the Syn DoS attack on the targeted host by using hping3 (flood), and finally
Opening 4-10 kali-linux terminal and repeat the above steps
7.2 Discussion
rin
From our attacking machine, upon initiating the DOS attack sudo hping3 -S 192.168.xx.x -a
10.10.x.xxx -p 22 –flood the target host (the web UI of Torizon Cloud) responded with ” A
webpage is slowing down your browser,” and ” A script on this page may be busy or it may
have stopped responding. You can stop the script now, or you can continue to see if the script
will complete”. From the kali linux terminal, a message ”hping in flood mode, no replies will be
ep
shown” was revealed, indicating that the hping3 program is operating in ”flood mode,” which
means that it is sending packets to the target device as fast as possible without waiting for
replies. In this mode, hping3 does not print any replies to the console, as it is focused on sending
as many packets as possible. Flood mode is a useful tool for testing network performance and
identifying potential bottlenecks, hence causing a DOS attack by intentionally disrupting the
Pr
Web UI. See Appendix D. Our simulated SYN DOS attack successfully overwhelmed our own
test machine but failed to impact the target host, the Torizon Cloud Web UI. This UI is the
admin panel for campaign managers to set up OTA updates after connecting devices to the
Torizon Cloud. Several factors limited the attack’s effectiveness. Firstly, the Torizon platform’s
underlying Uptane Framework prioritises security and includes built-in defenses against various
26
denial-of-service attacks, including the Freeze and Drop-request techniques used in our test.
Additionally, knowledge of the pen test credentials and attack origin narrowed its impact on
ed
our test machine. Other network devices connected to the same router remained unaffected,
suggesting potential security controls implemented by the Torizon platform, as discussed in
section 3.2 on the Logical Security Layered Concepts. These controls likely include firewalls or
server-side filtering based on source IP address or port, preventing targeted SYN packet flooding.
iew
8 Conclusion and future work
Modern vehicles rely on regular software updates for ongoing security, and this paper proposes
an adaptable Security-by-Design approach to secure Over-the-Air (OTA) updates against cyber-
attacks. While Security-by-Design is established for web applications (e.g., OWASP guidelines),
its application in automotive embedded systems is still evolving. Our methodology focuses
ev
on identifying potential attack vectors and threat surfaces exploitable by malicious actors tar-
geting an automotive system’s OTA update. To address this, we leverage the entire Security
Engineering life cycle and begin by analysing the OTA update’s cybersecurity relevance in the
concept phase to ensure our approach’s effectiveness. Building on this analysis, we introduce the
Logical Security Layered Concept: a framework of seven security layers encompassing various
r
control mechanisms. These layers map to the decomposition of threats, vulnerabilities, and at-
tack methods outlined in ECE/TRANS/WP.29/2020/79 (R155). This layered approach allows
for targeted implementation of security controls based on identified threats within each layer.
er
Additionally, we integrate cybersecurity activities throughout the product development process
using the V-cycle, starting with specification and requirement definition and culminating in ver-
ification and integration measures. Finally, our approach incorporates Security Architecture,
implemented through our design process, which itself leverages the Security Engineering life cy-
pe
cle and the Logical Security Layered Concept. By adopting this Security-by-Design approach,
automotive OEMs, suppliers, and other stakeholders can develop significantly more robust and
secure systems, ultimately impacting the secure development of relevant automotive technologies.
In essence, we empower stakeholders to achieve enhanced system security through our adaptable
Security-by-Design approach, contributing to the secure future of automotive systems.
For future direction, we will extend the novel Logical Security Layered Concept that we proposed
ot
in section 3.2, as a potential Software as a Service (SaaS) solution for implementing automotive
cybersecurity controls.
9 Declaration of Competing Interest

tn
The authors assert that there are no known financial conflicts of interest or personal relationships
that could have influenced the research presented in this paper.
rin
10 Acknowledgement
The authors gratefully acknowledge the invaluable support of CONIGITAL LTD for their gener-
ous sponsorship of this research through their PhD research student program. This collaboration
ep
has been instrumental in advancing our understanding of security-by-design approaches for au-
tomotive systems, building upon the important work of Iyieke et al. [36] and further broadening
our knowledge in this critical area. We sincerely appreciate CONIGITAL LTD’s commitment to
fostering innovation and research in automotive security. It is important to note, however, that
the views expressed in this publication are solely those of the authors, and CONIGITAL LTD is
Pr
not responsible for any errors or omissions.
27
References
ed
[1] ) verdin imx8mp. https://www.toradex.com/computer-on-modules/
verdin-arm-family/nxp-imx-8m-plus, Accessed on November. 2023.
[2] Autonomous vehicle: Security by design. https://arxiv.org/abs/1810.00545, jour-
nal=arXiv.org, author=Chattopadhyay, Anupam and Lam, Kwok-Yan, year=2018,
month=Oct, Accessed on 2022.02.07.
iew
[3] Cybersecurity guidebook for cyber-physical vehicle systems - sae international. https:
//www.sae.org/standards/content/j3061_202112/.
[4] Digital programming transmitted wirelessly to networked devices. https://www.
business.att.com/learn/tech-advice/know-the-term--sota-fota.html, Accessed on
2022.02.11.
[5] The essential guide to iso/sae 21434. out now! https://www.cyres-consulting.
ev
com/automotive-cybersecurity-the-essential-guide-to-iso-sae-21434/, Accessed
on Feb.2022.
[6] First steps with torizon remote updates. https://developer.toradex.com/quickstart/
firststeps/deploy-dockerfile/?module=verdin_imx8mp&carrier=yavia&host=
linux&os=torizon, Accessed on November. 2023.
r
[7] Host mechine. https://developer.toradex.com/torizon/os-customization/
torizoncore-builder-workflow/, Accessed on November. 2023.
[8] Iso/sae 21434:2021.
year=2021, month=Aug.
[9] Layered software architecture.
er
https://www.iso.org/standard/70918.html, journal=ISO,
https://autosar.org/fileadmin/user_upload/
standards/classic/4-3/AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf.
pe
[10] Omtp advanced device management.
[11] Proposal for a new un regulation on uniform provisions concerning the ap-
proval of vehicles with regards to cyber security and cyber security man-
agement system. https://unece.org/fileadmin/DAM/trans/doc/2020/wp29grva/
ECE-TRANS-WP29-2020-079-Revised.pdf, Accessed on May 2022.
ot
[12] Sparx systems. https://www.sparxsystems.com/, Accessed on July 2023.

[13] Syn flood attack: Variants and countermeasures. https://www.ionos.com/digitalguide/
server/security/syn-flood/, Accessed on June 2022.
tn
[14] Torizon cloud overview. https://developer.toradex.com/torizon/torizon-platform/

torizon-platform-services-overview/, Accessed on November. 2023.
[15] Torizon implementing uptane standard.
[16] Torizon ota update on yavia carrier board embedded with verdin imx8m plues
som. https://developer.toradex.com/torizon/torizon-platform/torizon-updates/
rin
first-steps-with-torizon-remote-updates/, Accessed on November. 2023.

[17] Torizon update client. https://developer.toradex.com/torizon/torizon-platform/
torizon-updates/aktualizr-modifying-the-settings-of-torizon-ota-client/, Ac-
cessed on November. 2023.
ep
[18] Torizoncore builder. https://developer.toradex.com/torizon/

os-customization/torizoncore-builder-tool-customizing-torizoncore-images/
#installing-torizoncore-builder, Accessed on November. 2023.
[19] What is sysml-sec? https://sysml-sec.telecom-paris.fr/.
[20] Yavia. https://www.toradex.com/products/carrier-board/yavia#features, Accessed
Pr
on November. 2023.
[21] Security by design principles according to owasp, Apr 2022.
[22] L. Apvrille. Figure 1 from sysml-sec: A sysml environment for the design and development
of secure embedded systems: Semantic scholar, Jan 1970.
28
[23] H. Bar-El. Intra-vehicle information security framework. In Proceedings of 9th Embedded
Security in Cars Conference, ESCAR, 2009.
ed
[24] M. Cebe, E. Erdin, K. Akkaya, H. Aksu, and S. Uluagac. Block4forensic: An integrated
lightweight blockchain framework for forensics applications of connected vehicles. IEEE
Communications Magazine, 56:50–57, 10 2018.
[25] M. Cheah, S. Shaikh, O. Haas, and A. Ruddle. [pdf] towards a systematic security evaluation
of the automotive bluetooth interface: Semantic scholar, Jan 1970.
iew
[26] M. Cheah, S. A. Shaikh, J. Bryans, and P. Wooderson. Building an automotive security
assurance case using systematic security evaluations. Computers and Security, 77, 2018.
[27] M. Cheah, S. A. Shaikh, O. Haas, and A. Ruddle. Towards a systematic security evaluation
of the automotive bluetooth interface. Vehicular Communications, 9, 2017.
[28] S. Chlup, K. Christl, C. Schmittner, A. M. Shaaban, S. Schauer, and M. Latzenhofer.
Threatget: Towards automated attack tree analysis for automotive cybersecurity. Informa-
ev
tion, 14(1), 2023.
[29] G. De La Torre, P. Rad, and K.-K. R. Choo. Driverless vehicle security: Challenges and
future research opportunities. Future Generation Computer Systems, 108:1092–1111, 2020.
[30] J. Dürrwang, J. Braun, M. Rumez, R. Kriesten, and A. Pretschner. Enhancement of auto-
r
motive penetration testing with threat analyses results, Nov 2018.
[31] C. Ebert and J. Favaro. Automotive software. IEEE Software, 34(03):33–39, 2017.
er
[32] D. S. Fowler. Project bearcat : Baselining, automation and response for cav testbed cyber
security : Connected vehicle amp; infrastructure security assessment, Mar 2020.
[33] D. Geer. Are companies actually using secure development life cycles?, 07 2010. Accessed
on April 2022.
pe
[34] M. Hause. The omg modelling language (sysml), 08 2007.
[35] W. He, G. Yan, and L. D. Xu. Developing vehicular data cloud services in the iot environ-
ment. IEEE Transactions on Industrial Informatics, 10:1587–1595, 2014.
[36] V. Iyieke, J. Bryans, T. Robinson, O. Kosmas, A. Shipman, and H. Jadidbonab. An adapt-
able security by design approach for ensuring a secured remote monitoring teleoperation
ot
(rmto) of an autonomous vehicle. SAE Technical Paper Series, 2023.

[37] M. Kara. Review on common criteria as a secure software development model. International
Journal of Computer Science & Information Technology, 4(2):83, 2012.
[38] B. Kim and S. Park. Ecu software updating scenario using ota technology through mobile
tn
communication network. 2018 IEEE 3rd International Conference on Communication and

Information Systems, ICCIS 2018, pages 67–72, 2 2019.
[39] S. Mahmood, H. N. Nguyen, and S. A. Shaikh. Systematic threat assessment and security
testing of automotive over-the-air (ota) updates. Vehicular Communications, 35:100468,
rin
2022.
[40] S. M. Mahmud, S. Shanker, and I. Hossain. Secure software upload in an intelligent ve-
hicle via wireless communication links. IEEE Intelligent Vehicles Symposium, Proceedings,
2005:588–593, 2005.
[41] D. K. Nilsson, T. Roosta, U. Lindqvist, and A. Valdes. Key management and secure software
ep
updates in wireless process control environments. Proceedings of the first ACM conference
on Wireless network security - WiSec ’08.
[42] D. K. Nilsson, L. Sun, and T. Nakajima. A framework for self-verification of firmwareupdates
over the air in vehicle ecus. 2008 IEEE Globecom Workshops, GLOBECOM 2008, 2008.
Pr
[43] H. A. Odat and S. Ganesan. Firmware over the air for automotive, fotamotive. In IEEE
International Conference on Electro/Information Technology, pages 130–139. IEEE, 2014.
[44] G. Pedroza, M. S. Idrees, L. Apvrille, and Y. Roudier. A formal methodology applied to
secure over-the-air automotive applications. IEEE Vehicular Technology Conference, 2011.
29
[45] R. S. Ross, M. McEvilley, and J. C. Oren. Systems security engineering: Considerations for
a multidisciplinary approach in the engineering of trustworthy secure systems — nist. 2016.
ed
[46] A. Ruddle, B. Weyl, S. Idrees, Y. Roudier, M. Friedewald, T. Leimbach, A. Fuchs,
S. Gürgens, O. Henninger, R. Rieke, M. Ritscher, H. Broberg, L. Apvrille, R. Pacalet, and
G. Pedroza. Security requirements for automotive on-board networks based on dark-side sce-
narios. deliverable d2.3: Evita. e-safety vehicle intrusion protected applications. Fraunhofer
ISI, 01 2009.
iew
[47] M. Shavit, A. Gryc, and R. Miucic. Firmware update over the air (fota) for automotive
industry. SAE Technical Papers, 8 2007.
[48] K. Sowka, L.-P. Cobos, A. Ruddle, and P. Wooderson. Requirements for the automated
generation of attack trees to support automotive cybersecurity assurance, Mar 2022.
[49] K. Strandberg, D. Oka, and T. Olovsson. Unisuf: a unified software update framework for
vehicles utilizing isolation techniques and trusted execution environments. 2021. https:
ev
//research.chalmers.se/publication/526667/file/526667_Fulltext.pdf.
[50] A. A. I. o. Technology. Threatget rules.
[51] K. C. Toth, A. Cavoukian, and A. Anderson-Priddy. Privacy by design identity architecture
using agents and digital identities. In APF, 2020.
r
er
pe
ot
tn
rin
ep
Pr
30
11 APPENDIX A
Screen shorts of OTA update security architecture model in
ed
Enterprise Architecture utilising ThreatGet as illustrated in
[36].
iew
r ev
er
pe
ot
tn
rin
ep
Pr
31
12 APPENDIX B
Formalisation of STRIDE level 3 to 5 threats and corre-
ed
sponding mitigation actions, as illustrated.[36]
iew
r ev
er
pe
13 APPENDIX C
A sample requirement and use case for the pen test
ot
tn
rin
ep
Pr
32
14 APPENDIX D
The web UI of Torizon Cloud during Dos attack, and The
ed
initiating of the attack in kali Linux terminal
iew
r ev
er
pe
ot
tn
rin
ep
Pr
33

SSRN Id4711138

Uploaded by

Copyright:

Available Formats

SSRN Id4711138

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SSRN Id4711138

Uploaded by

Copyright:

Available Formats

ed

An Adaptable Security-by-design approach for ensuring a secure

Keywords; Security-by-design, Automotive Cybersecurity, Over the Air Update (OTA),

Figure 1: OTA systems update process.

1.1 On-Board System (Vehicle)

Figure 2: OTA On-board system (Vehicle).

1.2 Off-Board System (Cloud Services)

develop secure automotive systems, regardless of the OTA framework used.

1.4 Paper Organisation

2.2 Secured OTA Update Discussion

external communication domain untouched, therefore exposing it to attack vectors. In contrast to

3.1.1 Checks for Cybersecurity Relevance

3.1.2 Concept Phase of the OTA Update

3.1.3 Item definition

3.1.4 Cybersecurity Goals and Claims

Table 1: Item definition requirement [8], [36]

relevant to cybersecurity shall be described.

goals, claims, and the TARA process. [36]

into this concept with specific examples [36]

Table 2: Cybersecurity goals[8], [36]

c) impact rating per 15.5;

d) attack path analysis in accordance with 15.6;

RQ-09-06] If the risk treatment decision for a threat scenario includes:

of [RQ-09-04] with to the results of [RQ-09-03];

of [RQ-09-06] of the item.

3.1.5 Cybersecurity Concept

Figure 7: Illustration of prerequisites required in our OTA cybersecurity concept [36]

cybersecurity requirement depicted in Table 3, remains agnostic regarding specific technologies or

• Analysis of stakeholder requirements, cybersecurity goals, and claims;

• Relevant cybersecurity controls for cybersecurity goals;

3.1.6 Verification of Cybersecurity Concept

3.2 Logical Security Layered Concept

Cybersecurity Requirement Specification Activities: The heart of cybersecurity planning lies

address the identified requirements; and

completeness, correctness, and consistency with the cybersecurity specifications

by [5] noted by [36].

Implementation Of Our Approach

4.1 System-Level Architecture

4.1.2 Torizon Cloud (Off-board System)

metadata offline for enhanced security.

4.2 Torizon OTA Update on Yavia Carrier Board Embedded with

– Set devices to automatically update when new versions are available.

The Torizon application updates are ready to be installed.

Installation of TorizonCore Builder on our host machine .

4.2.3 Creating the Update Packages

4.2.4 Initiating the Update

4.2.5 Deploying the Remote Update

5 Determination of Security Architecture

Building on this foundational assessment, we leverage ThreatGet, an automated plugin within

5.1 Asset Identification

5.2 Impact Assessment

Table 6 by Iyieke et al [36].

Table 6: Impact assessment requirement [8], [36]

[RQ-15-06] Safety-related impact ratings shall be derived from ISO 26262-3:2018,

5.3 Attack Path Analysis

5.4 Attack Feasibility Rating

5.5 Risk Value Determination er

5.6 Risk Treatment Decision

– Reduction: Implement measures to minimize the likelihood or impact of the risk,