Paper deep dive
Supporting Cybersecurity Risk Management for Medical Devices via the SECUMAN Ontology and Shapes
Martin Diller, Anne Esslinger, Piotr Gorczyca, Evi Hartig, Lia Kacholdt, Hannes Strass
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 91%
Last extracted: 8/4/2026, 4:53:06 AM
Summary
The paper introduces SECUMAN, an OWL-based ontology and SHACL shapes designed to formalize and validate cybersecurity risk-management documentation for connected medical devices. It extends the safety-oriented RISKMAN ontology to address specific cybersecurity concepts such as threat scenarios, attacker profiles, and secure design arguments, aiming to improve consistency, traceability, and automated validation of risk files in compliance with standards like VDE Spec 90025 and IEC 81001-5-1.
Entities (10)
Relation Signals (7)
SECUMAN β supports β Medical Devices
confidence 95% Β· Supporting Cybersecurity Risk Management for Medical Devices via the SECUMAN Ontology
SECUMAN β uses β SHACL
confidence 95% Β· uses SHACL constraints to check structural completeness and conformity
SECUMAN β uses β OWL
confidence 95% Β· SECUMAN provides a formal OWL-based vocabulary
SECUMAN β alignswith β VDE Spec 90025
confidence 90% Β· The ontology is aligned with VDE Spec 90025
SECUMAN β extends β RISKMAN
confidence 90% Β· SECUMAN thereby complements Riskman by covering the security-risk domain
SECUMAN β models β Secure Design Arguments
confidence 88% Β· Cybersecurity risk control in the proposed model is represented through secure design arguments (SecDAs).
Medical Devices β regulatedby β EU MDR
confidence 85% Β· manufacturers must provide documented justification ... required in the EU by the Medical Device Regulation
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:We propose the SECUMAN ontology and shapes for representing and analysing cybersecurity risk-management documentation for medical devices. Cybersecurity risks are increasingly relevant for connected medical devices and may have direct consequences for patient safety. Current risk-management files are often maintained as semi-structured natural language text, which makes consistency checking, certification review, and reuse difficult. SECUMAN provides a formal OWL-based vocabulary for modelling security-risk context, assessment, control measures, and residual-risk evaluation, and uses SHACL constraints to check structural completeness and conformity with the intended documentation model. The ontology is aligned with VDE Spec 90025 and the related RISKMAN ontology and shapes, while extending their safety-oriented approach to concepts relevant to cybersecurity risk documentation such as threat scenarios, protection goals, attacker profiles, exposure levels, assets, and secure design arguments. SECUMAN is intended to support automated first-pass validation, traceability, and integration of cybersecurity and safety risk-management documentation.
Tags
Links
- Source: https://arxiv.org/abs/2608.00698v1
- Canonical: https://arxiv.org/abs/2608.00698v1
Trouble viewing inline? Open PDF directly β
Full Text
105,299 characters extracted from source content.
Expand or collapse full text
Supporting Cybersecurity Risk Management for Medical Devices via the Secuman Ontology and Shapes Martin Diller Corresponding Author: Martin Diller, martin.diller@tu-dresden.de Anne Esslinger Piotr Gorczyca Evi Hartig Lia Kacholdt Hannes Strass Faculty of Computer Science, TU Dresden, Germany Else KrΓΆner Fresenius Center for Digital Health, Dresden, Germany secunet Security Networks AG Abstract We propose the Secuman ontology and shapes for representing and analysing cybersecurity risk-management documentation for medical devices. Cybersecurity risks are increasingly relevant for connected medical devices and may have direct consequences for patient safety. Current risk-management files are often maintained as semi-structured natural language text, which makes consistency checking, certification review, and reuse difficult. Secuman provides a formal OWL-based vocabulary for modelling security-risk context, assessment, control measures, and residual-risk evaluation, and uses SHACL constraints to check structural completeness and conformity with the intended documentation model. The ontology is aligned with VDE Spec 90025 and the related Riskman ontology and shapes, while extending their safety-oriented approach to concepts relevant to cybersecurity risk documentation such as threat scenarios, protection goals, attacker profiles, exposure levels, assets, and secure design arguments. Secuman is intended to support automated first-pass validation, traceability, and integration of cybersecurity and safety risk-management documentation. keywords: Risk management EL devices , , , , , and 1 Introduction Medical devices are safety-critical systems whose failures may harm patients, users, or the environment. Manufacturers must therefore provide documented justification that device-related risks have been systematically identified, evaluated, and controlled, as required in the EU by the Medical Device Regulation [1]. In practice, however, risk-management documentation is still often exchanged as semi-structured natural language. This complicates certification and maintenance: notified bodies must inspect large volumes of text, manufacturers must keep risk files consistent across device versions, and reusable parts of risk analyses and risk controls remain difficult to identify and transfer. To address these problems for safety risk management, the Riskman ontology and shapes were proposed in [29]. Building on ISO 14971 and VDE SPEC 90025 [38, 8], Riskman encodes central concepts and structures used in safety-oriented risk-management documentation for medical devices, while its SHACL shapes express structural and semantic constraints relevant to such documentation. The approach is not intended to determine whether a concrete control measure is technically adequate; rather, it supports automated first-pass validation, improved navigation, and more systematic reuse of risk-management documentation. For connected medical devices, including wearable monitors, implantable systems, and networked clinical equipment, safety-oriented documentation alone is insufficient. Such devices are now an integral part of modern healthcare: they enable continuous patient monitoring, real-time physiological data acquisition, and remote management, thereby improving diagnosis, treatment, and healthcare efficiency [43]. However, increasing connectivity also introduces cybersecurity risks that may affect patient safety [60]. Cybersecurity risks in healthcare are therefore not merely theoretical. In Europe, ransomware attacks on hospitals have led to cancelled operations and reduced treatment capacity, as observed in incidents in Spain and the United Kingdom [7, 15], while attacks on national health systems have disrupted access to patient data and critical services [50]. In the United States, healthcare data breaches have remained at a sustained high level, with more than 700 large breaches reported annually and over 275 million patient records exposed in 2024 alone [4, 5]. At the same time, the cybersecurity threat landscape continues to intensify, with ransomware accounting for more than half of attacks on the health sector [24, 25]. These developments show that cybersecurity has become a critical aspect of healthcare systems, with direct implications for patient safety. Regulatory and guidance documents explicitly reflect this connection. The EU MDR requires software-based systems to be developed in accordance with state-of-the-art principles, including information security principles (MDR Annex I, Sections 3 and 17.2). MDCG 2019-16 likewise treats safety and security risks as interdependent and requires cybersecurity risks and risk controls with potential safety impact to be considered within safety risk-management processes, and vice versa [1, 51]. Similar expectations are reflected in international guidance and standards, including IMDRF principles on medical device cybersecurity, IEC 81001-5-1, and AAMI TIR57, which emphasize the need to manage cybersecurity risks in conjunction with patient-safety considerations across the device lifecycle [36, 37, 9]. A separate ontology for cybersecurity risk management is needed because security risks are conceptualized differently from safety risks. Safety risk management typically starts from device-related hazards and analyzes how they may lead to hazardous situations and harms. Cybersecurity risk management must instead account for threat scenarios shaped by the operating environment, product security properties, attack types, protection goals, vulnerabilities, attacker capabilities, affected assets, and impacts. These concepts are often handled by different expert groups and documented using different terminology, evaluation methods, and data structures [49]. A security ontology must therefore preserve cybersecurity-specific concepts while remaining compatible with safety-oriented documentation, so that securityβsafety dependencies can be made explicit where needed. In this work, we provide such an ontology, based on a model for risk-management documentation inspired by VDE SPEC 90025 and Riskman, but specialised to cybersecurity using relevant standards and guidance such as AAMI TIR57, AAMI SW96, NIST SP 800-30, and IEC 81001-5-1 [9, 10, 42, 36]. Specifically, our contributions are: (i) an ontology for representing central concepts and structural elements of cybersecurity risk-management documentation for medical devices; (i) SHACL shapes expressing constraints on such documentation; and (i) a Riskman-compatible modelling approach that supports traceability from threat context through risk assessment to risk control and residual-risk evaluation. Secuman thereby complements Riskman by covering the security-risk domain and provides a basis for future integration between cybersecurity and safety risk-management documentation. 2 Related Work Risk-management ontologies for medical devices. Several ontologies have been proposed for medical-device regulation, risk-related concepts, or adjacent compliance tasks, but only few target risk-management documentation itself β see also the discussion in [29]. Uciteli et al. [66] defined a Risk Identification Ontology embedded in the General Formal Ontology (GFO) [33, 32], but their focus was on identifying risks in time periods surrounding surgical procedures. Kim et al. [45] integrated concepts from IEC 60601-1, IEC 62304, and ISO 14971 in an ontology for medical-software development processes; however, their model is primarily intended to support process integration and standards compliance, rather than automated reasoning over risk-management files. SchΓΌtz et al. [59] developed an ontology for medical devices in Germany with a broader focus on manufacturers, operators, and legal procedures, yet with the aim of general semantic interoperability, and based on a legal framework that has since been superseded by the EU MDR. More recent work has explored semantic technologies for neighboring medical-device regulatory tasks: Chattoraj et al. [17] proposed an OWL/RDF knowledge-graph architecture for representing and querying FDA medical-device regulatory rules, while Zhu et al. [68] introduced a methodology for constructing a medical-device risk knowledge graph that combines standards, adverse-event data, and large language models. These works illustrate a continued interest in machine-processable representations for medical-device regulation and risk-related information, but they do not provide an ontology that supports the generation and validation of medical-device risk-management documentation itself. As already mentioned, this work builds on the Riskman ontology [29], which formalizes safety-oriented risk-management documentation for medical devices using OWL and SHACL. Secuman adopts this documentation-centered approach and is intended to integrate with Riskman, for example by mirroring its separation into βcontextβ, βassessmentβ, and βcontrolβ aspects. However, Secuman targets the security domain: it models concepts required for medical-device security-risk management, including security-specific mitigation strategies represented as secure-design arguments, in contrast to the safe-design arguments used in Riskman. Cybersecurity and security-risk ontologies in the medical domain. Ontology-based security modelling covers a wide range of concerns, including security taxonomies, vulnerability and attack representation, threat intelligence, operational technology and industrial Internet of Things security, semantic log analysis, and ontology-supported large-language-model applications, as summarized in surveys on these topics, e.g. [58, 2, 34, 41, 48]. As to work closely related to our setting, Sills et al. [62] constructed a cybersecurity knowledge graph for medical-device cyber threat intelligence by integrating manufacturer bulletins, CISA Industrial Control Systems Cyber Emergency Response Team alerts, Wikidata, and FDA AccessGUDID data; their focus, however, is on cyber-threat-intelligence aggregation and embedding-based retrieval rather than on a documentation ontology for security-risk management. Hannou et al. [30] introduced SafecareOnto, a cyber-physical security ontology for healthcare infrastructures that models hospital assets, dependencies, impacts, and protections in order to reason about incident propagation, whereas Secuman targets medical-device security-risk management files and their validation. Dart and Ahmed [19] propose CYBER-AIDD, a Unified Modeling Language-based ontology and governance framework for cybersecurity resilience in large healthcare providers, but this is a high-level organizational governance model rather than a formal OWL and SHACL framework for machine-checking manufacturer risk-management documentation. Liu et al. [47] presented an ontology-based framework for classifying forensic evidence from Internet of Medical Things devices; this work is security-adjacent and medical-domain-specific, but it concerns post-incident forensic evidence prioritization rather than prospective security-risk analysis and control documentation. Work on Internet of Medical Things vulnerability modelling and ontology-assisted automation is closer to our setting, but still differs in its target artefacts. Bughio et al. [13] developed an Internet of Medical Things cybersecurity ontology for remote patient monitoring that represents devices, vulnerabilities, exploits, attacks, services, vendors, and affected assets, and in related work proposed a knowledge-graph-based framework for Internet of Medical Things vulnerability detection [14]; but they are primarily oriented toward infrastructure, vulnerabilities, and threat intelligence rather than toward documentation and validation. Ghosh et al. [28] presented CVE-LLM, an ontology-assisted large language model system for vulnerability evaluation in post-market medical-device cybersecurity, using existing cybersecurity knowledge such as CWE and CAPEC via the SEPSES knowledge graph to support artefacts such as affected-status classifications, justifications, comments, and environmental CVSS vectors; this complements Secuman by showing the usefulness of ontology-enriched automation, but it does not define a formal ontology and SHACL constraint layer for security-risk management files themselves. Finally, Chander et al. [16] proposed an Intelligent Cybersecurity Ontology Framework for Internet of Medical Things-enabled remote patient monitoring that combines ontology-based modelling of devices, dependencies, vulnerabilities, and threats with graph learning, temporal updates, risk scoring, and adaptive mitigation, thereby addressing operational threat detection and response rather than regulatory or engineering documentation. Overall, the closest related works are those on medical-device cyber threat intelligence, Internet of Medical Things vulnerability modelling, and ontology-assisted vulnerability evaluation [62, 13, 14, 28]; these approaches are complementary to Secuman, since they structure vulnerability, threat, asset, or operational-security knowledge, while Secuman focuses on a lightweight OWL ontology and SHACL shapes for representing, reasoning over, and validating medical-device security-risk management documentation. 3 Background Figure 1: HTML rendering of a security risk. The Secuman ontology follows the Riskman ontology in being based on the recent VDE Spec 90025 [8], which proposes a structured format for digitalizing risk management files, as well as a machine-readable exchange format using HTML with RDFa [3], which annotates selected HTML tags with Resource Description Framework (RDF) triples. However, whereas VDE Spec 90025 and Riskman focus on safety aspects of medical devices, primarily following ISO 14971 [38], Secuman formalises a model for cybersecurity risk management documentation drawing on cybersecurity-relevant standards and guidance, such as AAMI TIR57, AAMI SW96, NIST SP 800-30, and IEC 81001-5-1 [9, 10, 42, 36]. At the same time, Secuman follows the same philosophy as VDE Spec 90025 and Riskman with respect to the digitalisation and validation of risk management files, and is intended to support integration with safety-focused risk management documentation. In contrast to vulnerability-centric approaches, which assess isolated technical weaknesses, the model formalised by Secuman is built around contextualized threat scenarios, where risk emerges from the interaction of the operating environment, device-specific properties, attack types, and attacker capabilities. The model is structured into three sections: Context, Assessment, and Control, mirroring the conceptual structure of safety risk management as formalised in VDE Spec 90025. This separation enables consistent reuse of context attributes across multiple risk entries, thereby reducing the workload involved in creating a security risk management file, and supports traceability from threat description to risk control. The model is designed to support structured documentation of security risks and to enable alignment and systematic integration with safety risk management. Figure 1 shows the rendering of an HTML file containing a cybersecurity risk structured according to the model formalised by Secuman. The context of the risk describes the conditions under which a threat can occur. It is defined by the combination of information pertaining to the operating environment, product, attack type, and protection goal. These elements represent reusable attributes that are not specific to a single risk, but can be applied across multiple risk scenarios and even across multiple devices employed in similar contexts. Specifically, the operating environment captures external conditions relevant to cybersecurity. It includes physical security, network security, and system and platform security or hardening. The product describes security-relevant properties of the device itself, including identity and access management, data security and privacy, and operations and maintenance. The protection goal is one of confidentiality, integrity or availability. The assessment aspects describe how the threat affects the system, its operational environment, and relevant stakeholders. In particular, the assessment refers to the context and extends it with the component through which the attack occurs, the affected asset, the impact, and the initial security risk level. The component represents the high-level system element that serves as the entry point of the attack, while the asset represents the physical or digital entity that has value to an individual, an organization, or a government and that is affected by the attack. The impact may include different types of consequences, such as harm to people, financial loss, legal implications, or operational disruption. It also explicitly records whether an impact on safety can occur. The initial security risk level, i.e., the security risk level before any mitigation has been proposed, is composed of an exposure level and an attacker profile, which together form the likelihood factor, as well as an impact level. The control section represents the risk after the application of control measures. It refers to the assessment aspects and includes a secure design argument and the residual security risk level. The latter has the same structure as the initial security risk level, but represents the risk level after mitigation measures have been applied. Cybersecurity risk control in the proposed model is represented through secure design arguments (SecDAs). SecDAs are a variant of the safety design arguments proposed in VDE Spec 90025 and formalised in Riskman β which in turn are a simplified form of assurance cases as defined in standards such as ISO/IEC/IEEE 15026 and ISO/TS 81001-2-1 [39, 40] β specialised for mitigation strategies addressing security risks. SecDAs are structured as trees, with the top-level SecDA representing the claim that a given cybersecurity risk is adequately controlled. Sub-arguments, or sub-SecDAs, contribute to this claim by refining the control strategy into more specific measures. The tree structure enforces a clear separation of abstraction levels: the top-level SecDA defines the overall strategy and includes a test report for effectiveness verification; intermediate SecDAs refine the strategy without implementation detail; and leaf SecDAs define concrete control measures. The strategy defines the overarching approach to risk mitigation, including the control type, i.e., preventive, detective, or corrective, the rationale for the control, and its intended effect on risk parameters, e.g., the likelihood or impact factor. In addition to the strategy, each leaf SecDA contains attributes describing the intervention method, the location of intervention, the organisational context of intervention, assumptions, and an assessment of the impact on safety and security. Specifically, the intervention method describes the mechanism by which the control is applied. It is the most concrete description of the control and specifies what must be implemented. It may include technical, operational, or administrative measures. The location of intervention specifies where the control is applied within the system, including device internals, connected infrastructure, or, where relevant, the deployment environment. The organisational context of intervention describes the operational setting of the control, including the device lifecycle phase, responsible stakeholders, and relevant policies or practices. The assumptions capture conditions that must hold for the control to be effective, such as the availability of infrastructure or expected user behaviour. Finally, the assessment of the impact on safety and security indicates whether the control measure may itself introduce a safety impact or an additional security impact that requires mitigation. SecDAs inherit the subcategorisation of safe design arguments from VDE Spec 90025 and Riskman into implementation-specific arguments and assurance arguments. Implementation-specific SecDAs include an implementation manifest, which provides evidence of how the control measure has been realised within the medical device; in particular, leaf SecDAs must always include an implementation manifest. Assurance SecDAs, on the other hand, additionally reference established state-of-the-art practices, such as standards, regulatory guidance, or accepted security frameworks. These references support the justification and traceability of control strategies. In contrast to safety, where standards often define the state of the art more comprehensively, cybersecurity assurance may also rely on evolving best practices and accepted security baselines. 4 Design & Overview 4.1 Design The Secuman ontology was developed based on requirements and conceptual design decisions defined by a consortium of experts in medical devices, regulatory affairs, security risk management, ontology engineering, and software development. We followed the Linked Open Terms (LOT) methodology [56], which builds on the NeOn methodology [64]. The development process comprised three steps: (1) Requirement specification: We studied relevant norms and standards and examined real medical device security risk management files to establish a shared understanding of the required terms. This was done through regular consortium meetings, workshops, and meetings with manufacturers and security risk experts. The result was a conceptual model of security risk documentation that formed the basis of the Secuman ontology. (2) Implementation: We encoded the ontology and shapes in OWL and SHACL. During development, we primarily used the HermiT reasoner [61] and the OntOlogy Pitfalls Scanner (OOPS!) [57] to support validity and consistency checks. (3) Publication and maintenance: The Secuman ontology and shapes111https://github.com/cl-tud/secuman as well as the associated validation pipeline222https://github.com/cl-tud/semeco-q2-validation-pipeline are maintained in separate GitHub repositories for version control, issue tracking, and open online access. 4.2 Formal Background The Secuman ontology is encoded in the β°ββ E\!L profile of OWL [54], while the shapes are specified in SHACL [67]. For ease of presentation, we describe the ontology here using the description logic β°ββ++ E\!L^++ [11, 12] that underlies the β°ββ E\!L profile of OWL. For shapes, we use the abstract SHACL syntax introduced by Corman et al. [18, 6]. Before giving an overview of Secuman, we therefore briefly recall the syntax, semantics, and aspects of reasoning relevant to our approach of β°ββ++ E\!L^++ as well as SHACL in the sense of Corman et al. The Description Logic β°ββ++ E\!L^++ β°ββ++ E\!L^++βs concept constructors and their semantics are recalled in the upper part of Table 1; the middle (lower) part shows the constructs allowed in a TBox (ABox). Table 1: Syntax and semantics of concept, TBox, and ABox expressions of β°ββ++ E\!L^++. Name Syntax Semantics individual name β aβ N_I ββΞβ a^Iβ ^I concept name β Aβ N_C ββΞβ A^I ^I role name β Rβ N_R ββΞβΓΞβ R^I ^IΓ ^I top β€ Ξβ ^I bottom β₯ β nominal \ a \ β \ a^I \ conjunction CβDC D Cββ©DβC^Iβ©D^I existential restriction β.Cβ R.C xβΞβ|βyβΞβ:(x,y)ββ&yβCβ \xβ ^I\ |\ β yβ ^I (x,y )β R^I \,\&\,yβC^I \ domain restriction β()βdom( R) A βββΓΞβ R^I A^IΓ ^I range restriction β()βran( R) A ββΞβΓβ R^I ^IΓ A^I general concept inclusion CβDC D CββDβC^I D^I role inclusion axiom ββ―ββ R_1 β¦b R_k R βββ―ββββ R_1^I β¦b R_k^I R^I concept assertion β() A( a) βββ a^Iβ A^I role assertion β(,) R( a, b) (β,β)ββ ( a^I, b^I )β R^I As usual for description logics, the semantics of β°ββ++ E\!L^++ is defined via interpretations β=(Ξβ,β β)I= ( ^I,Β·^I ) with a non-empty domain Ξβ ^I and an interpretation function β βΒ·^I. An interpretation βI is a model of an ABox A (TBox T) if it satisfies all elements of A (T) as per Table 1. An assertion Ξ± is entailed by βͺT , written βͺβ§Ξ±T Ξ±, if every model of βͺT is a model of Ξ±. SHACL To define SHACL, we conveniently re-use description logic vocabulary, viz., pairwise disjoint sets N_C of classes, N_R of properties, and N_I of individuals. A finite set A of assertions (an ABox) can then be seen as representing a labelled graph, with individuals acting as nodes, classes labelling nodes, and properties labelling edges. The syntax of shape expressions ΟΟ and path expressions E is shown in Table 2 (top). For the semantics, a given graph (ABox) A with nodes (individuals) β() N_I(A) defines an evaluation function β¦β β§ Β· ^A that assigns to each path expression E a binary relation β¦Eβ§β()Γ() E ^A N_I(A)Γ N_I(A), and to each shape expression ΟΟ a set β¦Οβ§β() Ο ^A N_I(A) via induction as shown in Table 2 (bottom). Table 2: Syntax and semantics of path and shape expressions. The syntax of path expressions E and shape expressions ΟΟ is given by the grammars E::=β£ββ£EβͺEβ£EβEβ£Eβ and Ο::=β€β£Ο1β§Ο2β£Β¬Οβ£β₯nE.Οβ£βE.Οβ£E=E E ::= R R^- Eβͺ E E 0.5$ $E E^* and Ο ::= A a _1 _2 Ο _nE.Ο β E.Ο E=E where nββ+n ^+, β Aβ N_C, β aβ N_I, and β Rβ N_R with β R^- indicating the inverse of R. β¦β§ 2.0pt[12.91663pt][0.0pt] R ^A =(a,b)|β(a,b)β = \ (a,b )\ |\ R(a,b) \ β¦E1βE2β§ E_1 0.5$ $E_2 ^A =β¦E1β§ββ¦E2β§ = E_1 ^A E_2 ^A β¦ββ§ R^- ^A =(b,a)|β(a,b)β = \ (b,a )\ |\ R(a,b) \ β¦E1βͺE2β§ -10.00002pt E_1βͺ E_2 ^A =β¦E1β§βͺβ¦E2β§ = E_1 ^Aβͺ E_2 ^A β¦Eββ§ -4.30554pt E^* ^A =(β¦Eβ§)β = ( E ^A )^* β¦β€β§ ^A =β() = N_I(A) β¦β§ A ^A =a|β(a)β = \a\ |\ A(a) \ β¦β§ a ^A = = \ a \ β¦Ο1β§Ο2β§ _1 _2 ^A =β¦Ο1β§β©β¦Ο2β§ = _1 ^Aβ© _2 ^A β¦Β¬Οβ§ Ο ^A =()ββ¦Οβ§ = N_I(A) Ο ^A β¦βE.Οβ§ β E.Ο ^A =a|βb:(a,b)ββ¦Eβ§ implies bββ¦Οβ§ = [85.35826pt][l]$ \a\ |\ β b: (a,b )β E ^A implies bβ Ο ^A \$ β¦β₯nE.Οβ§ _nE.Ο ^A =a||(a,b)ββ¦Eβ§ and bββ¦Οβ§|β₯n = [85.35826pt][l]$ \a\ |\ \ (a,b )β E ^A and bβ Ο ^A \ β₯ n \$ β¦E1=E2β§ E_1=E_2 ^A =a|βb:(a,b)ββ¦E1β§ iff (a,b)ββ¦E2β§ = [85.35826pt][l]$ \a\ |\ β b: (a,b )β E_1 ^A iff (a,b )β E_2 ^A \$ A shape constraint is an expression of the form βΟ AβΟ, with β Aβ N_C and ΟΟ a shape expression. A shape schema is a pair (,β¬) (C,B ) where C is a set of shape constraints and β¬B is a set of target concept assertions. Intuitively, a target β() A( a) expresses the requirement that a be labelled by A. Formally, an ABox A is a model for a set C of constraints if β¦Οβ§ββ¦β§ Ο ^A A ^A for all βΟβ AβΟ . An ABox A is validated against a schema (,β¬) (C,B ) if there exists a set β¬β²B of concept assertions such that (1) β¬ββ¬β²B , (2) β(β¬β²)ββ() N_I(B ) N_I(A), and (3) βͺβ¬β²A is a model for C. For brevity, in the following we also use the syntactic abbreviations β€nβE.Ο _nE.Ο for Β¬(β₯n+1E.Ο) ( _n+1E.Ο) and =1βE.Ο =_1E.Ο for β₯1βE.Οβ§β€1βE.Ο _1E.Ο _1E.Ο. Reasoning For reasoning with respect to the Secuman ontology and shapes, we adopt a materialisation-based approach. First, all relevant logical consequences of a given ABox together with the β°ββ++ E\!L^++ ontology are computed; more precisely, we derive all entailed concept and role assertions involving concept, role, and individual names occurring in the input ABox. Second, the resulting completed ABox is validated against the SHACL constraints. The feasibility of this approach in our setting is ensured by three observations. First, the role inclusion axioms of Secuman satisfy the syntactic restriction imposed by Baader et al. [12, Section 3], and hence entailment of assertions can be decided in polynomial time. Second, Secuman uses existential quantification only on the left-hand side of general concept inclusion axioms. As a consequence, materialisation does not introduce fresh individuals, and thus remains finite. Finally, under the formal semantics of Corman et al., SHACL validation is NP-complete in general, whereas certain positive fragments are PTIME-complete [18]. 4.3 The Secuman Ontology & Shapes Figure 2: Schema diagram of the Secuman classes and properties divided into context, assessment, and control aspects. Any arrow representing a property without an explicit name means that the property has the name hasX where X is the class in the range, e.g. hasAsset for the property with domain AnalyzedSecurityRisk and range Asset. Property arrows are also labelled with information pertaining to the Shape constraints, e.g. an AnalyzedSecurityRisk can have 1 or more assets or a SecDA only has a TestReport if it is a top SecDA (i.e. is not the child of any other SecDA), and then it must have exactly one TestReport. If there are no such labels, then each instance in the domain must be related to exactly one instance in the range. Moreover, any two classes without subclass relationship are disjoint. Common Aspects Figure 3 presents the GCIs for classes shared across the assessment and control aspects of security risk management documentation. In particular, the central class SecurityRisk is characterized compositionally: every individual with an attacker profile and an exposure level is a LikelihoodFactor, every individual with an impact level and a likelihood factor is a SecurityRiskLevel, and every individual with a security risk level is a SecurityRisk. Finally, there is the GCI that introduces the auxiliary class ImpactAssessment, which captures an assessment of whether a security risk or a control measure may induce further risks, in particular in the safety or security dimension. Concretely, it states that every individual with an isAffected value is an ImpactAssessment. β.β€ β isAffected. β ImpactAssessment (1) β.β€ββ.β€ β hasAttackerProfile. β hasExposureLevel. β LikelihoodFactor (2) β.β€ β hasSecurityRiskLevel. β SecurityRisk (3) β.β€ββ.β€ β hasImpactLevel. β hasLikelihoodFactor. β SecurityRiskLevel (4) Figure 3: General concept inclusions for common aspects. The domain and range axioms in Figures 4 and 5 complement these GCIs by fixing the intended source and target classes of the relevant properties, including hasAttackerProfile, hasExposureLevel, hasImpactLevel, hasLikelihoodFactor, hasSecurityRiskLevel, hasRationale, hasSafetyImpactAssessment, hasSecurityImpactAssessment, and isAffected. In particular, both hasSafetyImpactAssessment and hasSecurityImpactAssessment have domain ImpactAssessmentDomain. As shown by further GCIs introduced below, this makes it possible to associate impact assessments both with risks and control measures (security design arguments). Moreover, the range of isAffected is a Boolean, while an ImpactAssessment individual may also have associated a Rationale, which captures, as its name suggests, the rationale underlying a particular impact assessment. β() ( hasAttackerProfile) β LikelihoodFactor (5) β() ( hasAttackerProfile) β AttackerProfile (6) β() ( hasImpactLevel) β SecurityRiskLevel (7) β() ( hasImpactLevel) β ImpactLevel (8) Figure 4: Range and domain restrictions for common aspects, part I. β() ( hasLikelihoodFactor) β SecurityRiskLevel (9) β() ( hasLikelihoodFactor) β LikelihoodFactor (10) β() ( hasRationale) β ImpactAssessment (11) β() ( hasRationale) β Rationale (12) β() ( hasSafetyImpactAssessment) β ImpactAssessmentDomain (13) β() ( hasSafetyImpactAssessment) β ImpactAssessment (14) β() ( hasSecurityImpactAssessment) β ImpactAssessmentDomain (15) β() ( hasSecurityImpactAssessment) β ImpactAssessment (16) β() ( hasSecurityRiskLevel) β SecurityRisk (17) β() ( hasSecurityRiskLevel) β SecurityRiskLevel (18) β() ( hasExposureLevel) β LikelihoodFactor (19) β() ( hasExposureLevel) β ExposureLevel (20) β() ( isAffected) β ImpactAssessment (21) β() ( isAffected) β Boolean (22) Figure 5: Range and domain restrictions for common aspects, part I. At the constraint level, the SHACL shapes in Figure 6 make these dependencies explicit for instance data. In particular, each LikelihoodFactor must have exactly one AttackerProfile and exactly one ExposureLevel, each SecurityRisk must have exactly one SecurityRiskLevel, and each SecurityRiskLevel must have exactly one ImpactLevel and exactly one LikelihoodFactor. Moreover, each ImpactAssessment must specify exactly one isAffected value and may have at most one Rationale. ImpactAssessment β=1.β€β§β€1.β€ β =_1 isAffected. _1 hasRationale. (23) LikelihoodFactor β=1.β€β§=1.β€ β =_1 hasAttackerProfile. =_1 hasExposureLevel. (24) SecurityRisk β=1β.β€ β =_1 hasSecurityRiskLevel. (25) SecurityRiskLevel β=1.β€β§=1.β€ β =_1 hasImpactLevel. =_1 hasLikelihoodFactor. (26) Figure 6: Shape constraints for common aspects. Context The GCIs in Figure 7, together with the domain and range restrictions in Figure 8 capture the context-specific information used to characterize a security concern more precisely. The central class ContextSpecificThreat brings together four dimensions: the operating environment, the product, the attack type, and the protection goal. The two classes OperatingEnvironment and Product further structure this information: OperatingEnvironment groups physical, network, and system/platform security aspects, whereas Product groups identity and access management, data security and privacy, and operations and maintenance. The protection goals are given by the distinguished values availability, confidentiality, and integrity. β.β€ββ.β€ββ.β€ββ.β€β splitβ hasOperatingEnvironment. β hasProduct. &\\ β hasAttackType. β hasProtectionGoal. & ContextSpecificThreat split (27) β.β€ββ.β€ββ.β€β splitβ hasPhysicalSecurity. β hasNetworkSecurity. &\\ β hasSystemAndPlatformSecurity. & OperatingEnvironment split (28) β.β€ββ.β€ββ.β€β splitβ hasIdentityAndAccessManagement. &\\ β hasDataSecurityAndPrivacy. &\\ β hasOperationsAndMaintenance. & Product split (29) β()β()β() split $ ProtectionGoal( availability)$& $ ProtectionGoal( confidentiality)$\\ $ ProtectionGoal( integrity)$& split (30) Figure 7: General concept inclusion axioms and concept assertions for context aspects. β() ( hasAttackType) β ContextSpecificThreat (31) β() ( hasAttackType) β AttackType (32) β() ( hasDataSecurityAndPrivacy) β Product (33) β() ( hasDataSecurityAndPrivacy) β DataSecurityAndPrivacy (34) β() ( hasIdentityAndAccessManagement) β Product (35) β() ( hasIdentityAndAccessManagement) β IdentityAndAccessManagement (36) β() ( hasNetworkSecurity) β OperatingEnvironment (37) β() ( hasNetworkSecurity) β NetworkSecurity (38) β() ( hasOperationsAndMaintenance) β Product (39) β() ( hasOperationsAndMaintenance) β OperationsAndMaintenance (40) β() ( hasOperatingEnvironment) β ContextSpecificThreat (41) β() ( hasOperatingEnvironment) β OperatingEnvironment (42) β() ( hasPhysicalSecurity) β OperatingEnvironment (43) β() ( hasPhysicalSecurity) β PhysicalSecurity (44) β() ( hasProduct) β ContextSpecificThreat (45) β() ( hasProduct) β Product (46) β() ( hasProtectionGoal) β ContextSpecificThreat (47) β() ( hasProtectionGoal) β ProtectionGoal (48) β() ( hasSystemAndPlatformSecurity) β OperatingEnvironment (49) β() ( hasSystemAndPlatformSecurity) β SystemAndPlatformSecurity (50) Figure 8: Range and domain restrictions for context aspects. The corresponding SHACL shapes in Figure 9 require these structures to be present explicitly in the data. Thus, each ContextSpecificThreat must specify exactly one value for each of its four dimensions, while each OperatingEnvironment and each Product must provide exactly one value for each of their respective subdimensions. In addition, every ProtectionGoal value must belong to availability, confidentiality, integrity. β=1.β€β§=1.β€β§=1.β€β§=1.β€ split ContextSpecificThreat&β =_1 hasOperatingEnvironment. =_1 hasProduct. \\ & β =_1 hasAttackType. =_1 hasProtectionGoal. split (51) β=1.β€β§=1.β€β§=1β.β€ split OperatingEnvironment&β =_1 hasPhysicalSecurity. =_1 hasNetworkSecurity. \\ & β =_1 hasSystemAndPlatformSecurity. split (52) β=1β.β€β§=1β.β€β§=1β.β€ split Product&β =_1 hasIdentityAndAccessManagement. \\ & β =_1 hasDataSecurityAndPrivacy. \\ & β =_1 hasOperationsAndMaintenance. split (53) ProtectionGoal β,, β\ availability, confidentiality, integrity\ (54) Figure 9: Shape constraints for context aspects. Assessment The GCIs in Figure 10 capture the essential structure of analyzed security risks. In particular, every individual that is related to a context-specific threat, an impact, an initial security risk level, a component, and at least one asset is characterized as an AnalyzedSecurityRisk. Moreover, the property hasInitialSecurityRiskLevel is specified as a subproperty of hasSecurityRiskLevel, which implies that every AnalyzedSecurityRisk is also a SecurityRisk (see Figure 3), while Impact is placed under ImpactAssessmentDomain, thereby linking impacts β and indirectly also analyzed risks β to the common impact-assessment pattern introduced above. hasInitialSecurityRiskLevel β hasSecurityRiskLevel (55) Impact β ImpactAssessmentDomain (56) β.β€ββ.β€ββ.β€ββ.β€ββ.β€β splitβ hasContextSpecificThreat. β hasImpact. &\\ β hasInitialSecurityRiskLevel. β hasComponent. &\\ β hasAsset. & AnalyzedSecurityRisk split (57) Figure 10: General concept and role inclusion axioms for assessment aspects. Complementing this conceptual characterization, the domain and range restrictions in Figure 11 determine the intended typing of these relations by assigning AnalyzedSecurityRisk as their domain and ContextSpecificThreat, Impact, SecurityRiskLevel, Component, and Asset as the corresponding ranges. β() ( hasAsset) β AnalyzedSecurityRisk (58) β() ( hasAsset) β Asset (59) β() ( hasComponent) β AnalyzedSecurityRisk (60) β() ( hasComponent) β Component (61) β() ( hasContextSpecificThreat) β AnalyzedSecurityRisk (62) β() ( hasContextSpecificThreat) β ContextSpecificThreat (63) β() ( hasImpact) β AnalyzedSecurityRisk (64) β() ( hasImpact) β Impact (65) β() ( hasInitialSecurityRiskLevel) β AnalyzedSecurityRisk (66) β() ( hasInitialSecurityRiskLevel) β SecurityRiskLevel (67) Figure 11: Range and domain restrictions for assessment aspects. The ontological axioms are mirrored at the constraint level by the SHACL shape in Figure 12, which makes the intended dependencies explicit for data: each AnalyzedSecurityRisk must specify exactly one context-specific threat, exactly one initial security risk level, and exactly one component, while requiring at least one impact and at least one asset. β=1.β€β§β₯1.β€β§=1.β€β§=1.β€β§β₯1β.β€ split AnalyzedSecurityRisk&β =_1 hasContextSpecificThreat. _1 hasImpact. \\ & β =_1 hasInitialSecurityRiskLevel. =_1 hasComponent. \\ & β _1 hasAsset. split (68) Figure 12: Shape constraints for assessment aspects. Control The main GCI in Figure 13 defines controlled security risks: every individual that is related to an analyzed security risk, a residual security risk level, and a secure design argument is characterized as a ControlledSecurityRisk. In addition, and analogously to hasInitialSecurityRiskLevel for analyzed risks, hasResidualSecurityRiskLevel is introduced as a subproperty of hasSecurityRiskLevel, from which it follows that controlled security risks are also security risks. hasResidualSecurityRiskLevel β hasSecurityRiskLevel (69) β.β€ββ.β€ββ.β€β splitβ hasAnalyzedSecurityRisk. β hasResidualSecurityRiskLevel. &\\ β isMitigatedBy. & ControlledSecurityRisk split (70) Figure 13: General concept and role inclusion for control aspects. The domain and range restrictions in Figure 14 again fix the expected typing of the associated relations, with ControlledSecurityRisk as domain and AnalyzedSecurityRisk, SecurityRiskLevel, and SecDA as the corresponding ranges. β() ( hasAnalyzedSecurityRisk) β ControlledSecurityRisk (71) β() ( hasAnalyzedSecurityRisk) β AnalyzedSecurityRisk (72) β() ( hasResidualSecurityRiskLevel) β ControlledSecurityRisk (73) β() ( hasResidualSecurityRiskLevel) β SecurityRiskLevel (74) β() ( isMitigatedBy) β ControlledSecurityRisk (75) β() ( isMitigatedBy) β SecDA (76) Figure 14: Range and domain restrictions for control aspects. Finally, the SHACL shape in Figure 15 formulates the corresponding constraints at the data level by requiring each ControlledSecurityRisk to specify exactly one analyzed security risk, exactly one residual security risk level, and exactly one secure design argument. β=1.β€β§=1.β€β§=1β.β€ split ControlledSecurityRisk&β =_1 hasAnalyzedSecurityRisk. =_1 hasResidualSecurityRiskLevel. \\ & β =_1 isMitigatedBy. split (77) Figure 15: Shape constraints for control aspects. Secure Design Arguments The GCIs in Figure 16 define the central structure of secure design arguments and their refinements. In particular, every individual that is related to a strategy is characterized as a SecDA, while every SecDA with an implementation manifest is classified as a SecDAI. The remaining GCIs introduce the assurance-specific specializations AssuranceSecDA and AssuranceSecDAI. In addition, the axiom β SecDA ImpactAssessmentDomain places secure design arguments into the common impact-assessment pattern introduced earlier. ββ.β€ SecDA β hasAssurance. β AssuranceSecDA (78) β SecDAI AssuranceSecDA β AssuranceSecDAI (79) SecDA β ImpactAssessmentDomain (80) β.β€β splitβ hasStrategy. & SecDA split (81) ββ.β€ SecDA β hasImplementationManifest. β SecDAI (82) Figure 16: General concept and role inclusion axioms for secure design argument aspects. The domain and range restrictions in Figure 17 fix the expected typing of the relations involving secure design arguments, with SecDA as domain and, depending on the property, assumptions, assurances, intervention methods, implementation manifests, locations and organisational contexts of intervention, strategies, subordinate secure design arguments, and test reports as corresponding ranges. β() ( hasAssumption) β SecDA (83) β() ( hasAssumption) β Assumption (84) β() ( hasAssurance) β SecDA (85) β() ( hasAssurance) β Assurance (86) β() ( hasInterventionMethod) β SecDA (87) β() ( hasInterventionMethod) β InterventionMethod (88) β() ( hasImplementationManifest) β SecDA (89) β() ( hasImplementationManifest) β ImplementationManifest (90) β() ( hasLocationOfIntervention) β SecDA (91) β() ( hasLocationOfIntervention) β LocationOfIntervention (92) β() ( hasOrganisationalContextOfIntervention) β SecDA (93) β() ( hasOrganisationalContextOfIntervention) β OrganisationalContextOfIntervention (94) β() ( hasStrategy) β SecDA (95) β() ( hasStrategy) β Strategy (96) β() ( hasSubSecDA) β SecDA (97) β() ( hasSubSecDA) β SecDA (98) β() ( hasTestReport) β SecDA (99) β() ( hasTestReport) β TestReport (100) Figure 17: Range and domain restrictions for secure design argument aspects. Once more, the SHACL constraints in Figure 18, which include several helper constraints, specify the structural constraints of secure design arguments at the data level. They require each SecDA to specify exactly one strategy, while allowing at most one location of intervention, at most one assumption, at most one implementation manifest, and at most one assurance. Moreover, the recursive organization of secure design arguments is constrained explicitly: every SecDA must have at least one implementation-level argument reachable via the hasSubSecDA relation, which implies in particular that every leaf secure design argument must have an implementation manifest. In addition, top-level arguments must have exactly one test report, whereas non-top-level arguments must have none, and only leaf arguments may carry impact and intervention related information as well as assumptions. For assurance-specific arguments, the corresponding SHACL shape further requires exactly one assurance and propagates the assurance character recursively to subordinate arguments. Moreover, the shapes for SecDAI and AssuranceSecDAI require exactly one implementation manifest. In this respect, the subdivision of secure design arguments into assurance-specific and implementation-specific arguments, as well as the corresponding constraints, parallels that of safe design arguments from [29]; for convenience, however, these structures are duplicated explicitly in the Secuman shapes. TopSecDA ββ€0ββ.β€ β _0 hasSubSecDA^-. (101) NotTopSecDA ββ₯1ββ.β€ β _1 hasSubSecDA^-. (102) LeafSecDA ββ€0β.β€ β _0 hasSubSecDA. (103) NotLeafSecDA ββ₯1β.β€ β _1 hasSubSecDA. (104) TopSecDAAndOneTestReport ββ§=1β.β€ β TopSecDA =_1 hasTestReport. (105) NotTopSecDAAndNoTestReport ββ§β€0β.β€ β NotTopSecDA _0 hasTestReport. (106) LeafSecDAAndOneA ββ§=1βh.β€ β LeafSecDA =_1h. for all β(A,h)β in β for all (A,h) in (,), β\( InterventionMethod, hasInterventionMethod), (, β( OrganisationalContextOfIntervention, ), β hasOrganisationalContextOfIntervention), (,), β( SafetyImpactAssessment, hasSafetyImpactAssessment), (,) β( SecurityImpactAssessment, hasSecurityImpactAssessment)\ (107) NotLeafSecDAAndNoA ββ§β€0βh.β€ β NotLeafSecDA _0h. for all β(A,h)β in β for all (A,h) in (,), β\( Assumption, hasAssumption), (,), β( InterventionMethod, hasInterventionMethod), (,), β( LocationOfIntervention, hasLocationOfIntervention), (, β( OrganisationalContextOfIntervention, ), β hasOrganisationalContextOfIntervention), (,), β( SafetyImpactAssessment, hasSafetyImpactAssessment), (,) β( SecurityImpactAssessment, hasSecurityImpactAssessment)\ (108) AssuranceSecDA ββ. ββ hasSubSecDA. AssuranceSecDA β§=1β.β€ β =_1 hasAssurance. (109) AssuranceSecDAI β=1β.β€ β =_1 hasAssurance. β§=1β.β€ β =_1 hasImplementationManifest. (110) SecDA β=1β.β€ β =_1 hasStrategy. β§β€1βh.β€ for all βhβ in β _1h. for all h in ,, β \ hasLocationOfIntervention, hasAssumption, , β hasImplementationManifest, hasAssurance\ β§ββ. β β hasSubSecDA^*. SecDAI β§(β¨) β ( NotTopSecDA TopSecDAAndOneTestReport) β§(β¨) β ( TopSecDA NotTopSecDAAndNoTestReport) β§(β¨) β ( NotLeafSecDA LeafSecDAAndOneA) for all βAβ in β for all A in , β \ InterventionMethod, , β OrganisationalContextOfIntervention, , β SafetyImpactAssessment, β SecurityImpactAssessment\ β§(β¨) β ( LeafSecDA NotLeafSecDAAndNoA) for all βAβ in β for all A in , β \ Assumption, , β InterventionMethod, , β LocationOfIntervention, , β OrganisationalContextOfIntervention, , β SafetyImpactAssessment, β SecurityImpactAssessment\ (111) SecDAI β=1β.β€ β =_1 hasImplementationManifest. (112) Figure 18: Shape constraints for secure design argument aspects. Disjointness Finally, the disjointness axioms in Figure 19 operate at two conceptual levels. First, pairwise disjointness is imposed on the ontologyβs primitive classes, i.e., classes that are not introduced as subclasses of other domain classes and therefore serve as basic modeling categories. Second, further disjointness axioms are stated for specialized classes that refine more general concepts. In particular, AnalyzedSecurityRisk and ControlledSecurityRisk, both subsumed by SecurityRisk, are required to be disjoint, and Impact and SecDA, both subsumed by ImpactAssessmentDomain, are likewise required to be disjoint. Together, these axioms exclude unintended class overlap both among primitive categories and among their specialized refinements. AiβAj A_i A_j ββ₯ for all distinct βAi,Ajβ in for all distinct A_i,A_j in β,,, \ Assumption, Assurance, Asset, ,,, AttackType, AttackerProfile, Component, ,, ContextSpecificThreat, DataSecurityAndPrivacy, ,, IdentityAndAccessManagement, ImpactAssessment, ,, ImpactAssessmentDomain, ImpactLevel, ,, ImplementationManifest, InterventionMethod, ,, LikelihoodFactor, LocationOfIntervention, ,, NetworkSecurity, OperatingEnvironment, , OperationsAndMaintenance, , OrganisationalContextOfIntervention, ,,,, PhysicalSecurity, Product, ProtectionGoal, Rationale, ,,, SecurityRisk, SecurityRiskLevel, Strategy, ,, SystemAndPlatformSecurity, TestReport, β ExposureLevel\ (113) β AnalyzedSecurityRisk ControlledSecurityRisk ββ₯ (114) β Impact SecDA ββ₯ (115) Figure 19: Disjointness axioms. 5 Usage & Extensibility RDF distillerβ°ββ E\!L reasonerSHACL validatorHTML +RDFa submission Secuman ontology Optional ontology Secuman shapes Optional shapes Valida-tion report Figure 20: Overview of the Secuman validation pipeline. Figure 20 shows the validation pipeline for risk management documentation of medical devices proposed in [29], which we adapt here for risk management documentation concerning security aspects. As noted above, the approach assumes that risk documentation is submitted as HTML files containing risk management data encoded as RDF triples and expressed using the terminology of the Secuman ontology. An RDF distiller extracts the RDF graph from the HTML by removing the markup and isolating the RDF triples β see Figure 21 for a graphical depiction of the RDF encoding the security risk rendered via HTML in Figure 1. The RDF triples are then used as input to an OWL (β°ββ E\!L profile) reasoner together with Secuman and, where needed, additional ontologies. As a result, a materialized knowledge base is obtained and subsequently validated against the Secuman SHACL constraints, and potentially additional constraints, using a SHACL validator. The result is then communicated in the form of a human-readable validation report. Figure 21: Partial graphical representation of the RDF for the security risk from Figure 1. In our extension of the validation pipeline for Riskman (see the URL in Section 4.1), we in particular use the HermiT reasoner [61] for materialization, although additional options are provided through a realization wrapper that we also make available online333https://github.com/cl-tud/realization-wrapper. For SHACL validation, we use PySHACL [63]. Like Riskman, the Secuman ontology and shapes are intentionally lightweight so that the validation pipeline can be adapted easily to different modelling needs by incorporating additional ontologies and shapes, as already indicated above. One area in which the ontology will clearly require extension is the modelling of security risk levels, for example attacker profiles, exposure levels, and impact levels, as well as the way in which these are combined to determine whether a risk level is acceptable or unacceptable. A minimalist βpluginβ for adding such levels to the Secuman ontology is also provided in our validation pipeline. In this setting, the user may enrich the Secuman ontology with an ontology Ο,Ο,Οaβ-βvβ-βi:=βͺΟ,Ο,ΟK^a - -1.0muv - -1.0mui_Ο,Ο,Ο : -1.0mu=T_ gt _Ο,Ο,Ο for Ο attacker profiles, Ο exposure levels, and Ο impact levels (Ο,Ο,ΟββΟ,Ο,Ο ). This ontology not only introduces individual profiles and levels represented by nominals, but also an ordering gt over these profiles and levels: Ο,Ο,Ο= _Ο,Ο,Ο= β()| 1β€iβ€Οβͺ \\, $ AttackerProfile( a_i)$\ |\ 1β€ iβ€Ο \βͺ β()| 1β€iβ€Οβͺ \ $ ExposureLevel( e_i)$\ |\ 1β€ iβ€Ο \βͺ β()| 1β€iβ€Οβͺ \ $ ImpactLevel( s_i)$\ |\ 1β€ iβ€Ο \βͺ β(+,)| 1β€i<Οβͺ \ $ gt( a_i+1, a_i)$\ |\ 1β€ i<Ο \βͺ β(+,)| 1β€i<Οβͺ \ $ gt( e_i+1, e_i)$\ |\ 1β€ i<Ο \βͺ β(+,)| 1β€i<Ο \ $ gt( i_i+1, i_i)$\ |\ 1β€ i<Ο \ = _ gt= β() \tra( gt) \ To encode a concrete security risk matrix β that is, the way in which risk levels are derived from combinations of attacker profile, exposure level, and impact level β further axioms would need to be added to T_ gt, since such matrices are typically manufacturer-specific and therefore do not form part of Secuman. As an example, the following axioms first identify critical attacker profiles, exposure levels, and impact levels, and then use these classifications in the last two GCIs to determine critical likelihood factors and, subsequently, critical security levels: β.β β gt.\ a_2\ CriticalAP β.β β gt.\ e_3\ CriticalEL β.β β gt.\ i_2\ CriticalIL β.ββ.β β hasAttackerProfile. CriticalAP β hasExposureLevel. CriticalEL CriticalLF β.ββ.β β hasLikelihoodFactor. CriticalLF β hasImpactLevel. CriticalIL CriticalRiskLevel Checking for controlled security risks with critical residual risk levels can then be achieved by adding the SHACL constraint βΒ¬(β.) ControlledSecurityRiskβ (β hasResidualSecurityRiskLevel. CriticalRiskLevel) to the Secuman shapes. Of course, more complex conditions for deriving and detecting critical security risk levels can likewise be expressed by adding further axioms and shapes. 6 Conclusion We presented the Secuman ontology and accompanying SHACL shapes for representing and analysing cybersecurity risk-management documentation for medical devices. Analysed risks and their mitigations are represented as an β°ββ++ E\!L^++ ABox; the Secuman ontology is used together with an β°ββ E\!L reasoner to infer implicit knowledge; and SHACL constraints are used to check whether the resulting data conform to the intended documentation model. The ontology, shapes, and a reference implementation of the complete validation pipeline are freely available. The Secuman ontology complements the existing Riskman ontology by targeting security rather than safety risks of medical devices. It was designed with the ultimate objective of enabling the combined analysis of safety and security risk-management documentation. This objective is reflected not only in the similar structure of the Riskman and Secuman ontologies, but also, for instance, in the explicit safety-impact assessments associated with both analysed security risks and SecDAs in the Secuman ontology. The next step is therefore to develop a bridging ontology for safety and security aspects. Such an ontology should make it possible, for example, to propagate a safety impact identified for a security control measure into the safety-risk-management domain, where the resulting risk can then be analysed and controlled. Both Riskman and Secuman are lightweight ontologies intended to support first-pass validation and, in particular, to facilitate the analysis, navigation, and reuse of medical-device risk-management documentation. More substantive automated analysis will require integration with additional domain ontologies and structured cybersecurity resources; see, e.g., [65, 35, 44, 31, 52, 53, 55], as well as the existing medical-device-specific cybersecurity ontologies and knowledge graphs discussed in Section 2. Quality assurance is a particularly significant challenge [20, 27]; possible techniques include dialogue-inspired explication methods from computational argumentation [22, 23], as well as other approaches for providing justifications in logic-based knowledge-representation formalisms [21]. Finally, the systematic reuse of risk-management documentation remains an important open challenge. We believe that a shared, Semantic Web-based repository of risk-management documentation, including reusable secure and safe design arguments, could substantially accelerate both the creation and the evaluation of such documentation. This potential is especially promising when combined with large language models in retrieval-augmented generation setups [46, 26]. Realising this vision, however, will require appropriate incentives for sharing risk-management knowledge, as well as infrastructure that supports controlled access and reuse without exposing manufacturer secrets. Acknowledgements. This work was supported by funding from BMFTR (Federal Ministry of Research, Technology and Space) within the project SEMECO (grant no. 03ZU1210BG). References [1] (2017) Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 april 2017 on medical devices. External Links: Link Cited by: Β§1, Β§1. [2] M. Adach, K. HΓ€nninen, and K. Lundqvist (2022) Security ontologies: a systematic literature review. In International Conference on Enterprise Design, Operations, and Computing, p. 36β53. Cited by: Β§2. [3] B. Adida, M. Birbeck, S. McCarron, and I. Herman (2015) RDFa core 1.1 β third edition, 17 march 2015. Note: W3C Recommendation External Links: Link Cited by: Β§3. [4] S. Alder (2025) 2024 healthcare data breach report. Note: The HIPAA Journal External Links: Link Cited by: Β§1. [5] S. Alder (2026) Healthcare data breach statistics. Note: The HIPAA Journal External Links: Link Cited by: Β§1. [6] M. Andresel, J. Corman, M. Ortiz, J. L. Reutter, O. Savkovic, and M. Ε imkus (2020) Stable model semantics for recursive SHACL. In Proceedings of The Web Conference 2020, Y. Huang, I. King, T. Liu, and M. van Steen (Eds.), Wβ20, New York, NY, USA, p. 1570β1580. External Links: Document Cited by: Β§4.2. [7] AP News (2023) Cyberattack hits major hospital in Spanish city of Barcelona. Note: Accessed: April 27, 2026 External Links: Link Cited by: Β§1. [8] D. Arndt, P. Bank, P. Gorczyca, G. Heidenreich, P. Kettmann, I. Kobel, A. Ludwig, S. Mennicke, H. Sefkovicz, H. Strass, S. D. Tsurkan, H. Wenner, and U. Zeller (2024-07) VDE SPEC 90025 v1.0 (en): medical devices β risk management: framework of a computerized risk analysis format for transmission and submission (MD-CRAFTS). Note: VDE Verband der Elektrotechnik Elektronik Informationstechnik e.V. External Links: Link Cited by: Β§1, Β§3. [9] Association for the Advancement of Medical Instrumentation (2016) AAMI TIR57:2016/(R)2023: principles for medical device security β risk management. Note: Reaffirmed 2023 Cited by: Β§1, Β§1, Β§3. [10] Association for the Advancement of Medical Instrumentation (2023) ANSI/AAMI SW96:2023: standard for medical device security β security risk management for device manufacturers. Note: ANSI/AAMI SW96:2023 Cited by: Β§1, Β§3. [11] F. Baader, S. Brandt, and C. Lutz (2005) Pushing the EL envelope. In IJCAI-05, Proceedings of the Nineteenth International Joint Conference on Artificial Intelligence, Edinburgh, Scotland, UK, July 30 β August 5, 2005, L. P. Kaelbling and A. Saffiotti (Eds.), p. 364β369. External Links: Link Cited by: Β§4.2. [12] F. Baader, C. Lutz, and S. Brandt (2008) Pushing the EL envelope further. In Proceedings of the Fourth OWLED Workshop on OWL: Experiences and Directions, Washington, DC, USA, 1β2 April 2008, K. Clark and P. F. Patel-Schneider (Eds.), CEUR Workshop Proceedings, Vol. 496. External Links: Link Cited by: Β§4.2, Β§4.2. [13] K. S. Bughio, D. M. Cook, and S. A. A. Shah (2024) Developing a novel ontology for cybersecurity in Internet of Medical Things-enabled remote patient monitoring. Sensors 24 (9), p. 2804. External Links: Document Cited by: Β§2, Β§2. [14] K. S. Bughio, D. M. Cook, and S. A. A. Shah (2024) Novel knowledge graph-based modeling for vulnerability detection in the Internet of Medical Things. In Recent Challenges in Intelligent Information and Database Systems, Communications in Computer and Information Science, p. 314β325. External Links: Document Cited by: Β§2, Β§2. [15] D. Campbell and A. Hern (2024) Services disrupted as London hospitals hit by cyber-attack. Note: The Guardian External Links: Link Cited by: Β§1. [16] A. S. Chander, M. Harshavardhana, N. Sathyanarayana, K. Hemalatha, and B. Gagana (2025) Intelligent cybersecurity ontology framework for Internet of Medical Things-enabled remote patient monitoring. In ITM Web of Conferences, Vol. 79, p. 01030. Cited by: Β§2. [17] S. Chattoraj, R. Walid, and K. P. Joshi (2024) Semantically rich approach to automating regulations of medical devices. In ICDH, p. 132β137. External Links: Document Cited by: Β§2. [18] J. Corman, J. L. Reutter, and O. Savkovic (2018-10) Semantics and validation of recursive SHACL. In The Semantic Web β ISWC 2018 β 17th International Semantic Web Conference, Proceedings, Part I, D. VrandeciΔ, K. Bontcheva, M. C. SuΓ‘rez-Figueroa, V. Presutti, I. Celino, M. Sabou, L. Kaffee, and E. Simperl (Eds.), Lecture Notes in Computer Science, Vol. 11136, p. 318β336. External Links: Document Cited by: Β§4.2, Β§4.2. [19] M. Dart and M. Ahmed (2023) CYBER-AIDD: a novel approach to implementing improved cybersecurity resilience for large Australian healthcare providers using a Unified Modelling Language ontology. Digital Health 9, p. 20552076231191095. Cited by: Β§2. [20] J. L. de la Vara, G. JimΓ©nez, R. Mendieta, and E. Parra (2019) Assessment of the quality of safety cases: a research preview. In Requirements Engineering: Foundation for Software Quality β 25th International Working Conference, REFSQ 2019, Essen, Germany, March 18-21, 2019, Proceedings, E. Knauss and M. Goedicke (Eds.), Lecture Notes in Computer Science, Vol. 11412, p. 124β131. External Links: Document Cited by: Β§6. [21] M. Denecker, G. Brewka, and H. Strass (2015) A formal theory of justifications. In Logic Programming and Nonmonotonic Reasoning β 13th International Conference, LPNMR 2015, Lexington, KY, USA, September 27-30, 2015. Proceedings, F. Calimeri, G. Ianni, and M. TruszczyΕski (Eds.), Lecture Notes in Computer Science, Vol. 9345, p. 250β264. External Links: Document Cited by: Β§6. [22] M. Diller, S. A. Gaggl, and P. Gorczyca (2021) Flexible dispute derivations with forward and backward arguments for assumption-based argumentation. In Logic and Argumentation β 4th International Conference, CLAR 2021, Hangzhou, China, October 20-22, 2021, Proceedings, P. Baroni, C. BenzmΓΌller, and Y. N. WΓ‘ng (Eds.), Lecture Notes in Computer Science, Vol. 13040, p. 147β168. External Links: Document Cited by: Β§6. [23] M. Diller and P. Gorczyca (2025) ABA disputes in ASP: advancing argument games through multi-shot solving. In PRIMA, Lecture Notes in Computer Science, Vol. 16366, p. 566β584. Cited by: Β§6. [24] ENISA (2025) Health. Note: Accessed: April 27, 2026 External Links: Link Cited by: Β§1. [25] European Commission (2026) Cybersecurity in healthcare. Note: Accessed: April 27, 2026 External Links: Link Cited by: Β§1. [26] W. Fan, Y. Ding, L. Ning, S. Wang, H. Li, D. Yin, T. Chua, and Q. Li (2024) A survey on RAG meeting LLMs: towards retrieval-augmented large language models. In Proceedings of the ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, p. 6491β6501. External Links: Document Cited by: Β§6. [27] S. Foster, Y. Nemouchi, M. Gleirscher, R. Wei, and T. Kelly (2021) Integration of formal proof into unified assurance cases with Isabelle/SACM. Formal Aspects Comput. 33 (6), p. 855β884. External Links: Document Cited by: Β§6. [28] R. Ghosh, H. von Stockhausen, M. Schmitt, V. G. Marica, S. K. Karn, and O. Farri (2025) CVE-LLM: ontology-assisted automatic vulnerability evaluation using large language models. In Proceedings of the AAAI Conference on Artificial Intelligence, Vol. 39, p. 28757β28765. External Links: Document Cited by: Β§2, Β§2. [29] P. Gorczyca, D. Arndt, M. Diller, J. Hampe, G. Heidenreich, P. Kettmann, M. KrΓΆtzsch, S. Mennicke, S. Rudolph, and H. Strass (2025) Supporting risk management for medical devices via the RISKMAN ontology and shapes. In SEMANTiCS, Studies on the Semantic Web, p. 226β246. Cited by: Β§1, Β§2, Β§2, Β§4.3, Β§5. [30] F. Hannou, F. Atigui, N. Lammari, and S. S. Cherfi (2021) SafecareOnto: a cyber-physical security ontology for healthcare systems. In DEXA (2), Lecture Notes in Computer Science, p. 22β34. Cited by: Β§2. [31] E. Hemberg, J. Kelly, M. Shlapentokh-Rothman, B. Reinstadler, K. Xu, N. Rutar, and U. OβReilly (2021) Linking threat tactics, techniques, and patterns with defensive weaknesses, vulnerabilities and affected platform configurations for cyber hunting. External Links: Document, 2010.00533 Cited by: Β§6. [32] H. Herre, B. Heller, P. Burek, R. Hoehndorf, F. Loebe, and H. Michalek (2006) General formal ontology (GFO): a foundational ontology integrating objects and processes. part I: basic principles (version 1.0). Technical report University of Leipzig: Research Group Ontologies in Medicine (Onto-Med). Note: Onto-Med Report Cited by: Β§2. [33] H. Herre (2010) General formal ontology (GFO): a foundational ontology for conceptual modelling. In Theory and Applications of Ontology: Computer Applications, R. Poli, M. Healy, and A. Kameas (Eds.), Dordrecht, p. 297β345. External Links: Document, ISBN 978-90-481-8847-5 Cited by: Β§2. [34] S. Hollerer, T. Sauter, and W. Kastner (2024) A survey of ontologies considering general safety, security, and operation aspects in OT. IEEE Open Journal of the Industrial Electronics Society 5, p. 861β885. External Links: Document Cited by: Β§2. [35] M. Iannacone, S. Bohn, G. Nakamura, J. Gerth, K. Huffer, R. Bridges, E. Ferragut, and J. Goodall (2015) Developing an ontology for cyber security knowledge graphs. In Proceedings of the 10th Annual Cyber and Information Security Research Conference, CISRC β15. External Links: Document Cited by: Β§6. [36] International Electrotechnical Commission (2021) IEC 81001-5-1:2021: health software and health IT systems safety, effectiveness and security β part 5-1: security β activities in the product life cycle. Note: IEC 81001-5-1:2021 External Links: Link Cited by: Β§1, Β§1, Β§3. [37] International Medical Device Regulators Forum (2020) IMDRF/CYBER WG/N60FINAL:2020: principles and practices for medical device cybersecurity. Note: IMDRF/CYBER WG/N60FINAL:2020 Cited by: Β§1. [38] International Organization for Standardization (2019) ISO 14971:2019: medical devices β application of risk management to medical devices. Note: Published by ISO, Geneva, Switzerland. External Links: Link Cited by: Β§1, Β§3. [39] International Organization for Standardization (2019) ISO/IEC/IEEE 15026-1:2019: systems and software engineering β systems and software assurance β part 1: concepts and vocabulary. Note: ISO/IEC/IEEE 15026-1:2019 Cited by: Β§3. [40] International Organization for Standardization (2025) ISO/TS 81001-2-1:2025: health software and health IT systems safety, effectiveness and security β part 2-1: coordination β guidance and requirements for the use of assurance cases for safety and security. Note: ISO/TS 81001-2-1:2025 External Links: Link Cited by: Β§3. [41] M. A. Jarwar, J. W. C. Freng, and S. Ali (2025) Modelling industrial IoT security using ontologies: a systematic review. IEEE Open Journal of the Communications Society. External Links: Document Cited by: Β§2. [42] Joint Task Force Transformation Initiative (2012-09) NIST special publication 800-30 revision 1: guide for conducting risk assessments. Technical report Technical Report NIST SP 800-30 Rev. 1, National Institute of Standards and Technology. External Links: Document Cited by: Β§1, Β§3. [43] M. Kang, E. Park, B. H. Cho, and K. Lee (2018) Recent patient health monitoring platforms incorporating internet of things-enabled smart devices. International neurourology journal 22 (Suppl 2), p. S76. Cited by: Β§1. [44] E. Kiesling, A. Ekelhart, K. Kurniawan, and F. Ekaputra (2019) The SEPSES knowledge graph: an integrated resource for cybersecurity. In The Semantic Web β ISWC 2019, Lecture Notes in Computer Science, Vol. 11779, p. 198β214. External Links: Document Cited by: Β§6. [45] D. Kim, Y. Park, B. Lee, and J. Lee (2019) Ontology-based process integration incorporating reference associations between medical standards from the perspective of medical software developers. Journal of Ambient Intelligence and Humanized Computing. External Links: Document Cited by: Β§2. [46] P. Lewis, E. Perez, A. Piktus, F. Petroni, V. Karpukhin, N. Goyal, H. KΓΌttler, M. Lewis, W. Yih, T. RocktΓ€schel, S. Riedel, and D. Kiela (2020) Retrieval-augmented generation for knowledge-intensive NLP tasks. In Advances in Neural Information Processing Systems, Vol. 33, p. 9459β9474. Cited by: Β§6. [47] J. Liu, R. Sasaki, and T. Uehara (2023) An ontology-based framework for medical IoT forensic evidence. In QRS Companion, p. 863β864. Cited by: Β§2. [48] B. LourenΓ§o, P. AdΓ£o, J. F. Ferreira, M. M. Marques, and C. Vaz (2025) Structuring security: a survey of cybersecurity ontologies, semantic log processing, and LLMs application. CoRR abs/2510.16610. Cited by: Β§2. [49] J. Martinez, J. Godot, A. Ruiz, A. Balbis, and R. Ruiz Nolasco (2020) Safety and security interference analysis in the design stage. In International Conference on Computer Safety, Reliability, and Security, p. 54β68. Cited by: Β§1. [50] M. I. Mashinchi, T. Acton, and P. M. Datta (2024) When healthcare becomes sick: recovering from ransomware. Journal of Information Technology Teaching Cases, p. 20438869241279443. Cited by: Β§1. [51] Medical Device Coordination Group (2020) MDCG 2019-16: guidance on cybersecurity for medical devices. Note: MDCG 2019-16 Cited by: Β§1. [52] MITRECAPEC: common attack pattern enumeration and classification(Website) External Links: Link Cited by: Β§6. [53] MITRECWE: common weakness enumeration(Website) External Links: Link Cited by: Β§6. [54] B. Motik, B. C. Grau, I. Horrocks, Z. Wu, A. Fokoue, and C. Lutz (2012-12) OWL 2 web ontology language profiles (second edition). Note: W3C Recommendation External Links: Link Cited by: Β§4.2. [55] National Institute of Standards and TechnologyNational vulnerability database(Website) External Links: Link Cited by: Β§6. [56] M. Poveda-VillalΓ³n, A. FernΓ‘ndez-Izquierdo, M. FernΓ‘ndez-LΓ³pez, and R. GarcΓa-Castro (2022-05) LOT: an industrial-oriented ontology engineering framework. Engineering Applications of Artificial Intelligence 111, p. 104755. External Links: Document, ISSN 0952-1976 Cited by: Β§4.1. [57] M. Poveda-VillalΓ³n, A. GΓ³mez-PΓ©rez, and M. C. SuΓ‘rez-Figueroa (2014) OOPS! (OntOlogy Pitfall Scanner!): an online tool for ontology evaluation. International Journal on Semantic Web and Information Systems (IJSWIS) 10 (2), p. 7β34. Cited by: Β§4.1. [58] F. d. F. Rosa, R. Bonacin, and M. Jino (2017) The security assessment domain: a survey of taxonomies and ontologies. arXiv preprint arXiv:1706.09772. Cited by: Β§2. [59] A. E. SchΓΌtz, T. Fertig, and K. Weber (2020) Defining a core ontology for medical devices in Germany to ensure semantic interoperability. In Modelling and Development of Intelligent Systems β 7th International Conference, MDIS 2020, Sibiu, Romania, October 22-24, 2020, Revised Selected Papers, D. Simian and L. F. Stoica (Eds.), Communications in Computer and Information Science, Vol. 1341, p. 394β410. External Links: Document Cited by: Β§2. [60] S. Schwartz, A. Ross, S. Carmody, P. Chase, S. C. Coley, J. Connolly, C. Petrozzino, and M. Zuk (2018) The evolving state of medical device cybersecurity. Biomedical instrumentation & technology 52 (2), p. 103β111. Cited by: Β§1. [61] R. D. Shearer, B. Motik, and I. Horrocks (2008) HermiT: a highly efficient OWL reasoner. In Owled, Vol. 432, p. 91. Cited by: Β§4.1, Β§5. [62] M. Sills, P. Ranade, and S. Mittal (2020) Cybersecurity threat intelligence augmentation and embedding improvement β a healthcare use case. In IEEE International Conference on Intelligence and Security Informatics (ISI), p. 1β6. Cited by: Β§2, Β§2. [63] pySHACL External Links: Document Cited by: Β§5. [64] M. C. SuΓ‘rez-Figueroa, A. GΓ³mez-PΓ©rez, and M. FernΓ‘ndez-LΓ³pez (2015) The NeOn methodology framework: a scenario-based methodology for ontology development. Appl. Ontology 10, p. 107β145. External Links: Link Cited by: Β§4.1. [65] Z. Syed, A. Padia, M. L. Mathews, T. Finin, and A. Joshi (2016-02) UCO: a unified cybersecurity ontology. In Proceedings of the AAAI Workshop on Artificial Intelligence for Cyber Security, p. 195β202. Cited by: Β§6. [66] A. Uciteli, J. Neumann, K. Tahar, K. Saleh, S. Stucke, S. FaulbrΓΌck-RΓΆhr, A. Kaeding, M. Specht, T. Schmidt, T. Neumuth, A. Besting, D. Stegemann, F. Portheine, and H. Herre (2017) Ontology-based specification, identification and analysis of perioperative risks. J. Biomed. Semant. 8 (1), p. 36:1β36:14. External Links: Document Cited by: Β§2. [67] W3C (2017-07) Shapes constraint language (SHACL): technical report. External Links: Link Cited by: Β§4.2. [68] W. Zhu, P. Zhang, W. Xia, Z. Gao, W. Li, R. Tian, and L. Wang (2026) AI-driven medical device risk management: a new paradigm integrating large language models and prompt engineering for standard-risk knowledge graph construction and application. Risk Management and Healthcare Policy 19, p. 571156. External Links: Document, https://w.tandfonline.com/doi/pdf/10.2147/RMHP.S571156, Link Cited by: Β§2.