Subscribe
Share
Share
Embed
Welcome to Your Network’s Edge by RAD, where innovation meets connectivity. This podcast highlights how RAD’s technologies are empowering businesses and service providers. In every episode, we provide in-depth insights into the world of IoT, 5G, network Edge, and AI-powered networking, showcasing how RAD’s solutions empower service providers and critical infrastructure operators to stay ahead.
Whether you’re a communications service provider, an industrial IoT professional, or someone passionate about the tech driving modern connectivity, this podcast offers valuable perspectives. Tune in to discover how RAD’s customer-centric approach and market-leading solutions are redefining networking for a connected world.
Welcome to your network's edge, where innovation meets connectivity. This podcast explores IoT, five g, the network edge, and AI powered networking. RAD's solutions are empowering communication service providers and critical network operators to stay ahead in a connected world. Let's dive into the insights that drive modern connectivity.
2:Imagine your entire grid or water supply could be disrupted, not because hackers broke in, but because you simply couldn't see what was happening at the edge. That blind spot is where the real risk hides.
3:That's exactly what keeps OT and security leaders up at night. A recent webinar from RAD and REBO dove into how visibility and secure connectivity intersect, especially with so much critical infrastructure at the edge.
2:In this webinar episode, you'll get real world insight on why secure tunnels aren't enough, how to scale monitoring across hundreds of sites, and what new regulations mean for OT security.
3:We'll walk you through the technical gaps at the grid's edge, how RAD and REBO integrate for simplicity, and answer the top questions OT leaders are asking. Let's kick off with why these edge locations are now the new cyber frontline.
2:So we mentioned earlier that secure communication is only half the battle. What really goes wrong at these forgotten substations?
3:It's wild. Most of these sites are well connected, but almost invisible from an operational perspective. Operators can reach them, but they don't really know what's happening inside. That's the dangerous blind spot.
2:In other words, the tunnel is up, but unless something breaks, issues stay hidden for months. Secure connectivity doesn't mean secure operations.
3:Exactly. And when something finally goes wrong, like a misused command or strange process drift, it's usually too late. That invisibility is the real risk, not just unauthorized access.
2:That brings me to something we hear all the time. We've got firewalls, VPNs, even encrypted links aren't recovered.
3:Such a common misconception. Secure tunnels protect the path, not the payload. They don't tell you if someone's misusing allowed commands or if processes are silently drifting off course.
2:And if malware or a rogue insider leverages existing permissions, you might not see any alarm, just business as usual, until it's not.
3:Right. You need eyes on the actual OT behavior, not just who's knocking at the door.
2:Let's touch on the scale challenge. Operators ask, how do we secure hundreds of remote sites without drowning in complexity?
3:It's a headache. If security adds manual work or constant tuning, it just won't scale. Most of these substations have one engineer visiting every few weeks or less.
2:So true. We need solutions that are standardized, centrally visible, and non intrusive. Anything heavy handed just gets bypassed in practice.
3:And that's why monitoring has to be passive, protocol aware, and easy to integrate. Otherwise, it's just another box to maintain.
2:Speaking of standards and regulations, how are things like n I s two and I e c six two four four three shifting the conversation on OT security?
3:Operators can't just say, we're protected anymore. Regulators want proof, continuous detection, visibility, even evidence of response. It's a huge step up from just showing static architecture diagrams.
2:So visibility isn't optional. It's now table stakes. And if you can't demonstrate ongoing control, you're not compliant.
3:Exactly. These standards are pushing everyone to monitor at the OT edge. Being out of sight, out of mind isn't going to fly.
2:So let's break down what a strong foundation looks like. For RAD, it starts with the IoT gateway at the edge. Can you walk us through how it's set up?
3:Sure. RAD's IoT gateway SecFlow connects substations or DER sites using fiber, four g, five g, even WiFi or serial ports for old devices. It's built for flexibility with enough RAM and storage to run extra applications.
2:That's where the integration comes in. By running Rebo's monitoring directly as a container on Secflow, you avoid extra hardware and get both connectivity and visibility in one package.
3:Right. Simpler setups mean fewer points of failure and better buy in from operational teams.
2:Let's get more concrete. When Rebo is running on SecFlow, what does it actually do from a monitoring perspective?
3:It passively watches the OT traffic protocols, like IEC 61,850, MMS, goos right at the edge. If a new function shows up or command usage spikes unexpectedly, it is flagged as an anomaly and the right person is alerted instantly.
2:So no added latency, no operational disruption, just real time insight if something odd starts happening inside the substation or DER site.
3:Exactly. Simplicity is the big win. Less complexity, faster response, and a solution that operators are actually willing to use.
2:Here's a big shift. OT security isn't just about keeping people out. Attackers today target the process layer itself. Why is protocol monitoring so critical here?
3:Because real attacks often happen through subtle changes, misused commands, new protocol functions, or gradual process drift. Monitoring GUZ or MMS communication lets us spot not just who, but what is changing and whether those changes make sense.
2:And that's only possible if you're analyzing live OT behavior, not just network logs or firewall alerts.
3:Yes. And the questions we ask now are, what changed? Should it have? And does it match normal operating patterns?
2:On the connectivity front, what's changed in how substations link to control centers?
3:We're seeing more use of both fiber and cellular private LTE five g as backup paths. SecFlow encrypts all traffic and can automatically switch from primary to backup if a link goes down, so the connection stays resilient.
2:And all this is happening while OT traffic is mirrored for monitoring even East West communication inside substations, which often gets overlooked.
3:That's right. Resiliency plus visibility, if either is missing, you're exposed.
2:Let's pivot to distributed energy resources or DERs. Solar, wind, batteries, all those remote sites. Why do they create new security headaches?
3:DERs multiply the attack surface. Each new site adds a remote entry point, but these locations can't support complex security stacks. They're resource light, but mission critical for grid stability.
2:So a heavy, multibox solution just isn't practical. You need lightweight, centrally managed monitoring that still gives you deep visibility.
3:Exactly. That's why integrating monitoring as a software container on the gateway is so effective.
2:So to sum up this integration, Secflow gives you the secure, flexible connectivity, while Rebo delivers the second layer visibility. Why is this layered approach so crucial?
3:Because even the strongest perimeter can't catch process anomalies. If someone tries to sneak a rogue command from a solar site to the grid, REBO will spot it instantly even if the connection is encrypted and approved.
2:And with everything preconfigured at the central site, you cut down on installation time and slash complexity for operators.
3:It's faster to deploy, cheaper to maintain, and much easier to scale across hundreds of sites.
2:We get lots of questions about this approach. Like, if I already have firewalls, what's the real added value of OT specific monitoring?
3:Great question. Firewalls control access, but they can't see what's being done inside allowed sessions. OT monitoring examines protocol behavior itself, detecting if a control command is sent at an odd hour or if a system suddenly starts writing instead of just reading.
2:Another one we hear, which OT protocols can Rebo actually inspect?
3:Pretty much all the common ones, IEC 61,850, MMS, Goose, IEC 104, and more. And if customers need to monitor something new, it can be looked into as well.
2:People worry about losing connectivity. What happens if the central link drops?
3:The Secflow is built with automatic failover exactly for this dispose. If the main link fails, it switches to backup fiber to LTE or from one cellular provider to another. And if everything's down, the local agent still logs traffic so nothing is lost.
2:So operators don't have to rush out to remote sites or worry about gaps in monitoring data. It's all handled automatically.
3:Exactly. The whole goal is end to end resilience. No single point of failure and no loss of forensic evidence.
2:Regulators now expect ongoing control, not just a security diagram. How does this integrated approach help with compliance?
3:It's all about evidence. With continuous monitoring, you can show real time anomaly logs, response timelines, and actual incident evidence far beyond what policy paperwork can prove.
2:And because monitoring and transport are unified, you don't need extra probes or after the fact bolt ons. That operationalizes compliance, not just theoretical readiness.
3:Exactly. It's a shift from trust me to show me, and this setup delivers that.
2:Operators sometimes ask, can we run lightweight analytics directly on SecFlow, or does everything have to go to the central system?
3:There's flexibility. You can run key analytics locally, like for DER sites with limited protocols or send data upstream for deeper centralized analysis. The deployment can scale up or down based on what the environment needs.
2:So if you want fast site level alerts, you've got it. But if you need big picture insights, that's possible too. No need to choose one or the other.
3:Absolutely. It's about tailoring the solution so it fits both massive utilities and small distributed operators.
2:A hot technical one, does encrypting traffic with IPSec or MACsec interfere with deep packet inspection?
3:Not at all. Inspection happens before encryption. Secflow analyzes packet content at the edge, then wraps it in encryption for secure transport. So visibility doesn't get sacrificed for security.
2:So you're getting both full protocol level monitoring and end to end encryption without compromise or blind spots.
3:Exactly. That's the synergy that makes the integrated approach work so well.
2:To wrap up, there are three key takeaways. First, edge visibility is now critical infrastructure regulators, and attackers both see it that way.
3:Second, perimeter security alone won't cut it anymore. You need to see what's happening inside, not just who's connecting.
2:And third, integrated edge strategies like combining secure connectivity with real time OT monitoring scale far better than fragmented setups.
3:So if you're managing remote substations or DER sites, the practical next step is to assess where your current blind spots are and explore how integrated solutions can deliver both visibility and resilience without adding operational headaches.
2:Thanks for joining us on this deep dive into OT edge security. Reach out with questions or to see a demo tailored to your setup. We're here to help you make those blind spots disappear.
1:Thanks for listening to your network's edge. Stay ahead in the world of connectivity. Be sure to subscribe, share, and explore RAD's solutions at rad.com. Until next time, stay connected and inspired.