1. Home
  2. CyberNEMO Components

L2S-M: Enabling Virtual Network Isolation in Kubernetes

In our previous post, we explored why micro-segmentation is becoming increasingly important for securing cloud-native infrastructures, particularly in Kubernetes environments. However, while the benefits of isolating workloads into separate network domains are clear, implementing this functionality across distributed Kubernetes infrastructures introduces several technical challenges. This is where Link-Layer Secure connectivity for Microservice platforms (L2S-M) comes into play.

L2S-M is a networking solution originally developed within the NEMO project that enables the creation and management of isolated virtual link-layer networks in Kubernetes. Unlike traditional approaches based on network policies or service meshes, L2S-M introduces a programmable networking layer that operates independently of the underlying Container Networking Interface (CNI), providing additional flexibility for managing workload connectivity.

At its core, L2S-M allows Kubernetes workloads to connect to isolated virtual networks, regardless of the physical nodes where they are deployed. These networks are represented as Kubernetes resources, meaning that they can be created, managed, and consumed through standard Kubernetes mechanisms. This approach simplifies the integration of advanced networking capabilities into cloud-native environments without requiring modifications to the applications themselves.

To achieve this functionality, L2S-M relies on a programmable overlay network composed of virtual link-layer switches distributed across the Kubernetes cluster. These switches are interconnected through Virtual Extensible LAN (VXLAN) tunnels, allowing workloads running on different nodes to communicate as if they belonged to the same local network. Multiple virtual networks can coexist within the same infrastructure while remaining logically isolated from one another.

However, creating virtual networks is only part of the solution. L2S-M also incorporates Software-Defined Networking (SDN) mechanisms to control how traffic flows through the infrastructure. Through an SDN controller, forwarding rules are dynamically installed in the virtual switches, ensuring that traffic is distributed according to the virtual networks and workloads associated with them. This programmable approach also opens the door to advanced traffic engineering capabilities, such as optimising communication paths or directing traffic through specific network functions.

Beyond connectivity within a single Kubernetes cluster, L2S-M also supports the interconnection of workloads deployed across different clusters. This functionality is particularly relevant for distributed cloud-edge infrastructures, where services may be deployed across geographically separated environments or different administrative domains.

To enable inter-cluster communications, L2S-M introduces Network Edge Devices (NEDs), which act as programmable network elements connecting different Kubernetes infrastructures through VXLAN overlays. These devices are coordinated by an Inter-Domain Connectivity Orchestrator (IDCO), which extends the SDN control mechanisms to manage connectivity between clusters. Within CyberNEMO, L2S-M builds upon the networking capabilities developed in the NEMO project to provide the virtual micro-segmentation mechanisms required by the Zero Trust Network Access (ZTNA) framework. However, CyberNEMO takes these capabilities a step further by extending L2S-M to support the dynamic application of network security policies within individual micro-segments. This evolution enables more granular control over workload communications, complementing the isolation provided by virtual networks with programmable traffic restrictions. In our next post, we will explore how these new capabilities enhance L2S-M and contribute to securing communications in distributed Kubernetes environments.

Read More

CyberNEMO Presents Path Verification Research at IEEE ISCC 2026

CyberNEMO research on secure network path verification was presented at the 31st IEEE Symposium on Computers and Communications (ISCC 2026) in the Algarve, Portugal. Mattin A. Elorza Forcada, from Telefónica Innovación Digital, presented the paper “Enhanced Path Verification Mechanism with Open-Source Solutions”, co-authored with Javier Velázquez Martínez and Antonio Pastor.

Bringing verifiable trust to network paths

Securing communications involves more than protecting the data exchanged between two endpoints. In distributed environments, it is also necessary to verify that packets traverse the network nodes required by the intended routing or security policy.

This is the challenge addressed by Proof of Transit (PoT), one of the components of CyberNEMO’s Zero Trust Network Access (ZTNA) solution. Path verification provides evidence about the route taken by traffic, extending verification beyond users and devices to the network paths themselves.

The presented work focuses on strengthening path verification mechanisms and validating the proposed approach through integration with open-source solutions. By connecting research with practical implementation, it supports the assessment of these mechanisms in programmable networking environments.

Sharing research with the technical community

Participation in IEEE ISCC 2026 provided an opportunity to present CyberNEMO’s research, exchange perspectives with the technical community, and discuss challenges in security verification and secure applications.

Through this contribution, Telefónica Innovación Digital supports CyberNEMO’s dissemination activities, sharing the project’s results with a wider audience and encouraging discussion around verifiable trust in distributed networks.

Explore the research

Further details are available in “Enhanced Path Verification Mechanism with Open-Source Solutions”, by Mattin A. Elorza Forcada, Javier Velázquez Martínez and Antonio Pastor.

Access the paper on Zenodo.

Read More

Thales in CyberNEMO

Thales, present in 68 countries and employing more than 81,000 people, is a global leader in advanced technologies across aerospace, aeronautics, defence, digital security, cybersecurity, and biometrics. Thales has become a key multinational player in protecting citizens, strengthening state resilience, and enabling business success. Its main areas of expertise include:

  • Aerospace / Aeronautics: Thales provides advanced avionics solutions, as well as in-flight entertainment and connectivity systems for both civil and military aviation—enhancing safety, efficiency, and the onboard experience.
  • Defense: Thales is a major industry player, delivering radars, sonars, and optronics for land, air, and naval forces, along with secure communications, cybersecurity, and ISR capabilities (intelligence, surveillance, and reconnaissance).
  • Digital Security and Identity: Thales is a pioneer in digital identity and security, offering solutions for secure transactions, identity management, and data protection. Its technologies are used in finance, healthcare, and public administration to ensure the integrity and confidentiality of sensitive data.

CortAIx Labs is a cutting-edge R&D organization dedicated to advancing AI, machine learning, and data science technologies. Its expertise includes AI for defence and security, large-scale data processing, cybersecurity, robotics, and autonomous systems. The CyberNemo project brings together contributors from two of its laboratories.

The first is the VAR laboratory – Vision, Autonomy and Robotics, which develops AI algorithms and multi-agent simulation capabilities for enhanced perception and the autonomy of robotic systems. The second is the cybersecurity laboratory at CortAIx Labs, which focuses on AI security. AI Friendly Hacker is a program dedicated to AI security, covering both offensive and defensive aspects, including robustness, privacy, and intellectual property protection.

Our major contribution to the CyberNemo project is the integration of our open-source component Pybiscus, which enables secure collaborative learning. Thanks to the collaboration with our various partners, we use this component to train AI models to detect anomalies in cybersecurity tasks across the different scenarios addressed by the project.

Read More

Building Trustworthy Security AI #3: Bridging Precision and Meaning with Hybrid Retrieval

In any retrieval-augmented security assistant, the retriever quietly decides what the model is allowed to know. When it fails, the model fills the gap with plausible invention. In cybersecurity, a single invented detail can do real damage: a misremembered CVE, a non-existent patch, or an asset placed in the wrong network segment can mislead mitigation attempts. More relevant to the approaches explored, graph traversal for example captures structure, such as which adversary can reach which server, but it cannot rank free-text relevance. The answer explored was a hybrid retriever. It runs sparse, dense, and graph retrieval in parallel, and merges their output using customized tools designed within the CyberNEMO project. That way, exact matches, semantic matches, and structurally connected entities all have a fair chance to reach the model’s context.

The second lesson was that retrievers can only be as good as what they embed. Early iterations embedded raw node properties and log fragments directly. The results were thin vectors that carried little meaning. CyberNEMO therefore introduced systematic, description-enriched embedding. Every entity in the security property graph received a templated natural-language description, generated from its properties and immediate relationships and then embedded alongside the structured data. Because the same template was applied consistently across all entities, embeddings became comparable. Retrieval quality improved noticeably on the questions asked, mixing the exact identifier with contextual qualifiers. The most important benefit, however, was protection against catastrophic hallucination.

Read More

Building Trustworthy Security AI #2: Persona by Design for Predictable LLMs

Deploying large language models in security operations exposes a hard truth. A model that answers correctly once may answer differently the next time. Identical alerts can be assigned different levels of severities. A phishing sample can be called malicious in one run and suspicious in another. Hence, remediation steps can shift in that order between sessions. In a domain built on repeatable playbooks, that variability can undermine trust.

To this end, CyberNEMO explored strict, versioned personas in its decision support design. Instead of one general-purpose assistant, specialized roles such as a security analyst, Threat Intelligence Correlator, and a Compliance Reviewer were used. Additionally, madate fields, explicit exclusions, fixed decision rubric, output contracts with a fixed template and fallback rules were also defined.

The outcome led to more realistic and stable model outputs across repeated runs on the benchmark set. Outputs became noticeably more consistent in structure, severity grading, and in terminology. The preliminary results in CyberNemo show that disciplined prompt design is one of the most cost-effective first steps toward trustworthy LLM security tooling.

Read More

Building Trustworthy Security AI #1: Connecting the Dots with Graph-RAG for Cyber Defense

Graph-based Retrieval-Augmented Generation (Graph-RAG) is changing how security knowledge reaches large language models. Conventional RAG splits documents into chunks and retrieves them by vector similarity. Graph-RAG instead grounds the model in a structured knowledge graph, where entities such as hosts, user accounts, software versions, CVEs, firewall rules, and MITRE ATT&CK techniques are linked by explicit relationships. This approach is explored in the CyberNEMO project with promising results in actionable retrieval. It permits a shift from merely finding texts that are similar, to finding connections that are relevant. Take the query “Which internet-facing assets could an adversary reach by exploiting CVE-2024-XXXX”? Flat vector search cannot answer it reliably, because the answer is not in any single document. A credible answer emerges only by traversing several hops: from the vulnerability to the affected package, to the server running it, to the subnet, to the identity with lateral-movement privileges. Graph-RAG turns that traversal into the context the model reasons over. Its answers can be traced back through the graph and checked by an analyst.

The property graph model is what makes this work for a customized enterprise infrastructure. Nodes and edges are typed, and both can carry key-value attributes. So, an edge such as (:Workstation)-[:AUTHENTICATES_TO {protocol:”Kerberos”, first_seen:…, risk_score:0.82}]->(:DomainController) captures not just that a relationship exists, but its context, time, and weight. The solutions in CyberNEMO explored the benefits of this level of expressiveness for organizations whose environments are unique by design. Notwithstanding the benefits, several milestones must still be reached before the target performance is achieved. Graph construction remains the first hurdle, where extracting entities and relations from unstructured threat intelligence with LLMs introduces noise, and entity resolution is still non-trivial. Schema governance is the second. Ontologies must evolve as the infrastructure changes without breaking downstream queries, which argues for alignment with standards such as STIX 2.1 and the Unified Cybersecurity Ontology. Scale and latency matter too: multi-hop traversals over graphs with billions of edges must return within seconds an incident responder can afford. Finally, the field lacks standardized benchmarks for judging whether Graph-RAG outputs are complete and faithful in security contexts.

Read More

From AI-Assisted Assessment to Continuous Assurance: The New Risk Management Model
AI support is not enough on its own

Artificial intelligence can analyse logs, correlate vulnerability information, identify anomalies and support mitigation decisions at a scale that would be difficult to achieve manually.

D1.2 already established AI as both an object of risk management and a tool supporting risk processes. D1.3 advances this model by introducing a more explicit framework for AI-empowered risk automation, including assurance of the AI systems performing risk-management activities.

The emergence of the assessor AI

An AI system may appear in risk management in two distinct roles. The assessed AI is the operational system whose security, behaviour and potential consequences must be evaluated. The assessor AI is the tool that supports or automates the assessment itself.

This distinction is fundamental. If an AI model determines asset criticality, classifies threats, prioritises vulnerabilities or recommends controls, errors in that model can directly affect risk decisions. The assessor must therefore be governed with the same discipline expected of other decision-support systems.

What AI can support

AI-relevant capabilities span the risk-management lifecycle: extracting information from structured and unstructured sources, discovering assets and dependencies, identifying missing records, correlating vulnerabilities with threat intelligence, recognising abnormal behaviour, estimating risk, supporting treatment selection, generating reports and monitoring changes in risks, controls and assumptions.

The potential benefit is a transition from periodic assessment to continuous risk awareness. Automation is valuable, however, only if the result remains trustworthy.

Risk information is a governed product

The updated methodology places greater emphasis on the risk management file as an organised collection of evidence, records and references. It may include asset descriptions, assumptions, vulnerability information, threat intelligence, logs, incidents, risk evaluations, treatment decisions, control-effectiveness evidence, uncertainty measurements, data-quality indicators and review records.

Assumptions, uncertainty, quality measurements and metadata are often not represented explicitly in cybersecurity information models. Their inclusion is necessary because an AI-generated result is only as defensible as the evidence and conditions behind it.

Quality becomes part of the risk calculation

A risk assessment can fail even when the calculation itself is correct. An accurate model working on incomplete asset data may miss critical exposure. Current vulnerability intelligence linked to an outdated topology may produce incorrect priorities. A recommendation generated from an invalid assumption may appear credible while being operationally unsuitable.

Quality characteristics such as completeness, accuracy, relevance, freshness, latency, consistency, provenance, traceability and fitness for the intended decision therefore become part of the evidence used to determine whether an assessment is fit for use.

Managing assumptions and uncertainty

Continuous risk management operates under incomplete knowledge. Threat actors adapt, systems change, models drift and dependency information is rarely perfect. Assumptions concerning system boundaries, threat relevance, control effectiveness, data completeness and human oversight must be explicit and monitored.

Uncertainty must also be connected to decisions. A risk that appears acceptable as a single point estimate may cross an unacceptable threshold when uncertainty in probability and consequences is considered. Treatment may therefore address the underlying risk or reduce uncertainty by improving data and system knowledge.

Assurance of the automation layer

The more responsibility assigned to an assessor AI, the stronger its assurance requirements become. An organisation must establish which data and model version produced an output, what assumptions and thresholds applied, whether the output was reviewed, how uncertainty was represented and what decision followed.

Operational logging connects model versions, inputs, outputs, errors, decisions and resulting actions. It supports monitoring, post-event investigation, auditability and re-evaluation.

Human oversight as decision control

Human involvement is part of the risk-control architecture. AI may prepare information, recommend an action or execute a pre-approved low-impact response, while a human validates actions with significant operational, legal or reputational consequences.

The central question is not whether a process is manual or automated. It is whether decision authority, escalation criteria and accountability remain explicit.

From assessment to continuous assurance

A risk assessment is no longer treated as a document produced at a single point in time. It becomes a continuously maintained body of evidence linked to system evolution, operational monitoring, incident response and control validation.

The resulting feedback loop is observe, assess, decide, treat, verify, learn and reassess. AI can accelerate each stage; governance, evidence quality, validation and human oversight determine whether that acceleration can be trusted.

The key lesson

AI can make risk management more current, scalable and responsive, but it also creates a second layer of risk: the reliability of the system performing the assessment.

TAKEAWAY Continuous assurance requires organisations to govern not only the systems being assessed, but also the data, models, assumptions and automated decisions used to assess them.

Editorial basis:  CyberNEMO D1.3. Public-facing version with no sensitive operational details.

Read More

Keeping the Continuum Safe: Introducing CASB, CyberNEMO’s Security “Dispatcher”

As critical infrastructures increasingly rely on interconnected devices, cloud platforms, and edge computing, one question keeps coming up: when something suspicious happens somewhere in that chain, who decides what to do about it and how fast?

Inside the CyberNEMO project, that job belongs to the Continuum Access Security Broker (CASB), a component designed and developed by SPACE Hellas.

What CASB Actually Does

Think of CASB as a dispatcher for security incidents, the same role a control room plays at a power plant or a water treatment facility when something goes wrong, just applied to cybersecurity instead of physical operations. Across a modern IT environment spanning cloud, edge devices, and everything in between many different tools are constantly watching for suspicious behavior: unusual logins, strange network traffic, unexpected system activity. On their own, these are just incoming signals; someone, or something, still has to decide what to actually do about each one.

That’s where CASB comes in and, like any good dispatcher, it can respond in two ways.

Most of the time, CASB reacts automatically: it takes incoming alerts, matches them against known attack patterns, and immediately dispatches the appropriate response for example, restricting network access to an affected device or service. A set of guardrail policies acts as a safety net on this automatic path, stopping any action that could affect sensitive, core parts of the underlying infrastructure itself.

Alongside that, a security operator can also step in directly and dispatch a mitigation themselves through the CASB dashboard (based on Airflow software) useful when a situation calls for human judgement rather than an automatic reaction. Whichever path is used, every action is logged and visible to the team in real time, so nothing happens without a clear, traceable record of what was done and why.

This combination is deliberate. In an active incident, low-risk, well-understood responses can be dispatched instantly without waiting on a person while operators retain the ability to step in and dispatch a response themselves whenever a situation calls for their judgement, with full visibility into everything that happens either way.

Why This Matters for Critical Infrastructure

CyberNEMO’s mission is to strengthen cybersecurity across sectors like energy, water, healthcare, media, and finance sectors where a slow or wrong response to a cyberattack can have real-world consequences. CASB doesn’t work alone: it’s one piece of a larger CyberNEMO security framework, coordinating closely with other components that detect threats, enforce network policies, and maintain an overall picture of the system’s security posture.

By centralizing how response decisions are made rather than leaving each tool to act independently CASB aims to make security responses more consistent, auditable, and easier to manage across large, distributed environments.

Where Things Stand Today

CASB’s architecture is fully designed, and the core building blocks automatic detection-to-response processing, safety guardrails, and the operator dashboard have been implemented and are running in CyberNEMO’s experimental lab infrastructure. The team is now working on broadening guardrail coverage and hardening the component ahead of the next stage: validation within CyberNEMO’s real-world pilot sites.

As with any research project, this is progress-in-motion rather than a finished product and we’ll share concrete results from pilot testing as they become available, rather than before.

What’s Next

Over the coming months, the CASB team at SPACE Hellas will focus on integrating the component more tightly with the rest of the CyberNEMO platform and preparing it for pilot deployment. We’ll follow up with a more detailed look at how CASB performs once it’s tested in a live environment.

Read More

SAAM: Turning Isolated Cyber Incident Reports Into Pan-European, Coordinated Defense

Modern cyberattacks don’t respect organizational boundaries, neither organizations are operating in isolation from each other. A breach at an energy provider can ripple into telecoms, finance or healthcare within hours. Yet, most organizations still defend themselves in isolation, filing incident reports through manual, paper-based processes that arrive too late to help anyone else.

SAAM was built to change that. SAAM is a collaborative platform for sharing cyber threat intelligence, assessing systemic risk, and coordinating incident response across Critical Infrastructures (CIs) throughout Europe, realizing in practice the share-to-benefit paradigm.

Instead of static, form-based notifications, SAAM enables continuous, machine-readable and explainable threat intelligence exchange, aligned with the EU’s NIS2 Directive, the Cyber Resilience Act (CRA), the AI Act, and the Critical Entities Resilience (CER) Directive.

How the Platform Works

At its core, SAAM is a centralized but distributed, multi-tenant, event-driven platform built around a simple principle: organizations get more value out of the system the more they contribute to it, forming a pan-European “knowledge sharing” ecosystem.

Here’s the flow:

  1. Ingestion: Distributed Critical Infrastructure operated CyberNEMO installations generate threat intelligence structured to SAAM’s own STIX 2.1 data model and send it through TAXII 2.1 to SAAM.
  2. Analysis: Everything moves through an Apache Kafka event-streaming backbone into the Systemic Risk Analysis Engine (SRAE), which enriches each event using severity, confidence, and mappings to the MITRE ATT&CK and D3FEND frameworks, identifying cascading effects and potential coordinated attacks.
  3. Governed sharing: The Sharing Engine applies policy- and Traffic-Light-Protocol-driven distribution rules based on impact scope, sector, geography, and membership in “Trusted Circles” before pushing enriched alerts out to the right stakeholders, organized by sector, country, cross-border region, or the whole of Europe.
  4. Knowledge retention: SAAM insights and findings are stored in a pan-European Knowledge Base and made accessible to its user base through a web-based Visualization Environment.

Security is baked in throughout as SAAM adopts Zero-Trust principles via a Keycloak-based Identity Management System (IMS), enforcing OAuth 2.0, OIDC, and SAML 2.0 across every component.

Built for Different Users, Different Needs

SAAM is designed around four distinct roles:

  • Cybersecurity Experts get a personalised view of their organisation’s threat exposure alerts, a submission tracker, a STIX viewer, and access to the shared knowledge base.
  • CTI & Risk Analysts work across sectors and borders to spot threat trends invisible at the level of a single organisation, mapping activity to MITRE ATT&CK and producing human-readable risk assessments.
  • Cybersecurity Authorities — national CSIRTs and sector ISACs — get a bird’s-eye view across sectors for cross-border situational awareness.
  • System Administrators manage the platform itself: infrastructure health, identity and access management, onboarding new partners, sharing policies, and audit logs.

Explainable AI at the Center

Predicting how a threat might arise or an attack cascade from one Critical Infrastructure to another is only useful if humans can understand why the system reached that conclusion.

SAAM’s Systemic Risk Analysis Engine combines several modelling approaches: LSTM networks for tracking long, multi-stage attack sequences, Transformer variants (Informer/Autoformer) for spotting complex patterns in parallel, and an optional Graph Neural Network layer that models how risk propagates across interconnected infrastructures.

Every prediction is made explainable using SHAP and LIME, with a large language model translating the technical output into plain-language narratives for human operators.

This isn’t just a nice-to-have; it directly supports the AI Act’s requirements for transparency and human oversight, while an anonymization layer keeps the system aligned with GDPR data-minimization principles.

Built With Regulation in Mind, Not as an Afterthought

SAAM’s cloud-native and modular architecture is designed to evolve alongside the harmonized regulatory objectives still being developed for the AI Act and CRA, while already supporting NIS2 incident reporting, CER risk assessment, and GDPR data-protection obligations.

More than that, SAAM follows the CyberNEMO Risk Methodology to work at the broadest possible tier of risk propagation from individual products and organisations, up through value chains, to society-level risk, closing the loop on how risk moves between interdependent organizations linked by sector or geography.

That’s the core reason CyberNEMO chose a federated design over a centralized one: risk doesn’t respect a single organization’s walls, so the platform that tracks it can’t either.

What’s Next

By pairing standardized, explainable threat-intelligence exchange with a trust-based sharing model, SAAM offers a concrete path away from isolated incident notification and toward proactive, coordinated cyber-defense across Europe.

Future work includes real-world pilot validation across energy, water, agriculture and healthcare Critical Infrastructures, along with continuous alignment as harmonized EU standards mature.

Read More

CyberNEMO and Open Source best practices

The open-source strategy for CyberNEMO is a core pillar of its mission to establish a secure, transparent, and resilient IoT-Edge-Cloud-Data computing continuum. By building upon the open-source foundations of the NEMO project (Next Generation Meta OS), CyberNEMO leverages the Eclipse Foundation ecosystem to ensure professional governance, intellectual property management, and long-term sustainability.

The strategy is designed to accelerate the adoption of its cybersecurity innovations, ranging from Zero-Trust Network Access to AI-driven threat detection, by making them accessible to a broad community of developers and stakeholders.

This commitment to an open-source model is driven by following open-source best practices, establishing clear licensing, open sourcing core components, maintaining thorough documentation, actively contributing to community building, participating in industry events, and hosting dedicated community events.

The application of the open-source best practices has been translated into statements which have been put into practice in CyberNEMO, among which the following ones can be highlighted:

  • All the CyberNEMO repositories in Research Labs should be public. No work in private is allowed in the public repository, as well as all the issues and discussions should be public.
  • All the CyberNEMO repositories should have a README file, facilitating the engagement and adoption of the CyberNEMO code by external developers.
  • All the CyberNEMO source code files (when the programming language allows it) will have a copyright header, following the defined structure.
  • All the CyberNEMO components will use open-source libraries, and third-party library conflicts or issues will be solved by the developers.
Read More