The strategy of zero-trust can be a effective way to increase the security of an organization’s data. In this video, you’ll learn more about best practices regarding zero-trust.
In many networks, you’ll find that once you’re through the firewall, the inside of the network is relatively open. People are able to move from system to system without any type of checks or balances. There are relatively few security controls in place and this not only allows authorized individuals to move anywhere they’d like, but also allows unauthorized individuals and malicious software to do the same.
But many security administrators are changing their network to be zero trust. This means that you have to authenticate or prove yourself each time you want to gain access to a particular resource. This applies to every device on the network, every process that’s running, and every user on the network.
As the name implies, with zero trust nothing is trusted and everything is subject to some type of security checks. This means you might be using multi-factor authentication during your login process, you may be encrypting data that’s stored and encrypting data as it’s traversing the network, there may be additional system permissions or additional firewalls that you’re installing, and there are a number of different security policies and different controls that may need to be added to create this zero trust environment.
One of the ways that we can start examining and implementing zero trust on our networks is taking our security devices and breaking them into smaller individual components. We commonly refer to this as separate functional planes of operation. So whether it is a physical device, a virtual device, or a security process that’s running in the cloud, we can apply these different control planes to every single one of these security controls. Broadly speaking, we can look at these as having two different planes of operation.
One of them is the data plane. The data plane is the part of the device that is performing the actual security process. So this might be a switch, router, or firewall that’s processing frames, packets, and network data in real time. The data plane on these devices is processing any forwarding, network address translation, routing processes, or anything else that helps move data from one part of the network to another.
But of course, all of this movement of data needs to have some type of management and control, and we perform that control in the control plane. This is where we manage all of the actions that are occurring in the data plane. This means we may be configuring policies or rules for a device to determine whether data may be traversing the network, or maybe we’re setting up a forwarding policy, or understanding how routing may be configured. So any time you’re referencing a routing table, you’re looking at a firewall rule or understanding how Network Address Translation should be handled are configuring in the control plane.
One way to get a better understanding of the data plane versus the control plane is to see how this might be implemented on a physical device. Here we have a physical switch and we want to be able to break out the different planes of operation. Down at the bottom of the switch are all of the different interfaces that are used to move data from one part of the network to another. And as we’ve already seen, all of the traffic that we’re forwarding all happens on the data plane of the device.
But of course, this device needs to have configurations, there needs to be network address settings or changes to how data might be trunked, and all of those changes would take place in the configuration of the device under the control plane. Of course, this separation of data plane and control plane is not just specific to physical devices. You might have a virtual switch or a virtual firewall that can also be separated into these two different planes. This same separation also applies to cloud-based security controls.
For zero trust, we not only need to implement additional security controls, but we need to be a lot smarter on how we evaluate those security controls. For example, we can implement a technology called adaptive identity. This is where we are examining the identity of an individual and applying security controls based on not just what the user is telling us, but other information that we’re gathering about this authentication process.
For example, we might want to look at the source of the requested resources. Perhaps someone who is requesting data that’s located in the United States is using an IP address that’s in China. And if that occurs, we may want to perform additional security to really confirm that this user is who they say they are.
This might also include an examination of the relationship of this person to the organization. So are they an employee? Are they a contractor? Do they work full-time or part-time? And of course, all of this goes into the evaluation of this authentication process.
We also want to look at things like physical location, the type of connection that’s in place, IP addresses, and anything else that can help us identify information about this user. Once we examine all of these different variables, we can have our systems automatically create a stronger authentication, if it’s needed in this particular case.
Another way to control this trust is to limit how many places can be used to get into the network. So you may want to limit entry points to only being people that are inside of the building or connecting through a VPN. There may be no other methods to gain access to this particular network. And once you have all of this information in place, we can now start creating what’s called a policy-driven access control that examines all of these individual data points, puts them all together, and then decides what type of authentication process should be used to truly understand if the person trying to identify themselves is really that person.
Another good way to qualify the identity of a person is to understand where they’re connecting from, and very broadly, we categorize these as security zones. This allows us to expand from something that is simply a one-to-one relationship where a user is logging into a server and instead looks at the overall path of the conversation. These security zones look at where we’re connecting from and examine where we’re trying to connect to.
So this may be on an untrusted network and we’re trying to connect to a trusted network, or maybe it’s an internal network or external network. And if you wanted to have even more granularity, you could create separate VPN connections or separate groups of different departments within your organization. This allows you to now start setting rules on what zone has access to all of the other zones. For example, you might want to have a rule that automatically denies access if someone is coming from an untrusted zone and trying to communicate to a device that’s in a trusted zone.
We can also use these zones to create an implicit trust. For example, if someone is in our corporate offices, they might be in a trusted zone. This user in the trusted zone may be accessing data on a database server that’s in our data center and the data center exists in the internal zone. This might allow us to create some policies that says if anyone’s communicating from the trusted zone to the internal zone, that portion of the communication is implicitly trusted.
To be able to set these policies and procedures along this pathway, we need to have something in place that allows us to create an enforcement of these policies. This is our Policy Enforcement Point and any subjects and systems that are communicating through this network will be subject to evaluation by the Policy Enforcement Point. These subjects and systems commonly are in users, they are individual processes running on a system, or they may be applications that are in use.
You can think of this Policy Enforcement Point as a gatekeeper. All of the traffic traversing the network must pass through the Policy Enforcement Point so that we can make decisions on whether we would like to allow or disallow this traffic. And although this Policy Enforcement Point is shown as a very broad abstraction in this diagram, you can think of this as multiple devices working together to be able to provide identification of the users and the traffic.
The Policy Enforcement Point doesn’t provide the decision on whether traffic should be allowed or disallowed. Instead it gathers all of the information about the traffic and provides that to a Policy Decision Point. This Policy Decision Point is responsible for examining the authentication and making a decision on whether that should be allowed on the network. Your Policy Engine is looking at all of the requests that are coming through, it examines the request and compares it to a set of predefined security policies, and then makes a decision on whether that is granted, denied, or revoked.
The Policy Administrator’s job is to take that decision and provide that information to the Policy Enforcement Point. There may be access tokens or credentials that are created as a result of these policy decisions and all of those credentials are then sent to the Policy Enforcement Point using this Policy Administrator.
Now we can put all of this together to create a single zero trust model, which starts with our subjects and systems communicating from an untrusted zone over the data plane and communicating through the Policy Enforcement Point. If there is a policy enforcement that needs to take place, this enforcement point will provide that to the Policy Administrator, which then communicates to the Policy Engine to make the decision about whether this traffic is allowed. That result is then passed down to the Policy Administrator, which provides that to the Policy Enforcement Point. And if this traffic is allowed, the Policy Enforcement Point then provides access to this trusted zone, and ultimately, the Enterprise Resource requested by the subjects or the systems.