Module 3 Part 2

Hello and welcome to the second part of our discussion of enterprise network architecture. If you recall, in the first part we talked about potentially conflicting requirements. When we design a network, we have a primary requirement that we want to be able to move data in the most efficient and fast way possible. On the other hand, we want to ensure that the movement of data complies with organizational security policy. It's that second piece that we are going to talk about In this segment, we'll talk about how we can create a network architecture that effectively ensures that movement of data within our network is in compliance with organizational policy. I'm going to walk you through a secure network design process. This secure network design process results in a logical network diagram called a zone diagraph. So we are going to build zone diagraph. Now as we dive deep into the topic, it's important to understand we are creating a network architecture for a specific physical location. But the architecture that we create is going to be logical. That is, if a company has got multiple locations worldwide, then each of those locations would need to have a network architecture defined. Would need to have a secular network design. So there'd be multiple networks that need to be designed. That design is going to be based on the physical layout of the enterprise buildings, the Enterprise Campus. It's going to be based on the actual physical presence of systems at that particular location. So this is a quick recap of the slide that we had in part one, we talked about how network architecture has to create a highly available, secure, scalable, manageable, and reliable set of network services, which results in a highly complex environment. This environment, the network architecture, is designed to achieve two different objectives, reliable and efficient movement of data and compliance of that movement of data with organizational security policy. The first thing that we do is at a broad level define security zones for the enterprise. If you recall, security zones are basically groups of systems that all have to comply with a common set of access control and security policies. In order to do that, we start by looking at tiers. Now these are the same tiers that we talked about in application architecture. In application architecture, we talked about how layers can map into one or more tiers. These tiers are basically logical sets of systems that are all addressed as one. That is, if you have a load balanced application server cluster, then we collectively refer to, let's say, five systems that are in that load balance cluster as our application server. Physically, there are five systems. There are essentially five identical clones in a load balance cluster. Or if you look at a failover cluster used for databases, you could again have three servers in an active, passive passive configuration. We collectively address that as our database tier. Basically, we are introducing a level of abstraction where we are saying we are collectively addressing a group of systems as one. We are labeling it based on the function that it provides. Inside the tier, there is going to be a physical architecture that could be designed for reliability, it could be designed for scalability, it could be designed for redundancy. But either way, we are going to take all of our systems and we are going to treat them as tiers, because there could be one or more systems that are grouped together to serve that particular application function. Let's start by defining security zones. A security zone is a logical entity. It can contain one or more tiers, and it basically segregates or separates various parts of our network. Now, one zone can be a member of other zones, it can contain nested zones, or it can span other security zones. The purpose of a security zone is to provide a logical container. So that policies for risk mitigation can be defined and applied at a zone level. By defining tier restrictions, that is, you are saying that this is the application zone only application related tiers can be placed within that zone. We can also define intra zone communication, which would be the communications that happens inside or is contained within the zone that we can have the inraoneier communications, which is what are the communications that we would allow between tiers that are in different zones. At a very broad level, we could think about two different sets of zones. We have the public zone and then we have the private zone or our internal network. These two would be separated by a firewall. The public servers, they're not the public zone. I made an error there. These public servers are corporate owned systems that are available for the general public. This dude right here to connect to. Right, the general public can connect to it and there is really no security control in place. The internal network, on the other hand, is behind a firewall. That zone, the internal network zone, basically isolates all the systems that are for internal use within the enterprise from all entities that are external to the enterprise. Let's start by looking at how we go about defining security zones at the broadest level for any organization. You could say that we have a large number of systems that are in the public zone and these are the systems that the enterprise has no control over. So this would be the system that is used by customers, by business partners that are external to the organization. And the organization has no control over it, as it cannot put any kind of a security restriction or it cannot impose security controls on those systems. With that said, it is important to understand that you could refuse to engage in communications. You could refuse connections if a system does not meet your standards. For example, at internet banking site might refuse a connection from a system that has an incompatible browser, or it has a browser that has not been recently updated. The private zone has all the systems that the enterprise owns and controls. These assets are controlled by the organization, which means that they get to specify standards, they get to specify controls. They get to say that this needs to have anti virus, it needs to have passwords enabled, it needs to have biometric authentication, whatever that might be, right? So the organization gets to dictate controls. Now once we get to the very broad definition of public zone systems that we don't control and private zone systems that the enterprise does control. Any further divisions of the private zone would be very specific organization to an organization. The next step in the process is to go in into our private zone and start defining all the different zones that are going to be within it. In order to do that, we need to have a list of all of our host, the word host, meaning systems. We take every single host that we have. We assign the host to a tier. Then we take every tier and we assign it to a zone. Now, one zone could have multiple tiers subject to restrictions. An application zone could have multiple application tier. It could have a warehouse management system. It could have a customer relationship management system. It could have a logistics execution system. It could have a manufacturing system. When we define these zones, we can also define the level of trust that we have in that zone. That is, how likely. Are we to have untrusted traffic, right? Or how likely are we going to have a high level of control, right? So we could have a restricted zone or a management zone for managing the network that have the highest level of trust. That is, we need to have the highest set of security controls so that the organization would have a high level of trust that the data that is moving through the network is not compromised in any way, shape, or form. Before we dive in and start looking at any specific examples of organizations and the security zones that they would use, without knowing anything, we could actually create a zone definition diagram by saying, we have the public zone, right? This is where all of the systems that we don't control side, we have a private zone, which are all the systems that we control. Within the private zone, we have a perimeter zone, so these are the ones that are directly exposed to the public zone. Right. All the systems in the perimeter zone would be directly exposed, the public zone. And if you look at what systems would they be? Well, that would be our public facing website. That could be communication devices, appliances, or systems like a voice over IP system. It could be a consumer portal. We'll also have a DNS in the perimeter. Dns is the domain name system that allows users, are systems that are in the public zone to actually find those resources that we are putting out in our perimeter zone. I must say here that another term that's very commonly used for perimeter is DM, or the Demilitarized Zone. We use the more neutral terminology of perimeter because DMC has got political and military implications in the perimeter zone, we put all of those systems that need to be directly accessed from the public zone, or broadly speaking, directly access from the Internet. Now in the internal zone we can say, hey, if you have an NTR architecture, well that means that we need to have clients. We need to have an Internet, which is basically web internal web applications. We need to have a set of traditional applications. Of course, we need to have a data tier where all of our data is stored. In addition to that, in order to run our network, we will need a set of infrastructure services, like the domain name system. Except that here the internal DNS will allow all of the systems that are in our internal zone to find each other. Right? So we could group our infrastructure zone, Internet zone, the application and the data zone together into a core zone. This is the heart of our enterprise computing, with all of those client devices being a little bit more transitionary, right? They are changed more often. You might have laptops that are within the enterprise or might leave the enterprise. Next, we need to look at the data that is going to move between zones. We have a source zone and a destination zone. And we are going to then exhaustively define what is the port number that is going to be used, what is the protocol that is going to be used, what is the transport layer protocol that is going to be used? And then say, why are we doing it? We basically create an exhaustive list of all the different traffic that could happen. In this case, the slide shows the traffic between the public zone and the perimeter web, but you will need to define for all combinations of zones, what is the traffic that is going to be explicitly permitted. So again, that list that we just looked at showed one example of public to perimeter and that is not exhaustive. Here is another incomplete list. We have to define all of our required interfaces and assign host to the tiers, right? So, we have to take all of the defined interfaces. That is, what is, what is the protocol? This is the application level protocol, right? This is the transport level protocol. This is application layer. This is transport layer. This is the port address. We are basically saying here are all the different tiers and the ports and protocols that are going to be used by those tiers. Again, this would be an exhaustive list based on documentation that is available from the organization. Once we have this, that is once we know what are all the systems, what are all the host, if you will, we assign all the hosts to tiers. We look at what are the ports and protocols that are going to be used within a tier. We look at the ports and protocols that need to be accessed between zones. Right, So we have all of that documentation. So then going back to the general diagram that we have, we can now start filling it in. So I'm using Indiana University as an example. You'll see here that I have intentionally stayed away from any cloud applications like Canvas or Cal Tura or Zoom, because they are all external to our IT infrastructure, right? While we consume those services, we don't control or manage them, so they will not be part of our zone diagram. So in the perimeter, we have our extra Nite, which is one. Do we have our website, www dot Indiana? We have our voice over IP platform for providing internal telephony and then connecting to the external telecommunications network. We have VPN, the virtual private network for secure connections into the network from outside. We have the central authentication system. All of you would have seen it when you logged in into any IU resource. And I've got e mail here. This e mail is not Office 365, but it is an internal e mail system, the traditional Microsoft Exchange. Right, So all of these systems are in the perimeter zone because they need to be able to directly communicate with devices that are in the public zone. Now in the internal zone, in order to populate this, you do need to have an in depth understanding of all of the systems that are in use by an enterprise. So that would come from the documentation, or in the case of your assignment, it would come from the scenario that I've given you, right? So we could have Sharepoint, right? For infrastructure, we have identity and access management uses Microsoft's active directory system. Talked about how we need an internal domain name system. We need DHCP or the domain host control protocol for assigning IP addresses. And we have a Juniper network based network management system. So that's why I have Juniper in here, right? So are you being a very large comprehensive university? We do have a large number of different databases. So we have a set of core databases. We have Oracle, SQL, IBM's DB to you name it, we have it, so each of these are tiers, and then they are all within the data zone. And then for applications we use people soft for our HR services. Sis is a student information system, so that's where the actual student records are maintained. Quality is our financial ERP system, that's the one that is used for managing the finances of the university. Then within the client here we have laptops and desktops. And I always separate out laptops and desktops because from a security standpoint, laptops have the ability to leave the organization not by themselves, but somebody could carry them out, which means that they could be lost. And then we need to make sure that the data on it is encrypted. Desktop systems tend to be behind closed or locked doors. As long as they are behind locked doors, you don't need to necessarily encrypt the hard drive and then take the performance head. The next thing we will do is defining network devices and segments. So far what we have done, we have defined the zones. We have taken our list of systems, assigned them to tiers. We assigned the tiers to zones. We also documented the communication that needs to happen between the tiers and between the tiers that span multiple zones, which are individual systems. Continuing along the lines as we did previously with the ports and the protocols, we now have to define every tier and the communication that happens within that tier. We can also define things like load balancing or other functional requirements within a tier. Now, another very important thing, particularly from a business standpoint, is the availability and the performance. From a communication standpoint, we need to understand. The performance capabilities of the systems that we are using. We need to understand the performance capabilities of the network and the network hardware that we are using. From an availability standpoint, we are looking at unplanned downtime. This term downtime refers to unplanned downtime, which means that unexpected downtime, downtime is measured in what is called a nine rating. A 29 rating is a 99 percentage up time. That basically means that we could have unexpected downtime of three days, 15 hours and 36 minutes per year, right? That sounds rather high, but then you have to understand that once you start getting into higher levels of availability, the costs start climbing dramatically. Once we get to the 59 availability, you are down to about 5 minutes of annual downtime, right? At that point, with 99.999% up time, we will need to create multiple redundant data centers. And those are very expensive, right? While it sounds good to say that we have 59 availability, you don't do it unless your business really requires it, right? If your business is exceptionally sensitive to downtime, then having multiple redundant data senders and the dramatic increase in cost associated with that would be fully justified. Similar to what we did for communications and the ports and the protocols. We have to define availability information. These slides, I don't have all of the possible systems or tiers captured. I'm just taking snapshots and showing them so that you know what this documentation would look like. Right? So again, we are looking at the zone or the tier, the data that is going to go and look at what is the bandwidth requirement or what is the speed requirement, the average, what is a latency which would be the delay and then the minimum acceptable nines rating. Keep in mind that for five ninths you need redundant systems, redundant hardware, potentially data centers. Then we have to look at what are the restrictions that we are going to put on the data, right? So what is the allowed communication or what are the restrictions? So remember we are going to apply the principle of default deny. That is, we will explicitly define all the traffic that is allowed to go through our system and anything else would be hit with default deny. No, you're not going anywhere. Right? So if traffic is not recognized, then the default deny principle would apply and that would really be the restriction. In order to implement the controls on traffic, we need to define switches and routers. We need to define firewalls and more switches and routers. A firewall, most people think about it as a device that restricts data. But the strict definition of a firewall is that it allows permitted data, right? With a firewall, we are going to explicitly define traffic that is allowed to pass through the firewall and then apply the principle of default deny, which is if it is not explicitly allowed, it will not be allowed to go through the firewall. Once we define these different network roles, we can then start thinking about the connectivity. So you'll see here we're looking at okay switching and routing. I need to connect all these systems together. I need to control traffic. So I want to do, I want to put a firewall. Then we have to define segments. Network segments are the connectivity that connects the switches, the routers, and the different actual physical systems together. Right here, we need to worry about connectivity, we need to worry about performance, and we need to worry about security, right? Security is typically implemented at layer three by using the IP address and at layer four by using the port address for the application. Here we can also make a decision between logical segments, which are lines that we discussed earlier, or physical segments which are traditional local area networks. Once we put that in place, we now have our overall zone diagram. Here we have our zones, our tiers, the roles and segments all defined. You will see that we have numbered all of the segments, so that in terms of creating documentation, we can say that here are all the different segments. Here is the speed of the segment, Here is the medium that is used. Here is how the segment is defined, whether that's a virtual land or a physical segment. The original material for the zone diagramming comes from some documentation that Microsoft created quite some time ago. But I found that is actually the simplest and logical way of creating network architectures that are inherently secular. It also helps, it doesn't really get into the weeds from a technology standpoint. It is actually very logical. You take an inventory of all of your systems. You assign every system to a tier. You assign tiers to zones. You define traffic between between tiers that are in different zones, between zones. And then you define the control devices and the network segments to provide connectivity. I don't expect you to read the reference documents, but if anybody does want to look it up, I do have it available, but you will not be tested on the reference document itself. In summary, in this segment, in this spot, we looked at how can we define a network that is inherently secure. How can we define a network that moves data in a reliable, efficient manner? At the same time, making sure that we are always in compliance with organizational security policy.