Glitch: Welcome to NPCE Grade Security and Architecture, Episode 9, Safety Dance Secure by Design Network Architecture. I'm Glitch.

Cypher: And I'm Cypher.

Glitch: Wow. I don't want to say it, but I'm gonna say it. You sound a little like Marge Simpson's chain smoking sister.

Cypher: Yeah, I do. So last week I took a trip across the pond to Hamburg, Germany, Southampton, UK, Ghent, Belgium, and then to London for a plane. And I will say the trip was absolutely fantastic. Ghent, Belgium, if you have not been there, it is absolutely amazing. But at Heathrow in London, I was sitting near a chick who kind of looked like she was auditioning for a role in 28 days later. And now I sound like a a soundbite from that flick. So, but anyway, I I don't I probably don't feel as bad as I sound. I really don't know because I don't feel that great anyway. But luckily, Glitch, the title of of this episode, Secure by Design Network Architecture, probably means that I'm gonna have an opportunity to sit back and just be like the Troy Aikman tear Joe Buck for an episode. So ⁓ I'll just ask the easy question right now since I'm not feeling amazing. Can't we just take away all the computers and connectivity and call it a day?

Glitch: Okay, one, nobody likes a bragger. Two, this would be a very quick and boring episode. Three, while I share that sentiment, and that would be ideal, clearly it is not practical. If we go back way back, two steps back, to episode seven, for a moment, where we discussed zero trust taking the first steps, some of the points we discussed revolved around not only identity but also networking. So I want to dive into that deeper in today's topic, unravel potentially some misconceptions in the process.

Cypher: Okay, okay. So we're gonna double click on network security today.

Glitch: Yes, on network security and no lazy day. And no on the lazy day, yeah. ⁓ but I know you feel so, so bad. I I'll take the lead for you this time. How about that? You're welcome. ⁓ you get the you get the one for the year. one of the biggest misconceptions in enterprise networking is believing that zero trust is a security product. It isn't.

Cypher: Thank you. Magnanimous of you.

Glitch: It's an architectural philosophy that fundamentally changes how you design networks.

Cypher: Yeah. And I I would argue that secure by design, ⁓ you know, we could also look at coding principles and whatnot, but okay, because we're talking about network security. So I think I can I can buy what you're selling. So let's let's go ahead and set the theme for the episode. So, ⁓ how about this? Stop building castles and start building neighborhoods with locks on every single door.

Glitch: I feel that is a great, great start. So instead of asking, How do I keep attackers out? Okay, so if you were trying to do something, it didn't come across.

Cypher: I okay, you're gonna have to cut that I I muted myself so that the cough didn't come through.

Glitch: Okay. I will say the line again. That's a great start. Instead of asking how do I keep attackers out?

Cypher: ⁓ buzzer, buzzer. Do you don't you have a buzzer button?

Glitch: ⁓ probably. I just haven't delved into it, so

Cypher: Okay. I I would like to have the buzzer button on my side because I think that would be so much fun. I would I would bust you like every seventeen seconds just to annoy you. But anyway, the the right question that we need to start asking though, instead of how do I keep attackers out is what happens when they're already inside? I mean the concept of zero trust is that we assume we're already the B word breached.

Glitch: Okay. B word, yeah. And foreshadowing, we will probably use the B-word again some yeah. ⁓ I know. So 100%. That single mindset shift changes everything. Traditional network design has historically revolved around perimeter firewalls, VPNs, large trusted internal networks, flat routing, and broad access permissions. Once users authenticated and entered the network, they often have unrestricted lateral movement. Does that sound familiar to you?

Cypher: Yeah, legit. Yeah, it does. ⁓ and we know in today's world that that is yesterday's security. So, ⁓ while I I hate feeding into that hype phrase, zero trust assumes that an organization's internal networks are no safer than the internet. You know, the public facing behemoth that nightmare stories can be made from. So with that lens of suspicion on now, every quest is evaluated independently. Every connection earns trust, nothing is inherently trusted because of the location or or other factors.

Glitch: Okay, so let's build on that castle model you implied in the theme of the episode. Traditional security resembles like a medieval fortress. Huge walls, deep moat, drawbridge, gate guards. So Cypher, what's the problem here?

Cypher: Gosh, I feel like Helm's Deep from ⁓ Lord of the Rings. So if an attacker crosses that bridge or that one thing and breaches that gate, they literally pretty much own the kingdom because everything inside there considers them as trusted. So not only do they cross the bridge, but then once they're across that bridge and in that gate, they're literally walking around unchallenged. You know, it is the the perfect haven for attackers who want to plunder and pillage our village.

Glitch: Ha ha ha. back to the good old days. Why can't we go back to the good old days? ⁓ they frown upon that. The plundering and the pillaging. Alright, so so let's use some analogies for Zero Trust based off of a modern city, so I can avo avoid terrible rhyming words. Evr Yahoo Every building has locks, security cameras, badge readers, hopefully, different access levels, again hopefully, and visitor logs, to name a few things. Just because you're allowed into City Hall doesn't mean you can walk into ⁓ the police evidence room that houses that houses Bob's twenty eighteen iPad or D's iPhone seven, I might add. The mayor's office, the data center, and the treasury.

Cypher: I'm so pleased to hear that Bob's iPad and Dee's iPhone have made it back in here. But yeah, I don't you're not wrong, I don't have a a witty little rhyme to go in there, so dang, but so but what you're saying there is then identity matters more than location.

Glitch: Mm-hmm. Without a doubt. If we take everything we have discussed so far from the the previous episodes, the primer, if you will, now the network becomes the transport, identity becomes security, applications become the enforcement point. The network should ask and answer can packets get there?

Cypher: And then zero trust should ask and answer should the user access this application or this data or this segment of the network?

Glitch: Right, so we have to change our mindset when applying a secure by design philosophy to network architecture. It's not just about the infrastructure, it's also about the purpose beyond just providing connectivity to get from point A to B. Speaking of B, I'm going to do the B word for a moment.

Cypher: No, I mean I I know you don't mean the B word that we just used. So you must mean like brainstorm, break dance. Ooh, braveheart.

Glitch: ⁓ freedom Thank you, William Wallace. But no we have to assume breach when designing networks. We have to assume that, for example, successful social engineering already happened. Credentials have already been harvested, malware already exists somewhere, insider threat exists, Bob's iPad from twenty eighteen has been compromised.

Cypher: ⁓ huh. No, not Bob's iPad. At least it wasn't Dee's iPhone. but what you're saying is the objective changes from essentially from prevention to containment. And we need to make that containment so it's more targeted.

Glitch: Indeed, ma'am, because of this change in mindset, now we are approaching the network design with the idea that one infected machine should never cause an entire department to be compromised, an entire entire building compromised, or an entire organization compromised.

Cypher: Yeah. So holistically one workstation, one identity, one application, ⁓ equals the containment ability that we're kind of aiming for.

Glitch: Right, right. So let's e break this down even further. Traditionally most organizations, or at least the ones who maybe misunderstand today's security needs, think VLANs equal security. It doesn't. VLANs reduce broadcast domains by themselves, they are not security boundaries. The objective combines routing, firewalls, identity, policy, and application awareness.

Cypher: You know, it it sounds like what you just described is what we security types Lego le like segmentation. I mean, I I think that would actually be like macro segmentation if we want to get all technical and junk.

Glitch: Yes, and we will get all technical and junk, so you're exactly right. Now let's break it down further into micro segmentation. Instead of protecting an entire subnet, now we need to focus on protecting individual workloads. For example, let's say Daryl has a server running on his iPhone seven.

Cypher: Wait, wait, wait, wait, wait, wait. Buzz buzzer? I need the buzzer. So

Glitch: Okay, humor me for a moment. Humor me for a moment. I didn't want to leave him out and give Bob all the attention.

Cypher: Okay, but he's running a server on his iPhone.

Glitch: Okay, fine. Daryl is running a machine with Mac OS Server, which, by the way, was discontinued in twenty twenty two. But I digress. His server needs to talk to, let's say, a SQL database, DNS, Active Directory, and maybe a logging server. That's it. Even a server or machine sitting physically next to it should not be able to communicate it with it unless it's explicitly allowed to. So now that we've changed our mindset and asked ourselves a different set of questions, we start to see a theme emerge, an identity first network design. Identity replaces IP addresses as the trust anchor.

Cypher: And and now kind of when you do that a new set of questions, aside from obviously how my best friend suddenly got so tech savvy that he's running a Mac server, ⁓ we start to get a new set of questions that emerge. So like is is this managed, is this compliant, is it corporate owned, was MFA authenticated, what's the risk level? ⁓ was anything recently compromised?

Glitch: Right. Policy follows identity, not an IP address. Because of this, not all devices will get the equivalent amount of trust.

Cypher: Yeah, nor nor should they. I mean, honestly. But regardless, trust decays, right? It is not permanent, which is why we need to have kind of the a continuous verification. I mean, the bad guys have mastered taking over after trust has been established. So if we let that trust persist, we're back to pillage the village. ⁓ so don't treat authentication as a one and done. You know, each request should be monitored for things like You know, location, device health, risk score, impossible travel, token validity, behavioral analytics, you know, the stuff and the things.

Glitch: I I I feel like we're baking a cake with layers, or I'm hungry. Probably both. So now let's add least privileged as a layer. Users should receive only enough access to do that function they need to do for their role and only for as long as needed. Instead of domain admins or network admins equ equaling forever, now we pivot to just in time access. Those elevated permissions last for 15 minutes, task is completed, and that access disappears.

Cypher: Mm? Mm. Yeah. ⁓ and we also use least privilege for our users too. You know, they shouldn't have unfettered access to things. But anyhow, what about what about that perimeter protection?

Glitch: Essentially with perimeter production, essentially you want your applications to be invisible by default. If you aren't authorized, you don't even know they exist. Compare this to traditional network where a port is open for access, an attacker gets a response banner and they begin interrogation. A software defined perimeter provides no response effectively making the application disappear, which, you know, before we'd probably need David Copperfield. Now we can do software based perimeters.

Cypher: All right.

Glitch: So even after everything we've talked about so far, we are still missing an important piece of the equation. Going beyond what we have talked about in previous episodes with asset management, both hardware and software, we need to have network visibility. You can't protect what you can't see. So as an architect, network or otherwise, we should be asking what devices exist, who owns them, what applications do they talk to, on what protocols, how often. What does normal traffic look like? But just as important, what's abnormal traffic look like? Do we have unknown devices? Without visibility, segmentation becomes absolute guesswork.

Cypher: Legit. And, you know, it's really awesome that probably one of the things that makes this podcast so absolutely, you know, hashtag amaze is that security and architecture are very deeply aligned. whether it's in the actual operational pieces of it or in the the governance and ⁓ risk type of pieces. But I will say I don't want to forget about the importance of logging. ⁓ every decision should create a signal of some type of of telemetry, you know. Who connected? When did they connect? From what device? With what identity? To what application? What policies were matched? Were they allowed that access? Were they denied that access? What was their risk score? But there's a lot of things, right? But logs become critical for a historical record when you're investigating an incident.

Glitch: Let me reminisce just for a moment because of something that you just said about how security is important with architecture. Just recently, ⁓ as of today, I was having a conversation with ⁓ my leader and he said that exact same thing as we were mind melding. And it's like security and architecture are attached at the hip. You you've gotta have both to be the champion of your your architecture process. So I just wanted to reminisce on that on on this is not just something that comes out of thin air. This is this is a not even a belief. This this is this is a thing. The th it's set in stone. Another important as

Cypher: Yes. So what you're saying is we're not we're not just here making it up as we're we're going. Is that what you're saying?

Glitch: ⁓ sure. Is yeah. Is yes appropriate? Yes. Okay. Another important aspect that gets ignored is DNS. ⁓ lots of malware depend on DNS. Not not everything, but lots of it still does. DNS becomes another enforcement point by incorporating secure DNS, DNS logging, DNS filtering, and where it's appropriate encrypted DNS. So then let's add into the mix our hybrid or remote workers.

Cypher: Okay. All right. Yes is absolutely appropriate. Good answer.

Glitch: We are allowing this typically by some type of secure remote access, traditionally VPNs that extend the network. Instead of allowing a laptop to connect to an entire corporate network, we should only be allowing that specific user from a specific device to connect to a specific application and nothing else.

Cypher: Yeah. When we should be applying the idea of application centric networking. You know, applications should define a policy. ⁓ let's let's take an HR system as an example. We will allow defined HR users from a managed corporate issued device authenticated with MFA, only from the United States during specific business hours, for example. Everybody else, if you do not hit those criteria, gets denied. Network becomes secondary in this case, but it But it is still relevant and important.

Glitch: If you will indulge me for a moment.

Cypher: You say that as if I have the means to hold you back.

Glitch: It's good to give you some hope. Now allow me to put on my Oprah hat to talk about encryption. You get encryption, and you get encryption and you get encryption. Encryption everywhere, from clients to applications, to internal APIs to databases, to backups, to replication, to management traffic, and so on and so on. Don't assume internal traffic is safe.

Cypher: Ha ha. Yeah. And we also need to eliminate implicit trust. So, for example, ⁓ you're inside the network. Sure, we'll trust you. Right? And then you you're connected over a VPN. I mean, come on in. The water is fine. Same subnet. ⁓ the world's an oyster. Known IP? Yeah. We have been waiting on you. Would you like would you like fries and a peanut butter milkshake for your unrestricted journey now, sir? I mean, we are here so you can have it your way.

Glitch: Dun dun dun dun dun. I I feel that this is totally about you with the peanut butter milkshake reference. But let's also not forget the importance of protecting our identity infrastructure. Identity becomes your new perimeter, so it's critical that your approach it you approach it aggressively. Things like Active Directory, Entra ID, domain controllers, PKI, MFA infrastructure, privileged access workstations, just to name a few things. Not to be all doom and gloom, but if identity fails,

Cypher: Could be. Yeah, could be.

Glitch: Everything fails.

Cypher: Yeah, you are so not wrong. One of my new slogans that I've put on on LinkedIn a few times is how identity's the new perimeter. So you are speaking my language, sir. But ⁓ so so glitch. We have covered a lot actually in this episode of the the right approach in designing a secure network architecture. What are some of the common mistakes or misconceptions that you've seen?

Glitch: ⁓ that's a great question. We can't truly learn without failure, whether it's from ourselves or from others. First thing is zero trust is not zero access. Zero trust doesn't mean no one can do anything. What it really means is everyone can do exactly what they need, nothing more, nothing less. Another mistake I see all the time, and I've been part of some of these myself, buying products before architecting the solution. For example, Most orgs bu all are a combination of these things because that's what you should do. You know, everybody you know everybody else is doing it. Why not? Why should I be left out? So they're getting things like firewalls, a NAC solution, a CASB, ZTNA or an EDR. And then they ask, okay, how do we build zero trust around that? Their approach should be architect out your solution first, technology comes after. Technology should be second to that.

Cypher: Preach, preach on preach as much as you want on that just for the record.

Glitch: Woo woo, I'm raising the roof right now. You can't see it, but I'm I'm doing it. Having flat networks or semi flat networks with minimal ACLs, that's a that's another one. Everything talks to everything. Ignoring legacy systems or applications, that's another big one. Many of these need many of these these legacy systems or applications need broad network access. They use old protocols and lack MFA. These systems, if they can't be replaced initially, need to be properly isolated.

Cypher: Okay.

Glitch: So couple more. Treating segmentation as a project. Segmentation isn't something you finish. Kind of like zero trust. It's not really something you finish. It's refinement and it's continuous. Organiza organizations change, applications evolve, threats adapt. We have to approach our policies the same way.

Cypher: I have to say that that was beautiful, man. It was beautiful. Carry on, carry on. Like

Glitch: I I l I learned from the best. Let me just put it that way. And finally, here's one that I think you can relate to. MFA equals zero trust or MFA is good enough.

Cypher: Yeah. MFA MFA is important, right? But MFA does not solve all of the problems. I mean, MFA in and of itself is not even equal. Like if you look at different MFA solutions, they're not even equal. ⁓ you have to look at your organization. You have to look at the things that make up your organization because what works for half of your user population may not work for the other half of your user population. So just like what you were talking about a minute ago. When you don't plug in a technology and and check the box is done where it's an evolution, you've got to you've got to literally get your solution figured out before you buy the technology to solve it. MFA is no different. ⁓ additionally, you cannot you gotta be careful when you're I mean, FA MFA is important, right? But you cannot challenge every user every step of the way, or either your users are gonna figure out a way to bypass you. Or the business is gonna completely come unhinged because you've impacted the productivity so much.

Glitch: One hundred percent. I mean, we've seen that recently with with an implementation where it it was needed by design, it was nothing that we could avoid. But it it fundamentally changed the efficiency of how they could do things. Now you you have to separate the the complaining from the actual issues, but you can't ignore it just to go just to be under the understanding of, Hey, my users are complaining, but we've got to do this thing, drop the mic, walk away. You've got to listen to their concerns because you can extrapolate even even if it is that they're using that that venue to vent and complain, there's probably some truth in that or some real ⁓ issues that you have to work out and have those conversations.

Cypher: Yeah. I ⁓ am back to the MFA, not all MFA being being equal. So MFA in a zero trust world actually has to be phishing resistant MFA, preferably PKI based. So ⁓ I was on a a meeting with someone from a different part of my organization on I don't know, Monday or Tuesday of this week, and they literally were like, Well, but why can't we just do SMS and or why can't we just do email as the second factor? And I was like, because Those those things are not considered secure MFA anymore. Those are those are yesterday's security practices and we have to march forward to today's security practices. So yeah, totally.

Glitch: Right. And and what what works today, we may find out a few years from now that that is no longer valid as a security method or or a secure way to deliver your second factor of of ⁓ authentication.

Cypher: And this my Joe and Jane Q public, we like to call evolution. We have to evolve and adapt along with the bad guys and the technologies or we get left with yesterday's perimeter is good enough. Who's ever even heard of Defense in Depth and what's this zero trust, you know, wickemerole you're trying to sell me? That's what happens if you don't a ⁓ adapt and evolve.

Glitch: yeah. One hundred percent. Very well said. I assumed you would articulate that very well. And as usual you have. So as we wrap this up, ⁓ what is important to understand and educate others is on zero trust. It's not about making networks more complicated. It's about making trust more deliberate. For enterprise architects designing a secure network architecture, success is measured not by how high the walls are. But by how small the blast radius becomes when inevitably something slips through. don't ever go into the mindset that nothing is ever going to happen. You've got to be in the mindset of something will happen. It's just a matter of when, okay?

Cypher: Well, and if you go with the zero trust mentality, you're assuming it already has and you just haven't figured it out yet.

Glitch: Bingo, bingo. A well designed zero trust network doesn't promise perfection. It promises resilience. Attackers may get in, but they don't get far, and that's the difference between an incident and a catastrophe, or the other word that we will not say.

Cypher: Thou shalt not say the B word, sir. Every time I hear the B word I think class action lawsuit and attorney.

Glitch: Yeah. Yeah. So I think we covered a lot in kind of a short time span, but hopefully, ⁓ from your side, ⁓ Cypher, what do you think? Do you think this went swimmingly?

Cypher: I yeah, I think that we actually hit some really value add points. Hopefully we gave some people some clarity on ⁓ the the secure by design for network architecture. That's definitely a thing. ⁓ I think the one thing okay, so two things. First off, we actually made it through an episode without really delving into communication with the business, which is kind of weird. I think that's a first. Yeah.

Glitch: All right. Yeah, it is. It is a first.

Cypher: ⁓ but second off, I think the hardest thing for most people to grasp is everybody wants an easy button. They want to be able to go out to the great wide interwebs and pull up some template that is a plug and play for how they get zero trust. And even if you're looking at the fantastic guidance, and there's a lot of different schools of thought on this, right? You like, you know, NIST has one and Cisco has one. That's actually pretty good for the record. And but most of these major ⁓ frameworks or major organizations have some take on how you should implement zero trust. But just like every other framework and every other ⁓ thing that we look at, you have to understand what your business needs from it. Not everything should be optimal because that's expensive and you don't necessarily have to be optimal to be secure for your organization because you have to enable the business. You don't have to put them on mega lockdown. ⁓ But yeah, I think that everybody just needs to remember that you have to tailor your security posture and your security practices and your enterprise architecture practices and your tooling practices. Everything has to be tailored for what your organization needs. There is no plug and play easy answer. And like you said at the beginning of this, there is no buy this product and your zero trust.

Glitch: Right. Right. And I and I think part of the reason of the easy button is the fear of the unknown. Most people who are entering this when when you're choosing as an organization to go down the zero trust route, most likely you're entering into a realm that you've never dealt with before. Or you maybe you've had maybe you've had some you have some professionals in your organization that have done it at previous organizations. But for mo for the most part Since this is a change in mindset for the whole enterprise, not just technology just not technology focused, for the whole business. And that's scary, especially if you can't present them with what that's going to look like. So somebody wants the easy button because of that fear. That fear should drive you to not find the easy button, but to design it to your business needs. And D well also I'm gonna use a phrase that you like to use sometimes, which is and you don't always have to go with the mindset of buying a Mercedes when you only just need to start out with a Honda. You can maybe get to the Mercedes l later, but start out with the Honda. Yeah.

Cypher: And later. Yeah. If you need it, right? Like if you actually need a Mercedes, but you might find out that you need a you know a a an EV or you might need a a you know a some four wheel drive truck. Like you have to figure out what's right for your business. But I think another one of the the reasons why people want to find that easy plug and play is because none of this because there isn't a template that applies to every single organization, you have to read ambiguous documentation. And you have to interpret what that ambiguous documentation means for your organizationally defined criteria of that. And then you you have to do what so many technologists hate to do. You have to write things down and you have to build your plan. And then you have to be able to hand I know, right?

Glitch: Wait, documentation?

Cypher: I don't know why, but that totally just made me think of a movie. ⁓ Buffy the Vampire Slayer, the movie, not the TV show. Like when Paul Rubens is like, ⁓ yeah, that was great. Okay. Kudos to you for getting me to bring up a freaking movie from like the nineteen nineties, eighties?

Glitch: Ha. ⁓ ⁓ y yeah, yeah. It's what I do. You get you get me to bring up song titles from the fifties, sixties and seventies and eighties. So yeah, I thought I'd flip it back on you this time with with movies.

Cypher: True. True. But yeah. But I do think we did a good job. Is there anything you think we we need to still add?

Glitch: Yes. To all of our new and returning listeners, thank you for being with us. I'm Glitch.

Cypher: And I'm Cypher, and stay chaotic, stay curious, and hey, stay slightly undocumented.

Glitch: Huh, go figure. We'll see you next time.