Extraordinary times call for extraordinary measures.
Many people have uttered this phrase in light of COVID-19. One of those extraordinary measures has been a pivot to remote work for many of us. In this context, access to critical apps is often discussed. But rarely do we hear the details about how that access has been enabled.
One of the ways that access has been enabled is by opening up RDP. It's no surprise that SANS noted Shodan saw a marked increase in the number of open RDP ports across the Internet at the end of March. Many folks rely on this most basic of options for enabling remote access direct to desktops.
Although RDP is probably the most often mentioned protocol when it comes to remote access right now, it seems operational consoles across IT are also being similarly allowed unfettered passage through the corporate perimeter. The same SANS blog contains a very interesting graph that, in addition to increases in open RDP ports, shows a significant uptick in open ports running on 8080.
Now, 8080 is the 'alternative to HTTP' port. Anyone who has deployed web apps will recognize that it's pretty much the default for frameworks and operational consoles.
Generally speaking, operational consoles have their own methods of controlling access. Credentials are required, so there are ways to limit who can suddenly start up a cluster or shut down an app or make changes to a running config. The problem, of course, is that when we look at the number of incidents that have occurred thanks to a lack of access control—i.e. no credentials required—for operational consoles, there is no doubt that some of those operational apps are running wide open, with no protection between them and the Big Bad Internet.
It's important to remember that operational consoles are, fundamentally, applications. They are composed of externally sourced components, just like any other app. They are developed using the same libraries and frameworks as any other app. They are deployed on the same platform as any other app.
Which means they need to be protected, like any other app, because they are vulnerable to the same exploits as any other app.
We can’t just rely on moving operational apps to a different port. In the age of automation, where bad actors have access to vast networks of bots to scan for open ports, they will be found. Coupled with the ability to fingerprint a response on any given port, apps will be found on non-standard ports. Security through obscurity isn’t a viable strategy today because the time and financial investment required to find targets is minimal.
We know from our research that a significant percentage of applications are protected by a web application firewall. What we don't know is what percentage of those applications are operational or business-oriented.
It may be time to start finding out.
As organizations progress on their digital transformation journey, they are going to rely more on operational apps to build, deploy, and operate the apps and app services that represent the business. Those operational apps need to be treated with the same criticality as any other app that expresses a business function. They need to be protected against malicious use because they can and will have a direct impact on the business if they are misused.
A lot of folks are saying this is the new normal; that remote work will be more acceptable and even preferable to many organizations after this pandemic passes. Remote work includes operators of applications and infrastructure who need access to the consoles that keep them in control. But those consoles—those operational applications—need to be protected from abuse and misuse to make that a reality. A basic set of protections should:
It's (past) time to make sure your security strategy includes operational apps as well as business critical apps. Because in the long term, operational apps are going to be business critical apps.
Stay safe out there. Personally, and operationally.