Network Security Archives - Telnet Networks

Understanding Suricata: The Open-Source Engine Inside Your Security Stack

There is a good chance Suricata already runs somewhere in your network, even if nobody on your team has ever typed its name. So what is Suricata, and why does so much of the security industry depend on it?

It sits inside open-source firewalls, behind AWS Network Firewall’s stateful rules, inside free security platforms used by SOCs and classrooms, and at the core of several commercial network detection and response (NDR) products. For an engine that so much of the industry relies on, it gets surprisingly little explanation.

In one sentence: Suricata is an open-source engine that reads network traffic and does three jobs with it. It raises alerts when traffic matches known threats (intrusion detection, or IDS), it can block that traffic when placed inline (intrusion prevention, or IPS), and it writes a detailed, structured record of what happened on the network whether anything matched or not (network security monitoring, or NSM). It is owned by a non-profit, the Open Information Security Foundation (OISF), and released under the GPL.

This post is for technologists who are new to Suricata and the tools built on it. We’ll cover where it came from, what sets it apart, what it is not, who uses it, and why we think it is well placed to remain a foundational security technology. We’ll also cover the part most explainers skip: Suricata is only as good as the traffic you feed it.

Where Suricata came from

In 2009, Snort had been the default open-source IDS for about a decade. It was capable, widely deployed and, by then, owned by a commercial company. It was also built around a single processing thread at a time when multi-core servers and 10 Gbps links were becoming normal.

The OISF was set up to build a next-generation alternative. Its early funding came from the US Department of Homeland Security’s science and technology directorate and the US Navy’s Space and Naval Warfare Systems Command, alongside a group of private security companies; OISF’s then-president put the initial DHS funding at roughly US$1 million. Two design choices stood out from the start. Suricata would read the same rule language as Snort, so existing rulesets would carry over, and it would be multi-threaded from day one.

Suricata 1.0 shipped in July 2010 under the GPLv2. Not everyone welcomed it: Snort’s creator publicly dismissed it as a taxpayer-funded imitation, and the early coverage framed it as a contest between the two. Snort remains under active development at Cisco, and the two engines still share a rule heritage, but their rulesets have since diverged (Snort’s compiled shared-object rules, for example, don’t load in Suricata). More importantly, Suricata went in directions an IDS of that era was never expected to go.

Over time the funding model shifted from government grants to an industry consortium. Today OISF’s Platinum members are AWS and Proofpoint, and its Gold members include France’s national cyber security agency (ANSSI), Arista, Corelight, Cylera, ENEA, Juniper, NEOX Networks, Red Piranha and Verizon. Consortium members receive a non-GPL licence to the engine, which is one reason Suricata turns up inside so many commercial products. Development itself remains a community effort.

Timeline of major Suricata releases from 1.0 in 2010 to 8 in 2025: port-independent protocol detection, file extraction and TLS analysis, EVE JSON output, xbits, Rust parsers, SMB support, datasets, HTTP/2, the now end-of-life version 7, and firewall mode in version 8.

As of this writing the current release is Suricata 8.0.7, from September 2026. Suricata 7, released in 2023, has reached end of life.

Two recent milestones have a Canadian thread. Moving Suricata’s HTTP parser (LibHTP) to Rust, one of the headline changes in version 8, was credited by OISF as a joint effort between Philippe Antoine of the Suricata team and Todd Mortimer of the Canadian Centre for Cyber Security. And SuriCon, the project’s annual conference, came to Montréal in November 2025, the year OISF marked its fifteenth anniversary.

What Suricata actually does

Three jobs, one engine.

Detection (IDS). Suricata compares traffic against rules. A rule describes something to look for and what to do when it’s found. Here’s a simple one:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Example: PowerShell user agent in outbound HTTP"; flow:established,to_server; http.user_agent; content:"PowerShell"; nocase; classtype:policy-violation; sid:1000001; rev:1;)

Read left to right: alert on HTTP traffic going from inside the network to outside, on an established connection heading to the server, where the User-Agent header contains “PowerShell”. Notice what the rule doesn’t have to do. It doesn’t say which port HTTP is on, and it doesn’t parse HTTP itself. Suricata has already identified the protocol and split it into fields; the rule just asks for the field it cares about.

Most organizations don’t write most of their rules. Proofpoint’s Emerging Threats team publishes ET Open, a free, BSD-licensed ruleset, and ET Pro, a commercial one. Other publishers, from abuse.ch to Secureworks to Stamus, ship rulesets that plug into Suricata’s own update tool, suricata-update.

Prevention (IPS). Placed inline, Suricata can drop traffic instead of only reporting it. Suricata 8 adds an experimental firewall mode: a default-deny policy in which the ruleset defines what is allowed through, written in the same rule language.

Monitoring (NSM). This is the job newcomers tend to underestimate. Even when no rule fires, Suricata can log every DNS query and answer, every TLS handshake, every HTTP transaction, SMB file operations, flow records, extracted files and full packet capture. All of it comes out in one JSON format, called EVE. That record exists whether or not anything was malicious. Months later, when someone asks whether any host talked to a particular domain in June, the answer is in the records, not in an alert that never fired.

What sets Suricata apart

It identifies protocols by their content, not their port. From its first release, Suricata looked at the opening bytes of each conversation to work out what protocol it was. Malware that ran HTTP to a command-and-control server on an unusual high port was still recognized as HTTP, and still matched HTTP rules. It sounds obvious now. In 2010 it meaningfully raised detection rates.

Rules ask for fields, not bytes. Because Suricata parses protocols itself, a rule can ask directly for a TLS server name, a DNS query, an HTTP user agent or an SMB file name. Rules are simpler to write, easier to read and faster to evaluate.

It is built to scale across cores. Multi-threading was the founding design goal. Suricata spreads work across CPU cores and supports high-performance capture methods including AF_PACKET and DPDK on Linux, with Napatech and PF_RING capture available as plugins. Throughput still depends heavily on the ruleset, the traffic mix and the hardware, so be skeptical of any single performance figure quoted without them.

Alerts and records come out of the same engine, in the same schema. Before EVE, an IDS alert was a terse record of addresses, a payload snippet and a rule ID. Suricata attaches protocol context to each alert and writes it in the same JSON as its protocol logs, so an analyst can pivot from an alert to everything else that host did. It also supports Community ID, a common flow hash that lets you join Suricata records with Zeek logs and other tools that use it. EVE drops into Elastic, Splunk, OpenSearch or almost any SIEM without a custom parser.

It speaks a long list of protocols, including industrial ones. Beyond the web and email protocols you’d expect, Suricata parses SMB, Kerberos, LDAP, RDP, SSH, SNMP, SIP and MQTT, plus the industrial protocols Modbus, DNP3 and EtherNet/IP. It computes client fingerprints such as JA3, JA4 and HASSH. That breadth matters at Canadian utilities and transit agencies, where operational technology (OT) networks are exactly the places a security agent will never be installed.

It is moving to memory-safe code. An engine whose job is to parse hostile input all day is itself an attack surface. Since version 4.0, new protocol parsers have been written in Rust, and version 8 moved more of the core across, including the HTTP parser.

Nobody can close it. Suricata belongs to a non-profit, its code is GPL-licensed, and its detection logic is a published, readable language. A vendor can build on Suricata, but no vendor can take it away. And when a Suricata rule fires, you can read exactly why.

Its rule language has become shared vocabulary. ET Open is written for it. AWS Network Firewall accepts stateful rules in Suricata-compatible syntax and passes them to Suricata for processing. A team that learns to read Suricata rules can carry that skill across products and clouds.

What Suricata is not

Being clear about the limits is what makes the strengths credible.

It is an engine, not a product. Suricata has no console, no case management and no long-term storage. On its own it produces a stream of JSON. Somebody has to collect it, store it, search it, tune the rules and decide what matters. That gap is the reason an entire ecosystem exists around it.

Signatures find what someone has already described. Rules and indicator lists catch known techniques and known infrastructure very well. Spotting new behaviour, such as a host that has never used SMB suddenly touching fifty file shares, takes analysis on top of the records: scripting, statistics, machine learning, or an NDR platform’s own detection layer. This is also the honest answer to the common Suricata vs Zeek question. Zeek is a scriptable network analysis framework built around rich logs and custom logic; Suricata is a signature engine that also produces rich logs. They overlap, and plenty of teams run both. Security Onion and Corelight both do.

It cannot read encrypted payloads. Suricata analyzes TLS handshakes, certificates and client fingerprints rather than decrypting traffic. That metadata is valuable, but it is shrinking at the internet edge: with TLS Encrypted Client Hello, even the server name is disappearing from the wire, as we covered in our post on what network tools can still see under ECH. Internal protocols such as SMB, Kerberos and LDAP, where much of an attacker’s lateral movement happens, remain far more visible.

It needs maintaining. Suricata publishes security releases regularly, and 2026 has seen an unusual volume of them. OISF attributes the record number of vulnerability reports behind its September release to the rise of AI-assisted code analysis. That is a sign of a healthy project under scrutiny, but it means anything built on Suricata needs to track upstream releases closely.

It is only as good as what it sees. Dropped packets, one-sided flows and oversubscribed SPAN ports quietly blind it. We come back to this below, because it is where most deployments go wrong.

The ecosystem: what runs on Suricata today

Because Suricata is an engine, most people meet it inside something else. A cross-section:

Tool	Type	How it uses Suricata
Security Onion	Free and open platform	Suricata generates the platform’s network intrusion detection alerts and can also produce protocol metadata and full packet capture
Malcolm	Open source, from Idaho National Laboratory with CISA	Combines Suricata alerts with Zeek logs and Arkime packet capture, with an emphasis on industrial control system protocols
OPNsense	Open-source firewall	Its intrusion detection and inline prevention system is based on Suricata (pfSense offers Suricata as an add-on package)
Assemblyline	Open source, from the Canadian Centre for Cyber Security	The Cyber Centre’s malware triage platform runs Suricata as one of its analysis services, pulling rulesets automatically
Clear NDR Community	Open source, from Stamus Networks	A turnkey Suricata-based NDR distribution, formerly known as SELKS
AWS Network Firewall	Cloud service	Stateful rule groups are written in Suricata-compatible syntax and processed by Suricata
Corelight	Commercial NDR	Runs Suricata alongside Zeek on its sensors, with a shared ID that lets analysts pivot from a Suricata alert into Zeek’s logs
Stamus Clear	Commercial NDR	Builds a detection, investigation and evidence layer on top of Suricata (more below)
Rulesets	Free and commercial	Proofpoint ET Open and ET Pro, Secureworks, abuse.ch and others publish Suricata rulesets

Underneath that, a long list of networking and security vendors embed Suricata in their own products, often without naming it on the datasheet. That is part of the point. Suricata has become common infrastructure, in the way Linux is common infrastructure.

A closer look: Stamus Networks

We’ll call out one company here, with the disclosure that Telnet is Stamus’s partner in Canada. Stamus was founded in 2014 by Eric Leblond and Peter Manev, both long-standing members of the Suricata development community. Leblond, Stamus’s CTO, has worked on Suricata since 2009 and sits on the OISF board. That makes Stamus less a company that adopted Suricata than one that grew out of it, and it keeps contributing back: the free Suricata Language Server, which brings rule checking and completion into code editors (version 2.0 arrived in March 2026), Suricata rulesets such as its lateral-movement set, and a free book, Suricata for Analysts.

Its commercial platform, Stamus Clear, takes Suricata’s output and turns it into a short list of high-confidence findings, which Stamus calls Declarations of Compromise, each backed by the evidence and detection logic behind it. It runs on-premises, private cloud or fully air-gapped. We introduced the partnership last month and will look at the platform in more depth in an upcoming post. Here, Stamus is a useful example of a broader pattern: the open engine does the inspection, and the commercial layer does triage, correlation and evidence.

Who deploys Suricata

Suricata’s user base is broad, so it is more useful to describe the types of organization than to list logos.

National cyber security agencies. ANSSI contributed Suricata’s original TLS support and is a consortium member. The Canadian Centre for Cyber Security contributes code and runs Suricata inside Assemblyline. The US Cybersecurity and Infrastructure Security Agency (CISA) lists Suricata among its free cyber security resources and backs Malcolm.

Cloud and service providers. AWS builds a managed firewall service on Suricata, and AWS and Verizon both fund OISF.

Critical infrastructure and OT operators. Malcolm was built with critical infrastructure in mind, including remote hydroelectric facilities, and Suricata’s industrial protocol parsers matter wherever agents can’t be installed. In Canada, this is the population Bill C-8 is about to ask hard questions of.

Enterprise SOCs and managed security providers. Usually through a commercial NDR, an open platform such as Security Onion, or Suricata’s EVE output feeding a SIEM.

Defence and training. Suricata-based tools are a regular presence in cyber defence exercises. Stamus, for example, says it has been an invited NDR partner in NATO’s live-fire exercises for more than ten consecutive years.

Small organizations, labs and classrooms. Through OPNsense, pfSense and Security Onion, Suricata is often the first IDS people learn on, which builds the talent pool everyone else hires from.

Why Suricata is positioned to lead

Predicting which technologies will matter in five years is a good way to look foolish. Still, several trends favour Suricata, and none of them depend on marketing.

The network is the layer attackers can’t avoid. Endpoints get missed, logs get wiped, and edge devices such as VPN gateways and firewalls have become favourite targets precisely because they rarely run security agents. Every intrusion still has to cross the network. An engine that records what crossed it, in an open and structured form, becomes more valuable as other evidence becomes less reliable.

Regulators want evidence you can explain. Canada’s Critical Cyber Systems Protection Act will bring incident-reporting deadlines for designated operators, and reporting means reconstructing what happened. A Suricata detection is a readable rule matched against recorded traffic, so you can show an auditor why it fired. That is a different proposition from a score produced by a model nobody outside the vendor can inspect.

AI-assisted security operations need trustworthy inputs. Every security vendor is adding AI agents that triage and investigate, and those systems are only as good as the telemetry they reason over. EVE is open, structured, documented and vendor-neutral, which is the kind of input that holds up. Stamus, for one, already exposes its Suricata-derived data to AI tools through the Model Context Protocol. The flip side, which we’ll take up in a later post, is that an AI analyst inherits every blind spot in the data underneath it.

It is becoming a platform, not just a program. Suricata 8 can be embedded as a library, extended with plugins for new protocols and capture methods, and run as an experimental firewall. Detection, prevention and policy enforcement expressed in one inspectable language is a convergence worth watching.

Its governance is built to last. A non-profit owner, a funding base drawn from competing vendors, a published roadmap and a steady release rhythm (roughly one major version every two years) are what make an open-source project safe to build a business on. Suricata has all of them.

None of this is guaranteed. Encryption will keep narrowing what any network sensor can see at the edge, and OISF depends on continued industry funding. But the direction of travel suits an open engine that turns traffic into evidence.

Getting it right: Suricata only sees what you feed it

This is the part we work on every day, and the part most explainers leave out. Suricata reconstructs conversations, and to do that well it needs complete, two-sided, accurately timed traffic. A few principles:

Use TAPs where it matters, not SPAN. Switch mirror ports drop packets under load and can hide errors. For the links that matter, a TAP gives Suricata a complete copy. Our TAPs overview covers the trade-offs.

Keep both directions of every flow together. Suricata tracks each connection’s state and reassembles its streams. If the request and response of one session land on different sensors, or on different worker threads, detection quietly degrades. When a packet broker load-balances traffic across sensors, it has to hash symmetrically so that both directions of a flow arrive at the same place.

Filter before inspection, but don’t slice. A packet broker can strip out traffic that doesn’t need inspecting (backups, storage replication, video) and remove duplicate packets, which lets the same sensor cover far more of the traffic that does. We made the same garbage-in, garbage-out argument years ago, and it still holds. But Suricata needs whole packets, so the packet slicing that suits some performance tools will break its protocol parsing.

Cover east-west, not just the perimeter. Lateral movement happens inside the network, often over SMB, Kerberos and LDAP: exactly the protocols Suricata parses well, and where encryption is less pervasive. A sensor that only watches the internet edge misses most of it.

Watch the drop counters. Suricata reports its own capture and kernel drop statistics. A sensor that drops 5% of packets at peak is a sensor that misses 5% of the evidence exactly when you need it most. Size for peak, not average.

Synchronize the clocks. Every investigation lines Suricata’s records up against firewall, endpoint and identity logs. If the clocks disagree, the timeline falls apart. Our post on precision time and Zero Trust explains why time is a security control in its own right.

Our view is simple: Suricata-based tools and the visibility layer that feeds them shouldn’t be treated as separate decisions. One determines what the other can possibly see.

Five questions to ask any Suricata-based tool

Whether you’re evaluating an open-source platform or a commercial NDR, these questions separate a well-built product from a thin wrapper:

Which Suricata version does it run, and how quickly do you ship upstream security releases? Suricata 7 is end of life. A product still running it no longer receives engine fixes.
Can we read, tune and add our own rules? If the detection logic is hidden, you’ve given up the main advantage of building on Suricata.
Can we get the full EVE data out, into our own SIEM or data lake? Your network records shouldn’t be locked inside one vendor’s console.
How does it report packet drops, and what happens at peak load? Ask for the sensor’s own drop statistics, not a datasheet throughput figure.
What does it add beyond the engine? Correlation, triage, evidence retention, integrations. That’s what you’re paying for, so the answer should be specific.

Where to start

If you’re new to Suricata, the fastest way to understand it is to watch it work on real traffic. Run it against a packet capture in a lab, or install one of the free platforms above, enable ET Open, and spend an afternoon reading the EVE records. The official documentation is thorough, and SuriCon 2026 runs November 18 to 20 in Lisbon for anyone who wants to meet the people building it.

And if you’re working out where Suricata-based detection fits in your environment, or how to build the visibility layer that feeds it, talk to our team. We’ll tell you what we see, including where it doesn’t fit.

Telnet Networks is a Canadian value-added reseller of network visibility, network security, test and measurement, and synchronized time solutions. We are Stamus Networks’ partner in Canada, and we also carry the TAPs and packet brokers that feed security sensors. Suricata is a trademark of the Open Information Security Foundation; other product names are trademarks of their respective owners.

Introducing Stamus Networks: Network Security Built For The Bill C-8 Era

Telnet Networks and Stamus Networks partnership lockup over a network topology motif, announcing Stamus Networks Canada partnership

The ground shifted in June

Bill C-8 received Royal Assent in June. For designated operators in telecommunications, energy, finance, nuclear and transportation, the Critical Cyber Systems Protection Act (CCSPA) brings a 90-day clock to stand up a cyber security program once a class of operators is designated, an incident-reporting window capped at 72 hours, and a continuing duty to identify and mitigate supply-chain risk. That last obligation does not stop at the operator’s front door. It flows down to the vendors and integrators who serve them. The telecom provisions are already in force; the CCSPA itself is law and awaits its in-force order.

None of this arrives in a vacuum. Ransomware crews and state-sponsored actors have been attacking Canadian utilities, transit systems and government networks for years. At the same time, the question of where security telemetry lives, and who can compel access to it, has moved from a procurement footnote to a board-level concern. Data sovereignty is now a security requirement, not a preference.

That is the context in which we went looking for a network security partner. We were not looking for just the loudest platform on the floor. We wanted one that turns network activity into answers teams can act on, backs each finding with evidence and disclosed detection logic, and runs in the environments our customers actually operate.

We chose Stamus Networks and its Stamus Clear network security platform.

Meet Stamus Clear

Stamus Networks is the creator of Stamus Clear, a network security platform built on Suricata, the open-source network security engine much of the industry runs on. Stamus Clear turns network traffic into clear, evidence-backed answers about what is happening on the network, so teams can see what the rest of the stack misses and know what to do about it.

Stamus Clear watches the network itself. Endpoints get missed, logs get altered, and nobody is installing an agent on a substation controller or a signalling system. But every attacker has to cross the wire at some point, which makes the network the one layer they cannot avoid touching. Stamus Clear turns that traffic into a short, list of response-ready cases: what happened, what to do next, and the evidence and reasoning behind it. Clear Detect raises high-confidence Declarations of Compromise and Declarations of Policy Violation rather than handing the team another queue of alerts or a score it has to trust.

That evidence is the point. When an incident happens, the questions come fast. What did the attacker touch? When did it start? What left the building? Can you prove it? A team running Stamus Clear can answer with evidence it can inspect and defend, and show its work to whoever is asking, whether that is the board, an auditor or a regulator.

Deployment is on your terms. Stamus Clear runs on-premise or in hybrid environments, including fully air-gapped deployments, with no dependency on a Stamus cloud. The customer keeps its network data under its own control.

A decade of proof

Stamus has been building on Suricata since 2014, founded by Eric Leblond and Peter Manev, two of the people behind the open-source engine. The team remains at the core of the Suricata project through the OISF. That depth matters: Stamus is not simply integrating the engine; it brings more than a decade of expertise turning network traffic into evidence teams can act on.

The customer list tells the rest of the story. Stamus is trusted by European national banks, EU institutions, government, critical infrastructure and global industrial operators: organizations that get attacked most and can least afford a finding they cannot explain. The team has also supported a decade of NATO cyber defender training. That track record, together with 97% net customer retention, is proof built over years rather than a marketing claim.

What settled it for us, though, was their approach. Stamus is transparent by design: for detections built on defined detection methods, analysts can inspect the detection logic that fired and the traffic evidence behind it; anomaly detections carry the evidence and reasoning behind the finding. Stamus Clear also integrates with the security tools customers already run. When you have to defend a decision to an auditor or a regulator, evidence and logic you can check are a very different proposition from a black-box score you are asked to trust.

From the fibre to the finding

For more than two decades, Telnet has designed and supplied the visibility fabric (network taps, packet brokers and aggregation) that Canadian utilities, telecoms, transit agencies, government departments and industry run. That fabric decides what a security tool can see. NDR is only as good as the traffic it is fed, and we have expertise in building the layer that feeds it.

Together, Telnet and Stamus deliver the complete evidence pipeline, from the fibre to the finding. We scope the traffic access, Stamus Clear turns network activity into prioritized, response-ready cases and evidence, and the whole chain stays in the customer’s custody.

We built this partnership for specific deployment realities: organizations that cannot send telemetry to a vendor cloud; air-gapped, OT and industrial networks where an agent will never be installed; and operators who will need audit-ready records as the CCSPA reporting obligations come into force. If you already run taps and brokers, Stamus Clear can be added to your existing visibility fabric, shortening the path from traffic access to useful, evidence-backed answers.

“Canadian critical infrastructure operators increasingly need control over where security data is processed and the ability to show exactly why a finding was made. Telnet Networks brings the local visibility expertise; Stamus Clear brings evidence-backed network security that can run on-premise or fully air-gapped. Together, we give operators a practical path from network traffic to answers they can act on without depending on a vendor cloud.”
— Mark Firmin, CEO, Stamus Networks

What happens next

Two things you can do today. Book a C-8 Readiness Briefing: 45 minutes with our team on what the Act requires, where the evidence gaps usually sit, and how to prepare for designation. Or ask us about a proof of concept on your existing visibility infrastructure.

Over the coming weeks we will go deeper on the questions this partnership was built to answer: what audit-ready network evidence actually looks like, why control of security data matters, how detection works in an air-gapped environment, and how to get ahead of the supply-chain questionnaires that C-8 will bring.

Welcome, Stamus Networks. We are glad to have you alongside us.

Bill C-8 data sovereignty NDR Network Security Stamus Networks

From Vienna to CERN: The European Innovation Behind Modern Network and Timing Infrastructure

Sub-nanosecond timing over Ethernet was not born in a product roadmap. It came out of CERN, where physicists needed the White Rabbit protocol to synchronize instruments across a particle accelerator with a precision that ordinary networking had no reason to attempt. The specification is now folded into IEEE 1588-2019 as the High Accuracy profile, and it has quietly become the reference point that timing vendors across Europe still measure themselves against.

That is a useful way to think about a handful of the vendors in Telnet’s own portfolio. They are not the biggest names in their categories, but they tend to be the ones doing the interesting engineering: a packet broker maker in Vienna, a clockmaker in western France that has been keeping time since before the telephone, a Suricata-based security platform built by open-source developers in Paris. Here is what each of them has been building lately.

Cubro: Precision Engineering With New Backing

Cubro has been designing network packet brokers, TAPs and probes out of Vienna since 2003, and in December 2025 the Swedish industrial group Addtech acquired a majority stake in the company. For a Telnet customer, the practical upshot is stability: Cubro keeps its Vienna engineering team and roadmap, now with a publicly traded parent behind it (Addtech trades on Nasdaq Stockholm).

The product itself keeps moving. Cubro’s Omnia platform runs application-layer classification directly on the packet broker, an architecture the company has been pushing further as encrypted traffic makes payload-based inspection less useful across the industry. It is the same “classify once, distribute everywhere” idea that shows up increasingly in how Telnet evaluates network visibility architecture generally, and Cubro is one of the vendors building toward it in hardware.

Profitap: Forty Years of TAPs, Reshaped for OT

Profitap’s roots go back to 1984 in Strasbourg, France, before the company relocated its headquarters and R&D to Eindhoven, Netherlands. That history matters less than what the team has done recently with it: the IOTA platform extends Profitap’s TAP and packet-broker lineage into portable, high-precision capture kits built for operational technology networks, where nanosecond-level timestamp accuracy in packet capture is often the difference between a diagnosable incident and a guess.

Profitap’s engineering has always leaned toward the physically compact and the field-deployable, and IOTA is the clearest expression of that instinct: fly-away capture kits that a field engineer can carry to a substation or a plant floor rather than a rack that has to be provisioned in advance.

Infosim: A University Spin-out That Stayed Independent

Infosim was founded in 2003 as a spin-out from the University of Würzburg, and more than twenty years later it is still headquartered there, still privately held, and still developing StableNet entirely out of its German R&D team. That kind of continuity is unusual in network management software, where consolidation is the norm.

StableNet’s release cadence has stayed active through that independence. Its unified approach to fault, performance and configuration management remains vendor-agnostic by design, which is a deliberate choice for a company that could have built a walled garden and didn’t.

Timebeat: Timing Software Built on Open Standards

Timebeat is a UK company building PTP and NTP synchronization as software first, hardware second, which is close to the opposite of how most of the timing industry has historically worked. Its stated position on vendor lock-in is blunt: interoperability is the point, not a concession. The Timebeat.app daemon replaces chrony, ntpd and ptp4l on a host, and the company’s grandmaster hardware line extends the same open approach into rack appliances and PCIe timecards.

Timebeat also builds explicitly for interoperability with White Rabbit-based networks, which is the same protocol lineage that opened this post. It is a small detail, but it says something about how connected European timing engineering still is to that original CERN work, even decades and several product categories removed from it.

Bodet: From Mechanical Clockmaking to Network Time

Bodet has been making clocks in Trémentines, France since the 19th century, long enough that the company’s own history predates the electrical grid it now helps synchronize. The relevant point for a network engineer is less the heritage and more what Bodet has done with it: its Netsilon line brings that clockmaking precision into NTP and PTP master clock appliances built for the same digital infrastructure everyone else in this post is building for.

Telnet has deployed Bodet clock systems where functional requirements could not be met by any other vendor and operational requirements were absolute. Performance has always met or exceeded the required standards.

Stamus Networks: Open-source Security Engineering Out of Paris

Stamus Networks was founded in 2014 by Éric Leblond and Peter Manev, both long-time core developers of Suricata, the open-source intrusion detection engine that much of the network security industry builds on in one form or another. Stamus is dual-headquartered in Paris and Indianapolis, but its product engineering and much of its leadership remain rooted in the same open-source security community that produced Suricata in the first place.

Clear NDR, Stamus’s flagship platform, turns that Suricata foundation into a full network detection and response system, and the company has kept contributing back to the open-source project rather than treating it purely as a dependency. That is a meaningfully different posture from most commercial NDR vendors, and it shows in how transparent Clear NDR is about what it is actually doing under the hood.

The Common Thread

None of these companies are chasing the same trend at the same time. Cubro is scaling with new capital behind it. Profitap is pointing forty years of TAP engineering at OT networks. Infosim has stayed independent long enough to keep StableNet vendor-agnostic on principle. Timebeat is building timing software that assumes interoperability rather than lock-in. Bodet is doing to network time what it has done to mechanical clocks for over a century. Stamus is building commercial security on an open-source foundation it still maintains.

What connects them is a certain patience with hard engineering problems, the same patience that turned a CERN physics requirement into an IEEE standard. Telnet works with all six because each one solves a specific, technical problem well, not because of where they happen to be headquartered. But it is worth noticing, occasionally, how much of the interesting work in this industry keeps coming out of the same part of the world.

Want to know where any of these fit into your network? Get in touch with our team and we’ll help you figure out what makes sense.

Bodet Cubro infosim Network Security Network Visibility precision timing profitap Stamus Networks Timebeat vendor spotlight

Encrypted Client Hello Is Here. What Can Your Network Tools Still See?

In March 2026 the IETF published RFC 9849, standardizing TLS Encrypted Client Hello. In plain terms, the part of the TLS handshake that announces which site a client is connecting to can now be encrypted. The Server Name Indication field, which a surprising amount of enterprise security tooling quietly depends on, becomes unreadable to anything watching the wire.

If your organization filters or allowlists by hostname, writes detection rules against destination domains, or produces any report that groups traffic by site, all of that rests on a field with an expiry date.

Before anyone reaches for the fire alarm: this is a planning problem, not an emergency. What follows is what the deployment data actually shows, what breaks when it arrives, what survives, and where we think the work belongs.

How fast is this actually coming?

Slower than the headlines suggest, and that distinction matters more than it might seem.

The client side is largely ready. Chrome, Edge, Firefox and Brave enable ECH by default when encrypted DNS is in use. Safari is the notable exception, exposing no user-facing support, which on its own puts a meaningful ceiling on enterprise exposure.

The server side has barely started. Research published by Corrata in May 2025 put real-world ECH usage at 0.06% of connections, against a theoretical ceiling of roughly 2% given how few servers support it. Fewer than 10% of the top million sites offer ECH; around 3% of the top thousand, and about 1% of the top hundred.

A passive measurement study of a university network carrying roughly 35,000 users, conducted in February 2025, found something instructive. 59% of QUIC flows carried the ECH extension, which sounds substantial until you look closer: only 1.96% of those were valid ECH. The remainder was GREASE, the deliberate padding clients send to keep middleboxes honest. Every valid ECH connection in the study went to Cloudflare.

That is the central constraint. Cloudflare is effectively the only CDN running ECH in production, and not on its free tier. No other major CDN has announced support since the RFC published. There is also a second gate that gets less attention: the ECH configuration is bootstrapped through DNS HTTPS records, specified in the companion RFC 9848, which in practice depends on DNS-over-HTTPS. The same study found only 3.8% of HTTPS DNS queries received a response at all, and most of those lacked the address data needed to act on them.

A realistic horizon for material enterprise impact is two to four years. RFC publication is the unlock, because CDNs and security vendors generally will not ship a protocol still in draft. The signal worth watching is the second and third major CDN announcing support.

There is a wrinkle, though, that makes that timeline less comforting than it first appears. Corrata’s research found roughly 17% of ECH-enabled sites fell into malicious or risky categories, with more than 90% of the phishing they detected riding Cloudflare infrastructure. That figure comes from a security vendor and is worth treating as directional rather than precise. The underlying logic is harder to argue with: if your operation depends on not being identified by the site you connect to, ECH is the first thing you adopt. The mainstream web is years out. The traffic you most want to inspect is already there.

What ECH actually changes

ECH encrypts the ClientHello, including SNI, under the server’s public key. An observer on the path sees a cover domain belonging to the CDN rather than the real destination. Millions of distinct hostnames collapse into a handful of shared names.

This is the successor to Encrypted SNI, which encrypted only the server name field and had known weaknesses. ECH covers the whole handshake message, which is why it closes gaps that ESNI left open, and also why it is more disruptive to anything that was reading those fields.

Worth noting alongside this: QUIC hides the entire ClientHello as a matter of course. Techniques built on observing the TLS handshake do not carry over to QUIC cleanly, so any answer to ECH that only works on TCP covers a shrinking portion of the traffic.

What this breaks

Framed as controls rather than concepts, because that is how the problem arrives:

SNI-based allowlisting and category filtering. The most common enterprise compromise, and the most directly affected.
Detection rules keyed to destination hostnames. Hostname indicators of compromise remain effective only where ECH is not in play.
Endpoint-agent TLS proxying. This one is worth dwelling on. As Kathleen Moriarty sets out at RIPE Labs, an ECH-enabled browser treats interception as an attack, because that is precisely what the protocol was designed to prevent. It does not degrade gracefully; it fails.
Reporting and capacity planning that groups by hostname. Less dramatic, more pervasive, and usually discovered late.
Any architecture built on “we don’t decrypt, we just read SNI.” A reasonable compromise for years, and one with a limited remaining life.

Why “just decrypt it” is not the answer it used to be

To be fair to decryption: it still has a legitimate place at defined boundaries, and organizations that have invested in it are not wrong. The issue is that its coverage keeps narrowing.

Certificate pinning already puts a growing share of application traffic out of reach. Inline decryption at scale carries real cost, in appliances and in latency. Privacy and regulatory exposure has grown, not shrunk. And ECH specifically defeats the endpoint-agent approach that many organizations adopted as the lighter-weight alternative to inline proxies.

The pattern is consistent: decryption is becoming a targeted tool for specific segments rather than a general strategy. That is a meaningful shift for anyone whose visibility architecture assumed otherwise.

What still survives on the wire

Quite a lot, as it happens. None of it is payload.

Addresses and ports remain visible. So do volume, timing and directionality. Flow and session behaviour is unchanged, and behavioural patterns are often the most durable signal available. Client-side TLS and QUIC fingerprinting still works against the outer handshake, though it is worth being precise about what that gives you: it characterizes the client, not the destination. Connection metadata and certificate information remain available where they are still exposed. DNS is readable where it has not been moved to DoH.

The useful realization is that for most enterprise purposes, payload was never the thing that mattered. Knowing that a host is talking to a command-and-control endpoint on a schedule matters. Reading the contents of that conversation is rarely what generates the detection. This is a point we have made before in a different context, and encryption has only sharpened it.

So what is deep packet inspection now?

This is where the industry’s vocabulary works against clear thinking.

“Deep packet inspection” still carries the connotation it earned in the 2000s: reading payloads, inspecting content, seeing inside the conversation. In an enterprise network in 2026, that describes an increasingly small and specialized activity.

What the term actually describes in current practice is application classification and metadata extraction, using behavioural and statistical signals rather than payload reading. The question it answers is not “what is in this session,” but “what application is this, what is it doing, and does that pattern make sense.”

That is a genuinely different capability, and the naming confusion costs teams good decisions. We see organizations reject classification approaches because they have privacy concerns about DPI as they remember it, and other organizations buy decryption infrastructure to answer questions that classification would have answered without it.

Where that work belongs

If classification is the capability, the architectural question is where to perform it.

The common pattern is to let every tool do its own. The NDR platform classifies. The SIEM ingests and classifies again. Performance monitoring runs its own copy. Each needs a full packet feed, each does overlapping work, and each produces its own vocabulary for the same traffic.

The alternative is to classify once at the visibility layer and distribute structured metadata to the tools that need it. This is not a new idea, and it follows the same logic we set out when looking at where the packet broker market is heading. Encryption strengthens it considerably: classification is getting harder and more specialized, so doing it once, well, in a purpose-built place makes more sense than asking five tools to each do it adequately. It assumes you have solved the layer below it first, which is a separate conversation about TAPs and capture.

This is where Cubro’s Omnia platform is worth a look, and specifically why. Cubro runs classification as an application on the packet broker rather than as another appliance, which addresses the objection that actually kills these projects. Most organizations already need a broker. Adding classification to infrastructure that is already in the rack, already in the change process and already understood by the team is a materially different proposition from introducing a new box. We have looked at the same platform previously from the high-speed 100G and 400G angle.

Output formats matter as much as the classification itself, because compatibility is the first thing a working architect will ask about. Cubro produces IPFIX, IPFIX with DPI enrichment, and a time-window format of their own. Cubro states that its DPI engine identifies layer 7 applications regardless of encryption, using a combination of deep packet inspection and machine learning. That is the vendor’s claim rather than ours, and it is the right thing to test in an evaluation against your own traffic, particularly against ECH and QUIC specifically rather than TLS 1.3 generally.

The economic argument follows from the architecture. Metadata is a small fraction of the traffic it describes, so tools downstream ingest far less than they would from full packet feeds. Where NDR and SIEM licensing scales with volume, that difference shows up directly on an invoice.

A note for Canadian employers

One thing worth flagging, because it tends to surface late.

In Ontario, an employer with 25 or more employees on January 1 must have a written electronic monitoring policy in place before March 1 of that year, describing how and in what circumstances employees are monitored and what the resulting information is used for. Network visibility tooling is not usually deployed with employees in mind, but the question of whether it belongs in that policy is a fair one, and it is easier to answer accurately for a metadata-based architecture than for one built on full decryption.

There is a broader point here. Where Canadian privacy law does reach employee information, the recurring test is proportionality. The Office of the Privacy Commissioner’s workplace privacy guidance asks directly whether there are less invasive means of achieving the same ends at comparable cost and with comparable benefits. An architecture that collects connection facts rather than message content is a more defensible answer to that question. We will cover this properly in a follow-up post.

This is not legal advice, and the policy itself is a conversation for your counsel rather than your network team.

Five questions worth asking

If you want to size your own exposure before it becomes urgent:

Do any of your security or filtering controls key on SNI or destination hostname? Do you know which?
What share of your egress is already QUIC, and can your current tooling classify it?
Where do you decrypt today, and what proportion of total traffic does that actually cover?
If hostnames disappeared from your monitoring tomorrow, which dashboards, reports and detection rules break?
Are you paying to ingest full packet data into tools that only need metadata?

Most organizations cannot answer the second and third from memory, and the answers are usually further from expectations than people assume.

Finding out where you stand

Telnet’s Network Visibility Assessment is a time-boxed engagement that answers those questions against your actual traffic rather than in the abstract. It includes the tooling and the analysis, and the output is a clear picture of what your current architecture sees, what it misses, and what changes as encryption continues to close in.

If the questions above were uncomfortable to read, that is usually a good reason to look.

Telnet Networks is a Canadian value-added reseller specializing in network performance monitoring, test and measurement, and network visibility. We work with Cubro alongside other visibility and security vendors, and our recommendations depend on the network in front of us.

Network Monitoring Network Security

The Second Ring of C-8: What Selling to Critical Infrastructure Now Requires

Concentric rings diagram: designated operators at the centre of Bill C-8, vendors on the second ring

This article is a follow-up to our Bill C-8 overview post

The contract renewal arrives from a customer you’ve served for a decade: a telecom, a bank, a pipeline operator. Your product hasn’t changed. Your service hasn’t changed. But the paper has. It now carries security attestations, audit rights, a 24-hour incident-notification clause, and a new right to terminate for unremediated cyber risk. Nothing about your business triggered this. Your customer’s legal environment did.

Bill C-8, An Act Respecting Cyber Security, received Royal Assent on June 16, 2026. Its centrepiece, the Critical Cyber Systems Protection Act (CCSPA), names only “designated operators” in six vital services: telecommunications, interprovincial pipeline and power line systems, nuclear energy, federally regulated transportation, banking, and clearing and settlement. If your company isn’t on that list, the Act never mentions you.

It will still rewrite your contracts. We have a front-row seat to this shift: Telnet Networks has supplied network, security, and timing infrastructure to Canada’s critical sectors for over 25 years, and we serve both the operators C-8 designates and the vendors who sell to them. Here’s why the flow-down is coming, and what to do about it.

Why flow-down is structural, not optional

The CCSPA makes designated operators responsible for risk they don’t directly control. Operators must establish a cybersecurity program that identifies and manages risks “associated with the operator’s supply chain and its use of third-party products and services,” and they must mitigate those risks as soon as they’re identified. This is a continuing duty, not an annual checkbox. Operators must also keep records of every step taken to mitigate supply-chain risk, which means your security posture becomes part of their compliance file.

The enforcement stakes explain what happens next. Administrative monetary penalties run up to $15 million per day for organizations and $1 million per day for individuals, and directors and officers can be personally liable for their organization’s violations. When executives are personally exposed for supplier risk, vendor risk tolerance goes to zero.

Operators can’t outsource the legal obligation. So they’ll do the only thing they can: transfer it contractually. Due diligence questionnaires, security schedules in MSAs, and continuous monitoring of the vendor base aren’t a courtesy anymore. They’re how a regulated operator proves it met its statutory duty.

That’s the second ring of C-8: a much larger population of undesignated companies (technology vendors, MSPs, integrators, SaaS providers, contractors) regulated not by Parliament, but by procurement.

What “C-8 by proxy” looks like in practice

Expect these artifacts to show up in RFPs, renewals, and vendor portals over the next 12–24 months:

Security questionnaires with teeth. No longer check-the-box. Answers will be tied to renewal, payment terms, and award decisions, and they’ll be retained as evidence of the operator’s own compliance.

Incident-notification clauses that beat the regulator’s clock. Operators must report significant cyber incidents to the Canadian Centre for Cyber Security within a window capped at 72 hours (regulations may set it shorter). An operator can’t report what it doesn’t know, so vendor contracts will require notification of incidents affecting the customer faster than the operator’s own deadline: often 24 hours, sometimes less.

Audit and inspection rights. Evidence requests for SOC 2 or ISO 27001 reports, penetration test results, and patch cadence, plus the right to inspect and, in some drafts, the right to direct remediation.

Vulnerability disclosure and patching SLAs for products embedded in or connected to critical systems.

Termination for cyber cause. If a risk you represent is identified and you don’t mitigate it, the operator’s cleanest legal path is to end the relationship. Expect that right to be explicit.

Insurance flow-down. Cyber coverage minimums appearing in MSAs and renewal terms.

Supplier-origin scrutiny. The companion amendments to the Telecommunications Act give the government authority to compel action against threats in telecom networks, including restricting suppliers. Expect heightened questions about product provenance, subcontractors, and where data lives.

What “somewhat compliant” actually means for a vendor

You don’t need a full CCSPA cybersecurity program. You need to be answerable. A pragmatic maturity ladder:

Tier 1: Table Stakes. Documented security policy, MFA everywhere, patch management, asset inventory, a named security contact. Without these you’ll struggle to complete a questionnaire honestly.

Tier 2: Contract-Ready. An incident-response plan with defined customer-notification timelines you can actually meet; vendor risk management for your own suppliers; a pre-built evidence pack (certifications, pen-test summaries, standard questionnaire answers).

Tier 3: Differentiated. Alignment to a recognized framework such as the Cyber Centre’s baseline guidance, NIST CSF, or ISO 27001; continuous monitoring; and the ability to support a customer audit without disrupting your operations.

The fourth-party ripple

Your customer’s obligation flows to you; yours flows onward. Because operators must manage supply-chain risk wherever it originates, they’ll increasingly ask about your suppliers: subprocessors, hosting providers, offshore development. Vendors will need their own miniature supply-chain risk program, starting with a current subprocessor list and baseline security requirements flowed into their own vendor contracts. C-8’s reach is recursive.

Turning compliance into a moat

Here’s the reframe worth internalizing: every artifact above is also a sales asset.

The first vendors in a category who can hand procurement a complete evidence pack shorten the security-review cycle from months to days, and win deals against slower competitors. “C-8-ready” is a positioning claim you can substantiate: pre-answered questionnaires, a standard security rider you’ll sign without three rounds of legal, notification commitments you’ve rehearsed. And as designation orders land, expect procurement teams at operators to begin disqualifying vendors on security posture alone. Readiness isn’t just risk management; it’s revenue protection.

A 90-day starter plan

Map your exposure. Inventory which customers are, or will plausibly become, designated operators across the six vital services.
Read your own paper. Review existing contracts for security and notification clauses already in force. Know your current commitments before new ones arrive.
Build the evidence pack before you’re asked. Policies, certifications, test results, standard answers.
Rehearse incident notification. Define who calls whom, and prove you can beat a 24-hour clock. That requires two things most vendors haven’t built: the visibility to detect an incident quickly, and trustworthy timestamps that let you reconstruct exactly when it started.
Push requirements downstream. Identify your own critical suppliers and set baseline expectations now.
Anchor to a framework. Run a gap assessment against the Cyber Centre’s guidance or NIST CSF and prioritize the gaps a customer would flag first.

Where Telnet Networks fits

Telnet Networks has spent over 25 years supplying mission-critical network, security, and precision-time solutions to Canadian enterprises, government, and the very sectors C-8 designates. That puts us on both sides of this story: we help operators meet their obligations, and we help their vendors become the low-risk suppliers those operators need. Four areas matter most for second-ring readiness.

Visibility you can act on. A 24-hour notification commitment is only as good as your ability to detect an incident in the first place. Network TAPs, packet brokers, and bypass switches give your security tools complete, reliable access to traffic, so detection isn’t dependent on luck or SPAN-port leftovers. The same architecture becomes evidence in an audit: it shows a customer exactly how you’d know something happened.

Detection you can demonstrate. Visibility feeds detection, and detection is what the questionnaires will probe. Through our new partnership with Stamus Networks, we deliver Clear NDR: Suricata-based network detection and response that produces transparent, explainable findings rather than black-box verdicts. When a designated operator asks “how would you know you’d been breached, and can you show us?”, an NDR deployment turns that answer from a paragraph of assurances into something you can put on the table.

Time you can prove. When a customer or regulator asks “when did you know?”, the answer lives in your logs, and logs are only as credible as the clocks behind them. Our GNSS and NTP/PTP precision timing platforms keep timestamps synchronized and defensible across your environment, turning an incident timeline from an estimate into a record.

Connections that can’t flow backward. If your service touches a customer’s critical or OT environment, you are the pathway an operator worries about. Data diode TAPs enforce one-way traffic flow in hardware, letting you deliver monitoring and support while physically removing the inbound threat path, which is often the single fastest way to shrink the risk you represent.

If C-8 clauses are starting to appear in your renewals, or you want to get ahead of them, talk to our team about a visibility and readiness assessment.

Sidebar: The C-8 timeline: why vendors feel it first

June 2022: Bill C-26 introduced, Canada’s first attempt at critical cyber systems legislation.

January 2025: C-26 dies on the Order Paper when Parliament is prorogued.

June 2025: Reintroduced as Bill C-8, substantially the same framework.

April 2026: Passes the House of Commons following substantive committee amendments.

June 16, 2026: Royal Assent. Telecommunications Act amendments take effect immediately.

Today: The CCSPA itself is not yet in force. Its obligations begin on dates set by the Governor in Council, and the schedule of designated-operator classes is still empty. Regulations defining incident-reporting thresholds and program details are still to come.

Designation + 90 days: Once designated, operators have 90 days to stand up their cybersecurity program.

Here’s the catch for vendors: procurement moves ahead of the law. Operators know designation is coming and are papering their supply chains now, because remediating hundreds of vendor relationships takes longer than 90 days. The contractual flow-down is arriving before the legal obligations that drive it, which means the vendor deadline is, effectively, already here.

This post discusses commercial and contractual trends, not legal obligations. The CCSPA imposes no direct duties on non-designated companies. It isn’t legal advice; talk to counsel about your specific contracts.

Bill C-8 CCSPA Network Security

Keysight Network Visibility, Testing and Security: Where Each Piece Fits

Keysight network visibility, TAPs and packet brokers — Telnet Networks vendor spotlight

You can’t secure or troubleshoot traffic you can’t see. That’s an old line, but it has become a harder problem: hybrid cloud, encrypted east-west traffic, high-density AI data centres, and a monitoring toolset that costs more every year to keep fed with the right data.

Keysight Technologies builds most of what solves this. Their network visibility, security and test portfolio — built on the Ixia and NetOptics product lines — covers passive traffic access, intelligent packet distribution, inline failover protection, and pre-deployment threat validation.

Telnet Networks has been designing and deploying these products in Canadian networks for years. This guide is our take on where each piece actually fits: what problem it solves, what it costs you to skip it, and which environments suit it best.

The architecture in four lines

Tap it. Network TAPs give you a passive copy of live traffic without touching your production switches.
Broker it. Packet brokers filter, deduplicate and decrypt that traffic so each tool receives only what it needs.
Protect it. Bypass switches keep the link up when an inline security tool fails or goes down for maintenance.
Test it. BreakingPoint and Threat Simulator prove your defences hold up before an adversary finds out for you.

Network visibility architecture: a network TAP feeds a Keysight packet broker that filters and distributes traffic to IDS, DLP and NDR tools; below, a bypass switch monitors an inline IPS or firewall by heartbeat and routes traffic directly link-to-link if the tool fails

The Keysight Visibility and Security Portfolio

1. Network TAPs and Aggregators

If you’re still feeding your monitoring infrastructure entirely from SPAN or mirror ports, you’re likely carrying blind spots you can’t see and adding load to switches that have better things to do. Network TAPs sit passively on the link and hand you a full copy of the traffic instead.

Key features: 100% passive traffic capture from 1Gbps to 400Gbps, supporting single-mode, multi-mode and Cisco BiDi fibre. The Flex Tap VHD packs up to 36 taps into 1U. For industrial and outdoor deployments, ruggedized Tough TAPs provide the same passive access in environments that would kill standard hardware.
Companion hardware: iLink Aggregators sit behind your TAPs to consolidate multi-link traffic into a smaller number of downstream tool connections — usually the cheapest way to avoid buying tool ports you don’t need.
Best aligned for: Provincial and municipal utilities and other ICS/OT operators, where a passive tap is often the only monitoring method an operations group will approve on a control network. Also financial services, healthcare networks, and enterprise data centres where dropped packets aren’t an option.

Our take: the most common thing we find on a first site walk is a monitoring architecture that quietly outgrew its SPAN ports two or three refresh cycles ago. A proper tap plan is usually the least expensive fix on the table, and it’s the one that makes everything downstream work better.

2. Network Packet Brokers and Software-Defined Fabric

Once traffic is tapped, something has to decide where it goes. A packet broker is the traffic controller for your visibility layer — it makes sure each monitoring, forensics and security tool receives the data it needs and nothing it doesn’t.

Key features: Built on a hardware-acceleration architecture Keysight describes as zero-packet-loss. The feature stacks layer up: NetStack (aggregation and line-rate filtering), PacketStack (deduplication and header stripping), SecureStack (inline and out-of-band SSL/TLS decryption), and AppStack (Layer 7 application awareness and geographic filtering).
Key products: Vision ONE is the standalone platform for a first visibility deployment. Vision Edge 10S (E10S) suits remote offices and smaller data centres where rack space is tight. Vision Edge 400P handles enterprise cores, with 32 ports of 400Gbps processing in a compact form factor.
Management overlays: Keysight Vision Orchestrator (KVO) and Ixia Fabric Controller (IFC) Clustering manage distributed multi-hop topologies from a single console, which matters as soon as you have visibility hardware in more than one site.
Best aligned for: Telecoms and regional service providers, mid-to-large enterprises, government departments and higher education. If you’re trying to get more out of an expensive tool farm — IDS, DLP, NDR, firewalls — rather than buying more capacity, this is where to start.

Our take: before recommending a Vision platform we’ll usually audit what your existing tools are actually receiving. In most environments a meaningful share of what’s being sent to IDS and DLP is duplicate or irrelevant traffic — capacity you’re already paying for, twice.

3. Bypass Switches (Inline Protection)

Putting a firewall or IPS directly in the traffic path is how you block threats. It’s also how you create a single point of failure. If that device freezes, loses power, or just needs a routine software update, the link goes with it.

Bypass switches solve this by acting as an automatic detour. If the security tool stops responding, the switch routes traffic around it at wire speed and the link stays up.

Key features: Fail-safe automated inline protection. The switch monitors connected appliances using configurable “heartbeat” packets and reroutes instantly when one stops answering — so a tool outage doesn’t become a network outage.
Topology: Built on the NetOptics legacy, with full support for both active-active and active-passive tool configurations at any scale.
Key products: The Keysight iBypass family, including high-density and copper configurations such as iBypass Copper Gen 4, protects critical links without adding latency or configuration overhead.
Best aligned for: Hospital networks and regional health authorities, Canadian financial institutions working to OSFI operational-resilience expectations, e-commerce platforms, and any mission-critical infrastructure where downtime maps directly to lost revenue or disrupted patient and customer operations.

Our take: the bypass switch is the least glamorous line item in a visibility design and the one clients thank us for most often. It typically pays for itself the first time an inline tool needs an unscheduled reboot during business hours.

4. Cloud Visibility and Performance Monitoring

When workloads move to public, private or hybrid cloud, most organizations lose the packet-level visibility they relied on for years on-premises. Keysight closes that gap by extending the same visibility intelligence into virtualized and software-defined environments, so your tools keep a single unified view no matter where the workload runs.

Key features: Vision Edge OS on open-compute hardware, paired with virtual cloud taps, lets you monitor public, private and hybrid fabrics including AWS and Azure. For workloads that need precise timing, TimeKeeper® provides verifiable clock synchronization.
Best aligned for: Organizations partway through a cloud migration who still need on-premises-grade packet visibility, SaaS providers, and any environment with microsecond timing or timestamp-compliance requirements.

A note on data residency: for public sector, healthcare and regulated financial clients, where visibility and telemetry data lives is as much of a design constraint as throughput. Cloud visibility deployments need to account for it from the start, not as a retrofit. Telnet supports Canadian deployments end to end and can help scope an architecture that keeps monitoring data where your policy requires it.

5. Network Test and Security Validation

Visibility is half the job. The other half is knowing how your defences actually behave under pressure — before a real adversary finds out for you.

Plenty of organizations run on baseline configurations and hope for the best, with no evidence of how the security stack performs under load. Keysight’s test portfolio lets you safely generate large-scale application traffic and simulate real attack techniques inside your own environment, so your team can demonstrate the defences work rather than assume they do.

Key features: BreakingPoint and BreakingPoint Cloud run application stress tests and simulate real-world attack traffic safely. The SaaS-based Threat Simulator runs continuous Breach and Attack Simulation (BAS) against your live environment without disrupting it. Both are fed by Keysight’s Application and Threat Intelligence (ATI) team, which maintains the threat and application definitions.
Best aligned for: SecOps and cybersecurity engineering teams, QA and lab environments, and compliance functions that need documented evidence of control effectiveness rather than a configuration screenshot.

Our take: for teams building a validation practice from scratch, we’ll usually suggest starting with a scoped BreakingPoint engagement rather than a full platform purchase. It’s a faster way to find out what you’d actually use.

Quick Reference

Product category	Primary focus	Best use case
Network TAPs	Passive, raw packet capture	Replacing overloaded SPAN ports; monitoring OT/ICS links without touching the control network
Packet Brokers (Vision series)	Filtering, deduplication, SSL decryption, tool load balancing	Getting more out of an existing tool farm; sending targeted traffic to specific appliances
Bypass Switches (iBypass)	Inline high availability and tool failover	Keeping critical links up when an inline firewall or IPS fails or needs patching
Test Suite (BreakingPoint / Threat Simulator)	Threat simulation and network stress testing	Proving control effectiveness; testing resilience before production deployment

Where to start

Building a visibility layer that holds up requires the right foundation — and most of the cost of getting it wrong shows up later, in tool licences you didn’t need and blind spots you didn’t know about.

As a Keysight partner, Telnet Networks can help you assess your current topology, design a visibility architecture that fits your environment, and choose the right mix of TAPs, packet brokers and test platforms for the budget you have.

Two ways to start:

Not ready to buy anything yet? Ask us for a network visibility assessment. We’ll review your current TAP and SPAN architecture and tell you where the gaps are.
Have a specific project in mind? Contact our team to talk to a technical specialist or request a proof-of-concept design built for your environment.

Network Security Network Visibility

Understanding & Operationalizing Bill C-8 as a Critical Infrastructure Operator

On June 15, 2026, Bill C-8, An Act Respecting Cyber Security, received Royal Assent. After years of consultation, a false start as Bill C-26, and months of committee scrutiny, Canada now has its first mandatory, enforceable cybersecurity law for critical infrastructure.

If you operate in energy, telecom, transportation, or finance, this law will reshape your network operations. Even for smaller, leaner organizations—like a local utility or independent provider—the headlines about ‘$15 million penalties’ can be overwhelming. This post helps you cut through that noise

This post breaks down Bill C-8’s requirements and provides a practical framework to turn these new obligations into an actionable compliance plan.

What Bill C-8 Actually Is

Bill C-8 does two distinct things, and it helps to keep them separate.

Part 1 amends the Telecommunications Act. It makes security an explicit policy objective of Canadian telecom law and gives the federal government new powers to order telecommunications service providers to take specific security actions, up to and including banning equipment from specific suppliers. These amendments took effect immediately on Royal Assent. If you’re a telecom or ISP, the era of voluntary security guidance is over.

Part 2 enacts the Critical Cyber Systems Protection Act (CCSPA). This is the centerpiece, and it’s what most critical infrastructure operators need to focus on. The CCSPA creates a regulatory framework requiring “designated operators” to protect their “critical cyber systems,” with mandatory cybersecurity programs, supply-chain risk management, incident reporting, and record-keeping, all backed by audits and significant penalties.

Importantly, the CCSPA comes into force in phases, with the operational details: who exactly is designated, what the reporting windows are, and what programs must contain, set by regulations that are still to come. That phased rollout is your runway. More on that below.

Who Is Covered (and Why You Shouldn’t Tune Out If You’re Small)

The CCSPA applies to six categories of “vital services and vital systems”:

Telecommunications services
Interprovincial or international pipeline and power line systems
Nuclear energy systems
Federally regulated transportation systems
Banking systems
Clearing and settlement systems

Oversight is distributed across six sector regulators, including the Superintendent of Financial Institutions, the Bank of Canada, the Ministers of Industry and Transport, the Canadian Energy Regulator, and the Canadian Nuclear Safety Commission, each with inspection, audit, and compliance-order powers.

Three things smaller operators should understand:

Designation isn’t about size. The classes of designated operators will be set by regulation, and there’s no revenue or headcount floor in the Act. If you own or operate a system whose compromise “could affect the continuity or security of a vital service or vital system,” you can be designated — whether you have a 40-person SOC or a two-person IT team.

The list can grow. The federal government of Canada can add new vital services and new classes of operators over time. Legal observers, including Osler and BLG, expect coverage to expand as the regime matures.

Even the undesignated will feel it. Designated operators must mitigate supply-chain and third-party cyber risk as soon as it’s identified. In practice, that obligation flows downhill: if you sell to, connect with, or provide services to a designated operator, expect security requirements, audit rights, and incident-notification clauses to start showing up in your contracts. Provincially regulated utilities and municipal systems aren’t directly covered, but C-8 is the clear signal of where Canadian regulatory expectations are heading — and frameworks like NERC CIP already reach Canadian electric utilities through provincial regulators.

The Obligations, In Plain Language

Strip away the legal drafting, and the CCSPA asks five things of a designated operator:

1. Know your critical cyber systems and stand up a cybersecurity program fast. Within 90 days of your class being designated, you must establish a cybersecurity program that identifies and manages cyber risks (including supply-chain and third-party risks), protects your critical cyber systems, detects incidents, and minimizes their impact. You must file that program with your regulator, implement it, and review it at least annually.

2. Manage your supply chain. When you identify a supply-chain or third-party risk, you have a duty to mitigate it promptly, and in line with guidance from the Communications Security Establishment. For many operators this is the most demanding requirement, because it forces a level of vendor risk management that few have formalized.

3. Report incidents within 72 hours. Incidents affecting a critical cyber system must be reported to the CSE’s Canadian Centre for Cyber Security within a window to be set by regulation, capped at 72 hours, with your sector regulator notified immediately after. The threshold is deliberately broad: incidents that interfere or may interfere with a vital service qualify. You can’t report what you can’t see, and you can’t meet a 72-hour clock with a detection capability that takes weeks to notice an intrusion.

4. Comply with cybersecurity directions. The government can direct operators to take specific protective measures, and those directions may be confidential: you may be legally barred from disclosing they exist.

5. Keep records in Canada. You must maintain records documenting your program, incidents, supply-chain mitigations, and compliance with directions, and be prepared for regulator audits.

The enforcement stakes are real: administrative monetary penalties of up to $15 million per violation (up to $500,000 for individuals), with each day of a continuing violation counting separately, plus criminal offences for serious contraventions. Directors and officers can be personally liable. But here’s the detail that should shape your entire response: the Act provides a due diligence defence. Documented, board-visible, honestly implemented compliance efforts matter. Perfect security is not the standard; demonstrable diligence is.

From Legislation to Operations: A Practical Readiness Roadmap

The gap between “read the Act” and “pass an audit” is where most organizations, especially smaller ones, get stuck. Here’s a sequence we recommend, aligned with the Cyber Centre’s Cross-Sector Cyber Security Readiness Goals — 36 foundational, achievable goals designed precisely for organizations that don’t have enterprise-scale security teams.

Step 1: Establish scope — inventory before anything else. You can’t identify your “critical cyber systems” if you don’t have an accurate, current picture of what’s on your network. Automated network discovery and inventory, the kind provided by platforms like Infosim StableNet, gives you a live map of devices, configurations, and dependencies, and doubles as the documented evidence base your regulator will expect. Determine which systems, if compromised, could affect the continuity of the vital service you deliver. Not everything will be in scope; a defensible scoping exercise keeps your program focused and affordable.

Step 2: Gain visibility into the traffic that matters. As we often say: you cannot secure what you cannot see. Detection and 72-hour reporting both depend on knowing what’s actually happening on your network. Network TAPs and packet brokers from partners like Garland Technology, Cubro, and Profitap deliver a complete, reliable copy of network traffic to your monitoring and security tools. In OT environments — substations, pipelines, plant floors — hardware data diodes let you extract that visibility and feed it safely to detection tools while physically guaranteeing nothing can flow back into the control network. That’s protection and detection from a single architectural decision, and it gives auditors something unambiguous.

Step 3: Build detection and response you can actually run. A lean team doesn’t need a dozen consoles; it needs consolidated, high-signal tooling. This is where network detection and response (NDR) earns its place at the centre of a CCSPA program, and it’s why we’ve partnered with Stamus Networks, whose Clear NDR platform is built on Suricata, the world’s most widely deployed open-source network security engine.

Fed by the TAP-and-diode visibility fabric from Step 2, Clear NDR combines intrusion detection, network security monitoring, and behavioural anomaly detection in a single system, and distills the noise into high-confidence Declarations of Compromise®: exactly the kind of clear, evidence-backed signal a small team needs when deciding, on a 72-hour clock, whether an event is reportable. Automated alert triage and guided threat hunting mean you don’t need a deep bench of analysts to operate it, and because it’s offered in both a free open-source Community edition and a commercial Enterprise edition, operators can start proving value now and scale as designation approaches.

Alongside it, AI-driven network forensics and managed endpoint detection and response, including 24/7 MDR for organizations without an around-the-clock SOC, round out the “detect” and “minimize impact” pillars of the mandated program without requiring you to build a security operations centre from scratch.

Step 4: Make your evidence trustworthy with precision time. This one is easy to overlook and painful to retrofit. Incident reports, forensic timelines, and audit records are only as credible as their timestamps. If your logs come from systems whose clocks disagree, reconstructing a 72-hour reportable incident becomes guesswork. Resilient, GNSS-backed network time from partners like Safran ensures every log, packet capture, and alert across IT and OT shares one accurate, traceable clock, a foundational control we’ve written about before in the context of Zero Trust.

Step 5: Validate, document, repeat. Before major changes to critical systems, test and verify that security and performance hold up. Review the program annually as the Act requires, keep your records current, and brief your board regularly; remember, the due diligence defence rewards exactly this discipline. As regulations arrive and your designation is confirmed, you’ll be adjusting details, not starting over.

The Runway Won’t Last Forever

The phased coming-into-force of the CCSPA is a gift to operators who use it. The 90-day clock for filing a cybersecurity program starts when your class is designated; 90 days is not enough time to build a program from a standing start. The operators who fare best under this regime will be the ones who treated the period between Royal Assent and designation as their build phase, not their waiting phase.

The encouraging news: nothing in the CCSPA asks for exotic technology. Asset inventory, network visibility, detection, incident response, supply-chain hygiene, accurate records: these are fundamentals, well understood and readily deployable, even for organizations without deep in-house security expertise. What most operators lack isn’t capability; it’s a clear, sequenced plan.

That’s where we can help. Telnet Networks has spent more than 25 years helping Canadian utilities, transportation operators, telecoms, government agencies, and industrial companies build secure, visible, well-managed networks. Our engineering team can walk through your environment, map your current posture against the CCSPA’s program requirements, and design a practical, right-sized roadmap to compliance, from visibility architecture to detection tooling to precision time.

Ready to build your Bill C-8 action plan? Contact the Telnet Networks team for a no-obligation consultation.

Further reading: the full text and status of Bill C-8 on LEGISinfo; the Government of Canada’s Royal Assent announcement; legal analyses from Osler, BLG, and McCarthy Tétrault; and the Cyber Centre’s Cyber Security Readiness Goals.

Network Security

Data Diodes in ICS Environments: Why One-Way Visibility Is Becoming Non-Negotiable

“You cannot secure what you cannot see.”

It’s a mantra we come back to often, because it’s true. Your security tools are only ever as good as the data they receive. But in operational technology (OT) environments, that principle comes with a hard constraint that doesn’t exist in the IT world: the act of gaining visibility can’t introduce a new way into the network. Every monitoring connection you add to an industrial control system (ICS) is a potential path an attacker could travel in the wrong direction.

That tension, needing complete visibility while guaranteeing nothing flows back toward the plant floor, is exactly what data diodes were built to resolve. As IT and OT environments continue to converge, data diodes have moved from a niche defence-and-nuclear technology to a mainstream control for any organization serious about protecting critical infrastructure. Here’s a practical look at what they are, how they differ from the network TAPs you may already be using, and where they deliver the most value.

What Is a Data Diode?

A data diode is a purpose-built hardware device that allows network traffic to travel in one direction only. Think of it the way you’d think of its electronic namesake: current flows one way and is physically blocked from flowing the other. A network data diode does the same thing with packets. Data can leave a protected segment so it can be monitored, logged, or replicated, but nothing can be sent back in.

The critical word there is physically. A data diode doesn’t rely on a firewall rule, an access control list, or a software policy that could be misconfigured, disabled, or defeated. The one-way property is enforced in the hardware itself. Even if every other control in your stack were compromised, a data diode cannot carry traffic backward into the OT network. That deterministic, hardware-enforced guarantee is why diodes are trusted in the highest-security environments in the world, from nuclear facilities to national defence networks, and why they’re increasingly showing up in substations, water treatment plants, and manufacturing floors.

How Data Diodes Differ From Traditional Network TAPs

If you already run network TAPs (Test Access Points), it helps to be precise about where a data diode fits, because the two are related and often confused. A traditional network TAP is a visibility device: it sits in-line on a link, creates a complete, full-duplex copy of the traffic, and sends that copy to your monitoring and security tools. Unlike SPAN or port-mirroring on a switch, TAPs don’t drop packets under load or alter the timing of frames, and they keep working even if a tool is removed or loses power. The job of a TAP is faithful, complete duplication of what’s on the wire. (For a refresher, see our overview of network visibility solutions.)

A data diode is a security device. Its job isn’t just to copy traffic but to guarantee the direction traffic can travel, making absolutely certain the monitoring path can never become an injection path back into the control network. Some mirroring and monitoring connections are bidirectional by design, which quietly creates an opening: a tool plugged in to watch the network can, in principle, also talk to it. A diode closes that door permanently. Increasingly the two are combined in a single data diode TAP, which delivers a complete copy of traffic to your tools while physically preventing any packet from being sent back toward the live network. You get the fidelity of a TAP with the one-way assurance of a diode: full packet-level visibility, with a hardware guarantee that the visibility itself adds zero risk.

Why Data Diodes Are Essential in ICS Environments

For decades, OT systems were protected mostly by isolation, and that era is over. Digital transformation has connected ICS to corporate IT, cloud analytics, IoT sensors, and remote access in pursuit of efficiency and better data. The same connectivity that lets you stream substation telemetry to a central platform also widens the attack surface dramatically, and the legacy SCADA, PLCs, and IEDs running critical processes were never built to defend themselves, nor can they always be patched on an IT cadence without risking uptime or safety. (CISA keeps a useful primer in its Industrial Control Systems resources.)

This is exactly what data diodes were made for. When you need to get operational data out of a protected zone, whether to a SIEM, a historian, an intrusion detection system, or a cloud dashboard, without creating any way back in, a diode is the cleanest answer. It lets you embrace modern analytics while keeping the control network sealed off from inbound threats, lateral movement, and remote compromise, complementing the rest of a layered network and endpoint security program.

There’s also a growing compliance dimension, and for Canadian operators it is becoming concrete:

NERC CIP governs the North American bulk electric system and is enforced in Canada through provincial regulators, so Canadian utilities are squarely in scope. Physically preventing inbound electronic access can simplify several requirements.
Canada’s Critical Cyber Systems Protection Act (CCSPA), advancing through Bill C-8, will require designated operators in federally regulated energy, pipeline, transportation, telecom, finance, and nuclear sectors to run a cybersecurity program, manage supply-chain risk, and report incidents to the Communications Security Establishment, with significant penalties for non-compliance.
CSA N290.7, the cyber security standard the Canadian Nuclear Safety Commission applies to nuclear facilities, alongside the U.S. NRC RG 5.71, both point to hardware-enforced one-way flow between security levels.
IEC 62443 (international) and the EU NIS2 Directive round out the global picture, recognizing diodes as a valid isolation mechanism.

Software controls alone are hard to prove and easy to undermine. A hardware diode gives auditors something unambiguous: a device that, by physics, cannot pass traffic the wrong way. The Canadian Centre for Cyber Security publishes OT-specific guidance worth reviewing as your program matures.

How Data Diodes Strengthen OT Security Monitoring

The real value of a data diode shows up when you fold it into a broader visibility architecture. A few of the most common patterns:

Feeding security tools safely. Intrusion detection and OT-aware monitoring platforms, such as Nozomi, Claroty, or a Zeek/Suricata based solutions like Stamus Networks, need a complete copy of network traffic to baseline normal behaviour and flag anomalies. A data diode TAP delivers that full feed while guaranteeing the tool can never reach back into the control network. Your detection improves and your attack surface doesn’t. (Our post on enhancing OT security through network visibility covers the broader picture.)

One-way data replication to IT and the cloud. Plants routinely need to move historian data, process telemetry, and event logs from the OT side up to enterprise analytics, reporting, and cloud platforms. A diode lets that data flow outbound continuously while making inbound connections physically impossible.

Securing the SPAN connection. Many teams still rely on switch SPAN ports for visibility. Placing a diode between a SPAN port and the monitoring tool hardens that connection, removing the back-flow risk that bidirectional mirroring would otherwise create.

Monitoring air-gapped and segmented zones. Even networks that are nominally air-gapped need oversight. A diode extracts telemetry from an isolated segment for monitoring without ever bridging it to a less-trusted network, preserving the isolation while eliminating the blind spot.

When deployments grow, diodes pair naturally with network packet brokers, which aggregate, filter, and load-balance traffic so each tool receives exactly the data it needs. The result is an end-to-end visibility fabric: complete packet capture, intelligent distribution, and a hardware guarantee of one-way flow at the boundary.

A Closer Look at the Hardware: Garland and Profitap

The right diode depends on your media types, the number of SPAN or sensor connections you need to handle, and whether it lands in a clean data-centre rack or a rugged plant-floor cabinet. Two of our partners build purpose-built diode hardware spanning that whole range.

Garland Technology

Garland Technology pioneered the modern network TAP and offers a dedicated line of Hardware Data Diodes that connect SPAN and mirror ports safely to monitoring and security sensors, enforcing one-way flow through physical hardware separation inside the diode. Because they are unmanaged hardware with no IP or MAC address and no software to exploit, they install fast and carry no subscription, port, or feature fees. The portable CTAP-P1GCCREG regenerates two SPAN inputs to your sensors over copper at 10/100/1000M; the P1GCSSP adds copper-and-SFP flexibility with aggregation and regeneration of three SPAN inputs; and the 1U half-rack INT1G10CSASP is a high-density aggregator that consolidates eight copper SPAN inputs down to two SFP monitoring ports. AC, DC, rack, and DIN-rail options make the portables a practical fit for substations and other space-constrained OT cabinets. Garland’s Visibility 101 guide to hardware data diodes and OT/ICS network security pages go deeper.

Profitap

Profitap, based in Eindhoven, builds precision visibility hardware, and its Network Data Diodes provide deterministic, hardware-enforced unidirectional communication so monitoring tools can receive traffic while it stays physically impossible to send anything back into production. The flagship C1DD-1G delivers one-way copper visibility across all seven OSI layers with no packet loss, redundant power supplies for high availability, and a compact form factor that fits roughly a third of a rack unit. Profitap also builds data diode functionality directly into its Copper TAPs and the ProfiShark 1G portable capture device, preventing monitoring gear from injecting traffic back onto the link, while its ruggedized industrial and OT TAPs add DIN-rail mounting and DC power for the plant floor. That makes them a natural fit for teams working toward CCSPA or NERC CIP compliance. See our vendor spotlight on Profitap and Profitap’s ICS/OT network monitoring resources for more.

Where Data Diodes Deliver the Most Value

Data diodes pay off anywhere the consequences of an inbound compromise are severe and the need to extract data is constant. A few sectors stand out:

Electric utilities and substations. Modern smart-grid substations generate enormous volumes of real-time data that must reach central energy management and SCADA systems. Diodes let utilities ship that data upstream for monitoring and compliance while enforcing the unidirectional separation NERC CIP demands, keeping transmission and distribution control systems insulated from the corporate network. For Canadian operators answering to provincial regulators and, increasingly, the CCSPA, that hardware boundary is a clean way to demonstrate control.

Nuclear power and safety-critical systems. Few environments tolerate less risk, and here one-way flow isn’t just best practice, it’s regulated. Canadian nuclear operators work to CSA N290.7 under the Canadian Nuclear Safety Commission (and U.S. operators to NRC RG 5.71), both of which call for hardware-enforced separation between security levels. The same logic extends to safety-critical systems such as railway signalling networks.

Water and wastewater treatment. Often run by smaller municipal teams with limited cybersecurity resources, these facilities have become frequent targets. Diodes offer a low-maintenance, set-and-forget way to gain visibility into treatment processes without exposing the control systems that manage chemical dosing, pumps, and valves.

Oil, gas, and pipelines. Geographically dispersed assets and a tightening regulatory picture (including the CCSPA’s coverage of federally regulated pipelines) make one-way data export from remote sites particularly valuable. You get the telemetry you need at headquarters without opening a return path to field controllers.

Manufacturing and Industry 4.0. As factories connect production lines to MES, analytics, and cloud platforms, diodes let manufacturers feed OT data into IT systems for optimization and predictive maintenance while protecting production from ransomware and IT-side compromise.

Government, defence, and critical research. The original home of the data diode, where transferring data between networks of different classification levels without any possibility of back-flow is a foundational requirement.

A representative example ties it together. Picture a Canadian electric utility connecting dozens of substations to a central monitoring centre. Engineers want full packet visibility at each site to feed an OT intrusion detection platform, and they need substation data flowing to corporate analytics, all while staying inside NERC CIP scope. By deploying data diode TAPs at each substation, the utility gives its detection tools a complete, faithful copy of the traffic and streams telemetry northbound to the SOC, with the hardware guaranteeing that none of those monitoring paths can ever reach back into the control systems. Visibility goes up, audit scope gets simpler, and the attack surface stays flat.

Bringing It Together

Visibility and security used to feel like a trade-off in OT, where every tool you added to watch the network was another potential way in. Data diodes dissolve that trade-off, delivering the complete, packet-level visibility that modern threat detection and compliance demand while a simple law of physics ensures the visibility can never become a liability. Whether you’re hardening SPAN connections, feeding an OT detection platform, or designing one-way data export from a protected zone, the right combination of TAPs, packet brokers, and data diodes makes the difference, and that’s the kind of design work we do every day.

Ready to add secure, one-way visibility to your OT environment? Reach out to the experienced Telnet Networks sales and engineering team for a no-obligation consultation. We’ll walk through your specific environment, your compliance drivers, and the right diode and visibility architecture to get you there. Contact us »

Network Monitoring Network Security

The Hidden Foundation of Network Security: Why Precision Time Matters in a Zero Trust World

Zero Trust Architecture has fundamentally changed how organizations think about network security. Identity must be continuously verified. Every access request is interrogated. Trust is earned moment to moment, not granted by default. It’s a powerful model, but it rests on a foundation that many network architects and SOC teams rarely examine closely enough: time. (If you’re looking for a grounding primer on Zero Trust itself, our practical guide to Zero Trust implementation is a good starting point.)

Precise, synchronized, and trustworthy time underpins nearly every security control that Zero Trust depends on. Without it, logs become unreliable, authentication tokens can be manipulated, and anomaly detection loses its ability to reconstruct the sequence of events. In a ZTNA environment, where the accuracy of continuous verification depends on precise event ordering and time-bounded access grants, clock drift is not merely an operational inconvenience, it’s a security gap.

This post explores how Network Time Protocol (NTP), Precision Time Protocol (PTP), and advanced solutions like White Rabbit-based timing systems enable and strengthen network security and Zero Trust implementations, and why investing in a hardened time infrastructure deserves a place on every security architect’s roadmap.

Why Time Is a Security Primitive

Most security practitioners understand that time matters at an abstract level. Logs need timestamps. Certificates have validity windows. Kerberos tokens expire. But the operational reality of just how much security-critical logic depends on synchronized time is often underappreciated until something goes wrong.

Consider what precise, trustworthy time enables across a modern security stack:

Log correlation and SIEM accuracy : When endpoints, firewalls, identity platforms, and network devices have misaligned clocks, even small discrepancies (tens of milliseconds to seconds) make it impossible to accurately reconstruct attack timelines. A security incident that spans multiple systems becomes a jigsaw puzzle without a common temporal reference.
Certificate and PKI validation : TLS certificates, code signing, and identity certificates all rely on clock accuracy to determine whether a certificate is valid, expired, or revoked. Clock skew can cause valid certificates to appear expired, or, more dangerously, allow expired certificates to be accepted as valid.
Authentication token lifetimes : Kerberos, OAuth, JWT, and SAML tokens are all time-bounded. Drift between the issuing authority and the verifying endpoint creates windows of vulnerability. Excessive skew can lock out legitimate users; insufficient skew checking can allow replayed or extended tokens.
Behavioral baselines and anomaly detection : Machine learning-driven NDR and SIEM tools build behavioral models based on temporal patterns of activity. Without a consistent time reference, “working hours” anomalies, connection frequency thresholds, and lateral movement detection all become less reliable.
Forensic integrity : During incident response, timestamps in logs, packet captures, and audit trails are submitted as evidence. If timestamps across systems cannot be traced to a common, authoritative time source, the forensic value of the data is diminished and potentially challenged.

In a Zero Trust model, where every transaction must be continuously verified and logged for later audit, each of these functions is load-bearing. The accuracy of your time infrastructure directly affects the integrity of your security posture.

Understanding the Timing Stack: NTP, PTP, and White Rabbit

Not all time synchronization is created equal. The protocol you use, and how it’s deployed, determines the accuracy, security properties, and attack surface of your time infrastructure. For a deeper technical foundation, our complete guide to network time synchronization covers the full landscape.

Network Time Protocol (NTP)

NTP has been the workhorse of network time synchronization for decades. It provides millisecond-level accuracy across IP networks and is supported by virtually every device on the planet. For many security use cases like log correlation, certificate validation, and authentication token management, NTP is entirely sufficient, provided it’s properly secured.

The challenge is that traditional NTP deployments are often not. NTP was not designed with security in mind. Without NTS (Network Time Security), the modern authenticated extension to NTP, synchronization traffic can be subject to:

On-path manipulation: An attacker positioned between a client and an NTP server can alter timestamps in transit, shifting a device’s clock forward or backward.
Replay attacks: Recorded NTP responses can be replayed to steer a target’s clock without active interception.
Denial of service: Flooding or disrupting NTP servers can cause clients to drift, degrading authentication and log accuracy across the network.

For SOC teams and security architects, the key takeaway is this: if your environment is running unauthenticated, internet-sourced NTP without monitoring, your time infrastructure is an unaudited trust surface. In a Zero Trust context, that’s an inconsistency worth closing. Our cybersecurity checklist for secure timing outlines the core security features every time server deployment should include.

Precision Time Protocol (PTP / IEEE 1588)

Where NTP operates at millisecond precision, PTP (IEEE 1588) achieves sub-microsecond accuracy, and in hardware-assisted deployments, sub-nanosecond performance. PTP uses a combination of timestamping at the hardware level and a master-slave hierarchy (now referred to as grandmaster-boundary clock architecture in IEEE 1588-2019) to distribute highly accurate time across a network.

From a security standpoint, PTP offers meaningful advantages over NTP:

Hardware timestamping eliminates software-layer jitter and makes it significantly harder for attackers to introduce timing manipulation without physical access to network infrastructure.
Cryptographic authentication options in PTP profiles allow grandmaster clocks and boundary clocks to sign their synchronization messages, verifying source integrity.
Tighter accuracy means better event ordering in high-frequency environments , critical for financial-grade logging, high-speed trading, and industrial control systems, but increasingly important for any organization generating high volumes of security telemetry.

For enterprise and government networks running OT/IT converged environments, 5G infrastructure, or latency-sensitive applications, PTP is the appropriate baseline. It is also increasingly specified in regulatory frameworks that require traceable, tamper-evident timekeeping. Telnet’s precision timing solutions span the full range from NTP grandmasters to hardware-assisted PTP deployments.

White Rabbit: Sub-Nanosecond Precision for Critical Infrastructure

Originally developed at CERN for particle accelerator control systems, White Rabbit (WR) is an open-standard extension of PTP that achieves sub-nanosecond accuracy across fibre-optic networks, synchronizing over 1,000 nodes to within less than 1 nanosecond over links up to 10 kilometres in length.

White Rabbit combines Synchronous Ethernet (SyncE) with precise hardware phase measurements and IEEE 1588 PTP messaging to achieve a level of timing precision that has historically been the domain of laboratory and scientific computing environments. That is changing. As critical infrastructure protection, defence networks, and high-assurance environments increasingly demand verifiable, traceable time with sub-nanosecond integrity, White Rabbit is moving from the research world into operational security infrastructure.

For ZTNA deployments in high-security or critical infrastructure contexts such as telecommunications, power grids, defence, or large financial networks, White Rabbit-based timing provides a hardened, verifiable timing root that supports the most demanding requirements for log integrity, event reconstruction, and forensic accuracy. Learn more about White Rabbit solutions available through Telnet Networks.

Precision Time as a Zero Trust Enabler

The connection between precision time and Zero Trust is not theoretical — it’s structural. ZTNA operates on time-bounded tokens, continuous re-authentication, just-in-time access windows, and behavioral anomaly detection that depends on accurate event ordering. Every one of those controls degrades when clocks drift or diverge.

Clock manipulation is also a legitimate attack vector. An adversary who can skew a target device’s clock, even by a few seconds, can extend the validity of stolen tokens, corrupt the ordering of forensic logs, or cause authentication failures that mask lateral movement. In an environment built around “assume breach,” leaving time as an unverified trust input is a design inconsistency.

A well-designed time infrastructure doesn’t replace the other pillars of Zero Trust; It makes each of them more accurate and harder to subvert.

Building a Hardened Time Infrastructure

Implementing precision time as part of a security strategy involves more than pointing devices at a public NTP pool. A hardened time infrastructure for a security-conscious environment typically includes:

Authenticated time sources: Deploying NTS-secured NTP or cryptographically authenticated PTP to ensure time signals cannot be forged or manipulated in transit.
Redundant, diverse time references: Relying on a single GNSS source creates a single point of failure. Hardware-based grandmaster clocks with multiple reference inputs (GNSS, OCXO holdover, PTP upstream) provide resilience against spoofing, jamming, and outage. Interference Detection and Mitigation (IDM) capabilities add another layer of protection for GNSS-dependent timing infrastructure.
Network-internal distribution: Minimizing dependence on external NTP servers by deploying boundary clocks and internal PTP grandmasters reduces exposure to external attack surfaces.
Time monitoring and alerting: Just as you monitor network traffic for anomalies, monitoring clock health across critical nodes, detecting drift, jitter, or unexplained offsets should be part of SOC operations.
Traceability to authoritative UTC sources: For regulated environments, demonstrating that timestamps are traceable to UTC through an auditable chain of custody is increasingly a compliance requirement.

Safran’s timing portfolio, including their SecureSync platform and White Rabbit solutions, represents the high-assurance end of this spectrum, delivering GNSS-disciplined, highly redundant grandmaster clocks capable of maintaining sub-microsecond accuracy even during GNSS outage through precision oscillator holdover. Their White Rabbit implementations bring this level of accuracy directly into critical network infrastructure.

Timebeat takes a complementary approach, delivering software-defined PTP synchronization that enables accurate, resilient time distribution across hybrid and cloud-connected environments. Timebeat’s mesh-based PTP architecture removes traditional single points of failure in timing distribution trees, making high-accuracy time achievable in dynamic, distributed environments where hardware-only solutions face constraints.

Together, solutions like these address the full range of enterprise time infrastructure needs — from the hardened core of a critical facility to the distributed edges of a hybrid cloud environment.

Time Security Is Network Security

Time synchronization rarely gets a line item in a security budget, but in a Zero Trust environment, it should. An unauthenticated, unmonitored NTP deployment is an unaudited trust surface, and that’s an inconsistency that Zero Trust was designed to eliminate.

The right answer isn’t always a full PTP overhaul. For many organizations, the first step is simply authenticating existing NTP with NTS, monitoring for clock drift as part of SOC operations, and ensuring time sources are resilient and traceable. From there, the path to hardware-assisted PTP or White Rabbit is well-understood and incremental.

At Telnet Networks, we work with organizations across Canada to assess time infrastructure gaps and align timing solutions with broader network security and Zero Trust strategies. Get in touch to start the conversation.

Ready to assess your time infrastructure’s role in your Zero Trust strategy? Contact the Telnet Networks team to start the conversation.

Network Access Network Security Time Server Time Server NTP Time Synchronization zero trust

Understanding Keysight Threat Simulator & Adding Value in the First 24 Hours

In 2026, assuming your network is secure because you bought the “best” tools is no longer a viable strategy. The attack surface has mutated rapidly; identity is the new perimeter, and AI-driven threats can execute in minutes.

The real challenge isn’t acquiring security controls (Firewalls, EDR, SIEM); it’s verifying that they are configured correctly and operating effectively. This concept—constantly testing your defenses against real-world adversarial behavior—is called Breach and Attack Simulation (BAS).

Today, we are diving deep into one of the industry’s premier BAS platforms: Keysight Threat Simulator, and outlining how you can extract measurable value from the platform in your very first day of deployment.

The Core of the Matter: What is Keysight Threat Simulator?

Keysight Threat Simulator is a safe, scalable, and continuous Breach and Attack Simulation platform. Its primary purpose is to eliminate security assumptions by proactively validating your entire security stack against a library of thousands of simulated attacks.

Unlike a static penetration test that provides a snapshot in time, Threat Simulator provides continuous visibility. It uses software agents (probes) deployed safely in your production environment—behind your firewalls, on endpoints, and in the cloud. These agents communicate with each other and Keysight’s “Dark Cloud” to emulate complete attack chains, without using real malware or compromising actual user data.

By running these controlled simulations, you achieve three critical goals:

Identify Misconfigurations: Discover where a firewall rule drift or an outdated EDR policy is failing to block known threats.
Validate Logging & Alerting: Ensure that when a control does block an attack, your SIEM actually receives the alert. Many organizations have blocking power but are functionally blind.
Prioritize Remediation: Stop guessing what to fix first. Threat Simulator prioritizes gaps based on real-world risk and provides specific, vendor-agnostic remediation steps (like Snort rules or policy changes).

Adding Value in the First 24 Hours: A Phase-by-Phase Guide

The biggest mistake new BAS users make is trying to test everything at once. This leads to alert fatigue and data overload. The goal for your first 24 hours is foundational validation: ensure the agents are deployed, integrated, and that basic security communication is happening.

Here is your Day 1 playbook:

Phase 1: The Baseline (Hours 1–4)

Objective: Verify that the infrastructure is ready and your controls can execute fundamental blocking.

Deployment: Deploy at least two agents: one in a “Protected” zone (trusted internal network) and one “Unprotected” (DMZ or outside).
The “Sanity Check” Audit: Run a simple, low-risk audit, such as a clear-text transfer of the EICAR test file over HTTP.
The Question: Did my perimeter firewall/IPS block the download? In the Threat Simulator dashboard, this test must show as “Blocked.” This confirms the fundamental blocking loop is intact.

Phase 2: The Visibility Audit (Hours 5–12)

Objective: Test your detection logic and logging pipeline. Does your SOC actually see the attack?

Integrate Your SIEM/EDR: Connect Threat Simulator to your central logging platform (Sentinel, Splunk, CrowdStrike, etc.) via API.
The Lateral Movement Test: Simulate a common internal technique, like an SMB brute-force or internal port scan, between your two agents.
The Analysis: This is the most critical check. Ignore the Threat Simulator dashboard for a moment. Open your SIEM. Did a corresponding alert fire within 5–10 minutes?

If Keysight says “Blocked” but your SIEM shows “No Alert Found,” you have a serious Visibility Gap. You must verify your logging configuration.

Phase 3: Targeted Testing (Hours 13–24)

Objective: Move beyond basic validation and test against a modern, relevant adversarial technique.

Select a MITRE Audit: Choose a technique relevant to the 2026 threat landscape, such as T1059.001 (PowerShell Execution).
Run the Audit: Keysight will attempt to execute obfuscated PowerShell scripts that mimic ransomware behavior.
Remediate and Re-Test: If it fails (attack succeeds), review the generated Remediation Report. Apply the suggested rule change on one test machine. Immediately re-run the same audit. You have now found, fixed, and verified a gap in a single day.

The Takeaway: 2026 Priority Testing Cheat Sheet

Not all MITRE techniques are created equal. As we move deeper into 2026, attackers are focusing on identity theft and bypassing behavior-based detection. When you are ready to move past Day 1, prioritize these five areas within your simulator:

Technique ID	Attack Name	Why It’s Critical in 2026
T1055	Process Injection	Continues to be the #1 evasion technique, used to hide malicious activity inside legitimate processes.
T1059.001	PowerShell	Attackers are now using highly specialized, automated PS1Bots that employ complex encryption to bypass traditional inspection.
T1078.004	Valid Cloud Accounts	Identity is the new perimeter. Testing UEBA (User Behavior) to catch impossible travel or token theft is mandatory.
T1562.001	Impair Defenses	This is the “First Move” in major attacks. You must test if your system alerts when an attacker attempts to stop your EDR service.
T1071.001	Web Protocols (C2)	Attackers are “Living off the Cloud,” hiding Command & Control heartbeats within legitimate API calls to providers like Microsoft or OpenAI.

Looking Beyond Day 1: BAS as a Long-Term Strategy

The true power of Keysight Threat Simulator is realized when it moves from an ad-hoc testing tool to a continuous, structured program.

BAS is not just for security validation; it is a critical tool for long-term security posture management and compliance.

Continuous Posture Validation: Integrate Threat Simulator into your CI/CD pipelines or network change windows. Every time a new firewall rule is pushed or an endpoint image is updated, an automated BAS audit should trigger. This ensures that environmental changes do not accidentally introduce “security drift” or reopen old holes.
Mapping to Compliance Frameworks: Many regulatory frameworks (ISO 27001, NIST 800-53, PCI DSS 4.0) mandate regular security testing and validation. BAS allows you to generate continuous compliance reports, mapping your test results directly to specific controls within those frameworks. This shifts compliance from an annual, painful audit to a continuous state of readiness.
Red Teaming At Scale: Your expensive, human Red Teams should not be wasting time testing basic Snort rules. Use Threat Simulator to handle the 90% volume of known attack behaviors (testing your “Hygiene”). This frees your human analysts to focus 100% of their time on highly complex, custom adversary emulation.

By integrating Keysight Threat Simulator into your continuous operations, you stop managing security based on the tools you bought and start managing it based on the behaviors you are proven to stop.

Are you ready to move from assumption to validation? Contact Telnet Networks today to discuss how Keysight Threat Simulator can revolutionize your continuous security testing strategy.

breach and attack Keysight Network Security threat simulation