**Abbreviations**

The following abbreviations are used in this manuscript:


#### **Appendix A. Applicability in the Context of ISA/IEC 62443**

In this section, the potential application of the proposed EDG model to the existing security standards is described. The proposed EDG model can be used isolated by itself, or in combination with other techniques that complement the analysis. In this sense, the EDG model can be used to enhance some tasks in the security evolution processes defined by security standards.

The ISA/IEC 62443-4-1 standard specifies 47 process requirements for the secure development of products used in industrial automation and control systems [49]. Thus, the EDG model was developed to enhance the execution of one of those requirements defined by the standard: the "SVV-3: Vulnerability testing" requirement, serving as a support for the execution of Practice 5—Security Verification and Validation testing. According to the SVV-3 requirement, both known and unknown vulnerability analysis has to be performed. The EDG model proposed in this research work is intended to support the identification of known vulnerabilities, their dependencies, and the possible consequences of their propagation, yielding the opportunity to analyze them systematically. Nevertheless, more requirements of the ISA/IEC 62443 can be mapped to one or more of the metrics defined in this research work. Using this relationship, it is possible to apply the EDG model to enhance the analysis and review of the following requirements:

### *Appendix A.1. Security Requirements—2: Threat Model (SR-2)*

"A process shall be employed to ensure that all products have a threat model specific to the current development scope of the product. The threat model shall be reviewed and verified periodically" [49]. The proposed EDG model can serve as an abstraction of the threat model that has to be obtained. Moreover, the standard states that this threat model has to be reviewed periodically for updates. Given that the EDG of a given SUT evolves with every update, the threat model would be always up-to-date. Potential threats and their severity using the CVSS can also be analyzed with this proposal. Finally, these results can be used to enhance the risk assessment of the SUT.

### *Appendix A.2. Security Management—13: Continuous Improvement (SM-13)*

"A process shall be employed for continuously improving the secure development life cycle" [49]. The EDG model can be used to identify recurrent issues in the development of an industrial component, due to its ability to track the state of a SUT over time. Consider the scenario where a piece of code contains an unknown vulnerability. For example, this code can implement a communication protocol or the generation of a cryptographic key.

If this piece of code is recurrently integrated into many types of devices, then when they are released to the market, the end-users can identify that vulnerability and report it to the product supplier. The EDG can reflect the presence of that vulnerability. If an EDG is done for each type of device, then this problem can be detected beforehand. Using the CWE, the root problem can be detected. With this information, new training and corrective actions can be proposed to avoid this issue.

#### *Appendix A.3. Specification of Security Requirements—5: Security Requirements Review (SR-5)*

"A process shall be employed to ensure that security requirements are reviewed, updated, and approved" [49]. As before, taking advantage of the previous scenario, the information extracted from the generated EDG model can be used to propose new requirements or to update the existing requirements.

#### *Appendix A.4. Security Verification and Validation Testing—4: Penetration Testing (SVV-4)*

"A process shall be employed to identify and characterize security-related issues via tests that focus on discovering and exploiting security vulnerabilities in the product" [49]. The EDG model facilitates the identification of possible entry points to the SUT when carrying out a penetration test. In addition, existing attack patterns (CAPEC) and weaknesses (CWE) can serve as a starting point to discover unknown vulnerabilities and exploits.

### *Appendix A.5. Management of Security-Related Issues—3: Assessing Security-Related Issues (DM-3)*

"A process shall be employed for analyzing security-related issues in the product" [49]. When a new vulnerability is detected, end-users will report it to the product suppliers. Then, the corresponding EDG model of that SUT will be updated to reflect that change. This information, in addition to that previously contained in the EDG, can be used to obtain the severity value of the discovered vulnerability using the CVSS. This also facilitates the identification of root causes, related security issues, or the impact.

**Table A1.** Mapping between the developed metrics and the requirements they refer in the ISA/IEC 62443. SR (Security Requirements), SM (Security Management), SVV (Security Validation and Verification), DM (Management of Security-Related Issues).


Finally, the ISA/IEC 62443-4-2 document defines four types of components of an IACS (i.e., software applications, embedded devices, host devices, network devices) [95]. The proposed model is capable of representing the inherent complexity of each of them.

### **Appendix B. EDG for OpenPLC V1**

This appendix contains the generated EDG for OpenPLC V1.

**Figure A1.** EDG for OpenPLC V1. Notice that, for simplicity, CWE and CAPEC values are omitted, and only the CPE identifier of the SUT is shown.

### **Appendix C. Proposed Requirements, Training, and Test Cases**

In this appendix, we show the generated requirements, training, and test cases from the EDG model of OpenPLC V1.

**Table A2.** An example of generated requirements for OpenPLC V1.



**Table A2.** *Cont.*

**Table A3.** Example of proposed training for OpenPLC V1.



**Table A4.** Example of generated test cases for OpenPLC V1.
