VNC is a protocol used by a number of products for remote viewing and control of devices. I am also including services such as X11 in this discussion. Ultimately, this includes any remote viewing software that is not native to an application that runs persistently on the end device.
Identity Access Management
Software like this, many times, does not integrate into existing directory services and requires manual management of user access. The default configuration often requires no password. This can lead to information disclosure at the least and PrivEx and RCE at the worst.
Anytime an application takes the management of IAM out of the centralized IAM processes it adds significant risk to the organization. Not only is identity and authentication managed by the application now, someone has to take ownership of the employee lifecycle. Who is going to disable accounts and change passwords if someone is terminated?
Additionally, if the cloud components are used, it can allow remote access to internal systems without any internal authentication, logging, notification, or 2FA.
Many of these systems do not natively log to the Windows Event Log or to existing monitored repositories. Most have logging, but it is to a plain text file or it is not using standard Windows/Unix logs. At the least, this means that the logs are not going to be natively recognized by SIEM or automatically included in existing dashboards or reports.
At worst, the systems would not see remote login attempts, usernames, or access. In highly regulated environments, this means you cannot show that a user accessed information or systems.
Basically, these services turn an end user device into a server listening on a port for remote connections. The connections, if not properly configured, do not require user interaction to start and can be transparent to the end user. This could lead to disclosure of confidential information.
This requires adding additional, often well-known ports as exceptions to firewalls as well as running services as system that are not part of a centralized patch management process.
This is one of the biggest risks. It is a non-standard process, that is not managed by centralized services such as AD, group policy, log management, IAM etc.
It is an exception to most security processes with limited detective and preventative controls. In other words, its difficult to enforce any sort of required settings with existing systems.
There are also a number of enterprise solutions that provide the same functionality, which makes it hard to justify a business case for using software like this.
Everyone should have a standard policy for handling these types of remote connections. At the very least, they should utilize all of the standard, centralized security processes. This usually knocks them all out of the running. There are legitimate business needs for this type of access, so it would also be advisable to have a solution to offer in place of these.