## 2 Materials and Methods
### Security Requirements According to ISO/IEC62443
#### 2.3.2 Zones and Conduits Concept  
The IEC 62443 security standard emphasizes performing a security analysis of a manufacturing facility. The facility is broken up into sections that have been given the name \"security zones\" [20]. In addition, data flows among connected security zones are suggested in the standard via another type of zones for communication channels; these channels are called conduits [16]. The standard outlines the zones and conduit requirements, abbreviated as ZCRs, for the system under consideration. The SuC entails defining a collection of IACS together with any assets associated with it in order to conduct a risk analysis. IEC 62443 describes the procedures to be followed in order to set up zones and conduits, and their connections to ZCRs [14; 21]. According to the IEC 62443-3-2 [21], the ZCRs are described as follows:  
* **ZCR1--identification of the SuC:** An identification of the system under consideration (SuC) shall include a specified description of the security limits and an identification of all access points to the SuC. * **ZCR2--high-level risk assessment:*
* In order to detect unmitigated risks, a high-level risk assessment of SuC is carried out. This clarifies the worst-case scenario that SuC presents. The assessment assists in the grouping of assets in distinct zones and conduits. High-level risk can be quantified using a risk matrix to define the relationship between the likelihood and the impact values. There are five different levels of parameter values for the likelihood and impact values. In the following, the the likelihood levels are listed:
* **Level 1**: Trivial
* **Level 2**: Minor
* **Level 3**: Moderate
* **Level 4**: Major
* **Level 5**: Critical The next listing shows the possible impact values:
* **Level 1**: Remote
* **Level 2**: Unlikely
* **Level 3**: Possible
* **Level 4**: Likely
* **Level 5**: Certain
* **ZCR 3--Partition the SuC into zones and conduits:** This phase splits up the complex overall system into separate zones and conduits. Figure 2 illustrates an example of splitting the system into distinct zones and a conduit. Figure 2 illustrates components connected wirelessly to provide a particular function. Two security zones are defined to represent a security boundary containing all components that must be protected from multiple cyberattacks. The management security zone represents a system boundary with a set of common security properties to protect monitoring and storage devices, such as cloud servers and computer. The second security zone describes an aggregation of field components, such as actuators and electronic control units (ECU), that need to be protected. Between these two zones, all communication challenges are defined as a part of a conduit that securely creates a protected medium for data transmission. * **ZCR 4--document cyber security requirements, assumptions and constraints:** This is the last phase to assess the cyber risk for each zone and conduit to individually evaluate target security levels [22]. Figure 2: Example of SuC partitioning in zones and a conduit. In the course of our research, we investigated the utilization of the IEC 62443 security standard in terms of guidance for protecting a system model from multiple forms of cyberattacks. The ontology approach was proposed before as one of the most effective solutions for building complete tractability between potential threats (i.e., security issues) and security-related requirements (i.e., security solutions driven by standardization). [PERSON] [14] introduced an ontology-based cybersecurity framework that is capable of automating the tracking of threats and related security attributes until the main security objective and its associated security requirements can be specified. In order to address existing security issues, the framework derives a set of security requirements for handling identified potential cyber threats to protect system components/assets. It builds relationships between various entities in the hierarchical ontology model.