Security Assessment of Agriculture IoT (AIoT) Applications

: Cybersecurity is an important field in our digital world. It protects computer systems and communication networks against theft or sabotage of information to guarantee trouble ‐ free opera ‐ tion in a trustworthy working environment. This article gives an overview of a cybersecurity assess ‐ ment process and an appropriate Cybersecurity Management (CSM) implementation for future dig ‐ ital agriculture applications. The cybersecurity assessment follows the IEC 62443 cybersecurity standard for Industrial Automation Control Systems (IACS), adapted to Agriculture Automation Control Systems (AACS). However, the research results showed application differences; thus, an expansion of the standard is necessary to fill the existing open security gaps in agriculture. Agricul ‐ ture differs from industrial control systems because of the outdoor located field area, which requires other forms of security. An appropriate cybersecurity standard for the agriculture domain is not currently available. However, such a standard will be necessary to define generally applicable pro ‐ cedures to protect agricultural assets against cyberattacks. The cybersecurity standards and regula ‐ tions existing today (2021) are not sufficient for securing the agriculture domain against new and domain ‐ specific cyberattacks. This article describes some of the cyber vulnerabilities identified and provides initial recommendations for addressing them. real ‐ time scheduler, and configured through an external interface. Examples: wireless Sensor Networks (WSNs),


Introduction
Today, all major product suppliers in the agriculture vehicle and machinery manufacturing domain support their products with a set of sensors to gather all available functional and vital data from the machines for maintenance analysis. These data are collected via USB-sticks in the workshop during periodic maintenance phases or, increasingly commonly, initiated via in-time data transfer from the machine to the manufacturer via cellular radio communications. These technologies allow preventive maintenance to shorten the service (nonoperating) time and the collection of highly informative real-time data for the further development and improvement of the machines.
The agricultural companies also benefit from continuous data collection using modern network technology. In this case, all production data are recorded during execution. It enables cooperation with the machinery supplier and the cooperation with other agriculture companies for task optimization and improving product quality. While machinery suppliers exchange data, for example, via DataConnect (used by John Deere, Claas, CNH, New Holland, and Steyr), the farmers collaborate on platforms, like 365farmNet (https://www.365farmnet.com/en, last access on 10 June 2021) and Agrirouter (https://myagrirouter.com/en/, last access on 10 June 2021). The DataConnect interface was originally developed by Claas, 365FarmNet, and John Deere.
The increasing digitalization in agriculture and the associated networking of machines and production systems increases the risk of cyberattacks. Security describes the protection of production plants and all the related components against deliberately or unintentionally caused errors externally introduced to the farm. In the early days of automation, only the Information Technology (IT) sector was affected by security threats. The Operational Technology (OT) domain was isolated from the outside world and was technically set up very simple. Today, the IT domain is seamlessly connected with the OT domain, and cybersecurity measures are necessary for both domains. By widely distributed production facilities (field level), which are typically for agriculture, new points of attack were added, making it easier for attackers to penetrate the production facility, manipulate it, and even impair safety (machine safety). Nowadays, employees who are not IT experts also have to deal with potential security threats. Therefore, it is necessary to carry out a comprehensive security risk assessment of the entire agriculture production system, both from IT and from OT, to ensure an adequate security level. Also, the involved employees must be trained according to existing and new security threats in periodic intervals so they can react quickly and purposefully.
Most importantly, an extensive security program both for the IT and the OT layer must be established to ensure smooth and trustworthy operation. For new agriculture production system designs, cybersecurity is part of the system architectural design (Security-by-Design). For pre-existing legacy agriculture production systems, a security assessment exposes the necessary cybersecurity improvements to guarantee a defined, sufficient security level.
This article gives an overview of the cybersecurity work and the research outputs of the European research project "AFarCloud" (http://www.afarcloud.eu/, last access on 10 June 2021), with a focus on Cybersecurity Management (CSM) methods research in agriculture. The AFarCloud project deals with the aspects of the current ongoing and future digitalization in the agriculture domain. AFarCloud defines a general architectural structure of a data driven agriculture architecture divided into four function levels, as shown in Figure 1. Starting from the cloud level (Level 4), the system connects with the Farm Management System (FMS) and external data repositories, then to the middleware function layer (Layer 3), and finally, down to the farm level functions (Level2) and the field level (Level 1) devices. In this architecture, CSM is embedded as a cross-layer service, both for the FMS, the semantic middleware, which includes the cloud-based data processing, the decision making and the data repository functionalities, and finally, for the hardware elements at the field level, such as sensors, vehicles, and actuators. Figure 1 will be described in more detail later in Section 2.
Cybersecurity is a very important issue in modern agriculture, according to system security and data confidentiality. Today's agriculture production plants are equipped with a huge number of interconnected computers and modern electronic equipment. These components and the data communication between them must be considered in a cybersecurity risk assessment. The use cases and applications, where all system components are involved must be added to the system description, and all involved stakeholder's roles complete the overall system description for the cybersecurity assessment.

Security Standards Overview
The following overview of well-known safety and security standards shows that the main initiatives to create security standards come from the industrial automation and mobility (vehicles, railway, avionics) domains.
Security standards for agriculture mainly handle the area of food and nutrition security, while no dedicated standards are defined for the agriculture IT/OT security domains at the present. But in this case, today's well-established industrial control security standards are a perfectly good source for agriculture applications too.
The following overview lists some cybersecurity standards from the IT/OT domain:  ISO/IEC 15408 establishes the general principles of IT security evaluation;  ISO/IEC 27000 overviews the Information Security Management Systems;  ISO/IEC 27001 specifies a management system for information security;  ISO/IEC 27002 describes guidelines for organizational information security and information security management practices;  ISO/IEC 27005 brings guidelines for information security risk management;  ISO/IEC 62443 Industrial Communication Networks-Network and System Security series.
Food Security concerns the availability and sufficient access to food. Food security is ensured by using new agricultural technologies and by establishing good product quality.
The focus of safety standards for agriculture are in safety regulations: to prevent illnesses and injuries from agriculture work by pesticide handling and to guarantee a safe use of heavy machines and safe work with animals.
Food Safety concerns the production of wholesome food products. A lot of safety standards and legal regulations for food safety are defined.
Animal welfare regulations ensure animal-friendly treatment of livestock. To provide cybersecurity requirements, a successful approach could be the adaptation of the cybersecurity standard IEC 62443 as a basis to assess the security vulnerabilities in the agriculture domain. The standard describes a security analysis flow and recommendations for the system development and the assessment of existing systems. Adapting a cybersecurity standard for Industrial Automation Control System (IACS) makes sense because the hardware and software architecture is similar in these two domains and the vulnerabilities are of the same types, except for the extensive differences at the field level. Both system architectures have a similar structure: field area, edge processing area (middleware), and administration and planning area (farm management, data repository). On the industrial control side, in most cases, the field elements are enclosed in industrial control buildings and are, by this circumstance, easy to protect and to supervise. In the agriculture domain, the field elements may be installed and located far away from the farm buildings and these elements are more likely to be endangered by manipulations, destruction, and risk of theft.
There are many reasons why cybersecurity attacks will be performed. The following must be considered for a cybersecurity analysis.

Cybersecurity Attack Motivation
There are three groups of attack motivation types identified: espionage, destruction, and sabotage, as described by examples in the following list. Man-in-the-Middle (MITM) attacks To limit possible cyberattack risks in agriculture applications, a cybersecurity management process must be installed to identify the system vulnerabilities with the possible attack vectors, and to propose suitable countermeasures.

Cybersecurity Considerations
Cybersecurity examines various aspects and points based on the following four considerations:

Technical Considerations
Cybersecurity in agriculture is different in contrast to security in industrial production, but both system architectures have, as already mentioned, a similar structure: field area, edge processing area (middleware), administration and planning area (farm management with Mission Management Tool (MMT), Decision Support System (DSS), and system configuration for agriculture), and cloud service/storage area.
Relevant components: software applications, embedded devices, host devices, network devices, etc.

Vulnerability Considerations
There are multiple reasons why an attacker performs a cyberattack on vulnerable Internet of Things (IoT) systems. One of the most common reasons is stealing or leaking of information. A secondary reason is the manipulation and sabotage of smooth operation of the agriculture processes to disrupt the correct operation.
The given attack vectors are, as already mentioned above, more extended in agriculture because of the wide, not gapless monitoring, field area. Also, there are attack vectors in the communication links and (cloud based) managing and planning area (farm management and system configuration).
Relevant: type of attackers, attack vectors, etc.

Economic Considerations
This viewpoint considers the aspect of the security options available for small (S), mid-sized (M), and large (L) agriculture companies (AC). In general, a L-AC has more economic options for security measures in the company compared to that of S-and M-ACs; it is possible that an L-AC could employ security experts in-house full-time. What are the possible threats and vulnerabilities for such ACs, and what are suitable solutions for external support if needed by the S-and M-AC?
Relevant: farm size, IT/OT experience at the AC, etc.

Privacy Considerations  Data Privacy
This view handles the question of data security and gamification. The future agricultural IoT landscape produces Masses of Data (MOD). The MOD has a value and each farmer must receive the possibility to sell it similarly to agriculture goods. Here, data security is a very important topic. Who is storing the data in the cloud and where? How reliable are the security measures of the internet, the cloud, and the digital service provider? Is this answerable by S-and M-AC without external assistance?
Relevant: who is the owner of the digital data produced; who ensures data security; who handles the intellectual properties, etc.

Materials and Methods
To perform a cybersecurity assessment, a standardized process brings the best results when security statuses are compared, the ongoing improvements are assessed, and the work carried out is certified.
In this chapter, the cybersecurity assessment of a given system, worked out in the AFarCloud project, is explained in more detail as a practical example. The assessment is carried out according to the cybersecurity standard IEC 62443. As a reference, this standard, a well-established work standard for IACS's, is used and adapted for agricultural applications.

Cybersecurity Management Methods
There are well-defined methods for cybersecurity analysis that define measures for a new design or how to implement such measures in an existing system. Monitoring and maintenance cybersecurity for a system is a mandatory continuous process to guarantee maximal cybersecurity situation for the whole life period of the given system. These four tasks are evident.

The System Operation States
One aspect of the cybersecurity assessment is the definition of all system operation states which the system will pass in their overall life cycle. Table 1 lists an example of four main cycles of a system life cycle: production, installation, operation, and decommissioning. Each of these operating states can be divided into substates to define the performed activities and consider the possible security vulnerabilities for the different operation conditions. A security assessment is never fixed to only one of the system's life cycles, and furthermore, for a complete security assessment, all cycles must be rated and analyzed with the same level of care and precision. For example, an unsafe and undefined process in the "decommissioning" state is the disposal of old data storage devices, which can lead to a data breach. This could enable third parties to recover highly sensitive system information, using it for attacks in the "operation" state of the new devices. However, if all operating cycles are not considered during the safety assessment, this fact must be carefully recorded in the safety documentation.

Cybersecurity Assessment Key Questions
An assessment process should always follow the same procedures. This is important because a cybersecurity assessment must be repeated periodically to identify new types of vulnerabilities and to improve the system against new attack vectors. This enables successive evaluations to be compared. Further aspects in the cybersecurity process are the roles and responsibilities of all persons involved. The IEC 62443 security standard defines three different roles of competence and responsibility. The Asset Owner (AO) operates the Agriculture Automation and Control System (AACS), and the System Integrator (SI) integrates the functionalities and components in the AACS, instructed by the AO. The Product Supplier (PS) develops and validates the functionalities and components used and provides these with appropriate test certificates to the SI. All these roles must be considered in the CSM processes.
The cybersecurity process must be coordinated with the AO, who must agree and support the mandatory tasks to harden the system according to the actual possibilities in technology.
The CSM process consists of the four main cycles: o Security assessment and analysis. o Security measure installation. o Security guidance and training. o Security verification.

The Cybersecurity Assessment Process
The standardization of a cybersecurity assessment process was mainly driven by the initiative of the International Society for Automation (ISA) and the American National Standards Institute (ANSI) started in 2002. Originally named ANSI/ISO-99, it was later renamed as the ANSI/ISA-62443 standard series. In 2009, the European standardization committees utilized a fundamental concept from the original ANSI/ISA-62443 standard to introduce the IEC 62443 cybersecurity standard series [1][2][3][4][5][6][7][8].
The industrial security standard IEC 62443 specifies a security assessment process for the overall system domain, both from the system and component view. Different security aspects are relevant for the security assessment, and these aspects must be analyzed. The appropriated analysis results are documented in a security documentation and define the security determinations in a security plan.
The security assessment process flow defines five dedicated steps, as shown in Figure  2. Each step must be performed to carry out a standard cybersecurity assessment.
An assessment process should always follow the same procedures. This is important because a cybersecurity assessment must be repeated periodically to identify new types of vulnerabilities and improve the system against new attack vectors. This enables ongoing and comparable evaluations. The process defines five main activity steps and one decision and assessment step. The following overview of the process steps gives a short introduction. In the following chapter, the steps and the necessary activities are explained in detail.  SuC Identification: Activity: accurately describe the SuC for which the security assessment shall take place. It is important to define the borders of the system to define what is and is not part of the SuC.  High-level cybersecurity risk analysis Perform a high-level security risk analysis of the system defined by the SuC description. Determine the Target Security Level (SL-T). This is the minimum cybersecurity level the system must have.  Split into zones and conduits Split the SuC into zones (system areas with similar criticality) and define the communication paths (conduits) which connect the zones. This activity prepares the system for the detail cybersecurity assessment.  Detail cybersecurity risk analysis Perform for each zone and conduit a detailed risk analysis. The analysis determines existing threats and vulnerabilities. The standard IEC 62443 provides seven Foundational Requirement (FR) groups to support the analysis. By the definition of a suitable SL the standard provides a set of requirements that must be fulfilled and well-ordered in the seven FR groups. Each group specifies a set of sub-requirements, depending on the selected SL.  Tolerable risk assessment Repeat the detailed risk analysis in a loop manner until the SL-T matches the Capability SL (SL-C). The system or component capability level describes the maximal realizable SL by implementation. When no match can be targeted, the system does not provide the necessary SL. In this case, a possible solution may be to embed the entire system in a safe, enveloping operating environment.  Document requirements and countermeasures Document all the security implementations, security requirements and any security artefacts to create a final cybersecurity report. The actual security implementation documents the Archived SL (SL-A).

Process step: SuC Identification
The cybersecurity assessment process starts with the exact and careful definition of the system which shall be assessed. An appropriate system description of the SuC must first include a general description of the system use and all planned applications. These descriptions are important for a general vulnerability and security threat estimation. A list of the hardware and software components (assets) involved defines the level of available and necessary security features. Next, a detailed system overview, in the form of a block diagram, shows all the components in a sector of identical criticality and the interconnections between the sectors, where data are transmitted. Finally, the definitions of the system borders are significant. An incomplete system description or an inaccurate system border definition will lead to an inconsistent safety assessment. This can have the consequence that the security assessment delivers wrong results or calls for unnecessary measures, thus leading to undesirably higher implementation costs. It is very important that the system to be assessed is described completely with a sufficient level of detail. Defining the system in an inadequate way implies the hazard that important system security issues may be overseen, whereas too large a system definition may lead to unnecessary security risk analysis efforts, which usually do not help improve the security of the system.
The output of this step is a detailed system description, which is the basis for the next assessment steps. This document is part of the overall security assessment documentation and describes the actual system state. This is an important input to identify changes when performing a periodical security reassessment in the future. When the SuC is carefully defined and documented, an imported step is done to know the assets, which must be protected against cybersecurity attacks.
In the IACS domain, IEC 62264 defines an edition of functional hierarchies of the industrial automation process (IAP) [9], as shown in Figure 3. The "Sensing and Actuation" segment is located at the bottom of the pyramid, with the sensors and the actuators (IAP: Level 1). On top of the pyramid is the "Business Planning and Logistics" segment (IAP: Level 4). Between these segments, both the "Monitoring, Supervision and Control" segment and the "Manufacturing Operations and Controls" segments are arranged (IAP: Level 3 and Level 2). In most cases, Level 0, Level 1, and Level 2 are found at a single geographical location, generally in a company building. Level 3 and Level 4 could be located far away from the building, possibly anywhere worldwide. The top levels can operate by using cloud-based services and can be partially outsourced to third-party companies. These decentralized system architectures are becoming more and more general for both large and medium-sized companies.
In AFarCloud, a comparable system architecture for agriculture applications was defined and developed as shown in Figure 1. It is divided into four main-segments. On the bottom, in the "Field" segment, there are the sensors and the actuators for the livestock and crop process activities. On the top "Farm Management" segment, functions, such as mission management and configuration, are provided. Also, the data repositories are installed in the top segment level by using cloud-based services. The "Semantic Middleware" segment provides services to collect and distribute data and to perform decision finding by processing actual and historical data. In this segment, the CSM services are installed to support the overall system with security processes. The "Farm" segment provides the OT functionalities for data collecting and distributing, and acts as the fog or edge computing layer.
In Figure 1, all communication interfaces established between the segments are illustrated. While, in the field segment, numerous different communication protocols are in use, adapted for a special use and application, the higher segments are only supported by some selected communication paths and protocols to improve the data and cybersecurity. The yellow key and lock symbols give a rough overview of implemented cybersecurity measures.
The following overview lists all assets of the system architecture. Only a short excerpt of the available hardware and software and the communication protocols in use are given. In a real cybersecurity assessment, the system documentation is performed in more detail. Each detail of interest is important to find the appropriate security protection level and to identify potential security vulnerabilities.
The drones link directly via cellular communication to the Data Distribution Service (DDS) manger in the semantic middleware using the DDS protocol.  The hardware and software assets of the "Semantic Middleware" and the "Farm Management" segments are denoted as "services". This means that the services are executed on one or on different computing units by the appropriate service provider.
In the architecture segments Levels 1 and 2, the asset owner has full control over the installed security measures to harden the system against cybersecurity attacks. For Levels 3 and 4, the asset owner can only perform a very accurate provider selection and must trust that the defined security specifications are fulfilled. The asset owner has little or no influence upon the security conditions of these services. He/she can only request security certificates and must trust the service provider on compliance with the duty of caution. Unfortunately, from time to time, one hears about cyberattacks against service providers in which private customer data was stolen. Further points of discussion in security and privacy are the questions of where the data are stored by active service providers operating worldwide with remotely located cloud-based data repositories and service farms.
Continuous security monitoring is the only activity the asset owner can perform to increase confidence. This is a requirement which may be performed by medium and large farm companies. Small farm companies need support and consultation from their professional associations to reach a level of security and privacy such that the company can work trouble-free.

Components (Assets) Location
To perform a cybersecurity assessment, the location of the components of the architecture must be first considered. In Figure 1, the associated components (assets) of the AFarCloud architecture are shown and categorized in three criticality groups: (a) Components located outside in the field or outside a farm outbuilding: If the overall SuC is very complex, a good approach is to divide the overall system into sub-SuCs, where each individual sub-SuC receives its own cybersecurity assessment.
The overall SuC in Figure 1 will be divided into the following sub-SuCs:  The documentation of all five sub-SuCs would go beyond the scope of this document. In this case, only "Soil-sensor SuC" is used as an example (see Figure 4) to document the cybersecurity assessment process further on. Furthermore, in this paper, the cybersecurity assessment focuses on field sensor security in segment 1 (Field) and segment 2 (Farm). This reduces the scope of the work and the size of the paper and gives a sufficiently detailed overview of the cybersecurity assessment process. On the other hand, segment 1 (Field) and segment 2 (Farm) are of great interest to the farm staff, as these are their areas of responsibility. The sub-SuC "Soil-sensor SuC" defines the architecture, the components and the sensor communications data flows of a soil sensor application. It defines the sensor to the middleware and the middleware to the mobile MMT data communication. It provides a set of sensors in the field zone which transfer sensor data via Long Range Wide Area Network (LoRaWAN) or by using the Bluetooth Low Energy (BLE) transmission protocol to the cloud repository in the middleware. The farmer on the field side can request postprocessed environmental data via a telecommunication link on a mobile MMT device (smart mobile phone, tablet with 3G/4G functionality).

Process Step: High Level Cybersecurity Risk Analysis
When the SuC, or the sub-SuC, is clearly defined, the maximal allowable cybersecurity risk shall be fixed at a high-level view. The output of this assessment process step is the definition of the minimal acceptable SL of the target SuC. This fixed SL is also named SL-T and represents a reference point in the further assessment process.

Cyber SL's
The standard defines four SL for the protection classes. Each class defines the protection capability necessary to protect the system again potential attacks, as listed in Table 2.

SL-0
No specific requirements or security protection necessary SL-1 Protection against casual or coincidental violation SL-2 Protection against intentional violation using simple means with low resources, generic skills, and low motivation SL-3 Protection against intentional violation using sophisticated means with moderate resources, IACS specific skills, and moderate motivation SL-4 Protection against intentional violation using sophisticated means with extended resources, IT specific skills, and high motivation The SL-1 and SL-2 will be sufficient for small and medium agriculture enterprises to ensure a general cybersecurity protection against many of the known cyberattacks. The necessary cybersecurity countermeasures can be managed by the farm staff itself. It is important that general and mostly recommended precautionary measures are observed and implemented.
The SL-3 and especially SL-4 require advanced knowledge and precautions, which in special cases can only be achieved by well-equipped and educated experts. If necessary, this knowledge can be requested from cybersecurity service providers.
For example, the Component Requirement (CR) 2.1 (Authorization enforcement) requires the establishment of access regulations for each user regarding certain actions (e.g., access control, read/write/execute). For SL-2, this requirement is mandatory for all users (humans, software processes and devices), not only for humans, and it requires that the access rights are mapped to roles. SL-3 additionally requires that in the event of emergencies or other serious events a supervisor allows an operator to quickly react to unusual conditions by overruling the access control. SL-4 requires a dual approval for actions which can have a serious impact. These requirement enhancements are required for most of the base requirements by the IEC 62443 cybersecurity standard.

Security Aspects
In the following paragraphs, the security aspects are discussed in detail and supported by values to determine the SL with a defined valuation method.
To define the minimum acceptable security level, various security aspects must be considered and assessed, such as: Software applications consist of one or more software programs and their dependencies that are used to interface with the process or the control system itself (for example, configuration software and history database During the high-level cybersecurity risk analysis, possible system vulnerabilities are identified. Definition of system vulnerability: the vulnerability describes the disability of a system to withstand an attack both from inside or outside. This system weakness allows actors to gain unauthorized access to the system for (i.) espionage, (ii.) damage, (iii.) sabotage, or (iv.) misusage. During the security risk assessment, the severity (impact) of possible vulnerabilities are determined and defined.
The security risk assessment distinguishes between different types of security vulnerabilities, as listed in Table 3. This cybersecurity analysis task requires a good knowledge of possible risks and actual vulnerabilities for the individual system type. A list of possible risks and vulnerabilities examples, prepared and maintained by cybersecurity experts, will be a good support to perform the task. Recommended sources of such lists are collected in Table 4; most of them are accessible on the Internet.

Process Flow Step Description
NVD-NIST I-CAT vulnerability database [11] The National Vulnerability Database (NVD) is the U.S. government repository of standards-based vulnerability management data Link: https://nvd.nist.gov/, accessed on 10 June 2021 SANS CIS [12] The CIS Critical Security Controls recommends cyber defense measures Link: https://www.sans.org/critical-security-controls/, accessed on 10 June 2021 OWASP Top 10 [13] The Open Web Application Security Project ® (OWASP) provides recommendations to improve software security. Link: https://owasp.org/www-project-proactive-controls/, accessed on 10 June 2021 NIST I-CAT [14] Vulnerability database of the National Institute of Standards and Technology (NIST) Link: https://nvd.nist.gov/general, accessed on 10 June 2021 The identified vulnerabilities must be documented in the cybersecurity assessment documentation. This expresses the detected weak points of the system architecture and represents the security analysis focus during the assessment process.

Security Aspect-Security Threats
During the high-level cybersecurity risk analysis, possible system threats are identified in contrast to operation environment and system architecture.
Definition of system threats: A threat is the danger that system security can be reduced by exploiting a system vulnerability to produce system harm and system damage.

Threat Explanation
Computer virus, malware A computer virus will change the OS or other parts of operating software (malicious function). This can lead to improper system operation or system damage. Computer viruses affect system security and count as malware. Rogue security software This type of software mimics the presence of a computer virus to lead the user to pay money for virus removal software.
Trojan horse A "Trojan horse" refers to tricking someone into inviting an attacker into a securely protected area.
Adware and spyware Adware will track data from the computer use to get information of the user. In the most cases, adware is added to the computer by downloading software in consensus with the user. Spyware is added to the computer without consent or knowledge of the user. This can happen by malicious downloads from unsecure domains.

Ransomware
Ransomware is a type of malware which encrypts the user data to blackmail the user into paying money.

Computer worm
A computer worm is a malicious program with the ability to replicate itself once it is run. The more and more powerful microcontroller performances used in the field and edge domain are rewarding targets for computer worms.

DoS and DDoS attack
These threat variants summarize network attacks to overload network resources to reduce operability: Denial of Service (DoS): attack from one computer to overload a target device by flooding this device with request packages in a high frequency. DDoS same as DoS, but the attack is performed by a synchronized cluster of computers. These clusters of computers and the high computing power are provided by manipulated kidnapped computers.

Phishing
This threat type obtains other people's personal data (e.g., password, credit card data) by using fake emails or websites.

Rootkit
A rootkit is a collection of software tools that are installed on the compromised system after breaking into a software system to prepare it for future undetectable access and to hide processes and files.

SQL injection attack
A vulnerability of SQL data bases, where an unauthorized person performs data and control manipulations in the case of weak access authentication and weak access checks and monitoring.

Man-in-themiddle attacks
This attack eavesdrops on the communication between two targets and may be used for several purposes: After the identification of possible system relevant security vulnerabilities and the possible cybersecurity threats, a combination of different attack potential factors will be determined to define the minimal necessary SL-T. The SL defines the rigor of the requirements and defines how robust the system is against attacks.
The following attack potential factors (Tables 6-11) are combined to define the security compromise level, which determines the minimal necessary SC-T. These are:

Motivation (MO)
The motivation factor states that an attack occurs coincidental by less motivation or is planned with a high successful result target.
Question: what level of motivation must be assumed for an attack to be carried out?

Elapsed Time (ET)
The amount of time required for an attacker to identify a specific potential vulnerability, develop an attack method, and maintain the effort required to perform the attack on the target. This factor states that the faster an attacker finds a vulnerability, the lower the protection is.
Question: how much time is required to get access to the system? Table 7. Attack potential factor: elapsed time.

Months 1
The attack needs lots of time for preparation.
The system provides a high protection level. Weeks 2 Days 4 Hours 8 No or little time is necessary to get access to the system. The system provides a low protection level.

Expertise/Skills (ES)
Knowledge of the underlying principles or methods of a suitable attack. Question: which expertise or skills does the attacker have?

Access (AC)
Access level of the target needed to carry out the attack. Question: which access restrictions does the target system offer?

Equipment (EQ)
Knowledge and equipment to identify or exploit the vulnerability to prepare an attack. Question: which tools does the attacker have to perform the attack? The sum of all attack potential values (AP value) gives a first cybersecurity assessment value which is used to determine the related SL, according to the IEC 62443 standard. In this assessment, the value ranges from 6-48. Table 12 gives the definition of the necessary protection and espionage requirements.
Attack Potential value overview  AP sum = 13…18 Protection against intentional violation using simple means, low resources, generic skills, and low motivation. Espionage: prevent the unauthorized disclosure of information to an entity actively searching for it using simple means with low resources, generic skills, and low motivation. AP sum = 19…24 Protection against intentional violation using sophisticated means, moderate resources, AACS specific skills, and moderate motivation. Espionage: prevent the unauthorized disclosure of information to an entity actively searching for it using sophisticated means with moderate resources, AACS specific skills, and moderate motivation. AP sum = 26…48 Protection against intentional violation using sophisticated means with extended resources, system specific skills, and high motivation. Espionage: prevent the unauthorized disclosure of information to an entity actively searching for it using sophisticated means with extended resources, AACS specific skills, and high motivation.
In a next step, the resulting AP value will be combined with the probability or likelihood that the attack will occur, which determines the severity of the attack risk.

Probability/Likelihood (PL)
The probability or likelihood value, which expresses if the attack occurs, is a further significant risk assessment factor for the security assessment process. Table 13 shows an example for a risk likelihood scale.
Questions: during which interval will an attack event occur?

Range Value Description
Very high 11...12 Most likely to occur e.g., event occurred or is expected to occur within one to four months High 9…10 Likely to occur e.g., event occurred or is expected to occur within 1 year Moderate 6…8 Quite possible/not unusual e.g., event occurred or is expected to occur within 1 to 5 years Low 3…5 Unusual/possible e.g., event occurred or is expected to occur within 5 to 10 years Very Low 0…2 Conceivably possible but very unlikely to occur, e.g., event could occur at some time greater than 10 years

Severity Level
The severity level defines the impact of a successfully performed attack on the system. Table 14 gives an example of a severity scaling. Questions: how serious is a successful attack on the system function? Finally, the security risk matrix compares the risk severity with the attack probability/likelihood of an attack (as illustrated in Table 15).
Questions: how serious is a successful attack on the system function?
The table value is the product of the severity and the probability value.
The risk value is the product of the severity multiplied with the probability/likelihood. * (1) The AP value range 1-6 defines the tolerable risk, the risk where theoretically no protection is necessary. In this case, it is defined as the SL-0.
As already mentioned in Table 2, IEC 62443 defines five SLs, from SL-0 to SL-4, for different attack strengths and different protection requirements definitions.
In the high-level cybersecurity risk assessment phase, the resulting SL-T is defined. SL-T states the necessary SL to protect the underlaying SuC in a proper way.
To distribute the five SLs, SL-0 to SL-4, over the given attack potential range (AP values 0...48 from Table 12), the IEC 62443 standard defines the Cyber Risk Reduction Factor (CRRF) to support the mapping of the AP values to the SL values. (2) The factor 6 denotes the value of the maximal tolerable risk (see the appointed green areas in Table 16). In this cybersecurity assessment example, 15 threats (as illustrated in Figures 5 and  6) are selected for the high-level risk analysis. In a real application, many more threats are dealt with, but here, only the process flow is shown, using examples with a reduced number.
Gives an overview of 15 selected threat assessments according to the security aspects (A), (B), (C), and (D). The assessment ratings are drawn up in a voting round by security experts with appropriate experience. The sum of the assessment ratings of each threat defines the necessary SL (as illustrated in Table 2). The implementation and realization of the relevant security requirements enable the system to withstand cyberattacks in the estimated strength. The relevant security requirements are defined in IEC 62443 in seven requirements groups.
According to the results from the high-level cybersecurity assessment, the SL in the AFarCloud example is determined as SL-T = 2.

Impact Value
After the estimation of the SL, the severity and impact of an attack are quantified in the next step.
Tables 17-20 define the impact values for system safety, the financial situation, the operational behavior, and the system/components' effects in case a cybersecurity attack takes place. Table 21 lists the impact level ranges.

Destruction/ Catastrophic
Financial damages threatening existence and/or the incident will lead to legal proceedings against the company; a serious impact on the public image (reputation) of the company 1000 3 Severe/ Critical Significant financial damages, but which do not threaten existence, and/or the incident can have a serious impact on the public image (reputation) of the company 100 2

Damage/ Medium
Unwanted financial damage and/or the incident may have an impact on the public image (reputation) of the company 10 1

Safe/ Insignificant
No financial or intolerable damage 0

Destruction/ Catastrophic
A strong impairment leads to a total failure of the system/function with a possible destruction of the system.

Severe/ Critical
A strong impairment leads to a significant disturbing of the system/function operation with a partly possible destruction of the system.

2 Damage/ Medium
A system/function damage is detectable but will not influence the system/function operation. A low reduction of the system/function performance is noticeable.  To reduce the impact, a change of the system architecture can be adequate. As an example, reducing the number of external communication interfaces into the system or reducing the number of communication protocols used helps to strengthen the system against attacks. According to the risk matrix, all medium, critical, and catastrophic effects must be avoided by adding suitable cybersecurity measures, since the risk is unacceptable regardless of the probability value.
The following values were estimated for the example sub-SuC (as illustrated in Figure 7). In this example, the impact analysis indicated "Damage/Medium" impact levels. At the end of the "High level cybersecurity risk analysis" process step, the SL-T is defined. For the AFarCloud example, it is level 2 (SL-T = 2), and the impact level is set to "Damage/Medium". Cybersecurity risks are evident. It is strongly recommended to take appropriate security measures.
In the next process step, the SuC is prepared for a detailed cybersecurity analysis. For this task, the SuC is split in zones and conduits.

Process Step: Split In Zones And Conduits
IEC 62443 defines security zones as "groups of physical or logical assets that share common security requirements, which have clearly defined borders (physical or logical)". The zones are connected by so called conduits. A conduit includes necessary security measures to: (a) control the access to the conduit; (b) resist denial of service attacks; and, (c) prevent the spreading of any type of attacks. The conduit works as a shield for the succeeding zone and protects the integrity and confidentiality of communications.
Each zone implies an objective SL, derived from the SL-T. After a security analysis, the components of the zones and conduits must offer a SL-C. The SL-C must be equal or higher than the SL-T. If it is less, the detected security gap must be compensated for by including additional security measures. These improvements of the zones and the conduits are done until no security gap remains after the detailed cybersecurity risk analysis.
As shown in Figure 8, IEC 62443 gives hints on how to compensate the gap with extending the cybersecurity measures requirements. A conduit can be improved with appropriate security measures (e.g., a firewall), the SL-T of the subsequent zones, even when the SL-C of the desired zone has a lower value. In the above example, the farm zone is embedded by the conduits on the left and right side, which provide the SL-C with level 2. But this zone embedding must be performed with care because in a future zone extension, additional communication links are added (for example, by connecting unsecure wireless communication devices to the zone), and thus, a security weak point can be opened. Generally, it is always better to secure the system with a high level of security. The zone embedding can be usefully and appropriate in a SL-4 system to enable the use of components with a more or less SL or, on the other hand, this method can be used to protect old legacy systems, where an improvement or exchange of the existing devices will be not feasibly.   There are four zones with different security criticalities defined according to different threat types. The zones are aligned with the areas of the system architecture and are interconnected by four data communication links with different communication protocols. A first approach to improve the security is to reduce the number of data communication links (conduits), but in this case it will not be possible. Table 22 summaries the designations and abbreviations of the zones and conduits.

Process Step: Detailed Cyber Risk Analysis
Each zone and conduit are subject to a detailed analysis of the fulfilment of specified requirements given by the cybersecurity standard IEC 62443.
These requirements are grouped in seven foundational requirements, as listed in Table 23. Restrict use of the system or assets according to specified privileges to protect against circumvention by entities using simple means.  Mapping of roles in the management process requirements  System use policy requirements  12 system requirements/12 requirement enhancements FR 3: System Integrity (SI) Protect the integrity of information in the system against manipulation by someone using simple means.  Session handling, cryptography, recognize changes requirements  9 system requirements/10 requirement enhancements FR 4: Data Confidentiality (DC) Prevent the dissemination of information to an entity actively searching for it using simple means.  Encryption requirements  End to end data encryption requirements  3 system requirements/3 requirement enhancements Prevent the intended circumvention of zone and conduit segmentation systems by entities using simple means.  Less connectivity requirements  Network segmentation requirements  4 system requirements/7 requirement enhancements FR 6: Timely Response to Events (TRE) Monitor the operation of the system and respond to incidents when they are discovered by actively collecting forensic evidence from the system  Event/Action Logging requirements  Monitoring requirements  Anomaly/Inconstancy detection requirements  2 system requirements/1 requirement enhancements FR 7: Resource Availability (RA) Ensure that the system operates reliably under normal and abnormal production conditions and prevents denial-of-service situations by entities using simple means.  System backup requirements  System recovery requirements  8 system requirements/5 requirement enhancements Each foundational requirement group consists of additional subrequirements. There are more than 50 system requirements with additional requirement enhancements defined by the IEC 62443 standard. The higher the SL, the more requirement enhancements are defined and must be implemented to satisfy the dedicated SL. Each system requirement must be fulfilled by the defined zones and the conduits of the SuC. A detailed security analysis is a very time-consuming task, especially for large systems. Figure 10 gives a graphical overview of the numerous system requirements grouped around the foundational requirements. Moreover, it can also be used for a quick and clear PASSED/FAILED status display of a system element. For PASSED the appropriate cell is in green, for FAILED it is in red.

Process Decision: Tolerable Risk Estimation
There are four SLs defined to classify risks, as shown in Table 2. The tolerable risk is expressed with the SL-T. Additionally, there are two further SL types defined, to document the result of the security assessment process. The SL types are explained in more detail in the following.

Cyber SL Types
To obtain a comparable result for the assessment, three types of SL are defined, which document the "Target", "Capability", and "Archived" levels (Source: IEC 62443-3-2):  Security Level Target (SL-T) is the desired level of security for the identified SuC, usually determined by a risk assessment with the goal of identifying which security protection is needed to ensure correct system operation. This level is determined in the "high level cybersecurity risk analysis" phase of the cybersecurity assessment process.  Security Level Achieved (SL-A) is the actual level of security for the SuC, which can be measured after the system concept and design are available. The purpose is to verify that the SL-A is identical to or higher than the SL-T.  Security Level Capability (SL-C) is the presentation of the provided SLs by all system components when properly configured and integrated. SL-C expresses the need of cybersecurity improvements with additional compensating countermeasures to achieve the determined SL-T when SL-C < SL-T.
The SL-T to SL-A relationships can be figured out in graphical representations, as shown in Figures 11 and 12. These are two examples that express the relationship between two SL types in a fast and meaningful way to document the system security status.  The diagrams show briefly whether the expected target SL-T was met or whether additional improvements are necessary.

Process
Step: Documentation, Requirements Fixing, Recommentations 2.9.1. Documentation A cybersecurity certification needs good and complete cybersecurity assessment documentation. Some of the necessary documents are already created in the previous process steps. Finally, the following documents close the cybersecurity assessment documentation work: listing of all system relevant requirements (depending on the appointed SL), definition of test cases, test result documentation to verify the correct and complete requirements integration, list of necessary security countermeasures, and security recommendations which must be implemented.

Requirements
As an example, in the following paragraph an excerpt of three requirements definitions from the FR1 (Access Control AC) requirement group is shown. Note that the line "belongs to the zones/conduits" defines for which system elements the requirement is specified. The vulnerability was identified in the "high level cybersecurity risk analysis" phase.  (FR1-AC): The system shall provide functions to uniquely identify and authenticate all users, restricting access for unauthorized people.
Vulnerability A system interface without user identification and authentication allows unrestricted access by anyone and from anywhere.

Countermeasure
Use at least a single-factor authentication mechanism with username and password.

System
The This requirement states that only a certain form of password must be used, and this must be checked.  (FR1-AC): The number of failed login attempts in a time period (e.g., 24 h) shall be limited to 3 tries.

Vulnerability
The attacker guesses the password with a brute force attack. Countermeasure Using a login attempt statistic counter.

System
After three wrong authentication attempts, the system should prohibit further inputs for a time of 24 h. Belongs to the zones/conduits This requirement defines the use of a login attempt counter to prevent trying to guess the password.
An important part of the requirements definition work is also to design adequate and executable test cases to verify the requirements implementation. This part is often done as the last work in the full process life cycle, but this requires much additional time and must be prepared very carefully. The effort required is easily underestimated but note that these tests must be repeated in the event of a system change. Then, an existing and well-prepared test environment does the job with one mouse-click. Also, the cybersecurity reassessment for recertification is done quickly.

Recommendations
Finally, a few additional suggestions for the security implementation should be made.  Network segmentations Isolate the business IT components from the privately used IT environment by using routers with activated firewalls.  Using a business and a private cellular phone Consider using a separate business cellular phone with carefully selected and necessary business relevant apps only. This also protects your business partners if the private mobile phone has been spied on and compromised by an app.  Zero trust Zero trust (ZT) defines a paradigm shift. Up to now, cybersecurity protection was done with a "perimeter-based" approach, where the protection was ensured to the company boundaries by applying network segmentation, intrusion detection, restricted network access, and so on. ZT is a purely "data-centric" security approach. Following the security principle "Do not trust anyone, verify everyone", the principle of ZT follows the granular approach of checking each individual data flow for trustworthiness. As an example: the MQTT (Message Queuing Telemetry Transport) protocol requires data encryption with an asymmetrical keys and certificates and the transmission of user credentials for each data message. This gives this data transmission protocol a high level of data integrity and data security.  Demilitarized Zone Another way to improve the local IT security is to define a so-called demilitarized zone (DMZ). The DMZ is isolated from the Internet (WAN) by a firewall and from the company internal network (Intranet, LAN) by an additional firewall. This isolation from both WAN and LAN provides a high level of protection and complete control over who can access the DMZ. As a result, a single vulnerability does not immediately compromise the DMZ. Ideally, the two firewalls are from different sources, since otherwise a single known vulnerability would be sufficient to overcome both firewalls.

Results
In the future, for modern agriculture, new types of IT tasks and new technology challenges await the farm company management and staff.
One significant challenge will be the responsibility for security measures. Refer to the agriculture architecture in Figure 1; for Levels 1 and 2, the asset owner has full control over the installed security measures to harden the system against cybersecurity attacks. For Levels 3 and 4, the asset owner can only perform an accurate provider selection and must trust that the defined security specifications are fulfilled.
The asset owner has no influence over the security conditions of the services; he can only request security certificates and must trust the service provider with compliance with the duty of caution. Unfortunately, from time-to-time, one hears about cyberattacks against service providers in which private customer data was stolen.
A further point of discussion in security and privacy are the questions of where data are stored by global active service providers operating remotely located, cloud-based data repositories and service farms.
Continuous security monitoring is the only measure the asset owner can perform to increase confidence. This is a requirement that is feasible and may be performed by large and medium-sized farm companies. If small farm companies are not able to perform security assessments by themselves, they need support and consultation from their professional associations to reach a level of security and privacy so that the company can work trouble-free. The external security service provider can support their customers with actual cybersecurity threats and appropriate security measures. Today, it is not feasible for small and maybe some medium-size farm companies to manage the necessary security monitoring in an increasingly digitalized agriculture world. Further research and adapted business structures must be developed to support and ensure secure operation.
Another significant challenge is the big difference between IACSs, as illustrated in Figure 3, and the agriculture architecture, illustrated in Figure 1. In an IACS environment, in the most cases, field components at level 1 are housed inside the factory buildings and are basically well-protected against direct physical access attacks. Malfunctions and manipulation can only be carried out if one breaks into the building to gain access, but that already shows high motivation and criminal intent. Also, direct supervision is easy installable in a factory building; however, in the agriculture domain, according to Figure 1, the field elements are mostly far away from the farm building, and the components are more vulnerable to manipulation, destruction, and risk of theft. Due to networking and widely distributed production facilities in modern agriculture environments, especially for Layer 1 and Layer 2, new points of attack were added, which make it easier for attackers to penetrate the production facility, manipulate it, and even impair machine safety.
Nowadays, employees who are not IT experts also have to deal with potential security threats. Therefore, it is necessary to carry out a comprehensive security risk assessment of the entire system, both from IT and from OT, to ensure an adequate SL.

Study Results
The above results mean that the components in Layer 1 and Layer 2 need additional protective measures. In the AFarCloud project, a conceptual prototype of an improved soil sensor protection concept is demonstrated to show solutions that manipulations are detected immediately, and the theft of field components is made pointless when they are not reusable outside of a defined area by a non-resettable protection measure.
The conceptual prototype, named SED (Security Evaluation Demonstrator) [24], is built around a standard soil sensor, which utilizes Long Range Wide Area Network (Lo-RaWAN) communication technology to transfer the field data wireless to a data gateway. From here the data are transported via an Internet connection by using the Message Queuing Telemetry Transport (MQTT) network protocol via the cloud-based AFarCloud Middleware (MW) to the cloud data repository. Figure 4 shows the block diagram of the SED, which was built with real hardware to verify the implemented security improvements. If LoRaWAN and MQTT already bring a lot of data security features, the sensor has been upgraded with a Hardware Secure Module (HSM) and additional monitoring sensors, like GPS, which detects unauthorized movements of the device. The HSE is a non-manipulatable cryptographic device which manages cryptographic key storage and protects the sensor firmware. Figure 13 shows the SED sensor hardware without the case; such a sensor represents the most vulnerable part of an outdoor field device.
The SED prototype is based on a Raspberry-Pi single-board computer with an attached LoRa shield, which also carries the GPS receiver. The HSM is plugged into the expansion bus. In a commercial sensor all components are embedded on a single electronic board, ideally all integrated on a semiconductor chip. The environmental sensors (temperature, humidity, etc.) are also connected to the expansion bus. Each detected manipulation or irregular operation generates an alarm or a notification messages, which informs immediately selected users.
The verification results of the above listed security functions are descripted in detail in the [25].
Finally, all employees must be adequately trained in security issues when they operate with field elements which need security authentication for installation and maintenance.

Discussion
The following questions need to be discussed, and answers can be found by further research. Additional threat analysis work is necessary to identify existing and new vulnerabilities in agriculture.
What are the special vulnerabilities and cyber threats in agriculture that are not known and covered in this form by the IACS domain experience? The answer to this question defines (a) the need of a totally new cybersecurity standard for agriculture or (b) indicates that adaptions and extensions of already well-known cybersecurity standards will be sufficient. From our point of view, a dedicated cybersecurity standard for agriculture will be necessary, because of the totally different security conditions on the field segment and the farm segment in comparison to that of the security situation, provided by a well observable plant building.
The future problem is not the theft of a single field device and its subsequent manipulation for cybercriminal activities. Much more, there will be many IoT devices in the field in future installations which offer an attractive base for botnets. Because even the simplest sensor will contain a powerful processor with its own OS and extensive additional functions, these field IoT devices will require periodic software updates, which can be carried out using Over-the-Air (OTA) programming techniques.
Using Single Sign-On (SSO), Multi-Factor Authentication (MFA), and access broker structures to hide the real data storage location. An access broker reduces the attack surface to a very restricted system access port. A well-established approach of such a data access philosophy is provided by the MQTT protocol, which supports a publish-subscribe network protocol. The data exchange is only possible via an access broker, which authorizes the data traffic and monitors the data flow (intrusion detection).

Conclusions
After two years of project work and research in the field of cybersecurity for agriculture, the following insights were gained: nowadays, standardization in agriculture contains only a few standards and regulations to control the use of pesticides, to secure the use of heavy machinery without damage and injuries, and to require animal-friendly treatment of farm livestock.
One thing we learned from the first two years of the project is that the safety standards for agriculture mainly concern the area of food and nutrition safety, but so far, no specific IT/OT safety standards were defined for the agriculture specific architecture. In the Industrial Automation Control System (IACS) and in the automotive domain, there are cybersecurity standards that guide the system responsible to provide a safe operating condition. Some of these regulations can be applied (transferred) directly to agricultural electronic systems. In the communication area, there are some ETSI standards from the area of Machine-to-Machine (M2M) communication with expansions for interaction with agricultural machines, such as the ISOBUS [26].
There is a need to define cybersecurity guidelines for modern agriculture (Agriculture 4.0) in the European Union (EU), like those developed for industrial control systems. In the USA, the United States Department of Homeland Security (DHS) [27] carried out research during the last years to identify potential cybersecurity vulnerabilities for agriculture; in Europe, however, no similar investigation occurred. The document "European Cybersecurity Centres of Expertise Map-Definitions and Taxonomy" [28], focuses on many industries to show the risks and the need of monitoring support to ensure cybersecurity, but the modern agriculture domain is not included. Even in the EU publication entitled "Study on risk management in EU agriculture" [29], from Q4 2017, smart farming and cybersecurity are not mentioned.

Outlook
The work for cybersecurity in agriculture will continue in the last year of the project with a focus on a Security Evaluation Demonstrator (SED) to show the different security vulnerabilities and adequate improvements, achieved in both hardware and software, to demonstrate the security concept on a simple sensor node. The implementation examples avoid most cybersecurity vulnerabilities and provide a fast-responding sensor manipulation monitoring system.
A new proposal (NP) or a preliminary work item (PWI) is planned to start an initiative for a future agriculture cybersecurity standard.
Finally, the research results, cybersecurity assessment and analysis methodologies, requirements, and security recommendations will be collected in a publication, such as this one, which could be a useful cybersecurity guide for the agriculture domain.  Institutional Review Board Statement: Not applicable.