Welcome back to the Cybersecurity Architecture Series. In the previous two videos, I talked about identity management and endpoint security, and now we're going to focus on the network. The network security involves a lot of different elements, and we're going to talk about each of these-- --about firewalls, which are a fundamental component of this, about segmentation, which we're able to do with using firewalls, about virtual private networks, about SASE. You'll hear more about that in a few minutes. And then, actually, the topic is so large and so mature, you really can't cover it all in this space. So there's going to be some things I'm not going to get a chance to talk about.
But needless to say, there's a lot more that could be discussed here. So, first thing we're going to talk about are firewalls. So let's talk about what are we going to do with firewalls. The idea behind them in the first place where the technology and the notion even came from is in the physical world, a physical firewall.
Let's say we've got three townhouses all connected. And this guy has a fire in his unit. Well, what we'd like is to have some way to limit the spread of that fire from one unit to the next. It might not make it completely go away, but it slows it down so that the fire department can get there and do something about it. So it's a way of creating isolation and protection from a dangerous event. So take that concept in mind and then apply it to a network scenario.
Here we've got a user on a workstation hitting a web server, and that web server then goes against a database. The typical architecture we put in here is we add a firewall here and a firewall here. One that's Internet facing and one that is internal facing. And what we're going to do, the reason we're putting two of these here, we'll talk more about it in segmentation. But simply what we're going to do here, in the most basic form, is we're going to filter based upon certain things that are happening here.
This is this notion of packet filtering. With packet filtering, I'm going to look into the packet, that is, the information that's being sent from this guy to this guy. And in that, he's going to include things like his source address, that is, the address that he's coming from, his destination address, where he wants it to go, which is going to be this web server and the port that he's going to use, which is a way of designating what kind of traffic it is. So this firewall can then filter based upon that information that's in the header of that packet. And he's going to look at and say, okay, port 80, that's the standard industry standard for unencrypted Internet traffic. So I'm going to allow that web traffic to come through on port 80, that we will allow.
We will also allow encrypted traffic. So this is your SSL or now TLS encrypted web traffic. So I'm going to open this first firewall to allow that information to flow through. But I'm also going to add some more things to make it a little tighter. I'm going to say the source address has to be in the range of the external Internet. Why would we look at that? Well, I want to make sure that somebody isn't spoofing and acting like they're coming from inside.
Sometimes we'll trust traffic that comes from the inside and give it more privileges and sort of drop our guard. We don't want that to happen from external traffic. So if this packet is literally coming from the outside and claims to be coming from the inside, we're going to block it. It's just going to be blocked right here. The destination address, we're going to say, where you can go is you must in fact only go there.
If this guy tries to put any other address, like here, if he tries to go to the database directly, that will be blocked, because that destination address is not something we're going to allow through the first firewall. Now we have a second firewall here that's going to add even a little more security. It's going to say this is the traffic, this is the port we're going to open up to allow this kind of traffic between the web server and the database. We're going to allow a source address only of the web server. So I'm not going to allow anything that came from the Internet, the external world, if it's got that address as its source, where it started from, I'm not going to allow it.
It has to have originated here and its destination can only be that. So what we've done in creating that set of rules is any traffic from the outside can only get to and must stop over here where it can be inspected and where we can implement some sort of security controls. It cannot get anywhere else. So that's what we're basically doing here, and you can keep applying these kinds of rules in order to tighten up your security. And what we're doing, what I've described here, is basically this idea of packet filtering where we're essentially just looking here at the packet that is, the first part of the packet, the header.
So think of it as like an envelope. If I'm mailing a letter to you, what's going to be on the envelope? Well, we're going to have a to address and we're going to have a return address. This is your to address. This is your return address. So that's what we've basically done here. But we have not looked inside.
So there's no inspection, here. But in this next example, I'm going to talk about stateful packet inspection. Where in this case, we're going to look not only at the packet, but we may also go ahead and look at the full thing, look at what's in the payload as well. And there are other things like application firewalls that are specific and they'll do even more inspection of this payload. That is the data that you're actually sending and make sure that it's not going to do harm to us. And in this case, it's more like the open envelope so that we're able to see the contents, not only the to and the from, but we can also see the contents as well.
So that's an analogy to help you understand what this is. Stateful packet inspection also looks at the context of the packet. So it's looking at you sent one of these, and then one of these, but you should never have sent that next thing because that breaks all the rules. So it can look at more than just individual packets in isolation, which is what packet filtering does. This was sort of our first generation of firewalling, and then it got more sophisticated when we added stateful packet inspection.
But there are other things here as well in this sort of firewall and technologies. Think about these all as a collection of technologies that can be part or not of a particular firewall. And the next one is this idea of a proxy. A proxy is something that acts on behalf of something else. So we have here a workstation that's coming in from the outside and it wants to hit this web server, for instance. Except what I'm going to do is say I'm going to put another server here in between that is the proxy.
And what's going to happen is I'm going to break this session. Right now what you see depicted is a direct connection, end-to-end. I insert a proxy, I'm going to tell this guy, you're going to communicate directly with me and he is going to communicate directly with the back end Web server. Now we have two sessions.
And what it is, is this guy thinks he's talking here, but in fact, he's talking to this guy. This guy thinks he's talking to this. In fact, he's talking to that. Now we have effectively a man-in-the-middle.
But it's a good man in the middle. It's one that we put in there so that we can inspect the traffic. By the way, traffic coming in from the outside into my internal network. Maybe I want to have a look at that before I allow it in, see if it's got viruses or things like that. So I can inspect and I can enforce a security policy, if I need to. That's one of the advantages of putting in a proxy.
By the way, sometimes people also put in proxies for privacy reasons, so that they can guard against who's seeing exactly who's doing what. It just looks like everything is coming from the proxy, not the actual end user, in that case. The final bit that I want to talk about here is actually maybe one of the most pervasive of these technologies, network address translation, or NAT for short. This is something that is probably in your home and you're probably using it right now and you may not know it. With NAT, what we do is, the Internet-- So by convention, we've all agreed by industry standard that there is a range of addresses that are reliable across the Internet and a range that are not reliable across the Internet. So this is specified in the in the rules for Internet traffic.
If the address starts with a 10, then it doesn't matter what the other numbers are after that, because Internet addresses are always these four numbers separated by periods. That's the way we depict those. If it starts with a 10, if it's a 10 dot address, it is not routable across the Internet. It is routable across an internal intranet or across your home network. If you've got a home router, Wi-Fi router, whatever, you probably will find that it used a 10 dot address or more commonly it's used one of these 192.168 dot something dot something. That's very common in home setups. So this is an internal address that cannot be routed across the internet.
That's why we need this NAT box. The NAT box does the translation, that's the T in NAT. So if this guy wants to send traffic that goes out to the Internet, his internal address, if he put that out directly, it would hit the first router on the internet and get blocked.
It wouldn't go anywhere. But in fact, what we're going to do, is the NAT table, the NAT router or NAT firewall maintains a table where it's going to translate this into an external address, usually just a single address that is recognized for everything that's behind here. So it actually conserves IP addresses. I don't need I could have 100 of these different devices back here.
They all look like just one address going out to the Internet. So I'm going to translate the traffic as it comes here into something that's routable so it can get out there and it will come back and then the NAT box will turn it back and send it back to the workstation that it needed to go to. Now that's just to preserve existing functionality. Where's the protection? The protection comes in the fact that if this guy out here wants to directly hit this workstation, he can't because the address for this workstation, this 192.168.1.1 is example is not routable across the internet. If he tries to send that, it won't go anywhere.
So this way we have internal traffic and external traffic and we can flow this way. But it prevent someone from being able to get from the outside directly to the inside. And as I said, this is very common technology. It's usually built into all of the home routers.
Okay, we just talked about firewalls. Now we're going to talk about segmentation. That is, how are we going to apply these firewalls in various network architectures to achieve different levels of security? Let's take the first one. This is the most primitive. I don't recommend this. Don't ever do this.
But this in the early days of the Internet was a viable option for a lot of people. It's a bastion host. We basically take our web server and put it on the Internet because what we don't want is the internal network-- intranet --being exposed directly to the Internet. And if I don't put this somewhere outside here, then that means I have to allow all the Internet traffic into my internal network. And that's a really bad idea.
So in the early days, people would put a single firewall right here, put their web server out here, or whatever devices, it had to be a bastion, last bastion on on the defense right out here on the edge. Again, not recommended. We have better ways to do it.
The sort of next generation of this was a tri-homed network where in this case we've created essentially a firewall that we've carved off here into three different networks. So the firewall that's sitting here recognizes traffic coming in on one network interface card. And this traffic, for instance, all of the Internet traffic will be directed directly into where our Web server is. It's coming in on this network interface card, it will automatically be directed there.
And maybe we apply some rules like the packet filtering and stuff like that. But that's where the traffic is destined to go in most cases. And likely in this case, the internal traffic, it's coming in on this network interface card, it could be routed here if somebody's internal user wants to hit our website.
But it could also just as equally be trying to go out somewhere here. So here we have a single firewall sitting there, but it's got three different network interface cards. So it's trying to kind of do a lot of work in one place. And that's why it's called tri-homed. This is a DMZ of sorts. A demilitarized zone is the term we use there to refer to an area that's a buffer between an untrusted environment and a more trusted environment.
Now, I'm going to use those terms very simplistically with apologies to people who understand what zero trust means, that there's really no trusted networks. But that's why we're essentially trying to show here's the red zone, the untrusted. The yellow zone is the semi trusted and the green zone is the more trusted zone. That's the idea here behind the color coding. Okay, move to the next one, the basic DMZ. And this is very popular.
By the way, this last one is one that's often done in home networks. If you want to have an internal network and you want to allow guests to have access or your IoT devices or things like that. If you're hosting your own web server on your home network, not a great idea, but you could do it. You might want to separated out like this because again, it's a low cost option.
That's the advantage is, it's very scalable. It's cheap. But on the downside, it's a single point of failure. If this thing doesn't do its job, everything's wide open potentially. Okay, moving on to the basic DMZ, which in this case I'm going to use two firewalls.
So automatically I end up with more costs because I've got multiple security protections that I'm putting in place. And it's going to be more complex because I have to administer different rules and different capabilities here. And I gave an example of this in the first frame. In the first example before, when I talked about packet filtering and traffic coming in here and coming out there and so forth. That would be a basic DMZ.
We got a red zone, a yellow zone, a green zone. Think of this as the traffic light. This is the danger untrusted, semi trusted caution. And then this is where it's more trusted. And we've built a kind of firewall rules to make sure that this can be trusted, because again, someone cannot go from here to here.
We block that. We block that actually at this first firewall and then we have a secondary block here. And as a result, because we've got one block here and another block here, we have defense in depth. You remember going back to the very first video in this series, one of the principles I talked about that was important is this notion of defense in depth.
I don't rely on any single security mechanism to protect me. If this firewall fails for some reason, I still can't get traffic from here to there because I've built in a rule that said the source address has to be traffic coming from this web server, for instance. And if this failed and all the traffic was able to come through it, then it would still be blocked by this second. So we've got defense in depth. It's also more scalable. So I could build up multiples of these, multiples of a lot of these kinds of things.
So the opportunities are a lot greater. Again, not a single point of failure, but defense in depth. And then finally, I'll talk about a multi-tiered DMZ. So the multi-tiered DMZ, we basically put a firewall here and here. So now we've got this this diagram essentially replicated here. But in this case, I've split out the web server from the application server from the database, in this example.
In this case, I'm going to implement yet another firewall, a third firewall in this case. So as you would guess, one of the downsides is it's going to be even more expensive than these others. It is going to be more costly and complex than these others, because now I've got three firewalls to administer and different rules on each one of them. However, we've got defense in depth on steroids. We've got even more because now any one of these mechanisms, it would have to be that all three of them failed. If one of them failed, it wouldn't necessarily be a huge problem for us.
We also have greater granularity. That is, I can allow traffic to only go to here from this zone to this zone. I can allow traffic from this zone only to go to that zone and traffic from this zone only to go to that zone and do the reverse back.
So more granularity, more firewalls, more cost and complexity. But potentially, if I do it right, more security. Okay, in the previous section, we talked about firewalls and segmentation. Now we're going to cover the next subject of virtual private networking VPNs. Now, what are VPNs designed to do? They're basically trying to give us a secure channel over an untrusted network. That's the idea.
I can't necessarily trust the Internet because I don't control I don't have visibility into all of the aspects of that. But I'd like to be able to send secure information or information in a secure way over it. So I want a secure channel over an untrusted network.
That would be a great capability. And the way I do that, I accomplish it by encrypting my information and then sending it over the network. The idea there is I get confidentiality. And I get that because people can't see what is in the packet.
All they'll see is the encrypted information. We lots of times think about this as a pipe or as a tunnel. You'll hear those kind of analogies used here. Think about if we've got a user here with a browser trying to get to a web server and we're building a secure pipe, a connection from one end to the other. And I'm encrypting all the packets as they go across. So that way someone who looks here sees nothing that they can interpret, nothing that means anything.
That's the idea behind a secure pipe, secure channel over an untrusted network. So that's the good stuff. And security guys love that we can do that.
What they don't love is this. That is a limited inspection capability, this ability to-- so the good guy can send their traffic without everybody seeing it. It also means a bad guy could send their traffic without everybody seeing it and that would be a problem. So it limits our ability to inspect and therefore see if someone's putting malware into my system or someone's initiating an attack. So it's one of those blessings and a curse at the same time. All right. There are different kinds of VPN technologies.
And to understand them, we really need a little bit of understanding on network technologies. A 7 layer OSI stack. This is classic stuff. We're not going to go into it in detail.
But the notion is, is that there are different layers. For every packet I send, different concerns, different aspects that are implemented at different layers here. And what happens in the real world is most people, if you're an application programmer, you're really concerned more up here with the application, presentation layers, these kinds of things.
And the networking infrastructure, people are much more concerned with the stuff down here at the transport network data link, physical layers and those kinds of things. So there's a little bit off concerns that separate there. But the other thing that's really important about this is, with this model, we have a way of, if you implement a security capability, for instance, at one of these layers, it's inherited by the upper layers. So if I encrypt all my traffic here, then it's encrypted by all the higher layers as well. So from a simple security standpoint, it might be easier to put the encryption down lower in the stack.
We'll talk in a minute what hat's not necessarily what you always want to do, though. So there are different examples of how we do this. For instance, at the application layer. You may have heard of this protocol--secure shell. That's an example of an application layer or application specific VPN. It encrypts the data so that you can connect into a particular device console, this sort of thing.
There's a secure FTP and other examples like that. Another one that's very common and you're going to run across this all the time, whether you're aware of it or not, is TLS or SSL--transport layer security or secure sockets layer. This is the older term. The newer name for this standard is TLS. It's implemented at the transport layer.
That's what you usually see when you're a browser connected to a web server and you see that little lock in the browser up on the the URL line. That's what is is being implemented there, TLS. So that is everything that's going to that Web server then is going to be encrypted.
There are other examples. There's a thing called IPsec, which is implemented at the network layer. If you do that, then everything between two network addresses will be encrypted as opposed to between the web server or for a very specific application.
And then we have some other examples of point-to-point tunneling protocol, P2PTP or L2TP, which is the layer 2 tunneling protocol. These are some examples of even lower on the stack. So not to go into details on it, but just to give you an idea, there's not a single type of VPN or VPN technology.
They all share some of these qualities. And if you see these things, you should think, ah that's a type of VPN. Now what's happening these days, is we're tending to move away from these broad network based VPNs more toward application specific VPNs. What's the reason for that? Well, on the advantage side for the broad ones, is that they're relatively simple.
I set up a connection, for instance, between two endpoints or me into a particular network. And everything I do, for instance, if I set up an IPsec session, everything I send into that whole network now will be encrypted. So that's a very simple type of thing to do. However, it doesn't give us the granularity that we get over on this side with a very application specific firewall or VPN like we're doing here with SSH. The other advantage on the broad based side, network-based side, is a catch all. Again, if I encrypt at this layer, then all the traffic, all the different applications can benefit from that basic VPN.
I don't have to set up separate ones. So it's simpler in that regard. However, I don't have as much control and as much granularity. The ability to control and say I have a VPN for my email, a VPN for my file sharing application, a VPN for my instant messaging application and control all of those separately gives me more control so that if I need to shut a particular service down or a particular user down, I can do that. So a lot of different possibilities here in this area of VPNs.
Okay, now we've covered firewalls, segmentation, VPNs, and our last one is SASE. What is SASE?. It's secure access service edge.
That's what the acronym stands for. It's actually a very relevant and important topic these days as part of the larger subject of zero trust. And in fact, another aspect of zero trust that's very relevant is micro-segmentation.
And we talked about segmentation before, but micro-segmentation just carries that to the extreme and puts lots and lots of zones within your network with little micro networks. But SASE in particular. What we're trying to do here is create some sort of of secure capability that's delivered on the edge.
To think about it this way. Let's look at a Venn diagram. Here, we've got networking concerns here. We've got security things and we've got the cloud. If you think about the intersection of network security and cloud, this is the world where SASE lives. Because-- and depending on how you want to think about this, if you think more mathematically, you might like this description, if you think more visually, you might like this one.
We'll go through the mathematical one first. SASE is basically network security plus WAN, wide area networking capability. So that's the network and the security all delivered from the cloud. So that's the way of taking that Venn diagram and expressing it kind of as a loose mathematical equation. So if we were to decompose this a little more, what does it mean? What does the NetSEC mean, network security? Well, it's basically firewalling, which we've talked about. It's secure web gateways, which we didn't really go into detail, but think about those as application-specific firewalls and things of that sort.
And DLP, data loss prevention, which is something I'll talk about in the data security domain when we get to that topic. But all of these things and more, delivered on the edge, so that's the network security component of all this. The WAN, specifically, is a software-defined WAN. Which is a way of creating a dynamic network where you can change where the boundaries of the network are and provision these in real-time, effectively.
So it gives you a lot more agility and flexibility. So we're adding that capability, this SD-WAN marrying it, merging it, with the network security components and then delivering the thing from the cloud, because the cloud gives us the ability to do scalability. We can scale up and scale down elasticity and agility.
Again, lots and lots of flexibility. That's what people are looking for in this case. If I take all of those things and then maybe even add in another thing within the security space, identity management, specifically, authentication and authorization.
So some access controls, then this is what SASE is about. It's combining all of these functions into a single logical component and delivering that from the cloud, at the edge of the network. Another way to look at it is this way. So here we've got our users, here we've got the external network, and then I've got this SASE capability that's here in the middle. And what this delivers is on one end, the networking capabilities I mentioned previously, on the other end, also the security capabilities-- firewall and DLP and so forth. So all of this is is a way of combining these functions and delivering them.
This is a more modern way of delivering all of these capabilities as opposed to what would have in the past each one of these would have been a separate appliance, a separate component, a separate administrative capability, a separate person to administer it and all of those kinds of things. So it's bringing these functions together and having them operate in a more holistic way. All right, now, we finished the networking topic. A couple of things that I didn't cover and I put here in the etc. just because of the interest of time, I didn't really get into very much in the physical networking side, things like 5G and Wi-Fi and the network security capabilities of those.
If there's interest in that, put that down in the comments and maybe we'll revisit that in a future video. Until then, now we've completed the networking portion of our domains. The next one and, we want you to stay tuned and look for that one. The next one will be in the area of application security as we move along the various domains.
Please remember to like, subscribe and hit notify so that you'll be aware when future videos in the series are available.
2023-07-07