#GoToGetsIT: This article is part of an ongoing series from GoTo’s thought leaders on the frontlines: Our Solutions Consultants deeply understand our customers’ unique challenges and connect the right solutions to meet their goals using GoTo technology. Here, they share their industry knowledge on what it takes to help businesses everywhere thrive in a remote or hybrid world.
Commonly, organizations consider the value of deploying IT systems within their own on-premises environment so that they can control their data and the environment, as opposed to trusting a cloud vendor with their data, communications, and access capabilities. But is this approach justified? With the accelerated proliferation of cloud services, are organizations heading towards mass exposure and risk?
On-prem comes with heavy customer responsibility
IT managers have a lot on their plates. Systems deployed on premises put a greater responsibility onto the IT manager or IT partner looking after their customer. With this responsibility, there are numerous things to consider for a healthy platform:
Software assurance (SA)
Software deployed on premises needs to be maintained at the most current level to ensure security patches are available to the customer. Software assurance is the mechanism that entitles the customer to receive these patches and updates to the platform. In practice, many customers lapse their SA and find that they are exposed. Lapsing of SA can lead to re-enlistment fees and delays in re-enablement due to internal and vendor processing speed.
Having current and valid SA may not be enough. You still need to apply the patches. If the software in scope is a key business application, like a telephone system, then you need to schedule for an after-hours period. Then there is the question of who does it. Traditional on-premises platforms require that a certified engineer carries out upgrades. Hence having a maintenance contract in place is critical for on-premises deployments.
Vigilance of the vendor
Many vendors of onsite software will define the underlying hardware and operating system (OS) their applications can be deployed on. This makes sense to minimize the variations of the deployments and provide a means to define the scalability and functionality of the platform.
From a security perspective it still means that there are many permutations of hardware and OS that need to be tested for vulnerabilities. As an example, telephone or Unified Communications (UC) systems can be deployed on proprietary hardware, industry standard servers and virtualized platforms, deployed in Windows or Linux environment. The vendor needs to be vigilant across a very broad set of vulnerabilities and test how their software performs in any of these permutations. Therefore, the speed at which all the instances can be tested, verified and delivered, will be affected.
The above is further compounded by the process used to apply the fix. On-premises deployments translate to many instances across many customers. When certified engineers are required to perform this task, the resource needs to be planned and scheduled. It is therefore not something that is updated in minutes but in days, weeks, and sometimes months.
Multi-level security accreditations
At the vendor, service provider, hardware, and OS provider levels there is a commitment to ensure that all parties involved work to the same standard. However, not all customers can afford to use a service provider that has valid ISO 27001 accreditation or are large enough for that service provider to look after them.
On-premises vs cloud vendor differences
Vendor profile and vigilance
The security outlook of a vendor that sells on-premises software is often quite different to a public cloud vendor. There is a level of assumption from the perspective of an on-premises vendor that they are insulated and protected by the bricks and mortar that encapsulate their software platform. Much of the security focus is placed on the customer, who is responsible for ensuring they have their own right measures put in place in their network and firewalls.
Public cloud-based vendors understand that they are always at risk of being exposed. As a result, they take preventative and precautionary measures to always test their platform. Since the risk of exposure is significantly higher, they are diligent about putting in place security measures; this is seen as an investment in their service.
Software as a service (SaaS) providers will therefore persistently take measures to control who has access to the platform and ensure that they have perimeter defense and intrusion detections in place to prevent unauthorized network traffic from entering the product infrastructure. SaaS providers also contract data centers that provide the highest levels of physical security and environmental controls. These providers will make certain that data will be encrypted in transit, for example, as the data is exchanged between the end user and the cloud provider as well as at rest when the cloud provider stores things like call recordings, user data, and metrics.
Security as a service or add-on
SaaS providers will see single sign-on (SSO) and Multi-factor Authentication (MFA) as core to their offering while an on-premises vendor may see that as a value feature to charge for. For example, UC vendors often charge for call encryption or for Secure Sockets Layer (SSL) certificates.
Boundaries expanded beyond brick and mortar
The change in working from anywhere has meant that an inherently secure, in-office environment now needs to be extended to a network outside of the organization and to devices sourced by the end user. From a Unified Communications perspective, the domain of an in-office phone has moved to an app on a desktop, a browser, or a mobile device via an internet connection. As a result, the customer using an on-premises platform needs to be as diligent as the Unified Communications as a Service (UCaaS) provider, but also repeat this diligence across their entire software stack.
Consider if multiple vendors can play nicely
Few applications operate in standalone mode. For example, a Unified Communications platform may need to operate in a Microsoft 365 or Google Workspace framework and will need a contact center, reporting, etc. For an on-premises platform, they may need to add a third-party call recorder in order to capture the IP voice traffic. Often, the encryption on the handsets is disabled to allow the call recorder to do that or to add a Session Border Controller (SBC) that decrypts the messages. SIP Trunks connected to an on-premises telephone system are often not encrypted. Some Tier 1 providers insist on a private network to circumvent this, but most of the Tier 2 and below do not. (Here are some examples of Australian SIP trunk providers accredited for a sample on-premises telephony vendor showing lack of SIP TLS support.)
Reducing the IT vendor stack can reduce security exposure. For instance, GoTo provides unified communications tools like phone, meeting, messaging, customer engagement, contact center, and webinar, as well as IT management and support like remote monitoring and management (RMM), IT automation, patch management, ticketing, remote support, and more, all from one vendor.
The bottom line: How hands-on are you prepared to be?
On-premises software deployments have the benefit of being customized to a specific requirement. This customization, however, can be expensive both to implement and to maintain securely. Cloud-based solutions reduce complexity and take on many of the security responsibilities otherwise left to the customer.
GoTo is dedicated to monitoring and continuously improving our security as well as technical and organizational measures to better protect sensitive customer content. We are always evaluating industry standard practices regarding technical data privacy and information security and strive to meet or exceed those standards. Our security programs are comprehensive and dedicated to all facets of security. For more information across all GoTo products please visit our trust resource center.