As cyberattacks become more frequent and complex, organizations are turning to Artificial Intelligence (AI) to defend their digital assets. Standard AI is incredibly fast at spotting patterns, but it often works like a “black box”—it might tell a security team, “This file is a virus,” or “there is a cyberattack going on from this IP addresss” without ever explaining why. For a security professional, a simple “Yes” or “No” isn’t enough. If the AI is wrong, it could block an important company document or block services that the company provides; if it’s right, the team still needs to know how the attacker got in to stop it from happening again. This is where Explainable AI (XAI) comes in.

What is Explainable AI (XAI)?

XAI is a set of tools and methods designed to make the “internal thought process” of an AI understandable to humans. In cybersecurity, XAI doesn’t just detect a threat; it provides a rational justification for its decision.

For monitoring assets and detecting attack instead of just monitoring for “bad” things, XAI helps security teams understand what “normal” looks like. If the AI flags a login attempt as suspicious, XAI can point to specific reasons: “The user is logging in from a new country” or “This account is suddenly accessing 2,000 files it never touched before.” XAI can generate maps or charts showing exactly where a network’s behavior deviated from the norm, helping humans spot the “smoking gun” quickly.

For suggesting mitigations XAI doesn’t just sound the alarm; it helps build the shield. By explaining the nature of the attack, it can suggest the best way to stop it.If the AI explains: “This is a Brute Force attack targeting the HR database,” the suggested action is clear: “Temporarily lock the targeted accounts and require a password reset.”

The Importance of the “User-in-the-Loop”

The most critical part of XAI is that it keeps a human—the User-in-the-Loop—at the center of the decision. Cybersecurity is high-stakes; a mistake could shut down a hospital’s network or a city’s power grid. XAI increases trust, facilitates collaboration and provides accountability.

• Trust and Validation: When an AI can explain itself, a human expert can quickly verify if the alert is a real threat or a “false positive” (a mistake).
• Collaboration: Humans bring “common sense” and context that AI lacks. For example, the AI might flag a large data transfer as an attack, but a human knows it’s just the annual company backup. XAI allows the human to see the AI’s logic, agree or disagree, and teach the system to be better next time.
• Accountability: If something goes wrong, XAI provides a clear “paper trail” showing why a certain decision was made, which is essential for legal and safety audits.

The main differences between standard AI and explainable AI (XAI) are the following. In terms of output standard AI could mention that “High Risk is detected” but explainable AI would say “High Risk: Unusual data flow to an unknown IP is detected.” The human role is highly elevated in XAI from blindly trust or ignore the human to review evidence and take informed action. In addition, the learning process becomes stronger because instead of AI algorithms learning alone the human can provide feedback to refine the AI algorithms.

XAI transforms AI from a mysterious oracle into a transparent partner, ensuring that while the computer does the “heavy lifting” of data analysis, the human stays in control of the final defense strategy.

In the complex architecture of the CyberNEMO meta-Operating System, ensuring secure and reliable communication across the computing continuum is paramount. While high-level security frameworks like Zero Trust Network Access (ZTNA) provide the overarching strategy, the actual heavy lifting of data exchange happens at a much more fundamental level: the network socket.

A network socket is essentially an internal endpoint for sending or receiving data at a single node in a computer network. Think of it as a virtual “plug” that allows two different processes—whether they are on the same machine or across the world—to talk to each other. In a Kubernetes (K8s) environment, which serves as the foundation for CyberNEMO’s deployment, sockets are the critical bridges between containerized microservices. They enable the point-to-point communication necessary for workloads to function as a unified system.

Why Sockets Matter for Network Measurement

Within the WP2 (Work Package 2), the focus is on “Cybersecurity and Privacy by Design”. To achieve this, we cannot rely on surface-level metrics. We need to measure real communication at the socket level. This is where components like White Shark come into play.

Originally developed for the NEMO project, White Shark is a specialized network probe designed to collect and retrieve high-fidelity network data. By tapping into socket communication, White Shark can measure point-to-point metrics—such as latency and throughput—directly between two endpoints. This provides a level of precision that traditional network monitors often miss, as it captures the actual data flow as seen by the applications themselves, rather than just the underlying infrastructure.

From Raw Data to Intelligence: The Role of NADA

Capturing socket-level data is only half the battle; the next step is making sense of it. In CyberNEMO, this data is fed into the Network Anomaly Detection AI (NADA). NADA’s purpose is to identify temporal and contextual anomalies—suspicious patterns in the network traffic that could indicate a security breach.

Securing communication across distributed environments requires more than just strong cryptography, it also demands agility, programmability, and centralized control. Centrally Controlled IPsec (CCIPS) introduces a new way to deploy and manage IPsec tunnels by combining SDN principles with the I2NSF (Interface to Network Security Functions) standard.

What is CCIPS?

Traditional IPsec deployments rely on IKE (Internet Key Exchange) for tunnel negotiation. While robust, IKE can be complex to manage at scale, especially in dynamic environments. CCIPS takes a different approach: it defines an IKE-less model where a central controller provisions, manages, and monitors IPsec tunnels across the network.

This model leverages I2NSF IPsec specifications to provide:

• Standardized interfaces for setting up security functions (e.g., VPNs, firewalls)

• Centralized policy enforcement and lifecycle management of tunnels

• Application-driven deployment of secure communication channels

• The result is a flexible and interoperable framework for secure networking in modern architectures.

How it works?

The CCIPS architecture is built around two main roles:

CCIPS Controller

The central component that manages requests from applications. Translates high-level security requirements into tunnel configurations based on the IKE-less data model. Manages the lifecycle of tunnels via YANG notifications, ensuring that tunnels are created, monitored, and removed correctly.

CCIPS Agents

Network devices capable of terminating one end of an IPsec tunnel. Receive configuration parameters directly from the controller. Deploy the requested tunnels, enforce security policies, and report status updates. Generate notifications back to the controller for lifecycle management.

Why this matters

The CCIPS architecture provides significant advantages over traditional IKE-based deployments:

Centralized control: Policies and lifecycle management are coordinated through a single controller.

Scalability: Simplifies deployment in multi-cluster or multi-domain environments.

Interoperability: Built on I2NSF standards, ensuring consistency across different implementations.

Auditability: Lifecycle events and tunnel operations are logged and verifiable.

In short, CCIPS modernizes IPsec by making it programmable, centrally managed, and lifecycle-aware, an essential step toward secure and agile communication infrastructures.

In CyberNEMO, we’re building a Zero Trust Network Access (ZTNA) solution where every decision is backed by verifiable evidence. Beyond authenticating users and devices, we also need to ensure that the network paths packets take can be trusted. That’s where the Proof of Transit (PoT) component comes in.

What is the Proof of Transit (PoT)?

PoT, is a path verification mechanism. Its purpose is to guarantee that a packet has followed a predetermined route through specific nodes, providing security, traceability, and regulatory compliance.

This capability is essential in environments such as:

• Service Function Chaining (SFC) with NFV

• 5G and beyond network architectures

• Critical infrastructure where packet order and integrity must be preserved

PoT ensures that packets not only arrive at their destination but also travel through the expected, authorized sequence of nodes.

How it Works?

The IETF PoT draft defines two main approaches, both based on Shamir Secret Sharing (SSS):

1.Polynomial-based distribution:

• A polynomial of degree n–1 (where n is the number of nodes) is generated.

• Each node receives a point on the polynomial, used to verify its participation in the path.

2.Enhanced entropy with a public polynomial:

• An additional polynomial (with no constant term) is introduced.

• This is combined with a random value (RND) at the ingress node, creating a cumulative value (CML).

• The value travels across all nodes, and the final node verifies it against the expected result, ensuring no tampering occurred.

Ordered Proof of Transit (OPoT)

PoT has naturally evolved into OPoT (Ordered Proof of Transit), which not only validates the nodes traversed but also guarantees the correct sequential order. This prevents reordering attacks and is particularly critical in Real-time, sequence- sensitive systems.

OPoT achieves this by using symmetric masks shared between contiguous nodes,
ensuring both authenticity and ordering of packets.

Why this matters for ZTNA

ZTNA is about “never trust, always verify.” Proof of Transit extends this principle to the network fabric itself. By integrating PoT and OPoT into CyberNEMO, we:

• Ensure packets take only the approved, policy-compliant paths

• Detect tampering, misrouting, or reordering of traffic

• Provide strong traceability and auditability of packet flows

• Meet compliance and regulatory requirements for sensitive environments

In other words, PoT brings verifiable trust to packet transit, strengthening the Zero Trust foundation of CyberNEMO.

In CyberNEMO, we’re building a Zero Trust Network Access (ZTNA) solution where every access decision is based on verifiable evidence. One of the core building blocks of this architecture is the Notary component, powered by our Transparent Notary Service (TNS).

What is the Transparent Notary Service (TNS)?

The TNS is essentially a digital notary for network evidence. Its job isn’t to decide whether a piece of evidence is good or bad, but to make sure that once evidence is registered, it stays immutable, timestamped, and cryptographically verifiable.

The TNS uses a lightweight append-only ledger. Each signed statement (such as a configuration attestation, event log, or policy proof) is stored in an immutable data structure like a Merkle tree. This allows anyone to verify inclusion and consistency without having to trust the notary itself.

How it works

1. Issuers sign statements using IETF’s COSE (CBOR Object Signing and Encryption) with algorithms like ECDSA or EdDSA.
2. The Notary logs the statement, storing it in the append-only ledger.
3. A receipt is generated that acts as proof of inclusion
4. A Transparent Statement is generated including the original statement along with its receipt
5. Relying parties can verify the statement’s authenticity and timestamp independently using the TNS public key

This design ensures that if someone tries to tamper with evidence or hide a log entry, it becomes immediately detectable.

Why this matters for ZTNA

ZTNA is all about “never trust, always verify.” But verification needs to be trustworthy too. By introducing a tamper-evident, verifiable notary into CyberNEMO, we:

• Create strong audit trails for security events.

• Improve accountability and compliance by preserving evidence.

• Allow independent verification of access decisions without centralizing trust.

In other words, the Notary helps make our Zero Trust architecture provably trustworthy.

Zero Trust Principles in CyberNEMO: Building security by Design

Zero Trust has become one of the most important paradigms in modern cybersecurity. At its core, Zero Trust means no implicit trust; everything must be verified, every time. Every user, device, application, and service must prove its legitimacy before gaining access to resources, regardless of whether it’s inside or outside the corporate network.

In CyberNEMO, we’ve embraced these principles as the foundation of our ZTNA (Zero Trust Network Access) solution. The goal is to reduce the attack surface, prevent lateral movement, and enforce consistent security controls across all environments.

Zero Trust Principles

In CyberNEMO, we use the following Zero Trust principles as our architectural baseline:

• Identity verification and strong authentication to ensure that only legitimate users and devices gain access.

• Least privilege access enforcement, granting the minimum level of permissions necessary to perform specific tasks.

• Micro-segmentation of networks and services to prevent unauthorized movement within the system.

• Continuous monitoring and risk assessment to adapt dynamically to evolving threats and anomalies.

• Data-centric security to protect sensitive information wherever it resides or travels.

How CyberNEMO implements them

Cybernemo’s ZTNA solution was built with these ideas from day one:

• Micro-Segmentation with L2S-M: Built on the NEMO-developed Link-Layer Secure connectivity for Microservice platforms, L2S-M provides secure, dynamic segmentation across multi-cluster environments, overcoming the limitations of conventional network segmentation solutions.

• Advanced Metrics & Telemetry: Using the ALTO protocol, combined with insights from BGP-LS, SDN controllers, and inventory systems, CyberNEMO ZTNA exposes abstract, real-time network metrics. These insights enable orchestration and deployment decisions that are aware of current network conditions and can react adaptively.

• Secure and Verifiable Data Plane: Proof of Transit (PoT) is incorporated to validate packet flow integrity and sequence, providing traceability, regulatory compliance, and resilience against routing attacks or traffic manipulation.

• Identity & Evidence Management: CyberNEMO adopts Distributed Ledger Technologies (DLTs) to ensure immutable, auditable records of access and configuration events.

  1) The Distributed Identity Manager (DID Manager) issues and validates decentralized, verifiable credentials, enabling federated identity management.

  2) The Transparent Notary Service (TNS) acts as a cryptographic notary for signed statements, preserving their integrity, timestamp, and origin authenticity. This allows any party to independently verify security events, configuration attestations, and policy decisions without having to trust the notary itself — enhancing accountability and auditability.

• Policy Enforcement & Anomaly Detection: Network policies are enforced dynamically, while real-time anomaly detection mechanisms help mitigate threats as they emerge.

From Principles to Practice

Zero Trust is more than a security concept, it represents a fundamental shift in how networks are designed and operated. By embedding these principles directly into its architecture, CyberNEMO delivers a verifiable, adaptive, and resilient ZTNA solution for modern distributed environments.

With strong identity management, cryptographic evidence, micro-segmentation, and continuous monitoring, CyberNEMO provides not just access control but confidence in every access decision.

In short, CyberNEMO transforms Zero Trust from a guiding principle into a practical, measurable, and future-ready security architecture, enabling secure connectivity, prevent lateral movement, and build a trustworthy foundation for critical communications.