Techstrong TV March 24, 2026

Hey everyone. Welcome back here to Techstrong TV. I'm really happy to introduce this next gentleman here.

You're going to have to excuse him. He's literally been traveling around the world, and he's on a stop here for a few days before heading out to join the rest of us at RSA next week. But let me introduce you to Vikram Sharma.

Vikram is the founder and CEO of a company called Quintessence Labs, and let's welcome him. Vikram, welcome to Techstrong TV. It's nice to have you on here.

Thank you for having me, Alan. Real pleasure to be here. Thank you.

So I understand you're in New York today, having just arrived, actually, Australia via Auckland, New Zealand. I've done that flight. It's a flight into Newark.

And yeah, that's a flight okay. But I appreciate you getting on. Your body probably doesn't know exactly what time it is, but that's okay.

Still working it out. Oh, yeah. You'll figure it out.

Vikram, I mentioned you're the founder and CEO of Quintessence Labs, but let's go to Vikram before Quintessence. Let's understand a little bit about your makeup. What gets someone to travel halfway around the world to talk security and crypto agility and so forth?

Let us hear a little bit about your path. Well, thank you very much, Alan. Yeah, quite a career in IT over a number of years.

Had the good fortune to be at graduate school, something called the Sloan program at Stanford a number of years ago. An amazing program, but on finishing that, had the remarkable good fortune to sit in on some classes taught at quantum physics by a gentleman called Steve Chu, who actually went on to become, way back when, Energy Secretary for the United States. Nobel Laureate in physics, and he exposed us to the idea that we are on the cusp of being able to harness quantum effects to create all kinds of new capabilities.

I'm sure you've heard a lot about quantum computing. There's quantum sensing, but equally, quantum security. Now, this struck me as a really important problem, something I was very interested in, and something, even though it wasn't a thing then, but that in my perception, was something that really would need addressing.

And so oddly, went back and I found back at my doorstep in Australia, they were about to embark on some cutting-edge research at the intersection of quantum and cybersecurity. I was really fortunate to be a member of this amazing team they had, and this is at the Australian National University, and we had some world firsts in the application of quantum effects to deliver strong data protection. Culminating out of that research was the seed of science, which then resulted in my being able to form Quintessence Labs well over a decade ago now.

Really? Oh, so this sounds to me like you found the passion of your life in quantum and then quantum security, right where it intersects, and you've spent the last 10 years exploring that. Yeah.

Absolutely, Alan. It's funny you say that because I never really followed... I heard of quantum.

I kind of know what the idea behind quantum computing is and why it's a threat to our cryptography and everything else, but I'm more of a generalist, let's call it. " Mm-hmm. " Yeah.

Five years later, still five to 10 years out. 10 years later, still five to 10 years out. But now, that's changing.

Right? Agreed. Now that's changing.

It's no longer five to 10 years out. We could taste it. IBM is pledging to have something, I think, by 2029 or 2028.

Yeah. We're talking a two to three-year window, and we're seeing breakthroughs and technology advances every single day. We really are.

And Alan, it's interesting. It's sort of a bit of a similar trajectory with AI, if you think about it. Yes.

Right? Yeah. It was very similar, 30 years in the making, then all of a sudden with the ChatGPT moment, it sort of exploded into our consciousness and- Yeah ...

gone stratospheric in the last three or four years. Yes, it has. So I think similarly with quantum, it's been, as you said, probably two decades plus in the making, in the maturation of those seeds of science, into things which can start to lay the foundations for practical applications.

And now we're seeing very clearly, as you mentioned, IBM and others have on their roadmaps to deliver what they call a utility-scale quantum computer, before the end of this decade. So, roundabout, as you said, the 2029 timeframe. And equally, much as there's been progress on the hardware side, from a risk to cryptography side, there have been equal advancements in software as well.

Late last year, Google published something suggesting that was down to a million qubits. So that's a 1,000-fold reduction, and that journey's not finished. It's likely over the next few years to continue.

Plus, there's the possibility of alternative algorithms, which might be partially run on supercomputers and partially on quantum computers through a hybrid, which also offer interesting promise. Absolutely. Vikram, before we jump into that, though, I'm getting the sense you're humble and modest.

Let's return back to your work, both at the Australia University and over the last 10 years at Quintessence Labs. If I'm not mistaken, you were singled out or acknowledged by the Australian government, the Australian Prime Minister's office, as one of the leaders in quantum- Well- ... security?

Thank you very much, Alan. I was very fortunate, in November last year to be the recipient of the Australian Prime Minister's Prize for Innovation for work in quantum. While I had this tremendous honor to be recognized, I think to be fair, it really is representative of the tremendous work done by our team at Quintessence Labs in making advancements, fundamental advancements, in quantum cybersecurity, to the point where we do now have that science going to tech and then tech going into solving problems and being deployed globally today.

Absolutely. We've been involved a little bit recently with quantum security with our friends at DigiCert. Right.

And so I've had the chance to interview and speak with many quantum experts out there. And one of the things that we saw was the idea of what we call, take it, I forget what the exact term is, but we're going to steal it now and decrypt it later kind of thing. Yeah.

Right? Mm-hmm. Harvest Now, Decrypt Later, I guess is the term.

Yep. And this is a real problem as we get closer to the time where Q-day arrives and we can, not we, the bad guys can- Mm-hmm ... decrypt payloads that they've been harvesting.

This becomes more and more of a problem, right? Because the data that gets harvested, Vikram, in my mind, is almost like radioactive data, right? It has a- Yeah ...

half-life. Mm-hmm. And so every X period of time, half of that data becomes obsolete, not worth anything.

However, that's fine when you're 10 years out and that half-life is every year, right? So in 10 years- Right ... but when that Q-date, the runway's not that long, the half-life doesn't necessarily protect you as much anymore.

The radioactivity, right, doesn't protect you as much. And it's a valid strategy by these, call them bad guys, call them hackers, call them whatever you want to call them. Yeah.

But they're figuring they're going to harvest this sooner than later. Absolutely, Alan, and to your points there, probably a couple of ideas to throw in there. So one is, as we've just discussed, that day where a cryptographically relevant quantum computer, as they call it, will become a reality, is now not so much a theoretical date, but something which will practically be achieved.

I think we can see a clear pathway towards that. But right now, today, as you said, these Harvest Now, Decrypt Later or Handel attacks, as we call them, are rife. We understand state-sponsored activity is ongoing, where, as you noted, data which has a short half-life perhaps is not so much at risk.

But there are very valuable information sets which are being targeted by the Harvest Now, Decrypt Later actors, whether they're valuable intellectual property, designs of technology, medical devices, or medical technologies which take a decade to mature, or indeed, state secrets. All of these need to be protected today, but many of them need to be protected 10 years out from now, and such data is at risk, and its compromise could have tremendous political, geopolitical, and financial consequences. Oh, absolutely.

Yeah. So talk to us about what Quintessence Labs is doing to help us here. Yeah.

We believe to protect well against such attacks should be a critical priority today. As you've rightly noted, the likelihood of having a quantum computer at scale has now very much come into planning horizons for many chief information security officers. Now, the interesting thing is that the time to transition or important thing, maybe more correctly say, is non-trivial for large organizations.

To change cryptographic infrastructure to become quantum resilient is, for many organizations, a three-plus-year journey. So we should really, as a imperative, start understanding what crypto we have today. So I think a lot of organizations are actively involved in crypto inventory.

From that, build a roadmap to transition to a quantum resilient posture, start some trials and pilot programs to understand what it does take to transition, and then implement that roadmap. At Quintessence Labs, we believe there are four key elements to being well prepared. The first of those is quite a simple one to implement, is to remove the risk of pseudorandom numbers, which are used to fashion cryptographic credentials.

So let's use a true random number source. It turns out quantum is a good one. So at Quintessence Labs, we have something about the size of a cell phone.

It's a PCIe card form factor but also available as an appliance, which puts out a gigabit per second of full entropy, so a billion random numbers per second. And in fact, it now appears on the NIST approved website as approved sources of entropy. Right.

The second is to be able to manage encryption keys at very large scale with the performance, the resilience, and the control that large enterprises require. So if we look at today, we're managing probably thousands, tens of thousands of encryption keys. But as we move to 5G, 6G, and fine-grained encryption, that will move IoT also to millions, if not hundreds of millions of keys.

So to be able to manage at that scale with the performance and redundancy that's required is another, we believe, essential piece of this. The third element is about crypto agility. So as we see, or as you may be aware, Alan, about 18 months ago, the NIST standardized the first three so-called PQCs, Post-Quantum Cryptographic algorithms.

And that, we understand, is just the beginning. Over the next decade, we understand there will be several dozen new ciphers that will be standardized. So enterprises will be in a situation where they have to handle legacy ciphers, existing ciphers that we have today, but also transition to these new PQCs as they're progressively announced.

And to be able to handle that transition smoothly, you need to have an agility to be able to ingest these new algorithms as and when they are announced, so you're not investing huge costs every time a new cryptographic algorithm is standardized. So crypto agility is the third piece that we deliver to market, that ability to support existing legacy ciphers, sorry, and existing ciphers today, but equally bring in the new PQCs as they are standardized. And the final piece that's critical is the secure distribution of these keys.

So we have a product called Q-Connect, which allows you to distribute these keys very securely between locations that need to exchange cryptographic keys. Collectively, these capabilities give you the cryptographic infrastructure foundations, security infrastructure foundations, to support a comprehensive and agile transition to a quantum-resilient posture. I love it.

Vikram, these interviews are only 15 minutes, and we're out of time. But for people who want to get more information about Quintessence Labs, what's the website? Well, thank you.

com. We have a host of information available there, and we would love for anyone that's interested to contact us. We will also be exhibiting at the RSA Security Conference upcoming- Next week?

Mm-hmm ... and we're booth 4300 there. Fantastic.

4300. I'm just thinking about that floor. But RSA is a great show for you there.

I'm actually looking forward to seeing the presence quantum has this year at RSA, because I think that'll be a good indicator as well. Sort of like the predictability markets, by what presence you see how... You could probably make a bet to see how real it is.

How it develops, right? Yes. How it develops.

Yep. Mm-hmm. Anyway, Vikram, I know your body is telling you it might be bedtime, so I'm going to let you go.

Rest up. Good luck in New York. Safe travels to San Francisco for RSA.

Hopefully, we'll see you there. Thank you very much, Alan. Real pleasure to chat with you today.

Pleasure. My pleasure. Vikram Sharma, founder, CEO, Quintessence Labs here on TechstrongTV.

We're going to take a break. We'll be back in a minute. Hey everyone, it's Alan Shimel, founder CEO here at Techstrong Group.

Really happy to introduce this next session here for you. In this session, we are going to have Futurum's Fernando Montenegro, who is the analyst in the security cyberspace, speaking with Ryan Jones. Ryan is the partner director of product for Power Platform Managed Platform over at Microsoft.

Great conversation with Ryan and Fernando. Fernando's going to talk to Ryan as we explore how organizations can securely scale agentic apps, including Power Platform's governance capabilities. This is going to include managed environments, adaptive risk models, and life cycle controls.

Hopefully, you'll get out of this video practical guidance for balancing innovation with compliance in an age of AI-first development. Let's listen in on Fernando and Ryan. Alan, thank you very much.

So I'm Fernando Montenegro. I am VP of security research over at Futurum, and I'm thrilled to be here with Ryan Jones to talk about the broader topic of AI governance. Ryan, want to say a few words before we get started?

Yeah. Thanks so much, Fernando. My name is Ryan.

I work on a number of the security, governance, and operational capabilities that we provide not only to our AI agents, but also that we provide to our low-code apps and automations that run on the Power Platform as well. Have you come across something more specific to AI risks or AI governance concerns that surface above and beyond this data flow, and sharing, and others? As we look at the maturity of agents, we see that they kind of go from being assistants that are completely directed by humans to still interactive agents where humans are dispatching tasks, but the agent is completing them on behalf of the human, and then we see those fully autonomous agents.

And I would say that that 10% to 20% is really more over on the end of the spectrum with those fully autonomous agents than it is with my little assistant agent or something like that. " The second scenario that we see is we're in the very early innings of AI, and so there are lots of cases where agents need help, where they sometimes get stuck. And so some of the things that we've been trying to add into our products and our offerings are things like within Power Apps, we have the agent feed, where a human can see what all the agents are doing for them.

And then within Copilot Studio, the request information action, which actually allows us to define an agent such that it can engage with humans as needed. So what has been your exposure, your experience? What kind of considerations do you have in this topic of model drift and model security and so on?

Yeah. I think that, it's funny, we talked about how what's old is new again earlier, right? Yep.

We've had static tests that we perform against software for a long time. And what's interesting is seeing how that is evolving because models are less deterministic than traditional software. We call it stochastic life, right?

And so as a part of that, one of the capabilities that we've added to Copilot Studio is the ability to add tests and evaluations so that as our technology improves, as makers and builders go through and they modify what tools their agents can use or what knowledge sources are used to ground those agents, those test cases, those evals can run and can return a result so that folks, as they are evolving, they know whether or not they're actually improving the quality of their agents. Because what we find is that the first day that an agent is shipped in an organization, this may sound negative, but that's going to be the worst that that agent ever is. Okay?

It's only going to get better over time as folks refine the knowledge sources, as folks refine the tools, as folks look at and improve the success rate across those evals over time. And so I think that those quality gates that we've had in software for a long time, we have those with AI as well. Mm-hmm.

I think also, a lot of times, an individual maker, they're going to be the folks that are really interested in whether or not that agent really works well or not, while IT is going to take a bigger pictureLook at things. Sure. Right?

They're going to want to understand in aggregate how are things looking, are they healthy or not. And it could be that if they see an agent that's not performing well, but maybe just you and I use it, IT probably doesn't care. But if I have an agent that 20,000 people used this month, IT is going to care.

And so those same views that we provide to our makers to understand whether or not their agents are healthy, we provide those aggregated views for the admins as well. In fact, had a large customer in the energy industry where someone built an agent, and it was for them, and they shared it, and it kind of grew and grew and grew. Next thing they knew, they had 10,000 people using it.

They moved on to work on other things, right? " And so they took it over. They added it into their portfolio of applications that they managed.

And the thing was, they saw it not as a burden, but rather as an opportunity because there's an application that's out there that delivers value to tens of thousands of people in the business every month, and their dev cost up to that point had been zero. So it was a win-win for everybody. Once the technology security teams build the guardrails, right, then the business users are free to go work on those use cases.

So what kind of advice do you think would be applicable to those technology and security teams in terms of getting them ready to build those guardrails or to leverage what they have to implement those guardrails? I think enumerating the categories or the dimensions of risk is one of the first steps. There are huge categories of risk that these teams can eliminate through how they define policies.

And to be clear, I don't mean policies like a Word document. I mean- Yeah ... policies that are codified in the Power Platform and Copilot Studio and these sorts of things.

Sure. Organizations don't want a random person in their company to build a workflow that takes information from their core ERP system and pushes it to Twitter, right? We have the controls that allow you to preclude that.

What would you consider to be from a governance angle? You mentioned, okay, let's not focus on use cases. What would the advice for, okay, let's move this forward, right?

" I think the first thing that we see people do is they define a zoned governance framework or a zoned governance approach, right? They decide within their company or their organization what does green, what does yellow, what does red look like. Mm-hmm.

And then they go through, and they define that using the tools that we provide through the Power Platform and through Copilot Studio. I think the second thing that we see folks do is that helps with kind of the supply side, right? That sees to it that the technology is available and accessible for folks- Mm-hmm ...

across the organization. But then there's this strong demand element. Because gosh, I was talking to another big company in the credit processing space a couple of weeks ago, and they had- Yeah ...

this amazing governance framework set up. But they didn't do anything to stimulate demand, right? And so the next thing that we see is reaching out to the businesses, not to harvest their use cases, but to help them implement their use cases.

Things like hackathons, things like training- Mm-hmm ... things where for the people that are interested and excited about transformation through technology, where they can roll up their sleeves and get into it. I mean- Mm-hmm ...

the number of apps and agents and automations that came out of those couple day training session and hackathons, it blows my mind every time I have the opportunity to participate in one of them. And it's fascinating because you see the passion of the people in the business. You see their ideas come to life.

" And what you highlight here is super interesting because one of the things we talk about in the context of platforms is how you can have that network effect of you've already configured something in your environment for a particular use case, like you said, Entra groups for identity, and how that can accelerate the time to value, if you will, within AI development because, hey, you're building on a foundation that you already built for your organization. So I think that's a really powerful message, right? And it's something I tie back to how do we help technology and security teams build that scaffolding so that those business users can go play on those environments.

1,000%. And I think that in a lot of-circumstances, it means, standing on the shoulders of giants that came ahead of us, right? Yep.

What organization today doesn't have Entra deployed in one form or another for user and group management? And so why wouldn't we use those grouping constructs as a foundational capability around which we build our security and governance frameworks, right? It's already there.

It already works. And I think that is one of the things that's a little bit differentiating around the offerings that we provide in the space. Because- Mm-hmm ...

I build an app, an agent, an automation from day zero. It's Entra authenticated and authorized, right? Another thing that we're seeing that's super common right now is as companies are trying to figure out how do they get these AI tools into the hands of people across the organization, and how does that center of excellence or that center of an enablement help people in the various business units up-skill and drive transformation?

One of the things that we're seeing is that our customers who already had a center of enablement or a center of excellence built out for low-code applications and automations, they're moving much, much faster when it comes to agentic transformation. Because a lot of the foundational governance concepts that you need to have in place, they're modality or client agnostic. " I think that one of the areas that we want people to be aware of, like we talk about in our research, is that this evolution in models, we shouldn't be, just like you said about the use cases, just like the use case conversation, you shouldn't be waiting for the use cases before you get started kind of thing.

We shouldn't be waiting for a perfect model to solve, okay, once we have this model, this is how we're going to do this. No, because these models are evolving constantly, right? And if you architect your AI governance framework right, you build in or you leverage the build in, the monitoring capabilities to observe how a particular model is evolving, how a particular model is behaving.

So yes, it is a critical component, observing how these things are evolving. NET framework or what version of Python I was using to deliver services to them. And so I think it's a little bit interesting that folks are looking for that level of control with some of these models.

And I think that if we zoom out and ask ourselves, apply the good old five whys to why folks are looking for that, they want to make sure that as new models are available, it doesn't cause functional regressions in their agents. And the thing is, like we were talking about earlier, that's quite literally why we have tests and evals, right? And that's where, by the way, if for some reason, even though I don't think I've seen it practically speaking in the last year or so, if folks did see a regression as a result of a new model, awesome.

At that point, yes, you want the control to go back to an older version. But we're not really seeing that in practice that much, so... Yeah.

This talk track of multiple tools for your SaaS apps within the business environments is something that, it's a shared pain for security teams as well. Because when we speak with security executives and their teams, they are swiveling between multiple tools on the environment as well. As a matter of fact, we're working now on a report on security platforms precisely on that note.

And one of the areas that we are tracking is AI for security, right? In the context of how do the agents that are now being deployed within Sentinel, for example, right, are helping with, okay, let's do exactly what you're describing from a low-code, no-code perspective. I know it's on the Power Platform, but we're seeing a similar thing on the security platforms as well.

And there is tremendous interest in doing that, provided that, yes, we've handled the governance and risk constraints around those. So absolutely, this is a phenomenal time. The joke I make is that, listen, you can wake up at 6:00 in the morning, go to bed at midnight, and this stuff, it keeps coming at you with opportunities, right?

It's information to collect, it's information to parse, and opportunities to make improvements. As you're thinking about how you're evolving the Power Platform, what have you been looking to improve in terms of security and governance capabilities on the platform? Where do you see the platform going in terms of one of the things that, this is more of a higher-end use case, but we do see requests for regulatory compliance.

Remember when the internet was new, and people started creating those blogs that talked about what they ate for lunch or what their dog did that afternoon because they didn't know what else to do with it? Yeah. I feel like we're in the same place right now with AI.

And so I would definitely want to preface anything I say with, these are early innings. And so I kind of don't know. Okay?

Sure. At the same time, as we look at the types of regulations that are coming into play with the EU AI Act, some such examples that we're seeing there are like, hey, these particular types of data need to be handled in a particular way. And one of the things that we've started doing within Copilot Studio is surfacing those data labels, those information protection labels, in the response so that folks don't inadvertently start working with sensitive data in a way that they don't intend to.

And I foresee that in the fullness of time, this will continue to grow. One of the things that we're seeing is we have a capability in the platform today called Advisor. And Advisor constantly scans over the agents and the apps and the automations to make recommendations in a reactive governance or reactive security perspective.

Because we believe strongly in the principle of trust but verify. And one of the things that we're starting to see with Advisor and the way that it can iterate through AI-generated app and agent descriptions, is we can actually start to flag when some of these apps or agents may be getting too close to that boundary of what acceptable use policy within a company looks like. And so there's definitely something interesting going there.

So one of the areas that when we speak with security practitioners comes up a lot is they are balancing two very distinct problems. On one hand, they are absolutely swamped. The other is we need to balance two things.

On one hand, we want to use as much as possible of the broader tooling we already have, the security platform conversation that we are observing, right? That being said, there is still, in many cases, particularly the more novel use cases, there is a need to work with third parties. What's been your experience navigating this platform and ecosystem scenario in the conversations you've had as people have been using your platform?

Yeah. I think that what we try to do is we try to start from, first and foremost, providing those foundational security primitives that people need to be able to leverage these capabilities safely. And that has to be native within the platform, right?

If I have to go find an authentication provider or find an authorization service or figure out my auditing and those sorts of scenarios, that's a non-starter, right? And so we have to provide those capabilities from the get-go across Power Platform and Copilot Studio. I think the next layer above that is if I think about the tools that someone in the CISO's organization is using on a daily basis, I'd love to think that they come to the Power Platform admin center every day, but I know that's not true, right?

Sure. They're spending their time in Defender experiences. They're spending their time in Sentinel experiences.

And so it's critically important that all of the telemetry, all of the audit logs, and these sorts of things naturally flow into those systems because we have to meet those security professionals where they are. And then I think the final thing that we're seeing is there are some unique and novel risks in some cases with AI, right? When we look at things like prompt injection and the emerging product categories of XDR for AI, does Microsoft have some solutions in that space with Defender?

Yes. Is it also such a quickly evolving product category that we need to plug into the broader ecosystem? Yes.

And so, the same extensibility hooks that we use for integrating with Defender are actually the exact same APIs that we allow partners like Zenity to connect to, so that they can provide additional defense and depth when it comes to particular risks like prompt injection. Ryan, this was a phenomenal conversation. Thank you so much for the time.

Hey, thank you so much for your time and for all the awesome discussion. And my hope is that folks, as they hear what we discussed today, they'll feel confident, they'll feel empowered that they have the capabilities needed to manage that security, governance, operational availability risk, and that they'll be able to parlay that into accelerating how AI is able to transform their business and deliver outcomes for their employees as well as their customers. Can't wait to see what's next.

I think that as I ponder on what we discussed, a few things. First and foremost, this notion that you have been building a platform to begin with in terms of low-code, no-code before, and then building the AI capabilities on top of that does give people the benefit of building on what they've already done. It does give the benefit of tying to the rest of their ecosystem.

And it's as much about the culture of let's try and get started and work on different types of use cases without trying to boil the ocean. We're going to build a capability that accommodates different use cases, different levels of governance requirements, right? And then we're going to help those teams start to work on those particular scenarios.

I look forward to seeing how the platform evolves and capabilities. This area never stops. One of the taglines I use is that there's never a dull day in this industry, and that's the case here.

Hey, everyone. " My next guest, I want to introduce you to him. I'm really happy to have him here.

His name is Willie Tejada. T- Tejeda? It's good enough, Alan.

Willie, I apologize. It's good enough. Willie is the GM and SVP of Aviatrix.

Willie, pronounce your name right, first of all. Let's get- Tejada ... let's correct.

Tejada. Tejada. It's pretty close.

Yeah, Tejada. There you go. Much easier.

Tejada. Just the way it's spelled. Willie, you're GM SVP here, but you weren't born that way, right?

No. You had a- No ... a life.

Like most folks, I had a journey to actually get here that puts me in front of this conversation, Alan. Thanks for actually having me. My career in technology has spanned...

I'm old, so it spans over 25, 30 years. And in security, I was fortunate enough to have one of my startups bought by Akamai Technologies. Mm-hmm.

And then one of the things that we did back then is we saw that many of the features were being used for security. And what we ended up doing is standing up the first security products for Akamai, and that was in web application firewall, their DDoS type of product, basically- Really? were the first kind of entry points.

Now, I think the security products are the largest revenue producer for Akamai. Yeah. No, they are.

So were you there when Andy Ellis was CSO, or? Oh, yeah. Absolutely.

I know Andy very well. Yeah, me too. Spent lots of time actually with him.

Andy's a friend. And then, my latest stint before coming to Aviatrix was at Zscaler, working for Jay and- Sure, I know Jay too ... yeah, heading up their what they call their takeoff team products.

So you can kind of think of them, Alan, as kind of their emerging products. And so I knew very well kind of like the, I'll call it workload protection, the digital experience monitoring area, as well as the data protection area. And then what was really interesting about how I crossed paths with Aviatrix is I owned the workload protection business at Zscaler, and a colleague of mine introduced me to Doug Merritt, who's now our CEO.

And Doug was in the midst, basically, of pivoting Aviatrix from a multi-cloud networking company to a security company. And what I realized was, back at Zscaler, if we had been able to use the network as an enforcement point, the workload protection business, number one, would've been much easier, but it would also actually have been able to future-proof a lot of things. Because today, we posit at Aviatrix that the largest unguarded attack surface area isn't at the perimeter.

It's actually in between the cloud workloads. Yeah. And so every app, every data- Well, there is no perimeter anymore- Exactly ...

is the answer, right? Exactly. It's funny, I remember being at an America's Growth Capital Cloud Security panel that I moderated.

Jay Chaudhry had just- Yeah ... started Zscaler, and he got up there and said that, that the perimeter's gone. Yeah.

The perimeter's gone. It's all about what's in the cloud. And a lot of people in the audience were clutching their pearls, you know what I mean?

But Jay's not a dumb person. No, not at all. Yeah.

And there you go. I think for the most part, most folks really, really oftentimes it's trying to guard that front door when the reality actually is, is once attackers actually get in, they move laterally inside the clouds to get to high-value assets. And so that's where Aviatrix spends its time.

That's where we deliver value, protecting those high-value workloads and applications by utilizing the network as an enforcement layer. So is it like micro-segmentation kind of stuff, or? It is micro-segmentation, but again, if you think about dissolving your constructs of how you built a security stack on-prem, so you know, typically, oh, I got a firewall, I have an app device, I have all these other pieces, and you built it from the ground up and said, "Great, I'm going to focus on cloud workloads," not user-centric zero trust, but let's call it workload-centric zero trust.

If you're doing it from that standpoint, then you'll do these principles like, great, you need to be in line to traffic. Great, your enforcement point needs to be close to the workload of the VPC or the VNet. You have to do all those types of things.

So yes, we do micro-segmentation. Yes, we do firewalling. Yes, we do NATting.

You do all these types of things with the sole idea that I'm protecting workloads. So, we get a lot of telemetry from partners like Wiz, and allows us roughly actually toDeal with security in the runtime, the cloud runtime, as we call it, so that when we look at it from that standpoint, the network is an ideal enforcement layer. Alan, what I would say is, think about the entity we're trying to protect, modern cloud workloads.

When you went from a VM, you lifted and shifted basically to a VM, a traditional next-generation firewall, probably fine, probably north-south traffic basically is going to be okay. But when you think about the progression of that, it's moved to Kubernetes, it moves to serverless, it moves to autonomous agents, right? If you have an agent-based architecture for protection, how do you do that basically with a serverless?

Just when you think about the ephemeral aspects of workloads, they disappear and they come back, and IPs are different. So looking at it from that standpoint, the ideal scenario to get pervasive workload protection is actually the network. Right.

We utilized 10 years of building an asset of multi-cloud networking and orchestration, and now we're purposing it for protecting workloads. When you think of it, it's the one constant, right? You know- In a world where we're all working from home or from anywhere, there is no perimeter, there is no moat.

The only constant is we're all connected, right? You know, it- And that's how you got to look at it. You got it so fast, Alan.

I almost had to skip a beat because you got it so fast. Again, thinking about it from this idea of some of the things that we deal with is enterprises almost always believe that the cloud network is implicitly trusted, right? That's one of the things that comes about.

And then the rest of the security industry has been primarily focused on locking the front door. But- Yeah ... in the cloud and workloads, it's as if you locked the front door and moved everything inside of a building that has no walls, right?

Yeah. That's basically where the gap really lies. So, we find roughly that the last five years of security has been really focused on end-user-centric zero trust, and we think, and being accelerated by agents, that the next five years, well, a lot of the focus will be on essentially what we refer to as workload-centric zero trust.

And so that's what we refer to as our cloud-native security fabric. Love it. Willie, before we jump into the topic of discussion today, for people who want to get more information about Aviatrix, where do they go?

ai. The other thing that I think practitioners would find high value is we provide some threat research resources, like a threat research center. So you can come to find out about Aviatrix, but probably more importantly, come to find out about threats and other things that you should know as a security practitioner, actually come to Aviatrix, and won't be product-based, but can help you do your job.

Excellent. I love it. Let's pivot a little bit.

So I guess it was earlier this week, because today's already Friday when we record it, the White House released their cyber strategy for America. And I'm warning you, I've got some opinions on this. But I'm going to let you go first.

What was your take? Yeah. All right, so let's do this, Alan.

Let's give credit where credit's due first, right? Okay. On one side, I'd say this is the strongest presidential cybersecurity kind of posture statement that I've seen in my career, right?

Is one side. But I think what's left up is the execution actually of it. So they should get credit, basically, for putting this posture actually out.

But, the other side of it is, you almost have to hold the applause because one of the things that I think is going to be important is about how the execution happens around roughly kind of the posture statement itself. And look, I think a lot of this actually has to do with how the public and the private sector actually work together. One of the, I'll call criticalness is that, of course, Aviatrix likely has i- in this scenario, is a lot of the definitions of it, we think because of the threat landscape being in the cloud, is built on protecting end users, like we'd mentioned before, when the real threat in front of us isn't the perimeter, it's actually in the cloud itself.

And so we think that there's, while they define pillars, I think that there's still a lot of specificity that they can actually make to have this position actually translate to hardened execution. Yeah. Look, I wrote an article on this.

My views are out there. You can check it out on Security Boulevard. Grab it on LinkedIn.

To me, this is akin to what we've been hearing about the healthcare plan we're going to get for the last 10 years. It's going to be huge. It's going to be great.

You're going to have less money for drugs. You're going to have taking the insurance companies out. Well, we took that same analogy and said, "We're going to have a great cyber plan.

We're going to be offensive. We're going to be offensive cyber warriors, and we're going to work public and private," but make no mention of CISA, the agency that's supposed to be in charge of that public and private. That they've cut the budgets and there's probably less than 1,000 people, and everyone I know who worked there left.

I mean, it's-Kind of crazy. But it goes on. We're going to cut regulation.

Now, normally, I'm not for government regulation, I'll be honest with you. I'm not a big government regulator guy. But when it comes to cybersecurity, especially critical infrastructure that transcends public government-owned infrastructure, we're talking about utilities, healthcare, critical infrastructure.

This isn't a case of physician heal thyself. " You need standards. Look, I've been in security for 30 years.

I've seen this, right? And for a long time, the security industry tried to implement some standards to sort of veto, not veto, but to negate the government having to, right? The whole PCI, if you remember back.

No. 100%. I mean, you've been around, you know.

Yeah. No. We're talking the same language here.

We are. You know what? If I build on what you say, there's one side of it, basically, which is just, as you said, the resources and you had agencies and departments doing good work, actually, in terms of standards like CISA.

You had an entire industry basically doing mappings to how does my solution map to NIST or CISA? Yeah. So, those frameworks could continually be invested in.

But I'll even take another angle, actually, at this in terms of that scenario of what they need to do in this area is, the people writing those national cybersecurity policies, they deeply understand endpoint identities, zero trust. They've been well-briefed. But the cloud network layer is new territory.

And so, from our vantage point, the industry hasn't been talking about this, and so that's where a lot of the focus actually is. But the largest threat, as I opened with, is this unguarded attack surface area that's actually in the cloud. And then to your point about standards, Alan, it's like where could we make some ground?

Look, first, you could have cloud network security standards, right? Second, you could do what? AI agent traffic visibility as a standard.

Would be nice. Right? Mm-hmm.

Yeah. Those two things basically would be really fantastic in terms of really getting back to the substance that you're talking about. And then, back down to the scenario of organizations, you can have public and private cloud security coalitions.

The things that help us close the gap between operational and taking a paper, but basically making it really enforceable in execution. These are things, like you said, they have to be more than just notions, right? They have to actually be grounded actually in either agencies putting forth very strong standards.

And like I mentioned before, it's one thing to be rooted actually in what was the trailing architectures, but today, how fast things are moving, I think we got to look forward basically in terms of how are AI agents going to impact these pieces, and where are the areas that we actually see are being breached, and we think it's the cloud network is that largest liability. Absolutely. It's an interesting point you make there.

I do think that the cybersecurity posture of this nation, and make no mistake, this nation, the US, is a hyper-connected society at the B2B level, the B2C level, and everything else. Those are the kinds of situations that scream out for public-private partnership. No private industry is going to be able to do it themselves.

Let's look at cloud, for instance. You mentioned cloud alliances. Like you have the CSA, Jim Reavis, the Cloud Security Alliance.

Sure. They've been doing good yeoman's work now for, I don't know, 12 years, maybe more. Right?

I'm trying to think. I was there at the first meeting at RSA when they formed the CSA. My friend Rich Mogull's over there now as the analyst in residence or whatever.

They do a great job. They just came out with a whole bunch of new stuff. But the problem is this, where's the teeth, right?

How do you get organizations to do more than shake their head and say, "That's nice"? And that's always been a problem in security, right? Is because for each company, it's a risk management decision that they make.

What I may consider too risky, you may not. Yeah. And- Yeah ...

and so that's why when it comes to things like critical infrastructure, I do think you need some standard. I always said to people about security compliance, security compliance 999 out of 1,000 times is lowest common denominator security. It's the bare minimum of what you need to do.

You should aim higher. Yeah, no. But if you're not even going to have...

Makes no sense to me. Look, I think the things that you're actually saying, Alan, when you think about when agencies won't show up, the private sector has to be in the room, right? Is basically what it comes down to.

So, yeah, there's no doubt in my mind that, again, I wanted to give credit where it's due. It's great. They put a position actually out.

And it's starting these conversations that you and I are actually having here. Yeah. But to your point, if there's no teeth in it, if there's not muscle actually behind the NIST and the CISAs actually of the world, then the bottom line is much less identity and all these other areas that we actually know.

The cloud network is where-American enterprise and government infrastructure actually lives now. If we don't secure it, then what else really matters in my mind from that standpoint? So a lot of what we're actually rooting for is great.

It's a great gesture in putting out a framework along those lines. But again, putting some of the things that I mentioned, especially around cloud network attack surface area, putting some of those motions actually in place, I think go a long way of putting teeth into the system. How do we get cloud network security standards?

How do we impose regulations on AI agent traffic visibility? When you're putting some of these things actually in place in other hardened analogies, the bottom line is that you would deploy cameras in somewhere and mandate that they have cameras to watch certain things that have high protection. We're just saying give us the same level of specificity so that there is compliance and actually advancement in what we're actually trying to do in terms of securing critical infrastructure.

Agreed. Hey, we got a little bit of time left, not much, but I want to take a right turn here. You mentioned AI and agentic AI.

It's the elephant in every conversation, right? These last two, three weeks, I think it's set OPSEC on its head- Yeah ... right, with some of the stuff going on.

It's got to be having a huge impact on what you guys are looking at at Aviatrix. Tell us- It does ... a little bit about it.

Yeah. You know what? So we articulate this macro problem.

We kind of refer to it as the architectural divide. And let me try to explain it actually to you, Alan. So if you think about the two opposing forces that most enterprises are dealing with.

They adopted a cloud because they wanted faster innovation, right? So faster innovation, they changed the way they develop. They have CI/CD pipelines.

They've gone to essentially how fast can they actually build this innovation, and certainly agents and AI are playing a critical role actually in that. That's one vector is what's actually going on basically is great, they've adopted cloud, and that cloud infrastructure has gotten quite complex. So lots of times they had a very well-thought-out cloud, well, we're going to do...

It could be Azure, it could be AWS, it could be GCP, whichever one was the first cloud that they went to. But then all it took was another developer saying, "I like this cloud better," or they acquired another company, and now they have multiple clouds, and the complexity basically grew. Then kind of along the other vector, I would say, is this idea that the workloads are evolving at a pace and have different types.

I mentioned VMs, Kubernetes, serverless. And then think about an AI agent is one of these workloads on steroids, right? Because it's autonomous.

It makes its own decisions. It has skills to connect to all these other pieces of data. And so when you think about those two vectors continuing to grow, that space in between is the attack surface area that all of these bad guys are really trying to actually go get.

So as long as you continue to develop agents and as long as you continue to actually have greater cloud infrastructure, you incorporate Equinix or a Megaport, that complexity is exactly what gets exploited. And so our posit is that what you actually need, and you said this earlier, is a pervasive enforcement layer, and that's where the cloud network actually comes into play. The idea that you could put an agent to monitor all of your agents that you're deploying.

I think one of the stats that I saw was machine identities are 144 to one to human identities. So one, you just got all these things. Think about it, you're trying to monitor all these laptops because that's where user identities are.

Now you're at 144 to one relative to basic cloud. And that doesn't count the agents. Wait till agents- It doesn't ...

really take off. Exactly. You could put another zero in front of that.

And then they operate at machine speed, right? And they're in this kind of scenario. So what are we dealing with in this scenario?

In many of these cases, we're still in education mode, Alan, where trying to explain to people, great, you know what? You need to have your arms around securing your cloud agents, but utilizing that network as the enforcement layer is the thing that's going to allow you to have common policy across all clouds, to have common enforcement close to where the workloads live and where the greatest vulnerability actually is. So yes, we're quite busy in that scenario.

For the folks who get it, they're running actually to us. " But I think, again, we're entering into this next era where what folks will actually think about is what can they do roughly actually to enable themselves to take advantage of the innovation that's coming with AI agents, expansion of workforce, acceleration, basically of a 10X knowledge worker. And to do all those types of things, they have to be confident that they can securely deploy those agents in the cloud, and that's where Aviatrix comes in.

Got it. Hey, Willie. We're over time.

I apologize. I got people in the waiting room for our next interview. I'd love to continue the conversation, though.

I'm going to be at RSA. Is it next week? Next week by the time people see this, if you're there.

I will be, too. We're at Broadcast Alley in a week. Fantastic.

Stop by- Fantastic ... and say hello. I'd love to meet you in person.

I would, too, Alan. Thank you so much. All right.

Here talking about the cyber strategy for America, but more importantly about securing our cloud networks. " We'll be back in a moment. Welcome to "Security Boulevard," the cybersecurity podcast from the Futurum Group.

Each episode explores a variety of topics within cybersecurity and the technologies that drive it. com, the "Security Boulevard" YouTube channel, Techstrong TV, and all of your favorite podcast platforms. Let's meet today's panelists before we jump into the topic for the episode, starting with Fernando.

Hello, everyone. Fernando Montenegro. I lead cybersecurity and resilience research over here at Futurum, and it's always a pleasure to be here.

Good. And we're glad to have you. And joining us this week as co-host is Mr.

Jack Palmer. Hello, everyone. I am the principal analyst and founder of Paradigm Technica, an analyst firm focusing on cybersecurity.

All right. And of course, I'm Tom Hollingsworth. I'm the event lead for Security Field Day, as well as many other security topics at Tech Field Day.

Let's jump into today's episode. And we're going to be talking about hacking, which is a topic that we've brought up before, but the last week, as of this recording, has seen some very interesting developments, specifically around nation state actors and their targets. If you're not keeping up with the news, Striker, which is a large healthcare organization, had to release information that they had been hacked, and not just hacked, as in we took some of their data, but they had most of their systems wiped, including their employees' laptops, phones, and pretty much anything that had lights on it.

And in this case, we're not talking about our good friend Ted Striker, or even William Striker. We're talking about the people who led a strike against Striker and what that could potentially mean for the future of warfare as it is encompassing cybersecurity more and more. So I'm going to open this up to my co-hosts here.

I don't necessarily know that I was shocked that Striker got hacked. I think it was more amusing to see how thoroughly they had been dumped, because you would hope that healthcare and hospitals had better security, but apparently, at least the people who got in touch with them definitely got in touch with them. So let me start by saying a couple of things.

First of all, I have a good friend. She's an amazing threat intelligence analyst. She goes by Striker on social media.

So when I saw the news that Striker was hacked, I was like, "Oh my God. " No, it's fine. Right?

The other thing is that I'm old school, and I'm still one of those, hacking is not a crime people. Right? So I don't like the term.

They weren't hacked. They were attacked. Right?

But your point stands, right, in the context that they were attacked. And listen, we are in the middle of a perilous time with geopolitical implications, and we've seen it time and time again that there are state-affiliated groups that will do things for non-financial reasons, right? And in this day and age where a significant portion of the conversation around defenses and threat modeling focuses on the financial motivation of attackers, which yes, they are there, this is a harsh reminder that there are non-financial motivations, and we've had it here.

I have more to say, but I don't want to monopolize the conversation. Well, I don't disagree with you completely, but I would take issue with a couple points, and I think we need to make a differentiation between hacking, which, as you say, there's sort of ethical hacking and maybe non-ethical hacking, but I think this was much more an attack. And I think the cybersecurity industry has been talking for not years, but decades about nation state attackers, right?

And I think the difference here, as you mentioned, is up until now, and maybe not even up until now, but almost always the nation state attackers are financially motivated. We have seen hacktivist groups that are doing things for politically motivated or social justice reasons, but for the most part, vast majority are financially motivated in one form or another. And in this case, the only financial motivation here was the destruction, the total destruction of another company who was perceived to be apparently a US company and could damage US from somebody who is non-US and doesn't like the US.

But I think what's really striking about this isn't the fact that they were attacked, but was that they were destroyed instead of had their data exfiltrated in ransomware or other typical attack vectors. Yeah. I agree.

Where I'm poking on things a little bit is that, yes, we've seen this type of motivated attacker before, and again, I'm not directly involved in the IR for this or anything, so I'm speaking with second level, third level information, but what appears to have happened here is... There's good and there's badRight? The bad, of course, is that they were attacked and suffered significant disruption.

The good is that, from what I understand, the company did something really good in that some of the medical device networks are segregated. Right? And those medical devices were not affected by this.

Right? In this day and age of flat networks and SDN everything, it's a good reminder that, yeah, some good old-fashioned segregation is warranted, and particularly if you're dealing with this type of mission-critical, life-critical type of environment. And I salute those who work in healthcare IT because they have to deal with that with, what is it?

Chewing gum and bailing wire sometimes, right? But, yeah. So in this case, yes, it was bad, but you know what?

Kudos to the team who segregated their networks and avoided a larger impact. So I'll just throw this out there because I think it's kind of interesting. I think one of the reasons why hospital healthcare IT has been maybe less, hmm, at the front, maybe less rigorous is because there's this kind of understood goal that in a war, you don't attack hospitals.

You also don't attack churches and schools and places of refuge and things like that. But one of the things that we're seeing is a lot of those mores, if you want to call that, for these things are kind of being put by the wayside. And I noticed it a couple of years ago when we started seeing reports that the criminal attackers, people doing it for money, were going after hospitals.

And at the time, it was because, oh, well, hospitals will pay because they don't want to lose lives, and it's a huge hit to their reputation if their entire healthcare system goes down, and that means that they're willing to pay up. But now what we're seeing is people who are not motivated by money but are motivated by ideology or orders are going after them because they make really good soft targets. And they're not the only thing, too.

Power infrastructure is one thing that we keep talking about. And the reason why this is relevant to me is because I was thinking back, oh, man, over 10 years ago, I wrote an article for a ambassador forum where I talked about the fact that what's going to happen when some of these kind of off-limits targets are no longer off-limits, and how does that impact that? Because we know that certain systems are definitely hardened against intrusion because they are common attack vectors.

I think that the CIA servers are probably some of the best on the planet, not just because they keep all the secrets, but because it's the first thing that everybody wants to hack. But a hospital in either in a mid-sized US state or possibly even a rural hospital system make very tempting targets when you know that you can basically kind of waltz in and do whatever you want because they're not focused on keeping attackers out. They're focused on billing and keeping patient records secure.

But it's the minimum necessary to make that happen with the budgets that they have, which as you guys brought up, are often very infinitesimal compared to the cost of an aspirin at that same hospital. Well, I think one of the things you brought up is you mentioned hospitals, you mentioned healthcare, and you mentioned power stations, right? And what occurs to me is that we've talked a lot in the last, I don't know, three, four, five years about critical infrastructure and cybersecurity needing to protect critical infrastructure.

And we had the pipeline incident on the East Coast. I can't remember what the name of the pipeline was that was taken- Colonial Pipeline ... The Colonial Pipeline that was taken down, right?

But more and more with, as interconnected an environment and an interconnected society we have, particularly here in the United States, we're highly dependent on digital communications and the digital world to do business. And more and more things that we wouldn't think of as critical infrastructure are critical infrastructure. So yeah, obviously, your power supplies are, your energy supply, your healthcare is.

But then go down the line and what do those suppliers depend on? And you don't think that, oh, well, an ambulance is dependent on Stryker's medical network for the information it transmits on the way. Or, well, how many of those ambulances are routed by Google, right?

By Waze or by another mapping application, and what happens if that disappears, right? There's a lot of things that secondary and third in what we would think about traditionally as the software supply chain, but it's actually the services supply chain that are also critical infrastructure that we don't think about as that, and that could be very well compromised or attacked by these people who, again, aren't financially motivated, but want to just wreak destruction and havoc across the world. And yes, and every -- yes, and, right?

The coffee, yes, and. And one of the things that this calls out, it's something that we've talked about in the show before, and it continues to be true. We talk about it because it's now that much more important, that much more strategic.

" Yes, software ate the world. Here we are having an indigestion, right? So what ends up happening is that the complexity of that network, exactly as you described, right?

If you ask a bare bones security executive about their environment, they may not understand that, oh, look, the ambulances that are being routed needneed guidance and need that kind of access and so on. One of the things I'm looking into is how does the profession evolve, right? And one of the things that I keep coming back to is because this is all more important, we get more and more specialized in some ways, right?

I think that one of the most important roles that are coming up in industry, particularly for larger companies, right, is not so much the CISO, the chief information security officer, it's the BISO, right, the business unit- Mm-hmm ... information security officer. Because that person, they have the mandate of having one hand in, or one leg in the cybersecurity realm to understand technology, to understand threats, to understand controls, but another view on what does that business unit need, right?

So as we talk to practitioners and sometimes I talk to early career professionals or people wanting to get into the industry, one of the areas that's interesting is, okay, look, cybersecurity is way too big to be a cyber expert for everything. You can't, right? How do you specialize?

And those types of BISO type of roles, and the structure that they need are really interesting in all of this. One of the other parts of that, I'm glad you brought that up, is in cybersecurity, as you think about that specialization, we are very much focused downward and inward as a cybersecurity person, right? Is how do I look at my role and what I'm doing as protecting this service, right?

And we talk about protection all the time. We talk about risk reduction all the time. We have security controls.

It's all focused on the world of IT, which is, in my view, necessary, but it's insufficient. Mm. We really need to think upwards as well, which is we're providing a service to the business, and part of the service that cybersecurity is providing is business uptime and continuity, right, and reliability, right?

So IT thinks about it as if my systems go down because we had a misconfiguration or because the server crashed, the business fails, right? And we need to maintain uptime for the business, right? Cybersecurity needs to think somewhat in the same terms as that I'm protecting these services and these IT environments not just to protect them, but the end goal, the ultimate goal is keeping the business up and running.

And I bring that up because we look at Stryker, and now we don't know all the details, in fact, we have very little details, but we do know that they had a lot of things go wrong simultaneously. And my heart goes out to the CISO and to the security team and the IT team that has probably spent a week plus and is now going to spend another month or two of very sleepless nights, right, trying to put all of this back together. But what plans did people put in place for the catastrophic events that could happen?

Did they do any war gaming? Did they do any planning and thinking about not just what happens if somebody attacks my web server and therefore I need a web firewall, but what happens if they destroy my infrastructure in some form or another, right? I think Tom and I have talked about this before, about Active Directory is a critical component in a lot of environments.

If your Active Directory goes down, everything goes down, right? You can't get anywhere if you can't authenticate. How do you bring up your environment?

How do you bootstrap and get started? Has people thought about these things and think about what does the business need to get running again? And again, phenomenal questions, where one of the ironies of this is my understanding of the Stryker incident so far is that that destruction that you're talking about was achieved via traditional management tools, right?

It's that the way that you wipe laptops is with your MDM tool of choice. And again, that's how we use MDM tools, right? Oh, look, we want to wipe a device.

Great. You wipe a device. Oh, we want to wipe all of the devices.

Mm. And to some extent, this is that how do you navigate the impact of something like this? It's governance, right?

As much as I love to talk about the impact of AI and agents and everything, which is, again, 2026, right? This kind of more traditional security controls are still fundamentally important, right? Was this an issue of, hey, we didn't have proper authentication on our MDM?

Is this an issue of the authorizations weren't set up right, and somebody had the ability to do whatever they wanted? So we need to work through those things and let that be a lesson for every other organization out there. One of the things that I've had, there's quite a few people in industry who brought it up before, it's we need to understand the misses and the near misses, right?

And aviation does this extremely well, right? We need to continue doing that in cyber. I'm hoping that everyone who's reviewing the Stryker incident is looking at, "Hmm, okay, so how is our infrastructure resilient against this?

" And then they improve that a little bit, right? Right. I think about that really as fundamental cybersecurity hygiene.

And the cybersecurity community is very like all techies, right? We get excited by the cool, shiny new toy. Right now, the cool, shiny new toy is AI.

Everything is AI, and we're going to hear all about AI in the RSA Conference, we're going to hear all about AI for the next couple of years. But if organizations don't do basic cybersecurity hygiene, if they don't do authentication and authorization correctly, if they don't do vulnerability scanning, which is very boring, but very critical to your environment. If you don't understand what's going on in your environment, if you don't have good inventory of what's there, you can't protect what you don't know about.

And it's so much of what I see when I talk to CSOs is that's the part they struggle with, is just getting the basics done. " Like, yeah, I get I have a problem, and I'd love to buy your toy, but I got a different problem. I still can't convince my company to make MFA mandatory for the entire company.

Right. Because it's too much friction. But we know what it'd be.

So if we can't get these basics done, how do we get the rest of it done? And this is where I praise the amazing concept that Wendy Nather came up with many years ago, I think she was back at 451, the notion of the cybersecurity poverty line, right? Yes.

We need to understand that there is a level, and I think we've been tiptoeing around this point. Many healthcare institutions, they may struggle with meeting cybersecurity minimums. So how do we help address that problem?

Well, one of the things we can do is how can we lower that cybersecurity-- There's two ways to do this. Either you lower the cybersecurity minimum, or you raise the capabilities, or you raise the resources that somebody has to meet that minimum. And this is one of the areas where I'm a huge fan of the work that CISA and others are doing in helping to, in a way, they are working towards doing both.

On one hand, they are helping people get better cybersecurity insights cheaper. Either it's freely available, like the known exploit of the KEV lists, or the guidance from CISA. All of that is free information hoping to lower the cost of implementing better controls.

At the same time that they are pushing vendors with secure by default to reduce the number of things that may happen. But anyway, it's a complex public policy problem that we're not going to solve in a podcast episode. We're not going to solve in a year or two or five or 10.

It's the maturity of this industry. And incidents like the Striker one is one more notch on, okay, perhaps we need to fix one more thing here. But I think that the Striker problem is something that executives need to pay attention to because it changes the equation of their risk management.

To borrow that line from "Fight Club," if A plus B plus C is less than the cost of a recall, we don't do one. Well, in this case, all of those executives were looking at what is the cost for an outage, what is the likelihood that all systems would be affected, and what is the likelihood that we will get attacked? And they were doing the math to figure out is the cyber insurance going to pay, and all those other things we do.

And that was working off of a flawed assumption, and the flawed assumption was, is the people attacking us wanted to get paid, and that they were going to do the minimum amount of damage and work necessary to make that happen so that they could get paid and move on to a different target. It's the same way that you calculate whether or not a venture capital investment or a private equity investment is going to wreck your company. What's the minimum amount of money that I have to make them to get them out of my organization?

But now you're dealing with another group of people who don't care. Their method is to wipe everything, so now your cost for an outage goes up significantly. And you can't pay them off.

You can't send them money and hope that they go away. They're not leaving until they've salted the earth. And that's the problem when you're dealing with a group of people that are not motivated by money.

They are going to do what they came to do, and you can't stop them. It's very similar to what we dealt with years ago with Fancy Bear and SolarWinds. They weren't motivated by money.

They were motivated by things like intelligence gathering and other non-monetary solutions. And so that's why they were able to sneak in and get very creative in the way that they dropped things, and it took us a long time to root those out. This is the exact opposite.

They're not trying to sneak in quietly. They're trying to make noise. We saw that with the defacements that happened, where they wanted you to know who hacked them.

And if you think this is an isolated incident, not two days later, a robotic surgery company was hacked and had a lot of their systems knocked offline. And I have it on pretty good authority that surgeries were canceled that used those robots because they couldn't verify that the robots wouldn't get knocked offline in the middle of a surgery. You've created an environment where people don't trust the healthcare systeCould you imagine if modern healthcare tried to go back to using paper and pen?

I was telling somebody this, I think it was Jack, I was telling this on a story the other day. I remember, because I used to work for Walmart when I was in high school, I remember one day in the late '90s when the cash register system went down, and we had to go back to using carbons on credit cards. Yeah.

And how much of a nightmare that was. And do you know now you can't actually do that anymore? That's right.

Because most credit cards can't run through a carbon machine because they don't have raised digits on the card face anymore. They're all smooth because we've moved away from that technology. Could you imagine trying to do something-- No knock on doctors and nurses and PAs and medical professionals, because they're going to do everything they can.

But just think about the last time you were in a hospital, the way that they dosed medication. They have to scan into a chart. They have to scan the bottle.

They have to do all these things as a way to double-check to make sure that they're not going to be giving you the wrong medication or giving you the wrong dose or anything like that. That's difficult to overcome on the best of days when it was an accident or when it was a crime. Now, when it's a military assault or something that looks very similar to it, that's going to cause a lot of problems in the healthcare system that's just going to exacerbate the problem.

But then again, that's the point. The point is to make it hurt for people. Now, imagine if they hacked a hydroelectric dam.

Imagine if they hacked the Texas power grid again, only this time they're not attacking it when it's nine degrees outside, they're attacking it when it's 99 degrees outside and shutting off all the air conditioners across the state of Texas. I don't want to live in Houston without an air conditioner. So, you bring up two things that I want to talk about.

One is real quickly, we actually had that more recently than your credit card issue. We had it last year or the year before, I think it was last year, where one of the major service providers that handled auto purchases was- Yeah ... right.

Mm-hmm. They got ransomware attacked, and for a week or two, all the car dealers had to go back to filling out contracts by hand, and that really put a crimp in their business. But more importantly, I think one of the other things that between you and Fernando, Fernando brought up that one of the ways that you wipe all of a company's systems is by using their management tools, right?

And what you were talking about, this being a military attack, this reflects to me the immaturity of the cybersecurity industry. Despite being 40 or 50 years old now, we still haven't put in place some of the manual governance solutions we do have in the military or in the finance system, where you have dual controls for a lot of things. You can't launch a nuclear weapon without having two people approve it simultaneously.

Same thing with finances. There's a lot of places in finances where you can't write a check over a certain amount of money without getting multiple signatures involved to make sure that it's not a hack or it's not you trying to embezzle from the company. And from a company perspective, there's a difference between wiping a single device and destroying all devices with a single command, and something like that maybe should be protected by dual controls or other control methods.

I agree, and the purpose of a dual control is friction, but we are all about eliminating friction. And I hate to break it to you, Jack, but War Games was 50 years ago. You can launch nuclear weapons with one person today.

Yeah, of course. But here's the thing. We as cybersecurity people, we are only thinking about one side of the ledger, right?

We're only thinking about, here we are talking about adding the controls, adding the dual control. And Tom brought it up. What is the risk calculation here, right?

If the dual control is excessive, 999,999 times out of a million that we use it, but that one time it absolutely made sense. Is there the cost trade-off to doing this? And I go back to one of the most...

It was a simple post, but it was one of the most impactful posts I read. Daniel Miessler, he does a lot of AI stuff now, but he wrote years ago about why software is insecure. And it came off to a very simple conclusion.

Software is insecure because the cost of insecure software is something that we are willing to accept, period. The moment that the cost of insecure software becomes too much, we will address it, and here we are addressing it. So the challenge here is that because we are now using technology all over the place, the opportunities for that cost blow up is that much higher.

And that is an evolving conversation with cybersecurity executives, with line of business executives, with senior company management, with regulators and users about, okay, here's what we need to... Here's the environment we're dealing with. And I go back to there's good and there's bad from the Striker incident, right?

Tom's absolutely right. It's horrible that we are now in an environment like this was a reminder that you can be hit with things that are not financial relatedBut honestly, I think it was good that, look, they segregated their net. I go back to the network segregation, right?

We are learning some lessons. Are we learning the lessons fast enough? Probably not.

Well, I'm snorting because we had this lesson that we could've learned two years ago when the Las Vegas casinos got hit, and yeah, it was financially motivated, but it still took down a business that is literally time and money, and that's all they do is they trade time for money at all, right? " I don't know if they did, right? Speaking with security executives after the casino breaches, there were plenty of conversations around afterwards.

And this is the thing, minor soapbox issues. This is like the Stryker incident, the robotic surgery incident, the casinos, the Colonial Pipeline. These are all horrible incidents.

I agree. Right. But are we not overcompensating?

You know the story about Abraham Wald and the bullet holes on planes from World War II? Yes. Right.

Yeah. Are we not talking about survivorship bias here? Right?

Are we not, or availability bias for the incident. Right? Are things decidedly getting worse?

Are we not learning these lessons? I am not sure. I'm optimistic in the sense that think about with all the technology that we have available, with all the attack surface that we have available, are things getting worse?

I don't know. I can see arguments for it. I can see arguments against it.

Well, I go back to, and maybe it's my soapbox because I spend a lot of time in identity and identity security, right? But the casino attacks were in part predicated by user impersonation of IT people to reset passwords, right? Now, what did we hear about late last year, two years later, was the overwhelming number of companies that have hired North Korean workers who are impersonating other people, right?

So we're still not being very good on validating human authentication and understanding that part of the equation, which is your critical infrastructure inside a company, your IT support staff is your critical infrastructure inside your-- the human critical infrastructure, that's kind of critical, right? And again, we don't know the details of the Stryker attack, but rumor has it that it was related to their MDM environment and that somebody got a hold of management credentials, of super user credentials. And if that's the case, then we're still back to basic authentication authorization problems.

And this is my soapbox, and I'll go back to what I said earlier about the sort of shiny thing. A lot of organizations, a lot of CISOs, and a lot of ink is spilled over zero-day vulnerabilities and those types of attacks. And I wrote an article about this on Security Boulevard because we've had two decades of rise in DBIR data that shows that the majority of attacks start with a human and a credential attack.

And Google came out with a cloud report this quarter that said the exact same thing. 83% of the cloud attacks they saw came from an identity attack, right? So why are we focused on vulnerabilities?

It's necessary to focus on vulnerability, but if you don't understand the human side of the equation, then we're still at the root. I am in wholehearted agreement with you on the focus on identity and more, right? I think that it's uncanny, right?

Vulnerabilities play a part, but it's much more about how are these systems used, and these are used by humans and eventually by agents. But my optimistic pushback maybe is, what is a good number, right? Yes, we had Stryk.

What proportion of companies that could have been affected by North Korean fake workers was actually affected, and what is an acceptable number? We still have car accidents but that doesn't mean the roads are not safer, right? Can they be made better?

True. Yes. We still have airplane accidents, right?

But things are getting better. So my question is, from a risk management perspective, we have to up our game to understand this risk trade-off and to guide senior executives, right? Because if we go to a senior executive and say, "Failure is not an option," like Apollo 13, right?

Fine. Works wonderful as a line in a movie. Works wonderful for this NASA mission, but does it work in the real world?

And if we as cybersecurity professionals don't acknowledge these imperfections in the real world, we get laughed out of the room, right? Because our advice doesn't get implemented because it's not realistic. So I'm all for, I'm 100% with you on identity being a key thing.

I just want to make sure that we have the right expectations. It's like my golf gameRight? Listen, if I hit a 100-yard shot to within 15 feet, that is PGA level, right?

The fact that I didn't hit it in the hole shouldn't be a... So it's what are the expectations that people have and should have about cybersecurity? That's my soapbox.

So I want to give you guys a chance to kind of give everyone out there lessons learned from this, and I'll tell you why. Because you bring up a really good point, that after the MGM hack, that people learned a lot in the casino industry, and after this hack, people are going to learn a lot in the healthcare industry, and it's very segregated in that way. " So I'm going to ask both of you, what is one thing that, in general, IT security people need to have taken away from the Striker incident that they can implement in their own organization to prevent something of this scale from happening in the future?

I would say it's not a question of if, it's only a question of when, and therefore focus on how you're going to maintain your business continuity, right? Whatever you need to do to get up and running if a catastrophe happens. That's the lesson.

That's a very good one. Very good. I would add that the major lesson here is understand how the threat model changes and what it means for your organization.

Right? If you are operating under the assumption that your only adversary is script kiddies, like we used to call them, right? Or financial actors, maybe that's not the case, and what does that mean for your environment?

And if I can throw in one more there, is that the absolute, utter, complete importance of identity, right? So on cybersecurity is not purely a technical discipline, right? It is a socioeconomical, political, technical discipline, and the way that users interact with this cybersecurity environment is through identity.

So nail down, if you can get your identity management, that's perfect. All right. We are going to wrap this episode up.

I want to give our hosts a chance to tell you some of the stuff that they're working on, starting with our guest this week, Jack. Jack, if people want to check out some of the stuff you've been working on, where can they go to learn more? com or LinkedIn and Security Boulevard.

com. Fernando, what about you? com is where we post most of our stuff.

We're working on several reports together. When we're recording this, it's the week before the RSA Conference, so you're going to find me running around the expo halls. com, LinkedIn is my favorite, and here.

I love to interact with people, so do reach out and we can chat. " If you enjoyed the conversation, please do us a favor, subscribe on YouTube or in your favorite podcast application so you don't miss any episodes. We also would love it if you'd leave us a rating or review, because that does help the show grow.

com and the Futurum Group. com, the Security Boulevard website, and Techstrong TV website. Or check out the Techstrong TV app, which is available on Apple TV, Roku, and pretty much every smart device out there.

We also want you to follow us on socials, X, Twitter, and LinkedIn. Just look for SecurityBLVD for lots more content. Thanks for tuning in and we'll see you all next week.

I'm Dimitri. You can guess I'm French with the accent, and you can guess I'm a little bit older than 25. And we'll talk about networking, and especially VPC in the networking capabilities of our private cloud VCF.

So I don't know if all of you are more compute, storage, or network, but that's fine even if you don't have your network tattoo. Any cloud has compute needs, virtualization compute needs, storage needs, and network needs. You need those three pillars.

And my background is mainly on the networking, but because I've been working in cloud for a while, I have some knowledge also on compute and storage, and that's cool, and that's what everybody in the cloud administration management should have. Not expertise on everything, but at least some knowledge, and yes, the three pillars again are compute, storage, and networking. On top of that, within VCF, you have your workloads, whatever they are, VMs, containers, private AI.

And on top of that, you have advanced services, and if we stick to networking, load balancing, network observability, but other things like database that was presented just before me. But anyway, enough about VCF, and let's talk about networking. For many years, less and less, but for many yearsPeople ask, why do I need in my VCF network virtualization offered by VCF?

Because I have already my network. My network is the Cisco I love, the Arista I love, whatever, and I love them all. So congratulations, you made the good choice.

Whatever it is, it's a good choice. And that network offers also overlay VXLAN. I'm sure you, or I guess you have heard about this, which is the ability to create virtual networks on your physical infrastructure overlay.

So why adding another network virtualization within VCF when my physical fabric can do it? And before talking about VPC, I'll talk about that quickly. So when you have an application, VMs, containers, at the end of the day, you need to plug that somewhere so people can access your application.

And that application needs switching, routing, maybe load balancing, maybe security with some firewalling, maybe a VPN access to some remote data center. So you need a lot of services, especially network services. And if you do that in the fabric, so your cloud does not offer network services built in, what do you do?

Then you go on your physical fabric. When you have your new application, let's say this beautiful two-tier app, web tier, app tier, you go to your physical fabric, Cisco, Arista, whatever, and you create those two networks for this new application. And because you have overlay, you'll most likely not do VLAN, but you'll do VXLAN on your physical fabric.

That's great. But then you'll go on vCenter and do click, click on vCenter to create your port group VLAN that are mapped to those VXLAN VNI. So you click, clicked on Cisco, Arista, whatever, you click, clicked on vCenter, and then yeah, great.

You can plug your applications into the network, but you need a default gateway. So you do some click, click more on your physical fabric you like. Then you may need some load balancing, so you do click, click on the F5, on the whatever load balancer you have, or maybe VMware AVI.

But anyway, on the vendor you like, and maybe some firewalling and so on and so forth. So you've done a bunch of click, click, click. If you're not the only one managing your cloud, most likely you open tickets to do that, involving the different teams, managing the load balancer, managing the security, managing the physical fabric, and so on and so forth.

And I'll be quick. So when you do it within your cloud, then you don't need to open ticket. All those services are available to you, and that's what VCF with a private cloud offers.

And now you're autonomous to configure all the things you need, compute, storage, network included, consuming those services from the platform for the cloud you have. Like on AWS, you don't open a ticket when you want to deploy an application. On VCF, it's the same.

Your developer doesn't open a ticket to deploy his application, compute, storage, network. And that's what makes the usage of network virtualization in a cloud, a real cloud, where before, okay, it's weeks, it's just a number. It could be weeks, it could be months, or days, depending on how fast you write people to process your tickets, or it can be seconds if you click, click super fast in VCF or use some orchestration, VCF orchestration to deploy your whole application.

Okay? That's it. So I hope that's clear why network virtualization is key and one of the three pillars of any cloud, VCF included.

Sounds good? Okay. 0.

So network virtualization within VCF has been there for years and years and years. But we have this new model, which is pretty cool. So what is it?

A VPC, it's a network bubble, if you ask me. It's a network bubble where you will plug your applications in it. And, oh, VPC, by the way, if you know AWS, it's exactly this, virtual private cloud.

So for once, VMware, we did not invent a new word. We use the industry standard. I don't know if AWS is an industry standard, but am I recorded?

Shoot. Anyway. So we use VPC for virtual private cloud, and it's a network bubble, and you can create that network bubble from VCF, from different components of VCF.

If you're a vCenter admin, beautiful. You can create network directly from the vCenter UI you have been using for years and years and years and you love. Or if you want to use something else like VCF Automation, or if you want to use NSX, anyway, from different VCF components, you can create those network bubbles, or you can also do API automation, Python, Terraform, whatever you love.

And you create those network bubbles with the subnets. 0 with the VPC concept, and that's what I really enjoy is if you're the vCenter admin and you want to be autonomous so you don't open tickets to ask for a new VLAN, a new subnet, a new default gateway, or a new NAT, a new load balancer. When you're the vCenter admin, you don't know what subnet is available to you.

And so within VCF, so the VMware Private Cloud, when you deploy VCF, there is one question, which is, okay, give me your physical servers where I will install ESX, give me this, that, that. And one of the question is, give me an IP block reserved for the future applications running on VCF. And so when you deployed VCF, you had to talk to the network guy, so at some point, to ask them, "Hey, you're using so many IP blocks, so many subnets in your own physical infrastructure.

Actually give me one for VCF, for vSAN, give me one for vCenter, vSAN, for vCenter, vMotion. " Okay? So that's done at the VCF installation.

And then you have this concept, so of external IP blocks. And when somebody, the vCenter admin, the VCFA admin or tenant, or the NSX admin, because you can create those network bubbles from the different VCF components, you don't say what subnet, you just take one of those blocks. A slice of one of those blocks.

Okay, enough of that. And then, okay, you created your network bubbles. Here I have two VPC subnets in my VPC bubble.

And technically how it works, those workloads, VM containers, here I'm showing VMs, they are plugged to those VPC subnets, and they are physically a little bit on ESX1, a little bit on ESX2. But those networks and VPC bubbles are everywhere. And they have a default gateway.

It's a VPC gateway. It's fully distributed. I'm showing it only on ESX1, but it's actually everywhere, on ESX1, ESX2, ESX3.

And so when web one wants to talk to app one on two different subnets, it goes to its default gateway, which is always within its own ESX. And then it's not a VM, this VPC router, it's a process running inside ESX, but it's not a VM. And so, yeah, the distributed router VPC of that VPC blue, takes the traffic and route to app one VM, and will send it to app one VM.

And here it's the same technology we used for 15 years within NSX, which is the component of VCF for network virtualization. 11. It will be encapsulated by ESX1 and sent to ESX2.

So the physical fabric, what does it see? It sees the IP of ESX1 talking to the IP of ESX2. And so any new VPC subnets you create, it's completely transparent to the physical fabric.

You don't need to touch the physical fabric because the traffic is encapsulated. And that physical fabric is using VLAN, is using VXLAN, don't care. The only requirement is ESX1 IP needs to be able to talk to ESX2 IP.

Nothing to do with web and app VMs. Okay. So summary.

Virtual private clouds are the core building block for private cloud experience. So a true cloud experience. Yes, you need compute virtualization, you need storage virtualization, and you need network virtualization, as I talked about before.

And VPC, yeah, it relies behind at the end, it's running on NSX. Even if you create your VPC bubbles and your network things from vCenter, VCFA, whatever, or NSX, at the end, it's implemented in NSX. 0, that's great.

Now, if you have been using VCF for a long time and vCenter and NSX for a long time, and you use, I don't know if you're familiar with NSX, logical routers tier zero, logical routers tier one. 0. You don't need to trash and redo.

You can upgrade, have those applications still running on logical networks created by NSX UI, API, tier zero, tier one segment. 0 deployed with this old, let's call it, how do you say in English? Legacy.

Legacy. Thank you. 0, it will still work, but you need to do click click NSX or API NSX.

Or for the new applications, you can use this new model and now you can give your different users, personas, the vCenter admin, the VCFA tenant, Pepsi, Coke, finance, marketing, this way, so it's autonomous. Okay. A few words, and then I have a live demo, that will clarify all of that, hopefully.

Just a few words on VPC. It does a lot of things, but there is one thing that is important to grasp. So you create your different VPC bubbles, the vCenter admin or whoever, create those VPC bubbles with networks inside.

Now, how do networks communicate between those bubbles? And you can decide, and we'll talk about that on the next slide. You can decide how a VPC bubble talks to another VPC bubble, or the outside world will reach my VPC bubble or stuff in that VPC bubble.

Now if you want more granularity than that, then we have vDefend, which is our firewalling or securityAdd on, where it's not about who can access yes or no my VPC bubble or subnet in my VPC bubble. It's very specific, like, hey, can I do HTTPS but not HTTP? You go protocol level or even deeper than that, IDS, IPS, malware inspection.

That's vDefend. What I'll talk about here is only networking, so who can access it or not access it. Now, if you can access it, you can do whatever you want.

SSH, HTTP, Telnet. If you want to protect more, it's vDefend. So for the access.

So you have multiple bubbles, VPC bubbles, with networks inside. I'm showing tenant one, tenant two with a bunch of bubbles in it. Tenant one, tenant two can be Pepsi and Coke, can be finance, marketing, whatever.

You have the ability to group applications or business units or customers within a tenant. And so if you want everybody to talk to you, then you create a VPC subnet public. Now, if you want only the workloads, the applications in your tenant, Pepsi or finance, to talk to those workloads plugged on that subnet, you make it private transit gateway.

So anybody within that tenant will be able to talk to it, not other tenants, not the outside world. And if you want only the compute, the workload in that bubble to talk to VMs on that subnet private, then you make it private, VPC private, and nobody else will be able to talk to it. Okay?

Can you change those? Are they dynamic to be changed along the way, or once you define that's- No. But you decide where you plug your workload.

So you can create a public, a private, and you decide to plug that VM here. Yes. And six months later, "Oh, shoot, actually, I'd like everybody to talk to it," you can plug it here.

Or that VM is in a private subnet, so nobody can talk to it. Like AWS, you can create an external IP. Mm-hmm.

So you can create an external IP, and now this VM still has a private IP that nobody can talk to outside of the VPC bubble. But people can reach that VM through its NAT type external IP address. Yes.

Okay. Both are possible. Okay.

So that's it for the slides. Now I have a lab, so let's see this in action. Okay.

Still showing. Okay. 0 lab.

You can see, I'm on my vCenter, part of this beautiful VCF. I can log in. Part of this beautiful VCF.

And I have a bunch of applications. Beautiful. 0, which is VPC.

And here you can see I already have a VPC finance created with a public subnet, which is 30 whatever. With its default gateway, with its DHCP server, because I wanted a DHCP server. I have a private subnet with whatever.

How did I create that? Very simply. If I want to create a new subnet, I can just do new subnet.

And I'm the vCenter admin. I'm not the network guy at all. And I say, "Hey, I want it public," and I don't know, public two, because I want a new DMZ for my new application, or I can call it DMZ, whatever.

I don't know what subnet I could use. I don't know what is available within my company to be advertised to the real world. I just know it's a small application and 16 IPs is more than enough.

Do I want DHCP? Yeah, I'm lazy, or no. Or I use DHCP relay because I want to use my info blocks to manage the IPAM.

Okay. That's it. Next, next, next.

Here we go. And I don't have a tattoo. A network tattoo.

I don't really understand how DHCP works and how I should configure it. I just do click DHCP and that's it. And here we go.

I have this new public 2. It's live. But so this new beautiful subnet, where does that come from?

I'm the vCenter admin, so I'm not the big boss of networking, but if I want to, I could have guessed, because we have this new thing also here under vCenter. Network connectivity, and the big block is this guy. So any future IP subnet, VPC subnet, sorry, VPC subnet public I will create, it will come from this big giant block.

Or giant, whatever. The network team gave to the guy who deployed VCF. So where my mind first goes to, is this helping to basically help prevent CIDR overlaps?

Yeah, exactly. So if somebody used, for its own VPC, this CIDR, this subnet, this CIDR, and somebody else from vCenter, click, click, click. From NSX, click, click, click.

From VCVCF automation, click, click, click. Create. I'm showing VCF automation.

I wanted to do it later, but whatever. On VCF automation, I'm the tenant, Pepsi, whatever. Mm-hmm.

And I want to create a new subnet. Same thing. And I no clue.

I'm Pepsi. I don't know what the cloud admin has for public network. " And boom, it will take...

Or I can do it. Yeah. Okay.

Who cares about the name? That's a beautiful name. And it will not take something that is already taken.

Mm-hmm. Okay? Where is the refresh?

Regardless of which DHCP option you pick, it's still going to make- Yeah. Here we go ... it to overlap.

Here we go. Yeah. So you cannot make mistake.

So that's great for the network admin. He's not scared somebody will pick something that, "Oh, shoot. " No mess can happen.

And then if for whatever reason it started to... I digress a lot. This is too small because at the beginning, they told me, the network guy gave me a small subnet and the VCF is becoming more and more popular.

People started to deploy stuff. You can add... Not me because I'm the vCenter guy.

I'm in charge of more compute and storage, but not network. I consume it, and I create my own network now. But I'm not allowed to...

Yeah, the big network guy can add more blocks for future VPC subnets. Cool. Okay.

And yeah, I created a subnet, but I can create a VPC. It's as easy as click. Okay.

And I create my VPC marketing, whatever. So I can do click, click all day long or because I'm a vCenter admin, so I love PowerCLI, and I made a... Where did I put that?

I made a beautiful PowerCLI script. Oops. And of course, it's too small you cannot read, but I'm telling you it's beautiful.

Sorry. It's not recorded, correct? Yeah.

I have my vCenter. I connect to my vCenter. I create a VPC.

I call VPC marketing. I create two subnets. I don't say what IP address is.

I just take it from the block. I want two subnet, a public, a private, and I want to plug my beautiful VMs on it. Anyway.

And here we go. It's called VPC marketing, and it's an overloaded lab, so it takes a few minutes. It's live.

Yeah, it takes few seconds to connect. Oh, shoot. And let's go quick here.

Yeah. Here we go. My VPC marketing is here.

Here we go. Two subnets. Only one is displayed in...

Here we go. Two are displayed in the... And I plug my VM.

It's not rocket science. And we had the question on external IP. Actually, in this beautiful script, I also create an external IP.

And I'll finish with... Oh, no, I have five minutes? Oh, plenty of time.

You have also this beautiful thing I love. Again, I don't know much networking. I'm a vCenter guy.

This doesn't speak to me, but I love pictures. I love diagrams. And here for the VPC marketing, I can see that my VPC marketing has this beautiful logical router, VPC router, this beautiful web subnet, this beautiful private subnet.

I have this VM connected to it. It's maybe not powered on. Oh, it's running.

I don't know if it's ready. Oh, yeah, it's already ready. Yeah, no.

It's not already up and running. But the date will be up and running the VM because I just powered it on. It will have an IP address via DHCP private, so nobody can access to it.

But if they want to access to it, I created this external IP for it. Okay. If I refresh...

Oh, here we go. Here we go. And yeah, that's it.

Then you can even see should have the same IP address. Here we go. I access my marketing I just powered on in front of you.

Where is it? Here. Here.

The IP address 67. The IP address 67. The web tier can talk to the DB tier, which is private, but of course, me, myself, from my external client...

Yeah. Let's go. Sorry.

Let's go to a new one. Ping. Of course, from the outside world, I cannot talk to it because it's private.

But if I go to... Sorry. It's this guy.

You follow me or I go too fast? Good. I can ask another question, though.

Yeah. So let's say I'm the network person. Can I create a CIDR overlap?

NopeEven if you want to, you cannot. Because I'm a network guy, I love to do ping. It's not super sexy, but I had to.

Anyway, so now you can see I can ping my database behind through its external IP. Mm-hmm. Okay.

Can I do overlapping? If I create a new subnet and I make it public, it will never overlap with another public subnet. However, let's do that.

You're saying the external IP- Right ... address range that it gets assigned- Yeah ... will never overlap.

No, I cannot. But the internal address space it's using, that can overlap. So when I created a VPC here- Mm-hmm ...

you can see here, if I want to, there is no red star, so it's optional. If I want to, I can manually enter a private, it's not a subnet, it's a block, a private block. Okay.

And that private block will be used for future VPC subnets private. Mm-hmm. Mm-hmm.

And that block, for this VPC 3, can overlap. Oh, let's overlap. Let's see this VPC Finance, what I used.

I forgot. VPC Finance. So you can see it's live.

Here we go. This guy- Mm-hmm ... it's for any future private subnet on that specific VPC, and I'll do VPC 3.

And the network admin is not involved for that subnet, because who cares? Nobody from the outside. This subnet will never go to the real world.

Mm-hmm. So I can do that, and now I have overlapping. If I create a VPC subnet private, but who cares, because it's private to my bubble.

Mm-hmm. Does that make sense? Yeah.

Yeah. Are you able to set up any kind of alerts when that happen? No, and you don't...

Why an alert? Alert means bad. There is no IP overlapping, it's just it happens to be that two network bubbles have private subnets that have the same IP, and so what?

Because they'll never talk to the outside of the bubble with that IP. Unless you're connecting them. Yeah.

No, no, no. If I connect them, what, to the bubble? If you want to do transit between the two VPCs.

Yeah. That's NATed. Okay.

If we go back to this beautiful thing, here we go. Oops. Here.

When the VM here wants to initiate traffic to the outside world, it will be NATed. Mm-hmm. And so when I exit that bubble to go here or to go to the physical world or to go here, what IP address do you see when you exit the bubble?

Up the logical router VPC. You don't see this IP. You see the NATed IP.

Correct. Which is public. Yeah.

And so there is no conflict, never. It's not possible. Hey.

Can I jump in with a quick question? Sure. If you guys can hear me.

Yeah. Yeah. So there are other cloud providers where you pay quite a lot.

It's caught me on my cloud bill for that NATing. Yeah. I love this.

I just got to say, it brings a point. VCF is not free. I'm not on the sales side.

I don't think it's free. But once you pay for VCF- Understatement ... then you can use that feature.

It's included. The NAT thing or the number of public subnets. You allow the vCenter guy, click, click, click, or the VCFA guy, click, click, click.

And then you, you're the VCF big admin, you own it, you gave us money to use it. You can charge your customer, if your customers are Pepsi and Coke, or if your customers are finance, marketing within your company, you can charge them by utilization. And I'll finish with this because I'm late now.

In VCFA, not in vCenter, but in VCFA, you can associate... I won't show it because, yeah, I'm late. Okay, I cannot show it.

You'll trust me? In VCFA, you can decide, you can give quota. You're the big VCFA provider, the big VCFA admin, and you create an org for Pepsi, an org for Coke or finance, and you give quota.

You can give quota in term of CPU, memory. Don't care much, I'm the network guy. But also quota on network.

You say Pepsi cannot use more than so many public IP addresses. So it won't take all the IP addresses from Coke and from the other guy. Make sense?

So you have the ability to do quota. And if you want to charge Pepsi and Coke on the number of IP addresses they use, feel free.