IT security is all about segmentation.
It's about allowing or disallowing traffic
between different devices.
We can do this in a number of different ways,
but if we're segmenting across the network,
we can segment physically between devices,
we can create logical separation within the same device,
or we can do virtual segmentation
with virtual systems.
It's sometimes common to segment application instances
into their own separate private segments.
This is especially useful for applications
that have high bandwidth requirements
and need the fastest amount of throughput possible.
We can also set up segmentation for security.
For example, we might have database servers that
contain sensitive information and we
may segment our users so they can't talk directly
to those servers.
Or perhaps we have application instances running inside
of the core of our network, but the only protocols
that should be in that core should
be SQL-type traffic and SSH traffic
and we can segment other types of traffic
to remain outside of the network core.
Or we might be segmenting the network because we are legally
required to segment it, or there may be rules or regulations.
For example, PCI compliance requires
that we have mandated segmentation
to prevent any type of user access
to credit card information.
One obvious way to segment the network
is to have physically separate devices.
For example, we might have a switch A, and a switch B,
and you can see there is a physical separation.
We sometimes refer to this as an air gap
because there is no direct connection
between these devices, the only thing
in the middle of these switches is the air itself.
If we did need to communicate between switch A and switch B,
we would then need some type of physical connection.
We would need to run a cable between these switches
or we might put a router in the middle or firewall,
and then send all of our traffic through that device
so that we can communicate between those two physically
separate devices.
We might also implement this type of physical segmentation
to keep devices separate from each other.
For example one switch may contain all of our web servers,
and the other switch may contain all of our database servers.
If these are on separate switches
then we know the web servers could never accidentally
communicate to a database server,
and the database servers would have
no access to the web servers.
Or maybe we're concerned about customer data mixing
with each other, so we keep customer A on one switch
and customer B on the other.
Here's a practical design for keeping
our customers separated, you can see
we have the customer A switch on the left and the customer B
switch on the right.
The devices for customer A can communicate with each other
and the devices for customer B can communicate
with each other, but you can see that there
is no direct connection between these two switches
so customer A has no way to communicate
with anything that's on customer B and vise versa.
There are a number of challenges with this design.
One is that we have two separate physical switches
that both have to be separately maintained,
separately upgraded, and separately powered.
We also have a number of interfaces on these switches
that we probably aren't using, so we're
spending a lot of money for a switch
but not using all of the capabilities of that switch.
Instead of physically separating these devices,
we can do logical segmentation using VLANs,
or Virtual Local Area Networks.
VLANs have the same functionality
where we can have customers on one part of the switch,
and another customer on another part of the switch.
Because we've configured this with separate VLANs,
these two different customers can still not
communicate directly with each other.
It's as if we had two separate physical devices,
but instead now have them logically separated inside
of the same device.
As with physical segmentation, we
would need to have direct communication
between these devices using a cable or a third party device
like a router that can allow us to communicate
between these separate VLANs.
It's very common to install services on our local network
that we would like to provide to people
that may be on the internet.
But we don't want to provide access
to the internal part of our network
for people that are coming in from the internet.
So instead, we'll build a completely separate network
just for that incoming traffic.
This is sometimes referred to as a screened subnet,
you may also hear this referred to as a Demilitarized
Zone or a DMZ.
This allows people to come in from the internet,
usually they connect to a firewall,
and the firewall redirects them to the screen subnet.
Instead of accessing our internal network, which
would be on this side, all of the users
access the services on the screen subnet
and we can set additional security
to make sure that no one has access
to the inside of our network while still providing access
to the applications that are on our network.
You may find that an extranet is a very similar design
to a screened subnet.
We have an internet, there's a firewall,
and a separate network that has been designed as an extranet.
We still have our internal network
for all of our internal resources are
but we've built out this separate extranet for vendors,
suppliers and other partners of ours
that need access to our internal resources.
Unlike a screened subnet, an extranet
commonly has additional authentication that's required.
So we would not allow full access to our extranet
from the internet, instead there would be an authentication
process or a login screen that would then gain
you access to the extranet.
Your organization might also have an intranet.
An intranet is very different than a screened subnet
or an extranet, because an intranet
is only accessible from the inside of your network.
So you might be at your headquarters network,
your remote site number one, or your remote site number
two, and from all of those networks
you can access the internal part of your network and gain access
to the intranet on your network.
This intranet commonly has internal servers
that can provide company announcements, maybe employee
documents and other company information,
and it's only accessible by employees of the company.
Since your intranet usually contains
company private information you would never
want to make this available to others outside of the network.
The only way to access the intranet
is if you are on an internal network already,
or you're accessing the internal network
through a VPN connection.
If you're managing data flows within a data center then
you have another set of segmentation challenges.
There may be hundreds or thousands of devices inside
of your data center and there may be hundreds of thousands
of users who are accessing those services.
For all of these applications running in the data center,
it's important to know what the data flows happen to be.
You need to understand where data is coming from,
where people are connecting from,
and where you're sending the data to.
In a data center it's very common
to refer to these data flows with directions.
For example East-West traffic would
be traffic between devices that are in the same data center,
and because they're local inside of that same building,
you usually get very fast response times
between those devices.
North-South traffic refers to data
that is either inbound or outbound from our data center,
and we are usually setting up different security policies
for that type of traffic because very often that's
coming from an unknown or an untrusted source.
Here's a better picture of our data center.
We have an internet connection that's
coming into some core routers, those core routers are then
connecting to redundant switches,
and the switches are connecting to file
servers, web servers, directory servers, and image servers.
If any of these devices inside of our data center
are communicating outside of the data center,
then we're referring to that as North-South traffic.
So we may have traffic coming inbound and then
going back outbound over the internet,
and that would be North-South traffic.
Anything that's communicating internally within our data
center, for example our web servers may
be communicating to directory services or file servers,
all of that traffic that stays within the building
is referred to as East-West traffic.
One of the challenges with data centers and other network
configurations is once you get inside of the network,
we don't tend to have a lot of security controls.
Traditionally, if you've been inside the network then
there is an inherent level of trust
that we've associated with that device.
But as we've seen, once malicious software gets
on the inside of your network, having no security
controls effectively means that software
can spread to every other device inside of your network.
Instead of trusting every device,
we've changed the model to be zero trust, which
means you trust nothing else on your network
and there has to be additional authentication
and additional methods in place to make sure
that the data flows that are occurring
are data flows that should be occurring
for those applications.
With zero trust every device, every application,
and every data flow is considered to be untrusted.
This means that the flows that would normally
go across our network without any checks whatsoever,
are now suddenly subject to authentication,
encryption, and other security controls.
So we might set up multifactor authentication
between our devices where no authentication existed before.
Maybe we're including encryption on the core of our network,
where normally we didn't bother with encryption.
And of course we'll have additional permissions,
perhaps additional firewalls and other security controls,
to make sure that we can verify every data flow that's
occurring on the inside of our network
using this zero trust model.