Skip to content
TrackPodcasts
technologyOct 6, 202640:58

PP129: Inline Segmentation – HPE Networking’s Easy Button for Zero Trust (Sponsored)

Get every episode summarized

Each time The Fat Pipe - Most Popular Packet Pushers Pods publishes, we email you a written briefing from the transcript — the topics, who appeared, and any specific claims, with the ad reads skipped.

Email me new episodes

Free for 3 shows. No card needed.

About this episode

“Today we've got a sponsored show with HPE Networking to learn about zero trust in line segmentation.”From the transcript
Sponsor HPE Networking comes to Packet Protector to talk about zero trust inline segmentation. This is a feature available in Juniper switches that can segment LAN traffic using group policy tags without the complexity associated with VXLAN or other segmentation mechanisms. On today’s show we dig into how inline segmentation works, common use cases, how... Read more »

Hosts & guests

Transcript ready

401 searchable segments. Every word is indexed and playable.

PP129: Inline Segmentation – HPE Networking’s Easy Button for Zero Trust (Sponsored)

The Fat Pipe - Most Popular Packet Pushers Pods

0:00
40:58

Full transcript

The Fat Pipe - Most Popular Packet Pushers Pods — PP129: Inline Segmentation – HPE Networking’s Easy Button for Zero Trust (Sponsored). Machine-transcribed; use the interactive transcript above to jump the player to any line.

Hey everybody, welcome to Packet Protector, the podcast at the intersection of networking and security. I'm Jennifer J. Javush, here with Drew, Conry Murray. Today we've got a sponsored show with HPE Networking to learn about zero trust in line segmentation. This is a feature in all of the Juniper switches that can segment land traffic using group policy tags without the complexity of associated VXLAN and other segmentation mechanics. So on today's show, we're going to dig into how in line segmentation works, some common use cases, how it compares to other segmentation options that are out there, and how it can support our broader zero trust initiatives. Our guests today from HPE Networking are Abby Shamsudar and Wes Purvis, both senior directors of product management. Hi guys. Hey, two today. Hello, Drew, Drew. Yeah, so welcome to the podcast. And, you know, we are going to be talking about segmentation. So let's just start with the typical ways that you might segment land traffic and then

we'll contrast that with what we're going to talk about in line segmentation. Traditionally, a segmentation has been a function of you having the ability to write access lists and in the wireless world, we've done WXLAN policies, all of them eventually going down to a part of assigning some form of a role to a device and then having, you know, IP, port protocol on the right hand side and our combination of all of those and being able to segment traffic, which is primarily, have always been traditionally in the VLAN. Intra VLAN has always been an open function talking very strictly, very traditional functions you write ACLs. Unless you start doing Mac to Mac ACLs then if it's not scalable, anything in Trabil and has always been a function of, you know, some form of tagging to prevent that conversation.

But, you know, it has served us well until IP spaces, spaces are started exploding, you can't keep up with the amount of IP supplements you create, hence IP, the number of access lists grow and then search is run out of TCAM and then problems start to grow. So that's essentially a quick form of it has served us well, but I think we need to now just step into the new future. So are we talking about, when I think of, you know, micrasegmentation particularly at the network level, I tend to think EVP and VXLAN is that what you're talking about here? EVP and VXLAN is one way to do it. I think that's a very fair question because EVP and VXLAN always comes in the picture. Whenever you think of tags or group based tags of GVPS they're called and EVP and VXLAN comes in the picture because these group based tags are embedded into the VXLAN header.

The policy locally on a given device by itself does not need EVP and VXLAN at any given point in time. The VXLAN comes in the picture every time you want to do percolation of these tags because just one device knowing about the tags is not good enough. We need the rest of the devices on the network to also be aware of the tags and that's where VXLAN comes in the picture where the tag itself is embedded as part of the VXLAN header. That means any packet that's coming in comes into the switch and gets its tag in some form or fashion. Let's say a dynamic static whatever ways they are and then once they're moving towards the destination that tag is also embedded as part of the VXLAN header. Now the traffic passes all the way to the destination. Now only at the destination you finally have the complete picture. You have the source tag as part of the VXLAN header. You have the destination tag because that is locally learned at the destination.

Then you decide to either drop the packet or all the packet. This is generally called egress enforcement because you're not implementing this function at the end of the case but now you're and that's where the X-ZN comes into picture. That's a part where you know that's been done in the last three, four years that's every time somebody said a micro-secondation we said okay go that out of ADP and VXLAN because VXLAN was standard-based and percolation can only happen over VXLAN. That also meant if you have a small network, five switches, 10 switches store, 15 APs or five switches in a store or even medium branches, 20 to 30 switches, some 50 APs, all of them in spite of being a simple network where even in the store that I was just talking about a retail function, the switches and the APs probably did only add two functions.

Just changing them to the world of European VXLAN would mean everybody needs to re-architect the network, you know, default gateways, it's just start coming down to these switches as against how they went on a van router that used to be the challenge and we want us to go away from that. That's kind of the intent of ZETIS and that's the solution. What is it a question line segmentation? So I'll be, I mean Drew mentioned, you know, in his thought process and you said basically anytime we're doing micro-secondation and segmenting within the same VLAN, we start talking about VHLAN on EVPN, is that the underpinning of what you're talking about here with the zero-attressed and line segmentation? The only part that we have from that function is group-based tags. The tags will still and the policies of still executed based on tags as an you allow and deny based on source and destination tags, but the solution itself now takes away the requirement for you to go

and have to implement the VHLAN. Okay, so you get the tagging benefit without the underlying whole architecture having to be built for it. That is correct. That's the exact point. Okay, all right, now I'm interested. You know, honestly, all things that we, whether we focus on it missed, this one is mostly evolutionary. It's not revolutionary. It's not, tagging is not a new concept, you know, being able to do source and destination tags probably has existed almost close to a decade. But the barrier for adoption has always been what I just mentioned. Hey, having to re-architect the network or change hardware to support all of these functions, now we go there out of a simpler, easier way to solve the most important problem, which is percolation. And we don't want you to go via architecture network. We don't want you to do, you know,

rip and replace everything. We just want you to have the networks that you have. Keep it at where they are. Keep it at three where they are and still get to the adoption of ZTIs or the trust on your LAN. So how are the tags getting distributed then? Well, that's the most important problem that we are solving for without having to do the X-LAN. We have to help percolate tags. And what we do in essence is, well, this function of being able to percolate anything within a given network over multi-cast is a function that we have done many a time within the product on the wireless front, on the wired front. We're using a small modification of the same multi-cast protocol for us to percolate. So there are devices that could listen to this function. There are interfaces on which this is sent out. And it's a simple implementation where the user doesn't have to click a button to say,

enable ZTIs. It's primarily them going and saying, here's my source, here's my destination, allow them or block them. We help percolate all of these functions internally without you having to go throughout the VPN, the X-LAN on your networks. Okay, so you're essentially distributing tags using multi-cast? That is correct. Okay. You have the ability, you have multi-cast listeners all listening to the same group, which would be all in Jennifer or HP network devices. And they will all listen to the same. There's also interesting implementations since the listeners usually get that like to get into the details of such. Hey, what happens with multi-cast? What if my multi-cast gets lost? Is there, what do we do? And as I said, this is not the first time we're implementing this protocol, this protocol helps us scale, sharing keys at scale. That means if you don't have a particular

tag that you're looking for, there's always a look-up. There's an update message. So there's a lot of these fun functions built in to ensure you're never in a place where you don't have access to a pack. So there's very well talked through mechanisms to make sure this works. But it does sound like this. If I want to do this zero trust in line segmentation, I need to be using HP A Juniper switches, is that correct? For all the listeners, as in a forwarder going to be implementing this tagging functionality and allowing or denying functionality, they need to be HP network devices. If you have a LAN that is comprised of HP networking devices and LAN, which actually housed most retail, small branch networks, almost a lot of distributed networks today. This will be to end the price networks today. About 50% of them are pure Play L2. The LAN is where your L3 resides. The LAN is where

you're the rest of the functions towards getting out to the internet resides. You just are playing up your L2 function. Even in a scenario like that, you can do both L2, L3, as well as L4 segmentation functions right on the L2 devices that you have. So if the LAN function were to be a third-party vendor and not an HP networking vendor, you still are able to go execute this function in incompleteness without having to depend upon an L3 device to execute this function. That's nice because a lot of the distributed, especially retail, where you've got lots of little things spread around everywhere. They love the something to talk out to wherever it's going to talk on a wide area network or internet or whatever. Then the cheapest layer two stuff they can get away with inside of that out of any given portfolio. So what you're saying is,

you get all the juicy layer two layer three layer four control without having to rely on some other piece of whatever's going to do the routing that is on prem or might not be there and appropriate. That is very correct. That's a very important distinction, especially for the segment that you mentioned. The investments that would go in in terms of where do you want to do segmentation? If the answer is, I want to do this within the LAN talking about the things, anything that can I nowadays, small digression. In 2021, when a lot of enterprises were going wireless first, we really thought they'll be dwindling off the number of such ports that people would need on an enterprise. Turns out, that number has actually increased. There are various different kinds of things that you mentioned, JJ, that are connecting to the network, door locks and

lock maker or the key makers. You name it. All of these are internet connected. All of them don't need to talk to each other necessarily. How do you not make firewall your only place where you have to make the decision on whether or whether something should talk to each other or not? That takes away that fear of what's happening between the LAN. Now, we're doing segmentation super close to where the devices are connecting. That's a very interesting proposition for this particular solution. You're still keeping your architecture the same, not complicating the network and protecting the things that we don't need to talk to each other. I'm guessing the combination of picking parts of something that's standard and piggyback on it without doing the underneath. It's appropriate for you mentioned the retail distributed earlier on. I jumped on that. I'm guessing there's a size where based on how the tags are being distributed,

there's a size where this makes sense and then there's a size where you're not, this isn't going to be the solution you would. Where does that line fall for you guys? That's a very important question. Thank you. The solution for us in all, the most important part of the solution, I think that I need to emphasize on. I focused on the European VX LAN function and I said you're dropping packets at the egress. In the Zeta's world, everybody knows about everybody. As in every single client that comes up onto the network, it is sharing the knowledge about the particular client, Mac, IP and the tag binding to every other device on the network. Everybody knowing everybody would have a limitation. A limitation in terms of the number of clients that you should be percolating across.

That number today is up to 10k clients. Thank you. 10,000 different clients. That's pretty big though. That's actually a much larger number than a good statistics. I just want to be clear. If I've got the world's biggest retail site that has 10,000 clients, I can have zero trust in line segmentation there and then another store with another 10,000 clients. I can also have zero trust in line. You're not talking about total number of clients I have. It's per local area network. Good distinction. Yes. Anything within a single network, anything encompasses that branch is 10,000. It's actually a pretty sizeable number for even medium-scale enterprise that are out there. If I'm a hospital, for example, with a lot of IoT driven medical devices, this may be an option for me. This definitely would be. Especially

a traditional network where you had only controls, even L3 controls only at the distribution, or sometimes in a collapse core layer. What happens between the switches within the network has always been a question. This brings a very strong segmentation function very close to the network. This one brings also the advantage of ingress replication or ingress enforcement, which is, I know about everybody. When the packet comes in, I know who the sources, I know the destination is. I drop right at the point when the device enters the network. For all things that are less than 10K, Zeta is absolutely a very recommended solution for us to go to. Anything beyond that, we already have traditionally we explain methodologies for us to go and adopt for this. This is one place I strongly believe we should not say that is just one size fits all,

rather we pick our horses for courses and say one is ease of implementation, a reduction of barrier for adoption. The other one actually looks for extremely large scale, large universities in our functions of that nature. EDPN Lakes Land brings you added advantage of L2 stretches in all of that fun stuff and we go that way. There's different horses for different courses here. Something else I wanted to clarify, you talked about being able to implement policy on ingress or egress. Can I do that with ZTIS or search trust and line segmentation? I can block a connection at the ingress switch as opposed to waiting for it to get to the egress switch. That is correct. What's unique about this function is everybody within a network knows about every single device. As in switch 10 has a client coming in and it gets a tag of some sort, dynamic or static.

That is immediately notified to every other device on the network. That means any traffic that is designed to switch 10's client, that can be dropped act switch one itself. You don't have to pass the traffic all the way to switch 10 and then drop it at that instance. That's unique about the way ZTIS would operationalize. Given that you said all the devices know about everything happening on the network. Is there a potential impact on switch performance? Having to keep all that state is the right word but keep all of that information about devices on the network. If we go into the nerdy details of this, essentially all of these tags are stored on the MAC table. You are not worried about additional processing or even the two things that you could potentially think of what we have added and what could add to the switch's performance. One table size is and that's why the number 10K.

We know that number can be much higher and we have set it to NK to ensure there's no impact. Number two is multi-cast. You're talking so much multi-cast. It's not really so much multi-cast to be honest. It's every client when it comes on or you start like clients coming on every two seconds especially on the firewall. The other one is if you don't know about a destination, you're just doing a unique lookup message. Both of these functions very well verified function tested. Neither of them have any adverse impacts on the switch. In fact, in hints, we've gone the route of saying distributed enterprises, you want to do policy go the route of ztis. When I first heard in Psalm, I had that little squeeze moment. You're right because it's not everything that the endpoint is sending is going everywhere. Multi-cast. It's just that announcement state change. Here I am, here I'm not. That's so little overhead even if you have things popping

on and off. Let's talk about, because you did mention layer two, three, and four. I'm assuming there's that maybe somewhere there's a central place where you put these policies and you can assign groups and it sounds like other parameters. Not just this group can or can't get to this one, but maybe you can get down into port protocol for the policy. Yeah. So you have a single layer on which you can define. So each of these clients that come onto the network have to receive the tags in some form of fashion. One, they can receive them dynamically, which is a radius that we're sending a response. If it is on the ms dashboard, then preferably go the ms tax as the short-end start, because you have inline visibility of exactly what's happening to the client. But if not, it's fine since the group-based tags are standard-based activity value pairs. Every single radius over can

send them back. The other part is you know, you statically assign them. IP, you know, Mac and so on and so forth. The policies themselves. Yeah. I want to pause just to try to wrap my head around this. So when you talk about kind of like get the radius server sending something back, is that as a result of like an 802.1x authentication or it's just purely on the backend? You know, it is part of a regular radius function. It could be 802.1x, MAM, either of these two functions that can send a response as part of the access accept. Usually you get, you know, tunnel private group ID, which is the VLAN of the device, but you could also send an additional function, which is the group-based tag. So it is stacked on top of, you know, using yes, you're allowed to get into the network with access accept. You belong to VLAN 10 because of, you know, tunnel private group ID. Now you're sending another network with value pair, which just says you are of the type employee, which is just group

tag 100 or whatever that is. Okay. Yeah. It is a part of the radius standard space radius response or the other one that can be locally done that you were saying is static tagging, you know, IPvs, then Mac based and functions that for things that cannot go to a radius server, or it could be the destination, for example, hey, my employee should not be talking to Amazon servers on 541010. Just making that 541010 doesn't decide in your universe. It is a destination. It could just be statically tagged to say this is a group, it's statically tagged function. So just to clarify, I can build tag policies around things like IP address, Mac address, or role like this is an employee, this is a security camera, this is, I don't know, an MRI machine. Yes, absolutely. If they are not able to talk to radius server for whatever reason,

you can go that out, you just mention going through the subnets and so on. Then subsequently to JJ's question, there's a part of the policy. How do you write this policy of who can talk to whom and where does this reside? All of these policies reside on the Mist dashboard. The Mist dashboard has very, we don't extremely large networks, like the ones that you were saying, 510 devices in a given site, but there could be 5000 sites of such nature. Or there could be 5000 devices just in one extra large site, all governed by templates. So these templates are what govern the policies that go down to each of these devices. The templates, for a policy standpoint, it's very simple. Your left hand side is the source tag, the right hand side is a bunch of destination tags whether or not they can be a louder or not. The red or green based on whether they're louder or not.

No. I feel like even I could follow that one. Yes. Green go red no go. Green go red no go. Right? No go. So we went one step beyond. We said, okay, I'll organize nice. But now the ask primarily is, hey, my cameras should not talk to each other cameras, which is great. You know, tag a don't talk to tag a at all. But tag B, if it were to be an NVR, I want to talk to the NVR, but only on this particular port and protocol. Right? I want to limit that function so that I'm very prescriptive. And most policies nowadays are written as exclusive permits and everything else didn't have ID for like, you know, I really want to control what my device is more talk to. So you would say, you know, exclusively permit the cameras talking to this particular NVR. Over a port and a protocol and then I have everything else. We've been able to achieve that as well with the same ZTIS framework. So a lot of thought

we're in canful designing this intentionally, even at L2 being able to do L3 and L4 policies. I think that's where let's say you don't own the default gateway. It's just a packet passing through you. Still being able to snoop those functions of, you know, destination IP, destination reports. I think that's what makes the solution very unique. Still implementable in a simple fashion, but not having to, you know, rearchitect your internet work to get there. This is going kind of outside of the solution, I'm sure, but are there are there other things built into any part of the platform that help people figure out what the things are if they don't already know the things that are attached to the network? Yeah, there are a couple of things. There's a very rich telemetry that is being sent out. Point one is any time a device connects to the network. So that every single device automatically snoops all of the DHCP parameters, which is

basically a gold by-off information to tell you about these things that connect to the network. And every time a port goes up, we capture a dynamic pickup off the first 100 packets that happen as part of the transaction. Again, the MBNS packets, these devices send, you know, there's a lot of information for you to find out what is the nature of these devices. So you actually have like a pretty high level of confidence about what it is, not just like, oh, this is the Mac prefix and we're going to guess it's a whatever. Yeah, that's cool. And all of this information, guess what? It's shared with our NAC service. So if you were to ever make NAC as your determination point, to say, every time a port comes up, you go to NAC and NAC not only just based on search and or a Mac by pass, it can also additionally do this kind of profiling to say, I know your DHCP

options are these. I know these were the first 100 packets you sent. And I with 90% confidence can tell that this is a camera or this is a MRI device, or the nature of the devices. And this can be part of your policies at NAC itself to say, you're part of my, you know, Mac address database, which anybody can spoof, but also exhibit these behaviors to qualify yourself as a camera. Then you rely solely on on a headless device that has no search installed just on Mac address. At least you have another sense of confidence that all of this information is sent back to NAC and NAC now does this strong profiling and says, I know who you really are before it, it sends that access except down to these devices. Okay, sorry, I didn't mean to derail, but like there's a lot of like, oh, there's cool dynamic policy stuff, but there's also I think right now, you know, Drew and I cover a lot of stories

when to the news roundups about how, you know, every segment, every industry basically is trying to figure out all of those random things that are plugged in. And everybody's talking about IoT is so much of that is wireless and there is a lot, but there's still this just unknown mass of things on the wired network and it's not as easy on a wired network because at least on wireless we have the little toggle to like block interstation traffic, right? I mean, at least if nothing else you can do that, but on the wired network we, until there's an easy button like this, there's not really a way to do that. So you're just kind of stuck with everything talking to everything. And JJ, you made appreciate this. So one of the good things that, you know, one of the many good things that has come out of the, you know, the acquisition is we've we've topped into the clear pass, you know, client insights team to, you know, to bring a lot of that goodness, you know, you know, into the product as well. And so, you know, you have, you know, as you're

menstrual wired network, right? So a lot of these devices may be DHCP, but many of them are static. Yeah. And the static address ones are very difficult to profile no matter who you are. And so, you know, some of my methods that I've been talked about, you know, have actually, have been very successful in, in fingerprinting some of these static devices. Yeah, that's fantastic. I mean, I think this is great because, you know, little soap boxing for me, I kind of feel like if things are plugging into or through the network, the network already sees all of the traffic, you know, all of these overlay things we've been doing for, you know, over a decade to try to figure out what the stuff is when, when you have this whole smart network right there, you know, the fact that you guys are leveraging that, you know, capturing the pcap one connect, I think is phenomenal. I mean, that's so much juicy stuff you get right there that's not guessing. So I don't want to derail. I don't want to derail the online segmentation conversation, but I do think that's an important piece because you want to do the segmentation thoughtfully based on what those things are,

what they should be talking to. And this is, this is just now a super double easy button of, you know what it is and you can decide what it should talk to. And that part is so true. In the past, everything that gets plugged in, everything just shipped in hardware, we knew nothing about what's actually no traffic patterns. Obviously, you don't want to snow upon one big language traffic in the world where you're not, you're not, you're hardware switching, but this, this data has been alongside the algorithms from client insights has been game changing and understanding the nature of this nature of these things that get connected network. So do you have customers using this sort of in production in the wild? Yeah, we have, I think popular places where we see this implemented is hospitable clinics where there are lots of things that get plugged into the network. And a recent function of where we see see this, we know us for more is the retail sector. There's a lot more wide things that are

getting plugged into the network. You know, and the focal point that send it to my firewall and then we'll see, you know, we'll see about whether or not we allow is no longer acceptable, even for security groups. So security groups are working with network operations to say, hey, can we, well, how can we do segmentation at the access, at the end clip point before, you know, I get to know about it at the firewall has been a very strong conversation that we have been having and that's been very fruitful, which was a difficult thing in the past between security and network operations. Now it would, you know, all of the emerging functionalities, this has become a matter of month. Everybody's been worried about like lateral movement and pivoting and malware spread so much that I never understood why the whole send it to the firewall and figured out there was ever even a

thing for this because it's like, it's too late. It's too late. It doesn't matter at that point. Just quarantine the whole, you know, quarantine the whole network segment at that point. Anyway, sorry, I know Drew had another question. No, I just, yeah, that's a good point, but obviously in our prep call, you said, you know, segmentation is not the same thing as security, but it sounds like there is some security benefit here. So can you kind of like expand on what you meant by that phrase? Yeah, I mean, I'm not going to confuse myself or others to say, hey, segmentation is equal to security, but segmentation, however, is a good stepping stone towards security. Obviously security is, for me, is statefulness comes into picture. You don't have to protect both ways. In this case, you do have to A to B, but also you have to say, what do you do with B to A as well? Security functions, firewalling functions to both functions because they know the

protocol, they know the transaction ID, they take care of whether or not to allow something. But it's too late, like JJ said, if you're waiting for everything to go to the firewall, what can we do at the access layer is what, especially lateral movement, malware, the moment one of the devices is infected, everything that is on the same subnet, consider it done, right? You can protect anything on the network at that point. Educational institutions are places where some places you have open ports to go plug stuff into. If you quarantine patient zero, at port zero, then there is no extension of that, that is the only port that they got access to. So I think that's critical. It helps. It's a great stepping stone to prevent security incidents from happening, but this is not a firewall function, right? This doesn't do stateful functions, this doesn't do by directional functions. But I think this is really

good augmentation to what is happening at the firewall function. It no longer is a nice to have, in my opinion, and that's what the industry is asking for as well. I think this is going to be a very active function where the security network groups will work together to implement these functions locally at the access layer. One of the things I was watching, so you had done a like a mobility field day video we've got linked in the show notes. And I think you said something that was just really elegant at the beginning of that. You said something defective. You know, everybody, I think on the network on on-prem networking, everybody's always talking about what is zero trust and was micrasegmentation. And you just basically said, look, micrasegmentation is we need to do something with within a VLAN, more granularly than between VLANs. And we just haven't had a lot of solutions in that space, but we've had a lot of need with like exposure and

asset management, you know, solutions that go look at everything saying, look, as much as 60% of an enterprise has, it is unknown endpoints. Like there's stuff connected to the network that they don't even know about. A lot of those things are routing traffic between segments that that are not intentional, along with just entry pivot exit points, things like that. So I thought that was just a really nice way to think about it and that you guys have done this very gracefully and frankly, at a scale, when you said, you know, okay, it has to be kind of like contained and obviously with the way you guys are sending tags, that makes sense. But you know, something on the scale of 10,000 endpoints in an area or zone, however you're, you know, setting that up is pretty significant. Yeah, the scale numbers, I think, you know, one, the scale numbers are already pretty sizable for 10k endpoint. Even if you have a larger network than that, you have a bigger network and it's okay to implement EVP and VXLAN

in the size of the network where EVP and VXLAN will only decide in the code and distribution. It acts as if it just can still remain plain old access and still achieve everything that you're looking for. So we're not, again, we're trying to ensure at the heart of it all, it should be simple to implement and it should be very quick to troubleshoot as in it shouldn't, you know, need 16 brains over 17 hour call to understand where my packet was lost. That is in essence for all solutions that we build it missed. And this is one such example. So this does sound very interesting. I'm sure folks are going to want to dig into it, but Wes or Abbey any last thoughts before we wrap. You know, probably a good way to end this is providing you an example of an incident that actually triggered, you know, for us to think about the solution and why it is important.

You know, this was one of a close customer that we work with from our university segment. And they spoke about, you know, how it was for them when intruder came in to an open port and took over a segment of important functions under their data center clients that they had. And they essentially turned out, you know, a ransomware demand. Obviously, all they did was they came into the network through one open port and just laterally moved wherever they could. And this lateral movement was the trigger point for us to think about Ztis and Ztis differently and how to make this easily accessible. And I think protecting devices, you know, especially lateral movements before it ever goes to the firewall is paramount and

enhance the solution. And hopefully, you know, it's easily implementable. It's not complicated for you to adopt and that's the goal and hopefully more customers go this far. Yeah, you're not talking about needing to do deep packet inspection or matching up signatures to traffic or anything like that. You're talking about very basic A can't talk to B, which as you said, segmentation and security, but it does a significant stepping stone. It is. Well, thank you, Wes and Abby, for joining us and thanks to HPE for being a sponsor because sponsors make everything we do here at Pack of Pusher's, including the Pack of Protectors show possible. There's going to be links in the show notes to go if you want more information, including Abby's presentation at a network field day. Some more details about Zero Trust Inline segmentation. Are you guys online? Are you blogging? Where can folks find you? Or are you on LinkedIn if they want to reach out and get in touch? Yeah, I'm on X as well as LinkedIn. I'll send you the links

and you can be talking on there. Yeah. Awesome. Wes. Yeah, and the real-world service on X and LinkedIn as well. Awesome. All right. We'll have those links in the show notes. Again, thank you, Abby and Wes, for the conversation. And again, thanks to HPE Networking for being a sponsor. By the way, Pack of Protectors is one of the many shows that we have on Pack of Pusher's, bringing you lots of technical content, including podcasts, videos, blogs, and more. Always for free, never behind a login or a paywall. Find it all at packupusheres.net. And as always, stay safe out there.

More episodes

More from The Fat Pipe - Most Popular Packet Pushers Pods

View all episodes →