Readers of classic science fiction will likely recognize the reference to Robert Heinlein’s 1950s novel. In this futuristic tale, the characters must use a tunnel between Earth and an unfamiliar (and inhospitable) planet in order to take a survival test. The novel has insights that can be applied to modern security requirements regarding the use of SSH and RDP—the subject of today’s blog.
Let’s start with SSH, which is well-known as both a protocol and a client because it enables SecOps teams to securely control and monitor remote computers. However, SSH has more to offer; for example, it can be used to route local network traffic to a remote destination, or it can even be used to securely transfer files—and it is as simple to use as a UNIX file copy command.
RDP is similarly powerful. For average users, RDP is useful for desktop sharing. It is, however, quite mature (nearly 20 years old!). Not only does RDP permit desktop sharing and remote control, it also allows for file transfer, drive mapping, and even printer access—and all through an encrypted tunnel. This proprietary Microsoft protocol has been built into Microsoft Windows operating systems since XP, but Microsoft permits third-party vendors to use this universal standard.
Why is this relevant? As end-to-end encrypted tunnels, SSH and RDP bypass many perimeter security controls, and often, these protocols are opportunistically established between endpoints and third parties—with no regulation. Enterprises that access third-party systems using these protocols should create a workflow that ensures these protocols are regulated and keeps data confidential, unmodified, and readily available. This is not trivial, but necessary if organizations wish to reduce their threat surface area.
Authentication, Authorization, and Accounting + Virtual Jump Box
One approach is to break the workflow into two parts: managing access and isolating the data. This approach requires a separate jump box (also known as a jump host, jump server or even SAW—secure admin workstation), and ideally, the jump box would be implemented as a virtual machine to speed provisioning. The jump box would be equipped with the security controls required for data scanning and secure internal user access, isolation from internal shared resources, and limit access to only the third-party system. Think of the jump box as a safe location that holds all of the tools required for evaluating data prior to allowing it into a network.
Let’s walk through this. Imagine you’re an employee at Company ABC and you require access to data on a third-party system—data that your team may want to purchase for recurring use, for instance. You will need to evaluate this system before making a purchasing decision, so you ask your IT team to obtain connection information (destination IP, tunnel information, SSH-key, credentials, etc.). The following could then occur:
If you like what you see, the IT team marks the jump box as a semi-permanent resource and coordinates times for its use. If the business relationship terminates at a later date, the jump box and its policies can be decommissioned and even deleted after a time period that aligns with the company’s security policy. This workflow is illustrated below:
Best practices include:
While initially SSH and RDP protocols may not be considered threat vectors, they can introduce risk. The workflow discussed adds some complexity but it also enables an adaptive approach that leverages the strengths of multiple teams and permits rapid provisioning, secure access, and simplified decommissioning.
The primary focus of SecOps teams today is to protect users as they navigate through the “deep space” that is the Internet. A modern SecOps professional may not necessarily relate to the term “survivalist,” but I don’t think it’s that much of a stretch in today’s digital ecosystem.
Do you recommend another approach? Email me!
The mission of the NSS Labs enterprise architecture research group (EARG) is to work with enterprises to solve security architecture and product challenges. We provide research and advisory services that are objective, accurate, reliable, and actionable. Our data comes from NSS Labs test results, first-hand experience in the lab, and interaction with our enterprise clients.
Follow us on Twitter (@NSSLabs) to keep informed as new research is released.