A scenario [10], [11] is an artifact that describes situations (within the application or the software domain) using natural language. It describes a specific situation that may arise in a certain context to achieve some goal. The scenario includes a set of steps (episodes) to reach that goal. In the episodes, active agents (actors) use materials, tools, and data (resources) to perform some specific action. Although there are many templates to describe scenarios, this paper will use the one proposed by [23]. Table 1 summarizes the template.

Table 1. Table 1. Template for describing scenarios that focus on functionality.

Attribute	Description
Scenario title	ID
Goal	Objective
Context	Starting point (time, place, activities previously achieved)
Actors	Active agents
Resources	Passive elements (tools, materials, data)
Episodes	List of actions, simple breakdown with no conditions, no iterations

Source: Own work.

Let’s consider the following example scenario describing how an irrigation system is activated. This task could be done in different ways depending on the technological infrastructure of the farm. For example, an operator could manually start the irrigation by physically entering the machine room where the pumps are. In this situation, no IoT software application is involved. Instead, this paper will focus on another kind of scenario where it is a software application that activates the pumps. Now, the example goes as follows: An expert in agriculture evaluates the field conditions to determine whether irrigation is necessary and provides the information to the farm supervisor. Then, the supervisor activates the irrigation pipe using an IoT-based web application. Table 2 summarizes the situation.

The previous scenario describes an authorized person’s legitimate use of the software application to activate the irrigation system. This scenario could be similar to a use case or user story [7]–[9]. However, the software system could be vulnerable to hacking attacks, where a malicious user intends to break into the web software application to start the irrigation system either just for fun or to destroy the crop. This incorrect and harmful utilization of the software application is regarded as a misuse case [24].

Table 2. Table 2. Authorized attempt to start the irrigation system.

Attribute	Description
Scenario title	Attempt to access the water irrigation infrastructure by an authorized person.
Goal	Protect access to the water irrigation system to ensure that water is used responsibly.
Context	The farm has irrigation infrastructure (pipes, tanks, pumps, and valves) to water (irrigate) the field.
Actors	Expert, Supervisor.
Resources	Checklist to determine if it is necessary to irrigate the field. Security protocol to have access to and operate the pump and valves.
Episodes	· An expert evaluates the conditions of the field to determine if it is necessary to irrigate. · The expert writes a report to the supervisor with the recommendation to irrigate. · The supervisor logs in to the IoT web application. · The supervisor starts the pump and opens the valves.

Source: Own work.

Software architecture is the process of designing a system’s fundamental structure and organization to achieve specific quality attributes. Quality Attributes (QA) are critical non-functional characteristics that determine the system’s overall effectiveness. QAs are specified using quality scenarios, which define how the system should behave under various conditions. A Quality Attribute scenario is a specific, testable scenario that demonstrates how a QA requirement is satisfied. A QA scenario is typically structured with an ID, a stimulus that triggers the interaction with the software application, the environment where the interaction occurs, the affected artifact, the response, and some quantitative description of the response. Table 3 summarizes a template for this kind of scenarios.

Table 3. Table 3. Security scenario template.

Attribute	Description
Scenario ID	Unique Some identification of the scenario.
Source of the Stimulus	Some human, system or any other actor generates a stimulus to the system.
Stimulus	It is an input condition that generates a response from the system.
Environment	The stimulus occurs under a certain context. The system may have an overload context, normal operation, or some other relevant state. For many systems, "normal" operation can refer to one of a number of modes. For these kinds of systems, the environment should specify in which mode the system is executing
Artifact	The stimulated artifact. This may be an ecosystem, a whole system, a component, or some set of components.
Response	It is the response as the result of the arrival of the stimulus.
Response Measure	The response should be measurable so that the requirement can be tested.

Source: Own work.

Security refers to a system’s capability to defend itself against danger, ensure its safe-ty, and protect system data from unauthorized disclosure, modification, or destruction. Security involves protecting computer systems using technical and administrative safeguards. Additionally, security refers to the degree to which a particular security policy is enforced with some level of assurance. The three fundamental types of security concerns are confidentiality, integrity, and availability. Confidentiality refers to the protection of data and processes from unauthorized disclosure or access by individuals or entities that are not authorized to access them. Integrity refers to protecting data and processes from unauthorized modification, whether intentional or accidental. It includes ensuring that data are not tampered with or corrupted during storage, processing, or transmission. And availability refers to the protection of data and processes from denial-of-service attacks or other forms of disruption that could prevent authorized users from accessing or using them. This includes ensuring that systems are available and responsive when needed and that they can handle high levels of traffic or activity without becoming over-loaded or crashing. Table 4 is an example of a security scenario that refers to the same situation as the requirement scenario described in Table 2.

Table 4. Table 4. Security scenario example.

Attribute	Description
ID	S01
Source of stimulus	An unauthorized individual attempts to access the water irrigation system through an IoT-connected device.
Stimulus	The individual attempts to gain access to sensitive data (sensor measurements) or to manipulate the system’s functionality (change the valve behavior).
Environment	Normal execution. The system has IoT-connected devices that are used to access the functionality of the solution, such as sensors, actuators, and processors.
Artifact	Security protocol and access control subsystem.
Response	The security protocols detect the unauthorized access attempt and ban the individual from the access control subsystem.
Response measure	Ensure the security of the system. Attacks should be detected quickly, ideally within 0.5 seconds. Additionally, the system must have a high rate of success in resisting attack attempts, with a target success rate above 95 %.

Source: Own work.

Our proposed approach consists of several steps. First, we describe scenarios that outline the intended use of the software. Next, we create scenarios that describe incorrect use of the application in an attempt to exploit any vulnerabilities. We then convert these scenarios into security scenarios by applying a set of preestablished rules. Lastly, we refine and improve the security scenarios. Figure 1 summarizes our approach.

Figure 1. Figure 1. Our approach in a nutshell. Source: Own work.

The first step is the description of scenarios that focus on the correct use of the software application regarding security concerns. This step should be completed by a requirement engineer or analyst (or a group of them), who should interact with domain experts (clients, users, and stakeholders in general) to capture the requirements for the software application and specify scenarios. They should describe the functionality of the intended software and also consider security concerns. Therefore, the analyst eliciting and defining scenarios should have some background knowledge of non-functional security requirements in order to include this concern in the specifications. The result of this step is a set of scenarios that describe the functionality, as illustrated in Table 2.

The second step is analyzing the scenarios that were described in the previous step to find security issues. Issues that exploit the problems and compromise the security of the software application are described. Ideally, this step should be completed by the same requirements engineer (or group of them) that participated in the previous tasks. They should analyze every scenario in detail and consider guidelines such as those proposed by [34], [21]. Then, they describe scenarios of incorrect use of the software application. Basically, they should describe scenarios that exploit possible vulnerabilities. For example, considering the scenario of correct use of the software application to activate the irrigation system (Table 2), the requirements engineer may determine that the access to the system (and therefore the access to the activation of the pumps) constitutes a security breach. Hence, they describe a scenario where an unauthorized person gains access to the software application and, consequently, to the irrigation infrastructure. Table 5 describes this scenario of unauthorized access.

Table 5. Table 5. Unauthorized attempt to start the irrigation system.

Scenario title	Attempt to access the water irrigation infrastructure by an unauthorized person.
Goal	Protect access to the water irrigation system to ensure that water is used responsibly.
Context	The farm has irrigation infrastructure (pipes, tanks, pumps, and valves) to water (irrigate) the field.
Actors	Unauthorized person.
Resources	Checklist to determine if it is necessary to irrigate the field. Security protocol to access and operate the pump and valves.
Episodes	•An unauthorized person gains access to the IoT web application. •An unauthorized person starts the pump and opens the valves.

Source: Own work.

In this step, a set of rules is described to map the information contained in an incorrect use scenario. The goal is to obtain a first draft of a scenario describing security concerns. It is worth mentioning that the incorrect use scenario will not provide enough information for a complete security scenario. The rules proposed here use only four attributes from the incorrect use scenario (title, context, actors, and resources) to fill out four attributes of the security scenario (stimulus, environment, source of the stimulus, and artifact).

With this information, the following step is to refine the security scenario. Table 6 summarizes the mapping between attributes of the two types of scenarios. Following the example of the incorrect use scenario described in Table 5, the scenario obtained by applying the proposed rules is shown in Table 7. This preliminary scenario is still far from being a full-fledged security scenario such as that described in Table 4. It needs to be refined in the following step.

Table 6. Table 6. Mapping rules between attributes of the incorrect use and security scenarios.

Attribute of the incorrect use scenario	Attribute of the security scenario
Title	Stimulus
Context	Environment + Source of the stimulus
Actors	Sources of stimulus
Resources	Artifact

Source: Own work

Table 7. Table 7. Result of applying the mapping rules between attributes of the incorrect use and security scenarios.

Attribute	Description
Stimulus	Attempt to access the water irrigation infrastructure by an unauthorized person.
Environment + Source of stimulus	The farm has an irrigation infrastructure (pipes, tanks, pumps) to water (irrigate) the field. An unauthorized person attempts to operate the pump and the valve to irrigate the field.
Source of stimulus	Unauthorized person.
Artifact	Checklist to determine if it is necessary to irrigate the field. Security protocol to access and operate the pump and valves.

Source: Own work.

Some adjustments and improvements should be made to the scenarios derived from the mapping in the previous step. Some new information should be added, and some should be rephrased. The requirements engineer should use their experience and knowledge to provide further information and paraphrase other based on the elicitation meeting and their expertise in the field. First, the security scenario should be assigned an ID to identify it in the software development process; this is a minor task related to documentation definitions. Afterwards, the stimulus, environment, source of stimulus, and artifact attributes should be rephrased to adapt the information obtained in the previous step. Both the environment and source of stimulus attributes capture data from a single attribute in the incorrect use scenario (i.e., context). Therefore, in the security scenario, the information in context should be split into two attributes. Finally, the response and response measure attributes should be defined from scratch. Although the mapping rules do not provide information about these two attributes, the descriptions found in the rest of the scenario provide the context that requirements engineers need to define them. Requirements engineers should bear in mind that the response measure attribute, in particular, should be described with quantitative measures. The tool described in the following section can support this task.

Table 8 summarizes the necessary refinements in this step. The scenario described at the beginning of this paper in Table 4 is an example of the kind of scenario that this approach aims to obtain.

Table 8. Table 8. Refinement to the security scenarios.

1. An ID must be assigned.	2. Stimulus must be rephrased.	3. Context must be split in two attributes (i.e., environment and source of stimulus).
4. Source of stimulus must be rephrased.	5. Artifact must be rephrased.	6. Response and response measure must be added

Source: Own work.

Security scenarios in smart farms and IoT require a specific vocabulary so that they are accurately described [29] argue, there are several concerns to take into account as part of these scenarios. One such concern is technology-dependent security for IoT devices (artifact), which refers to the security measures required in the IoT context (environment). Another important aspect is the authentication of IoT objects and individuals (sources of stimulus) using various mechanisms to prevent or detect attacks (responses). These responses to potential security threats have several limits (response measure). Requirements engineers could use this vocabulary as specialized terminology and a semiotic tool.

Next, we assessed the acceptance of our approach by security experts in the field of IoT-based smart agriculture, using the Technology Acceptance Model (TAM) [35], [36] to guide our evaluation. Specifically, we were interested in understanding to what extent our approach was accepted by its target audience. To evaluate the usefulness and ease of use of our approach, we adopted two well-known and widely used metrics-Perceived Usefulness and Perceived Ease of Use-as defined in Fred D. Davis’s work [35]. To this end, we designed and administered a survey to a group of security professionals who are representative of our target audience and have experience in eliciting security requirements. Conducting the survey with this group provided us with valuable feedback and insights that helped us to identify strengths and weaknesses in our approach and ultimately improve its overall acceptance.

We conducted a survey with a group of five experts in the field of software and network security. Prior to the survey, we presented our methodology to the group and spent approximately 40 minutes discussing and addressing any questions they had. Once we presented our approach, we administered a survey that included 17 close-ended and three open-ended questions. The survey aimed to gather insights from the experts on the perceived ease-of-use and usefulness of our method. Most of the experts found the proposed security scenario method to be a useful tool for specifying the requirements of agricultural IoT solutions. Half of them think that the proposed method simplifies the process of specifying security requirements, resulting in better quality and control of the specification.

The experts noted that the proposed method is well-defined, easy to understand, and flexible, making it ideal for defining scenarios. Additionally, the evaluation revealed that most (over 60 %) found it to be clear, well-structured, and interactive in its.

While the method was generally perceived as useful and easy to use for developing security scenarios, it was suggested that it needs to be more specific to determine its usefulness in practice. The experts suggested that the method could be enhanced to include specific aspects of cybersecurity, as well as development and implementation elements that are essential to ensuring the security of agricultural IoT systems. This would allow for a complete specification of the security requirements of such systems. Furthermore, it was noted that users need to interact with the method to remember its steps. During the evaluation, the experts identified some areas for improvement, such as incorporating vulnerabilities and risks commonly found in IoT systems, considering different types of users and adversaries, and taking into account various attack vectors.

By applying these suggestions, the proposed method could be further refined to better meet the needs of users and enhance the security of agricultural IoT systems, particularly adding this information to the terminology of the field.

The aim of the prototype is to make the information contained in a scenario more robust, using natural language processing techniques to extend the scenarios with precise information contained in catalogs that have been specifically designed for this prototype [40]. The literature was reviewed to obtain relevant information about the most common attacks that threaten IoT-based agricultural solutions [12], [20]–[22], [41]–[45]. Special attention was paid to identify vulnerabilities and specific attacks, the Quality Attribute (QA), and the architectural layer affected by each type of attack, as well as the corresponding mechanisms to mitigate them. The information thus obtained was transferred to the two following catalogs:

QA (Security): the quality attribute affected by an attack, e.g., privacy.

Example attacks: some concrete examples of the type of attack.

Consequences for the agricultural industry: a description of the impact and consequences the attack may have on the agricultural industry.

Architectural layer involved: a list of the architectural layers that may be affected by the attack.

Layer definition: a description of the affected architectural layer.

Common problems: an explanation of some common problems caused by the attack.

Resources: a list of all the resources that may be involved in the attack.

QA (Security): the quality attribute(s) that may be affected by the attack.

Threats and attacks (1): a list of concrete examples of attacks whose targets are the same as for the main attacks.

Threats and attacks (2): a list of exploits related to the type of attack.

Description: a detailed description of the attack.

Mitigation mechanism: a description of the recommended mitigation protocols or algorithms to mitigate or counter-attack the former attack.

Keywords: a list of words that best describe the attack.

Comments: comments about the specific attack, such as alternative classifications and extra information related to the attack.

These catalogs are organized as tables, each heading corresponding to a column. Each row of the General Security Aspects catalog contains information about one quality attribute (e.g., privacy, confidentiality, etc.). Each row of the Specific Attacks catalog contains information about one specific type of related attack. Figure 4 and Figure 5 show screenshots of the General Security Aspects catalog and the Specific Attacks catalog, respectively.

Figure 4. Figure 4. General Security Aspects catalog (screenshot). Source: Own work.

Figure 5. Figure 5. Specific Attacks catalog (screenshot). Source: Own work.

The operation of our prototype can be summarized as follows. First, keywords related to specific attacks are identified in existing scenarios (both correct and incorrect use scenarios). The catalogs are then searched for the keywords in order to locate the row containing an occurrence of the specific attack. Once the relevant row is identified in both catalogs, the following information is extracted: affected security QA, attack involved, mitigation mechanism, and consequences for the agricultural industry. The algorithm concatenates the information extracted from the catalogs and attaches it to a security scenario in a new field labelled threats. The user can use this information to derive more robust and precise security scenarios.

We expect that our prototype will help requirements engineers to complement correct and incorrect use scenarios for software applications. The following is a detailed description of the algorithm:

Step 0: Preprocessing (Tokenization and POS tagging). This step is carried out using spaCy’s open-source libraries. spaCy’s pre-trained language models are used to tokenize the document and assign POS (part-of-speech) tags to each token.

Step 1: Process scenarios looking for nouns and verbs. First, the document is processed to extract all nouns and verbs (the words concentrating the most important information). The nouns and verbs are lemmatized to obtain their root form. Also, the main subject is captured.

Step 2: Process catalogs looking for ADJ + NOUN sequences. First, keywords from the catalogs are captured using an external source. Then, the catalogs in CSV format are processed using spaCy’s libraries. spaCy’s matcher is used to extract ADJ + NOUN sequences from the catalogs. Matched sequences are filtered. Thus, only the most important matches are kept.

Step 3: Compare the outputs of Steps 1 and 2. Using the output of Step 2, we look for specific words in the output of Step 1 that have the same syntactic structure. That is, the words extracted from a scenario are checked against the words obtained from the CSV catalogs. The number of rows in the catalog where a match is found is counted. This count is stored in tuples (row, no. of matches).

Step 4: Find the row with most matches. The tuples are processed with a max function.

Step 5: Get the relevant information from the catalogs and fill in the scenario. The relevant information is extracted from the row with most matches and tagged as follows: affected QA, threats and attacks, affected layer, layer details, mitigation mechanisms, and impact. This information is then added to a draft of the security scenario, in a field labelled threats. The results of this process are shown in Figure 6.

Figure 6. Figure 6. App output. Source: Own work.

The algorithm strengthens the incorrect use scenario (which is based on the correct use scenario), enabling the expert to complete the information for the analysis and subsequent derivation of the security scenario.