Network Security Zones and Attack Surface Reduction

I worked on hundreds of different networks in my career, and everyone's network tends to have unique

characteristics. This makes sense because if you're working in a manufacturing environment, your network

infrastructure is going to be very different than if you're working in a medical environment. But even with these

dramatic differences between the overall goals of the organization, there are still parts of the network that are very

similar from one network to another. We tend to use firewalls to help us segment the network and determine where

we might place different devices in our network infrastructure. This can help us keep the attackers on the outside of our

network while allowing legitimate traffic to pass through. But of course, the firewall is not the only security

technology we might use. There are other devices that either include their own security or can help with the overall

security architecture. Devices such as honeypots, jump servers, sensors on the network, and load balancers can help

create a more secure computing environment. One characteristic that can help in the

process of designing a secure environment is the idea of a security zone. A security zone is very different

than an IP address range or subnet description. Instead, a security zone allows us to logically separate all of

the devices on our network by their use or their access type. Each section of the network would be assigned a zone.

For example, you might create a very basic network design where part of the network can be accessed from the

outside, and part of the network is prohibited from outside access. You might assign one of those zones as a

trusted zone, and the other as the untrusted zone. By themselves, those names don't tell us a lot about what

those zones do. Some organizations refer to these as an internal zone and an external zone. And if you wanted to

expand on those descriptions to provide more granular security, you can have many different zones, some that might be

called inside, internet, servers, databases, or screened. This makes it easier for us to

understand what the security rule is based upon, and it makes it easier to maintain these rules in a very large

rule base. For example, we might have a rule that says we are allowed to send data from a trusted zone to an untrusted

zone. Or you might allow access from the outside, the untrusted part of the network, to a screened zone, which is

where our screened subnet might be. Or in certain circumstances, there may be untrusted traffic that is allowed to

move onto the trusted network. Here's how we might put these into practice. This is a network that has an

internet connection on the outside. There's a firewall, and then there's a router that connects to the rest of the

internal network, which includes mail servers, database servers, directory servers, and other internal devices. A

very simple zone configuration then might be everything on the outside and everything on the inside. We might call

one of those zones the untrusted zone, where the internet is, and then we would have the inside, which is the trusted

zone. Here's a similar design where we're using an internet zone, a screened zone, and an inside zone. And you can

see that we have more granularity when we start breaking these up into smaller zones and can set more precise security

rules in all of our firewalls. An attacker is going to work very hard to find any opening that might be on

your network. And for that reason, we should think about how would an attacker get into our network? If this was our

house, they could get in through a door, a window, or perhaps the basement. In our network, they could get in through

application code, an open port that might be in a server, the authentication process itself, or simply human error.

We could work very hard to make sure that we patched all of our applications and we've closed any open ports that are

unnecessary on our servers. But if we've got one firewall rule that we've accidentally configured improperly, that

human error could result in someone gaining access to our network. We refer to this combination of potential

openings of our network as the attack surface and our goal is to minimize the size of the possible attack surface. For

example, we may want to audit any code that we're putting into our network. We might want to specifically block certain

ports on our firewall and we'll always be monitoring traffic in real time to get an idea of who's entering our

network and what applications are being used. And of course, part of that attack

surface is the connectivity that we build throughout our network. Of course, every device on our network tends to be

connected in some way to every other device. So, it's important that we integrate security into the network

connectivity as well. One thing that we can do is secure the network cabling that we have in our facility. In many

organizations, the cabling is simply sitting out. There are both physical and logical protections that we can apply to

the network drops that are next to our desks and our conference rooms. And we might also want to consider protecting

the cabling as it goes between different parts of the building. If someone is able to tap into the network, they can

watch all of the traffic traversing between devices. For that reason, it's always a good idea to provide

application level encryption. So, even if they are able to capture the actual packets, they have no idea what's

contained inside of those packets. For our remote sites and people connecting from offsite, we may want to

include additional encryption for those links. It's not unusual to build IPsec tunnels from site to site or to have a

VPN concentrator so that anyone on the outside can securely connect to the corporate office.

Mhm.