## 3 Methodology
### Implementation
Secondly, the ontology readily accommodates the addition of new knowledge, thereby enhancing the adaptability of our cybersecurity framework to new attacks and defenses, albeit at the expense of an ontology reasoner being more computational intensive than a lightweight rule engine. Additionally, the ontology reasoner can also be used to explain certain inferences, such as depicted in Figure 4 with the Protege tool for the Manchester OWL query in Figure 5.

The ability to explain inferences offers transparency about how query results are derived from the underlying knowledge base. Security analysts can gain a deeper understanding of the relationships and dependencies among different entities and concepts within the adversarial ML domain. By explaining inferences, they can gain insights into the hidden or inferred relationships, helping them discover new knowledge without explicitly encoding it in the ontology. Also, when inconsistencies or unexpected inferences arise, the analysts can use the ontology reasoner to diagnose and trace the root cause of the issues. This helps in identifying and rectifying errors in the ontology or refining the knowledge representation. ### Quantitative Evaluation: Performance

The backbone of our ontology-based cybersecurity framework is powered by an OWL 2 reasoner. Therefore, the careful selection of an optimal implementation of such a reasoner is paramount. We initially selected the HermiT ontology reasoner because of its strong compliance with the OWL 2 DL (description logic) specification and its efficient reasoning capabilities [28]. Additionally, the Protege tool comes with HermiT pre-installed. Figure 4: Explaining the results of Manchester OWL queries. Figure 5: DL query examples in Manchester OWL syntax. The outputs are individuals that can be subsequently queried for more details. Our objective is to achieve a query response time below 3 s, deemed reasonable from a usability perspective. We then carried out performance assessments of our REST-based framework, deploying all components on a single system to minimize the impact of network latencies that would otherwise arise when submitting queries and retrieving the results. #### 4.2.1 Experimental Setup

With a basic shell script that invokes the _curl_ command line utility, we orchestrated the execution of 100 REST requests within distinct query categories against our framework, subsequently assessing the corresponding response times. The queries were systematically categorized into three complexity tiers, determined by query length and depth. Presented below are examples representing each complexity category of queries:

* **Simple queries**: class instances or property restrictions
* (breaks_mitigation **value*
* (breaks_mitigation **some*
* **Normal queries**: nested property restrictions
* (extends **some*
* (name **value*
* \"Adversarial Input Detection\"))
* (breaks_mitigation **some*
* (breaks_attack **some*
* (breaks_mitigation **value*
* **Complex queries**: multi-nested property restrictions and conjunctions
* ((extends **some*
* (external_references **some*
* (external_id **value*
* \"AML.T0015\"))) **and*
* (breaks_mitigation **value*
* (breaks_mitigation **some*
* (breaks_attack **some*
* (breaks_mitigation **some*
* (breaks_attack **some*
* ((extends **some*
* (name **value*
* \"Evade ML Model\")) **and*
* (has_threatmodel **value*
* perfect_knowledge_adversary) **and*
* (uses_dataset **value*

We will carry out two types of experiments, the first one without including the extensive MITRE ATT&CK (version 14.1) Enterprise knowledge base. As a result, if a query filters instances of the class _Technique_, it will not process those covered by the ATT&CK Enterprise knowledge base, only those covered by the ATLAS knowledge base. In the second experiment, we will include the ATT&CK Enterprise data, expecting that this will increase memory usage, computational complexity, as well the query response times.