# Sustainable Risk Identification Using Formal Ontologies +
## 4 Discussion
We chose to adhere to the standard implementation to demonstrate the feasibility and practicality of OnToRisk. Ideally, however, the risk identification implementation can be easily improved when developing an ontology-based application or information system by using a proprietary mechanism to yield new individuals. Such individuals can be derived formally as the tuple (vulnerability, impacted element, attack surface), i.e. :  
\[ \begin{array}{l}(v,i,a)\equiv\{(v,i,a)|\\ (\
i v\in V\ \&\
i i\in BF\ \&\
i a\in A\ \&\ (a,i)\in SF\ \&\ (v,i)\in\ RF\ \&\ (v,\ a)\in RV)\ or\\ (\
i v\in V\ \&\
i i\in SI\ \&\
i a\in A\ \&\ (a,i)\in AI\ \&\ (v,i)\in\ RI\ \&\ (v,\ a)\in RV)\}\end{array}  \tag{7}\]  
with:  
\(V\)--the set of Vulnerability class (i.e., concept) instantiations  
\(BF\)--the set of Business Function class instantiations  
\(A\)--the set of Application class instantiations  
\(SF\)--the set of supportsFunction object properties instantiations  
\(RF\)--the set of risksFunction object properties instantiations  
\(SI\)--the set of Sensitive Information class instantiations  
\(AI\)--the set of accessInfo object properties instantiations  
\(RI\)--the set of risksInfo object properties instantiations  
\(RV\)--the set of risksVia object properties instantiations  
OnToRisk currently provides the identification of potential risks. Identified risks should be further analysed. In the case study implementation, for example, an application marked as susceptible to a vulnerability due to the identity of one of its components may not present an actual risk, e.g., in a case where an application uses the component in a version which is not susceptible to the vulnerability or if the context of use or security controls prevent the exploitation of the disclosed vulnerability. Future research can establish the use of other ontology elements, such as data properties--in addition to classes and object properties--for improving the risk identification and its automation. Expanding the ontology with additional elements may also contribute to the prioritisation of risks (e.g., by introducing impact levels) and to the inclusion of additional CTI information. With OnToRisk currently validated for the specific case study of a vulnerability-induced risk, additional research can utilise the method to identify other types of cybersecurity risks, such as those emerging from a compromised supply chain or from existence of Common Weaknesses Enumeration (CWE) in applications and application development. Whereas a previous method by [PERSON] et al. employs automated risk identification for improving engineering artifacts [30], OnToRisk provides automated risk identification for better organisational situational awareness. OnToRisk provides a more concrete view of business consequences, compared with the high-level consequence categories of the engineering-focused method proposed by [PERSON] et al. OnToRisk relies on continuous integration of information within operational context, as opposed to initiated engineering design verification, which is the domain of the method by [PERSON] et al. Both methods share a formal ontology approach as well as the goal of relieving personnel from tedious risk identification so that it can concentrate on other aspects of risk management. Therefore, future research may seek to integrate the two methods and deliver an ontology-based risk identification method for the full system lifecycle.