Do you have to connect to a VPN to check your banking statement and wire money to different bank accounts? No. So why do your remote operators need to connect to a VPN to answer a phone call?
Imagine a day when your remote Telephone Answering Service (TAS) operators only have a single login to remember for all of their applications, do not have phone quality issues due to VPN network latency, and you are able to meet all of your customer regulatory requirements (e.g. HIPAA, PCI, etc.) because your answering service and the TAS vendors have made security a top priority. This day is not far away and was hinted at during the Startel National User Group (SNUG) conference that Relay Hawk attended in Tucson, AZ, this past week.
Matt Bogan, a Product Manager at Startel, mentioned Zero Trust in his talk, Agent UX: An Unchartered Wilderness, and said Zero Trust would replace traditional VPNs in the coming years. I am a big proponent of Zero Trust, and I caught up with him afterward to chat about how he thought it would impact answering services. Matt said, "As cyber threats continue to evolve, traditional VPNs are becoming less and less effective. The TAS industry must shift to a Zero Trust model to keep up with the changing threat landscape."
This blog is an overview of Zero Trust Architecture, how it will impact answering services, and what you can do in the short-term to mid-term to protect your business and prepare for the future. Let's dive in.
An important note
In this blog, we will not debate where your business should host the TAS software on-premise, in the cloud, or be a SaaS application. This blog post is applicable regardless of where your business is hosting its TAS software.
Additionally, we will not dive into the implementation details. The transition from VPNs is not imminent, and this blog will stick with high-level conceptual information. We will look into the future when traditional VPNs don't exist and what you need to do to prepare for the future.
The purpose of a VPN
Remote answering service operators must connect to the TAS software before they can start taking calls. The software requires that the operator have access to the same network that the TAS software has access to. The way they connect to the same network is over a VPN.
In this blog, we will often refer to these VPNs as "traditional VPNs" because newer technologies are emerging that improve user experience, reduce latency, and are more secure. More recent technologies use a zero-trust architecture which this blog post will discuss later. Still, some people may refer to these as VPNs because it is what answering service owners and IT managers are familiar with.
How traditional VPNs work today
Traditional VPNs require that a remote user connects to the VPN to access the services to perform their job functions. The three most popular ways to authenticate the user before permitting access to the VPN are to:
- Authenticate the user with a username and password.
- Authenticate the user with a pre-shared key.
- Authenticate the user with a certificate stored on the device.
If you have a remote office, you can connect the two networks with a site-to-site VPN so the users do not need to install a VPN on their machines.
After connecting to the VPN, the device can access the networks and services as if the user physically connected their device to the same network as the TAS software.
The problems with traditional VPNs
Lack of segmentation
Traditional VPNs grant devices broad access to a network. Security best practices for networking recommend that you segment the network so that the devices can access only what they need to access. However, in practice, this is not done. Most telephone answering services will keep all applications and services on the same network, also called a "flat network." Having a flat network means the operator can connect to the TAS software and databases, security cameras, billing software, and other software they may not need direct access to. A flat network is not a problem on a day-to-day basis, but what happens when a device connected to a VPN is compromised and begins attacking your flat network? The compromised device can then attempt to compromise everything on the network.
Lack of visibility
Once your users connect their devices to a VPN, it can be challenging to determine what device is performing what actions on a network. Imagine that an operator's device is compromised, and the operator has connected to the VPN. The device will wreak havoc on your systems, and you will have difficulty determining the compromised machine.
Lack of device enforcement
How do you know if a device connecting to the VPN has the latest operating system updates installed, has antivirus running, and have the other various technical controls implemented that customers and regulatory bodies (e.g. HIPAA, PCI, ISO 27001) require?
According to Rob VanBuskirk of VanRein Compliance, "Our TAS clients are experiencing a rise in demands from their customers to guarantee that security measures like the most recent operating system updates, antivirus protection, and full disk encryption are in place on operator workstations." Traditional VPNs do not check this information, and you are left hoping that all devices implement the appropriate security policies.
Note: these problems are not unique to VPNs but are issues with the traditional network architecture. The proposed solution will remediate these concerns whether or not you are on a VPN or on-premise. However, the problems are exacerbated by remote devices connecting over a VPN because you are less likely to have control of devices not on-premise.
Enter Zero Trust Architecture
If you Google "Zero Trust," you will see tens, if not hundreds, of advertisements for cybersecurity companies trying to sell you "Zero Trust" software. Each company does something different, and even their definitions of Zero Trust will differ (some much more than others). So what exactly is Zero Trust security architecture, and where did it come from?
John Kindervag, an analyst for Forrester Research at the time, coined the term "Zero Trust" in 2009 and said that you should "Never trust, always verify" source. It was made popular by Google in 2014 when they released a paper titled Beyond Corp, A New Approach to Enterprise Security, which is the first well-documented approach to implementing Zero Trust at scale.
An overly simplified definition of Zero Trust is that every application must first authenticate the user and the device and then check to see if they are authorized to access the application based on a set of criteria.
Authentication is ensuring that the user or device is who they say they are. You can authenticate a user one of three ways: by something they know (e.g. a password, passphrase), something they have (e.g. a hardware token the company has issued, their cellphone), and something they are (e.g. their fingerprint). When people mention Two-Factor Authentication (2FA) or Multi-Factor Authentication (MFA), they refer to authenticating the user with two of the three ways to authenticate a user.
Authorization validates that the user or device has permission to access the application.
In a zero-trust architecture, each application must do the following:
- Securely authenticate the user
- Securely authenticate the device
- Authorize the user and device against an access policy
Securely authenticate the user
The first step before an application can grant access in a zero-trust architecture is to authenticate the user. "Secure" means that you check two forms of authentication, such as a user's passphrase and a token (e.g. hardware token or a code sent over SMS).
Securely authenticate the device
This section is where things will likely be new to you.
All devices are not equal. A personal mobile device is different from a company-issued device, and you likely want to handle their access policies differently. Do you want an employee logging into your TAS software with access to medical information on their mobile device? Likely not. To know what is accessing an application, you must first authenticate the device to know what device it is.
Authorize the user and device against an access policy
Before an application can grant access to a user and device, it must check if they have the necessary configuration to access the application.
The application's user authorization policy may say that the user must be in the group "operators" to log in to the application.
The application's device authorization policy can require that a device meet specific requirements such as whether the operating system has installed the latest updates, it is a laptop and not a mobile device, a company device policy manages the device, the device is in the US and not another country.
For any of this to work, you must have an inventory of
- Applications
- Users
- User access levels (e.g. management, supervisor, operator)
- Devices
- Current device configuration (e.g. latest installed operating system update version, latest antivirus update version, desktop or mobile)
- Permissions (e.g. the TAS software requires the user to be an operator or supervisor, and the device must have the latest operating system updates and antivirus updates installed)
Creating an inventory may sound like a lot. However, if you have Active Directory or Google Workspaces, you have most of this already. For organizations that don't, you have more work to do than those who do.
Example Zero Trust Workflow
The following is an oversimplification of a workflow and only includes some technical components required. However, it provides a representation of what you can expect a zero-trust workflow to look like.
- The user opens a web browser and accesses the TAS web application.
- The user clicks "login," and the website presents the user with the company's login page hosted on their Identity Provider (IdP).
- The IdP will securely authenticate the user.
- The IdP will securely authenticate the device.
- The IdP will check to see whether the user and device meet the authorization policy required by the application.
- The IdP will grant the user and device access if everything is successful.
One great benefit of using an IdP is that the operator does not have to remember a unique username and password for every application. Remembering only a single set of credentials reduces the cognitive load on the operator. It also reduces the likelihood of an attacker compromising the user's credentials because you securely authenticated the user.
Another great benefit is that the operator did not have to remember how to connect their VPN. Not requiring the user to remember what to click on to join the VPN also reduces the cognitive load on the user.
One last benefit is the reduced network latency because everything does not have to tunnel through a VPN.
What can you do today to prepare for the future
This blog post has hopefully convinced you that a zero-trust architecture is excellent for security and user experience conceptually. Still, the organization and software must be ready for this radical change.
Short-Term
Review your VPN access policy
The most tactical thing you can do today is to review your VPN access policy. Ensure that it requires users to log in with a username unique to the user, a complex password (e.g. 12 characters), and requires Two-Factor Authentication. Requiring 2FA will prevent an attacker from being able to steal an operator's user credentials and log in to your VPN. You can read more about this in our blog post, A Guide to Creating and Managing Passwords.
Mid-Term
Implement a Remote Monitoring and Management tool.
If you don't have a way to manage your devices remotely, start thinking about ways to do this. Your customers are going to begin requesting this if they aren't already. You should not have to manually log in to a machine to update the operating system or applications. You should also have an easy way to see if everything is up to date. I recommend using a well-known product to do this, which will be supported by other products when you need to tie it into your Zero Trust Architecture.
- If you are Microsoft 365 customer, consider Azure Active Directory - Managed Devices and Microsoft Intune.
- If you are a Google customer, consider Google Windows Device Management.
Implement device authentication and authorization within the VPN.
VPNs and Firewalls such as SonicWall and Cisco are adding support for checking device configurations before allowing them to connect to the VPN. The device would still have access to the entire network. Still, at least you could guarantee that the device connecting has implemented your company's security policy.
Conclusion
The shift to Zero Trust will improve your operators' user experience, reduce network latency, and reduce the likelihood that your business will be a victim of a cybersecurity attack. The road is not short to reach this end state, but if you work on the steps mentioned in the short-term and mid-term sections, you will be well on your way. However, as an answering service, you are not the only puzzle piece. The TAS software vendors must also prioritize supporting a zero-trust architecture.
If you have thoughts on this, we can talk on Twitter @jmassey09 or email me at justin@relayhawk.com.
If you would like to learn more about protecting your business, Relay Hawk is here to help. Relay Hawk's product reviews your business security footprint. It identifies ways to improve your security posture to reduce the likelihood of a successful cybersecurity attack. We will also work along side you as you begin your journey to a zero-trust architecture. You can request more information about Relay Hawk and sign up for our newsletter below.