Crosscutting concerns in use case modelling

The pioneer of the use case modelling approach, Ivar Jacobson, in the paper [10] has highlighted the challenge of tangling and scattering in the realization of the use case diagram. It employs the <<extend>> relationship involves defining aspects that cut across multiple use cases. It introduces the extension points as pointcuts within the base use case, and joinpoints to specify the locations where these extensions take place. The extension operation then activates advice on the extension pointcut, thereby influencing the behavior linked to the extension in the base use case. Another approach [14] proposed aspect-oriented UML use cases. It defines the crosscutting system functionality as an aspect use case and specifies it with the base use case using pointcut, joinpoint, and advice expressions. It uses the traditional use case <<extend>> relationship representing the crosscutting concerns with the extension point as a pointcut which joins at the steps in the basic flow, applying particular behavior of extension as advice. Based on this specification, the aspect use case model is further specified formally in extended AspectZ.

There are approaches in literature that provide alternative mechanisms instead of using the traditional <<extend>> relationship [15,16]. An existing approach [15] uses aspectual use cases to model crosscutting concerns as non-functional requirements (NFR) that crosscut functional use cases. The NFR is connected to the use case using stereotype <<constrain>>, and itself NFR use case is represented visually using stereotype <<NFR>>. A candidate aspect, considering a use case as a good candidate when it is related to more than one use case using the traditional extend and include relationships. Another approach [16] adapts the use cases to model and specify crosscutting behavior into distinct entities called crosscutting use cases. It represents the NFR as security, reliability, and performance as crosscutting concerns and establishes connections with regular use cases using the <<crosscuts>> relationship. It proposes the concept of a composition table to define the composition between affected use cases and their crosscutting use cases. It includes the details of affected use cases, conditions of composition, the behavior of the crosscutting use case specified as advice using operators after, before, overlap, override, and wrap, at the points in affected use cases where this behavior is applied.

Since there are approaches in literature that address aspect-oriented modelling with use cases [17–21]. An approach [17] addresses an aspect-oriented use case model that introduces an “aspects” block to consolidate new functional and non-functional concerns, such as performance, logging, and authentication, with the core functional use cases. It incorporates aspect-oriented modelling constructs like pointcut, joinpoint, and advice within the use case model. The aspect block is linked with more than one core concern as use cases using the relationship stereotype <<crosscut>>. It consists of the pointcut on the joinpoints in the core use cases and corresponding advice as before, after, and around. Another study [18] defines an aspect-oriented method for defining and addressing security threats within the context of a use case-based functional modelling approach. It introduces a use case template to express crosscutting aspects, recognizing that threats may manifest in various sections of the same or different use cases. The approach aligns the use of pointcuts, joinpoints, and advice with the key points in a use case, such as main flow, alternate flow, precondition, and postcondition. Moreover, one of the studies [19] introduces an aspect-oriented method for defining security requirements through the utilization of aspectual use cases. This involves incorporating a pointcut to select joinpoints in the basic and alternate flows of the base use case to apply advice. This approach proves valuable in modelling functional requirements as base use cases and security requirements as aspectual use cases, enabling security personnel to identify security threats independently of functional requirements. Lee et al. [20] present a goal-driven use case. It defines the base use case, specifying the slice of system functionality used by an actor. Another use case is defined as an aspectual use case, which is also a system functionality that cuts across the base use case. It identifies the aspectual use case that affects the base use case with the defined places as joinpoints. These joinpoints describe the places in the base use case where the aspectual use case weaves its operation along with the weaving operators as insert behavior, replace behavior, or impose constraint. Another study [21] provides an aspect-oriented use case modeling approach for product lines. It considered the functional requirements as variabilities in the system and introduced a <<variability>> relationship specialization of <<aspect> relation. These variable requirements are crosscutting concerns. These variable requirements crosscut the base use case by defining the pointcut expression that signifies the joinpoint within the elements of the base use case, such as steps, operations, alternatives, extension points, and conditions. The pointcut applies the advice on the selected joinpoints using various types, such as before, after, around, and concurrent types. The variable requirements as crosscutting concerns are woven with the common requirements specified by a pointcut expression. Finally, they transformed the aspect model to a Petri net, to generate the state chart and test model through automated and extended tool support as UCEd.

There are UML profiles SecureUML [22], UMLsec [23,24], SECTET [25], ModelSec [26], and SecureMDD [27] that build UML profiles with the integration of aspect-oriented modelling to address crosscutting security concerns. SecureUML [22] proposed a Role-based Access Control (RBAC) framework to integrate crosscutting security concerns in system design. Whereas UMLSec [23,24] proposed stereotypes and constraints to specify crosscutting security concerns as confidentiality and integrity. The focus of SECTECT [25] is to model the security guidelines while modeling crosscutting security concerns in service-oriented architectures. ModelSec [26] proposed the UML profiles for class diagram, sequence diagram, and state machine diagram to model crosscutting security threats within system design. Similarly, the focus of SecureMDD [27] is on UML use case, activity diagram, and component diagram. This is observed from these studies, which highlight the importance of modeling crosscutting concerns, but they do not follow the true concepts of pointcut, joinpoint, and advice.

Despite addressing the significance of incorporating an aspect-oriented approach in use case methodology in software development, the above literature highlights several key differences.

• • Few studies rely on the traditional use case <<extend>> relationship as an aspect, which causes ambiguity, particularly in identifying aspect threats or additional behavior [10,14].
• • While some studies [15,16] recognize the crosscutting concerns as NFRs and specify by introducing the stereotypes as <<crosscut>>, <<aspect>>, or <<constrain>>, but they fail to fully apply the core aspect-oriented concepts such as pointcut, joinpoint, and advice.
• • Literature generally lacks a comprehensive approach to model crosscutting security threats; only a few studies [17–21] specify the security threats as an aspect following pointcut, joinpoint, and advice. Aspect modeling is primarily applied for crosscutting NFR performance, reliability, security, logging, authentication, and others [15–19] or functional requirements [10,14,20,21] that crosscut with the base requirements.
• • However, these approaches relied on the use case modeling method to define crosscutting security threats, rather than utilizing the more specialized misuse case model originally designed for capturing security threats. This deviation from the traditional use of use cases, typically intended for functional requirements, presents a limitation in modeling security concerns separated from the functional ones.

Specification of crosscutting mitigations

Only one study exists that addresses the issue of tangling and scattering in the specification of mitigation cases. Dianxiang et al. [18] proposed the mitigation aspect, which identifies mitigation pointcuts and applies the mitigation advice. The proposed mitigation advice template includes the advice name, threat category, main flow, alternate flow, precondition, and postcondition. Mitigation points specify the threat points that need the mitigation logic to apply, and the mitigation advice defines the steps that mitigate the identified threat.

This study also addressed the existing mitigation templates in the literature for comprehensive coverage of the existing approaches. The purpose is to select and extend the mitigation template that can be aligned with and reflect the intended objective. Another approach presents a more comprehensive and precise mitigation scheme complementary to the security use cases to mitigate the security threat. It proposed a mitigation section, where it defines the name of the misuse case to mitigate, and its behavior using basic and alternate flows to mitigate the threats. The security use cases are complemented by the mitigation template defining the mitigation scheme [7]. Another approach provides a misuse case model for security testing. It defines the misuse cases and their mitigation in a single template, including sections such as ID, name, category, goal, actor, precondition, threat flow, post condition, and mitigation flow [28].

• • From the literature, it is observed that only one study has proposed the aspect-oriented mitigation template while following the essential concepts of aspect-oriented modelling as pointcut and advice and fails to specify the joinpoints and advice types in the mitigation template.

Unambiguous specification of misuse case

Specifying security threats unambiguously and formally is an active area. Many studies have presented the structured misuse case template to specify the security threats to reduce the ambiguity in misuse case descriptions [7,8,29]. But in general, they do not address the specification of crosscutting security threats, which still causes ambiguity in threat specification. Therefore, the basic purpose of this study is to develop an unambiguous and formalized aspect-oriented misuse case template. To achieve this objective, this study included the existing structured and formalized misuse case templates that provide an improved and structured approach with complete details. This can be further extended to specify the crosscutting security threats

El-Attar [8] presents a Structured Misuse Case Description (SMCD) to reduce the ambiguity in misuse case models by proposing a structured template and limiting the use of natural language through keywords to formally specify the security requirements. It extends the SSUCD [30] with sections such as Misuse case name, Associated Misuser, Misuser profile, Description, Extended Misuse cases, Extension points, Threatens, and Mitigates. It formalizes the structural elements as generalization, includes, and extends relationships using the formal keywords such as ABSTRACT, SPECIALIZES, IMPLEMENTS, INCLUDE, and IF keywords. The emphasis is on structured misuse cases serving as guidelines to authors in providing a comprehensive and common understanding regarding threat specification. Another approach is presented by El-Attar [29] that defines a Formal Misuse Case Description (FMCD). It provides a formal structure for misuse case specification before transforming it into a mal-activity diagram. It restricts the use of natural language by formalizing loops and concurrency using RESUME and AFTER, and conditions using IF and AT keywords. Furthermore, it advocates initiating the basic flow with the keyword START and ending it with FINAL.

The study proposed by Mai et al. [7] reduces the ambiguity in the Restricted Misuse Case model (RMCM) by introducing a structured misuse case template and formalizing it using restriction rules. It extends the Restricted Use Case Model (RUCM) [31] with the misuse case constructs and fifteen restriction rules to specify the threats unambiguously. The proposed approach is empirically evaluated as precise, structured, and analyzable to model the security threats.

• • It is evident from the above literature that the studies focused on limiting the use of natural language to reduce ambiguity in the specification of security threats. They proposed restricted keywords and rules to specify the security threats in the misuse case specification template. However, according to the objective, these approaches are lacking in specifying crosscutting security threats. Nevertheless, they are precise and unambiguous enough to be extended with AOM constructs and restriction rules to specify the crosscutting security threats.

Research gap analysis

In general, the key limitations in existing literature are analyzed in relation to the objective of this study.

• • There is a notable gap in the literature specifically addressing tangling and scattering in the context of misuse case modelling. The existing approaches typically rely on use case diagrams and specification templates to define crosscutting security threats, rather than utilizing the more specialized misuse case model designed for capturing security threats. This reliance on traditional use cases typically intended for functional requirements presents a limitation in modelling security concerns separately from functional ones.
• • The existing aspect-oriented use cases cannot specify the introduction, advice (before, after, and around), and weaving to model crosscutting security threats and their mitigations.
• • While several misuse case and mitigation specification templates exist to best address the threats and mitigation precisely and unambiguously. But to the best of current knowledge, no one has specified crosscutting security threats and their mitigation using such templates.

In the context of this study, there is a need to propose a comprehensive and unambiguous aspect-oriented approach that specifies the crosscutting security threats and their mitigation using misuse case and mitigation case templates. Which follows the essential aspect-oriented concepts such as pointcut, joinpoint, advice, introduction, and weaving. For this purpose, among the literature, one of the most comprehensive and precise approaches is RMCM [7]. This study has adopted and extended the RMCM template and restriction rules to specify aspect-oriented misuse cases and aspect-oriented mitigation cases to reduce ambiguity and effectively specify the crosscutting security threats and their mitigations.

Requirements specification

The artifacts used by the AFMUC are the use case specification, misuse case specification, and security requirements specification. The functional requirements are specified using the RUCM template proposed by Yue et al. [31]. In proposed context, the essential required sections of this template are, use case name, Dependency, Precondition, Basic Flow, and Postcondition. Based on the specified use case, the threats and mitigations are specified using the misuse cases and security use cases respectively, by adopting the RMCM template [7]. These templates are selected because they are renowned, actively used by the researchers, and evaluated as precise, structured, and practical to analyze the functional and security requirements [32,33].

AFMUC constructs

The basic constructs of AOM are pointcut, joinpoint, advice, introduction, and weaving [34]. The aspects for threats and mitigations are defined and then woven into the misuse case and mitigation case description templates, respectively. This section explains AOM constructs used in the proposed AFMUC (misuse case and mitigation case) approach.

Aspect-oriented formalized misuse cases to specify aspect threats

Table 1 shows the proposed AFMUC – aspect misuse case template for the specification of aspect threats in a precise and structured form. It extended the RMCM template [7] with aspect-oriented modeling constructs such as pointcut, joinpoint, advice, and introduction.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 1. AFMUC- Aspect Misuse Case Template.

https://doi.org/10.1371/journal.pone.0322664.t001

The RMCM [7] approach includes elements such as misuse case name, brief description, primary actor, precondition, basic threat flow, alternate threat flow, alternate flow, and dependency. In this study, all elements from the RMCM have been adopted, except for the misuse case name and threat section; these two elements are modified and renamed as AFMUC name and Threat Pointcut. The AFMUC name represents the crosscutting threat as an aspect misuse case name. This differentiation is made to distinguish the regular misuse case name as an aspect threat name to indicate it as an aspect. The threat pointcut section replaces the threat section. Previously, the threat section only specified the name of the use cases it threatens, causing ambiguity as it fails to provide comprehensive details on how a threat is cut across use cases. The proposed Threat Pointcut section addresses this issue by specifying the crosscutting threats using AOM constructs such as pointcut, joinpoint, advice, and introduction. Additionally, AFMUC ID is introduced to specify the unique identifier of the threat, and the Threat Category sections represent its compliance with the OWASP [35] and ISO/IEC 27001:2022 Information Security Management [36] Standards. The complete details of the RMCM template can be found at [7].

Aspect-oriented formalized mitigations to specify aspect mitigation

AFMUC also provides the aspect mitigation template presented in Table 2. The RMCM [7] security use case specification template is adopted, and aspect-oriented constructs are integrated to represent the crosscutting mitigation of the threats. The elements, such as security use case name, mitigation, and basic flow of security use case specification, are replaced with the proposed AFMUC constructs as Aspect Mitigation Name, Mitigate Pointcut, Basic Mitigation Flow, and Alternate Mitigation Flow. The Aspect Mitigation Name represents the name of mitigation that cuts across multiple threats or misuse cases. Basic Mitigation Flow represents the behavior used to mitigate threat, Alternate Mitigation Flow specifies the alternate behavior used to mitigate threat in reference to basic mitigation flow. A field of Aspect Mitigation ID is also introduced to assign a unique identifier to the aspect mitigation. This approach is used to provide relevant names and to differentiate them from other templates. Lastly, the Mitigate Pointcut represents the actual specification of AOM constructs such as pointcut, joinpoint, and advice.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 2. AFMUC- Aspect Mitigation Template.

https://doi.org/10.1371/journal.pone.0322664.t002

Aspect-oriented formalized restriction rules

The aspect-oriented restriction rules are designed to formally and unambiguously specify the crosscutting security threats and their mitigation. These rules apply to aspect threats and aspect mitigations. These proposed rules are extensions of the RMCM restriction rules [7], as they have already been assessed as unambiguous, precise, and practically applicable. Altogether, the AFMUC template and restriction rules are designed to ensure that the aspect threat and aspect mitigation are unambiguous, structured, and formalized by restricting the use of natural language in specifying the crosscutting security threats and their mitigation.

Table 3 represents sixteen restriction rules (R1-R16) for specification of aspect threats and their aspect mitigation using pointcut, join point, advice, and introduction. The rules (R1-R5) are used to formally specify the elements (subsets) of the description templates (Basic Flow, Precondition, Post Condition, Basic Threat Flow, Basic Mitigation Flow) in the relevant templates. The rules (R6-R16) are used to formally specify the AOM constructs as Pointcut, Joinpoint, Advice, and Introduction.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 3. AFMUC- Restriction Rules.

https://doi.org/10.1371/journal.pone.0322664.t003

Formalizing the aspect threats using restriction rules

The AFMUC restriction rules are mentioned in the Threat Pointcut section of the template (Table 1), that are used to define the aspect misuse case model To define the aspect misuse case (i.e., aspect threat), the rules R1-R4 and R6-R16 except the R5 are mandatory to complete the expression with essential constructs, i.e., pointcut, joinpoint, advice, and introduction. The R5 is not applicable here because it specifies the basic mitigation flow, mostly useful in specification of aspect mitigation model.

Referring to rule R6, the POINTCUT expression (POINTCUT<name> SUBSET <selection constraint>) selects the base use case in <name> parameter. The SUBSET reflects use case element specified as BF (R1), PRECONDITION (R2), or POSTCONDITION (R3). The <selection constraint> is a condition to select the attack surfaces (joinpoints) from the SUBSET. JOINPOINT (R7) is an expression (JOINPOINT <sequence no>) used to specify the attack surfaces with the sequence numbers that satisfy the selection constraint defined in R6. R6 and R7 collectively form a complete pointcut expression that selects the joinpoints where advice can be applied. To apply advice, all relevant pointcuts and joinpoints must be defined beforehand. Advice is defined as an expression (ADVICE <type> POINTCUT <sequence no> EXECUTE <flow>) used to specify the threat behavior. It is applied to the selected joinpoints identified by the pointcut expression. It consists of three parameters where the parameter <type> specifies the advice type: BEFORE (R9), AFTER (R10), or AROUND (R11). BEFORE Advice indicates that the SUBSET in POINTCUT expression serves as a PRECONDITION (R2) of the base use case where JOINPOINT exists, similarly the AFTER Advice reflects the SUBSET as POSTCONDITION (R3) of the base use case, and the AROUND advice applied at JOINPOINT exists at BF (R1) of the base use case. The ADVICE executes the threat behavior as BTF (R4), representing “Basic Threat Flow” in the <flow> parameter. This behavior is applied to POINTCUT expressions with their numbers given in parameter <sequences no > . Alternatively, the keyword ALL (R14) can be used if ADVICE applies to all specified POINTCUT expressions.

Regarding rule R15, the INTRODUCTION expression is defined to add a new threat to the existing base use case, showing it is a legitimate functionality. The expression (INTRODUCTION <name> ASSOCIATE TO <use case> AS <dependency>) specifies the threat name specified in the <name> parameter, which is introduced in the application by associating it with the existing base use case in parameter <use case > . The association relationship between the newly added threat and the existing base use case specified in the <dependency> parameter. This association may be both INCLUDE USE CASE or EXTENDED BY USE CASE. Either Rule R13 (||) or R14 (&&) is used to associate the threat with multiple use cases.

The second form of INTRODUCTION expression (R16), INTRODUCTION <name> REPLACE <use case > , is used to replace the base use case with the threat. The <name> parameter defines the name of the threat, while the < use case> parameter is used to define the name of base use cases to be replaced. Rule R 13 (||) or R14 (&&) may be used to select multiple use cases to replace them with a threat.

Formalizing the aspect mitigations using restriction rules

The restriction rules (R2-R14) in Table 3 are applicable to specify the aspect mitigation using AFMUC aspect mitigation template (Table 2). While the purpose of these rules remains consistent, their interpretation changes in this context. This is because the base model refers to a misuse case, while the aspect model is an aspect mitigation case. For example, the rule R6 (POINTCUT<name> SUBSET <selection constraint>) represents the name of the base misuse case as a POINTCUT in <name> parameter. The parameter <selection constraint> is used to define the condition to select the joinpoints within misuse case SUBSET, such as PRECONDITION (R2), POSTCONDITION (R3), or BTF (R4). The Joinpoints (JOINPOINT <sequence no>) select the mitigation surfaces within the SUBSET that satisfy the selection constraint. The ADVICE expression (ADVICE <type> POINTCUT <sequence no> EXECUTE <flow>) is used to execute the mitigation behavior as BMF (R5), on the selected joinpoints. The <type> parameter in the ADVICE expression determines advice type. BEFORE (R9) advice applies when the SUBSET in the POINTCUT expression is PRECONDITION (R2), the purpose is to prevent the threat from occurring. AFTER (R10) advice is applied when SUBSET is POSTCONDITION (R3). It is used to apply post-mitigations after the threat has harmed the application. And lastly, AROUND (R11) advice is applied at SUBSET as BTF (R4) and is used to mitigate threat by controlling its execution.

Another difference is that R1, R15, and R16 are not applicable in aspect mitigation. Specifically, R1 is relevant for selecting attack surfaces as joinpoints from the base use case model and is utilized in aspect threat specification, as discussed in section “Aspect-Oriented Formalized Misuse Cases to Specify Aspect Threats”. On the other hand, rules R15 and R16 are not applicable because the aspect construct introduction is intended to add a new behavior to the application without altering the existing behavior. Accordingly, mitigation inherently involves responding to an applied threat. Therefore, it requires the existence of a threat and cannot be introduced independently.

Application of proposed approach

Fig 6 (A, B) shows that the aspect threat “get unauthorized access via SQLi” cuts across two use cases named register customer and make reservation. In Fig. 6 (B), the specification of aspect threat shows that Get Unauthorized Access via SQLi is an AFMUC name. In the “Threat Category” section, the type of threat as an injection attack is specified in compliance with the OWASP [35]. The AFMUC element “Threat Pointcut” specifies a crosscutting threat aspect including the pointcuts, joinpoints, and advice. In this section, the proposed restriction rules are applied as: the keyword POINTCUT (R6) is used to explicitly define the name of the base use cases as register customer and make reservation, along with the SUBSET as BF (R1) having the selection constraint as “customer enters data”. According to the aspect threat, the attacker can get unauthorized access to the application when the input fields are vulnerable to entering a malicious SQLi script. Next, the rule (R7) defines the keyword JOINPOINT along with the sequence steps selections of the attack surfaces from BF, which satisfies the selection constraint “customer enters data” (highlighted in red color and annotated as joinpoints -Fig 6 (A)). Therefore, the joinpoint expression for register customer, is JOINPOINTS 1 && 2 && 4, and for the use case named make reservation, JOINPOINT 1 && 10. Following the R6 and R7, all the pointcut expressions are defined in sequences. Lastly, the advice is applied using “ADVICE AROUND POINTCUT ALL EXECUTE BTF”, which implements the threat behavior on all pointcut expressions.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 6. Excerpt of aspect threat - pointcut joinpoint and advice.

https://doi.org/10.1371/journal.pone.0322664.g006

The overall Threat Pointcut section depicts that the aspect misuse case get unauthorized access via sqli POINTCUTS at the use cases register customer and make reservation where the constraint is customer enters data, given in the use case BF against which the JOINPOINT are selected as the sequence steps (1&& 2&& 4, 1&&10) in BF respectively, where the ADVICE apply the basic threat flow as BTF using advice type as AROUND in ALL specified pointcuts using keyword EXECUTE.

Fig 7 (B) shows the application of R16 for the aspect threat mask a web page that threatens the use cases named register customer or make reservation using the keyword INTRODUCTION. It replaces the flow of the entire use case with malicious behavior by defacing it. Fig 7 (A) shows the red highlighted and annotated use cases. It shows that complete use case specification is replaced with the threat specification. This means that when the customer visits the registration or reservation page, they are redirected to a fake page that appears legitimate to the customer. This deception leads the customer to provide sensitive information to the attacker.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 7. Excerpt of aspect threat using introduction (R16).

https://doi.org/10.1371/journal.pone.0322664.g007

Similarly, Fig 8 (A, B) shows the application of R15, where the aspect threat Create malicious ad, a type of phishing attack that threatens the use cases register customer or make reservation. In the Threat Pointcut section (Fig 8B), the keyword INTRODUCTION is used to define the threat name as Create mal ad and ASSOCIATE TO the use cases as register customer or make reservation with the relationship as INCLUDED USE CASE, the change is assumed to be reflected in the dependency section of the use case highlighted red and annotated dependency in Fig 8A. It means that the attacker modifies the register customer code (vulnerable to attack) with the malicious ad code and displays it on the registration page as a legitimate ad to the customer. And following the semantics of the include relationship, it mandates the customer to click on the ad to complete the registration. The specified threats “get unauthorized access via SQLi”, “mask a web page”, and “create malicious ads” are woven into the AFMUC misuse case template given in Fig 9.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 8. Excerpt of aspect threat using introduction (R15).

https://doi.org/10.1371/journal.pone.0322664.g008

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 9. Weaved AFMUC template to specify aspect threat.

https://doi.org/10.1371/journal.pone.0322664.g009

In Fig 10B, the threats are mitigated by the mitigation case named monitor network. It crosscuts three threats specified in Fig 10A. The Mitigation Pointcut element specifies the three pointcut expressions (R6) for the threats named get unauthorized access via SQLi, mask a web page, and create malicious ads. The selection constraint for choosing the joinpoint in all these pointcuts is defined as “spoofed IP address”. Satisfying this selection constraint, the JOINPOINTS, or mitigation surfaces, for these threats are specified as precondition number four for “get unauthorized access via SQLi” and precondition number three for both “mask a web page” and “create malicious ads”. The mitigation surfaces are highlighted in green color and annotated as joinpoints (Fig 10A). The mitigation aspect applies the basic mitigation behavior (BMF) as BEFORE advice on ALL three POINCUT expressions. This means that the spoofed IP address is mitigated by the intrusion prevention system via network monitoring before the execution of these threats and blocks the malicious network traffic. Fig 11 shows the complete woven model of AFMUC aspect mitigation template.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 10. Excerpt of aspect mitigation - pointcut, joinpoint, advice.

https://doi.org/10.1371/journal.pone.0322664.g010

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 11. Weaved AFMUC template to specify aspect mitigation.

https://doi.org/10.1371/journal.pone.0322664.g011

The mobile finance application

The Mobile Finance Application (MFA) case study is obtained from the industry. To maintain the confidentiality agreement, the organization name is anonymized as “Company X”. The acquired software requirements specification for MFA includes its functional and security requirements. It is important to note that this application is neither a practical industrial project nor a student project, but rather a comprehensive application specification designed by industrial security experts and faculty of the Information Security Department based on the provided requirements.

The objective of MFA application is to provide easy access to financial services to customers via mobile phones or a web portal, offering identical features across both platforms. This study focuses on the web-based services of the MFA application. In MFA, the sensitive information can be processed, stored, and shared by the customer while performing online transactions. The application’s basic functional requirements include registering customer accounts, logging in, transferring money to various accounts (including bank, mobile, and CNIC), paying bills, loading mobile balances, purchasing mobile bundles, and generating account statements. Due to the involvement of financial transactions, the application is vulnerable to numerous threats. Attackers aim to exploit application vulnerabilities to access sensitive customer information by breaching databases, intercepting network communications, or launching phishing attacks. Additionally, attackers may seek to disrupt application services, rendering them inaccessible to customers. Their goal is to obtain confidential customer information or get financial gains from Company X. Given the time constraint, three significant use cases such as register customer, login, and transfer money to bank account are selected, which is threatened by five crosscutting threats (misuse cases) that pose significant threats such as unauthorized access, data modification, mask a web page to compromise services and phishing attack. One mitigation strategy, “monitoring network”, is chosen to focus on, which crosscuts all the defined threats. The threats and mitigations are identified based on standards ISO27001 [36] and OWASP [35]. The excerpt of the MFA functional requirements, threats, and their mitigation is purposely selected to ensure the scope of study in a manageable time while completely covering the AFMUC approach. Completing the entire case study is out of the scope of this study

Experimentation

A controlled experiment is conducted to evaluate the ambiguity of the proposed approach. The experiment is designed and reported according to the template provided by Wohlen et al. [38].

Planning and design.

This section describes the planning and design of the controlled experiment.

• Objective and motivation: The experiment is conducted to perceive the viewpoint of the information security students about the unambiguity of the proposed approach for analyzing the crosscutting security threats and their mitigation.

• Goal: The goal is to assess how unambiguous the AFMUC is in modelling and specifying the aspect-oriented security threats and mitigations.

• Research questions: To address the goal of the experiment, the research question is formulated as:

1. RQ: Is the AFMUC unambiguous enough to model the crosscutting security threats and mitigations?

Therefore, this leads to the definition of the two-tailed hypothesis.

1. H₀: AFMUC is ambiguous in modeling crosscutting security threats and mitigations.
2. H₁: AFMUC is unambiguous in modeling crosscutting security threats and mitigations.

The ambiguity of AFMUC restriction rules to specify crosscutting security threats and mitigations, is measured in terms of understandability, applicability, restrictiveness, and error rate adopted from [31,39]. This experiment has four dependent variables, namely understandability, applicability, restrictiveness, and error rate, and one independent variable as AFMUC restriction rules.

• Dependent variables:

1. i. The understandability is assessed based on a common understanding of the AFMUC constructs and restriction rules.
2. ii. The applicability is evaluated by determining whether the AFMUC constructs, and restriction rules are applicable to specifying the aspect threats and mitigation.
3. iii. Restrictiveness is evaluated to assess whether the AFMUC constructs, and restriction rules are challenging to specify aspect threats and mitigation.
4. iv. The error rate is used to measure incorrect implementation of the AFMUC restriction rule.

• Independent variable:

1. i. AFMUC restriction rules are unambiguous in terms of high understandability, applicability, low restrictiveness and error rate.

• Population and sampling strategy: The target population of the experiment consists of university students as participants from an information security program. The sample of 24 students is selected using a non-probabilistic convenience sampling technique [40]. Considering this, the students are chosen based on ease of access, having studied courses such as information security, cybersecurity, and secure software design and development. The students are familiar with the threats, mitigations, UML designs, and misuse cases. However, students have no prior understanding of aspect-oriented modeling. To address potential bias, a training session is conducted to familiarize the subjects with AOM before the experiment. The rationale for selecting these students is to find samples that could quickly be trained to use the AOM approach over a short time. The students are recruited for two days and motivated to attend the experiment by being graded for participation. On March 19, 2024, a comprehensive training session is held and completed. On the second day, March 26, 2024, a controlled experiment is conducted to apply and evaluate the proposed approach. Both sessions lasted three hours. Before engaging in the experiment, students are asked to sign a consent form indicating their willingness to utilize their experiment results for research purposes. Additionally, the experiment plan had undergone a thorough review and received approval from the Research Ethics Committee of the Computing Department of Riphah University before the execution of the experiment. Subjects actively involved in the experiment expressed their agreement by signing the consent form, confirming their understanding and approval to utilize the obtained data for research purposes. This process ensured a transparent and ethically sound approach to obtaining participants’ informed consent.

A questionnaire-based evaluation is selected for data collection on the reasoning by Ardalan et al. [19] that constitutes three things: (1) the sample population is not too large, (2) the responses are required on the day of the experiment, and (3) quantitative data is required.

• Data collection: The ambiguity is determined by using four metrics such as understandability, applicability, restrictiveness, and error rate. Quantitative data is collected for each of the four metrics. Understandability is measured by a dichotomous scale (Yes/No) while applicability and restrictiveness are assessed using a four-point Likert scale. Also, mathematical formulas are designed to calculate the error rate on a scale of 0 and 1.

• Questionnaire design: The quantitative questionnaire is designed to address the research question by focusing on the dependent variables. Each questionnaire is designed to obtain responses for AFMUC constructs and restriction rules. The questionnaire guidelines are adopted from Yue et al. [31,39]. Table 4 represents the questionnaire consisting of three closed-ended questions on the understandability, applicability, and restrictiveness of AFMUC. Question 1 is used to measure the understandability of the approach on a scale of yes/no. Each rule is evaluated to determine whether the subject understands the restriction rule and shares a common understanding. Question 2 contains the question regarding applicability of the approach. It defines whether the subjects can properly apply the AFMUC restriction rules for specifying the aspect threats and their aspect mitigations. It is evaluated on a four-point Likert scale. Lastly, question 3 is used to evaluate the restrictiveness of the proposed approach, which assesses whether the subject finds the restriction rule challenging to specify. It is also evaluated on a four-point Likert scale.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 4. Questionnaire to evaluate ambiguity of AFMUC in terms of understandability, applicability and restrictiveness.

https://doi.org/10.1371/journal.pone.0322664.t004

This questionnaire aimed to gather their subjective opinions on the proposed AFMUC approach, evaluating their perceptions of understandability, applicability, and restrictiveness. The quiz assessment is designed to ensure their understanding of the proposed approach to avoid any potential subjectivity bias in obtaining the data for each measure. The complete quiz is given in “S1 Appendix”. The quiz questions are designed for each aspect. There are three sections for each question, Section A consists of questions regarding the pointcut expression, including joinpoints. Section B defines the question regarding the advice, and Section C presents a general question. Regarding the aspect element introduction, Section A addresses questions on introduction expression, and Section B consists of a general question. All questions are closed-ended questions, structured as multiple-choice questions, except one open-ended general question where students are asked to justify their choice, whether they experienced any uncertainty in identifying threats or mitigations. All multiple-choice questions contain one correct answer except those marked with three asterisk symbols (***). The justification provided by subjects for each answer is carefully analyzed to assess their understanding of the respective aspects. Total, there are ten multiple-choice questions covering aspects threats and mitigation, and six general questions. The responses to the quiz questionnaire are used to validate the data collected, but they are not analyzed to test the experimental hypothesis.

• Error rate measure: For the measure of error rate, the raw data is collected from the AFMUC aspect threats and mitigation template attempted by each student. The error rate measures the inaccurate application of the restriction rule. It is measured on a scale of 0 and 1. Table 5 describes the units to collect the raw data in the form of mistakes made by students in each aspect. These units measure the individual error count for each AFMUC restriction rule presented in Table 6. And finally, the sum of error rate for each restriction rule, aggregated across all students, is calculated using the formula Error Rate_r, as defined in equation 1. All these units and formulas are adopted from Yue et al. [31,39] and modified according to AFMUC restriction rules. For example, the error rate for R1 is calculated as the average of (N_missed/N_UC). It captures the rate of occurrences where the BF keyword should be applied, but it is missing. The variable (N_m) calculates total mistakes made when applying the keyword BF. The formula (N_m/N_BF) calculates the frequency of keyword BF being misused, applied in an inappropriate context, or used when it should not be. The specifications of the error rate for each rule are specified in Table 6, along with the description of variable (N_m) for measuring the errors for each rule. “NA” represents the measure is not applicable for restriction rule in a specific aspect.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 5. Metrics to calculate raw data for each aspect.

https://doi.org/10.1371/journal.pone.0322664.t005

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 6. Measure of the error rate for each restriction rule as aspect threat and aspect mitigation.

https://doi.org/10.1371/journal.pone.0322664.t006

The formula for calculating the error rate of each restriction rule is further defined as follows:

(1)

Error Rate_r represented the sum of errors made by all the students S for a particular AFMUC restriction rule across all defined aspects ErrorRate_aspect. In other words, each student evaluated the application of a given AFMUC restriction rule across all defined aspects, and any mistake made during implementation is measured as an error. The sum of these errors across all students and all aspects is used to calculate the overall error rate for that rule. This metric provides a quantitative measure of incorrect implementation of the AFMUC restriction rule.

• Statistical test: A Spearman correlation statistical test [41] is used to measure the strength and relationship between understandability, applicability, restrictiveness, and error rate. The proposed approach is assumed to be highly understandable and applicable with less restrictiveness while reflecting a low error rate.

Experiment preparation and execution

The following are the steps outlined to prepare and execute the control experiment.

Ambiguity in aspect threat and mitigation specification

The objective of the research question is to evaluate the ambiguity of the proposed approach in terms of understandability, applicability, restrictiveness, and error rate. For this purpose, each restriction rule is evaluated using four quantitative measures: understandability, applicability, restrictiveness, and error rate. The first three measures are used to determine the subjective opinion of the students, while the error rate gives the objective measure to collect the errors while applying the rules by students. The results are compiled and presented individually for each measure. Also, a statistical Spearman’s rank correlation coefficient test is applied to assess the correlation between these four measures. The data collected for each metric is provided in “S2 Data”.

Understandability.

Understandability is measured based on a subjective opinion of students for each restriction rule. As shown in Fig 12, twelve out of sixteen rules are considered highly understandable with a threshold frequency rate of 90% or above. The rules R3, R4, R6, and R13 received a frequency of 90%. Rules R1, R5, R9, R10, and R14 are rated at 95%. Meanwhile, rules R2, R11, and R12 are rated completely understandable with a 100% frequency rate. In contrast, rules R7 (JOINPOINTS) and R8 (ADVICE) received an 85% score, which is slightly understandable. However, the R15 (70%) and R16 (80%) got the lowest score, with R15 representing the least understandable rule. It is observed that R15 and R16 are related to the “introduction” construct in AFMUC, a concept that students find difficult to grasp. This highlights a need to put more training effort into these rules.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 12. Understandability of AFMUC restriction rules.

https://doi.org/10.1371/journal.pone.0322664.g012

In general, it is observed that most of the restriction rules are understandable up to a sufficient level by the students.

Applicability.

Each rule’s applicability rate is determined according to how students believe it should be applied using a four-point Likert scale from completely agree as “1” to completely disagree as “4”. In Fig 13 shows the analysis of high applicability based on the frequency of responses rated as “agree” for the restriction rules when the threshold score is 90% or above. And disagree when the score is below 90%. The results show that twelve out of sixteen rules are highly applicable, with most students showing high applicability. Within these, rule R11 gets 90%; rules R1, R3, R5, R9, R10, R13 and R14 get a 95% rating. while R2, R4, R6, and R12 are considered fully applicable because they all have 100% agreement. However, rules R7, R8, R15, and R16 receive an applicability rating below the 90% threshold. Each rule, R7, R15, and R16, gets an applicability score of 85%. With 80%, R9 is considered the least applicable. Although the applicability of these rules is slightly lower than others, the difference is not significant enough to suggest they are inapplicable. It is observed that rules R7, R8, R15, and R16 received a lower rate not only in applicability but also in understandability. This indicates that they are more challenging to understand and thus relatively difficult to apply. Intensive training or automated tool support could improve the understanding and applicability of these rules.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 13. Applicability of AFMUC restriction rules.

https://doi.org/10.1371/journal.pone.0322664.g013

Restrictiveness.

Fig 14 shows the restrictiveness of the rules, which shows the subjective measure of the students regarding the difficulty and challenges in specifying the aspect-oriented threats and mitigation. The measure is assessed on the scale of four-point Likert scale, “1” for completely agree and “4” for completely disagree. The results are analyzed on the frequency of responses for “agree” which tells the perceived restrictiveness. The threshold for low restrictiveness is defined as 20% or less showing “agree” and “disagree” when the frequency is greater than 20%. The results show that twelve out of sixteen rules are highly restrictive, with scores above 20%. This includes rules R1, R3, R5-R11, R13, and R15-R16. Among these, rule R8 has the highest restrictiveness rate at 45%, indicating that applying the Advice is challenging for students. Rules R15 and R16 exhibit high restrictiveness with a rate of 40%. Notably, these three rules, R8, R15, and R16, have also received a lower rate of understandability and applicability. The rules R6 (35%), R13 (30%), R1, R3, R5, R7, R9, R10, and R11 each show the restrictiveness rate of 25%, which may be considered less challenging given their high rating for understandability and applicability. In contrast, four rules, R2, R4, R12, and R14 are identified as less restrictive. These rules are also most understandable and applicable, indicating that students find them easy to understand and apply.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 14. Restrictiveness of AFMUC Restriction Rules.

https://doi.org/10.1371/journal.pone.0322664.g014

Overall, 80% of the students find the rules too restrictive for specifying aspect-oriented threats and their mitigation. This is likely because they applied the rules for the first time and have only recently been introduced to aspect-oriented modelling techniques, which are new to them. This unfamiliarity has made it challenging for them to specify aspect-oriented threats and their mitigation effectively.

Error rate.

Error rate represents the incorrect implementation of the restriction rules while specifying the aspect-oriented threats and their mitigation. The rule is considered to have a high error rate when its score is ≥ 5%. In Fig 15, the results show that ten out of sixteen restriction rules attain a high error rate. The highest error rates are R11 and R6, at 11.6% and 10%, respectively. The high error rate for R11 is due to the misuse of the AROUND advice type rule, often applied in situations where it is not required. Similarly, R6 has a high error rate because the pointcut expression contains three different logical expressions inside: (1) specifying the name of the use case or misuse case where the aspect threat or mitigation aspect pointcuts, (2) selecting elements such as BF or BTF in the relevant case, and (3) selecting the constraint to identify the attack surface in the use case or the mitigation surface in the misuse case. It is observed that the high error rate for R6 is due to not completing the expression or specifying the expression in the wrong situation. It is also analyzed that ten rules with high error rates, R1, R2, R4, R6, R7, and R9, R11–R14, involve key constructs of aspect-oriented modeling, such as specifying pointcut R6 (10%) and joinpoint R7 (8.50%). It shows a higher error rate in identifying joinpoints in the basic flow R1 (7.64%), and precondition R2 (6.67%), and applying the type of AROUND advice R11 (11.6%), and BEFORE advice R9 (7.50%), respectively. The advice threat behavior (BTF), as R4 also shows, has a higher error rate of 7.19%. Furthermore, using logical operators R12, R13, or ALL R14 to select joinpoints also contributed to higher error rates at 5.33%, 6.88%, and 7.71%, respectively. These quantitative findings suggest that students face challenges applying these rules specific to AOM constructs, such as pointcut, joinpoint, and advice. Additionally, it is also analyzed that rules R2, R4, R12, and R14 are perceived as highly understandable, applicable, and less restrictive to use however they present challenges during implementation in actual scenario. It is believed that the high error rates for these essential AOM constructs stem from limited exposure and experience with aspect-oriented modeling. Providing tool support or further training on these rules helps lower the error rate.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 15. Error Rate of AFMUC Restriction Rules.

https://doi.org/10.1371/journal.pone.0322664.g015

In general, it is observed from the results that very few restriction rules are correctly implemented, such as R3, R5, R8, R10, R15, and R16, with low error rate. These rules include introduction expression (R15, R16), applying AFTER (R10) advice at the POSTCONDITION (R3) with correct advice expression (R8), and implementing mitigation flow (R5) to threats.

Statistical analysis

This section establishes the significance of results through statistical analysis. It analyzes the correlation between the understandability, applicability, restrictiveness, and error rate. It is expected that the rules that are easy to understand and apply should be less restrictive and have a lower error rate. For this a statistical test Spearman non-parametric correlation test [41] is performed between each pair of understandability, applicability, restrictiveness, and error rate. Statistical significance is measured using a p-value threshold of ≤ 0.05. Table 7 shows the statistical relationship between the three measures as understandability, applicability, and restrictiveness. It is observed that there exists a positive monotonic relationship between these three variables. Understandability has a meaningful and statistically significant positive relationship with both applicability and restrictiveness with the p-values as 0.022 and <0.001, respectively. This indicates that the AFMUC restriction rules perceived as understandable are also considered as more applicable and less restrictive to use. Similarly, a significant relationship between applicability and low restrictiveness (p = 0.003) also reinforce that AFMUC rules perceived as easier to apply are also less restrictive. These significant relationships between understandability, applicability and restrictiveness, each with p-values below the threshold (p value = 0.05) rejects the null hypothesis and confirms that AFMUC restriction rules are unambiguous to specify the crosscutting security threats and mitigations.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 7. Summary of the spearman correlation test.

https://doi.org/10.1371/journal.pone.0322664.t007

On the other hand, the correlation between error rate and other measures, e.g., understandability (p-value = 0.52), applicability (p value = 0.63) and low restrictiveness (p = 0.725) is weak and statistically insignificant. This indicates that despite being perceived as unambiguous AFMUC rules may still lead to implementation errors. The reason behind this could be that the results are not consistent with all the students, some students have got the maximum understanding of the rules and are able to apply them while making no mistakes or very few. However, some of the students do not have enough experience to apply the rules correctly; those students may have found the rules understandable and applicable with less restrictiveness but when they specify the rules, they make mistakes.

Table 8 shows the integrated result of all four measures to manually analyze the relationship between understandability, applicability, restrictiveness, and error rate. It is worth noting that rules R2, R4, R12 and R14 show high understanding and applicability (90%−100%) and are least restrictive (20%), but still have non-negligible error rate (6.67%, 7.19%. 5.33%, 7.71% respectively) when implemented. The rules R3, R5 and R10 generally scored above 90% in understandability and applicability and low error rate as 4.42%, 1.25% and 3.75% respectively. However, they are slightly restrictive, each with a restrictive rate of 25%. Compared to other rules, R2, R4, R12, R14, R3, R5 R10 can be considered among the most unambiguous AFMUC rules. These rules exhibit consistently high understandability and applicability along with slight restrictiveness (R3, R5, and R10) or slightly elevated error rate (R2, R4, R12 and R14). Which can be further enhanced to reduce implementation errors or make it less restrictive. The rules R1, R6, R9, R11, and R13 also exhibit high understandability and applicability (90% and above), but they also show high restrictiveness and a higher error rate. Therefore, these rules can be categorized as moderately unambiguous AFMUC restriction rules, as they are generally understandable and applicable but are challenging and tend to result in errors during implementation. The rules R8, R15, and R16 can be categorized as highly ambiguous, as they contrast a low error rate (less than 5%) with poor results on the other three measures such as understandability, applicability below 90% and restrictiveness above 20%. This indicates that students have perceived these rules as difficult to understand, less applicable, and challenging, but they applied these rules correctly in accordance with no or few mistakes. And lastly, R7 stands out as the highest ambiguous rule, exhibiting poor results across all four evaluation measures of ambiguity. It shows low understandability (85%), low applicability (85%), is considered restrictive (25%), and has a high error rate (8.5%). This indicates that students face consistent difficulty in understanding and implementing the R7.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 8. Comparative analysis of understandability, applicability, restrictiveness and error rate.

https://doi.org/10.1371/journal.pone.0322664.t008

However, these unusual results may stem from the fact that aspect-oriented modeling and restriction rules are relatively new concepts to the students, leading to challenges in both understanding and implementation.

Comparison of existing (mis)use case approach

This section compares the proposed approach with existing work that specifying the specify the crosscutting concerns using use case Since proposed work AFMUC focuses on the modelling of crosscutting security concerns through misuse case model. Tables 9 and 10 compared with two dimensions: (1) features of aspect oriented supported by use cases such as pointcut, joinpoint, advice and its type, introduction and weaving. (2) features of (mis)use cases supporting by the aspect oriented approach such as precondition, basic flow, alternate flow, postcondition and dependency. Based on the above comparison criteria, eleven existing studies [10,14–21] address the aspect oriented features in the context of use cases. Table 9 characterizes these works with respect to their coverage of important aspect oriented modelling constructs including aspect, pointcut, joinpoint, advice, types, introduction and weaving also characterizes the model and requirements that are specified as crosscutting concerns. For instance, Table 9, the approach presented in [18] and [19]only supports modelling crosscutting security concerns using aspect oriented construct as pointcut, joinpoint and advice (indicated by +sign) in use case specification model. These constructs are also found in other approaches [10,14,17,20,21] but they are used to specify the crosscutting functional requirements [20,21]or used use case diagram instead of specification [10,14,17]. The modelling constructs that are not supported by these approaches are indicated by a – sign. Certain approaches [15,16] address the modelling of crosscutting NFR(e.g., security) using stereotypes but are not supported by AOM constructs. In related work, the existing misuse case templates [7,8] also compared with proposed AFMUC. Table 9 suggests that no misuse case approach is exclusively specify the crosscutting security concerns (e.g., threats and mitigation). Table 10 provides information on the use case features (e.g., precondition, basic flow, alternate flow, postcondition, dependency) use by each approach for modeling aspect oriented constructs, whether the pointcut selects the joinpoints in any of these Use case elements. Table 10 suggests that in [18] and [19] the AOM constructs are used to specify crosscutting security concerns at use case precondition, basic flow, alternate flow and post condition. And related work [21] applied the maximum AOM constructs on all use case elements such as precondition, basic flow, alternate flow and post condition but for specification of crosscutting functional requirements.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 10. Comparative analysis of (mis)use case features used in AOM constructs.

https://doi.org/10.1371/journal.pone.0322664.t010

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 9. Comparative analysis of AOM features supported by (mis)use cases.

https://doi.org/10.1371/journal.pone.0322664.t009

Based on Tables 9 and 10, it is concluded that the modelling of crosscutting security concerns using AOM constructs is significantly adopted by use case approach which is inherently the functional analysis modelling approach. AFMUC, shifts this focus to misuse cases, the most ideal for security threat modeling and mitigation. Also, it facilitates more precise and systematic analysis of cross-cutting security threats and corresponding mitigations using all essential AOM constructs such as pointcut, joinpoint, advice, its types, introduction and weaving. In addition, the AFMUC explicitly and precisely specifies the attack surfaces within the use case basic flow, precondition, postcondition and dependency, that are vulnerable to threats. Similarly, the AFMUC mitigation template significantly enhances mitigation analysis by precisely specifying the mitigation surfaces with the misuse cases precondition, basic threat flow and postcondition. It also proposes the use of introduction constructs and weaved the aspect threat model into base use case model and aspect mitigation into misuse case model in a novel manner. which is a more unambiguous and formalized approach to identify the vulnerable points in the use case model and to analyze their corresponding mitigations.

Comparison to existing UML based aspect oriented approaches.

Several use case profiles proposed in literature to address the crosscutting concerns [12,13,22–27] for different UML diagrams. Table 11 assesses the existing UML profiles focusing on modelling crosscutting security concerns. It characterizes these works with respect to their purpose, and coverage of requirements. For instance, [23,24,26,27] model crosscutting security requirements into UML models using stereotypes, constrain, tagged values, or annotations. Nevertheless, these methods usually depend on security annotations that are incorporated into UML models, which leads to tightly coupled with UML model reducing modularization. Also, they frequently result in scattered and ambiguous representations of crosscutting security concerns. Table 11 also suggests that UML profile in [13] provide implementation of AOM constructs, i.e., pointcut, joinpoint, advice, and weaving to model crosscutting security threats but it supports the modelling in interaction diagram, e.g., sequence diagram.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 11. Comparative analysis of existing AOM based UML profiles.

https://doi.org/10.1371/journal.pone.0322664.t011

In comparison, the proposed AFMUC approach enhances modularization by separating the crosscutting security threats and mitigations from core functional requirements. It adopts an AOM based approach, allowing security threats and mitigations to be specified independently as aspect model and then woven into the functional model. This leads to more scalable and maintainable solutions for modeling crosscutting security concerns in complex systems. Additionally, AFMUC provides analysis of crosscutting security threats and mitigation early in the software requirements phase in SDLC, supporting secure design by facilitating transformation into aspect oriented behavioral models such as mal sequence diagram [13] and AspectSM [12].

Comparison to existing threat modelling approaches.

In comparison to existing threat modeling approaches such as STIDE [42], DREAD [43] and Attack trees [44] provide valuable analyses to the security threats. Table 12 suggested that STRIDE [42] focuses on identifying and categorizing threats and utilizes Data Flow Diagrams (DFDs) to model system boundaries, events, and entities. Another threat analysis approach DREAD [43] is a risk assessment and prioritization model used to evaluate threats. It emphasizes prioritization and mitigation using class-specific controls. Attack Trees [44] provide a hierarchical representation of attack goals and the different ways to achieve them. Table 12 provides that these approaches work well within their scope, they are particularly used to detect threats, priorities threats, and give structural view of threat.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 12. Comparative analysis of existing threat modelling approaches.

https://doi.org/10.1371/journal.pone.0322664.t012

The AFMUC approach provides precise and formalized modeling of crosscutting threats behavior, interaction of threats with the core functional requirements while identifying the attack surfaces. Additionally, it also supports mitigation analysis by identifying crosscutting mitigations, analyzing their behavior, and understanding their interaction with corresponding threats while determining appropriate mitigation surfaces. AFMUC is important for security engineers to understand threat behavior, locate vulnerabilities and mitigation points in the model for secure application development.

Conclusion validity

One of the potential threats to the proposed approach is that the generalizability of the results depending on the sample size selected for the experiment is a good representative of the students. To reduce this threat, a convenience sample technique [40] is followed to select students who are available at the moment and meet the criteria of the study. To generalize the results, the findings are also statistically analyzed using a non-parametric test, specifically the Spearman correlation test which is suitable for the small sample size.

Internal validity

Another threat to the validity of results relates to the experiment design and procedure. To limit these threats, the experiment is piloted with the undergraduate students and faculty of the information security program to reduce any potential bias and ambiguity in the design of experiment objects. At the beginning of the experiment comprehensive training on the new approach aspect-oriented modelling and AFMUC approach is provided to the participants. Additionally, participants are given a home-based assignment on an example case study, i.e., EU-Rent car. Before the execution of the experiment, feedback is provided to individual participants. The assignment is graded to keep participants motivated to learn. Additionally, to assess the results that are based on subjective opinions, participants are asked to complete a quiz during the experiment to prevent potential bias while applying the proposed approach. The quiz is used to check the consistency of the results obtained from experiment and quiz but is not used to conclude the research outcome. Additionally, to maintain the authenticity and integrity of results, the participants are graded in their course while participating in experiment.

Construct validity

There is a threat of the case study design to cover the proposed approach. To validate the AFMUC approach, MFA case study is designed, encompassing sufficient use cases threatened by aspect threats and their aspect mitigation. Five aspect threats threatening two use cases are selected along with one mitigation to mitigate these aspect threats. This ensures comprehensive coverage of the restriction rules, this selection included coverage of all essential constructs of the proposed approach such as pointcut, joinpoint, advice, and introduction. The small excerpt of case study is deliberately chosen because the primary objective is to evaluate the initial viability and coverage of the approach within a specific and manageable context. However, it is important to note that, to the best of current knowledge, the approach presented is novel.

External validity

There is a threat to the validity of time and selection of students as subjects instead of professionals. This threat is addressed by keeping the industrial case study small, including three substantial use cases, five aspect threats, and one mitigation. The focused timeframe of three hours is thoughtfully chosen for a session to effectively assess the AFMUC constructs and restriction rules. This duration is sufficient to guide participants through the tasks without causing exhaustion while allowing for the thorough application and assessment of AFMUC. That is enough to complete in a three-hour session and cover the proposed approach. Selecting students as participants has posed another threat. However, students with suitable knowledge, skills, and backgrounds are chosen, and they have also received comprehensive training on the approach. This decision is made because industrial experts and practitioners have limited knowledge of AOM and would require significant training, time, and cost to learn it. Conversely, students are more inclined to learn new concepts.