[Paper] An Ontology-Based Approach to Security Risk Identification of Container Deployments in OT Contexts

Source: arXiv - 2601.04010v1

Overview

The paper presents Container Security Risk Ontology (CSRO), a model‑driven framework that lets engineers automatically identify and quantify security risks in containerised Operational Technology (OT) deployments. By formalising the relationships between container artefacts, attack scenarios, and risk‑assessment rules, CSRO bridges the gap between low‑level container configurations and high‑level security decisions—an increasingly critical need as OT environments adopt Docker‑style micro‑services.

Key Contributions

• A unified ontology that captures five inter‑related domains: adversary behaviour, contextual assumptions, attack scenarios, risk‑assessment rules, and container security artefacts.
• End‑to‑end risk calculation: from concrete container descriptors (e.g., privileged flag, network capabilities) to a reproducible risk score.
• Tool‑agnostic integration: the ontology can be linked to existing CI/CD pipelines, IaC manifests (Docker‑Compose, Helm), and security scanners without rewriting them.
• Case‑study validation in a realistic OT setting, showing that CSRO can automatically flag high‑risk configurations that would be missed by manual audits.
• Modular design that isolates the technical (container‑level) layer from higher‑level host‑ and organisational‑level risk factors, enabling future extensions.

Methodology

1. Domain analysis – The authors surveyed OT container deployments, identified common privileged‑mode patterns, and mapped the knowledge gaps among IT, OT, and security teams.
2. Ontology engineering – Using OWL (Web Ontology Language), they encoded the five domains as classes, properties, and inference rules. For example, a rule may state: If a container runs with --privileged and mounts the host /dev directory, then the attack scenario “Escalate to host root” becomes applicable.
3. Risk assessment rules – Each attack scenario is linked to a quantitative risk formula (e.g., CVSS‑like scoring) that combines likelihood (derived from adversary capability) and impact (derived from the criticality of the OT asset).
4. Toolchain integration – A lightweight parser extracts container descriptors from Dockerfiles, Compose files, or Kubernetes manifests and populates the ontology. A reasoner (e.g., Pellet) then automatically derives applicable attack scenarios and computes risk levels.
5. Case‑study evaluation – The approach was applied to a real‑world OT plant that uses containerised monitoring agents. The authors compared CSRO‑generated risk scores against a manual security audit.

Results & Findings

• Automation: CSRO identified 12 high‑risk containers that a manual review missed, reducing the audit time by ~70 %.
• Reproducibility: Running the same artefacts through the ontology on different machines produced identical risk scores, confirming deterministic behaviour.
• Interpretability: Each risk flag is traceable to a specific ontology rule, making it easy for engineers to understand why a container is risky (e.g., “privileged flag + host network = potential packet injection”).
• Scalability: The reasoning step processed 250 container definitions in under 3 seconds on a standard laptop, indicating suitability for CI pipelines.

Practical Implications

• CI/CD security gates – Teams can embed CSRO checks into build pipelines to reject images that exceed a configurable risk threshold before they reach production OT networks.
• Dynamic compliance – Because the ontology is data‑driven, compliance teams can update risk‑assessment rules (e.g., new CVE impact scores) without touching code, keeping the risk model current with emerging threats.
• Cross‑team alignment – The shared ontology serves as a common language between OT engineers, IT ops, and security analysts, reducing miscommunication around privileged container usage.
• Incident response prioritisation – Risk scores can feed ticketing systems, automatically assigning higher severity to containers that expose critical OT assets.
• Foundation for broader risk models – The modular structure makes it straightforward to plug in host‑level factors (e.g., kernel hardening) or organisational policies (e.g., role‑based access) later on.

Limitations & Future Work

• Scope limited to container‑level technical controls – Host‑hardening measures, network segmentation policies, and organisational processes are not yet modelled.
• Ontology maintenance overhead – Keeping the knowledge base up‑to‑date with new container features or OT‑specific attack patterns requires dedicated effort.
• Evaluation confined to a single case study – Wider validation across different industries (e.g., energy, manufacturing) would strengthen generalisability.
• Future directions include extending CSRO to cover Kubernetes‑level constructs, integrating threat‑intel feeds for dynamic likelihood estimation, and building a visual dashboard for non‑technical stakeholders.

Authors

• Yannick Landeck
• Dian Balta
• Martin Wimmer
• Christian Knierim

Paper Information

• arXiv ID: 2601.04010v1
• Categories: cs.SE, cs.CR
• Published: January 7, 2026
• PDF: Download PDF