D2.10 Certification Graph – v1

Deliverable D2.10 Certification Graph – v1 Editor(s): Verena Geist, Stefan Schöberl Responsible Partner: Software Competenc e Center Hagenber g GmbH Status - Version: Final Date: 31 . 0 1 . 202 5 Type: OTHER Distribution level ( SEN , PU): PU D2.10 – Certification Graph – v1 Version 1.0 – Final. Date: 31.01.2025 © EMERALD Consortium Contract No. GA 101120688 Page 2 of 28 www.emerald-he.eu Project Number: 101120688 Project Title: EMERALD Title of Deliverable: Certification Graph – v1 Due Date of Delivery to the EC : 31 . 01 .202 5 Workpackage responsible for the Deliverable: WP2 – Methodology for Knowledge Extraction Editor(s): Verena Geist, Stefan Schöberl (SCCH) Contributor(s): Angelika Schneider, Florian Wendland , Christian Banse (FHG) Reviewer(s): Angela Fessl (KNOW) Cristina Martínez, Juncal Alonso (TECNALIA) Approved by: All Partners Recommended/mandatory readers: WP2, WP3 Abstract: EMERALD aims to integrate evidence collected at different levels of the cloud service into a single graphbased structure, the Certification Graph. This document describes the interim version of the graph, i.e. its schema (or ontology), with semantically linked and combined evidence. The development mainly involves work of T2.1 and T2.6, but also inputs of T2.2, T2.3, T2.4, T2.5, and T3.1 are considered. Keyword List: Knowledge graph schema, ontology extensions, security features, knowledge integration, combined evidence analysis. Licensing information: This work is licensed under Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0 DEED https://creativecommons.org/licenses/by-sa/4.0/) Disclaimer Funded by the European Union. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union. The European Union cannot be held responsible for them. D2.10 – Certification Graph – v1 Version 1.0 – Final. Date: 31.01.2025 © EMERALD Consortium Contract No. GA 101120688 Page 3 of 28 www.emerald-he.eu Document Description Version Date Modifications Introduced Modification Reason Modified by v0.1 03 . 12 . 20 2 4 First draft version , key information, and TOC. Verena Geist (SCCH) v0.2 05 . 12 .202 4 Executive s ummary, i ntroduction, functional description, requirements fulfilment, technical specifications, licensing information, and download. Verena Geist (SCCH) v0.3 09.12.2024 Recap and changes, architecture, and references. Verena Geist (SCCH) v0.4 08.01.2025 Details on ontology extensions, delivery, and usage Stefan Schöberl (SCCH) v0.5 10.01.2025 Review o f content Angelika Schneider (FHG) v0. 6 13.01.2025 Finalization before internal review Verena Geist (SCCH) Stefan Schöberl (SCCH) v0.7 15.01.2025 Internal Review Angela Fessl (KNOW) v0.8 23.01.2025 Addressing internal review and improving subcomponents description and illustrative example Verena Geist (SCCH) Stefan Schöberl (SCCH) v0.9 27.01.2025 Final reviewed version Cristina Martínez, Juncal Alonso (TECNALIA) v1.0 31.01.2025 Submitted to the European Commission Cristina Martínez, Juncal Alonso (TECNALIA) D2.10 – Certification Graph – v1 Version 1.0 – Final. Date: 31.01.2025 © EMERALD Consortium Contract No. GA 101120688 Page 4 of 28 www.emerald-he.eu Table of contents Terms and abbreviations ............................................................................................................... 6 Executive Summary ....................................................................................................................... 7 1 Introduction ........................................................................................................................... 8 1.1 About this deliverable .................................................................................................... 8 1.2 Document structure ....................................................................................................... 9 2 Recap of the initial draft of the CertGraph ontology and changes ..................................... 10 3 The CertGraph ontology (interim version) .......................................................................... 11 3.1 Functional description ................................................................................................. 11 3.2 Technical description ................................................................................................... 14 3.2.1 Architecture ....................................................................................................... 14 3.2.2 Subcomponents description .............................................................................. 15 3.2.3 Technical specifications ..................................................................................... 21 3.3 Delivery and usage ....................................................................................................... 21 3.3.1 Download .......................................................................................................... 21 3.3.2 Package information .......................................................................................... 22 3.3.3 Instructions for use ............................................................................................ 22 3.3.4 Licensing information ........................................................................................ 22 3.4 Limitations and future work ........................................................................................ 23 4 Refined illustrative example of modelling and combining evidence information for the used TLS Version .................................................................................................................................. 24 5 Conclusions .......................................................................................................................... 26 6 References ........................................................................................................................... 27 List of tables TABLE 1. REQ.01 - FORMAL LANGUAGE.............................................................................................. 11 TABLE 2. REQ.02 - CLEAR CONCEPTUALIZATION ................................................................................... 11 TABLE 3. REQ.03 - HIERARCHICAL STRUCTURE OF CONCEPTS ................................................................. 11 TABLE 4. REQ.04 - REASONING AND CONSISTENCY CHECKING ................................................................ 12 TABLE 5. REQ.05 - INTEROPERABILITY AND EXTENSIBILITY ...................................................................... 12 TABLE 6. REQ.06 - DOCUMENTATION AND ANNOTATION ...................................................................... 12 TABLE 7. REQ.07 - VERSIONING ........................................................................................................ 12 TABLE 8. OVERVIEW AND DESCRIPTION OF PACKAGE STRUCTURE FOR THE CERTGRAPH ONTOLOGY ............... 22 List of figures FIGURE 1. INITIAL DESIGN OF THE CERTGRAPH ONTOLOGY WITH SUB-ONTOLOGIES AND EXTENSIONS FROM D2.1 [1] ........................................................................................................................................ 10 FIGURE 2. EMERALD COMPONENT OVERVIEW DIAGRAM [12] ............................................................... 14 FIGURE 3. UPDATED DESIGN OF THE CERTGRAPH ONTOLOGY .................................................................. 15 FIGURE 4. EXCERPT OF THE EVIDENCE SUB-ONTOLOGY ........................................................................... 16 FIGURE 5. EXCERPT OF THE FRAMEWORK SUB-ONTOLOGY ...................................................................... 16 D2.10 – Certification Graph – v1 Version 1.0 – Final. Date: 31.01.2025 © EMERALD Consortium Contract No. GA 101120688 Page 5 of 28 www.emerald-he.eu FIGURE 6. EXCERPT OF THE FUNCTIONALITY SUB-ONTOLOGY ................................................................... 17 FIGURE 7. EXCERPT OF THE PROPERTIES SUB-ONTOLOGY ........................................................................ 17 FIGURE 8. EXCERPT OF THE SECURITY SUB-ONTOLOGY ........................................................................... 18 FIGURE 9. EXCERPT OF THE CLOUD ONTOLOGY EXTENSION ..................................................................... 19 FIGURE 10. EXCERPT OF THE APPLICATION ONTOLOGY EXTENSION ........................................................... 19 FIGURE 11. EXCERPT OF THE ML ONTOLOGY EXTENSION ........................................................................ 20 FIGURE 12. EXCERPT OF THE DOCUMENT ONTOLOGY EXTENSION ............................................................. 21 FIGURE 13. CLASSES (RECTANGLES) AND INSTANCES (HEXAGONS) FOR THE TLS EXAMPLE, SHOWING EVIDENCE FOUND IN SOURCE CODE (IMPLEMENTED) AND CORRESPONDING EVIDENCE IN A DOCUMENT (SPECIFIED) REGARDING TRANSPORT ENCRYPTION, WHICH CAN BE USED TO VERIFY CRY-02 FROM BSI C5:2020 (ADAPTED FROM [9])................................................................................................................ 24 D2.10 – Certification Graph – v1 Version 1.0 – Final. Date: 31.01.2025 © EMERALD Consortium Contract No. GA 101120688 Page 6 of 28 www.emerald-he.eu Terms and abbreviations AI Artificial Intelligence AI - SEC AI Security Evidence Collector AMOE Assessment and Management of Organizational Evidence BSI Bundesamt für Sicherheit in der Informationstechnik BSI C5 BSI Cloud Computing Compliance Criteria Catalogue CertGraph Certification Graph Codyze Static Code Analyzer EC European Commission eknows Platform for software analysis eknows - e3 Extractor component developed in the context of EMERALD GA Grant Agreement to the project HTTP Hypertext Transfer Protocol ID Identity KR Key Result MEDINA Predecessor project of EMERALD ML Machine Learning NLP Natural Language Processing OTP One - time password OWL Web Ontology Language PDF Portable Document Format Protobuf Protocol Buffers RDF Resource Description Framework RCM Repository of Controls and Metrics SSO Single Sign - On SPARQL SPARQL Protocol And RDF Query Language SWRL Semantic Web Rule Language TLS Transport Layer Security UI User Interface URI Uniform Resource Identifier WP Work Package XML Extensible Markup Language D2.10 – Certification Graph – v1 Version 1.0 – Final. Date: 31.01.2025 © EMERALD Consortium Contract No. GA 101120688 Page 7 of 28 www.emerald-he.eu Executive Summary This deliverable describes the interim version of the central Certification Graph schema (i.e., the CertGraph ontology) for storing evidence in a graph-based format and is the refinement of the initial work on designing the CertGraph ontology in D2.1 [1]. This ontology serves as a common structure for semantically linked and combined evidence that is filled by all evidence extraction components of WP2. By developing the CertGraph ontology, this deliverable contributes to the key result CERTGRAPH (KR2) of the EMERALD project to provide a unified graph-based model of the cloud service under certification at different layers of the service. Following a knowledge graph-based approach in EMERALD, the ontology for storing and linking heterogenous evidence information is developed in WP2, and the model is then implemented as a knowledge graph in WP3. First, this document starts with a recap of the CertGraph ontology from D2.1 [1] and indicates current changes. Second, the main part provides the functional and technical descriptions of the ontology, including its sub-ontologies and extensions to support the holistic approach to evidence collection. Some instructions for delivery and usage as well as current limitations are also presented. Third, a refined example of modelling and combining evidence information for TLS encryption from different sources illustrates the purpose and innovation of the ontology. Finally, the document concludes with a short summary and discussion of future work. The main result of this deliverable is a uniform graph-based model to (i) consolidate all extracted evidence information, (ii) enable the retrieval of combined evidence by aggregating individual pieces of information to a higher-level viewpoint, (iii) maintain traceability back to different information sources and extraction tools, and (iv) provide all required concepts for resource types and security features to assess certification-relevant security metrics. Based on this model, the uniform schema of evidence information will be further refined and analysed. The final version of the CertGraph ontology will then be reported in D2.11 [2], due in month 27. D2.10 – Certification Graph – v1 Version 1.0 – Final. Date: 31.01.2025 © EMERALD Consortium Contract No. GA 101120688 Page 8 of 28 www.emerald-he.eu 1 Introduction The CertGraph ontology, previously drafted in D2.1 [1], is a central graph-based model to support certification by bridging different layers and sources of extracted information, called evidence, from a cloud service. For this purpose, the ontology provides a highly structured, formal representation of a set of concepts (or classes) and their relationships and properties within the cloud service certification domain. It is created using a formal language, i.e. the Web Ontology Language (OWL), which supports complex expressions and logical inferences, including constraints, class hierarchies, and more. The main purpose of an ontology is to support knowledge sharing and reuse through structured domain knowledge as well as reasoning about the entities within the domain. In EMERALD, the CertGraph ontology enables harmonization of evidence gathering and assessment. Security controls defined in different schemas or catalogues are assigned to ontological concepts and those ontological types will be further used in metric definitions. For automated compliance tools to work, suitable evidence needs to be extracted and linked. The evidence extractors developed in the EMERALD project and described in D2.2 [3], D2.4 [4], D2.6 [5], and D2.8 [6] extract and provide suitable evidence from (i) the source code of services, often written in different programming languages, such as Java, Go, or Python (Codyze and eknows-e31), (ii) relevant parts of legal and policy documents, such as requirement or architecture documents (AMOE), (iii) applied machine learning (ML) models with respect to various criteria, such as robustness, fairness, and explainability (AI-SEC), and (iv) the virtual infrastructure, such as virtual machines, containers, or storage as well as runtime information, such as configuration or log files (Clouditor-Discovery). The CertGraph Ontology with its respective extensions described in this document is a central tool to bridge those different layers and sources of evidence. Therefore, the ontology defines a vocabulary for mapping between the properties that shall be measured and the respective gathering of adequate evidence. It allows to aggregate individual aspects and fragments of information to a higher-level viewpoint of combined evidence, not previously detectable by a single tool. 1.1 About this deliverable This document aims to describe the CertGraph ontology for modelling evidence information in the cloud service certification domain as a common structure for semantically linked and combined evidence. It consists of a core ontology and several sub-ontologies for capturing security features as well as domain concepts and relationships of different extensions. In this deliverable, the structure and the main concepts of the extensions to consolidate all extracted evidence information in terms of taxonomies is presented. In addition, properties are discussed which maintain traceability back to different information sources and extraction tools. For better illustration, we base the explanations on an example which uses one selected security criteria “encryption of data for transmission”, which is specified in the BSI C5:20202 (CRY-02). The CertGraph ontology represents the basis for integrating and instantiating the knowledge graph in the Evidence Store component in Task 3.1. It is also the foundation for analysing the semantic information and context of the heterogeneous evidence information in Task 2.6 to enable the retrieval of combined evidence. Another important aspect is to semantically describe 1 Note that the component was renamed from eknows to eknows evidence extractor (eknows-e3) 2 https://www.bsi.bund.de/dok/13368652 D2.10 – Certification Graph – v1 Version 1.0 – Final. Date: 31.01.2025 © EMERALD Consortium Contract No. GA 101120688 Page 9 of 28 www.emerald-he.eu how specific Resource Types are related to Security Features, which are essential concepts to assess certification-relevant security metrics in Task 3.4. 1.2 Document structure The document is structured as follows. In Section 2, we give a short recap of the CertGraph ontology as introduced in D2.1 [1]. We also indicate any changes from the initial draft and discuss current refinements. Section 3 provides functional and technical descriptions of the CertGraph ontology at the current development stage, as well as information on delivery and usage. Details on the sub-ontologies and extensions for the different cloud service layers are presented, i.e., for extracted evidence from source code, from policy documents, from ML models, and from cloud runtime environments. We further discuss refinements and limitations of concepts for combining evidence and supporting traceability, as well as for security features to assess new security metrics. In Section 4, the illustrative example originally outlined in D2.1 [1] for modelling and combining extracted evidence information from different sources is refined. Section 5 ends up with the conclusions, including a short summary of the content presented, open challenges, and future work. D2.10 – Certification Graph – v1 Version 1.0 – Final. Date: 31.01.2025 © EMERALD Consortium Contract No. GA 101120688 Page 16 of 28 www.emerald-he.eu Figure 4. Excerpt of the Evidence sub-ontology 3.2.2.1.2 Framework – containing common types of software components Common (high-level) types of software components are modelled in the Framework ontology (see Figure 5), which can be reused across different resources. This includes, for example, a HttpServer or a Logging component. This ontology is based on the taxonomy with the same name from the Cloud Property Graph [7]. Figure 5. Excerpt of the Framework sub-ontology 3.2.2.1.3 Functionality – containing common data types In addition to the high-level types (defined in Framework), smaller parts of software must be modelled. Also, in many parts of the CertGraph ontology, simple record types are needed. The Functionality ontology (see Figure 6) models all needed types, without restriction to a specific domain. For example, HttpEndpoint or HttpRequests are two classes in this ontology, which model smaller parts of software. On the contrast, CipherSuite, for example, is used as a record type and wraps the respective properties. This ontology is based on the taxonomy with the same name from the Cloud Property Graph [7]. D2.10 – Certification Graph – v1 Version 1.0 – Final. Date: 31.01.2025 © EMERALD Consortium Contract No. GA 101120688 Page 17 of 28 www.emerald-he.eu Figure 6. Excerpt of the Functionality sub-ontology 3.2.2.1.4 Properties – containing common object and data properties Within the whole CertGraph ontology, classes are connected by object and data properties. Often, these connections are quite similar or have similar semantics. The Properties ontology (see excerpt in Figure 7) defines a common set of object and data properties, which can be reused across the whole ontology. This includes generic properties to model *-to-one and *-tomany relationships like has and hasMultiple, and specific ones like filename or filetype to connect the respective properties to file-like classes and instances. Properties contained in this ontology are based on the ones from the Cloud Property Graph [7]. Figure 7. Excerpt of the Properties sub-ontology 3.2.2.1.5 Security – containing Security Feature Security models security properties for all kind of domains (see Figure 8) and is based on the taxonomy with the same name from the Cloud Property Graph [7]. Concepts in this ontology include:  Auditing – including anomaly detection or logging, for example.  Authenticity – including different types of authentications like passwords, OTP or SSO, for example.  Authorization – including firewalls or access control, for example.  Availability – including backups or redundancy, for example.  Confidentiality – including transport encryption or encryption at rest, for example.  Integrity – including signatures or hashes, for example.  Reliability – including ML-related scores for robustness or explainability, for example. D2.10 – Certification Graph – v1 Version 1.0 – Final. Date: 31.01.2025 © EMERALD Consortium Contract No. GA 101120688 Page 18 of 28 www.emerald-he.eu Figure 8. Excerpt of the Security sub-ontology 3.2.2.2 Cloud – an ontology extension for cloud resources Cloud models cloud resources (see Figure 9), and this extension is based on the CloudResource taxonomy from the Cloud Property Graph [7]. Currently, this ontology extension is already the most developed one. High-level concepts in this ontology include, among others:  CICDService – including jobs, and workflows.  Compute – including different types of compute resources like containers, functions, and virtual machines.  Credential – including certificates, keys, and secrets.  Networking – including virtual networks, and load balancers.  Storage – including file and data base storage. D2.10 – Certification Graph – v1 Version 1.0 – Final. Date: 31.01.2025 © EMERALD Consortium Contract No. GA 101120688 Page 19 of 28 www.emerald-he.eu Figure 9. Excerpt of the Cloud ontology extension 3.2.2.3 Application – an ontology extension for source code Application models source code and code-like artifacts (see Figure 10). A first draft of this extension, based on the genera idea of [11], is included in the current version. Still, further refinement of this extension is needed. This includes extending links to other classes and refining the abstraction level, as just storing the syntax tree would be far too detailed. High-level concepts in this ontology include:  Component – models large software components and forms the base class of Application and Library.  Module – models small software components like source code files.  Application – models source software applications and stores properties like the programming language.  Library – describes dependencies of components. Figure 10. Excerpt of the Application ontology extension 3.2.2.4 ML – an ontology extension for AI/ML models A taxonomy for assessing security-related criteria for ML models deployed in the cloud serves as a structured framework to evaluate, categorize, and mitigate potential threats and security vulnerabilities (see Figure 11). Whereas scientific work (e.g. [14]) provides a comprehensive taxonomy on deep learning techniques, in EMERALD we focus on required data to assess key criteria such as robustness against adversarial attacks and explainability (transparency and interpretability of decisions). We base our work on existing research [15] to be able to provide a generic approach that can be applied to various types of ML models. To assess the robustness and explainability scores of a ML model, the following information is typically required in the taxonomy on a high conceptual level: D2.10 – Certification Graph – v1 Version 1.0 – Final. Date: 31.01.2025 © EMERALD Consortium Contract No. GA 101120688 Page 20 of 28 www.emerald-he.eu  MLModel – representing the model information, that is the model architecture (including model parameters, hyperparameters, loss function, etc.), the respective task (image recognition, NLP, etc.), the required input and output data types and formats, and evaluation metrics (such as accuracy, response time, confidence, etc.)  Dataset – specifying the data actually used by the model, or its subset. Figure 11. Excerpt of the ML ontology extension Currently, classes contained in this ontology extension can be used to represent ML models and their context in a very high-level and abstract way. More details (e.g., properties) need to be elaborated and included into the taxonomy according to the needs and scope in EMERALD and will be documented in in the final deliverable D2.11 [2] due in month 27. Also, frameworks for Machine Learning need to be modelled. Here it still must be decided whether they are parts of the ML extension or fit better in the Framework sub-ontology of Core. 3.2.2.5 Document – an ontology extension for security-related documents Creating a taxonomy for documents, which primarily contains human-readable text (see Figure 12), for automatically assessing security policies and standards involves organizing content into hierarchical or categorized groups that reflect the nature, purpose, and context of the documents [16] [17] [18] [19]. High-level concepts in this taxonomy include:  PolicyDocument – documenting policies regarding information security, acceptable use, data protection, password, encryption, authentication, etc.  SecurityAdvisoryDocument – documenting regulators requirements, internal guidelines, etc.  ServiceMetadataDocument – documenting information on network security, application security, secure software development lifecycle, etc.  GenericDocument – representing a placeholder for additional documents that are not yet modelled separately. D2.10 – Certification Graph – v1 Version 1.0 – Final. Date: 31.01.2025 © EMERALD Consortium Contract No. GA 101120688 Page 21 of 28 www.emerald-he.eu Figure 12. Excerpt of the Document ontology extension At the time of writing, the taxonomy for security-related documents is only designed at a high level of abstraction, which will be adjusted in the final deliverable D2.11 [2] due in month 27 depending on specific needs and scope in EMERALD. 3.2.3 Technical specifications The Protégé6 and Git7 tools are used to develop the CertGraph ontology in EMERALD. Protégé is a desktop application developed by Stanford university that enables the modelling of ontologies using OWL concepts. It supports the splitting of the ontology into multiple files for better structuring and linking of concepts using different namespaces, i.e., through different subontologies and extensions. A reasoning component can derive new information based on rules, which is very useful for the fusion of multiple evidence parts and can detect inconsistencies in ontologies. All sub-ontologies and extensions are saved as OWL/XML8. Changes are checked into the Git repository. The discussion and review of these changes occur via pull requests on GitLab, before the changes are merged into the main branch. This process ensures that the created ontologies are secured in the sense of allowing for version control, to make sure that the newly developed ontologies are discussed, and only corrected and accepted versions are merged into the main branch. 3.3 Delivery and usage The following sub-sections detail the delivery and usage of the CertGraph ontology. The provided information is currently work in progress and may change. 3.3.1 Download The CertGraph ontology is available from the public EMERALD GitLab repository9 hosted by TECNALIA. The repository will host all sub-ontologies and extensions in the OWL/XML ontology format (*.owx). 7 https://www.git-scm.com/ 8 https://www.w3.org/TR/owl-xmlsyntax/ 9 https://git.code.tecnalia.dev/emerald/public/certgraph D2.10 – Certification Graph – v1 Version 1.0 – Final. Date: 31.01.2025 © EMERALD Consortium Contract No. GA 101120688 Page 22 of 28 www.emerald-he.eu 3.3.2 Package information Table 8 shows the structure of the Gitlab repository9 and its contents. Table 8. Overview and description of package structure for the CertGraph ontology Folder / File Description emerald.owx Entry point of the whole ontology, which can be used to open it in Protégé, for example (used for convenient development within the EMERALD project) core.owx Core ontology . In addition, it imports the five core ontologies below core/evidence.owx Evidence Ontology core/framework.owx Framework Ontology core/functionality.owx Functionality Ontology core/properties.owx Properties Ontology core/security.owx Security Feature Ontology resource.owx Wrapper ontology, which imports the four extension ontologies below (used for convenient development within the EMERALD project) resource/infrastructure.owx Ontology extension for cloud resources resource/application.owx Ontology extension for source code resource/ml.owx Ontology extension for machine learning models resource/document.owx Ontology extension for documents 3.3.3 Instructions for use Instructions for use are provided as part of the README in the public GitLab repository9. In summary, following requirements must be met before using the CertGraph ontology:  To explore the ontology, an ontology modelling tool that supports the OWL ontology format, such as Protégé, must be installed.  If the ontology should be extended or changed, a version control tool, such as Git, is recommended. The whole ontology can be viewed in Protégé by opening emerald.owx. In addition, if only parts of the ontology are to be viewed, the respective owx file can also be opened on its own. To instantiate the ontology, the following workflow is recommended: 1. Create a new ontology file. 2. Import core.owx using the Imported Ontologies view. 3. Import relevant extensions from the resource folder or all of them by importing resource.owx. 4. Created instances will be stored in the newly created ontology file. Note that the CertGraph ontology will not be visualized in the EMERALD UI. 3.3.4 Licensing information The CertGraph ontology and its sub-ontologies and extensions are licensed as open source under Apache License, Version 2.0. D2.10 – Certification Graph – v1 Version 1.0 – Final. Date: 31.01.2025 © EMERALD Consortium Contract No. GA 101120688 Page 23 of 28 www.emerald-he.eu 3.4 Limitations and future work The CertGraph ontology with its sub-ontologies and extensions will continuously be extended in the course of the project. Furthermore, some design decisions are not final and are still under discussion. This includes, but is not limited to, connections between classes in general or new classes required for describing the extension domains. The ontology is constantly being further developed, in particular, the Application and ML extensions require more extensive refinement. To meaningfully fuse the knowledge, which is provided by the evidence extraction tools, we have discussed several ideas on how to accomplish this. One idea is to use SWRL10 or similar languages to describe rules, which are used to derive new knowledge from gathered evidence, thus new edges are added to the graph, which in turn leads to denser interlinking of data. In this context, it has already become apparent that a unique ID is necessary to identify service instances (i.e., each service can be referenced by a unique URI across extractors). Another idea is to use SPARQL11 to query the graph and in this way to link the information in the graph and receive it as a query result. Currently, we are evaluating what can be implemented, which libraries are available, and what is supported by the used graph database. At the time of writing, the implications of each decision cannot yet be entirely estimated, and the structure of the CertGraph ontology will continue to evolve. The results will be reported in the upcoming deliverable D2.11 [2]. 10 https://www.w3.org/submissions/SWRL/ 11 https://www.w3.org/TR/sparql11-query/ D2.10 – Certification Graph – v1 Version 1.0 – Final. Date: 31.01.2025 © EMERALD Consortium Contract No. GA 101120688 Page 24 of 28 www.emerald-he.eu 4 Refined illustrative example of modelling and combining evidence information for the used TLS Version For better illustration, we base the idea for modelling and combining evidence information from different sources on an example (see Figure 13), which uses a selected security criteria: “Encryption of data for transmission”, which is specified in the BSI C5:20201 (CRY-02). In this example we model the used TLS (Transport Layer Security) version from different views. This is a refinement of the first idea drafted in D2.1 [1]. The focus is on illustrating interconnectivity between selected sub-ontologies and extensions, and not on contained details. The restructuring and extension of the CertGraph ontology is reflected in Figure 13. In the diagram, classes are visualized as rectangles and instances as hexagons. Open-headed arrows with a filled line (⇾) represent “subclass of” relations, which connect subclasses to their parent class, and open headed arrows with a dashed line (┉▹) represent “instance of” relations, which connect instances to their class. Simple arrows (→) represent data and object properties. These arrows are used between classes to define the schema, as well as between instances in their materialized form. Figure 13. Classes (rectangles) and instances (hexagons) for the TLS example, showing evidence found in source code (implemented) and corresponding evidence in a document (specified) regarding transport encryption, which can be used to verify CRY-02 from BSI C5:2020 (adapted from [9]) As described in Section 3.2.2, the ontology Core forms the basis for the CertGraph ontology. It defines the metamodel for EMERALD evidence and uses the concepts defined in the Security Feature sub-ontology, which contains a variety of security features and data properties:  Evidence is the central class and instances of it represent detected security evidence. Each evidence has connections to SecurityFeature, CertificationTarget, Resource, and Tool.  Resource represents the source of a piece of evidence and stores relevant metadata for the location. Each Resource has a connection to an ResourceType.  ResourceType classifies the role of resource within the system. ResourceType is modelled as an enumeration type in ontology terms. For this, a class is needed, and an D2.10 – Certification Graph – v1 Version 1.0 – Final. Date: 31.01.2025 © EMERALD Consortium Contract No. GA 101120688 Page 25 of 28 www.emerald-he.eu instance is created for each possible variant. Currently, we distinguish between these two possible variants: o The first variant, Specification, is used for evidence found in resources, which describe how the system should behave. The main application for this variant is in human-readable documents which are not automatically processed for compilation, e.g. policy documents. o The second variant, Implementation, is used for evidence found in resources, which describe, how the system actually behaves. This variant is mainly used for evidence found in machine-processed assets, e.g. source code, configuration files, or runtime information.  CertificationTarget ties the evidence to a certain service. This connection enables the fusion of evidence from multiple sources using a unique identifier for each service, which will be used as URI for the service instance.  Tool represents the extractor component that has collected the evidence.  To keep things simple, only a single feature (TransportEncryption class) is showcased in this example and the hierarchy has also been simplified to two levels. The base class of this hierarchy is SecurityFeature. Also, for simplicity reasons, just one data property version is shown to store the TLS version. Resource (defined in Core) is the starting point for ontology extensions. In this example, we used the Document and Application extensions, which are built on top of the Core ontology, and limit the scope to just one class per extension. As previously described, the classes in the extensions should model their respective domains. The following two classes are used in the example:  PolicyDocument represents a human-readable textual document for policies. It is modelled as a sub-class of Document and includes (has) two shown data properties type and path.  SourceCodeFile represents a source code file which is compiled for a given service and is stored in a repository. It is modelled as a (indirect) sub-class of SoftwareResource and includes (has) a data properties language. Gathered evidence provided by tools is modelled by instantiating classes defined in Core and in extensions. In the example in Figure 13, evidence for the certification target ProductService is provided by two extraction components:  AMOE scanned the DevGuide (a PDF document stored at docs/guide.pdf) and found that TLS version 1.2 is required to be used in development.  eknows-e3 scanned the ProductServer (written in Java) and found that TLS version 1.2 is used in the implementation.  Found evidence is represented as the instances TEFoundInDoc and TEFoundInCode, which have respective connections to the other instances. Please note that “TransportEncryption” is abbreviated as “TE” in the diagram. To sum up, the example illustrates the key idea of the Certification Graph to represent securityrelated parts of a cloud service, e.g. of the source code, in a graph structure and provide additional context through the discovery of other related cloud resources, e.g. policy documents. Bridging different domains allows to combine evidence at a higher level of knowledge and enables a comparison, for example, of what is described in policy documents and what is actually implemented in software. An important point for maximising the potential of the Certification Graph is that evidence from other extraction components must link to the same service instance. In OWL, two instances are considered as the same if they are identified by the same URI. This enables knowledge fusion later on for the assessment in WP3.