Continuous Trust in Cybersecurity : Why Identity Is the New Security Perimeter

Aaron Crow: Thank you for joining me on another episode of the PrOTect IT All podcast, where I get the opportunity and privilege to sit across from a lot of really amazing people who have built things, are building things, and have fought the fight. Today is no different. I really enjoy the fact that many times as I'm on this screen, I'm sitting in the room with people. I'm usually not the smartest person on the call, and I'm okay with that. I love being around people. Every one of these times I get to learn things, and many times it's not something I necessarily expect.

For those of you who have listened for a while, you realize that my podcasts are not scripted. I don't have a list of questions. I'm not trying to get you. I'm not trying to prove I'm smarter. The whole point is to have interesting conversations and talk about real problems that we have in cyber and how we can solve those things. And it's not always about a product. Sometimes it's a product, sometimes it's a product and a policy or process, or people and everything in between.

So with all that said, Frank, thank you very much for joining me today, taking time out of your day. Why don't you introduce yourself to the audience, tell us who you are and how you got where you are today.

Frank Goodman: Absolutely, Aaron. Thank you so much for having me. I'm honored to be here. My name is Frank Goodman. I've spent about 25 plus years, let's say 25 plus so I don't date myself too hard, in technology, mostly leading engineering teams in enterprise security software. I went through lots of different technologies over time, which has been great. I started in networking, moved into medical devices, and then back into security. I've done the engineering leadership, I've done the product management, so kind of a full spectrum of the development lifecycle. Through that, I've come to realize there are some problems we kind of know how to solve, but nobody has really gotten around to solving them. I'm hoping to put a company together to take care of that.

Aaron Crow: So let's dive in. What problems are you guys solving? What are you seeing in the space?

Frank Goodman: If you're paying any attention to the cyber news lately, you're seeing all kinds of attacks coming through. A lot of them supply chain, a lot of them based on this weird dependence we've grown on static keys and tokens. It's strange to me because we've understood how to prevent this for a long time, but there just aren't platforms that address it.

The main thing I'm talking about is that we grew up on the internet saying, "I need to know exactly who I'm talking to." When I go to my bank, if I don't see that little lock icon at the top of my screen, I'm in trouble and I need to be very careful. We trained the world to understand that. But for some reason, nobody has really solved the source identity problem. We have user identity and we have some machine identity, but a lot of this is implemented in static or siloed systems. There's no generally available platform to deliver strong cryptographic source identity.

So we've fallen back on static keys and tokens, all of these things that can be stolen and replayed. With cryptographic source identities, these whole attack vectors just disappear, because the protocols that have existed for a long time, like MTLS, mean you cannot even knock on the door without a strong source identity.

The company I'm building, Onoratio, is focused on not just delivering source identities within a trust domain, but also making sure that trust itself is a continuous process. Connection-time-only trust is not good enough. Trust changes over time. And then we also make sure we have policies to enforce that, so we don't have to rely on overwhelmed SOCs to detect things that take a long time to figure out. We put in place policy engines and enforcement points that will automatically act to disconnect things that aren't behaving properly.

Aaron Crow: If you think about the full stack, all the layers from physical all the way up to application layer, every bit of authentications and credentials, how many of those things can break down. And then you start getting into complex systems. We've already seen it with AI, with Open Claw and people plugging in API keys and giving it access to their email. It's insane. They don't even realize what they're doing.

I'm using Open Claw, but I have it running on a dedicated system, I have dedicated APIs that only allow certain access, and I'm rolling those keys constantly. I'm a cyber professional, I do this for a living. Most people using this are not doing that. They're putting it on their laptop that has access to the internet.

Frank Goodman: Well, some professionals have also gotten in trouble with this. It's nuts. AI is the latest incarnation of things that can go wrong, no question. But if you think about what an AI is from a traditionalist standpoint, it's a process, and a sub-agent is a sub-process. These are not new things from a technology standpoint. What they can do is new. What bad acts they can perform is certainly new. But the way they're operating in our systems today is very traditional.

There are two kinds of questions around AI that have to be answered. One is, should they be allowed to connect to things? That's the problem Onoratio solves. And then if they're misbehaving, how do you stop them? Onoratio doesn't deal with detection, but it does enable detectors to signal changes in trust in a pluggable way, so as these new governance and AI things come about, we'll take a signal in and disconnect that thing the second it reads the wrong file.

We deliver these identities not just to the endpoint or the workstation or the workload, but to every process and sub-process that runs on that box. Nothing can even connect unless it's passed a series of tests, and those tests are definable.

Aaron Crow: The way I describe AI in my layman terms is it's like the intern. What access are you going to give it? It's no different than a person. Yes, it's a computer, but what are you going to trust it with? What access does it have? What authority are you going to give it to actually make changes? And where are you putting in the approval process? It's no different than I would do if I hired a new person. I'm not going to give them full domain admin rights when they just got out of college and have never touched a system. I may let them tinker, but I'm going to make them come ask me, then we'll do this together and walk them along the path. It's the same way I design an AI system.

Frank Goodman: But to complete the analogy, most people are giving the AI their own credentials. It gets to act like you, and it doesn't have your experience. You're like, "Oh god, I let my intern run wild with my API keys, and it can connect to anything I can connect to." It's crazy.

Aaron Crow: So many times the problems I see, whether it's in OT where we're connecting OT systems directly to the internet, or a lot of the bad actions I've seen in my experience, most of those aren't because people are stupid, malicious, or don't care. Many times it's because they have to do something and they're trying to get the job done. This is the only way, or the best way, they know how to do it. Nobody showed them, or it's too difficult or expensive.

AI is everywhere. The barrier of entry is really low, but there needs to be rigor. Before you give your kid the keys to the Lamborghini, you should at least teach them how to drive a stick.

Frank Goodman: For the large enterprise, it's really important to remember that even the best companies aren't always sure what they're running. Open source is amazing, you can do all kinds of great things with it, but it's turtles all the way down. You don't always know exactly what's in each one of your systems. The more sophisticated security organizations are doing things like SBOM analysis and cryptographic signing by their developers to make sure the image you deploy is actually the image they built. That's to try to get at some of these supply chain problems.

Using those technologies to help in allowing whether or not that process or workload should get access makes a huge difference. It's not just, "I'm a container in this cluster, therefore I'm safe." No. Are you the right container? Are you the right image? Are you the right hash? All of those things have to be taken into account to get access. That's where this pluggable attestation architecture is so important. You need to build your own confidence, and for every enterprise that's going to be different.

They have different tooling, different security standards, different development processes. They need to be able to adapt that to their environment. Some are going to be in the cloud, some in multiple clouds, some using Lambdas. All of that has to be factored in. But if you are one of those more sophisticated companies that latches on to that technology and looks at the pieces, you can use that same evidence to ensure that nothing gets into your system at runtime that hasn't passed those gates.

Aaron Crow: That is huge. I know OT is behind the ball, but IT, enterprise, there are so many IT architectures and enterprises when you start thinking cloud and all the technologies, systems, and connections. Think about how complex that is. And most of the time you have silos. I've got this team responsible for these technologies and applications, these are over here, these are over there. Different people are setting up different things.

Yes, there's usually an overarching cyber or compliance or architecture group supposedly looking at those things, but nobody can be an expert to the nth degree in all of those settings. Log4j was an obvious example. We didn't know what was included in those things. How can I figure that out without understanding all of the things I have across my entire organization and how A plus B plus C is going to impact my risk and connections?

Frank Goodman: That is a huge thing. I want to give a small shout out. There's really good tech out there right now. There's great EDR technology for endpoints. There's great identity technology for user identity and two-factor authentication. There are fantastic OT companies now that are fingerprinting devices and understanding exactly what's connecting when all you see is a MAC address coming into your network at Layer 2. There's really good tech there.

But what there isn't is a system that takes all of that in and helps you formulate a policy and enforcement, and then helps you enforce that. If you have a bunch of OT devices, let's say five MRI machines from the same manufacturer, and your OT team is monitoring that because you've got a great tool for that, and it suddenly sees one start talking to something outside the normal pattern, there's going to be a signal sent back. If you send that into Onoratio, we're like, "Hey, wait, that MAC address is now suspect. Its trust score has dropped." If your policy says that its trust score has dropped to a certain level, we signal back and say, "Take that thing offline." That's OT, but we can do that with everything in your network at the process level.

The tooling that exists today is fantastic, but none of these companies, as good as they are, are in the business of solving the broader problem. They're in the business of building their business, correctly so, because they have shareholders that pay the bills. Unfortunately, sometimes that leaves you with silos.

If you look at what most high-end SOCs do, they're aggregating all of this signaling from all of their tooling into a big SIEM with dashboards and custom homemade stuff. Part of the problem is they're working at human speed. They come in and say, "Hey, there's this anomaly. That one's not important, this one's not important." They're processing all this at human speed.

What Onoratio does is take in all that same input, apply your predefined policies to how important those events are, and it acts. The protection is in place 30 minutes, 45 minutes, hours, days ahead of when the SOC can reasonably act given the volume. When they're acting, they're sitting there in post-mortem mode because the thing has been protected milliseconds after the event crossed the threshold.

It's really important that these things be automated, because the dwell times and the bad actors are what kill you. If you can nail these things in milliseconds, you've got plenty of time to figure out what happened. We have a log of absolutely everything. There was an event, it triggered this, the trust score changed, we disconnected the device, and we can provide all that to the SOC to do the post-mortem. It makes a huge, huge difference.

Aaron Crow: To really simplify it, when I built teams and we were troubleshooting something, it didn't matter what it was, all the way back from my desktop administration days to networking, system administration, OT systems. I learned this a long time ago: when troubleshooting, start at the lowest layer of the OSI model first. I don't start troubleshooting the application if I haven't confirmed the network cable is plugged in and the power is turned on. Have you turned it on and off again?

That infrastructure layer is incredibly important, and it crosses boundaries between technologies, verticals, and business units. That is the glue.

Frank Goodman: And between companies. How does UPS know that the order that came in from Amazon, which was from a non-human identity, from some microservice running in the background, is a legit order? If it's an API key, if that's all it knows, that's not a great answer.

Aaron Crow: If you take a big step back and think about that as a human, that's a really big problem to understand. Many times when I go into these businesses, one of the biggest problems they have is they don't really understand the end-to-end business process well enough to grasp how big the problem is. They're trying to compartmentally solve it with, "I'm going to bolt this tool on, I'm going to bolt that tool on." It doesn't really inherently solve the problem at the bottom. They're whack-a-moling symptoms, not fixing the true issue.

Frank Goodman: The metaphor I like to use is that trust is kind of a missing layer. We have the OSI model, we have the data plane, we have the control plane, but we don't have anything that's continuously monitoring whether anything and everything in the system should be trusted right now. Not when it connected three hours ago, but right now. Everything happening on that endpoint or workload or Lambda is changing all the time, because other things are coming in, behavior is changing, memory is growing, there's a leak, whatever. Someone has to act, someone has to bring that together and automatically turn things off that are broken, and do that at a session level, not at a big-pipe level.

Aaron Crow: How do you see this changing secure architecture in the future: SDLC, product development, architecture? Where do you see this being the biggest impact in making a difference, lowering risk, and changing how we approach and attack?

Frank Goodman: Take the simple example of no API keys, and the fact that you have to prove who you are to even, I want to be clear, to even connect. Today, if you get a token or a session key, you can do whatever you want with the permissions that thing has. We've seen plenty of examples with the latest supply chain attacks that go through three levels of systems, tearing things apart and exploding from there. Those attack vectors just stop existing, because it's not like you have access. You literally cannot knock on the door without strong source identity in this model. And that doesn't require development, that doesn't require changes in architecture. MTLS has been around for a long time. We have the technology to do this right now. We just need this layer that can provide the source identity for the organization, enforce it, and drive the policies that allow you to disconnect things when they misbehave.

The attack vectors collapse. They disappear. There's plenty of phishing and things like that, but same thing: if a system detects that, the score changes. When the score changes, if it reaches the threshold of disconnect, that system is gone in seconds. Events usually cascade. One bad thing happens, time goes on, two things happen, time goes on. Trust is a threshold. Once you've crossed that threshold, something has to change, and it has to change quickly. At the end of the day, we're protecting the workloads, the payroll systems, the sales customer data, the proprietary information, the source code. That has to be the priority. They have to be locked up first and fast.

AI doesn't solve that either, because AI still contemplates what it's doing. An AI can assist in maybe setting up what those policies are, but it's not going to be in the data path. It's not going to be able to act fast enough for the kind of security we need in large enterprises. Banking, healthcare, oil and gas, critical infrastructure, federal government, they don't have time to mess around.

Federal government has been talking about zero trust and policy engines for five, ten years now. It's good tech. But the two pieces that haven't been done yet are policy engines and source identity. Without those things, with this continuous trust model, they're not succeeding. You can find "zero trust" slapped on absolutely every security product in existence today, but it's words. It's a very small sliver of the requirements that those standards set forth.

Aaron Crow: We have this problem no matter the vertical, no matter IT, OT, enterprise, cloud, local, on-prem. I keep targeting OT because some people will claim OT is at least 20 years behind IT, and we're having the same problems. We have authentication issues, we're introducing APIs and service accounts. We have that same problem in the IT space, it's just faster. Not as many people are using AI in OT yet, so we have a little time there, but that doesn't mean we aren't having the other problems.

I don't care if I have the best SOC in the world with the best tools in the world. An analyst isn't going to be able to respond fast enough to stop a bad thing from happening, because they're human.

Frank Goodman: Exactly. Or even with computation that isn't designed to scale into the data path. We're talking session-level interruption, packet-by-packet verification of the trust score prior to letting things continue on their way. That's not something that's going to be handled by just any old software. It has to really be designed for that performance and scale so it can act in the milliseconds it needs to.

OT is a great problem space because they have other issues. The pedigree of their source code, where they come from, very little identifying information. The best-in-breed products that already exist in the security space are huge levers, but those things need to connect to the rest of the internet and the rest of the things. They need the other side of the tooling as well, and they all need to come together to deliver the inputs or the trust capabilities. If the OT device does something, the back ends can be protected. You're not trying to protect your OT device, you're protecting it from going out and going nutty on everything else.

Aaron Crow: Walk us through: what does this look like if you're walking into an organization that doesn't have this visibility? How do you set this up? This has always been my struggle with zero trust, because most people, especially the way most zero trust products work, you have to have a complete map of everything that talks to everything and how they talk, which protocols, when they talk. You have to know what good looks like to be able to lock it down. Most people don't even have a clue what their environment actually does and how it works. They've bolted things on and it works. They rolled the dice: "Yeah, seems to work. Let's go."

Frank Goodman: You can scale this out very easily. You put in place the centralized controller, set up the policies, what does a various input mean, how does it impact the trust score. That's what the software helps you do, work through the configuration. Ultimately, trust as a technology doesn't really exist as a real-time thing right now. So I can't go in and say, "Hey, retrofit this software so it looks at the trust score and acts accordingly," because nobody is going to do that. If they did, it would take them six to nine months to release the next version.

We can do it by putting in place gateways that see every session that comes through. You can put them in a reverse proxy, in the Kubernetes space, on a VM on the back end. Those gateways act as the enforcement points for your system. They require source identity to even allow anything to connect. They're protocol-independent. SSH, RDP, HTTPS, whatever. We see the connection, verify the source credentials. If it fits within the trust domain of the environment, we allow it. If a trust score changes while that session is in place, we are notified asynchronously and we kill the connection.

First thing is to put the back end in place. Then you work forward to how you give source identities. That depends on the maturity of the organization. On the back end where you're dealing with Kubernetes clusters and containers, they've got CI/CD pipelines, they've got all this technology, they have a pretty good handle. Putting in place attestation for those environments is pretty straightforward, and it's also cool because they can say, "Here's the stack of things a workload has to pass in order for us to allow it into the system to get that source ID." Not just, "Did we build it?" but, "What's the SBOM? Does it have any CVEs? Does it have the right hash on the image size?" You can completely build this up based on your environment.

Then you've got your whole back end working off these source IDs. Next step is to go out to your endpoints, which are a little harder because they're controlled environments, usually Microsoft Windows or macOS or the predominant things. You can add Android and iOS if you're doing mobile stuff. Putting agents out there that can see what's happening is a big piece.

The other thing to understand is that many companies, whether OT or large enterprises, have a certain amount of stuff they build, deploy, and manage on the back end, but they also have a tremendous amount of IP and proprietary information floating out there in the cloud in other providers. Salesforce data, Slack, any of these SaaS-based companies, great companies, almost exclusively work based off a user ID, and those companies don't really have any sense of what's on the laptops they're connecting to. When we start to move out to the endpoint agents, we see all of those connections being deployed into the SaaS providers. When the trust score changes on that endpoint, we can signal the SaaS to disconnect the user.

Completely out-of-band monitoring that, for the first time, really brings together what your internal security team knows with what your SaaS companies know. Right now those two don't talk very often. How much information do companies have in Salesforce? All their customer information. A lot of them do ordering in there. One token or one session key and you're off and running, just sucking that data down. We'll know that connection exists if you're an enterprise customer, and we'll know if your trust score changes, and we'll be able to adapt accordingly and disconnect those connections. So deploying is pretty straightforward.

Aaron Crow: So the other side of the coin, and I can hear the devil's advocates: what happens when it breaks and I don't know what's going on? How do I troubleshoot it? How do I know where it broke in the stack and what caused it? How do I make sure all the teams know where to look when they're troubleshooting? I just added another complexity along the way.

Frank Goodman: The system itself is completely self-logging. We have complete audit records of every single event that occurs. We know exactly what tests you passed for attestation. If you put your SBOM in as part of that process, we have a capture of the SBOM for the images that are running. If an event changes your trust score, we have that in our logs. We cryptographically sign that, so they're immutable. If we do an enforcement, we know why.

The exact history of everything we've done as a system is constantly available to anybody with permissions to look at. The system will be deployable either as a SaaS for companies that don't want to manage the infrastructure, or self-hostable. A lot of large security organizations, financial services, are not going to put this kind of technology in a public cloud. They'll probably put it in a data center. Perfectly okay with us.

For the record, we eat our own dog food. Everything in our system doesn't talk without source identity and destination identity and trust scoring continuously. Anything that can happen in our system happens to us as well through the same process.

Aaron Crow: That's the key to this. We have to have that visibility and understanding. Imagine I have an understanding of all the applications and everything they're talking to. Not just the application, but the process in the end, which we don't always have visibility into. The application team understands their stack, they understand their Kubernetes environment. But they don't necessarily understand the transition to the networking team, which is then a transition to the client-facing team. There are very few people who really understand end-to-end how that process works and where it breaks. There are gray areas every time there's a transition. It's the Spider-Man thing where they don't really understand who owns it, who supports it, how to troubleshoot it. "Why is it broken? No, you did it. It's always routing. It's always the network team. It's always a firewall issue."

Frank Goodman: Yeah. It's always DNS.

Aaron Crow: Exactly. So this would give a lot more visibility into what's going on even beyond just the blocking and tackling of bad things. I can see it being useful for understanding what's going on at that layer in the end, because you're seeing that full thing as it goes out and comes back.

Frank Goodman: You'll see every piece of the session. We will probably over time do more and more with metrics around session information. Our primary objective is to secure the systems, not necessarily measure every step, but you will natively see every step in the connection from source to destination through our system, because it will pass through various checkpoints along the way.

Aaron Crow: In theory, you have to, right? To be able to score it, you have to really understand that full process. That's the value-add. Think about dynamically saying, "Hey, usually Aaron's good. Aaron's laptop has all the right things, has the CVEs patched, he's connected to a secure environment, he's on VPN. But Aaron just popped up in China. That changes his risk score."

Frank Goodman: Absolutely. A lot of companies worry about where things are in the world. Geographically is a huge issue. You can have policies that adapt to that. I mentioned there is no trust layer right now, but once this trust layer is in place, because we're doing it with gateways to make sure it's deployable on day one, we're also delivering SDKs that can allow for graduated access. If you want to modify your apps over time to be more granular in how you deal with trust scores, that's a reasonable thing, and more sophisticated organizations will probably take that path. You could actually make your policies adapt to that very scenario. When Aaron's in China, read-only access, baby. There's no writing to the database. Or however you want to enforce it for what you're doing. You can adapt those policies in real time.

One weird side effect: if you're doing things like MTLS from the endpoints all the way through the back end, some of the current things just fall away. Do you still need a VPN if everything is cryptographic? We secure it all the way. That's a big expense for enterprises.

If you're using SBOMs for attestation of workloads and a new CVE comes in, and you as the SecDevOps or whatever the title is have to figure out the blast radius, how do you do that? You've got CI/CD systems, build systems, all this. We can tell you in seconds what's running in your system right now, because we took the SBOM in before it even got access. These are things that fall out of the architecture that bring additional value. When Log4j came out, the company I was at spent weeks trying to figure out if it was impacted, what was impacted, what we'd sent to people. This system will tell you exactly what's running, which is different than what's in your development and repositories, but what's running in your system right now and whether or not it has that issue.

Aaron Crow: It's so dynamic in what we're doing. We're doing the best we can. You mentioned the VPN stuff. We use the technology and capabilities we have because they're the best solutions we have. We sometimes struggle to change, because change is scary. I've got my process around these things, so changing how I do something is bigger than installing technology. It's installing technology and changing processes and procedures and training my people. Now I've got to train my support staff on troubleshooting. They're not problems, but at the same time they are. It's that learning curve of anything new. You see it with AI right now. Everybody's scrambling: "How do I use this? How do I do it safely?" Some organizations just block everything AI, others are building environments safely in their space so their data is not exfiltrating and people aren't trying to use ChatGPT.

Anytime you have something like this that is fundamentally and architecturally changing the way we do things, even if it's not having to add onto my stuff, it's still changing things. It's going to break things because I don't know how they work. We have to troubleshoot, understand that, update my documentation. These are things that make people hesitant, which is why some people are very slow on the adoption of new technologies. Others are more on the bleeding edge. Where are you seeing that kind of resistance as you talk about things with a new capability?

Frank Goodman: It's important to prove your mettle at the right level. My goal for Onoratio is to really start in the large enterprise space, where security is clearly a prime directive, because they have both the scale and the dynamic capability to really put this product through its tests. With that, you earn your credibility. "Look, we solve this problem at scale. We're definitely going to be able to solve this problem at a lower level." How many companies even have a SOC? Some don't, majority don't. Maybe they have a CIO and three guys who run the network. Enterprises have teams of people, this is their job. This should make their job a lot easier, because it switches them from "something bad is happening, the heat's falling on me while I figure it out" to "something happened, the assets are protected, now I can calmly go through my job and figure out what happened."

It shifts the burden a little, because of the way it instantaneously operates. You take the knowledge practitioners have, work with them to put it into the policy engine so it acts correctly for their environment, and then it takes a lot of the heat off. Almost everything they're doing is with the confidence that their back ends are already secure and not under the watchful eye of the executive committee while they're trying to figure out what's going on, having sleepless nights because they're on the call all the time.

I expect there to be a warm welcome for this kind of technology in the places where this is the real challenge, which is at scale in the large enterprises where security matters. With that credibility, people will see quickly that this solves a tremendous amount of problems. This is not world hunger. This is not a panacea that solves everything, but getting rid of spurious access is a huge issue. That ability to dynamically handle trust changes the game tremendously.

It's weird because AI is exploding right now. We just saw the Anthropic announcement with all the new stuff. Guess what? Most of those attacks require you to get into the network. If you can't connect, a lot of that stuff, you're a lot safer without being able to connect. This isn't something we haven't thought about as a community for many years. No one has stepped forward and said, "Here's how you solve the problem." We can build it, and it's quite straightforward.

Aaron Crow: What's the most exciting thing for you to see with this new approach at targeting a problem a different way?

Frank Goodman: I've been sitting in the security space for a while now. I've seen great companies build great products, and it's been disappointing because they just create their own walled garden. I get it, but there really has to be something that brings them all together. Whether it's CrowdStrike and Microsoft Defender, they're competing, but they're both great products and they do things well and they need to be leveraged. Companies have massive investments in these tools, but there's huge inefficiency in deploying them, which is why they funnel all that data into dashboards and SOCs: they're trying to bring it all together.

This platform brings it all together in one place and acts on that data instead of just putting up red, green, and yellow bars for people to click through. I'm super excited to see that in action. Dwell time is everything in this game. When you know something is wrong, you need to lock it down now. And when I say lock it down, I mean at the session level, not the big-pipe level. The second you see something go wrong, it loses access. Nothing happens at that point.

Aaron Crow: Nothing spreads. One thing gets in, then it's isolated to that space and it's not spreading across my environment.

Frank Goodman: I want to make sure everyone understands this. The company I'm building is not in the detection business. I don't want to compete with anybody, nor could I hope to. CrowdStrike will forever be better than me at endpoint detection, and they're great at it. We want to leverage that existing technology in a unified platform to continuously monitor trust and deliver the enforcement aspect, as well as the strong attestation to make sure this thing works end-to-end.

Aaron Crow: The benefit of that is many times you're like, "I have to do this, but I've already spent all this money on these other tools." There's the Venn diagram of overlap. Which of these tools do I use for this capability? Which one is better at what? I'm going to use this one here, that one there. I don't have full, complete coverage. I've deployed it in 80% of my environments. This is a problem as old as time. But when you have something that sits in the middle and can really interact with, receive data from, alert on, and take actions upon, that's where you start really getting a multiplier. You're making the tools you already have more valuable. It wants you to invest more into CrowdStrike and the tools you already have, because the more things they see, the more things you can do and take actions on.

Frank Goodman: Absolutely. To your background, the OT tools are fantastic. They have incredible capabilities, they have signals, they see things other tooling doesn't see. They're fingerprinting and doing all that cool stuff. You want to integrate that with your EDRs, your network detection, your identity, all of it. From my perspective, the answer is E, all of the above. I want to use them all. They're all good products. Overlap doesn't scare me at all. I don't want customers to buy overlapping products, but if they do, I'll use both, and I'll get the best of both worlds.

Aaron Crow: I ask everyone this question. What's the one thing that keeps you up at night that you're concerned about coming over the horizon, and maybe one thing you're excited about?

Frank Goodman: What am I concerned about? From a company standpoint, we're just getting started. We're seed stage. We're getting ready to start raising money. That's always daunting. We're looking for design partners, companies that want to get in early and work with us. I'm not asking for money from design partners, just attention, roadmap advice, making sure we build this to fit the large enterprise environment. I'm definitely looking for people to reach out on that, because they can have a huge influence. Is it OT-focused? Is it large enterprise? The SaaS aspect? They're all great standalone pieces, and the design partners are going to help shape that. And obviously we'll cut them deals when they become customers later. As a solo founder, I worry about how to get this thing going faster.

But man, am I excited. I have not had a conversation yet where anyone's like, "I don't really get what you're doing." Everyone's like, "Really? You can do that?" It's exciting. You never know how you're going to be received with these kinds of things. I've been in this space for an enormous amount of time. I'm pretty confident in what I'm doing here. And I'm also confident because this isn't rocket science. I'm deploying technologies that exist today in a new and novel way because they should have been done a long time ago, and nobody got around to doing it. It solves so many problems and ultimately will save money. It will save billions of dollars in cyber risk, maybe even save your insurance bills.

There are going to be some really cool features here, because this really gets at a lot of structural problems we have, both between the way companies organize themselves and go after their customers, as well as how bad guys try to get at this technology. The era of API keys and tokens, that's got to go. It's got to go.

Aaron Crow: AI has broken that model for sure. It really was always a problem, but it's exasperated the problem now. It's making it that much faster.

Frank Goodman: And it has to operate at all those levels. It can't just be, "We have workload identity and user identity." We need process identity and sub-process identity and all the layers. 98% of AI users, even the guys coding in the big enterprise companies, probably don't know. It's not like it's advertising what it's doing when you say go. It's spawning off a bunch of sub-agents, running around, changing files, accessing things you didn't know it looked at, sending them back to the server. We've got to get this under control.

Aaron Crow: 100%. Any other call to action you want folks to know? How do they reach out, find information, get a demo?

Frank Goodman: Reach out, I'd love to talk to people. I'm taking meetings. Design partners are key right now. I'm really excited about that. It'd be nice to sit down with some good companies and talk through how this can help them, see if I can get them interested in participating. Again, to be clear, I'm not asking companies for money. I'm going to go out and raise that money. I just want them along for the ride, because they see what this can do for them and want to have early influence on how we build it out.

Aaron Crow: All the details are in the show notes, everybody check it out. Frank's left his information in there, how to reach out, all that kind of stuff. Definitely reach out. It sounds like an amazing thing. I can't wait to see it in the space and solving some of these complex problems we have across all the different verticals, from OT to IT to cloud and everything in between, obviously with AI and all the things that's going to bring.

I see it as a great opportunity to dig in and really secure the entire stack. Then it's more about, what signals can I get? Who do I trust? What do I want to trust? What does good look like? I'm not as worried about that later. I can do more of the things I want to do. I'm not reacting, I'm more proactive in the space. That's where we want to get to as cyber professionals and, honestly, as business owners. I just want to make the decisions I want to make, not spend all this money or time or effort because I'm being forced to. Thank you for your time, man. I appreciate the deep dive. It's exciting. I'm on your side and excited to see it grow.

Frank Goodman: Thank you, Aaron. I love talking about this, as you can tell. I just get going. I'm super passionate. I'm really excited about this and I can't wait to have more conversations. Thank you so much for having me on. It's been a pleasure and I really appreciate it.

Aaron Crow: All right, thanks a lot.

Frank Goodman: Take care.

Transcript lightly edited for readability.