Many networks are relatively open on the inside. In this video, you’ll learn about zero trust, policy-based authentication, least privilege, Secure Access Service Edge, and more.
Traditionally, we’ve always done a good job at protecting the edges of our network. This allowed us to control who may be entering the network and who might be leaving the network. But once you’re on the inside, all of the network tends to be very accessible. This obviously creates security concerns if you want to be sure that you have the highest level of security on your network.
In recent years, many companies have transitioned to more of a zero trust approach. This is a holistic approach to security that affects every user and every application being used on the network. With zero trust, every user, every device, and every application is inherently untrusted. We want to check and verify any type of traffic going over our network to ensure that only the right users are accessing the right type of data.
This means that we’ll be implementing technologies inside of our network, such as authentication, encryption, additional firewalls, monitoring of this network, and many other security controls.
When you connect to a resource, there’s generally an authentication process that occurs. There’s usually a username and a password that you have to enter, and there may be additional authentication factors as well. Many organizations may also create a policy based authentication, and one of the characteristics of that is an adaptive identity.
With an adaptive identity, every authentication process considers who’s trying to authenticate to the network. Is this an individual who’s been employed with the company for 10 years? Or is this a vendor who just started working with the company only a few months ago?
We might also consider where this person may be authenticating from. Are they located in our local geographic area? Or are they trying to authenticate from a different country?
We might also evaluate the IP address that’s in use and the type of connection that’s being used during this authentication. And we might want to combine all of those together to determine how risky this authentication process might be. If a user is inside of the building, they may only need to use a username and password. But if they’re coming from an unknown IP address in a different country using a VPN connection, we might want to require additional authentication factors.
We might also want to add additional rules and processes based on the information we’re gathering during this authentication process. If someone is using the correct username and password, but they’re connecting at an unusual time of the day from an unusual location, we may still choose to deny that particular authentication. If this same person was trying to authenticate from inside of the corporate headquarters during normal working hours, then instead we may want to allow that authentication.
Once the authentication process has completed and is successful, we can trust that that person really is who they say they are. Now that that trust has been created, we need to understand what type of access that user should have. This may depend on the user who’s provided the authentication.
If they’re part of the help desk, they may be able to view the hardware database for the entire company. If they’re the manager of the help desk, they may be able to make modifications to that database. And if they’re not part of the help desk or managing the help desk, they may have no access at all to that data.
We might also want to consider someone’s location. If they happen to be in a different country, they might have a completely set of rights and permissions than if they were inside of the corporate headquarters. And if the user is accessing the systems using a laptop that has been provided by the company and we can verify the certificate on that laptop, then we may give them additional rights and permissions.
A good best practice for IT security is to only provide rights and permissions to a user that match the requirements for their job. If your job requires that you have read access to a database, then we shouldn’t provide that user with any ability to change that database. This means that we would not arbitrarily provide someone with administrator rights just to be able to access a certain type of data.
All users should be accessing these applications with a limited set of rights and permissions. One of the reasons we don’t want to provide administrative access to everyone on the network is that administrators have full access to all data on all systems. And if a device is infected with malware and the user on that device has administrative access, then effectively, the malware now has administrative access to all of our systems.
One of the challenges with providing the right type of authentication and authorization is that users can be located anywhere. Some users may be located in the corporate office, others may work from home, and others may have a field service position which takes them across the world. And the applications that we use may be located on a public cloud, across the internet, or they may be in our private data center. We need some way to provide a secure mechanism for communication, regardless of where the user happens to be and regardless of where the application resides.
One way that we can create this secure environment is through the use of SASE. This stands for Secure Access Service Edge. And you can think of this as a next generation virtual private network. This moves our security technologies into the cloud itself, very close to where the application data might be. And we would have a SASE client installed on every user’s device so no matter what system they’re using or where they happen to be, they’re able to take advantage of this secure access service edge.
At the top of this SASE diagram is a public cloud, a data center, software as a service, or an internet connection. This is where our applications reside. Our users may be at our corporate office, they may be working from home, or they may be mobile users.
As the users are accessing these resources, we’re able to provide network as a service, so there’s quality of service and routing that we can provide. We might also have security built into this, zero trust network access, firewall is a service, and DNS security are just a few examples of what SASE can provide.
And because the SASE clients are installed on all of the devices and these connections are made automatically, the users don’t have to worry about turning on or turning off this SASE functionality. The users simply use the devices they’ve always used. They connect to the applications that they need to access, and security is built in to the entire process.