Architectural Invisibility For Modern Cybersecurity

The easiest system to hack is the one that’s always there to be found. We sit down with Steve Visconti, CEO and co-founder of XIID, to talk about a different cybersecurity mindset: architectural invisibility, where the goal isn’t to build a bigger wall, it’s to make the target unreachable in the first place.

We dig into what “no inbound communication” really means, including removing public IP dependence, reducing DNS exposure, and enforcing process-to-process connectivity so only the exact executable you approve can talk to the exact service it needs. Steve explains how outbound-only tunnels can be established on both sides, and why strong encryption and post-quantum secure tunneling matter when you’re protecting high-value systems in an increasingly autonomous, machine-to-machine world.

We also get practical about where this fits in today’s security stack. Because it operates at the application layer, it can complement existing tools without a rip-and-replace overhaul, and it can roll out one app at a time while still scaling through orchestration. Along the way, we connect the dots to real risks in modern software delivery, like AI-generated code and CI/CD pipelines that accidentally leave behind discoverable test endpoints.

Finally, we zoom out to critical infrastructure, including EV charging networks and the growing connection between vehicles, cloud billing systems, and the electrical grid. If you care about reducing attack surface, protecting OT environments, and building zero trust security that survives automation at scale, this is for you. Subscribe, share this with a security-minded friend, and leave a review with your biggest question about making systems “unreachable by design.”

Transcript

Flipping Cybersecurity With Invisibility

SPEAKER_01 0:01

Hey everybody, really excited and intrigued for this conversation today as we talk about flipping the script on how most people think about cybersecurity with uh an architecture called invisibility, architectural invisibility. Steve from XSEED, how are you?

SPEAKER_00 0:18

I'm doing very well, Levin. Thank you for hosting me.

SPEAKER_01 0:21

Thanks for joining. Really intrigued uh by you and your work. And of course, nice view of Las Vegas there behind you. Uh before we dive in, uh maybe introduce yourself. And and for those who don't know who or what XEED is, how do you describe what you're doing and the problem you're solving?

SPEAKER_00 0:42

Yeah, my name is Steve Disconti. I'm the CEO and co-founder of XSEED. We are uh actually a company that was designed and developed to solve the autonomous world that we are now moving into with uh you know everything automated, moving from human networks. Uh, so we decided that the approach had to be much different in how you secure those communications. And so XSEED is a typical startup company, uh venture funded, and uh super happy with where we're at.

SPEAKER_01 1:14

Amazing. And you talk about making systems unreachable instead of just harder to breach and break into. Uh so describe that. What does that look like in real life?

SPEAKER_00 1:24

Yeah, in real life, it's it's fundamentally broken down this way. We we believe in reducing the attack surface in such a way that uh you have no inbound communication, both on the client side or what we used to know as the client network, right? End node and exit nodes, no inbound communication, no public IP address. Imagine no static IP address. How do you communicate? No DNS exposure, process driven. Only this process can speak to this process. That is uh uniquely uh something that we designed and developed here at Xe.

SPEAKER_01 1:59

Sounds amazing. So uh, you know, how do you hide a critical system from attackers but still keep it usable and reachable uh for those who need it?

SPEAKER_00 2:09

Yeah, so we developed a platform

Outbound Only Networks And No DNS

SPEAKER_00 2:12

that uh is designed, it's actually deployed in two different ways. One, software as a service, so we deploy and manage a fleet of what we call connectors, and then we give a uh we designed a uh software component, which is a client that sits on, it's a very, very small client, by the way, that sits on uh the the both entry point and exit point of the client server as we used to know it, uh of both sides. And when they need to communicate, they reach outbound, both of them reach outbound from their uh device, and uh it is connected in the middle with all of our security routines that we do. We have a full post-quantum secure uh tunneling at three layers of of encryption to ensure that that conversation remains quiet and uh and difficult to break, if not impossible. Impossible with today's tools, by the way.

SPEAKER_01 3:08

Wow, that's pretty bold. Um curious, was there a moment or series of moments where you you guys looked at patching and monitoring and you know practices that you then thought it didn't enough?

SPEAKER_00 3:22

Yes, uh well, by design, right? We we started with under the premise that the way networks are today, it's been developed where everything is reachable. So think about the history of the net of the internet. Uh, there was a problem where you wanted labs and research centers to be able to communicate to one another. So they developed a system in which it was to make it easy to communicate with one another. But nobody really quite thought out the security uh implications with a network that we now know as the internet and our typical uh enterprise networking. So we, through observation and years of of you know our own history in this industry, said, hey, there's got to be a much better way to do this. And we actually foresaw automation coming along with the advent of containers. Uh a couple of our co-founders have been involved in AI for at least 15 years. And uh, so as a result, we said, hey, we have to build a system where it's not everybody's invited in, and we block those we don't want, we have to build it where nobody's invited in. We only allow those communications that we want to happen, which is a much different problem to solve. So that was the inception of the company. And uh fast forwarded today, we've we've developed it, it's working very well, and it works at the process level. So an executable. If you want to uh access a database, that's a process, that database will reach out using our client and attempt to establish a tunnel. And so it takes both parties to be able to establish that tunnel.

SPEAKER_01 5:01

Fascinating.

Why Reachable Networks Keep Failing

SPEAKER_01 5:02

Uh, talk a little bit about your connection to the US uh Air Force Research Labs, uh, to the degree you can. How did that come about? Um, what what did that mean for you and the team getting uh that kind of DOD authority?

SPEAKER_00 5:18

Yeah, very interesting. We when we were early on in the thinking of this product, really the early inceptions, hadn't even started coding. Uh, we were talking to many, many individuals around the uh mostly in the US, but some in Europe. And for whatever reason, we were befriended by somebody at the United States Air Force Research Lab, uh AFRL. And so we started talking about our concepts, and it went from there. They were interested, and they just continued to communicate with us as we developed this system, and they offered to test it. I mean, free. They said, Hey, let us test it, let us see if it's really uh matches the claims that you say. So we presented it and uh they did a full uh penetration test and gave us the test results, which is very unusual for the government. So I have that on their letterhead, which is interesting. Uh, it's from our very early uh development, but uh the product continues with the same foundational themes of not reachable. Uh, from there, it got out. And uh next thing we know, we're talking to uh uh three letter agencies, so that one of our customers is a uh one of the intelligence agencies. Um we also have a relationship with Defense Health Administration. They're the ones that uh took us through the authority to operate the ATO um program, yeah, which we were successful in uh attaining uh impact level five, which is a very high impact, uh very high security level for cloud security, uh with uh having that IL5 ATO. I think we're the only in Axis that maintain it without some conditions. So very proud of that.

SPEAKER_01 7:03

Fantastic. Well done. And so a lot of large companies, enterprises, government can sunk a lot of money into their security programs, tools, platforms. Uh, where do you slot into the security stack that exists today? I assume there's not a rip and replace that has to go on.

SPEAKER_00 7:22

No, in fact, everything we do is at the application layer, right? The highest layer. So there's no configuration that's required. I mean, we suggest they close inbound firewall rules, you know, close down the inbound ports. They don't have to. We only use uh port 443 on both sides, talking from uh both sides of the uh client and server. Uh so essentially you can put it in and be up and running in minutes and have a tunnel, a secure tunnel. Now, having said that, it would be prudent if you no longer need those open ports, close them. If you no longer need that static IP address, which is in the case with our product, turn it off. Um, make the DNS entries so that they just are not attackable. And that's how you do it. One application at a time. But we've developed an orchestration set of tools, right? Orchestration plane that allows you to roll these out programmatically, millions of tunnels, whether it's containers with thousands of containers or you know, hundreds of thousands of users, very easy to deploy.

SPEAKER_01 8:25

Fantastic. You talk a lot about working with developers and vibe coding, all the rage uh these days. Um walk through how that collaboration works, um, you know, and how traditional

Air Force Testing And IL5 Authority

SPEAKER_01 8:40

coding approaches sometimes create holes in the perimeter that are often exploited. And of course, developers like the rest of us have some pretty bad habits uh as well. Uh, how can we get security uh to work better with developers and close some of those loopholes?

SPEAKER_00 8:57

Yeah, that's a great question. Uh so one example is let's say you're developing some kind of uh an AI app. You use AI to develop an application, if you will, and it does all the things that it needs to do. It generates the code using APIs, it builds a Kubernetes manifest, it deploys this system before it's deployed, it's tested. Uh, but let's say it's a CI CD pipeline or something, or CI CD deployment pipeline, if you will. So buried in all of those pieces of code, there was one end node that they were using for a test that they forgot to turn off. So when the code is reviewed, and you're talking could be thousands and thousands of lines of code, uh, there's nothing that looks like it's malware that can be malpiece, and there's so forth. So it gets through all of the testing without any problem and it's deployed. Great. It works solid with one little problem. You forgot to remove that end node that you were using for test, and that is now becomes a target, a possible target that can be found by a nefarious actor. So even though the code was built and correctly and deployed more or less correctly, it was one little problem that the machine could not pick up on, and uh so therefore the attacker now has an obvious uh uh obvious entry point or a place to attack, right? So it's discoverable, and that's the problem. That's one of the problems, if you will. So in our world, had that happened, maybe that node was still there, but keep in mind we say it's process to process. So once it was deployed, you've already isolated those two processes to only be able to speak to one another. So even if there was a node that you left in there that we're using for test or to get captured data, it would have no problem. It would not be uh, you can't find it, you can't get to it. It's not there. So that's just one example. And there's many, as we get into this machine world where it's machine to machine and not human intervention, you're going to see a lot of opportunity for expansion of the attack surface because this is happening so fast and at machine speeds. So you need to think in terms of how do you reduce that attack surface? And uh, and so that's that's a big part of this.

SPEAKER_01 11:18

Indeed. And speaking of attack surfaces, critical infrastructure getting a lot of attention as as uh it should. And one area in particular you've been involved with is EV charging, which is you know rapidly coming on stream across the country, across the world. Talk about your work in that area and some of the partnerships that you've you've built uh to protect these these charger networks.

SPEAKER_00 11:43

Yeah, I love that. Critical infrastructure. People another individual asked me about EV charging. Why is that an attack circus? And I said, well, it's the unobvious things that you don't think about, right? So they have a car that pulls up to the charging system. That charging system is attached to the grid. That charging system is attached to a cloud for billing, back end services, whatever it needs to do. And not to mention that vehicle was built and designed even with all the security infrastructure. Imagine where did the batteries come from or where did this infrastructure come from? All those onboard computers, you know, 30, 40, 50 onboard computers. Wow. All of those things have the potential to leave behind little

Deploying At The Application Layer

SPEAKER_00 12:26

bits of openings. And that opening ultimately gets right to the grid, right? So that's critical infrastructure. That uh charging system is part of a network that's that actually, uh, by the way, there's a technology they use for uh uh vehicle called vehicle to grid that allows load balancing of the grid. So if you're not using that car, let's say it's parked and you have it connected to a charging system, they'll use that car, that car in the future for load balancing. They'll draw power from that car. If you're saying your garage connected, you have an in-home system, uh, it will use that car to draw power into your house and into the grid. It's you it becomes vulnerable. So we set out working with a company called everge to solve that problem. We did solve that problem with uh uh providing this uh tunneling system from EV charging to their back end systems. So you cannot get to the grid without having the proper preventions. Works very well. And we just uh inked the deal. I'm not promoting it, but we just inked the deal with a very large industrial worldwide uh with Hitachi systems, a similar situation where they're taking this out to go deploy artificial intelligence into OT environments, operational technology, into energy, into critical infrastructure, water, so forth. Uh so I think the world is is uh waking up to hey, if we're gonna build this autonomous world where it's machine to machine, uh, it's gonna be very complex and it's gonna move very quickly. We need to look at our security uh uh platforms and design something that uh can withstand uh those types of uh uh large networks.

SPEAKER_01 14:06

Amazing. Yeah, Dati's an incredible company, had them on the show and Ventara and the various uh IoT folks there many times. Can't wait to see that rolled out. Um any practical uh guidance for securing your networks in addition to working with uh XEED, what else can people do short term to shore up their vulnerabilities, in your opinion, and get started on a more uh secure environment?

SPEAKER_00 14:34

Well, certainly, you know, with all the CDEs that you see every single day, the idea of trying to play patch, catch, you know, patch of the system catch up, it just is continual. So, whatever you can do to evaluate your network and think of it this way I might want to build an application or make these applications available to whom, to what, to what systems,

Developers AI Code And Hidden Endpoints

SPEAKER_00 14:55

not building a, as I mentioned on the front end of the discussion, building a system that's available and how do I put up roadblocks to keep the bad people out? No, who needs to reach this asset? Why do they need to reach it? And let's think that through accordingly. And so uh products like ours, and I'm sure there's others that will emerge into this industry as we go forward. I'm already seeing some of that. Uh, it's a different way of viewing things. It's not about making it accessible, it's making it accessible to what or whom or what agent.

SPEAKER_01 15:28

Much better. Well said. Yeah, indeed. Paradigm shift. So you're in Las Vegas. I'll be there a few times this summer. I'll be wearing my sun hat. It's gonna be a hot one uh to say the least. Always uh where can folks see you, meet you, and the team, uh as they may be Black Hat, DEF CON, other other places.

SPEAKER_00 15:46

Yeah, we'll be at Black Hat. I don't have the booth in front of me, but we'll be at Black Hat for sure. And uh so come see us there. And uh, we also have a webinar series coming up, uh, working with a container corporate uh container orchestration company. So they can find that on our website. And uh yeah, give us a call. The product's incredibly simple, 30 minutes. You can deploy your own commander and do millions of tunnels, test it for yourself. Don't take our word, as they say.

SPEAKER_01 16:14

Wow. Well, that's a mic drop moment. So I'll let you go as the sun sets there on the beautiful mountains uh in Las Vegas. And uh good luck on the mission, really important one. We're all rooting for you. Thank you, Evan. Nice to meet you. Thank you, and thanks everyone for listening and watching. Also, check out our companion TV show, techimpact.tv on Bloomberg Television and Fox Business. Thanks very much. Bye bye.