Network segmentation
Network segmentation is a really important topic to understand for IT in general, but also for security. As we deploy resources in our networks, creating separation between those resources is an important step for securing those resources, and as a result, our overall network.
In some case, it could even be either required or highly recommended for compliance reasons.
For example, if you are handling credit card processing and therefore need PCI compliance, it would be highly recommended that you create network segmentation to separate anything that handles and/or stores customer cardholder data.
Prefer learning by watching videos? Here’s this blog post in video format pulled directly from our Security+ course:
Network Segmentation with VPCs
Let’s take a look at a cloud environment that makes use of Virtual Private Clouds, or VPCs, on the AWS cloud.
A VPC is very similar to a traditional network that would operate in a data center. It creates separate, virtual networks, that we can then launch resources inside of.
As we create this VPC, we need to give it an IPv4 or IPv6 CIDR block. If I were to give it a CIDR of 10.0.0.0/16, I would get access to a total of 65,536 hosts all ranging from 10.0.0.0 to 10.0.255.255.
Within those VPCs, we can create multiple subnets (which stands for sub networks). Each subnet is a range of IP addresses from within our VPC. Because we chose 10.0.0.0/16 for our VPC CIDR, that means we could have:
| Subnet #1 | Subnet #2 | Subnet #3 | Subnet #4 |
|---|---|---|---|
| CIDR: 10.0.0.0/24 | CIDR: 10.0.1.0/24 | CIDR: 10.0.2.0/24 | CIDR: 10.0.3.0/24 |
Next, we could configure some of those subnets to be private subnets, and others to be public subnets. We could say that subnets 1 & 2 are going to be the public subnets, and subnets 3 & 4 will be the private ones.
| Subnet #1 | Subnet #2 | Subnet #3 | Subnet #4 |
|---|---|---|---|
| CIDR: 10.0.0.0/24 | CIDR: 10.0.1.0/24 | CIDR: 10.0.2.0/24 | CIDR: 10.0.3.0/24 |
| Public | Public | Private | Private |
Public vs. private subnets
Public subnets are considered to be public when they have Internet access to and from the subnet. Private subnets, on the other hand, can’t communicate with the open Internet (at least not by default).
This means that if we launch resources within our private subnets, it’s not possible for an attacker to reach those resources unless they’re able to access our AWS account, or unless they find another entry point — like maybe they’re able to access a compromised resource within a public subnet, and they are then able to move from that resource and public subnet to a private subnet.
Otherwise, nobody can directly connect to those private subnet resources because they do not resolve to the public Internet.
This provides a lot of security benefits, because we could put our databases in those private subnets, and make those databases only accessible to our web applications. Even our web applications could be in private subnets, and then we’d just have load balancers and webservers in the public subnets to accept and serve requests.
Physical network segmentation
As I mentioned in the beginning of this post, VPCs mimic traditional data center segmentation, which means we can apply similar concepts. A main difference, though, is that with on-prem data centers, we can create physical network segmentation.
We could, for example, have two switches. Each switch would be on their own separate connections, and would have no way of communicating. This physical separation is what we call an Air Gap, which is a term we’ve seen before in the course.
The only way to remove this air gap would be to physically connect those two switches together, either by using an ethernet cable for a direct connection, or by adding some sort of router and firewall.
Once we have that connection in place, those two separate devices would then be able to communicate.
If we think about an attack scenario, we can think about why this is such an important concept.
Let’s say that Switch A’s network has been compromised by a ransomware attack.
Nowadays, some of the ransomware used is smart enough to look for all connections and devices in a network so that it can infect as many of those devices as possible. As a result, all of the storage devices in the Switch A network have been infected and encrypted by the ransomware.
However, the ransomware can’t see Switch B, or any of the devices and connections in Switch B’s network since they are not connected in any way. The only way for the attacker to also infect this network with ransomware would be to find a completely separate entry point into that network.
Instead, if Switch A and Switch B were connected to one another and not air gapped, then the ransomware would be able to find this connection and find its way to all of the devices in Switch B’s network.
That’s also why when we have these sorts of connections, we will often find firewalls in between the two networks in order to filter all traffic flowing back and forth. Even if we failed to prevent a breach in one of the networks, we still want to try to prevent that breach from spreading to all of the other connected networks.
We might have our web application servers in Switch A’s network, and then our databases in Switch B’s network. They need to be able to communicate with one another, but the resources in Switch B’s network will have a lot more restrictions in place since they contain all of our sensitive information.
Virtual Local Area Networks (VLANs)
Instead of having to purchase separate equipment to create network segmentation, we can also use something called Virtual Local Area Networks, or VLANs.
These VLANs can be configured to use the same hardware, but while still enforcing segmentation.
We could have a single switch, but that switch still has two completely separate networks that can’t communicate with one another.
If we needed to have those two networks communicate with one another, we could still add a router. The router wouldn’t care that it’s connected to the same switch…it would just operate like normal when routing packets between the two networks.
DMZ/Screened subnet
When we talked about Secure Areas in domain 2.7 of this course, we mentioned the term DMZ, or Demilitarized Zone. Another term for this is screened subnet.
These DMZs or screened subnets are designed to expose externally-facing services to the Internet without unnecessarily exposing resources in our internal networks.
This is important because sometimes you may have resources that have to be exposed to the Internet, but rather than open up your Internal LAN, you can create a separate network specifically for those resources.
Those resources would still be able to access resources in the Internal LAN, so they’re not completely separated unlike with our physical separation example from earlier, but an attacker would have to go through additional layers before they could reach the Internal LAN.
Extranet
Extranet is very similar to a screened subnet, but it’s typically built to create a private network for partners. These could be vendors, suppliers, contractors, etc…who need access to certain private resources, but who we don’t trust enough to give access to our internal networks.
Unlike a screened subnet, extranets usually require additional authentication. It’s not going to be used for the public but instead for people or services who will be given credentials that they have to use.
Intranet
An intranet, on the other hand, is very different from both extranets and screened subnets.
Intranets are designed to be private networks that can only be accessible from within internal networks. You would either have to be directly connected to that internal network, or you would have to connect via a VPN (which we’ll talk about in this section), in order to access this intranet.
These are typically used for sensitive documents that will never need to be publicly accessible. Examples include:
- Human Resources documents
- Company announcements
- Financial documents
- Centralized and private file storage
- Internal employee communications
- Etc…
Zero trust
A big part of the reason why network segmentation is so important is because oftentimes, security efforts are concentrated on the “network edge,” meaning that our public subnets, extranets, and screened subnets will receive most (if not all) of the attention. We’ll implement firewalls, security policies, etc…to prevent an attacker from breaching that network edge and accessing our sensitive and private internal resources.
Except because we focused most or all of our security efforts on the network edge, we don’t have much security within our private networks. In other words, if you’ve been able to access the internal networks, you have achieved a certain level of trust, and you’re not going to encounter as many security checks.
This – obviously – is a cause for concern.
That’s why the term Zero Trust has become quite the buzzword in recent years.
Zero Trust takes a different approach and assumes that there is no network edge — employees can be anywhere around the world and connecting from all sorts of networks, resources can either be local or in the cloud, and attackers may very well be in our supposedly “internal” networks.
Or — even worse — the attackers may be our very own employees or prior employees.
For that reason, Zero Trust implements a requirement that all users and resources need to continuously be authenticated, authorized, and accounted for.
An example of implementing this is that you may have to authenticate again to access internal resources even if you’ve already authenticated to access the private network. Another example would be that all user activity on our networks would be verified, logged, and monitored. Even if they’ve properly authenticated, if users take actions that aren’t normal, then it should be reported as a security event, and so on…
Network segmentation conclusion
Network segmentation is super important, but it can also be a challenging topic to properly implement. It takes a lot of strategy to properly design, and that’s why these concepts are important to understand.
Responses