© The Author(s) 2025. Published by EDP Sciences and China Science Publishing & Media Ltd.

1. Introduction

There are two possibilities for a system to be anomalous as a result of being attacked: One is that it has been directly attacked, and the other, it has been indirectly affected by other associated system that is operating abnormally after being attacked. For the first situation, we are concerned about how to quickly repair the system and recover the business capacity it supports. This type of attack has been described by many threat models [1–5]. However, for the second situation, a system may not have the opportunity to be directly attacked, but the possibility remains for it to be affected by the businesses of other systems on which it depends. Once an adversary discovers a business that can affect the target system and finds a vulnerable upstream business for it, attacking the business will cause system’s abnormal operation become inevitable. For example, in the scenario of an airline architecture¹, it may be difficult for an adversary to launch a direct attack against the architecture and make it paralyzed. However, if the adversary is possible to attack the ticketing system and make it unable to recognize passengers’ boarding documents, this will prevent a large number of passengers from boarding their flights by crowding the ticketing halls, resulting extensive delays in departing flights, and ultimately paralyzed the airline architecture.

While it is common knowledge that cross-architecture businesses have strong dependencies among different architectures, the pattern of attack based on dependencies among businesses has been long neglected, there are no models or analytical tools to discuss it, and existing threat models describing attacks on systems, are also unable to express it.

The effects that threats transmit and affect among businesses which caused by the pattern of attack. We refer to this pattern of affecting as “Threat Ripple”. The gap of the discussion in the characterization of the threats to the systems needs to be filled from the perspective of business dependencies.

1.1. Why are dependencies among businesses ignored?

On the one hand, it is because we have long believed that a system is equivalent to a platform, and that if the platform is running well, the supporting business is functioning properly. On the contrary, if the platform runs abnormally, it will inevitably affect the business functions. Therefore, we often strip away business and focus only on whether the platform is being attacked, and all our efforts in system security are focused on platform security. This fact is confirmed by the large number of attacks which patterns are “attack-direct”, i.e., the attackers launch a scan to find vulnerable platforms, and then attack on the vulnerable points [6–11]. However, due to the long common understanding of conflating business security with general application security, we ignore the fact that attack the platform and attack the business are two different ways can both affect the operation of the system. For example, the nature of a DDoS attack is not to attack the platform, as its purpose is to consume the service capacity of the target. Although the effect of DDoS attacks on the business level has been widely reported, it is still customarily to categorize them as attacks on the platform.

On the other hand, in threat scenarios, even though some of the systems’ businesses are out of service, we usually don’t consider them as the real target of the adversary because those platforms are not running abnormally. For some adversaries, their intention is to disrupt upstream businesses through the platforms, thereby affecting downstream targeted business in the business dependency sequence, so ostensibly the compromised platforms themselves did not appear to be operating abnormally. If we concern ourselves with attacks aimed at paralyzing the business, then we will focus on the business dependencies. For some APT organizations, the difference between these adversaries and the attackers is that the adversaries’ attack mode is “direct-attack”. They will utilize any means to achieve their goal of paralyzing the business. When it is impossible to attack the target’s support platform (e.g., the platform is network and physically isolated) or the other platforms which it depends (e.g., isolated intranet host supporting Iranian nuclear weapons integration operates independently of other platforms), they usually attack the upstream business to affect the target business through “business-to-business” dependencies [12–16].

For example, in version 1.x of the Stuxnet virus, the adversary inserted into the PLCs which used to control the centrifuges was not to disrupt their original functions, but affect the downstream businesses through them. The adversary modified centrifuges operating data and led to their abnormal speeds, so the downstream uranium separation business could not meet the requirements of weapons production–the adversary achieved the goal of stagnating the development of nuclear weapons [13, 14, 16]. Besides this, the Ukrainian blackout event was also a case of a cyber-attack affecting a non-cyber business [15].

These attacks, which seem to be on the platform but are actually on the business, give us an inspiration: it is not necessary to attack the support platform to affect a business; if the business belongs to a business dependency sequence, the adversary makes its upstream business operate abnormally, it will also cause the downstream target business to become abnormal. Therefore, only by solving the business-oriented attack description and expressing the effects brought by the business being attacked, we could accurately characterize the threat ripple effects even more and construct a complete architecture threat model.

1.2. How to characterize business-oriented attacks?

In order to express the threat events more accurately, we decompose the system into “platform + business” from the adversary’s intention, in order to characterize the two attack modes of “attack-direct” and “direct-attack” from the vulnerability level of the platform and the dependency level of the business. We construct a new architecture model to express the information interactive relationship among the platforms and the businesses. Also, we construct a threat ripple model combined with the architecture model, to characterize the transmissions and attribute changes of threats among the associated systems in the architecture after the architecture being attacked. A specific business may have difficulty to find a direct path to attack it, but it can be affected by other businesses it depends, which can result in the specific business being affected or even paralyzed by the associated effects.

Our threat ripple model not only take into account the focus on attacks against platforms and businesses in a traditional sense, but also the ripple effects of threats within business-to-platform and business-to-business which been long neglected, and characterize the entire effects of attack on an architecture accurately and completely.

Our model can also effectively express the logic of attack that aiming cross-modal architecture which has completely different attributes from the target architecture but has a strong relationship with, in order to affect the target architecture, e.g., via launching attacks on businesses outside the target architecture through social network attacks, social engineering, supply cutoffs, etc., utilizing the threat ripple effects to affect businesses inside the target architecture and make them operate abnormally. This provides a theoretical basis for characterizing the logic of threat transmissions among cross-modal businesses.

Our contributions:

• Construct an architecture model that integrates the platform and the business. The model provides a perspective that can directly observe the business, while the normal operating of the business is the most fundamental security factor of a system, and the purpose of attacking the platform is essentially to attack the business. In this paper, we construct an architecture model that can characterize the information interactive relationship among the platforms and the businesses, which can help to build endogenous security in the process of architecture design, operation and maintenance, also discover the transmission paths that enable risks and threats to spread the effects, in order to settle the potential security problems existing in the current information architecture in advance.

• Construct a threat model that reflects the ripple effect of threats utilizing the dependencies among businesses. This paper proposes a threat model from a business perspective that can characterize the propagation of threats utilizing dependencies among businesses. It can express the logic of the transmission and of threats in the architecture after the architecture being attacked. This helps defenders quantify the business effects of the threats as they respond and assess the threat events while encountered. Actually, our threat model can also characterize the logic of generate ripple effects by disrupt or interfere the business support elements, e.g., operational crew, physical resources, and operating capital, of the target architecture.

• Propose a methodology to discover and determine the vulnerable points of business and platforms in the architecture. For the business logic in the architecture, our threat ripple model is able to determine which platform or business could affect the important business once they are attacked. This helps the defender to infer which nodes are the adversary’s key targets, thus determine the security guarantee nodes for business. Defenders could characterize their architecture according to our model, then infer attacks through the threat model, and finally locate platform and business vulnerabilities directly. Besides security assessment, through building threat ripple model, defender is able to stop new effects in time that might transmit from the threat generated by attack, even if the attack has already occurred. In addition, this paper could also guide our attention to vulnerable business and platform elements in other cross-modal architectures, which could affect the current architecture through threat ripple if they are attacked.

The remainder of this paper is organized as follows. In Section 2, related work about threat models are discussed. In Section 3, the architecture model is constructed to characterize the dependencies among platforms and business. Section 4 introduces the definition of threat ripple. In Section 5, the threat ripple model is constructed based on the architecture model. Section 6 characterizes a typical cyberattack threat event utilizing the threat ripple model. Section 7 introduces how to make attack inference through our models. Finally, Sections 8 and 9 provide the discussion on future research directions and conclusion of this study, respectively.

2. Related work

From an adversary’s and a defender’s perspective, we divide threat models into two categories.

2.1. Adversary-oriented threat model

The most representative cyber kill chain model divides the life cycle of an attack into seven phases [17]. Besides, SANS Malware Forensics Kill Chain [18], ArcSight Attack Life Cycle [19], United States DoD Cybersecurity Kill Chain [20], Industrial Control System Cyber Kill Chain [21], Unified Kill Chain [22] are also typical kill chain models. Although they can be used to characterize the process of an adversary’s attack on an asset, they lack the coverage of the threat transmission process among businesses after the attack.

For threat models oriented to attack behaviors and actions, the MITRE’s Adversary Attack, Techniques & Common Knowledge (ATT&CK) is an adversary model and framework for describing the actions an adversary could take to compromise and operate within an organization network [23]. NIST SP 800-30 list of threat events [1], CAPEC [24], MITRE’s TARA [25] provide resources of threat modeling from tactics, techniques, and procedures-oriented dimensions (TTP), greatly improves the ability of the defender to investigate the adversary. But these models express the attack exclusively as an attack action on the platform, and none of them consider the attack on the business.

2.2. Architecture-oriented threat model

Previous studies have constructed typical generic frameworks and models that could be applied in large information system scenarios including ONDI Cyber Threat Framework [26], Cyber Prep 2.0/DACS [27], Attack Tree Model [3]. These frameworks and models provide clear approaches to describe the threats facing cyber asset systems. In threat and risk assessment, OWASP [28], PASTA [29] and ADVISE [30] provide modeling methods orienting technology to assess the risks to the system. Models that support design analysis and test including STRIDE & DREAD [5], NIST SP 800-154 [4], and OCTAVE [2] can help systems to assess their security. But these models are constructed from the perspective of the platform.

Structured Threat Information eXpression (STIX) uses adversary TTPs, attack events, process of actions, targets to exploit, threat actors, and other methods to provide a common mechanism for adding structured cyber threat intelligence information across a range of use cases for improving consistency, efficiency, interoperability, and overall situational awareness [31]. In terms of the secure design of the system, for large systems or architectures with complex integration and interoperability challenges, TOGAF [32] and DODAF [33] provide approaches to designing, planning, implementing, and managing enterprise information and technology frameworks. The two models are generally used to model at four levels including business, application program, data, and technology. Furthermore, DODAF also supplies operation diagrams to provide visualized information of base structure for issues concerned by specific stakeholders. However, neither these models nor security design approaches to the systems or architectures take business security into account.

3. Architecture model

We constructed an architecture model, shown in Figure 1, to express the mission processing pattern of the information architecture and the relationship between the platform and the business:

Platform refers to the infrastructure which support the business operation through running code, expressed as a solid rectangle.

Business refers to the service functions that the system provides to the outside world through data, expressed as a solid ellipse.

The information interactions between them have been labelled in Figure 1, where we have used single line arrows to express the code stream and double line arrows to express the data stream. There are four corresponding binary relations:

Command transmit: Platform → Platform. Commands are transferred from platform to platform through code stream to achieve functional synergy among platforms.

Business Data transmit: Business → Business. Information is transferred from business to business through business data stream to achieve capability synergy among businesses.

Support: Platform → Business. The platform supports its corresponding business through running code. Once the platform is down, the corresponding business naturally disappears.

Operate Data transmit: Business → Platform. Business uses its corresponding platform through entering operation data into the platform. Note that for a platform, the business which inputs operate data to, and its supporting business, are not necessarily to be the same.

Based on the operation and management patterns of the architecture, the operators can characterize the business processes that correspond to each mission, as well as the involved interactions, data flows and capability dependency information among the platforms and the businesses, with timely updates as the architecture evolves and adapts.

Figure 1. Architecture model

4. Threat ripple

We define the new objects added to the following definitions as follows: the threat source is the adversary (including attacker) who initiates the threat event, or the agent that can be used to initiate the attack, expressed as a circle. We use single line arrows to express the path of the threat source using code stream to attack and affect the platform, and double line arrows to express the path of using data stream to attack and affect the business.

Predefinition 1: Attack platform

The traditional pattern of attacks on platforms is that an adversary who successfully attacks a platform will use it as a springboard to move on to the next platform. The attack path from the initial platform to the target platform can be used to describe the adversary’s specific attack behavior. Therefore, the attack on these platforms is a sequence of network nodes, denoted as Q_p=[P₁, P₂, …, P_n], as shown in Figure 2a. And current cyberattacks in actual fact make threats to be transmitted between platforms and ultimately have an effect. The process of adversary launching a cyberattack is, in fact, the process threat transmitting among platforms and finally causing effects just like the definitions of cyberattack and cyberattack lifecycle:

Cyberattack. An attack, via cyberspace, targets an enterprise’s use of cyberspace for the purpose of disrupting, disabling, destroying, or maliciously controlling a computing environment/infrastructure; or destroying the integrity of the data or stealing controlled information [34].

Cyberattack lifecycle. Reconnaissance, Weaponization, Delivery, Exploitation, Installation, Command and Control, and Actions on Objective [17].

Figure 2. Attacks launched by the adversary. (a) Attack Platform. (b) Attack target business through dependent business. (c) Attack target business through business dependency sequence. (d) Attack support platform to affect target business

The current definition of cyberattack has been essentially limited to the attacks on platforms, so do the cyberattack lifecycle was also limited to the process of spreading the threat among platforms. What happened among platforms and businesses were neglected in both definitions above.

Predefinition 2: Attack Business

There are dependencies between businesses in an architecture, i.e., the normal operation of a business depends on the preceding business provides with normal data, and we say that the operational capability of that business depends on the preceding business. Therefore, for business B_n, its business operation capability depends on the business B_n−1 in front of it, and attacking business B_n−1 will lead to abnormal operation of business B_n as shown in Figure 2b.

For business dependency sequence Q_B=[B₁, B₂, …, B_n], interrelationships f_supply exist between businesses:

$$f_{\mathit{supply}}:\hspace{0.5em}{B}_{i-1}\to B_i,i\in [1,n]$$

i.e., for the business B_n in the sequence to operate normally, it is necessary for any of the businesses in front of it to be able to provide normal dependent data to the one behind it, as shown in Figure 2c.

If any of the business in Q_B is attacked and operates abnormally, it will lead to its inability to provide normal dependent data to its subsequent business, which will eventually and inevitably lead to the abnormal operation of B_n. Therefore, we have the definition of attack business:

Attack business. If the adversary’s goal is to make business B_n operate abnormally, then attack any of the business in its business dependency sequence Q_B will achieve the goal.

Predefinition 3: Utilizing relationships between platform and business to execute attacks

Since each business requires a support platform for its normal operation, if the adversary’s goal is to complete an attack on B_n, an attack on P_n−1 will also be able to achieve the goal of attacking B_n. This is because a successful attack on P_n−1 results in abnormal operation of B_n−1, which leads to abnormal operation of B_n, as shown in Figure 2d.

We denote the support platform required for the normal operation of any one of the business B_i in the business dependency sequence Q_B as P_i², there is a interrelationship f_support between them:

$$f_{\mathit{support}}:P_i\to B_i,i\in [1,n]$$

i.e., an adversary launching an attack on P_i which is the support platform for any of the business in Q_B, is able to complete an attack on B_n. Because once P_i is running abnormally, it will inevitably result in losing support and operating abnormally of B_i, which will cause the threat to be transmitted in Q_B and ultimately lead to the B_n operating abnormally. as shown in Figure 3.

Figure 3. Attack a support platform in business dependency sequence to affect the target business

Therefore, we have the definition of attack business support platform:

Attack business support platform to affect business. If the adversary’s goal is to make business B_n operate abnormally, launch an attack on its support platform P_n, or launch an attack on the support platform P_i of any business B_i in the business dependency sequence, will be able to achieve this goal.

Definition of threat ripple:

We combine the above predefinitions and generalize the way of attacking the business to get the definition of threat ripple:

Threat ripple. When the operation of target business depends on the operation of its preceding businesses, and they form a business dependency sequence, then attacking any business in the sequence (including target business), or attacking the platform that support it, will lead to abnormal operation of the business and all its subsequent businesses, ultimately make the target business operation abnormal. We define this pattern of threat transmission among businesses as threat ripple.

The pattern of utilizing threat ripples to attack the target business is applied to attack information architectures with complex business dependencies. Typically, during the design, construction and management of the architecture, the business coordinations and processing processes that execute to fulfil the missions, as well as the specific support platforms required for the operations, have already been determined. The adversary can obtain this information through intelligence gathering, network scanning, etc., and then explore the vulnerable objects and develop attack plans.

5. Threat ripple model

In this paper, a threat ripple model is constructed based on the architecture model, which is used to express the logic of threat transmission within the architecture after the architecture been attacked.

The normal state of a platform and business is the state in which it is able to perform its intended mission correctly and safely, and the abnormal state of a platform and business is a state in which its resources, functions, privileges, operation or running, data or communications are suffered in such a way that it is unable to perform its intended mission correctly and securely. When threats are encountered, the transition from a normal state to an abnormal state, is results from the platform or business operating in order to complete the mission after receiving unanticipated inputs. We abstract the actions of threat transmission that lead to changes in the operational state of the platform and the business into two types: attack and affect.

For platform, the attack is defined as changing the running state of the platform through code with attack attributes.

For business, the attack is defined as the action of changing the operational state of the business through data with attack attributes.

The affect is defined as without any new attack code or attack data, but due to its own running state or operational state being affected, platform follows the normal logic of interacting with associated platform in code will cause the associated platform’s running state to change, as well as business follows the normal logic of interacting with associated business in data will cause the associated business’s operational state to change.

Threats can arise after the platform and business being attacked or affected, and can be transmitted through data streams or code streams.

5.1. Objects definition

In the model, we define the newly added objects as follows:

Affected Platform is defined as a platform that suffers an attack or effect and results in an abnormality in the running state of the platform and is able to continue spreading its effects outwards and affecting other platforms or business, expressed as a dotted rectangle. After being attacked and compromised, then it can be the adversary’s new threat agent and will be able to launch another attack.

Affected Business is defined as a business that suffers an attack or effect and results in an abnormality in the operating state of the business and is able to continue spreading its effects outwards and affecting other businesses or platforms, expressed as a dotted ellipse.

The presentation of the dotted lines in the figures means that they are no longer secure and that they will continually spread threats outwards, thus becoming new threat transmitters.

If the platform or the business was attacked or affected, even though the outcome affects the platform’s operation status and the business’s operation status, these threats are no longer spreading, or the consequences of the threats are within the intrusion tolerance of platform’s running or business’s operations, then their markings will remain and they are still expressed as solid rectangles and solid ellipses. The presentation of the solid lines in the figures means that although they are affected, the threat does not spread and they do not become new threat transmitters.

5.2. Relationship definitions

We provide a formal representation of the relationships between objects in the threat ripple model. We define the threat ripple model L:

$$L=\{S,F,G\}$$

where S is defined as the set of all objects in the model L, F is the set of attack functions, and G is the set of affect functions. For S:

$$S=\{\mathit{Threat}\hspace{0.5em}\mathit{Source},\mathit{Affected}\hspace{0.5em}\mathit{Platform},$$

$$\hspace{0.5em}\hspace{0.5em}\hspace{0.5em}\hspace{0.5em}\hspace{0.5em}\hspace{0.5em}\hspace{0.5em}\hspace{0.5em}\hspace{0.5em}\hspace{0.5em}\hspace{0.5em}\hspace{0.5em}\hspace{0.5em}\hspace{0.5em}\mathit{Affected}\hspace{0.5em}\mathit{Business},\mathit{Platform},\mathit{Business}\}$$

For the objects of the threat’s action, there exists subsets: S_k, S_t, S_p, S_b⊂S, where:

S_k is the set of objects that launch the attack, i.e.:

$$S_k=\{\mathit{Threat}\hspace{0.5em}\mathit{Source},\mathit{Affected}\hspace{0.5em}\mathit{Platform}\}$$

S_t is the set of objects that transmit the effect, i.e.:

$$S_t=\{\mathit{Affected}\hspace{0.5em}\mathit{Platform},\mathit{Affected}\hspace{0.5em}\mathit{Business}\}$$

S_p is the set of platform objects that threats act on, i.e.:

$$S_p=\{\mathit{Affected}\hspace{0.5em}\mathit{Platform},\mathit{Platform}\}$$

S_b is the set of business objects that threats act on, i.e.:

$$S_b=\{\mathit{Affected}\hspace{0.5em}\mathit{Business},\mathit{Business}\}$$

For the threat actions among the objects of S_p, S_b in L, we define them into two types of mapping relationships: attack mapping relationships and affect mapping relationships.

5.2.1. Attack mapping function

The set F contains two mapping functions used to describe eight attack mapping relationships from S_k to S_p and S_b:

$$F=\{f_{\mathit{attack}\hspace{0.5em}\mathit{code}},f_{\mathit{attack}\hspace{0.5em}\mathit{data}}\}$$

Where f_{attack code} represents the attack executed through code stream. For the objects in S_k attack via code stream, thereafter make effect on the objects in S_p, the mapping relationship is expressed as:

$$f_{\mathit{attack}\hspace{0.5em}\mathit{code}}:\hspace{0.5em}{S}_k\to S_p$$(1)

We expand Equation (1), the two attack mapping relationships initiated by threat source through code stream are shown in Figure 4a:

f_{attack code}: Threat source → affected platform. The adversary launches an attack on the platform through code stream, causing it to run in an abnormal state, and the threat will continue to spread. e.g., in the Ukraine blackout event, the adversary took control of the SCADA system via the BlackEnergy Trojan. Then, the adversary gave the command to cut off the power [15, 35].

f_{attack code}: Threat Source → Platform. The adversary launches an attack on the platform through code stream, causing it to run in an abnormal state, but the threat will no longer spread. e.g., the report “Mobile Malware Threat Landscape 2022” released by Kaspersky states that attackers will use Trojans to hack into the user’s mobile terminal and upload the user’s data. At this time, the mobile terminal can still run normally, but the user’s data has been stolen [36].

The two attack mapping relationships initiated by affected platform through code stream are shown in Figure 4b:

f_{attack code}: Affected Platform → Affected Platform. The attack agent launches an attack on the platform through code stream, causing it to run in an abnormal state, and the threat will continue to spread. e.g., in the Stuxnet event, after compromising an industrial network user terminal, the adversary used it as a springboard to move laterally to attack other hosts [13, 16].

f_{attack code}: Affected Platform → Platform. The attack agent launches an attack on the platform through code stream, causing it to run in an abnormal state, but the threat will no longer spread. e.g., in the attack event of SWIFT service provider EastNet, the adversary used the compromised server in the MGMT region as a springboard to compromise an Oracle database server in the SAA region, then steal its data. Although the server remained operational, the data was stolen [12].

Figure 4. Attack mapping. (a), (b) and (c) are the mapping expansion of fattack code. (d) is the mapping expansion of fattack data

For the affected platform attack the objects in S_b via running code³, the mapping relationship is expressed as:

$$f_{\mathit{attack}\hspace{0.5em}\mathit{code}}:\hspace{0.5em}\mathit{Affected}\hspace{0.5em}\mathit{Platform}\to S_b$$(2)

We expand Equation (2), the two attack mapping relationships initiated by affected platform through running code are shown in Figure 4c:

f_{attack code}: Affected Platform → Affected Business. The attack agent launches an attack on the business through running code, causing it to operate in an abnormal state, and the threat will continue to spread. e.g., in the event of WannaCry, the worm, after attacking users’ Windows computers, would ransom them and ask for payment via Bitcoin. This stagnates the work tasks of current users and prevents the operation of any of the businesses involved [11].

f_{attack code}: Affected Platform → Business. The attack agent launches an attack on the business through running code, causing it to operate in an abnormal state, but the threat will no longer spread. e.g., in the Heartbleed vulnerability analysis report, an attacker who compromised an intranet host was able to send maliciously constructed heartbeat packets to an OpenSSL server with the vulnerability to remotely access 64K of data in memory that had crossed the boundary. The server’s supporting business can still operate normally, but data has been leaked [9].

Where f_{attack data} represents the attack executed through data stream. For the threat source attack via data stream, thereafter make effect on the objects in S_b, the mapping relationship is expressed as:

$$f_{\mathit{attack}\hspace{0.5em}\mathit{data}}:\hspace{0.5em}\mathit{Threat}\hspace{0.5em}\mathit{Souece}\to S_b$$(3)

We expand Equation (3), The two attack mapping relationships initiated by threat source through data stream are shown in Figure 4d:

f_{attack data}: Threat Source → Affected Business. The adversary launches an attack on the business through data stream, causing it to operate in an abnormal state, and the threat will continue to spread. e.g., in the Ukraine blackout event, the adversary launched a telephony DDoS attack against the electricity customer service center, causing customer service business breakdown. This prevented crews from determining the area of the outage and from taking measures to deal with it [15, 35].

f_{attack data}: Threat Source → Business. The adversary launches an attack on the business through data stream, causing it to operate in an abnormal state, but the threat will no longer spread. e.g., with Bitcoin soaring in 2019, attackers began using DDoS attacks to ransom some companies’ websites, preventing them from responding normal access. The threat from the attackers did not spread, but companies were forced to disrupt their web access business [6].

5.2.2. Affect mapping function

The set G contains two mapping functions to describe eight affect mapping relationships from S_t to S_p and S_b:

$$G=\{g_{\mathit{affect}\hspace{0.5em}\mathit{code}},\hspace{0.5em}{g}_{\mathit{affect}\hspace{0.5em}\mathit{data}}\}$$

Where g_{affect code} represents the affect through code stream. For the affected platform affect the objects in S_p and S_b via code streams, the mapping relationship is expressed as:

$$g_{\mathit{affect}\hspace{0.5em}\mathit{code}}:\hspace{0.5em}\mathit{Affected}\hspace{0.5em}\mathit{Platform}\to S_p,S_b$$(4)

We expand Equation (4), the two affect mapping relationships where threats transmit through code streams initiated by affected platform are shown in Figure 5a:

g_{affect code}: Affected Platform → Affected Platform. The affected platform transmits threat to other platform through code stream, causing it to run in an abnormal state, and the threat will continue to spread. e.g., in the attack event on SolarWinds, the attacker replaced the Orion software source code provided on its official website with a backdoor-implanted version, thus implementing a supply-chain prefabricated attack. When users normally visit the website then download and use the installation package, the attacker can control the user’s host through the backdoor, and use it as a springboard to move laterally to attack other hosts [8, 37].

g_{affect code}: Affected Platform → Platform. The affected platform transmits threat to other platform through code stream, causing it to run in an abnormal state, but the threat will no longer spread. e.g., in the attack event on SolarWinds, the attacker compromised the distribution environment of the company’s Orion infrastructure management platform and added a backdoor to the source code. These legally digitally signed codes were distributed to the users along with the software updates. When user run the updated software, the attacker could steal data from user through the backdoor. This time, the user’s software could still run normally, but it was already in a state of intrusion [8, 37].

Figure 5. Affect mapping. (a) and (b) are the mapping expansion of gaffect code. (c) is the mapping expansion of gaffect data

The two affect mapping relationships where threats transmit through running code initiated by affected platform are shown in Figure 5b:

g_{affect code}: Affected Platform → Affected Business. The affected platform transmits threat to other business through running code, causing it to operate in an abnormal state, and the threat will continue to spread. e.g., in the Stuxnet event, after compromising the control host of the SCADA system, the Stuxnet worm modified the operating data in the valve PLC controllers of the cascade protection systems and the speed PLC controllers of the Iranian uranium centrifuges through data streams. This resulted in the uranium centrifuge business operating with incorrect data [13, 16].

g_{affect code}: Affected Platform → Business. The affected platform transmits threat to other business through running code, causing it to operate in an abnormal state, but the threat will no longer spread. e.g., an attacker maliciously modifies a company’s promotional website by rewriting the inquiry link as a link to the attacker’s own spoofed webpage. The corresponding business on the company’s website continues to operate normally, but users will mistakenly visit the attacker’s web page and obtain fraudulent information that the company is about to be closed down [7].

Where g_{affect data} represents the affect through data stream. For the affected business affect the objects in S_p and S_b via data streams, the mapping relationship is expressed as:

$$g_{\mathit{affect}\hspace{0.5em}\mathit{data}}:\hspace{0.5em}\mathit{Affected}\hspace{0.5em}\mathit{Business}\to S_p,S_b$$(5)

We expand Equation (5), the four affect mapping relationships where threats transmit through data stream initiated by affected business are shown in Figure 5c:

g_{affect data}: Affected Business → Affected Platform. The affected business transmits threat to other platform through data stream, causing it to run in an abnormal state, and threat will continue to spread. e.g., in the XcodeGhost event, the software company developed software using the polluted Xcode editor, which resulted in the software being polluted. Then the software was uploaded to online locations such as web cloud disks and forums. The software, when downloaded and installed by the user, would open a remote-control entry for the attacker. Attackers could enter the host and implant new malicious code, in order to further launch the attack [10].

g_{affect data}: Affected Business → Platform. The affected business transmits threat to other platform through data stream, causing it to run in an abnormal state, but the threat will no longer spread. e.g., in the XcodeGhost event, the software company used the polluted Xcode editor to develop an APP and uploaded it to Apple’s APP Store, where it passed the review. After the user installed the polluted software, the user’s mobile phone data would be sent back to the attacker’s specified domain. By this time, the users’ data has been leaked, but the threat will no longer spread [10, 38].

g_{affect data}: Affected Business → Affected Business. The affected business transmits threat to other business through data stream, causing it to operate in an abnormal state, and threat will continue to spread. e.g., in the Stuxnet event, after the Stuxnet worm modified the speed data of the PLC controllers for centrifuge speed at Iran’s industry of control system (ICS), some centrifuges in the uranium centrifuge business were damaged as a result of constantly variable-speed operation. This caused reduced capacity of the uranium production [13, 16].

g_{affect data}: Affected Business → Business. The affected business transmits threat to other business through data stream, causing it to operate in an abnormal state, but the threat will no longer spread. e.g., in the Stuxnet event, although the functions of the nuclear weapon integration business were normal, the lack of uranium prevented it from producing nuclear weapons due to the lack of capacity in the uranium production business [13].

The above mapping relationships express the pattern of the threat transmission set in model L, where Equation (1), Equations (2) and (4) are the transmission of threat through code stream and Equations (3) and (5) are the transmission of threat through data stream. For an attack event in a real scenario, the attack and affect processes it contains are usually a combination of some mapping relationships above.

5.3. Model representation

In this section, we construct the ripple model L={S, F, G}. Where S is the set of objects in the model, including threat source, affected platform, platform, affected business and business.

F is the set of attack functions with three attack mapping relationships:

$$\begin{array}{cc}\hfill F=& \{{\mathit{S}}_{\mathit{k}}\to S_p,\hfill \\ \hfill & \mathit{Threat}\hspace{0.5em}\mathit{Source}\to S_b,\hfill \\ \hfill & \mathit{Affected}\hspace{0.5em}\mathit{Platform}\to S_b\}\hfill \end{array}$$(6)

G is the set of affect functions with two affect mapping relationships:

$$\begin{array}{cc}\hfill G=& \{\mathit{Affected}\hspace{0.5em}\mathit{Platform}\to S_p,S_b,\hfill \\ \hfill & \mathit{Affected}\hspace{0.5em}\mathit{Business}\to S_p,S_b\}\hfill \end{array}$$(7)

Our model is able to not only characterize the traditional attacker attacks on platforms and businesses, but also the affect based on the relationships of platform-to-platform, business-to-platform, and business-to-business. These express the complete ripple logics of the threat within the architecture. The threat ripple model is shown in Figure 6.

Figure 6. Threat ripple model

5.4. Mathematical representation

The mathematical representations are concisely constructed for the threat ripple model to enable it to support algorithmic applications that allow automated analysis and inference for threat ripples. The objects in architecture are defined as follows:

$$B=\{B_1,B_2,\dots ,B_t\}$$

where B is the set of businesses and the support platform for business B_i∈B is P_i, the set of support platforms is:

$$P=\{P_1,P_2,\dots ,P_t\}$$

The business that directly depends on business B_i is denoted by B_j(i), and the platform that supports it is denoted by P_j(i). The threat source is denoted by T.

For business B_i and platform P_i, their abnormal states are denoted by $S_{B_i}^F$ and $S_{P_i}^F$ after suffering threats, respectively. Their states are expressed as ${\tilde{S}}_{B_i}$ and ${\tilde{S}}_{P_i}$ if they continue to transmit threats, and as ${\hat{S}}_{B_i}$ and ${\hat{S}}_{P_i}$ if they do not transmit threats, i.e.:

$$S_{B_i}^F\in \{{\tilde{S}}_{B_i},{\hat{S}}_{B_i}\}$$

$$S_{P_i}^F\in \{{\tilde{S}}_{P_i},{\hat{S}}_{P_i}\}$$

Where T and ${\tilde{S}}_{P_i}$ can launch an attack, we denoted them by A_K, i.e.:

$$A_K\in \{T,{\tilde{S}}_{P_i}\}$$

For the attack mapping functions in Section 5.2.1, we use f^C and f^B to express f_{attack code} and f_{attack data}, respectively. Then for Equation (6), the mathematical expressions of the attack functions in set F are:

$$\begin{array}{cc}\hfill F=& \{f^C(A_K)=S_{P_j(i)}^F,\hfill \\ \hfill & f^B(T)=S_{B_j(i)}^F,\hfill \\ \hfill & f^C({\tilde{S}}_{P_i})=S_{B_j(i)}^F\}\hfill \end{array}$$

For the affect mapping functions in Section 5.2.2, we use g^C and g^B to express g_{affect code} and g_{affect data}, respectively. Then for Equation (7), the mathematical expressions of the affect functions in set G are:

$$\begin{array}{cc}\hfill G=& \{g^C({\tilde{S}}_{P_i})=S_{P_j(i)}^F,S_{B_j(i)}^F,\hfill \\ \hfill & g^B({\tilde{S}}_{B_i})=S_{P_j(i)}^F,S_{B_j(i)}^F\}\hfill \end{array}$$

The mathematical expression of threat ripple is a complex theory, the specific forms and properties must be strictly defined and interpreted in detail. Due to the structure and length of this paper, the above is only a brief description⁴.

6. Characterize a typical cyberattack event

We map realistic Stuxnet attack event [13, 14, 16] to the threat ripple model, as shown in Figure 7. The Stuxnet event, an attack aimed at stagnating Iran’s nuclear weapons development process, is sufficient proof that cyberattacks can play an important role in military operations. The worms are divided into Stuxnet 0.5 [16] and Stuxnet 1.x [14, 16] versions, their final goal is to disrupt uranium centrifuge infrastructure by modifying parameter data of programmable logic controllers (PLCs) used to configure the industrial control system (ICS).

Figure 7. Threat ripple characterization of Stuxnet event. ① represents the network transmission mode, and ② represents the USB mobile media transmission mode, as described in Section 6

After Stuxnet 0.5 was conveyed, it first infected extranet hosts of the enterprise network, which in turn infected inserted-in USB devices, and then these devices contained Stuxnet 0.5 virus was taken into the target enterprise network through personnel-brought-in manner. When inserted into a new host in the enterprise network, Stunex 0.5 infects the Siemens Step 7 project files in the host. These infected files will then be spread among hosts on the enterprise intranet via USB devices or human file sharing (e.g., via email), and a P2P network will be set up among infected machines to enable sharing of updates to the malicious code via mailslots. When Stuxnet 0.5 finally succeed in spreading to and infecting key hosts in the SCADA control system network, it would implant malicious code by replacing legitimate DLL files of Siemens’ proprietary Step 7 control software, which in turn modified the PLC parameter data to pressurize the centrifuge. This resulted in the centrifuges operated under overpressure conditions and were ultimately damaged.

After Stuxnet 0.5 executed the infection, the adversary organization conveyed multiple new versions of the worms used to damage centrifuges to the enterprise network, which were collectively referred as Stuxnet version 1.x. They spread via two modes: network and USB removable devices, as shown in Figure 7.

For the mode of propagation through the network ①, there are four ways to infect new hosts:

• Infecting remote hosts via MS10-061 Print Spooler Zero-Day Vulnerability.

• Infecting remote hosts via MS08-067 Windows Server Service Vulnerability.

• Accessing and infecting hosts running WinCC database software by utilizing hard-coded database server passwords.

• Spreading via Network share utilizing scheduled job or Windows Management Instrumentation (WMI).

For the mode of propagation via USB removable media ②, Stuxnet 1.x replicated itself to inserted removable drives and infects new hosts in 2 ways:

• Replicating itself and infecting via exploiting the MS10-046 shortcut LNK vulnerability that allows auto-execution when viewing removable drives.

• Utilizing the autorun command to specify the malicious file to be executed as the actual autorun.inf file so that windows automatically executes when a removable drive is inserted thereby infecting the host.

During propagation, Stuxnet 1.x exploited the windows server service RPC vulnerability to establish a P2P network among infected hosts in order to propagate updates to each other. Eventually, Stuxnet 1.x would infect the Step 7 control software in the same manner as Stuxnet 0.5 after being brought via USB devices and inserted into the control system’s key hosts in the SCADA network. Then, by modifying the PLC parameter data, Stuxnet 1.x made the centrifuges repeatedly changed rotation frequency between the limit frequency of 1410 Hz, the normal frequency of 1064 Hz, and the low frequency of 2 Hz, which not only resulted in the ineffective separation of U-235 and U-238 from the gas mixture, but also caused the failure rate of centrifuge to skyrocket as a result of the repeated frequency changes.

Stuxnet 0.5 and Stuxnet 1.x worms ultimately achieved the destruction of 1/5 of the centrifuge units and made the separated uranium incapable of meeting weapons-grade requirements. The attacks resulted in the near-permanent stagnation of Iran’s nuclear weapons development plan.

Our threat ripple model can characterize existing attack events, clearly show the process of the adversary successfully attacking the platform, then modifying the platform data to make the threat transmit from platforms to businesses and then spreading among the businesses and affecting the architecture. The threat ripple model has the ability to cover both the expressive capability of the Kill Chain model for threat spreading across platforms and the ability of ATT&CK for attacks on platforms, as well as the ability to characterize the ripple processes of threats among businesses and platforms in the architecture. This allows us to accurately characterize attack that aim at creating threat ripple effects in the architecture.

7. Attack inference on representative banking scenarios

The U.S. Department of Homeland Security paper provides a typical modellable attack scenario against large banks and constructs assumptions about the potential systemic effects on the business following an attack on these banks, but lacks a business-oriented model to support it. In this paper, we use it as a representative example of attack prediction to show how, in practice, defender can use our architectural model to model an architecture, characterize the dependencies among businesses in it, and use the threat ripple model to infer an attack on the architecture using the inter-business dependencies.

7.1. Attack scenario

We construct an architecture model of a user-oriented credit card processing business of a large bank for the attack scenario in paper [39], as shown in Figure 8. The model shows the dependencies among the platforms and the businesses. In order to describe it cleanly, we hide the feedback streams of data and code transfer.

Figure 8. Credit card processing business process for a large bank

The credit card processing business of a large bank is, in fact, a mixture of multiple business dependency sequences that require multiple businesses and platforms to participate collaboratively [40–44]. When a user makes a transaction in an online shopping system, a series of business processes will take place in the banking system:

The credit card payment will enter the transaction processing stage. First, the transaction data need to be submitted to the bank’s credit card transaction business for audit. After the audit is completed, the transaction data will be submitted to the transaction processing business for handling. Next, the issuing bank business will receive the request for funds and after its confirmation it will order the transaction authorization business to select the transaction gateway corresponding to the user’s credit card to conduct the electronic transaction with the credit card organization. Then, after the transaction is completed, the account recording business will use the credit card processing system to credit the transaction information to the user’s account [42, 43].

At the stage of transaction settlement between the user and the merchant of the online shopping system, the settlement processing business will use the Transaction Settlement System to send an electronic payment request to UnionPay to execute the settlement, after obtaining the approval of the card issuing bank business. When the settlement is completed, the issuing bank business will request the Account Record Business to record the information. All the above processing results will be returned to the user. If there is a dispute over the result of a transaction, the user can apply to the bank for transaction checking and arbitration [40, 44].

These processes follow strict rules. Once an upstream business has problems, it will cause the downstream businesses in its business dependency sequence not being able to operate normally.

7.2. Attack prediction

We combine cases of attacks on financial systems such as the SWIFT event [12, 45–47] and analyses of systemic threats to the banking systems [48–51], make the following attack predictions. All involved techniques in ATT&CK are detailed in Table 1.

The exposed and Attackable Surfaces of the Bank:

• Routers used in bank networks may have vulnerabilities [39].

• Credit card processing system needs to open accessible ports to external networks as it needs to process user requests, which makes it possible for an adversary to access and scan hosts [12, 47].

• A large volume of compromised user credit card information was sold on the black market by criminal groups [45, 46, 50].

The Attackable Surfaces of the online shopping system:

• Vulnerabilities may exist in popular online shopping systems and checkout software [39, 51].

The adversary sets the goals of:

• Disrupting credit card business on dates when high volumes of transactions occur.

• Making systemic effects on the bank, and maintaining the disruption over a period of days.

• Undermining bank and consumer confidence.

The adversary preparations:

Information gathering and weaponization, as shown in Figure 9a.

• Purchased technical information about routers deployed in the target bank from the supplier.

• Bought large volumes of active credit card numbers and consumer identities on the black market, complete with credit card validation numbers.

• Developed malicious code that exploits zero-day vulnerability against the version of the system used by the router, and malicious code that targets the credit card processing system and the online shopping system, respectively.

Figure 9. The adversary perparations. (a) Information gathering and weaponization. (b) Pre-implantation of malicious code

Pre-implantation of malicious code, as shown in Figure 9b.

• Pre-implanted these malicious code into target systems.

7.3. Attack inferring

The adversary’s attack strategies and the caused threats ripple within the architecture are as follows.

• Attack the routers. On Black Friday, the adversary launches a zero-day attack on the bank’s router and brings them down, which disrupts the network and prevents the credit card processing system from operating normally, which stagnates the issuing bank business and downstream businesses that depends on it, as shown in Figure 10. The defender discovers abnormal router running through network diagnostics and brings in backup systems to ensure network recovery as a priority. Meanwhile the adversary is constantly trying to re-insert the exploit into recovered systems of the routers.

• Attack the credit card processing system. The adversary triggers the malicious code in the credit card processing system, which paralyses the system and causes a disruption to the transaction processing business it supports, as shown in Figure 11. Along with repeated attacks on routers by the adversary, this makes it difficult for the defender to determine what has gone wrong with the credit card processing system’s inability to be accessed by the extranet. The defender works intensely to identify the cause. Once it becomes clear the disruption is due to a cyberattack, the bank takes systems off-line, attempting to find and eradicate the malicious code. The disruption to credit card transactions, due to both the attack itself and the efforts to recover, has not only resulting in a backlog of current business, but also a persistent stagnation of downstream businesses in the business dependency sequence.

• Attack the online shopping system. At the same time, the adversary exploits the checkout vulnerability in online shopping system to launch fraudulent on-line transactions using a large number of illegally obtained valid credit card accounts, as shown in Figure 12. Victim consumers enrolled in text alerting services for on-line transactions receive alerts for purchases they did not make and apply to the bank for arbitration of the transactions. This causes the banking system need to perform a large number of transaction verifications under the existing business backlog, which additionally puts burdens on the businesses’ processing. The credit card business of the bank cannot return to normal for a short period of time.

The series of attack effects will cause credit card business remain disrupted during major trading days, which will have a serious influence on the bank’s financial reputation and consumers’ confidence.

Figure 10. Attack the routers

Figure 11. Attack the credit card processing system

Figure 12. Attack the online shopping system

We use the ATT&CK model for threat inference on the above attack scenario, as shown in Figure 13. Although it is able to express the transmission of threats between platforms, it only demonstrates the sequence of tactic executions. If combined with the threat ripple model, we can express threats that utilize dependencies among platforms and businesses to have systematic effects on the architecture while showing the attack process. Threat ripple model Integrated all attack phases are presented in Figure 14.

Figure 13. Attack inferring on large bank via ATT&CK model

Figure 14. Attack inferring on large bank via threat ripple model

With the construction of architecture model for information system scenarios, coupled with the threat ripple model for attack inference, the defender is able to determine which platforms or businesses in the architecture once attacked will cause threats ripple among the businesses, as well as which factors will result in the persistence of the business affected state. The threat ripple model can help defenders determine the vulnerability of the platform and business, analyze the logic of business interactions within the architecture that might be exploited by an adversary, as well as make strategies to stop the propagation of threats in the architecture.

8. Discussion

In the course of this paper, in order to make the model efficiently applied by professionals, we focus on comparing typical threat models that are widely used in the industry during the design of the model, instead of only focusing on the models and frameworks in the latest papers. Our threat ripple model has applicability to broader and rapidly evolving range of cybersecurity threats by being able to express both the process of infrastructure-oriented cyberattacks and the process of threats using dependencies among platforms and businesses to ripple their effect. To make our modelling approach fully comprehensible to researchers, this paper concisely expresses the logic of threat transmissions among businesses and platforms using function mapping and graphical illustrations, and also shows the application mode of our modelling approach through the modeling characterization of typical attack event and the attack inferring of against important information system:

Attack event analysis:

• Characterize the threat events that have occurred and reviewing the attack process

• Help defenders work out which nodes are the key targets of attackers

System operation and maintenance:

• Determine the dependencies among the businesses and platforms in the target system.

• Discover the transmission paths that enable risks and threats to spread the effects.

• Perform attack inferring on the target system to determine which business or platform once being abnormal will have a ripple effect on other parts of the system, and then strengthen their security.

Respond and assess threat events while encountered:

• Help defenders quantify the business effects of the threats.

• Stop new ripple effects on infrastructure and business in time that might transmit from the threat generated by attack.

In actual scenarios, the use of the model is flexible and researchers can use the system model to decompose the system at the required granularity depending on the complexity of the system, e.g., aggregating businesses that do not need to zoom in detail, thus focusing on vulnerable businesses and platforms.

An unresolved problem is that the business-specific risks and security needs of different industries may vary significantly, which require more tailor-made approaches. Our future work will investigate more domains involving non-information systems. In addition, we will continue work on mathematically expressing the modeling method to make it computable, in order to preparing for introducing algorithms.

9. Conclusion

The threat ripple model can be used to characterize the process of threats transmit and cause effects utilizing the relationships among platforms and businesses. By coupling with the architecture model, it can be used to perform business-oriented attack inference, identify the vulnerability points of the business and platforms in the architecture, and what threat ripple effects will be caused if they are attacked.

For threat events such as Stuxnet and the Ukraine blackout event, the adversary accurately attacked platforms as a means of rippling the threat caused by the attack in the architecture, utilizing the logic of data transmission of the businesses and code transmission of the platforms. Similarly, some attacks activities that aim at cross-modal architectures which are strongly associated with the target architecture, will disrupt its businesses or elements and participants of the business, in order to affect the target architecture, such as assassinating Iranian nuclear weapon scientist causing confusion in the development of nuclear weapons, Türkiye cutting off important water sources in Syria bringing the Kurdish region into a crisis, using social networks to spread false news to affect the public’s view on social issues, etc. These methods of spreading the effects of an attack via utilizing the relationships among components in cross-modal architectures are essentially threat ripple. Our threat ripple model is suitable for researching these threat ripple processes. In the future, the further exploration in calculation methods of threat ripple effects, important cross-modal business elements, etc. are able to form a more dimensional characterization of threat ripple.

Acknowledgments

Thanks to Master Sheng Huang for his support of this research.

Funding

This work was supported by the National Natural Science Foundation of China under Grants No. 62302122, and the Key R&D Program of Heilongjiang Province of China under Grants No. JD2023SJ07.

Conflicts of interest

The authors declare that they have no conflict of interest.

Data availability statement

No data are associated with this article.

Author’s Contributions

Shiliang Ao and Binxing Fang provided the threat modelling methodology. Xinguang Xiao provided the revision and proofreading, and Hongli Zhang provided resource support for this paper.

References

Shiliang Ao received the B.S. degree from Xidian University, Xi’an, China, in 2015. He is currently a Ph.D. candidate in the School of Cyberspace Science from Harbin Institute of Technology (HlT). His research interests include cybersecurity and system engineering.

Binxing Fang received the Ph.D. degree in computer science and technology from Harbin Institute of Technology, Harbin, China, in 1989. He is a member of the Chinese Academy of Engineering. His cument research interests include computer networks, information and network security.

Xinguang Xiao graduated from Harbin Institute of Technology, Harbin, China, in 1998. He is an adjunct professor in HlT, and the Chief Architect of Antiy Technology Group Co., Ltd. His research interests include Advanced Persistent Threat (APT) analysis & traceability and cyberspace security engineering.

Hongli Zhang received the Ph.D. degree in computer science from Harbin Institute of Technology, Harbin, China, in 1999. She is currently a Professor with the School of Cyberspace Science in HlT. Her research interests include network and information security, network measurement and modeling.

All Tables

All Figures

	Figure 1. Architecture model
In the text

	Figure 2. Attacks launched by the adversary. (a) Attack Platform. (b) Attack target business through dependent business. (c) Attack target business through business dependency sequence. (d) Attack support platform to affect target business
In the text

	Figure 3. Attack a support platform in business dependency sequence to affect the target business
In the text

	Figure 4. Attack mapping. (a), (b) and (c) are the mapping expansion of fattack code. (d) is the mapping expansion of fattack data
In the text

	Figure 5. Affect mapping. (a) and (b) are the mapping expansion of gaffect code. (c) is the mapping expansion of gaffect data
In the text

	Figure 6. Threat ripple model
In the text

	Figure 7. Threat ripple characterization of Stuxnet event. ① represents the network transmission mode, and ② represents the USB mobile media transmission mode, as described in Section 6
In the text

	Figure 8. Credit card processing business process for a large bank
In the text

	Figure 9. The adversary perparations. (a) Information gathering and weaponization. (b) Pre-implantation of malicious code
In the text

	Figure 10. Attack the routers
In the text

	Figure 11. Attack the credit card processing system
In the text

	Figure 12. Attack the online shopping system
In the text

	Figure 13. Attack inferring on large bank via ATT&CK model
In the text

	Figure 14. Attack inferring on large bank via threat ripple model
In the text