1. Home
  2. Blog

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

Reading the Hacker’s Mind: How Math Can Predict the Next Step of a Cyberattack

Imagine a burglar trying to break into a high-tech smart home. If you knew exactly which window or door they were going to try next, you could stand right behind it and catch them in the act. In the digital world, this is the ultimate goal of cybersecurity.

Cyberattacks rarely happen completely at random. Hackers usually follow specific, structured paths and methodologies to reach their targets. Today, security experts are developing a groundbreaking tool to exploit this predictability: a Probabilistic Graph. This is an intelligent mathematical model capable of analyzing an ongoing cyberattack in real time and predicting—with high statistical confidence—what the hackers will do next. Building this predictive crystal ball relies on a sophisticated four-stage pipeline that turns messy, scattered internet data into an active defense shield.

Stage 1: Gathering the Digital Clues (Cyber Threat Intelligence)

The first step is all about data collection. Every single day, cybersecurity analysts around the globe publish detailed post-mortem reports on recent cyberattacks. These documents are known as Cyber Threat Intelligence (CTI) reports.

  • The Challenge: The internet is flooded with information, but not all of it is accurate, high-quality, or relevant.
  • The Solution: The pipeline automatically scans the web to harvest these CTI documents. It then puts them through a strict filtering process. Only reports containing concrete, valuable blueprints of actual cyberattacks are kept, while the digital “noise” is discarded.
Stage 2: Decoding the Hacker’s Playbook

Once the high-quality reports are selected, the system dives deep into the text to extract the underlying strategy of the attack.

  • Identifying Techniques: The system automatically extracts the specific technical methods the attackers used.
  • The Importance of Timing: In cybersecurity, order matters. The system tracks the exact chronological sequence of events—noting, for example, that the hackers first sent a phishing email, then stole user credentials, and finally encrypted the database.
  • Standardizing with MITRE ATT&CK: To ensure everyone speaks the same language, each extracted technique is linked to the MITRE ATT&CK framework—a globally recognized dictionary of hacker behaviors.

By the end of this stage, the raw text is transformed into a clean, chronological sequence of standardized technical steps.

Stage 3: Connecting the Dots

A single attack report shows you how one specific hacker thought on a Tuesday. However, when you look at hundreds of attack reports together, you begin to see how the entire hacking ecosystem operates.

In the third stage, the pipeline takes the individual attack sequences extracted from various reports and merges them into a single, unified dataset. This massive library of combined historical data serves as the foundation for the predictive model, teaching it the common habits and behavioral patterns of cybercriminals.

Stage 4: Creating the Predictive Graph

In the final stage, all the combined historical data is transformed into a Probabilistic Graph. Think of this graph as a digital roadmap with multiple interconnected intersections. Each “stop” on the map represents a specific attack technique, and the roads connecting them are weighted with mathematical probabilities.

When a company detects a new cyberattack in progress, their security team inputs the malicious activities they have observed so far. The graph instantly analyzes the data to:

  1. Map out the most common paths historically taken from that specific starting point.
  2. Calculate the statistically most likely next step the attacker will take.
Why This Changes the Game

Historically, cybersecurity has been reactive: organizations waited for an alarm to trip and then scrambled to fix the damage. By utilizing probabilistic graphs, the industry shifts toward predictive defense. Security teams can now anticipate their opponent’s next move, fortify the exact vulnerability about to be targeted, and stop a cyberattack before the worst damage is ever done.

Read More

Beyond the Product: Managing Cyber Risk Across Organisations and Value Chains
Cyber risk rarely stops at the boundary of a system

Traditional cybersecurity assessments often begin with a product, application or infrastructure component. The objective is to identify vulnerabilities, understand relevant threats and determine whether available controls reduce the risk to an acceptable level.

That remains essential, but it is no longer sufficient. Modern critical infrastructures depend on interconnected software, cloud services, edge platforms, operational technology, data providers and external suppliers. A vulnerability originating in one product may affect an organisation’s operations, spread through a supply chain and ultimately influence services delivered to society.

A major development in CyberNEMO D1.3 is the introduction of a structured hierarchy connecting these different risk perspectives.

Three connected views of risk

Product and system risk concerns an individual product, service or system of systems. The assessment examines how vulnerabilities, misconfigurations, design weaknesses or foreseeable misuse could affect intended operation. Its result is an evidence-based description of how a product could contribute to broader operational consequences.

Product-level assessments then become inputs to organisational risk management. At this level, organisations determine what a technical failure means for business processes, service continuity, compliance obligations, financial exposure and operational resilience. Multiple product risks may need to be combined because organisational impact rarely depends on one component alone.

The broadest level concerns value-chain and societal risk. Critical infrastructures rely on shared technologies and services, so a cyber incident in one organisation can trigger disruption elsewhere. Organisational risk postures from federated nodes can be correlated against cross-sector dependencies to detect coordinated threats, cascading effects and supply-chain exposure.

From isolated risks to cascading consequences

A technical vulnerability may initially appear limited to a single asset. Its significance changes when dependencies are considered. A compromised service may affect the availability of a business function, the integrity of information exchanged with partners, the operation of connected infrastructures or another organisation’s ability to deliver an essential service.

The key question therefore changes from how severe a vulnerability is to where the resulting disruption can propagate. This dependency-aware perspective reveals risks that cannot be understood by analysing individual components in isolation.

Why aggregation is difficult

Risk aggregation is not simply the addition of multiple scores. Product assessments may use different scales, assumptions, data sources and levels of confidence. Some describe technical severity; others measure business impact or operational disruption. Combining them without preserving this context may produce a misleading organisational view.

A defensible process must retain the original evidence, assumptions, uncertainty and data-quality information, dependencies among assets and organisations, the rationale for escalation and the controls operating at different levels. Traceability is therefore a prerequisite for moving from product risk to organisational and value-chain risk.

Federated awareness without centralising everything

Cross-organisational risk management requires useful intelligence to be shared without unnecessarily exposing sensitive operational information. In a federated model, each organisation can maintain control of local data and decisions while contributing selected information to a collaborative layer.

The shared layer can identify related attacks, repeated vulnerabilities, shared dependencies and potential cascading consequences that would remain invisible to an isolated participant. The objective is not central control of every local decision, but a common situational picture built from distributed evidence.

Risk management across the lifecycle

D1.3 explicitly connects product risk management with system use, DevSecOps, incident response, certification, governance and pre-market and post-market monitoring. Risk begins before deployment and continues after a system enters operation.

Design decisions, third-party components, deployment conditions, operational changes and newly discovered vulnerabilities may all change the risk posture. Assessment must therefore accompany conception, design, development, verification, deployment, operation, continuous validation, re-evaluation and retirement.

The key lesson

Cybersecurity risk management can no longer stop at the product boundary. Product risks must be translated into organisational consequences and examined against the dependencies connecting suppliers, operators and critical services.

TAKEAWAY A mature cyber-risk model preserves traceability while moving from component-level evidence to organisational decisions and cross-sector situational awareness.

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

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